kernel: nf_conntrack: table full, dropping packet.

[xplod]

Hallo zusammen.

Ich habe ein Problem mit meinem OpenSuse 11.1 64bit Server (Intel i7 12GB RAM):
Das Ding steht in einem Firmennetzwerk, in dem es nachts hoch her geht. In den Logbüchern stehen dutzende von DNS Anfragen, so wie versuchte Zugriffe auf die Netzlaufwerke. An sich kein Problem, nur nach mehreren Tagen steht auf einmal folgendes im Logbuch:


May 11 02:01:28 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:29 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:29 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:30 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:34 hwe-core7 kernel: __ratelimit: 4 callbacks suppressed


Wenn die Meldung im Logbuch steht, dann geht gar nichts mehr, und ich muss den Rechner hard resetten.

Leider habe ich zu diesem Problem nur Antworten für kleine Netzwerkrouter gefunden, und nicht für "richtige" Server. Beispielsweise steht schon in der nf_conntrack_max in Wert von 65536 (Suse default).

Hat jemand von euch dieses Problem auch schon gehabt? Kennt jemand werte für Timeouts, die besser funktionieren als die Standardeinstellungen?

Ein paar Werte sind:
nf_conntrack_udp_timeout 30
nf_conntrack_tcp_timeout_close 10

Welche Datei sollte man am Besten mitloggen, um den Verursacher zu finden? /proc/net/nf_conntrack liefert leider keine Uhrzeiten mit.

Danke und Gruß
_X_

[tomes]

Hallo,

eigentlich solltes du die aktiven Verbindungen mit netstat sehen. Wenn das Nachts ist und du da nicht arbeiten darfs, dann schreib dir ein kleines shell Script das du mit cron alle x min laufen lässt und die 20-30 ersten Zeilen mitlogst.

Du kannst auch eine "einfache" logging Regel für iptables erstellen und den nächsten Tag das Logfile auswerten.
Irgendwie so:


iptables -I INPUT -p tcp -i eth0 -m state --state NEW -j LOG --log-level notice


Du kannst allgemein mit iptables die neue Verbindungen (act-sync) pro Client beschränken.
Iregndwie so:


iptables -I INPUT -p tcp -i eth0 -m state --state NEW -m recent --update --seconds 2 --hitcount 10 -j DROP

Damit sollte deine conntrack table nicht mehr so voll sein.

Allerdings sind meine Erfahrungen noch von ip_conntrack, sollten aber im allgemeinen noch immer so funktionieren.

Wahrscheinlich pingen (deine) Windows Rechner (NETBios) ständig durch die Gegend, um zu sehen ob die anderen noch da sind. Ein Windows Rechner in einem Netzwerk sucht immer Anschluss an die Gruppe, da er alleine Angst hat *ggg*. (vor allem Nachts)

mfg
tomes

P.S.: Aber pass auf dass du dir nicht selber alles zumachst (ssh)

[xplod]

Hallo,
eigentlich solltes du die aktiven Verbindungen mit netstat sehen. Wenn das Nachts ist und du da nicht arbeiten darfs, dann schreib dir ein kleines shell Script das du mit cron alle x min laufen lässt und die 20-30 ersten Zeilen mitlogst.

Das sieht eigentlich ganz gut aus. Da stehen nur Verbindungen zu Netzlaufwerken drin, und das ist in Ordnung.


Wahrscheinlich pingen (deine) Windows Rechner (NETBios) ständig durch die Gegend, um zu sehen ob die anderen noch da sind. Ein Windows Rechner in einem Netzwerk sucht immer Anschluss an die Gruppe, da er alleine Angst hat *ggg*. (vor allem Nachts)

Ich habe keine Ahnung, wie viele Rechner nachts noch an sind, aber sie scheinen Nachts wohl so richtig kommunikativ zu sein. Das Logbuch quilt vor "Ich bin x.x.x.x." Und "wer ist y.y.y.y." nur so über. Und genau diese Anfragen wollte ich nicht filtern, da der Server dann ja keine Rechner mehr finden kann.

Bei den IPTables habe ich den Fehler gemacht, dass YAST die Einstellungen vornehmen sollte. Eigentlich sollten alle Ports außer denen, die wirklich gebraucht werden, geschlossen sein. Ein Portscanner hat mir das bestätigt.

Kann es sein, dass conntrack sich einfach nur eine Liste aller Rechner erstellt und diese irgendwann vollläuft? Im Intranet befinden sich wahrscheinlich hunderte von VMWare Maschinen, die lustig irgendwelche wechselnden IPs bekommen. Wenn da so ein kleiner Linuxrechner versucht Überblick zu behalten kann das nur schiefgehen...

[tomes]

Hi,

mal am Rande, warum ist da ein Firewall an, wenn das Ding nur im Intranet steht? Oder gibt es ein direkte Verbindung nach "draussen"?
Wenn nein, dann schalte doch einfach das tracking ab. Es soll doch hauptsächlich gegen sync-flood''s helfen. Und diese sollte es von innen nicht geben. Wenn doch, ist da ein "böser" Bube oder ein falsch konfigurierter Client.

Ansonsten kann man man auch einzelne Ports auf UNTRACKED stellen (dns z.B.). Aber dann auch immer wieder mal nachschauen ob alles im "grünen" Bereich ist.
Vielleicht ist es auch besser ein IDS oder ntop aufzusetzten um zu sehen werd das Netz zumüllt.

mfg
tomes

[xplod]

Der Rechner hängt wirklich nur in einem Intranet und hat keinen Zugang zur großen weiten Welt. Allerdings hatte ich das Problem, dass die nächtlichen Backup- und Wartungsprozesse im Netzwerk den Linuxrechner (er ist einer der wenigen seiner Art, der Rest ist Fenstermüll) mit vielen für ihn unbekannten Anfragen so zumüllten, dass dieser danach nicht mehr richtig funktionierte. Ich weiß nicht mehr genau, welche Ports das waren, aber es kamen Anfragen auf Standardports, die mit Nicht-Standard Anfragen gehämmert wurden...

Nachdem ich alle funktional nicht benötigten Ports gesperrt habe lief das System einwandfrei. Es stürzt halt nur mal nach ein paar Wochen ab...

Ich habe mir mal die Mühe gemacht und mit Wireshark den Idle-Traffic anzusehen, der so durchs Intranet geht. Das sind wie gesagt fast nur "Wer ist" und "Das bin ich" Nachrichten des DNS. Die Dienste, die Nachts laufen kann ich leider nicht analysieren, da ich da nicht arbeite und ich wegen der Logfilegröße nicht einfach alles aufzeichnen möchte.

Ich denke, ich werde mich wohl mit IPTables beschäftigen müssen und dort die Regeln vernünftig anlegen.

Vielen Dank für die Hilfe,
Dirk

[tomes]

Hi,


Nachdem ich alle funktional nicht benötigten Ports gesperrt habe lief das System einwandfrei. Es stürzt halt nur mal nach ein paar Wochen ab...

Nicht benötigte Ports sperrt man nicht, sondern man deaktiviert den Deamon, bzw. die Bindung des Dienstes an das NetzwerkInterface.
Eine Firewall -> Iptables brauchst du, wenn du bestimmte Dienste (Ports) nur für bestimmte Netze/IP's zu lassen willst.



Ich habe mir mal die Mühe gemacht und mit Wireshark den Idle-Traffic anzusehen, der so durchs Intranet geht. Das sind wie gesagt fast nur "Wer ist" und "Das bin ich" Nachrichten des DNS. Die Dienste, die Nachts laufen kann ich leider nicht analysieren, da ich da nicht arbeite und ich wegen der Logfilegröße nicht einfach alles aufzeichnen möchte.


Du meinst bestimmt nicht DNS sondern NETBIOS.
Schau dir doch mal ntop an. Das läuft mit rrdtools.

mfg
tomes