Angriff verantwortlich das nichts mehr ging, auch kein ssh login

S

stefkey

Member
Hallo zusammen,

ich glaube ein Angriff hat meinen Server lahmgelegt. Per SSH war keine Verbindung möglich, nach einem Neustart läuft er jetzt nochmal.

Hier das finde ich im syslog:

Code: 
Dec  1 05:04:18 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:04:19 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:04:28 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:04:30 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:04:34 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:04:35 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:05:58 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:06:04 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:06:07 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:06:08 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:06:16 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:06:30 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:06:31 j2 kernel: nf_conntrack: table full, dropping packet
Dec  1 05:06:54 j2 kernel: nf_conntrack: table full, dropping packet


Ist das dafür verantwortlich das nichts mehr ging, oder bin ich auf dem Holzweg?

Ich lese mal hier http://www.pc-freak.net/blog/resolv...cket-flood-message-in-dmesg-linux-kernel-log/ weiter, wollte aber mal zwischendurch hier Meldung geben und hören was die Profis sagen.

Danke und Grüße
stefkey
 
Hallo!
The message means your connection tracking table is full. There are no security implications other than DoS. You can partially mitigate this by increasing the maximum number of connections being tracked, reducing the tracking timeouts or by disabling connection tracking altogether, which is doable on server, but not on a NAT router, because the latter will cease to function.
Click to expand...
Quelle: http://security.stackexchange.com/questions/43205/nf-conntrack-table-full-dropping-packet

Was sagt denn dein verbrauchter Traffic so?

mfG
Thorsten
 
Traffic sehe ich nichts auffälliges in der jiffybox Verwaltung, oder ist die nicht aktuell? Einen ordentlichen Peak hast bei der Netzwerk-Kommunikation, siehe Bild.

Du meinst ich soll das Tracking deaktivieren?
 

Attachments

  • Bildschirmfoto 2016-12-01 um 12.15.38.png
    Bildschirmfoto 2016-12-01 um 12.15.38.png
    22.3 KB · Views: 148
Sofern du ausschließen kannst, dass legitime Verbindungen aufgrund eines (sehr) massiven Ansturms (z.B. in Verbindung mit hohem KeepAlive) aufgebaut wurden, war es mit Sicherheit ein Angriff. Der TCP-Stack ist in Bezug auf Timeouts etc. gut anpassbar, ebenso sind iptables-Regeln, die zumindest Verbindungen je IP / Port limitiert und ggf. Verstöße loggt (*), trivial. Erfahrungsgemäß kann man aber auch die conntrack-Tabelle deutlich vergrößern, ohne Probleme zu bekommen, da der entsprechende RAM-Verbrauch (heute) nicht mehr ins Gewicht fällt.

(*) Lässt sich super von einer externen Software auswerten, die entsprechende IPs dann dauerhaft blockiert. DDoS-Protection *vor* dem Server ist dennoch immer eine gute Idee ;)
 
Hallo!

Schade, keine Übersicht über die Verbindungsanzahl? Es ist ein virtueller Server, richtig? Wie sehen denn die Vorgabewerte für net.nf_conntrack_max aus?
Code: 
sysctl -a|grep nf_conntrack_max

mfG
Thorsten
 
Danke ihr beiden!

@Thorsten ja, vserver. Standardwert ist 65536

Code: 
error: permission denied on key 'net.ipv4.route.flush'
error: "Input/output error" reading key "net.ipv6.conf.all.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.default.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.dummy0.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.eth0.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.gre0.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.gretap0.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.ip6_vti0.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.ip6gre0.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.ip6tnl0.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.lo.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.sit0.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.teql0.stable_secret"
error: "Input/output error" reading key "net.ipv6.conf.tunl0.stable_secret"
error: permission denied on key 'net.ipv6.route.flush'
net.netfilter.nf_conntrack_max = 65536
net.nf_conntrack_max = 65536

@PHP-Friends Aber macht es Sinn den Wert zu vergrößern, hat das andere Vorteile? Den es war ein Angriff, sonst gibt es ja keine Probleme dahingehend.
 
Hallo!

Du hast doch schon die Zeiten, in denen die Connection Tracking Tabelle voll war (Dec 1 05:04:18 ). Gibt es denn in den Logs Auffälligkeiten anderer Dienste zu diesem Zeitpunkt?

Was macht dieser Server? Ist es eventuell legitim dass er sehr (sehr) viele Verbindungen aufbaut bzw. aufbauen könnte / sollte?

Wenn der Server in der übrigen Zeit ohne Probleme lieft, würde ich als erste Maßnahme nicht gnadenlos die conntrack Werte vergrößern.

mfG
Thorsten
 
Nachdem die Jiffyboxen jetzt in Köln im Netzwerk von HostEurope hängen, sollten die DDoS Attacken eigentlich erkannt werden. Die müssten nach dem Umzug der virtuellen HE Server ins Datadock ja eigentlich schon Entzug im Netzmanagement haben. Damals ware DDoS in der Fläche doch oft am Start.
Da war HE erstaunlicherweise auf Zack. Wenn sonst auch so einiges unrund lief. Beim DDoS waren die Aktivitäten vom Netzmanagment eher erfreulich.
 
Bei einem Traffic-Peak von nicht einmal 6 Mbps (in Worten: Sechs Megabit pro Sekunde) kann man DDoS eigentlich sehr gut gut ausschließen. Selbst ein SYN-Flood hätte mehr Bandbreite erzeugt...

Allerdings ist der Connection-Tracker nicht ohne Fehler und jenachdem, wie deine Firewallregeln aussehen, könnte es sehr gut sein dass der Connection-Tracker einfach vollgelaufen ist weil er Verbindungen als offen erkannt hat, die es nicht waren. Eine Verbindung verbleibt z.B. unter Umständen als offen (und damit standardmäßig 5 Tage) im Connection-Tracker, wenn von deinem Server ausgehend eine TCP-Verbindung geöffnet werden sollte, von der Gegenstelle aber eine ICMP-Nachricht zurückkam, dass der Port nicht erreichbar ist.

Du solltest also nicht nur prüfen was reingekommen ist, sondern auch was möglicherweise rausgegangen ist.
Als Ansatz kannst du die Connection-Tabelle mit "conntrack -L" ausgeben lassen und mal schauen, ob du besonders häufig DST oder SRC bist.
 
Lord Gurke said:
Bei einem Traffic-Peak von nicht einmal 6 Mbps (in Worten: Sechs Megabit pro Sekunde) kann man DDoS eigentlich sehr gut gut ausschließen. Selbst ein SYN-Flood hätte mehr Bandbreite erzeugt...
Click to expand...

Uff, das würde ich so nicht unterschreiben. Ein Kunde von uns wurde gestern mit rund 8Mbit/s SYN angegriffen, in der Tat sieht man solche Miniattacken aber recht selten. ;-)

Ich würde hier fast auf HTTP Request Flood aka Layer7 tippen, das wären bei 6Mbit/s via XML-RPC auch ein paar tausend Requests die dabei zustande kommen :)
 
Moin, jup, heutemorgen wieder Dec 2 04:17:21 j2 kernel: nf_conntrack: table full, dropping packet

Danke erstmal an alle!

Nach einen Restart sehe ich im kernel.log nun folgendes:
Code: 
nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.

Das Problem ist, ich weiß nicht so recht was ich jetzt als erstes mal machen kann um es einzukreisen. Muss mich dann heutemittag mal weiter damit beschäftigen. Bin eben kein Fachmann.

Was ich hier so rauslese ist aber das ich womöglich mit entsprechenden iptables Regeln so etwas abfangen kann. Push, okay ich kann erst heutmittag weiter schauen. Vielleicht hat ja jemand noch 2-7 Tipps für mich ;-)
 
Schneide doch mal den Traffic über Nacht mit; dann weißt du auch, was passiert ist bzw. welche Art von Traffic gesendet wird.
 
stefkey said:
Vielleicht hat ja jemand noch 2-7 Tipps für mich ;-)
Click to expand...

Wie Tim schon angeraten hat, wäre es sinnvoll den traffic mitzuschneiden.

Am besten einfach mal tcpdump laufen lassen und den output in ne pcap file schreiben lassen. Anschließend kann man das Problem analysieren und die pcap file mit den uhrzeit aus deinen logs abgleichen :D
 
hey danke! Ich habe nun tcpdump installiert. Da gehts ja ganz schon ab (da läuft ein Forum auf meinem Server) Es macht m.E. Sinn alles aufzuzeichnen, also den Befehl einfach mit `tcpdump -w couture.pcap`aufrufen.

Die Angabe-Datei zu splitten macht auch Sinn, richtig? Also mit z.B. `-C 50`
 
Was ist denn der Grund warum du das conntrack Modul geladen hast? Hast du irgendwelche NAT Regeln (die brauchen conntrack) oder eine andere stateful Firewall? Einfache Regeln wie "iptables -A INPUT -s xxx -d xxx -p tcp --dport xxx -j target" benötigen afaik z.B. kein conntrack.
 
hmmm, nein ich brauche das conntrack Modul tatsächlich nicht. Aber ich wusste auf Anhieb nicht wie ich es entlade.

Außerdem interessiert mich jetzt auch woher das kommt, und dabei lerne ich auch bissl was dazu. Es wird sicher heutenacht nochmal aussteigen, dann schaue ich morgen ob mir die pcap files helfen und ich was rauslesen kann. Vlt. kann ja jemand helfen von hier wenn ich fragen habe.

Wie deaktiviere ich den das contract Modul? So wie hier beschreiben (das mit den 14 likes)?
http://serverfault.com/questions/72...ernel-module-in-centos-5-3-without-recompilin
 
Hi, nun habe ich traffic mitgeschnitten. Leider ist der "Angriff" aber nicht mehr gekommen, oder vlt hat der Provider etwas verändert vor den jiffyboxen?!?

Kann man sehen welche Kernel Module geladen sind?

Ich habe `modprobe -l` versucht, da gibt es aber nichts aus.
 
Danke sehr PHP-Friends!

Dann habe ich garkein Kernel Module geladen. Denn die Ausgabe zeigt

Code: 
root@j2:/home/user-xyz# lsmod
Module                  Size  Used by
root@j2:/home/user-xyz

Ich kann mich nicht erinnern das ich mit `rmmod nf_conntrack`das Conntrack Modul deaktiviert haben. Aber okay, aktuell läuft ja auch alles :-( Wenn sich Probleme von alleine lösen oder ich nicht mehr weiß wie ich das gemacht habe ist das echt ärgerlich...

Danke erstmal für die tolle Unterstützung hier, immer wieder!
 
You must log in or register to reply here.
Back
Top