Problem mit dem Connection Tracking der iptables-Firewall

dsteinkopf · 6 Mai 2006

Hallo nochmal,

ich habe mich nun noch etwas mit dem connection tracking beschäftigt, weil bei mir manche Dinge nicht gehen, weil ip_conntrack_tcp die Verbindung für kaputt hält:

Code:

May  6 11:13:30 fritz.box kernel: SRC=192.168.xx.xx DST=xx.xx.xx.xx LEN=52 TOS=0x08 PREC=0x00 TTL=64 ID=56670 DF PROTO=TCP SPT=xx DPT=xx SEQ=2084163667 ACK=910903613 WINDOW=1728 RES=0x00 ACK FIN URGP=0 OPT (0101080A1898B4B4000281BF) ip_conntrack_tcp: INVALID

Ich habe einiges gelesen (u.a. im Buch "Linux Firewalls mit iptables & Co." von Addison Wesley) und es scheint mir, dass unser Kernel 2.4.17 der FritzBox einfach zu alt ist. Sinngemäßes Zitat (aus dem Kopf):

"Das connection tracking des Linux stand lange seit unter der Kritik, dass das TCP-Window-Tracking zu streng sei und viele Clients, die sich nicht 100% an das Protokoll halten, nicht funktionieren.... Inzwischen wurde das deutlich verbessert..."

Ich habe versucht, die aktuellen Patches von netfilters patch-o-matic in unseren Kernel zu übertragen, das hat aber nicht geklappt, weil dazu u.a. ein Patch mit dem Namen nf-log notwendig ist, der aber mindestens Linux 2.4.31 voraussetzt :-(

Also bliebe noch die Möglichkeit, solche "kaputten" Pakete an bestimmte Ziele einfach gar nicht abzuweisen (z.B. an localhost - wie wir es ja im Zusammenhang mit dem telefon-Dämon brauchen). Aber ich kriege die Pakete in keiner Chain akzeptiert. Offenbar passiert dieses Abweisen vorher...

Irgendwelche Ideen?

Dirk

olistudent · 6 Mai 2006

Hi.
Ich hab mal testweise das ip_conntrack-Modul aus den Linksys-Sourcen kompiliert.
Das blockiert die "INVALID"-Pakete anscheinend nicht...

Source: ip_conntrack_core.c

Code:

Schnipp
if (!(ct = resolve_normal_ct(*pskb, proto,&set_reply,hooknum,&ctinfo)))
/* Not valid part of a connection */
//zhangbin 2005.2.20
//return NF_DROP;
return NF_ACCEPT;

if (IS_ERR(ct))
/* Too stressed to deal. */
return NF_DROP;

IP_NF_ASSERT((*pskb)->nfct);

ret = proto->packet(ct, (*pskb)->nh.iph, (*pskb)->len, ctinfo);
if (ret == -1) {
/* Invalid */
nf_conntrack_put((*pskb)->nfct);
(*pskb)->nfct = NULL;
/* ***************** xiaoqin modify 2005.08.03 ******************/
/* returning NF_ACCEPT will lead "backup configuration" to fail */
return NF_DROP;
//return NF_ACCEPT;
} 
Schnapp

MfG Oliver

dsteinkopf · 6 Mai 2006

Schon viel besser

Es kommen jetzt viele INVALID-Pakete durch die FORWARD-Chain, wo ich sie jetzt einfach mit einer Regel akzeptieren kann.

Aber leider noch nicht ganz ok :-(
Es werden immer noch Pakete vorher einfach verworfen. z.B.:

Code:

May  6 21:24:34 fritz.box kernel: SRC=192.168.32.254 DST=192.168.40.2 LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=4381 SEQ=3159148737 ACK=796264058 WINDOW=5840 RES=0x00 ACK SYN URGP=0 OPT (020405B401010402) ip_conntrack_tcp: INVALID: invalid TC

(NB. Die Meldung ist so abgeschnitten.)

Dirk

dsteinkopf · 6 Mai 2006

Ich habe inzwischen Fälle analysiert, wo der Zielrechner im Status SYN_RECV steht, aber die iptables in der Fritzbox die Antwort ablehnen, weil sie offenbar beim SYN keine Verbindung protokolliert haben. Aber auch dieses Ablehnen passiert wieder vor den Chains...

Dirk

dsteinkopf · 6 Mai 2006

Wieder einen Schritt weiter: Ich habe in ip_conntrack_core.c noch eine Stelle gefunden, wo in 2.4.31 ACCEPT statt DROP steht. Hier der patch:

Code:

--- source/ref-4mb/kernel/kernel_ohio-8mb_build/kernel/linux-2.4.17_mvl21/net/ipv4/netfilter/ip_conntrack_core.c	2006-05-06 21:54:37.000000000 +0200
+++ source/ref-4mb/kernel/kernel_ohio-8mb_build/kernel/linux-2.4.17_mvl21/net/ipv4/netfilter/ip_conntrack_core.c.dstk	2006-05-06 21:55:49.000000000 +0200
@@ -771,7 +771,9 @@
 
 	if (!(ct = resolve_normal_ct(*pskb, proto,&set_reply,hooknum,&ctinfo)))
 		/* Not valid part of a connection */
-		return NF_DROP;
+                //zhangbin 2005.2.20
+                //return NF_DROP;
+                return NF_ACCEPT; // DSTK_2006-05-06 added this patch, changed DROP to ACCEPT
 
 	if (IS_ERR(ct))
 		/* Too stressed to deal. */
@@ -784,7 +786,8 @@
 		/* Invalid */
 		nf_conntrack_put((*pskb)->nfct);
 		(*pskb)->nfct = NULL;
-		return NF_DROP;
+		// return NF_DROP;
+		return NF_ACCEPT; // DSTK_2006-05-06, in 2.4.31 steht hier auch ACCEPT
 	}
 
 	if (ret != NF_DROP && ct->helper) {

Ich bin mehr nicht sicher, ob das überhaupt was gebracht hat - für mich ist es heute eigentlich schon zu spät... Vielleicht probierst du es mal aus. Danke.

Dirk

danisahne · 6 Mai 2006

Hat es eigentlich etwas geholfen, dass das firewall-cgi Paket nun vor den meisten Startskripten aus der original Firmware gestartet wird? Werden die Verbindungen immer noch als INVALID erkannt?

Ich könnte mir vorstellen, dass ip_conntrack Probleme hat, wenn die Verbindung schon besteht, bevor das Modul geladen wird.

olistudent · 7 Mai 2006

danisahne schrieb:
Ich könnte mir vorstellen, dass ip_conntrack Probleme hat, wenn die Verbindung schon besteht, bevor das Modul geladen wird.

So sehe ich das eigentlich auch.
Sobald ich die als INVALID erkannte Verbindung neu starte ist alles Okay, z.B. ICQ, SSH, Telnet...

MfG Oliver

dsteinkopf · 7 Mai 2006

@danisahne: Das weiß ich nicht, ich benutze das firewall-Paket nicht, ich mache das alles "per Hand". Aber Du hast schon recht, das ip_conntrack-Modul, das wir hier haben, blockiert auf jeden Fall Verbindungen, die schon vor dem Laden des Moduls bestanden haben. Es ist also sinnvoll, das Modul so früh wie möglich zu laden. Ich gehe daher auf Nummer sicher und compiliere das Modul fest in den Kernel - schön ist das aber nicht...

Aber trotzdem gibt es vom Kernel außerhalb der Chains abgewiesene Pakete. z.B. die Fälle, wo der Zielrechner im Status SYN_RECV steht, aber die iptables in der Fritzbox die Antwort ablehnen, weil sie offenbar beim SYN keine Verbindung protokolliert haben. Die sind ganz sicher nach dem Start des Moduls begonnen worden (ist ja bei mir fest im Kernel).

Ich kann solche Fälle leider nicht aktiv reproduzieren, sondern beobachte das vor allem bei donkey (mldonkey=mlnet) so alle paar Minuten.

Dirk

dsteinkopf · 8 Mai 2006

Also nachdem die Pakete, die jetzt noch "unkontrolliert" abgewiesen werden, keine dramatischen Auswirkungen haben, habe ich die Forschungen aufgegegben.

danisahne: Kannst Du bitte den Patch von oben in die nächste ds-mod-Version integrieren? Wäre super! (Mach ruhig meine Kommentare raus)

Danke für Eure Hilfe,

Dirk

Languages

Suche

Languages

Suche

Problem mit dem Connection Tracking der iptables-Firewall

dsteinkopf

Mitglied

olistudent

IPPF-Urgestein

Anhänge

dsteinkopf

Mitglied

dsteinkopf

Mitglied

dsteinkopf

Mitglied

danisahne

Aktives Mitglied

olistudent

IPPF-Urgestein

dsteinkopf

Mitglied

dsteinkopf

Mitglied

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums