Firewall lässt sich nicht starten

[Marco M.]

Hi!

Ich habe seit knapp einer Woche einen vServer von 1blu gemietet. Auf dem Ding läuft SuSE 10.0 mit nem

[hostname]:~ # uname -a
Linux [hostname] 2.6.9-022stab078.14-smp #1 SMP Wed Jul 19 14:16:50 MSD 2006 x86_64 x86_64 x86_64 GNU/Linux
Kernel.
Das aktivieren der Firewall über die mitinstallierte Plesk-Oberfläche spuckt einen Fehler aus. Also bei Support angerufen und den Jungs mein Problem geschildert. Nach mehreren Nachfragen von dem Supportbubi bei seinem großen Kollegen kam raus, dass man die Firewall über Plesk nicht aktivieren kann, das ginge nur per SSH.
Also habe ich eben via SSH und yast die Firewall anschmeißen wollen, was sich aber auch nicht ging:

[hostname]:~ # SuSEfirewall2 start
SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled.
SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
FATAL: Could not load /lib/modules/2.6.9-022stab078.14-smp/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.9-022stab078.14-smp/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.9-022stab078.14-smp/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.9-022stab078.14-smp/modules.dep: No such file or directory
//sbin/SuSEfirewall2: line 422: /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts: Operation not permitted
//sbin/SuSEfirewall2: line 422: /proc/sys/net/ipv4/tcp_syncookies: Operation not permitted
//sbin/SuSEfirewall2: line 422: /proc/sys/net/ipv4/tcp_ecn: Operation not permitted
//sbin/SuSEfirewall2: line 422: /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses: Operation not permitted
//sbin/SuSEfirewall2: line 422: /proc/sys/net/ipv4/ipfrag_time: Operation not permitted
//sbin/SuSEfirewall2: line 422: /proc/sys/net/ipv4/ip_local_port_range: Operation not permitted
SuSEfirewall2: batch committing...
FATAL: Could not load /lib/modules/2.6.9-022stab078.14-smp/modules.dep: No such file or directory
iptables-batch v1.3.3: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
SuSEfirewall2: Error: iptables-batch failed, re-running using iptables
FATAL: Could not load /lib/modules/2.6.9-022stab078.14-smp/modules.dep: No such file or directory
iptables v1.3.3: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Could not load /lib/modules/2.6.9-022stab078.14-smp/modules.dep: No such file or directory
iptables v1.3.3: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
SuSEfirewall2: Firewall rules successfully set

Nun kann ich nicht mal mehr eine Namensauflösung durchführen. Also habe ich die Firewall wiedergestoppt und bei 1blu angerufen.
Auf Nachfrage teilte der 1blu-Supporter mir mit, dass es auch über yast nicht ginge, sondern nur über die IPTables direkt.

Also habe ich mir von Harry's Firewallgenerator ein Skript bauen lassen (sh. Anhang).
Als ich das Skript ausgeführt habe, wurde der Rechner allerdings so dicht gemacht, dass er von außen gar nicht mehr zu erreichen war. Nur noch ein Neustart half da weiter.
Da ich leider wenig bis gar kein Vertrauen in die Fähigkeiten von dem auf der Webseite von 1blu gepriesenem Experten habe ( "Lassen Sie sich von einem unserer Experten individuell beraten.") frage ich hier mal nach ob, jemand von Euch eine Idee hat wie ich das Problem lösen könnte.

Ich freue mich über alle Anregungen.

Gruß
Mauri

PS.: Die Sufu vom Forum resp. Google habe ich bereits mehrfach ohne Erfolg bemüht

[Rain_maker]

Hallo,

Der Kernel ist jedenfalls kein SuSE-Kernel, die 10.0 hat einen 2.6.13-15.x.

Was ergibt


ls -ls /lib/modules/?

Greetz,

RM

[Marco M.]

dieses hier:


[hostname]:/etc/apache2 # ls -ls /lib/modules/
insgesamt 8
4 drwxr-xr-x 2 root root 4096 2005-09-10 01:35 .
4 drwxr-xr-x 7 root root 4096 2006-08-11 14:15 ..


Hab mich auch schon gewundert das dort nix drin steht. Aber woher bekomme ich die Module?

Gruß
Mauri

[Rain_maker]

Wie vermutet.



FATAL: Could not load /lib/modules/2.6.9-022stab078.14-smp/modules.dep: No such file or directory ==> Da ist nichts.

Dein Kernel ist monolithisch, so einfach ist das.

Dann kann es auch nicht mit der SuSEfirewall klappen und zumindest der Teil aus Harry's Script bringt nix:



# iptables-Modul
modprobe ip_tables
# Connection-Tracking-Module
modprobe ip_conntrack
# Das Modul ip_conntrack_irc ist erst bei Kerneln >= 2.4.19 verfuegbar
modprobe ip_conntrack_irc
modprobe ip_conntrack_ftp Welche Module soll das Script auch laden, wenn keine da sind?

Fällt aus wegen ist nicht.

Entweder netfilter/iptables ist fest einkompiliert oder es ist nix mit iptables-Firewall.

Ist denn überhaupt der Befehl 'iptables' vorhanden? Wie sieht Deine Kernelkonfiguration aus?

Greetz,

RM

[Marco M.]

Iptables gibt es.
es scheint unter /usr/sbin/iptables zu liegen.

Ein IPTables -L zeigt dass alle policies auf accept stehen, keine Ausnahmen sind definiert.
Wie kann ich mir denn die Kernelkonfiguration anzeigen lassen? Ich habe mir bisher noch keinen Kernel selber gebaut, sondern die Konfiguration von 1blu einfach übernommen.

Schon mal danke für Deine Hilfe

Gruß
Marco

[Marco M.]

Ich habe nun etwas anderes versucht.

erst mal meine momentanen Regeln

[hostname]:/tmp # iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


dann mal eine Überischt meiner interfaces:

[hostname]:/tmp # ifconfig
lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:286817 errors:0 dropped:0 overruns:0 frame:0
TX packets:286817 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:0
RX bytes:61018781 (58.1 Mb) TX bytes:61018781 (58.1 Mb)

venet0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:127.0.0.1 P-z-P:127.0.0.1 Bcast:0.0.0.0 Maske:255.255.255.255
UP BROADCAST PUNKTZUPUNKT RUNNING NOARP MTU:1500 Metric:1
RX packets:4975 errors:0 dropped:0 overruns:0 frame:0
TX packets:4825 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:0
RX bytes:610531 (596.2 Kb) TX bytes:1308701 (1.2 Mb)

venet0:0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:xxx.xxx.xxx.xxx P-z-P:xxx.xxx.xxx.xxx Bcast:0.0.0.0 Maske:255.255.255.255
UP BROADCAST PUNKTZUPUNKT RUNNING NOARP MTU:1500 Metric:1

Nun habe ich versucht eine Regel von Hand einzufügen und bekomme diese Fehlermeldung:

[hostname]:/tmp # iptables -A INPUT -i venet0 -m state --state NEW -p tcp --dport 22 -j ACCEPT
iptables: No chain/target/match by that name


Leider habe ich gerade keine Idee woran das liegt? Kann mir mal jemand auf die Sprünge helfen?:o

Danke schon mal.

Gruß
Mauri

[psy]

verschoben nach sicherheit

[Marco M.]

Hi,

Also bisher konnte ich noch nicht rausfinden, woher die Fehlermeldung aus meinem letzten Post stammt. Aber ich habe mir jetzt mal eine gaaanz einfache Firewall gebastelt (Anhang) und bin nun sehr erstaunt über die Ausgabe von

[hostname]:/tmp # iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere tcp dpt:domain

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


Bedeutet die erste Regel der INPUT-Chain nicht, dass alles von überhall reingelassen wird?:eek: Wie deckt sich dass denn mit dem ipchains script? :confused:

Auch seltsam finde ich, dass nach ausführen des FW-Skripts keine Namensauflösung mehr funktioniert.

Schon mal Danke für alle Hilfe.

Gruß
Mauri

[Harry]

Hi Marco,

Bedeutet die erste Regel der INPUT-Chain nicht, dass alles von überhall reingelassen wird?:eek: Wie deckt sich dass denn mit dem ipchains script? :confused:
nein - es bedeutet lediglich, dass die Ausgabe von "iptables -L" unvollständig ist und die Interface-Regeln z.B. nicht anzeigt.
Ein "iptables -L -vn" gibt Dir alle konfigurierten Details aus.


Auch seltsam finde ich, dass nach ausführen des FW-Skripts keine Namensauflösung mehr funktioniert.

Das ist nicht wirklich seltsam. Du lässt mit Deinem Skript für das DNS lediglich TCP-Pakete zu; typische Namensauflösungen werden hingegen über UDP durchgeführt.

Noch ein Hinweis: Deine Conntrack-Zeile wird so nicht funktionieren. Vielleicht schaust Du Dir einfach mal auf meiner Seite den iptables Generator an, lässt Dir dort ein Skript generieren und baust Dir daraus etwas passendes.

Harry

[Marco M.]

Hi,

Danke für Deine Tipps. Nachdem ich iptables -L -v aufgerufen habe war es dann klar. DNS Anfragen gehen jetzt auch.

Allerdings habe ich aus einem Skript von Dir mal


modprobe ip_conntrack

iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

übernommen.
Das Modul nachladen klappt leider nicht da ich einen monolithischen Kernel habe und die beiden iptables Aufrufe werden mir auch nur mit zwei

iptables: No chain/target/match by that name quittiert.

Auf Anfrage bei 1blu, wo denn der Hase im Pfeffer liegt bekam ich dies hier als Antwort:

Die Firewallfunktionalität kann gegenwärtig ausschliesslich über die Shell mit
der Standart- Tabelle "filter" genutzt werden. Diese umfasst INPUT, OUTPUT und
FORWARD Regeln. Um diese zu definieren, müssen das Kommando

iptables -t FILTER -A "Optionen"

ausführen.

Naja nicht sehr ermutigend da es mir nicht sehr dabei weiterhilft die Ursache dieser Fehlermeldung

iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
bei diesen Regeln nachzuvollziehen:

iptables -A INPUT -m state --state INVALID -m limit --limit 7200/h -j LOG --log-prefix "INPUT INVALID "
iptables -A OUTPUT -m state --state INVALID -m limit --limit 7200/h -j LOG --log-prefix "OUTPUT INVALID "
Ich muss doch irgendwie Pakete loggen können.

Bitte helft mit weiter.

Danke schon mal für alle Hilfe bisher!!

Gruß
Marco

[Harry]

Hi Marco,

Naja nicht sehr ermutigend da es mir nicht sehr dabei weiterhilft die Ursache dieser Fehlermeldung

iptables: No chain/target/match by that name
ich tippe mal, dass der monolithische Kernel ohne Connection Tracking/Stateful Inspection gebaut wurde. Das würde die Fehlermeldungen erklären. Übrigens würde das auch die Fehler beim Starten der SuSEfirewall2 erklären ;)

Lt. der zitierten Aussage von 1blu fehlt offensichtlich sowieso einiges an iptables/netfilter-Funktionalität auf dem Host bzw. auf dem VServer, wenn schon nur die Tabelle filter genutzt werden kann. Es würde mich dann auch nicht wundern, wenn diverse andere "Module" oder Targets ebenfalls nicht ansprechbar sind.

Harry

[Marco M.]

Danke für die Antwort.

Grml... :mad: Ich hab ja immer noch gehofft dass mir jemand sagt, dass ich einfach nur was grundlegend falsch mache und meine Vohaben fehlschlägt weil ich Schuld bin. Aber so muß ich ja die Jungs von 1blu dazu bringen einen neuen Kernel zu bauen. Das drüfte schwierig werden.

Aber vielen Dank für Eure Hilfe!

Oder hat doch noch jemand eine Idee wie ich trotz der auferlegten Restriktionen wenigstens die verworfenen Pakete mitloggen kann?

Gruß
Marco

[kyosanim]

Ich hab leider genau das gleiche Problem...


iptables: No chain/target/match by that name

Auch ich habe einen vServer von 1blu... Die typen vom support helfen mir auch nicht weiter...

Ursprünglich wollte ich meine Firewall-regeln bequem per Virtuoso eintragen. Aber bei mir geht dies nicht richtig. Ich kann die Regeln zwar eintragen, bekomme dabei aber immer eine Fehlermeldung. Die Regeln sind zwar eingetragen, aber nach einem Reboot wieder weg.
Ich vermute jetzt einfach mal, dass dies auch mit dem abgespeckten Kernel zu tun hat.
@Marco M. :hast du mittlerweile eine Lösung gefunden?
Hätt ich mir doch lieber einen richtigen Rootserver geholt, da kann ich wenigsten den Kernel selbstbaun...grml

mfg

[Marco M.]

Hi,

ich habe mir selber eine Firewall geschrieben. Nach einem Reboot ist die zwar auch wieder weg, aber das sollte ja kein Problem sein, wenn man sie in den init.d Bereich einbindet. Das automatische Starten kann man - glaube ich - auch per yast einrichten.

Auch wenn es ein bißl OT ist: Inzwischen frage ich mich ob eine Firewall überhaupt Sinn macht. Die Dienste die ich nach außen anbiete, sichert sie ja nicht ab (sonst könnte die ja keiner nutzen). Auf allen anderen Ports hört keine Anwendung, welche somit auch keiner Firewall bedürfen.
Viel wichtiger betrachte ich inzwischen das regelmäßige Einspielen von sicherheitsrelevanten Patches für die Dienste die laufen.

Gruß
Mauri

[kyosanim]

Ich glaub ich hab jetzt rausgefunden woran es liegt, dass diese Fehlermeldung kommt...
das module ip_conntrack ist nicht vorhanden...
Also alles was mit -m state --state XYZ zu tun hat wird nicht verstanden...

ein
cat /proc/net/ip_tables_matches zeigt auch das diese Option nicht verfügbar ist...

Könntest du mal deine FW-script posten bzw mir mal per email zukommen lassen? bin nämlich mittlerweile am verzweifeln...

Bei mir siehts jetzt so aus:

#!/bin/sh
ipt="/usr/sbin/iptables"

$ipt -F INPUT
$ipt -F FORWARD
$ipt -F OUTPUT
$ipt -P INPUT DROP
$ipt -P FORWARD DROP
$ipt -P OUTPUT ACCEPT
$ipt -A INPUT -i lo -j ACCEPT
$ipt -A INPUT -p icmp -m icmp --icmp-type 5 -j DROP
$ipt -A INPUT -p icmp -j ACCEPT

$ipt -A INPUT -p tcp --dport 20 -j ACCEPT
$ipt -A INPUT -p tcp --dport 21 -j ACCEPT
$ipt -A INPUT -p tcp --dport 80 -j ACCEPT
$ipt -A INPUT -p tcp --dport 443 -j ACCEPT
$ipt -A INPUT -p tcp --dport 4643 -j ACCEPT
$ipt -A INPUT -p tcp --dport 8443 -j ACCEPT
$ipt -A INPUT -p tcp --dport 8880 -j ACCEPT
$ipt -A INPUT -p tcp --dport 21337 -j ACCEPT
echo "Firewall aktiv"


Nur ftp geht nicht. liegt aber wieder daran das --state related,established nicht geht....

Also ich denk schon dass eine Firewall sind macht. Bei mir laufen z.b. Dienste die nach aussen nicht angeboten werden sollen, die ich aber trotzem brauche. Z.B smtp-dienst um aus meinen php-skripten mails zu versenden....

mfg

[Marco M.]

Hi, Wie Rainmaker schon gepostet hat, ist kein ip_conntrack vorhanden. Der Kernel ist monolithisch und lässt kein Nachladen von Modulen zu.

Ich hänge mal mein Firewallskript hinten dran, aber da du kein ip_conntrack hast, wird es meiner Meinung nach unmöglich werden Dienste die Du nutzt, NICHT nach außen freizugeben. Denn wenn du auf dem SMTP Port Traffic erzeugst, musst Du auch eine Regel haben die den Antworttraffic auf diesem Port wieder rein lässt. Ohne ip_conntrack gibt es aber keinen ANTWORTTraffic sondern nur Traffic. Ergo ist der Port entweder offen oder nicht.

Ach ja: Frag doch einfach mal den kostenlosen 1blu Support. Wenn wir nur lange genug Arbeit dadurch generieren dass sie keine vernünftigen Firewallfunktionalität bieten, ändert sich vielliecht was. :D

Gruß
Mauri

[majobu]

Hi,
bin ebenfall seit ein paar Tagen bei dem Verein 1blu und habe die gleichen Probleme mit dem Firewall-Skript von Plesk. Der Support reagiert nicht auf Anfragen :(

An solche Probleme denkt ja vorher niemand wenn man sich für einen vServer entscheidet :( Zugegeben, ich habe mich von dem Preis blenden lassen. Jetzt habe ich den Salat und muss damit vorläufig leben.

Daher meine Frage an die jenigen die ebenfalls bei 1blu sind: hat euch am Ende der Support geholfen, oder wie habt ihr das Problem mit dem Firewall-Skript am Ende gelöst?

Viele Grüße,
Marcus

[majobu]

Vielleicht interessiert es jemanden:

Ich habe gerade mit dem kostenlosen 1blu Support telefoniert. Der arme Mann am anderen Ende hatte so gar keine Ahnung wovon ich eigentlich rede. Nachdem er sich dann beim vServer Admin erkundigte, sagte er mir das SWsoft an einem Patch arbeitet damit das Firewall-Modul anständig arbeitet.

Naja... wer es denn glaubt....

[kyosanim]

Moin moin,
also ich hab vor ca. 3 Wochen ne Mail an den Support gerichtet. Nach 2 Tagen eine Mail von 1st-Level-Support mit dummen, unqualifizierten Tipps. Angeblich wurde meine Problem an "die Technik" weitergeleitet... Naja und seitdem haben die sich nicht mehr gemeldet.... Find ich schon etwas schwach!

Selbst wenn ein Patch für das Firewall-Modul von Virtuozo kommt, ich nutze IPtables ja direkt. Und ich glaub kaum, dass sich da was ändert.

Naja ich werd meine Lehre daraus ziehen. Nach den 12 Monaten geh ich woanders hin. Was bringt mir dieser "tolle" kostenlose 30min Installationssupport von 1blu wenn ich danach überhaupt keine Hilfe mehr vom Support erwarten kann....