ip_conntrack läuft alle drei, vier Tage voll

And7 · Jan 3, 2012

Hi,
ich habe seit ungefähr ein, zwei Monaten das Problem, dass mein Server alle drei, vier Tage Anfragen nur noch langsam beantwortet (CPU last nicht besonders hoch..), die Apache Prozesse immer weiter sinken, bis er dann gar keine Anfragen mehr beantwortet. Nur ein Neustart hilft mir dann noch.

In den Log Dateien finde ich immer die Nachricht, dass ip_conntrack voll ist. Ich hab das jetzt die letzte Zeit verfolgt und bemerke, dass in der Datei auch viele anscheinend alte Einträge (meist ESTABLISHED) sind, die man nach drei Tagen sicher nicht mehr braucht. Im Anhang hab ich noch eine aktuelle Statistik von ip_conntrack mit Munin hochgeladen. Da sieht man ja, wie voll die wird.
Kann es sein, dass der Server vergisst, die alten Einträge zu löschen oder ist das doch normal? Ich habe mal versucht, den Timeout für die Established-Einträge zu senken - hat nichts gebacht. Auch die Zahl der maximalen Einträge habe ich schon erhöht, bringt auch nichts..
Eigentlich glaub ich bisher nicht, dass mein Server Opfer einer SYN-Flood Attacke ist. SYN-Cookies hab ich schon aktiviert und sonst würde ip_conntrack doch nicht so stetig ansteigen.

Weiß jemand, was das Problem sein könnte? Auf dem Server habe ich einen Apache-, Minecraft- (wird aber nicht oft benutzt) und einen Teamspeak Server.

Ich würde mich wirklich über Hilfe freuen!

Danke im Voraus!

And7 · Jan 8, 2012

Kann denn niemand helfen? Ich bin immer noch nicht weitergekommen...

d4f · Jan 8, 2012

Ohne direkten Zugriff auf den Server zur Analyse ist es SEHR schwer zu erkennen ob es ein Problem mit deiner Software oder ein echter (D)DoS-Angriff ist, ich tipp aber spontan auf letzteres.

Da die Verbindungen im ESTABLISHED-Stadium sind kannst du sie nicht durch Synflood-Erkennung blockieren, sondern musst die Anzahl gleichzeitiger Verbindungen je IP drosseln.

In einem ersten Schritt solltest du SYN-Anfragen begrenzen:

Code:

iptables -A INPUT -p tcp -m state --state NEW -m recent --set
iptables -A INPUT -p tcp -m state --state NEW -m recent --update -seconds 3 --hitcount 60 -j DROP

Dann noch die Anzahl gleichzeitiger Verbindungen begrenzen:

Code:

iptables -A INPUT -p tcp -m state --state NEW -m connlimit --connlimit-above 45 -j DROP

Achtung
mod_recent kann meist nur einen Hitcount von '20' als Standardwert zulassen, um dies zu erhoehen musst du folgendes in /etc/modprobe.conf setzen:

Code:

options xt_recent ip_list_tot=1500 ip_pkt_list_tot=120

Es kann sein dass du das eine oder andere iptables-Modul erst noch nachladen musst oder, falls der Kernel kein Modulsupport hat, den Kernel wechseln musst.

Hinweis:

Wir haben die obigen Werte durch langes Experimentieren auf einer Produktivmachine (*g*) festgelegt, sie sind ein guter Mittelwert zwischen ungwollter Blockierung und nicht-zu-lockeren Reglungen.

Beachte dass die Effektivitaet enorm steigt wenn du die so blockierten Verbindungen loggst und IP's mit wiederholten Verstoessen direkt ins Nirvana schickst; dadurch wird ein bedeutend groesseres Botnetz fuer DDoS-Attacken benoetigt. Ich kann hier aber auch nicht "einfach so" alle meine Arbeiten veroeffentlichen, da wirst du -basierend auf Hinweisen in meinem Blog- Eigenarbeit leisten muessen...

PS: Das meiste haettest du durch eine Forensuche bereits rausgefunden, aehnliche Themen sind hier schon oefter aufgekommen und die Loesung ist meist sehr aehnlich.

Firewire2002 · Jan 8, 2012

Vielleicht prüfst du erstmal, warum es die Conntrack Table überhaupt gibt. Normalerweise wird diese nicht benötigt. Je nach IPTables Regelsatz wird sie automatisch geladen/erzeugt.

Es wäre also mal interessant, wie dein Regelsatz aussieht:

Code:

iptables -L -n -v

Code:

iptables -t nat -L -n -v

Und wenn du schon so eine schöne Tabelle hast, werte sie doch einfach mal aus. Wer, von wo, wohin baut denn die ganzen Verbindungen auf?
Steht alles da drin.

And7 · Jan 23, 2012

Danke erstmal für eure Antworten! Ich hab in der Zwischenzeit den Server bereits neu installiert. Das Problem ist immer noch da..
@d4f: Danke, Die Regel werde ich mal ausprobieren. Wie heißt denn dein Blog? Ich würde gern mal da bisschen durchstöbern..
@Firewire2002: Hier die Ausgaben:

Code:

# iptables -L -n -v
Chain INPUT (policy DROP 76 packets, 69460 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 386K  347M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
 1849  429K REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 reject-with tcp-reset 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8765 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:8766 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8443 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8880 
 2276  128K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
    0     0 ACCEPT     tcp  --  *      *       **.**.97.154        0.0.0.0/0           tcp dpt:21 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21 
    1    64 ACCEPT     tcp  --  *      *       **.**.97.154        0.0.0.0/0           tcp dpt:22 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:465 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:110 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:995 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:143 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:993 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:106 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5432 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:9008 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:9080 
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:137 
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:138 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:139 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:445 
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194 
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53 
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 code 0 
   62 10226 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 reject-with tcp-reset 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
    0     0 ACCEPT     all  --  lo     lo      0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy DROP 1 packets, 52 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 194K  295M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
 1345  262K REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 reject-with tcp-reset 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
 7253  461K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Code:

# iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 4033 packets, 493K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 9857 packets, 592K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 8576 packets, 744K bytes)
 pkts bytes target     prot opt in     out     source

Ich benutze eigentlich die Standardeinstellungen von Plesk. Hab nur den Zugriff für ein paar Ports für bestimme IP-Adressen eingeschränkt. Die ip_conntrack hab ich bereits angeschaut, bloß bisschen schwierig auszuwerten bei rund 50k Einträgen^^
Ich hab schon normal relativ "viel" Seitenaufrufe. Ich hoste einen Webproxy-Server und da kommen die Leute aus der ganzen Welt.
Welchen Regelsatz sollte ich denn mal ändern, damit die Tabelle nicht erzeugt wird? Sollte ich vielleicht die Plesk Firewall ausschalten und iptables von Hand bedienen?

Und sorry, dass ich erst jetzt antworte. Hab irgendwie nicht mehr mitbekommen, dass geantwortet wurde

d4f · Jan 23, 2012

Noch zu deiner Anmerkung dass du viele alte Eintraege in der conntrack liegen hast;
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
kuerzer stellen. Allerdings entfernt er automatisch alte Verbindungen (anfangend mit ASSURED) wenn er keinen Platz in der Tabelle mehr hat.

Wie heißt denn dein Blog

Rechts oben von meinen Beitraegen ist ein Link

And7 · Jan 23, 2012

d4f said:
Noch zu deiner Anmerkung dass du viele alte Eintraege in der conntrack liegen hast;
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
kuerzer stellen. Allerdings entfernt er automatisch alte Verbindungen (anfangend mit ASSURED) wenn er keinen Platz in der Tabelle mehr hat.

Das habe ich schon vor der Neuinstallation ausprobiert, brachte damals komischerweise nichts. Vielleicht aber diesmal

d4f said:
Rechts oben von meinen Beitraegen ist ein Link

Achso.. Dachte du hast extra ne Website für den Blog und hab nach nem Link gesucht..

And7 · Jan 26, 2012

Ok, hat sich jetzt etwas verbessert. Der Server muss schon mal nicht mehr neugestartet werden, aber die Einträge kratzen mittags knapp an der 50k Grenze..
Den Timeout habe ich auf 12 Stunden runtergesetzt - ist das zu wenig oder geht da noch mehr? Warum ist der Timeout vom Standard aus auf 5 Tage oder so gestellt? Ich finde den Wert etwas hoch..
Gibt es denn noch eine Möglichkeit, die IP-Conntrack für HTTP Anfragen nicht benötigt?

Danke noch mal für die Hilfe!

d4f · Jan 27, 2012

Conntracking kannst du nicht abschalten, da der Kernel wissen muss welche Verbindungen offen sind und welcher Status.
Du kannst hoechstens das iptables-Modul nf_conntrack welches darauf basierend filtern kann deaktivieren; Beschreibung

Ich denke du solltest wirklich rausfinden woher die vielen Verbindungen kommen =)

Warum ist der Timeout vom Standard aus auf 5 Tage oder so gestellt?

Wie schon erwaehnt wirft der Kernel alte Eintraege raus sobald er Platz fuer neue braucht (LRU genannt), ob in den entsprechenden Referenzen nun ein leerer Eintrag oder die Verbindungsinformationen liegen machen performancetechnisch keinen Unterschied. Aus Sicht der Maintainer macht es also keinen Sinn einen kurzen Intervall zu setzen und so oft ein (Ressourcen kostendes) Cleanup oft durch zu fuehren wenn der Leistungsbedarf und Ressourcenverbrauch identisch sind.

blacksynergy411 · Feb 13, 2012

Hallo,

ich hatte auch sehr lange Probleme mit derartigen synflood (DDoS) Attacken und dann ein Script gefunden, mit dem ich den Angriff gut in den Griff bekommen habe. Vergesse jedoch nicht die Konfigurationsdatei anzupassen.

Url:
http://anti-hack.net/Thread-SynBlock-Script

Viele Grüße
bs411

ip_conntrack läuft alle drei, vier Tage voll

And7

New Member

Attachments

And7

New Member

d4f

Kaffee? Wo?

Firewire2002

Registered User

And7

New Member

d4f

Kaffee? Wo?

And7

New Member

And7

New Member

d4f

Kaffee? Wo?

blacksynergy411

New Member

We value your privacy