Ich habe jetzt erstmals eine DSL-Verbindung auf einem Testrechner unter 9.2. Hat sich die Warnsyntax gegenüber 9.1 geändert? Online-Tests meinten, dass die FW dicht ist.
Was bedeutet "SFW2-OUT-ERROR IN"? Auffällig ist auch, dass die einzelnen Portscans von den Onlinetests nicht in den messages zu finden waren. Woran könnte das liegen?
Hier ein kurzer Auszug aus dem Log:
Jan 14 17:55:47 client7 kernel: SFW2-OUT-ERROR IN= OUT=dsl0 SRC=83.64.76.214 DST=216.254.95.40 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=56070 DF PROTO=TCP SPT=1134 DPT=8081 WINDOW=1452 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A001A14CA34FCC6D3) Jan 14 17:56:14 client7 gconfd (ab-6572): Der GConf-Server wird nicht verwendet und daher beendet. Jan 14 17:56:14 client7 gconfd (ab-6572): Beenden Jan 14 17:56:46 client7 kernel: SFW2-OUT-ERROR IN= OUT=dsl0 SRC=83.64.76.214 DST=216.254.95.40 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=56071 DF PROTO=TCP SPT=1134 DPT=8081 WINDOW=1452 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A001AF8CA34FCC6D3) Jan 14 17:58:43 client7 kernel: SFW2-OUT-ERROR IN= OUT=dsl0 SRC=83.64.76.214 DST=216.254.95.40 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=56072 DF PROTO=TCP SPT=1134 DPT=8081 WINDOW=1452 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A001CC0CA34FCC6D3)
Al
Am Freitag, 14. Januar 2005 18:40 schrieb Al Bogner:
Ich habe jetzt erstmals eine DSL-Verbindung auf einem Testrechner unter 9.2. Hat sich die Warnsyntax gegenüber 9.1 geändert? Online-Tests meinten, dass die FW dicht ist.
Was bedeutet "SFW2-OUT-ERROR IN"?
Gute Frage! In "iptables -L" kommt diese Meldung nur in der letzten Regel der OUTPUT chain vor: Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 LOG icmp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 icmp type 11 LOG flags 6 level 4 prefix `SFW2-OUT-TRACERT-ATTEMPT ' ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 11 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 3 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 4 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 9 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 10 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 13 reject_func icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-OUT-ERROR '
Die erste Regel sollte aber doch eigentlich immer greifen? Dann frage ich mich, wie die letzte Regel überhaupt jemals erreicht werden kann.
Auffällig ist auch, dass die einzelnen Portscans von den Onlinetests nicht in den messages zu finden waren. Woran könnte das liegen?
Auch wenn du "FW_LOG_*_ALL" in /etc/sysconfig/SuSEfirewall2 auf "yes" setzt?
Hier ein kurzer Auszug aus dem Log:
Jan 14 17:55:47 client7 kernel: SFW2-OUT-ERROR IN= OUT=dsl0 SRC=83.64.76.214 DST=216.254.95.40 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=56070 DF PROTO=TCP SPT=1134 DPT=8081 WINDOW=1452 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A001A14CA34FCC6D3) (...).
Solche Meldungen finde ich auch für verschiedene Zieladressen, allerdings recht selten. Aber immer "ACK FIN" oder "ACK PSH FIN".
MfG, Jan
Am Donnerstag, 20. Januar 2005 21:37 schrieb Jan Ritzerfeld:
Gute Frage! In "iptables -L" kommt diese Meldung nur in der letzten Regel der OUTPUT chain vor:
Meine Glaskugel flüstert mir zu, das es sich vielleicht wieder mal um ein Cold-/Hotplug-Problem handelt. Seit einem Reboot kam das nie wieder. Ich habe nun schon so oft erlebt, dass eine Änderung im Yast erst nach einem Reboot funktionierte und Firewall hat ja etwas mit Netzwerkkarten zu tun, wo es genügend Probleme schon bei 9.1 gab.
Al
Am Donnerstag, 20. Januar 2005 21:37 schrieb ich:
Am Freitag, 14. Januar 2005 18:40 schrieb Al Bogner: (...).
Was bedeutet "SFW2-OUT-ERROR IN"?
Gute Frage! In "iptables -L" kommt diese Meldung nur in der letzten Regel der OUTPUT chain vor: Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 (...). LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-OUT-ERROR '
Die erste Regel sollte aber doch eigentlich immer greifen? Dann frage ich mich, wie die letzte Regel überhaupt jemals erreicht werden kann.
Oje! Das sollte ich besser iptables fragen, aber diesmal richtig: # iptables -vnL OUTPUT Chain OUTPUT (policy DROP n packets, mY bytes) pkts bytes target prot opt in out source destination xxxY xxxY ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 (...). xxxY xxxY ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED xxxY xxxY LOG all -- * * 0.0.0.0/0 0.0.0.0/0
Ich hatte mich schon gewundert warum nirgendwo ein Interface angegeben war.
(...). Solche Meldungen finde ich auch für verschiedene Zieladressen, allerdings recht selten. Aber immer "ACK FIN" oder "ACK PSH FIN".
Wahrscheinlich Verbindungen, die aus dem Connection-Tracking schon rausgeflogen sind und "ACK FIN" zählt kaum als NEW ...
MfG, Jan
-
Al Bogner -
Jan Ritzerfeld