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