Wieso triggert SFW2-OUT-ERROR immer wieder?
Hallo Ich habe hier nen Server am Netz wo ich immer wieder etwas merkwürdige logeinträge finde aus denen ich nicht ganz schlau werde. Eigentlich ist das setup denkbar einfach: out soll alles erlaubt sein, in per whitelist nur was wichtig ist. Aufgesetzt ist das ganze unter Suse 10.0 mit SuSEfirewall2 Doch finde ich immer wieder solche Meldungen: kernel: SFW2-OUT-ERROR IN= OUT=eth0 SRC=x.x.x.x DST=y.y.y.y LEN=88 TOS=0x00 PREC=0x00 TTL=64 ID=60704 DF PROTO=TCP SPT=25 DPT=3446 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 kernel: SFW2-OUT-ERROR IN= OUT=eth0 SRC=x.x.x.x DST=y.y.y.y LEN=88 TOS=0x00 PREC=0x00 TTL=64 ID=60706 DF PROTO=TCP SPT=25 DPT=3446 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 kernel: SFW2-OUT-ERROR IN= OUT=eth0 SRC=x.x.x.x DST=y.y.y.y LEN=140 TOS=0x00 PREC=0x00 TTL=64 ID=51260 DF PROTO=TCP SPT=80 DPT=10987 WINDOW=2252 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A0FFA1B6263FEB7B0) Dies scheint immer nur mit gültigen connections aufzutreten wie hier mit smtp und http und in allen beispielen die ich bisher sah war das FIN oder RST Flag gesetzt Meine OUTPUT chain ist: (iptables -L -v) Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- any lo anywhere anywhere 518 486K ACCEPT all -- any any anywhere anywhere state NEW,RELATED,ESTABLISHED 0 0 LOG all -- any any anywhere anywhere LOG level warning tcp-options ip-options prefix `SFW2-OUT-ERROR ' Kann es also sein dass solche letzten Pakete einer Connection keinem solchen State entsprechen? Was könnte ich ändern? Zusatzfrage: Ist im SuSEfirewall eigentlich standardmässig ein spoofingschutz eingebaut welcher private IPs dropt die von extern kommen? Oder wenn nein, wie kann ich das aktivieren? Fand leider nichts dazu. Vielen Dank Matti
Hallo Matthias, hallo Leute, Am Dienstag, 6. Dezember 2005 21:23 schrieb Matthias Keller: [...]
Zusatzfrage: Ist im SuSEfirewall eigentlich standardmässig ein spoofingschutz eingebaut welcher private IPs dropt die von extern kommen? Oder wenn nein, wie kann ich das aktivieren? Fand leider nichts dazu.
Ist AFAIK eingebaut - gib einfach mal einen Dienst (z. B. ssh, http) frei und versuche, mit Deiner _externen_ IP (von intern) drauf zuzugreifen ;-) Zu Deiner Hauptfrage kann ich allerdings nichts beitragen. Gruß Christian Boltz -- [~/.gtkrc] Brauche ich für Mozilla Firebird, sonst macht der "Faustgroße Killerschriften greifen an!" in Formularen. [Ratti in suse-linux]
Christian Boltz wrote:
Hallo Matthias, hallo Leute,
Am Dienstag, 6. Dezember 2005 21:23 schrieb Matthias Keller: [...]
Zusatzfrage: Ist im SuSEfirewall eigentlich standardmässig ein spoofingschutz eingebaut welcher private IPs dropt die von extern kommen? Oder wenn nein, wie kann ich das aktivieren? Fand leider nichts dazu.
Ist AFAIK eingebaut - gib einfach mal einen Dienst (z. B. ssh, http) frei und versuche, mit Deiner _externen_ IP (von intern) drauf zuzugreifen ;-)
Kann ich so schwer testen da hinter dem server kein internes netz ist Grüsse Matti
Am Dienstag, 6. Dezember 2005 21:23 schrieb Matthias Keller:
kernel: SFW2-OUT-ERROR (...) ACK PSH FIN (...).
Dies scheint immer nur mit gültigen connections aufzutreten wie hier mit smtp und http und in allen beispielen die ich bisher sah war das FIN oder RST Flag gesetzt
Kann ich bestätigen: Diese Meldungen fallen mir auch immer wieder auf. Dein Rechner sendet zum Verbindungsaufbau ein ACK+FIN oder ein RST. Der entsprechende Server müßte darauf mit einem ACK antworten. Tut er das nicht wird IIRC das ACK+FIN bzw. RST nach einer gewissen Zeit erneut gesendet. Jetzt kommt das Connectiontracking mit seinen Timeouts ins Spiel: /usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Die ganzen States des Verbindungsabbaus haben einen Timeout von höchstens zwei Minuten. Meine Erklärung ist also, daß der Server nicht mit einem ACK antwortet und das erneute Senden von ACK+FIN bzw. RST erst nach einem Timeout des Connectiontrackings stattfindet. Mit diesen TCP-Grundlagen habe ich mich allerdings vor zweieinhalb Jahren das letzte Mal intensiv beschäftigt, es kann also gut sein, daß ich das nicht mehr so ganz korrekt in Erinnerung habe ...
(...). Zusatzfrage: Ist im SuSEfirewall eigentlich standardmässig ein spoofingschutz eingebaut welcher private IPs dropt die von extern kommen? Oder wenn nein, wie kann ich das aktivieren? Fand leider nichts dazu.
So auf Anhieb: Punkt 17.) und 17a.) in /etc/sysconfig/SuSEfirewall2 Gruß Jan -- The most useful program will be continually improved until it is useless.
Jan Ritzerfeld wrote:
Am Dienstag, 6. Dezember 2005 21:23 schrieb Matthias Keller:
kernel: SFW2-OUT-ERROR (...) ACK PSH FIN (...).
Dies scheint immer nur mit gültigen connections aufzutreten wie hier mit smtp und http und in allen beispielen die ich bisher sah war das FIN oder RST Flag gesetzt
Kann ich bestätigen: Diese Meldungen fallen mir auch immer wieder auf.
Dein Rechner sendet zum Verbindungsaufbau ein ACK+FIN oder ein RST. Der entsprechende Server müßte darauf mit einem ACK antworten. Tut er das nicht wird IIRC das ACK+FIN bzw. RST nach einer gewissen Zeit erneut gesendet. Jetzt kommt das Connectiontracking mit seinen Timeouts ins Spiel: /usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Die ganzen States des Verbindungsabbaus haben einen Timeout von höchstens zwei Minuten. Meine Erklärung ist also, daß der Server nicht mit einem ACK antwortet und das erneute Senden von ACK+FIN bzw. RST erst nach einem Timeout des Connectiontrackings stattfindet. Mit diesen TCP-Grundlagen habe ich mich allerdings vor zweieinhalb Jahren das letzte Mal intensiv beschäftigt, es kann also gut sein, daß ich das nicht mehr so ganz korrekt in Erinnerung habe ...
Hm ja ich glaube jetzt kommen wir in die richtige Richtung. ein FIN/RST wird jedoch kaum für den AUFBAU benötigt, sondern vielmehr für den ABBAU Ich habe alle apache logs mal nach dem letzten Eintrag durchsucht und stellte fest dass die Firewall rule ca 8.5 minuten nach dem letzten abruf auftrat. Ich schätze mal dass dies etwas mit dem keep-alive zu tun hat - bei moderneren Browsern wird ja nicht für jeden einzelnen request eine neue verbindung aufgebaut sondern verbindungen aufrechterhalten und für mehrere Requests gebraucht. Der Keep-alive hat zwar einen timeout von 15 sekunden aber irgendeine verbindung scheint das zu sein die offengehalten wird. Es wäre also möglich dass der apache schliesslich nach 8.5 minuten beschloss die verbindung zu kappen, der firewall jedoch davon nichts mehr wissen wollte... Denn FIN und RST werden nunmal für das 'weiche' und 'harte' trennen von tcp-verbindungen benutzt.... Daher nun meine Folgefrage: Eigentlich hätte ich gerne dass diese Pakete durchgelassen werden -- also eben genau die policy: nach aussen alles allow -- ob das wohl geht?? in den iptables sehe ich jedenfalls nix mehr, das scheint irgendwo intern zu laufen das conntrac... ? Jetzt erlaubt er ja nur: state NEW,RELATED,ESTABLISHED Eigentlich möchte ich für solche - meiner meinung nach simplen - sachen ohne custom rules auskommen....
(...). Zusatzfrage: Ist im SuSEfirewall eigentlich standardmässig ein spoofingschutz eingebaut welcher private IPs dropt die von extern kommen? Oder wenn nein, wie kann ich das aktivieren? Fand leider nichts dazu.
So auf Anhieb: Punkt 17.) und 17a.) in /etc/sysconfig/SuSEfirewall2
Habe zwar keinen 17a bei mir aber ich nehme an du meinst FW_KERNEL_SECURITY welches ich auf "yes" habe... Sehe aber anhand der Beschreibung nicht viel über private IPs... ? Grüsse Matti
Hallo, Am Thu, 08 Dec 2005, Matthias Keller schrieb: [..]
Daher nun meine Folgefrage: Eigentlich hätte ich gerne dass diese Pakete durchgelassen werden -- also eben genau die policy: nach aussen alles allow -- ob das wohl geht?? in den iptables sehe ich jedenfalls nix mehr, das scheint irgendwo intern zu laufen das conntrac... ? Jetzt erlaubt er ja nur: state NEW,RELATED,ESTABLISHED Eigentlich möchte ich für solche - meiner meinung nach simplen - sachen ohne custom rules auskommen....
Aus den Sourcen net/ipv4/netfilter/ unsigned long ip_ct_tcp_timeout_syn_sent = 2 MINS; unsigned long ip_ct_tcp_timeout_syn_recv = 60 SECS; unsigned long ip_ct_tcp_timeout_established = 5 DAYS; unsigned long ip_ct_tcp_timeout_fin_wait = 2 MINS; unsigned long ip_ct_tcp_timeout_close_wait = 60 SECS; unsigned long ip_ct_tcp_timeout_last_ack = 30 SECS; unsigned long ip_ct_tcp_timeout_time_wait = 2 MINS; unsigned long ip_ct_tcp_timeout_close = 10 SECS; Evtl. kannst du in /sys oder /proc/ was einstellen (s.a. sysctl.conf). Ja, sieht so aus als ob man da mit sysctl an den timeouts drehen kann. Jup, schon mit Kernel-2.4: # sysctl -a | grep conntrack net.ipv4.ip_conntrack_max = 20472 net.ipv4.netfilter.ip_conntrack_generic_timeout = 600 net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30 net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180 net.ipv4.netfilter.ip_conntrack_udp_timeout = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10 net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60 net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120 net.ipv4.netfilter.ip_conntrack_buckets = 2559 net.ipv4.netfilter.ip_conntrack_max = 20472 Siehe auch 'man sysctl' und 'man sysctl.conf'. HTH, -dnh -- [Filialleiter aus den USA] Wir [in FFM] mögen doch bitte den Hausmeister aus- findig machen, er hätte sich 3 Tage nicht gemeldet und die Schreibtischlampe wäre immer noch kaputt. Pech gehabt - die Pappnase hatte dem Hausmeister eine Woche vorher selbst gekündigt und keinen neuen eingestellt. -- B. Mangelsdorff
Am Donnerstag, 8. Dezember 2005 10:04 schrieb Matthias Keller:
Jan Ritzerfeld wrote:
Am Dienstag, 6. Dezember 2005 21:23 schrieb Matthias Keller:
kernel: SFW2-OUT-ERROR (...) ACK PSH FIN (...).
Dies scheint immer nur mit gültigen connections aufzutreten wie hier mit smtp und http und in allen beispielen die ich bisher sah war das FIN oder RST Flag gesetzt
Kann ich bestätigen: Diese Meldungen fallen mir auch immer wieder auf.
Dein Rechner sendet zum Verbindungsaufbau ein ACK+FIN oder ein RST. Der entsprechende Server müßte darauf mit einem ACK antworten. Tut er das nicht wird IIRC das ACK+FIN bzw. RST nach einer gewissen Zeit erneut gesendet. (...).
Hm ja ich glaube jetzt kommen wir in die richtige Richtung. ein FIN/RST wird jedoch kaum für den AUFBAU benötigt, sondern vielmehr für den ABBAU
Ogott, ich hatte tatsächlich Aufbau geschrieben! Ich werd alt ... :-(
Ich habe alle apache logs mal nach dem letzten Eintrag durchsucht und stellte fest dass die Firewall rule ca 8.5 minuten nach dem letzten abruf auftrat. Ich schätze mal dass dies etwas mit dem keep-alive zu tun hat - bei moderneren Browsern wird ja nicht für jeden einzelnen request eine neue verbindung aufgebaut sondern verbindungen aufrechterhalten und für mehrere Requests gebraucht.
Jau.
Der Keep-alive hat zwar einen timeout von 15 sekunden aber irgendeine verbindung scheint das zu sein die offengehalten wird. Es wäre also möglich dass der apache schliesslich nach 8.5 minuten beschloss die verbindung zu kappen, der firewall jedoch davon nichts mehr wissen wollte...
Das kann eine Möglichkeit sein. Allerdings habe ich hier (als Client) auch SFW2-OUT-ERROR für whois, ftp, pop3s, jabber, icq und manchmal auf für irgendwelche anderen highports. Und du auch bei smtp. Bei mir schiebe ich einige, mit meiner obiger Erklärung, auf die 24h-DSL-Trennung im Hardwarerouter.
Denn FIN und RST werden nunmal für das 'weiche' und 'harte' trennen von tcp-verbindungen benutzt....
Genau.
Daher nun meine Folgefrage: Eigentlich hätte ich gerne dass diese Pakete durchgelassen werden -- also eben genau die policy: nach aussen alles allow -- ob das wohl geht??
Das geht sicherlich, du willst halt ohne Connectiontracking auskommen.
in den iptables sehe ich jedenfalls nix mehr, das scheint irgendwo intern zu laufen das conntrac... ?
Tut es, als Kernel-Modul.
Jetzt erlaubt er ja nur: state NEW,RELATED,ESTABLISHED Eigentlich möchte ich für solche - meiner meinung nach simplen - sachen ohne custom rules auskommen....
Das Verbieten von solchen "zusammenhangslosen" Paketen soll vielleicht Mißbrauch durch den Rechner selbst verhindern, z. B. unsinnige Pakete zum unauffälligen Portscannen. Prinzipiell also ein sehr sinnvolle Sache. Daher wirst du wohl ein generelles ACCEPT für OUTPUT in fw_custom_before_denyall() von /etc/sysconfig/scripts/SuSEfirewall2-custom eintragen müssen. fw_custom_before_denyall wird vor drop_all und finish_chains ausgeführt, in finish_chains werden die "zusammenhangslosen" Pakete verworfen.
(...). Zusatzfrage: Ist im SuSEfirewall eigentlich standardmässig ein spoofingschutz eingebaut welcher private IPs dropt die von extern kommen? Oder wenn nein, wie kann ich das aktivieren? Fand leider nichts dazu.
So auf Anhieb: Punkt 17.) und 17a.) in /etc/sysconfig/SuSEfirewall2
Habe zwar keinen 17a bei mir aber ich nehme an du meinst FW_KERNEL_SECURITY welches ich auf "yes" habe... Sehe aber anhand der Beschreibung nicht viel über private IPs... ?
Bei mir in der Config von SL 9.2 wird unter 17a) (FW_ANTISPOOF) erwähnt, daß eben dieser Punkt 17a) nicht notwendig ist, weil rp_filter von Punkt 17 das Antispoofing schon macht, ganz ohne iptables. Ich bin jetzt allerdings zu faul zum Googlen, jedenfalls ist rp_filter recht neu (ab Kernel 2.6.8?). Gruß Jan -- It's easier said than done.
participants (4)
-
Christian Boltz -
David Haller -
Jan Ritzerfeld -
Matthias Keller