Rule-Bezeichnung "TCP ack packet attack"

#1 Ich sehe im Firewall-Log (Kerio 2.1.3) für sehr viele Einträge als Rulebezeichnung >TCP ack packet attack <
Nun gibt es aber in meinem Set keine Rule mit dieser Bezeichnung.
Die Blocks sind stets "incoming" und ausnahmslos auf Port 80 oder 8080 (hier befindet sich bei mir Proxomitron).
Soweit ich sehe ist der Ursprung dieser "ack packets" oftmals ein Host, den ich auch ansurfe. (lustiges Wort )
Da Kerio vom Prinzip her auf "Verbiete alles was nicht ausdrücklich erlaubt ist" steht, könnte ich mir noch sowas erklären.....weiss jemand was genaues, oder findet jemand diese Rule-Bezeichnung in seinem LOG ?
Gruss, Josch
__________
Durchsuchen --> Aussuchen --> Untersuchen

#2 Hi!

Mit diesen "ack packet attacks" habe ich mich in letzter Zeit etwas genauer befasst und kann dazu folgendes sagen:

Grundsätzlich handelt es sich dabei um den "TCP-Ping", den man bei pcflank testen kann. So, wie ich es verstanden habe, ist das ein PortScan-Typ, bei dem der Angreifer TCP-Pakete schickt, die so aussehen, als bestünde schon eine Verbindung zwischen den Rechnern (per "ack-flag").
Ältere Firewalls wie z.B. Tiny lassen diese Pakete "durch", so dass der Rechner eine Antwort an den Angreifer schickt und somit "non-stealth" ist.

Was passiert nun aber, wenn du von einem Web-Server eine Seite runterlädts, und mittendrin diesen Vorgang stoppst?
Einige Pakete, die noch "unterwegs" sind und ganz regulär eine ack-flag haben, werden beim Versuch, KerioFW zu passieren, als "ack attack" identifiziert und geblockt, da der Browser gar keine Daten-Pakete mehr erwartet (der Zielport der Pakete ist also "leer").

Das sind zwar nur Vermutungen, aber ich denke es ist ganz plausibel und kann leicht nachvollzogen werden: einfach ne Seite laden, während des Ladevorgangs stoppen und hinterher ins Log schauen.

Könnt ihr das bestätigen?

Ciao

#3 Jau...is einleuchtend und mir ist auch klar, wieso das auf einmal auftaucht.
"Log Packets Addressed to Unopened Ports" hab ich vor einiger Zeit auf "enabeld" gesetzt. Deswegen ist die Log-file bis oben voll.
Merci forge
__________
Durchsuchen --> Aussuchen --> Untersuchen

#4 Hi,Joschi

"Log Packets Addressed to Unopened Ports" enabled, kann sich als nützlich
erweisen und daher sinnvoll.Ich vermute daß du auch "Log Suspicious Packets"
aktiviert hast.Da wird deine Firewall-Log schnell mit "ack packet attacks"
(meistens sind es ja keine) zugemüllt.Die einzige Möglichkeit dies zu
umgehen,du deaktivierst diese Option.(Allerdings sollte mal irgendwann ein Angriff wie oben beschrieben stattfinden, wird es dann nicht aufgezeichnet)

Gruß
Ajax

#5 hey forum,

ich würde gerne an diesen uralt-thread anknüpfen, denn ich habe ein ziemliches problem mit oben genannter regel.

Zuerst:
Das Problem tritt bei mir im Zusammenhang mit den geliebten windows-shares auf, welche ohne kerio prima laufen.
Ich habe zwei Maschinen (gekennzeichnet durch ihre netbios namen):
VARDA: w2kprosp4; kerio 2.1.5 ip:192.168.102.1
VMVARDA: ein älteres clone von VARDA, welches in einer virtuellen Maschine läuft (vmware workstation 5.5.1). ip:192.168.102.2
Da VMVARDA ein Clone ist, ist auch seine kerio-installation identisch mit der von VARDA. das im folgende problem tritt sogar mit identischer config (persfw.conf) auf.

Problem:
Greife ich von VMVARDA auf VARDA zu, wird die Anfrage folgendermaßen quittiert:

Zitat

1,[09/Jan/2006 04:21:19] Rule 'TCP ack packet attack': Blocked: Out TCP, localhost:1277->varda [192.168.102.1:139], Owner: no owner

Kerio behauptet also, dass niemand am port139 lauscht, obwohl hier der netbios session service die anfrage entgegennehmen müsste.
Meines Erachtens liegt hier ein Widersruch vor, da der NBSS ja ohne Firewall seinen Dienst prima verrichtet, sonst würden die shares ja nicht ohne firewall funktionieren.
Lasse ich nun Kerio auf VARDA als "Gateway" laufen klappt die ganze Sache wieder.

Das Problem tritt - trotz gleicher config (siehe oben) - nicht auf, wenn VARDA auf VMVARDA zugreift - trotz deaktivierter Gatewayoption.

Kann sich jemand einen Reim auf die geschichte machen?
Danke für eure Bemühungen.