Angebliches Ping-Flooding von unserem Server aus

[rubot]

Hallo und Guten Abend,

heute kam eine abuse-Meldung über hetzner an mich heran.

Jemand (wie es scheint kein Serverbetreiber, sondern eine Privat-Person an einem PC) habe ein Ping-Flooding durch unsere IP erfahren:

May 16 16:46:07  PING-FLOODING flooding attack from WAN (ip:213.133.97.72) =
detected.May 16 16:46:01  PING-FLOODING flooding attack from WAN (ip:213.13=
3.97.72) detected

Nun habe ich erstmal mit:

$IPTABLES -A OUTPUT -p icmp -j DROP

den Ping vom Server ausgehend unterbunden.

Per tcpdump stundenlang beobachtet, und atsar logfiles gecheckt.

Da ich nichts entdecken kann und ich mir das gerne erklären würde, bzw vorbeugen möchte:

Wie ist das überhaupt möglich?

Kann sowas durch eine ARP Attacke möglich sein, oder ist vielleicht doch was auf unserem Server, das ich nicht sehe?


Lieben Dank für Hinweise!

Beste Grüße,
Ruben da RUBOT

 

[wstuermer]

DROP[/CODE]
Per tcpdump stundenlang beobachtet

Wie genau hast du den Befehl aufgebaut? tcpdump liefert per Default keine ICMP-Pakete aus.

tcpdump -n -i <interface> -t icmp

sollte dir dann was anzeigen, wenn's denn noch akut ist.

 

[d4f]

Um deine andere Frage zu beantworten:
ICMP-Pakete sind aehnlich UDP stateless und somit muss der Empfaenger vertrauen dass die angegebene Absender-IP korrekt ist.
Einige, aber bei weitem nicht alle Anbieter, fuehren Probability Checks ob die IP-Range ueberhaupt zutreffen kann an ihren Border Gateways durch, andere an internen Router - aber viele ueberhaupt nicht...

 

[rubot]

@wstuermer

stimmt, habe ich nicht dazugeschrieben, sorry. per

tcpdump icmp

natürlich.

@d4f

...und somit muss der Empfaenger vertrauen dass die angegebene Absender-IP korrekt ist...

Bedeutet das, dass jemand Pakete mit einer falschen IP ausstatten kann und diese trotzdem sein/ihr Netzwerk verlassen können?

---

Ich glaube nicht, dass der Server kompromitiert ist, habe aber ein ungutes Gefühl und würde mich noch über ein paar Hinweise freuen, was ich testen kann.

Was haltet Ihr davon ICMP in/out zu unterbinden? Macht ja irgendwie keinen Sinn als Dauerlösung. Stören wird es einen Webserver erstmal nicht, bis auf Monitoring, das ich anpassen muss...

Ich schau natürlich auch mal im Forum rum.

Vielen Dank bisher

 

[d4f]

Viele Anbieter aber nicht alle kontrollieren ob der Absender stimmt da dies durch die notwendige Paket-Inspektion (nicht DPI!) mehr Leistungsbedarf respektiv andere Hardware und somit mehr Kosten bedeutet.
Rechenzentren kontrollieren oft je RZ-Abschnitt in welche die IP's geroutet werden. Alle Pakete von oder zu einer nicht enthaltenen Adresse werden einfach gedroppt.

Wenn dein Server ICMP's nicht rate-limited kann ein Angreifer (welcher eventuell Spoofing einsetzt um deinem Server mehrere Clients vor zu gaukeln) sogar deine Machine als Proxy verwenden da die ICMP-Echo Antwort 1:1 der Anfrage entspricht. Das waere auch der einzige Grund warum ein Angreifer PING statt UDP verwenden soll - schliesslich ist PING-of-death bereits lange passe...

 

[rubot]

Danke sehr für die Antworten.

Bin jetzt auch darauf gekommen mich mehr mit iptables rate limiting zu beschäftigen.

 

[PapaBaer]

Berichtige mich, wenn ich dich falsch verstehe. Du willst mit iptables Ping-Floods sperren, die von deinem Server ausgehen?

Das ist so, als wolltest du ein besseres Schloss an deine Tür bauen, um dich damit gegen Einbrecher zu wehren, die durchs Fenster einsteigen.

Wenn dein Server Ping-Floods sendet und du nicht weißt, warum es das tut, dann musst du rausfinden, warum und die Ursache unterbinden.

 

[rubot]

Das dachte ich ja zuerst auch genau so.

Nun hatte ich aber nach den letzten Antworten und weiterer Beobachtung die Meinung, dass unser Server von außen mißbraucht wurde.

Ich weiss leider nicht, was ich noch beobachten soll ausser dem ICMP Traffic.
Und der hat sich eingestellt, bis auf zeitweise Stöße aus einem (wie es scheint) Video-Stream Netzwerk, die auf andere (teils unbenutzte IPs) im Subnet wollen und ein

ICMP echo request

auslösen.

Auf dem Server läuft kein Prozess, der das tut/getan haben könnte.
Wie würdest Du das genauer prüfen?

 

[PapaBaer]

Wie schon geschrieben: Erstmal tcpdump ne Weile laufen lassen und rausfinden, ob es wirklich vom Server kommt.

Kommt es nicht vom Server und es wurden einfach nur die Absender-IP gefaket, kannst du eh nix machen, weil es mit deinem Server nix zu tun hat.

Kommt es allerdings vom Server, müsstest du alle von außen erreichbare Dienste abklappern, ob da was verwundbar ist. Auch das würde ich wieder mit tcpdump anfangen, um zu sehen, was für Anfragen rein kommen.

 

[Lord Gurke]

Was haltet Ihr davon ICMP in/out zu unterbinden? Macht ja irgendwie keinen Sinn als Dauerlösung. Stören wird es einen Webserver erstmal nicht, bis auf Monitoring, das ich anpassen muss...

Jaein - ICMP ist mehr als Ping!
Über ICMP wird unter anderem auch die maximal mögliche MTU zwischen deinem Server und Clients ermittelt, wenn das unterdrückt wird könnte es gut sein dass Benutzer mit etwas kleinerer MTU (UMTS, Getunnelte IP...) einige Dienste auf deinem Server nicht mehr benutzen können.
Im Zweifelsfalle solltest du lieber nur ICMP-Echo sperren, darauf kann man tatsächlich problemlos verzichten.


Was sagt denn deine Trafficstatistik zu dem Tag (hat Strato doch bestimmt)?
Wenn zum betreffenden Zeitpunkt die Paketrate nicht wirklich angestiegen ist, würde ich von gefakten Absender-IPs ausgehen.
Zudem hast du einen Abuse erhalten. Wenn der Server wirklich kompromittiert wäre, wären das mit Sicherheit ein paar mehr gewesen und es würde sich in der Paketstatistik deutlich ablesen lassen.
Ping-Flood impliziert ja nunmal, dass viele Pakete auf einmal rausgehen...

Was läuft denn auf dem Server? Vielleicht ist die Firewall bzw. das IDS des Beschwerdeführers einfach zu paranoid eingestellt (die Phrase "zu kompliziert" will ich mal nicht benutzen - in den Händen von Unwissenden werden viele nützliche Tools zur Waffe).
Es gibt ja durchaus Serverdienste, die gewollt die Latenzzeiten messen und dabei dann halt für eine gesicherte Info in kurzen Abständen 50-100 ICMP-Echo-Requests raushauen, was dann bei den meisten IDS den absoluten Master-Alarm auslöst.

Nachtrag: Läuft auf dem Server auch ein DNS-Dienst?
Wir hatten den Fall, dass bei großen DNS-Antworten eine vorherige MTU-Aushandlung erfolgte und da auf dem Zielsystem wirklich alle ICMP-Pakete verworfen wurden, wurde vom Server noch 2-3 Mal nachgefragt (kam ja nie eine Antwort).
Währenddessen hat das IDS diese Anfragen als Flood erkannt und alles dicht gemacht. Wegen einer DNS-Anfrage, die aufgrund von DNSSEC und mehreren Round-Robin-Einträgen halt zu groß wurde...

 

[d4f]

Er kann wie bereits gesagt schlichtwegs als Smurf-Relay missbraucht worden sein. Ohne Amplification muss der Angreifer zwar gleich viel Bandbreite aufwenden wie das Ziel abkriegen soll, allerdings steht er zu keinem Zeitpunkt in direktem Kontakt mit diesem, schiebt also die Schuld auf andere Unbeteiligte.

ICMP-Floods koennen uebrigens sogar von einem PHP-Skript verschickt werden, es muss also, sollte der Angriff vom Server stammen, beileibe kein Einbruch ins System sein, sondern nur in einen Webhosting-Account respektiv "nur" in ein schlecht abgesichertes Script oder einen FTP Account. Ueblicherweise werden hierzu aber weniger schnell erkannte und gleich effektive UDP-Pakete statt die aufwendig als raw-Packet zu erstellende ICMP benutzt weshalb ich weiterhin eher von Absender-Spoofing ausgehe.