iptables: DROP ACK-RST & ACK-SYN trotz ACCEPT ESTABLISHED

#1 Also ich habe einen Packetfilter aufgesetzt, der erstmal alles zurückweist. (Input-Policy: DROP) Trotzdem werden bei hohem Netzwerkverkehr (etwa 1 Verbindungsaufbau pro 30 Sekunden) einige ACK-RST/ACK-SYN Packete verworfen, trotz folgender Regel:
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

Surfen, chatten, downloaden, etc funktionieren!
Und das sind die einzigen Packete die verworfen werden!

Das ist das Script bis jetzt:

Code

#leeren und Std-Verhalten setzen
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

#lokalen Verkehr erlauben
iptables -A INPUT -i lo -j ACCEPT

#einige icmp-msg durchlassen
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

#Packete zu bestehenden Verbindungen durchlassen
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

#Für Testzwecke noch ein log für alle verworfenen Packete
iptables -A INPUT -j LOG --log-level 0 --log-prefix "Und tschuess "

EDIT: Ganz selten werden mal ACK-PSH Packete verworfen.
Es werden keine Fehler ausgegeben, ipfwadm & ipchains sind entfernt und ip_tables & ip_conntrack geladen!
iptables v1.2.2
Kernel 2.4.10-4GB (von SuSE 7.3 prof)
SuSE-FW deaktiviert

#2 mh..

bei ftp ist es so, das manche pakete nicht zu established zählen, sondern als related

also:

iptables -A INPUT -m state --state ESTABLISHED,related -j ACCEPT

versuchs mal

greez

#3 Habs ausprobiert, kommen aber immernoch diese Meldungen. Außerdem hab ich ja kein ftp benutzt, sondern ganz normalen TCP/IP Verbindungen.

#4 Bist Du sicher , dass die verworfenen Pakete einer bestehenden Verbindung angehören ?? Der Paketfilter prüft hierbei nicht nur die Flags sondern auch
Sequenz Bzw.Bestätigungsnummern, sowie Quell/-Zieladresse bzw die entspr. Ports.
Oder hast Du tatsächlich Verbindungsprobleme, unvollständige Datenübermittlung im Internet ??
__________
Durchsuchen --> Aussuchen --> Untersuchen

#5

Zitat

joschi postete
Bist Du sicher , dass die verworfenen Pakete einer bestehenden Verbindung angehören ?? Der Paketfilter prüft hierbei nicht nur die Flags sondern auch
Sequenz Bzw.Bestätigungsnummern, sowie Quell/-Zieladresse bzw die entspr. Ports.
Oder hast Du tatsächlich Verbindungsprobleme, unvollständige Datenübermittlung im Internet ??

Also eigentlich läuft alles, was mich etwas stutzig macht ist ja, das wenn ich während starkem Netzwerkaufkommen zB surfe, sind trotzdem keine Packete von port 80 dabei!

Wenn du mir verrätst wie ich "Sequenz Bzw.Bestätigungsnummern, sowie Quell/-Zieladresse bzw die entspr. Ports" überprüfen kann, werd ichs machen.
Also sie sind weder '--state INVALID' noch '-m unclean'.


Vor dem Log hab ich das hier gesetzt:
iptables -A INPUT -p tcp -m state --state INVALID -j LOG --log-level 0 --log-prefix "Status ungueltig "
iptables -A INPUT -p tcp -m unclean -j LOG --log-level 0 --log-prefix "Packet unsauber "

Es kam nicht ein einziges solches Packet!

#6 Die diversen Nummern, Flags könntest Du mit einem Netzwerksniffer kontrollieren, jedoch ist das, was dein Anliegen anbetrifft ein echtes "Gepfriemel". Um einen Hinweis zu erhalten, wäre es fast sinvoller die Absender-IP der entsprechenden Pakete zu loggen und dann zu checken, ob Du selbst Verbindungen zu den entsprechenden Servern hattest.
Du könntest dies zusätzlich vor allen anderen regeln einfügen und dann die Sache mal weiter verfolgen.
http://board.protecus.de/t2937.htm.

Wie auch immer: solange deine gewünschten verbindungen reibungslos funktionieren, würde ich mir da keinen Kopf machn. Dein Script ist meiner Ansicht nach ok.
__________
Durchsuchen --> Aussuchen --> Untersuchen

#7 Werd mir mal das MonMotha-Firewall-Script ansehen. Vielleicht find ich ja noch das ein oder andere

Mich würde aber halt einfach interessieren, was das für Packete sind. Würde als sniffer wohl schon tcpdump reichen?
Werd mal sehen, meld mich wenns was neues gibt

#8 Also hab jetzt mal tcpdump angestellt und kam dann zu folgendem Ergebnis:

Code

21:57:20.833344 <ich>.4670 > <woanders>.3456: S 2804573201:2804573201(0) win 5840 <mss 1460,sackOK,timestamp 3107069 0,nop,wscale 0> (DF)
21:57:23.824661 <ich>.4670 > <woanders>.3456: S 2804573201:2804573201(0) win 5840 <mss 1460,sackOK,timestamp 3107369 0,nop,wscale 0> (DF)
21:57:25.386983 <woanders>.3456 > <ich>.4670: R 0:0(0) ack 2804573202 win 0
21:57:28.537694 <woanders>.3456 > <ich>.4670: R 0:0(0) ack 1 win 0

Code

21:57:28 [...] SRC=<woanders> [...] LEN=40 TOS=0x00 PREC=0x00 TTL=123 ID=38263 PROTO=TCP SPT=3456 DPT=4670 WINDOW=0 RES=0x00 ACK RST URGP=0

So sieht das bei (bisher) allen ACK-RST Packeten aus! (Hab noch kein verworfenes ACK-SYN eingefangen )

Wie es scheint, werden also zwei fast gleiche Anfragen verschickt (nur timestamp ist nicht gleich), wobei die erste akzeptiert wird und die zweite mit 'ACK 1' (->ACK-RST->Fehler) logischerweise abgelehnt wird.

Nach exakt 3 Sekunden läuft ein TimeOut ab, so dass diese Syn-Anfrage nochmal gesendet wird. Aber warum wird von mir dann kein ACK-verschickt, als Antwort auf das (ACK-)SYN? (Müsste doch so dein, beim Drei-Weg-Handshake, oder?)

Naja, warum das Packet zu keiner bestehenden Verbindung gehört, dürfte jetzt ja klar sein

EDIT: Hab ein paar ACK-SYNs eingefangen

Code

13:32:07.873522 <ich>.3954 > <woanders>.3456: S 1885230600:1885230600(0) win 5840 <mss 1460,sackOK,timestamp 1144374 0,nop,wscale 0> (DF)
13:32:10.871595 <ich>.3954 > <woanders>.3456: S 1885230600:1885230600(0) win 5840 <mss 1460,sackOK,timestamp 1144674 0,nop,wscale 0> (DF)
13:32:10.939403 <woanders>.3456 > <ich>.3954: R 0:0(0) ack 1885230601 win 0
13:32:11.556367 <woanders>.3456 > <ich>.3954: S 3606059394:3606059394(0) ack 1885230601 win 32767 <mss 1360,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)
13:32:11.556749 <ich>.3954 > <woanders>.3456: R 1885230601:1885230601(0) win 0 (DF)

Code

13:32:11 [...] SRC=<woanders> DST=<ich> LEN=64 TOS=0x00 PREC=0x00 TTL=116 ID=40592 DF PROTO=TCP SPT=3456 DPT=3954 WINDOW=32767 RES=0x00 ACK SYN URGP=0 

EDIT2: Jetzt hat der sogar zwei ACK-SYNs verwerfen wollen!

Code

14:14:48.693869 <ich>.1225 > <woanders>.3456: S 304442946:304442946(0) win 5840 <mss 1460,sackOK,timestamp 1400456 0,nop,wscale 0> (DF)
14:14:51.691652 <ich>.1225 > <woanders>.3456: S 304442946:304442946(0) win 5840 <mss 1460,sackOK,timestamp 1400756 0,nop,wscale 0> (DF)
14:14:53.181287 <woanders>.3456 > <ich>.1225: R 0:0(0) ack 304442947 win 0
14:14:56.070168 <woanders>.3456 > <ich>.1225: S 3744068643:3744068643(0) ack 304442947 win 16944 <mss 1412,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)
14:14:56.070443 <ich>.1225 > <woanders>.3456: R 304442947:304442947(0) win 0 (DF)
14:15:00.416473 <woanders>.3456 > <ich>.1225: S 3744068643:3744068643(0) ack 304442947 win 16944 <mss 1412,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)
14:15:00.416736 <ich>.1225 > <woanders>.3456: R 304442947:304442947(0) win 0 (DF)

Code

14:14:56 [...] SRC=<woanders> DST=<ich> LEN=64 TOS=0x00 PREC=0x00 TTL=116 ID=14523 DF PROTO=TCP SPT=3456 DPT=1225 WINDOW=16944 RES=0x00 ACK SYN URGP=0 
14:15:00 [...] SRC=<woanders> DST=<ich> LEN=64 TOS=0x00 PREC=0x00 TTL=116 ID=14555 DF PROTO=TCP SPT=3456 DPT=1225 WINDOW=16944 RES=0x00 ACK SYN URGP=0 

Das sieht mir aus, wie ein ungünstige/falsche Lebenszeit der Packete, eigentlich dürfte sich das doch nie so überschneiden, oder?

#9 Keiner ne Ahnung, wodran das liegt? Oder ist das ganz normaler "Verschleiß"?

#10 TTL=116, also kein Problem mit der Lebenszeit
Ich will niemand abhalten, ausgewertet Paketheader zu betrachten; käme aber selbst nur auf die Idee, wenn die Verbindungsqualität zu Wünschen übrig lässt oder mich sonstwas dazu antreibt (bei dem Wetter ...Puhh ).
Bei den letzten Zweien stellt sich mir die Frage ob Du zu <woanders> zuvor überhaupt eine Anfrage gestellt hast ?? Hast Du ? Sicher ?
Könnte ansonsten auch das Resultat eines Portscans sein was der Paketfilter da verwirft.
Nunja, im Grunde habe ich mich eigentlich wiederhholt. Ist schwer nachzuvollziehen, wenn man so eine Sache nicht bis ins Kleinste vor sich hat.
__________
Durchsuchen --> Aussuchen --> Untersuchen

#11 Ja, ich hab ne Verbindung aufgebaut (ich schick ja auch immer als erstes ein SYN).
Fall 1: Schicke Syn, schicke noch ein Syn (timeout), bekomme normales Rst (Gegenstelle will keine Verbindung) und noch ein Rst
Fall 2: Schicke Syn, schicke noch ein Syn (timeout), Gegenstelle schickt Ack und Rst, kommen aber andersherum an, daher schick ich ein Rst zurück
Fall 3: Schicke Syn, schicke noch ein Syn (timeout), Gegenstelle schickt Ack und Rst ,kommen aber andersherum an, Ich schicke Rst (wegen erstem Rst), bekomme noch ein Syn (timeout der anderen Seite), das wird aber abgelehnt.

Ist also immer eine Ungünstige Konstellation.
Aber damit müsste doch TCP/IP klar kommen, oder nicht?
Naja, bisher hab ich noch keine Probleme deshalb gehabt, also lass ichs erstmal so laufen.