iptables: ip_conntrack error

[atomd]

Hi,

was sollen mir die folgenden messages sagen und wodurch treten diese auf ?
was kann ich dagegen tun ??

17 09:09:02 gate-tux kernel: NET: 89 messages suppressed.
Oct 17 09:09:02 gate-tux kernel: ip_conntrack: table full, dropping packet.
Oct 17 09:09:08 gate-tux kernel: NET: 84 messages suppressed.
Oct 17 09:09:08 gate-tux kernel: ip_conntrack: table full, dropping packet.
Oct 17 09:09:13 gate-tux kernel: NET: 80 messages suppressed.
Oct 17 09:09:13 gate-tux kernel: ip_conntrack: table full, dropping packet.
Oct 17 09:09:17 gate-tux kernel: NET: 99 messages suppressed.
Oct 17 09:09:17 gate-tux kernel: ip_conntrack: table full, dropping packet.
Oct 17 09:09:22 gate-tux kernel: NET: 76 messages suppressed.
Oct 17 09:09:22 gate-tux kernel: ip_conntrack: table full, dropping packet.
Oct 17 09:09:28 gate-tux kernel: NET: 93 messages suppressed.

ich hab redhat 7.3 und das ist das erste mal das ich diese meldungen im log habe aber ich hab eigentlich nix anders gemacht als sonst :-)

thx for help

[Belkira]

Die können auftreten, wenn Du fehlerhafte Filterregeln geladen hast und das Connection Tracking Modul überlädst. Das speichert /proc/sys/net/ipv4/ip_conntrack_max Verbindungen. Was bekommst Du denn für cat /proc/net/ip_conntrack ?

[[WCM]Manx]

Hi!

Für Dein iptables-script:


if [ -e /proc/sys/net/ipv4/ip_conntrack_max ]; then
echo "4096" > /proc/sys/net/ipv4/ip_conntrack_max
fi


Grüße

Manx

[Belkira]

[WCM]Manx,

wie kommst Du darauf, daß 4096 bei Red Hat Linux 7.3 noch nicht eingestellt sein würde?

[[WCM]Manx]

Hi!

Ich weiß nicht was bei RedHat eingestellt ist, Kernel Default sind 2048 ;)
Aber man kann's ja noch raufsetzen.

Grüße

Manx

[[WCM]Manx]

Hi!

Kommt scheinbar auf die Größe des Arbeitsspeichers an:
Siehe auch:
http://www.netfilter.org/documentation/FAQ/netfilter-faq-3.html 3.6!

Grüße

Manx

[Belkira]

Ähm, noch höher? Mit welcher Begründung?

Das bekämpft übergangsweise allenfalls die Symptome, jedoch nicht die Ursache.

:rolleyes:

[atomd]

also

cat /proc/sys/net/ipv4/ip_conntrack_max ergibt: 10232
was ja irgenwie ziemlich groß ist . aber ich habe diesbezüglich nix geändert

im Rechner sind 160MB RAM

es war aber auch das erste mal das ich den Rechner so lange ca. 2 Tage an hatte...
... hab ich irgentwas falsch in meinen Regeln ???

es könnte natürlich sein, das der den affen wegen mldonkey und zu vielen connections auf dauer bekommen hat oder ??


allerdings schon blöd denn es nix mehr mit dem rechner :-(

[Belkira]

"cat /proc/net/ip_conntrack" zeigt bei Dir massig Verbindungen an, richtig? Kannst ja mal analysieren, was das für welche sind.



cat /proc/sys/net/ipv4/ip_conntrack_max ergibt: 10232
was ja irgenwie ziemlich groß ist . aber ich habe diesbezüglich nix geändert

im Rechner sind 160MB RAM

Merkwürdig groß, ja. Und nichtmal eine Zweierpotenz. ;)



es war aber auch das erste mal das ich den Rechner so lange ca. 2 Tage an hatte...
... hab ich irgentwas falsch in meinen Regeln ???

es könnte natürlich sein, das der den affen wegen mldonkey und zu vielen connections auf dauer bekommen hat oder ??

Ja. Deine Regeln nehmen zuviele Verbindungen an, die dann vermutlich nicht vernünftig bearbeitet werden. Oder sie werden ins Nirvana geroutet (schlechtes Firewall-Skript vielleicht?). Verbindungen haben aber ein Connection Tracking Timeout. Das resultiert für Dich dann in einer Art "Denial of Service" Attacke gegen Connection Tracking. Eine Möglichkeit dem entgegenzuwirken, ist, ist die Anzahl von Verbindungen mit iptables zu beschränken: man iptables und dort die limit Extension aufsuchen.

[atomd]

oki thx, werd ich mir angucken

[atomd]

in wie fern können fw regeln in dieser Beziehung schlecht sein ?

[Belkira]

Ein Skript kann z.B. Verbindungen annehmen, die dann irgendwo in der Luft enden und auf ein Time-Out warten oder sich nicht richtig beenden lassen. Wenn Du Deine Firewall nicht selbst aufgebaut hast, probier mal eines der häufig empfohlenen und populären Skripte, siehe z.B. http://freshmeat.net

[Harry]

Hallo,

10232 Conections werden bei Dir über das conntrack-Modul verwaltet und dann sagt der Kernel, dass er Datagramme droppt, weil die Table voll ist !?!?!

Sag mal, Du machst nicht zufällig nebenbei noch einen auf Hacker und führst massenweise Portscans bzw. Security-Checks über die Firewall nach außen durch?

Selbst bei "schlechten" iptables-Regeln kann ich mir eine solche Masse an Verbindungen, die alle auf ein Timeout warten nur dann vorstellen, wenn entweder mehrere Anwender hinter der Firewall sitzen, die jeweils massig Verbindungen öffnen oder ... naja :D

Harry

[geronet]

Oder er is voll der Power-surfer mit 1000-en von IE's :D

[atomd]

ich denke das war ein bug im mldonkey...der hat einfach zu viele Connections aufgebaut