Suse 9.1: Suse-Firewall verhindert SSH-Zugriff
Hi zusammen! Ich habe folgendes Problem: Ich habe einen VPS angemietet auf dem Suse 9.1 installiert ist. Zugriff auf den Server habe ich per SSH. Per YOU habe ich alle relevanten Updates eingespielt. Aktiviere ich nun per Yast die Suse-Firewall, dann kann ich mich anschließend nicht mehr per SSH anmelden, obwohl ich bei der Konfiguration angegeben habe, dass der SSH-Service erreichbar sein soll. Ich kann über ein Rettungs-System auf die Dateien des Servers zugreifen. Deaktiviere ich über diesen Zugriff die Firewall kann ich nach einem Neustart des Systems wieder per SSH auf den Server zugreifen. Hat jemand eine Idee, wie ich die Firewall konfigurieren muss, damit ich dennoch per SSH auf den Rechner zugreifen kann? Viele Grüße, Stefan
Stefan Kleeschulte wrote at Wednesday, August 31, 2005 6:52 PM
Hat jemand eine Idee, wie ich die Firewall konfigurieren muss, damit ich dennoch per SSH auf den Rechner zugreifen kann?
Also ich habe die 9.3 am Laufen, aber ich nehme an, dass sich da nicht allzuviel geändert hat: Es sollte reichen, wenn Du in /etc/sysconfig/SuSEfirewall2 im Parameter FW_SERVICES_EXT_TCP="" (bei 9.3 ist das der Abschnitt 9 des Konfigsfiles) "ssh" einträgst. Nach einem Neustart der Firewall mit "rcSuSEfirewall2 restart" sollte der Rechner dicht sein und ssh erlauben. Alternativ kannst Du das auch in yast konfigurieren. Wenn das nicht hilft, aolltest Du Dir mal die rules bei laufender Firewall mit "iptables -L" ausgeben lassen und Dir ansehen, was mit einem ssh-Paket beim Durchlaufen der Regeln passieren könnte ... HTH, Regards, Markus
Markus Heidinger schrieb: [...]
Also ich habe die 9.3 am Laufen, aber ich nehme an, dass sich da nicht allzuviel geändert hat: Es sollte reichen, wenn Du in /etc/sysconfig/SuSEfirewall2 im Parameter FW_SERVICES_EXT_TCP="" (bei 9.3 ist das der Abschnitt 9 des Konfigsfiles) "ssh" einträgst. Nach einem Neustart der Firewall mit "rcSuSEfirewall2 restart" sollte der Rechner dicht sein und ssh erlauben.
Alternativ kannst Du das auch in yast konfigurieren.
In /etc/sysconfig/SuSEfirewall2 hatte ich bereits nachgesehen, Yast trägt "ssh" dort korrekt ein. Ich habe dennoch keinen Zugriff per SSH.
Wenn das nicht hilft, aolltest Du Dir mal die rules bei laufender Firewall mit "iptables -L" ausgeben lassen und Dir ansehen, was mit einem ssh-Paket beim Durchlaufen der Regeln passieren könnte ...
Das Problem ist, dass ich nur per SSH auf den Server zugreifen kann. Und wenn die Firewall läuft, dann geht das halt auch nicht mehr. Viele Grüße, Stefan
Stefan Kleeschulte wrote at Wednesday, August 31, 2005 7:21 PM
In /etc/sysconfig/SuSEfirewall2 hatte ich bereits nachgesehen, Yast trägt "ssh" dort korrekt ein. Ich habe dennoch keinen Zugriff per SSH.
[...]
Das Problem ist, dass ich nur per SSH auf den Server zugreifen kann. Und wenn die Firewall läuft, dann geht das halt auch nicht mehr.
Naja ... Eine Firewall remote zu konfigurieren ist halt nicht das einfachste, denn Du müsstest einerseits die Rules sehen und andererseits bei aktiver Firewall das Log (/var/log/firewall) während eines Zugriffes beobachten ... Ich hab mich bei Versuchen, Firewalls von extern zu konfigurieren, auch schon regeäßig selber ausgesperrt :-( Trotzdem viel Erfolg, Gruß Markus
Markus Heidinger schrieb: [...]
Naja ... Eine Firewall remote zu konfigurieren ist halt nicht das einfachste, denn Du müsstest einerseits die Rules sehen und andererseits bei aktiver Firewall das Log (/var/log/firewall) während eines Zugriffes beobachten ... Ich hab mich bei Versuchen, Firewalls von extern zu konfigurieren, auch schon regeäßig selber ausgesperrt :-(
Nachdem ich mich ausgesperrt habe muss ich das System herunterfahren, um dann per Rettungssystem die Firewall zu deaktivieren. Nach dem herunterfahren wird /var/log/firewall allerdings offenbar gelöscht, die Datei existiert jedenfalls nicht. Gibt es eine Möglichkeit das Löschen zu unterdrücken? Ein Blick ins Logfile wäre ja vielleicht ein Anfang, ich habe nämlich bereits vergeblich in 'messages' und 'warn' gesucht. Viele Grüße, Stefan
Stefan Kleeschulte wrote at Wednesday, August 31, 2005 7:54 PM
konfigurieren, auch schon regeäßig selber ausgesperrt :-(
Nachdem ich mich ausgesperrt habe muss ich das System herunterfahren, um dann per Rettungssystem die Firewall zu deaktivieren. Nach dem herunterfahren wird /var/log/firewall allerdings offenbar gelöscht, die Datei existiert jedenfalls nicht. Gibt es eine Möglichkeit das Löschen zu unterdrücken? Ein Blick ins Logfile wäre ja vielleicht ein Anfang, ich habe nämlich bereits vergeblich in 'messages' und 'warn' gesucht.
Puuuh ... Wenn Du die Möglichkeit hast, Initskripte zu verändern/erstellen und in /etc/rc.d/rcX.d einzutragen, könnte es funktionieren, wenn Du die Datei vor dem Herunterfahren per Skript wegkopierst. Ein Cronjob der das tut könnte ebenfalls eine Idee sein, man müsste halt die Aktionen dann recht genau timen ;-) Ääähm ... Was ist das für ein Rettungssystem, das Du remote bootest? So ganz verstehe ich das nicht, warum Du nicht lokal an die Maschine kommst ... Regards, Markus
Markus Heidinger schrieb:
Puuuh ... Wenn Du die Möglichkeit hast, Initskripte zu verändern/erstellen und in /etc/rc.d/rcX.d einzutragen, könnte es funktionieren, wenn Du die Datei vor dem Herunterfahren per Skript wegkopierst. Ein Cronjob der das tut könnte ebenfalls eine Idee sein, man müsste halt die Aktionen dann recht genau timen ;-)
Ok, das Init-Skript konnte ich noch selber anlegen: Habe unter /etc/init.d eine Datei namens 'backup_firewall_log' mit folgendem Inhalt erstellt: #!/bin/bash mv /var/log/firewall /root/firewall exit 0 Und dann 'chmod +x /etc/init.d/backup_firewall_log' ausgeführt. Aber wie bekomme ich es jetzt hin, dass das Skript ausgeführt wird, bevor das firewall-Log gelöscht wird? Und wie kann ich das Ausführen später wieder deaktivieren? (Dazu reichen meine Linux-Kenntnisse leider noch nicht aus...)
Ääähm ... Was ist das für ein Rettungssystem, das Du remote bootest? So ganz verstehe ich das nicht, warum Du nicht lokal an die Maschine kommst ...
Also die Maschine ist ein VPS und ist bei meinem ISP gehostet. Das Rettungssystem funktioniert folgendermaßen: Das eigentliche System wird heruntergefahren und anstelle dessen ein Standard-Suse-9.1 gebootet. In diesem System sind dann die Dateien des eigentlichen Systems unter /repair gemountet. Entsprechend habe ich also z.B. die Datei 'backup_firewall_log' im Rettungssystem unter /repair/etc/init.d angelegt. Starten und Stoppen kann ich das ganze über ein Webinterface (Virtuozzo). Viele Grüße, Stefan
Stefan Kleeschulte wrote at Wednesday, August 31, 2005 8:51 PM
Aber wie bekomme ich es jetzt hin, dass das Skript ausgeführt wird, bevor das firewall-Log gelöscht wird? Und wie kann ich das Ausführen später wieder deaktivieren? (Dazu reichen meine Linux-Kenntnisse leider noch nicht aus...)
Nimm folgendes Skript: (Achtung: ALLES _zwischen_ ### Skriptanfang und ### Skriptende (ohne die beiden ;-)) also von #!/binsh bis rc_exit gehört da hinein, auch wenn manches wie Kommentar ausschaut!! ### Skriptanfang #! /bin/sh ### BEGIN INIT INFO # Provides: Backup Firewall log # Required-Start: $ALL # Should-Start: # Required-Stop: $ALL # Should-Stop: # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: Backup firewall log # Description: Start FOO to allow XY and provide YZ ### END INIT INFO . /etc/rc.status # Reset status of this service rc_reset case "$1" in start) echo -n "Dummy start backup firewall log - do nothing ;-)" rc_status -v ;; stop) echo -n "Backup firewall log" cp /var/log/firewall /root/firewall rc_status -v ;; *) echo "Usage: $0 {start|stop}" exit 1 ;; esac rc_exit ### Skriptende Und kopiere es statt Deines Skriptes in /etc/init.d, zum Beispiel als "fireback", damit's nicht so lang ist ;-). Danach machst Du ein "insserv /etc/init.d/fireback" und startest es der Ordnung halber einmal mit "/etc/init.d/fireback start". Beim starten wird es nichts tun, ausser den eigenen Status setzen. Aber beim herunterfahren sollte es dann zuallererst (so hoffe ich) Dein Log kopieren. Kontrolliere vorher sicherheitshalber, ob in /etc/init.d/rcX.d, wobei X Dein Runlevel - ich nehm mal an "3" ist - ob durch inssserv entsprechende Symlinks mit SXXfireback und KXXfireback erstellt wurden. Durch $ALL in der INIT INFO sollte gewährleistet sein, dass die höchstmögliche Start- und die niedrigstmögliche Killfolge vergeben wurden. Bin mal gespannt, ob es funkioniert, denn ich verstehe immer noch nicht ganz, wo das Firewall-Log hinkommt. Nun gut und dann muss es auch noch verwertbare Informationen bringen ...
Also die Maschine ist ein VPS und ist bei meinem ISP gehostet. Das Rettungssystem funktioniert folgendermaßen: Das eigentliche System wird heruntergefahren und anstelle dessen ein Standard-Suse-9.1 gebootet. In diesem System sind dann die Dateien des eigentlichen Systems unter /repair gemountet. Entsprechend habe ich also z.B. die Datei 'backup_firewall_log' im Rettungssystem unter /repair/etc/init.d angelegt. Starten und Stoppen kann ich das ganze über ein Webinterface (Virtuozzo).
Aaah jetzt ist alles klar .... HTH Regards, Markus
Erstmal herzlichen Dank für die Mühe!! Markus Heidinger schrieb:
Nimm folgendes Skript: [...] Und kopiere es statt Deines Skriptes in /etc/init.d, zum Beispiel als "fireback", damit's nicht so lang ist ;-).
Ok habe ich, und "iptables -L > /root/fwrules" habe ich im Stop-Block ergänzt.
Danach machst Du ein "insserv /etc/init.d/fireback" und startest es der Ordnung halber einmal mit "/etc/init.d/fireback start". Beim starten wird es nichts tun, ausser den eigenen Status setzen. Aber beim herunterfahren sollte es dann zuallererst (so hoffe ich) Dein Log kopieren.
insserv funktioniert, das Script ebenfalls.
Kontrolliere vorher sicherheitshalber, ob in /etc/init.d/rcX.d, wobei X Dein Runlevel - ich nehm mal an "3" ist - ob durch inssserv entsprechende Symlinks mit SXXfireback und KXXfireback erstellt wurden. Durch $ALL in der INIT INFO sollte gewährleistet sein, dass die höchstmögliche Start- und die niedrigstmögliche Killfolge vergeben wurden.
Runlevel ist 3. insserv legt Symlinks an. Allerdings hatte ich nach Aktivierung der Firewall und anschließendem Reboot ins Rettungssystem gar keine neuen Dateien unter /repair/root. 'man insserv' sagt, dass 'Required-Stop' unter SuSE nicht beachtet wird. Außerdem kann es m.E. schon deswegen nicht funktionieren, weil beim Verlassen des Runlevel 3 ja das Script ausgeführt werden soll, unter 'Default-Stop' steht jedoch nur '0 1 2 6'. Ich habe also mit 'insserv -r fireback' (im "normalen" System) die ganzen Symlinks wieder entfernt und anschließend im Rettungssystem von Hand folgendes: cd /repair/etc/init.d/rc3.d mv K01SuSEfirewall2 K02SuSEfirewall2 ln -s ../fireback ./K01fireback (K02... war noch nicht vergeben.)
Bin mal gespannt, ob es funkioniert, denn ich verstehe immer noch nicht ganz, wo das Firewall-Log hinkommt. Nun gut und dann muss es auch noch verwertbare Informationen bringen ...
Tja, was dabei rausgekommen ist... Eine Datei 'firewall' gibt's dann im Root-Verzeichnis immernoch nicht. Das Script funktioniert aber, ich hatte zusätzlich noch ein 'cp /var/log/warn /root/warn' eingefügt, 'warn' ist nun im Root-Verzeichnis vorhanden. Und auch eine Datei namens 'fwrules' ist da, mit folgendem Inhalt (das "> " vor jeder Zeile habe ich eingefügt, damit mein Mailprogramm die Zeilen nicht umbricht):
ACCEPT all -- anywhere anywhere DROP all -- anywhere 255.255.255.255 DROP all -- anywhere 0.0.0.0 input_ext all -- anywhere anywhere DROP all -- anywhere anywhere
Chain FORWARD (policy DROP) target prot opt source destination TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp time-exceeded ACCEPT icmp -- anywhere anywhere icmp port-unreachable ACCEPT icmp -- anywhere anywhere icmp fragmentation-needed ACCEPT icmp -- anywhere anywhere icmp network-prohibited ACCEPT icmp -- anywhere anywhere icmp host-prohibited ACCEPT icmp -- anywhere anywhere icmp communication-prohibited DROP icmp -- anywhere anywhere icmp destination-unreachable
Chain forward_dmz (0 references) target prot opt source destination
Chain forward_ext (0 references) target prot opt source destination
Chain forward_int (0 references) target prot opt source destination
Chain input_dmz (0 references) target prot opt source destination ACCEPT icmp -- anywhere anywhere icmp echo-request DROP icmp -- anywhere anywhere reject_func tcp -- anywhere anywhere tcp dpt:ident flags:SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN DROP all -- anywhere anywhere
Chain input_ext (1 references) target prot opt source destination ACCEPT icmp -- anywhere anywhere icmp source-quench ACCEPT icmp -- anywhere anywhere icmp echo-request DROP icmp -- anywhere anywhere reject_func tcp -- anywhere anywhere tcp dpt:ident flags:SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere tcp dpt:smtp flags:SYN,RST,ACK/SYN DROP all -- anywhere anywhere
Chain input_int (0 references) target prot opt source destination ACCEPT icmp -- anywhere anywhere icmp echo-request DROP icmp -- anywhere anywhere reject_func tcp -- anywhere anywhere tcp dpt:ident flags:SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN DROP all -- anywhere anywhere
Besonders schlau werde ich daraus nicht, aber eine Freigabe von 'ssh' bzw. Port 22 sehe ich auch nicht. Hat jemand noch weitere Ideen? Ich bin ziemlich ratlos... Viele Grüße, Stefan
Stefan Kleeschulte wrote at Thursday, September 01, 2005 12:11 AM
Tja, was dabei rausgekommen ist... Eine Datei 'firewall' gibt's dann im Root-Verzeichnis immernoch nicht. Das Script funktioniert aber, ich hatte zusätzlich noch ein 'cp /var/log/warn /root/warn' eingefügt, 'warn' ist nun im Root-Verzeichnis vorhanden. Und auch eine Datei namens 'fwrules' ist da, mit folgendem Inhalt (das "> " vor jeder Zeile habe ich eingefügt, damit mein Mailprogramm die Zeilen nicht umbricht):
Naja da haben wir ja schon was ...
ACCEPT all -- anywhere anywhere
Das kann nicht ganz der Anfang sein ... M.E. ist das die "Chain INPUT" ... Hast Du evtl am Anfang ein oder zwei Zeilen beim kopieren verloren? Die ersten vier Zeilen bei mir sind: Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
[...]
Chain input_ext (1 references)
So bis hierher kommen wir jedenfalls, wenn das oben die Input Chain ist ...
target prot opt source destination DROP tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN [...]
Nun ja, das da oben schaut mir komisch aus, hier werden ssh Pakete explizit geDROPped statt durchgelassen. Kann es sein, dass Du ssh in verbotenen und nicht in _erlaubten_ Diensten eingetragen hast? Ansonsten macht vielleicht Dein yast was falsch. Hier sollte stehen: ACCEPT tcp -- anywhere anywhere tcp dpt:ssh Aber ich hab eine Idee, noch dazu mit einem Sicherheitplus. Wo auch immer Du ssh erlaubt hast, dort nimmst Du es wieder weg. Stattdessen setzt Du den Parameter 25.) (wahrscheinlich), auf jeden Fall FW_CUSTOMRULES="" auf "/etc/sysconfig/SuSEfirewall2-custom". In ebendiesem Skript fügst Du folgende drei Zeilen in den Abschnitt fw_custom_after_antispoofing() { iptables -A input_ext -p tcp --dport 22 -m recent --update --seconds 300 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force " iptables -A input_ext -p tcp --dport 22 -m recent --update --seconds 300 --hitcount 4 --rttl --name SSH -j DROP iptables -A input_ext -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT true } ein, wie oben gezeigt. Das Mailprogramm wird das umbrechen, jede Zeile beginnt mit "iptables". Hier hast Du gleich einen Schutz gegen ssh-brute-Force attacken dabei: der 5. Verbindungsversuch von derselben IP wird geblockt, der nächste Versuch ist erst nach 5 Minuten Pause (von diesem Host) möglich. Das funktioniert so bei mir einwandfrei. Was an der anderen Konfig nicht stimmt, sieht man zwar, aber ich weiss nicht wie es dazu kommt.- Regards, Markus
ACCEPT all -- anywhere anywhere
Das kann nicht ganz der Anfang sein ... M.E. ist das die "Chain INPUT" ... Hast Du evtl am Anfang ein oder zwei Zeilen beim kopieren verloren?
In der Tat habe ich die folgenden beiden Zeilen am Anfang vergessen: Chain INPUT (policy DROP) target prot opt source destination
Aber ich hab eine Idee, noch dazu mit einem Sicherheitplus. Wo auch immer Du ssh erlaubt hast, dort nimmst Du es wieder weg. Stattdessen setzt Du den Parameter 25.) (wahrscheinlich), auf jeden Fall FW_CUSTOMRULES="" auf "/etc/sysconfig/SuSEfirewall2-custom". [...]
Prima, danke. Leider hat auch das keine Abhilfe geschaffen.
Das funktioniert so bei mir einwandfrei. Was an der anderen Konfig nicht stimmt, sieht man zwar, aber ich weiss nicht wie es dazu kommt.-
Mir ist eben noch etwas anderes aufgefallen. Nachdem ich die Konfigurationsdateien wie von dir beschrieben geändert hatte, habe ich die Firewall manuell gestartet (sonst immer per Yast). Kurz bevor die Verbindung abgebrochen ist meldete die Firewall noch folgendes:
# /sbin/rcSuSEfirewall2 start Starting Firewall Initialization (phase 2 of 3) which: no modinfo in (/sbin:/bin:/usr/sbin:/usr/bin) It's not possible to reject outgoing packets. Expect Timeouts. iptables v1.2.9: 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 v1.2.9: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. (Zitiert um Zeilenumbrüch zu vermeiden.)
Es sieht so aus, als könnte hier der Fehler liegen, oder? Viele Grüße, Stefan
Stefan Kleeschulte wrote at Thursday, September 01, 2005 3:11 PM
Mir ist eben noch etwas anderes aufgefallen. Nachdem ich die Konfigurationsdateien wie von dir beschrieben geändert hatte, habe ich die Firewall manuell gestartet (sonst immer per Yast). Kurz bevor die Verbindung abgebrochen ist meldete die Firewall noch folgendes:
# /sbin/rcSuSEfirewall2 start Starting Firewall Initialization (phase 2 of 3) which: no modinfo in (/sbin:/bin:/usr/sbin:/usr/bin) It's not possible to reject outgoing packets. Expect Timeouts. iptables v1.2.9: 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 v1.2.9: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. (Zitiert um Zeilenumbrüch zu vermeiden.)
Das schaut schon so aus, als ob da irgendwas fehlen würde oder so ... Ist Deine Installation auf dem neusten Stand? Wenn nein, dann würde ich mal schauen, ob es für die Pakete "iptables" und "SuSEfirewall2" Updates gibt (per YOU). Wenn nein, könnte es nicht schaden, diese über yast trotzdem neu zu installieren, vielleicht ist ja was kaputt. Könnten natürlich auch Kernelmodule sein. Denn jedenfalls hört es sich an, als ob Module fehlen würden ... Was gibt "lsmod | grep 'ip'" aus? Bei mir kommt das heraus: ipt_ULOG 7684 0 ipt_recent 10892 3 ipt_TCPMSS 4480 1 ipt_MASQUERADE 3328 2 ipt_LOG 6912 20 ipt_limit 2432 19 ipt_pkttype 1792 1 ipt_state 2048 51 ip6t_REJECT 6784 3 ipt_REJECT 6656 3 iptable_mangle 2816 0 iptable_filter 2944 1 ip6table_mangle 2432 0 ip_nat_ftp 3072 0 iptable_nat 22236 3 ipt_MASQUERADE,ip_nat_ftp ip_conntrack_ftp 72592 1 ip_nat_ftp ip_conntrack 42168 5 ipt_MASQUERADE,ipt_state,ip_nat_ftp,iptable_nat, ip_conntrack_ftp ip_tables 20352 12 ipt_ULOG,ipt_recent,ipt_TCPMSS,ipt_MASQUERADE,ipt_LOG,ipt_limit,ipt_pkttype, ipt_state,ipt_REJECT,iptable_mangle,iptable_filter,iptable_nat ip6table_filter 2816 1 ip6_tables 18304 3 ip6t_REJECT,ip6table_mangle,ip6table_filter ipv6 236672 25 ip6t_REJECT Naja ... Vielleicht kommst Du ja jetzt mal wieder einen Schritt weiter ... Grüße, Markus
Markus Heidinger schrieb:
[...] Das schaut schon so aus, als ob da irgendwas fehlen würde oder so ... Ist Deine Installation auf dem neusten Stand?
Ja, Suse 9.1 mit allen Updates.
Wenn nein, dann würde ich mal schauen, ob es für die Pakete "iptables" und "SuSEfirewall2" Updates gibt (per YOU). Wenn nein, könnte es nicht schaden, diese über yast trotzdem neu zu installieren, vielleicht ist ja was kaputt.
Ok, das hab' ich gemacht.
Könnten natürlich auch Kernelmodule sein. Denn jedenfalls hört es sich an, als ob Module fehlen würden ... Was gibt "lsmod | grep 'ip'" aus?
ip_vznetstat 2676 0 [vzmon] ipt_REDIRECT2 2160 1 vznetstat_core 10304 0 [vzmon ip_vznetstat vznet] ip_conntrack_ftp 5568 5 (autoclean) ip_nat_ftp 4320 1 iptable_nat 22828 14 [ip_nat_ftp] ipt_helper 1792 1 ipt_state 1664 7 ipt_conntrack 2240 1 ip_conntrack 30092 14 [ip_conntrack_ftp ip_nat_ftp iptable_nat ipt_helper ipt_state ipt_conntrack] ipt_length 1952 1 ipt_LOG 4960 1 ipt_ttl 2016 1 ipt_tcpmss 2496 1 ipt_TCPMSS 3840 1 ipt_REJECT 4384 4 ipt_TOS 2144 1 ipt_tos 1888 1 ipt_multiport 2272 1 ipt_limit 2592 1 iptable_mangle 3584 1 iptable_filter 3520 2 ip_tables 17856 543 [iptable_nat ipt_helper ipt_state ipt_conntrack ipt_length ipt_LOG ipt_ttl ipt_tcpmss ipt_TCPMSS ipt_REJECT ipt_TOS ipt_tos ipt_multiport ipt_limit iptable_mangle iptable_filter]
Kann man da etwas erkennen? Übrigens sieht die Ausgabe nach dem "manuellen" Start der Firewall jetzt wieder etwas anders aus:
# /sbin/rcSuSEfirewall2 start Starting Firewall Initialization (phase 2 of 3) modprobe: Can't open dependencies file /lib/modules/2.4.20-021stab028.16.777-smp/modules.dep (No such file or directory) iptables v1.2.9: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. modprobe: Can't open dependencies file /lib/modules/2.4.20-021stab028.16.777-smp/modules.dep (No such file or directory) iptables v1.2.9: 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
Ich trau' mich ja schon kaum noch zu fragen :-) - noch irgendwelche Ideen? Viele Grüße, Stefan
Stefan Kleeschulte wrote at Thursday, September 01, 2005 4:48 PM
Könnten natürlich auch Kernelmodule sein. Denn jedenfalls hört es sich an, als ob Module fehlen würden ... Was gibt "lsmod | grep 'ip'" aus?
ip_vznetstat 2676 0 [vzmon] ipt_REDIRECT2 2160 1 vznetstat_core 10304 0 [vzmon ip_vznetstat vznet] ip_conntrack_ftp 5568 5 (autoclean) ip_nat_ftp 4320 1 iptable_nat 22828 14 [ip_nat_ftp] ipt_helper 1792 1 ipt_state 1664 7 ipt_conntrack 2240 1 ip_conntrack 30092 14 [ip_conntrack_ftp ip_nat_ftp iptable_nat ipt_helper ipt_state ipt_conntrack] ipt_length 1952 1 ipt_LOG 4960 1 ipt_ttl 2016 1 ipt_tcpmss 2496 1 ipt_TCPMSS 3840 1 ipt_REJECT 4384 4 ipt_TOS 2144 1 ipt_tos 1888 1 ipt_multiport 2272 1 ipt_limit 2592 1 iptable_mangle 3584 1 iptable_filter 3520 2 ip_tables 17856 543 [iptable_nat ipt_helper ipt_state ipt_conntrack ipt_length ipt_LOG ipt_ttl ipt_tcpmss ipt_TCPMSS ipt_REJECT ipt_TOS ipt_tos ipt_multiport ipt_limit iptable_mangle iptable_filter]
Kann man da etwas erkennen?
Naja wenig ... Aber optisch schaut es nicht so schlecht aus. Was mir nicht gefällt ist das hier:
Starting Firewall Initialization (phase 2 of 3) modprobe: Can't open dependencies file /lib/modules/2.4.20-021stab028.16.777-smp/modules.dep (No such file or directory) iptables v1.2.9: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. [...] 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
Ich trau' mich ja schon kaum noch zu fragen :-) - noch irgendwelche Ideen?
Sag mal, ist auch Dein Kernel up-2-date? M.E. Sollte bei einer 9.1 auch mit SMP schon ein 2.6er Kernel laufen ... Hast Du mal ein Kernelupdate gemacht, bei dem etwas schief gagangen sein könnte? Gibt es /lib/modules/2.4.20-021stab028.16.777-smp/modules.dep wirklich nicht und ist das die Kernelversion, die "uname -r" ausgibt? Viel Glück ;-) Markus
Markus Heidinger schrieb:
Sag mal, ist auch Dein Kernel up-2-date? M.E. Sollte bei einer 9.1 auch mit SMP schon ein 2.6er Kernel laufen ... Hast Du mal ein Kernelupdate gemacht, bei dem etwas schief gagangen sein könnte?
Ich habe einfach alle Yast-Updates eingespielt, bis auf die diversen Firmware-Updates und den Nvidia-Treiber. Ist da ein Kernel-Update dabei? Sonst habe ich nichts am Kernel gemacht.
Gibt es /lib/modules/2.4.20-021stab028.16.777-smp/modules.dep wirklich nicht und ist das die Kernelversion, die "uname -r" ausgibt?
'uname -r' gibt '2.4.20-021stab028.16.777-smp' aus. Was hat denn dieses 'smp' zu bedeuten? Unter /lib/modules gibt es nur einen Ordner 'scripts', in dem wiederum ein leerer Ordner namens 'nvidia' und eine Datei 'nvidia.sh' enthalten sind. Sonst nix. Ich habe auch noch ein Problem mit dem sshd. Er startet beim Booten nicht, obwohl er eigentlich müsste (Links in rc3.d und rc5.d sind korrekt). Ich muss ihn nach dem Booten immer "von Hand" über eine externe Steuerungskonsole (Webinterface "Virtuozzo Power Panel") starten. In /var/log/messages und warn sind aber keine Fehlermeldungen vom sshd zu finden, dafür allerdings die Folgenden Meldungen vom Kernel:
Sep 1 19:05:20 km-research kernel: Cannot find map file. Sep 1 19:05:20 km-research kernel: Error opening /dev/kmem Sep 1 19:05:20 km-research kernel: Error adding kernel module table entry. Sep 1 19:05:20 km-research kernel: Cannot build symbol table - disabling symbol lookups
Noch Ideen? Vielleicht sollte ich bezüglich dieser Probleme einen neuen Thread aufmachen, sonst wird das hier unübersichtlich... Viele Grüße, Stefan
Stefan Kleeschulte wrote at Thursday, September 01, 2005 7:39 PM
Ich habe einfach alle Yast-Updates eingespielt, bis auf die diversen Firmware-Updates und den Nvidia-Treiber. Ist da ein Kernel-Update dabei? Sonst habe ich nichts am Kernel gemacht.
Gibt es /lib/modules/2.4.20-021stab028.16.777-smp/modules.dep wirklich nicht und ist das die Kernelversion, die "uname -r" ausgibt?
'uname -r' gibt '2.4.20-021stab028.16.777-smp' aus. Was hat denn dieses 'smp' zu bedeuten?
Unter /lib/modules gibt es nur einen Ordner 'scripts', in dem wiederum ein leerer Ordner namens 'nvidia' und eine Datei 'nvidia.sh' enthalten sind. Sonst nix.
Puh ... Da bin ich langsam etwas überfragt ... Den Modulordner sollte es eigentlich schon geben.
Ich habe auch noch ein Problem mit dem sshd. Er startet beim Booten nicht, obwohl er eigentlich müsste (Links in rc3.d und rc5.d sind korrekt). Ich muss ihn nach dem Booten immer "von Hand" über eine externe Steuerungskonsole (Webinterface "Virtuozzo Power Panel") starten. In /var/log/messages und warn sind aber keine Fehlermeldungen
Nun ja, das sehen wir uns denk ich später an, wenn erst mal die Firewall läuft.
vom sshd zu finden, dafür allerdings die Folgenden Meldungen vom Kernel:
Sep 1 19:05:20 km-research kernel: Cannot find map file. Sep 1 19:05:20 km-research kernel: Error opening /dev/kmem Sep 1 19:05:20 km-research kernel: Error adding kernel module table entry. Sep 1 19:05:20 km-research kernel: Cannot build symbol table - disabling symbol lookups
Das deutet auch genau in die Richtung dass mit /lib/modules was nicht stimmt ...
Noch Ideen? Vielleicht sollte ich bezüglich dieser Probleme einen neuen Thread aufmachen, sonst wird das hier unübersichtlich...
Mal abwarten, vielleciht nimmt sich ja sonst noch jemand hier des Problems an und vielleicht bin ich ja total auf dem falschen Dampfer .... (Siehe auch PM) ... Grüße, Markus
Markus Heidinger wrote:
Stefan Kleeschulte wrote at Thursday, September 01, 2005 7:39 PM
Ich habe einfach alle Yast-Updates eingespielt, bis auf die diversen Firmware-Updates und den Nvidia-Treiber. Ist da ein Kernel-Update dabei? Sonst habe ich nichts am Kernel gemacht.
Gibt es
/lib/modules/2.4.20-021stab028.16.777-smp/modules.dep wirklich nicht
und ist das die Kernelversion, die "uname -r" ausgibt?
'uname -r' gibt '2.4.20-021stab028.16.777-smp' aus. Was hat denn dieses 'smp' zu bedeuten?
Wie hast du es eigentlich geschafft diesen alten 2.4er Kernel unter Suse 9.1 zu erhalten? Suse 9.1 ist die erste reine 2.6 Kernel Ausgabe gewesen. Oder das vielleicht doch noch die Suse 9.0? Die hatte als letzte die Option, den alten Kernel 2.4 zu installieren. Das SMP im Kernel steht für die Multiprozessor-Fähigkeit des Kernels.Das wird auch verwendet, um Hyperthreading als zwei Prozessoren zu nutzen. Sandy
Sandy Drobic schrieb:
Wie hast du es eigentlich geschafft diesen alten 2.4er Kernel unter Suse 9.1 zu erhalten? Suse 9.1 ist die erste reine 2.6 Kernel Ausgabe gewesen.
Oder das vielleicht doch noch die Suse 9.0? Die hatte als letzte die Option, den alten Kernel 2.4 zu installieren.
Das ganze ist ein VPS (Virtual Private Server), bei dem ich den Kernel eigentlich gar nicht verändern kann. Der ist vom ISP vorgegeben... Die verkaufen das jedenfalls als Suse 9.1, in Yast wird das auch angezeigt. Viele Grüße, Stefan
Hallo Stefan, hallo Leute, Am Donnerstag, 1. September 2005 16:47 schrieb Stefan Kleeschulte:
modprobe: Can't open dependencies file /lib/modules/2.4.20-021stab028.16.777-smp/modules.dep (No such file or directory) [...] Ich trau' mich ja schon kaum noch zu fragen :-) - noch irgendwelche Ideen?
Kann es sein, dass Du per YOU ein Kernelupdate installiert hast und hast anschließend den Reboot "vergessen"? Hint: vergleiche die Ausgabe von uname -a mit dem gewünschten Modulverzeichnis. Außerdem kannst Du die Ausgabe von rpm -qa --last | grep kernel mit der von uptime vergleichen ;-) Da es sich beim betroffenen Rechner ja um einen "Rootserver" zu handeln scheint, kannst Du auch mal beim zugehörigen Support nachfragen - evtl. gibt es einen speziellen Kernel [1]. Gruß Christian Boltz [1] 1&1 war bei seinen SuSE 8.1-Servern so schlau und hat nur den Kernel "überbügelt", das SuSE-Kernel-RPM aber nicht aus der RPM-DB ausgetragen. Nach dem ersten Kernel-Update per YOU war der Server dann nach dem Reboot nicht mehr erreichbar :-/ Die SuSE 9.1-Server laufen zwar auch mit einem speziellen Kernel, aber immerhin YOU-sicher ;-) -- Ab heute (bis 5.9.2005): Weinfest in Insheim Bei der Landjugend: Liquid, AH-Band und Deafen Goblins Mehr Infos: www.Landjugend-Insheim.de
Hallo Markus, hallo Leute, Am Mittwoch, 31. August 2005 19:32 schrieb Markus Heidinger: [...]
Ich hab mich bei Versuchen, Firewalls von extern zu konfigurieren, auch schon regeäßig selber ausgesperrt :-(
Das ist ein klassischer Fall für den at-Daemon ;-) echo '/sbin/rcSuSEfirewall2 stop' | at 'now +5 minutes' (ungetestet, müsste aber funktionieren) Gruß Christian Boltz -- 2.-5.9.2005: Weinfest in Insheim Bei der Landjugend: Liquid, AH-Band und Deafen Goblins Mehr Infos: www.Landjugend-Insheim.de
Christian Boltz schrieb:
[...] Das ist ein klassischer Fall für den at-Daemon ;-)
echo '/sbin/rcSuSEfirewall2 stop' | at 'now +5 minutes' (ungetestet, müsste aber funktionieren)
Ui toll!! Das wird mir eine Menge Zeit ersparen, denn es dauert immer ewig zwischen Running- und Rescue-System umzubooten. Und 'now +2 minutes' reicht mir auch... Danke! Viele Grüße, Stefan
Christian Boltz wrote at Thursday, September 01, 2005 12:18 AM
Ich hab mich bei Versuchen, Firewalls von extern zu konfigurieren, auch schon regeäßig selber ausgesperrt :-(
Das ist ein klassischer Fall für den at-Daemon ;-)
echo '/sbin/rcSuSEfirewall2 stop' | at 'now +5 minutes' (ungetestet, müsste aber funktionieren)
Wow ... das ist zum Merken ;-) ... Immer wieder interessant, wie weit man mit Verständnis _und_ Kreativität bzw. Ideenreichtum bei Linux kommt ... Regards, Markus
participants (4)
-
Christian Boltz -
Markus Heidinger -
Sandy Drobic -
Stefan Kleeschulte