kernel: ip_conntrack: table full, dropping packet

[QuarK]

Ik spiekte net even in mijn /var/log/messages file en zag tot mijn verbazing de log van vandaag echt vol staan met de volgende soort messages:

code:

...
Jan 13 18:28:37 glas kernel: ip_conntrack: table full, dropping packet.
Jan 13 18:28:42 glas kernel: NET: 173 messages suppressed.
Jan 13 18:28:47 glas kernel: NET: 155 messages suppressed.
Jan 13 18:28:52 glas kernel: NET: 166 messages suppressed.
Jan 13 18:28:57 glas kernel: NET: 173 messages suppressed.
Jan 13 18:29:02 glas kernel: NET: 190 messages suppressed.
...

Alleen vandaag, vanaf een uur of 11 en het aantal onderdrukte messages werd steeds minder.
De bak heeft een 100MBit lijn, draait Debian 2.2, kernel 2.4.13 en iptables 1.2.3. Ik heb helemaal niets gemerkt van een kloteconnectie ofzo, alles functioneerde prima.

Ik gebruik geen NAT/MASQ, en het enige waar ik wel ip_conntrack voor gebruik is een heel simpele iptables rule:

$IPTABLES -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j DROP

Heeft iemand enig idee wat dit te betekenen heeft? Of hoe ik er kan achter komen wat er gebeurd is?

[Verwijderd]

Raar, het lijkt erop of zijn tabel volstaat. ( ja ik kan errors lezen )
Meestal zal hij die toch groot genoeg maken.

Welke kernelversie is het?
Hoeveel ram zit erin?
En hoeveel ram gebruikt hij voor ip_conntrack?
Dit laatste kun je meten met:
cat /proc/sys/net/ipv4/ip_conntrack_max

[QuarK]

Op zondag 13 januari 2002 19:53 schreef MarcelP het volgende:
Raar, het lijkt erop of zijn tabel volstaat. ( ja ik kan errors lezen )
Meestal zal hij die toch groot genoeg maken.

Welke kernelversie is het?
Hoeveel ram zit erin?
En hoeveel ram gebruikt hij voor ip_conntrack?
Dit laatste kun je meten met:
cat /proc/sys/net/ipv4/ip_conntrack_max

Kernel 2.4.13
256MB RAM
16376 /proc/sys/net/ipv4/ip_conntrack_max

Kan het misschien een of andere flood zijn?
Een of andere irc clown die de bak down denk te halen?

[Verwijderd]

Nu ik eens kijk naar je iptables rule gebruik je ! --syn.
Dat betekent dat hij elk pakketje dat geen syn bevat gecheckt wordt. Dat zijn er nogal wat.
Ik denk dat je eigenlijk --syn wilt checken op NEW.
Verander dat eens en kijk wat hij dan doet.

[QuarK]

Wel ik kan het nu niet checken, die errors komen nu niet meer voor in de log. Daarom vond ik het zo vreemd.
Het heeft ongeveer 10 uur geduurd ofzo, nu is het weer helemaal normaal..

Oh, en bedoelde je dat ik die regel beter zo kan doen:

$IPTABLES -A INPUT -i eth0 -p tcp -m state --state NEW ! --syn -j DROP

[Verwijderd]

Nee, ik bedoelde ipv:
$IPTABLES -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j DROP
zou je kunnen gebruiken:
$IPTABLES -A INPUT -i eth0 -p tcp --syn -m state --state NEW -j DROP

Volgens mij gaat hij dan alle syn packetjes matchen met de ip_conntrack tabel.
In jouw geval zal elk pakketje wat de syn bit niet gezet heeft gecontroleerd worden.

Ik weet niet hoe je andere regels eruit zien, dus misschien past jouw regel er prima tussen...

[QuarK]

Op maandag 14 januari 2002 12:07 schreef MarcelP het volgende:
Nee, ik bedoelde ipv:
$IPTABLES -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j DROP
zou je kunnen gebruiken:
$IPTABLES -A INPUT -i eth0 -p tcp --syn -m state --state NEW -j DROP

Volgens mij gaat hij dan alle syn packetjes matchen met de ip_conntrack tabel.
In jouw geval zal elk pakketje wat de syn bit niet gezet heeft gecontroleerd worden.

Ik weet niet hoe je andere regels eruit zien, dus misschien past jouw regel er prima tussen...

Tijdje geleden, maar toch even een kick, even zeker weten

Dit is de oude regel:
$IPTABLES -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j DROP

Deze zou ik dus beter kunnen vervangen door de volgende 2 regels (niet die van jou..):

$IPTABLES -A INPUT -i eth0 -p tcp --syn -m state --state NEW -j ALLOW
$IPTABLES -A INPUT -i eth0 -p tcp --syn -j DROP

Nog niet geprobeerd, zou dit kunnen kloppen? Zo checkt ie niet alle connecties?

[JayTaph]

Op dinsdag 22 januari 2002 10:57 schreef QuarK het volgende:

[..]

Dit is de oude regel:
$IPTABLES -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j DROP

Ja, dat klopt inderdaad niet. Je maakt voor elke niet-sync pakket (sync moet je zien als SYNC+!ACK+!RST), een entry aan in de connectiontracktabel (3keer woordwaarde). Geen goeie zaak.

Maar ik ga ervanuit dat je wilt dat niemand zomaar een tcp-connectie naar binnen kan opzetten.

$IPTABLES -A INPUT -i eth0 -p tcp --syn -m state --state NEW -j ALLOW
$IPTABLES -A INPUT -i eth0 -p tcp --syn -j DROP
Nog niet geprobeerd, zou dit kunnen kloppen? Zo checkt ie niet alle connecties?

Nee, wat je hier gaat doen, is aan alle inkomende connecties een state meegeven (en dat wil je, dus dat is goed). Daarnaast zeg je, alle syncpaketten droppen. Dat kan niet want die heb je een regel daarboven all geallowed.

Het probleem wat hier speelt is dat er niet goed gebruikt wordt gemaakt van connection tracking.

Je hebt 4 verschillende connectie-states: NEW, ESTABLISHED, RELATED en INVALID.

NEW maakt een nieuwe entry aan (veel gebruikt bij TCP-sync pakketen bijvoorbeeld).
ESTABLISHED is wanneer er al een connection-entry is tussen die ip's en poorten (bijvoorbeeld een al opgezette verbinding tussen jouw computer en een webserver)
RELATED is wanneer er een connection-entry is die te maken heeft met het binnenkomende pakket (bijvoorbeeld een ICMP-error dat een poort niet bestaat, is related aan de connectie die je net wilde opbouwen naar die poort toe. Of een beter voorbeeld: een ftp-data kanaal is related aan de ftp poort 21).
INVALID is wanneer er niets gevonden wordt in de connectiontable.

Wat je dus wilt, zijn connecties die binnenkomen bekijken of ze wel verwacht worden om binnen te komen.

code:

$IPTABLES -A INPUT -i eth0 -p tcp --syn -j DROP
$IPTABLES -A INPUT -i eth0 -p tcp -m state --state ESTABLISED,RELATED -j ALLOW
$IPTABLES -A OUTPUT -o eth0 -p tcp --syn -m state --state NEW
$IPTABLES -A OUTPUT -o eth0 -p tcp -j ALLOW

Dit is al een stuk beter denk ik. Regel 1 zorg ervoor dat al het binnenkomend verkeer dat een connectie wil opbouwen (dus een request naar je webserver, mocht je die hebben draaien, of een connectie naar netbus of sub7 ofzo) lekker dropt.
Regel 2, zorgt ervoor dat al het verkeer wat gerelateerd is aan een andere connectie, of al deel uitmaakt van een connectie doorlaat naar binnen (bijvoorbeeld, een ping-reply, of de html-page van google, die je net hebt opgevraagd).
Regel 3 zorgt ervoor dat sync-connecties naar buiten toe (bijvoorbeeld, bij het opvragen van www.google.com, een connectie-entry in de tabel zet. (zodat je die kunt matchen met RELATED,ESTABLISHED).
Regel 4 zorgt ervoor dat "normaal" tcp-verkeer naar buiten toe gewoon doorgaat (zonder een entry aan te maken).

Aanscherpen met poorten kan altijd (bijvoorbeeld, inkomende connecties naar poort 80 mag), maar dat moet je zelf maar uitvogelen.

[QuarK]

Aaah bedankt, het is al een heel stuk duidelijker zo.
Ik ga er nog eens wat verder mee spelen en testen.