IT-MÜCKE

DDoS-Angriff auf einen Webserver erkennen und abwehren

Beitragsdatum 15.01.2018
Letzte Aktualisierung -
Betrifft Ubuntu 12.x, 14.x, 16.x und andere, apache2.x und andere

Problem

  • Ein Kunde meldete sich mit der Info, dass sein Server ein Problem hätte
  • Auf dem Server (ein VirtualHost) laufen diverse Webseiten seiner Kunden
  • Diese würden nicht mehr auflösen
  • Es läge scheinbar ein DNS-Problem vor

Analyse

  • Ich meldete mich per ssh auf dem Server an
  • Prüfung der Aussage, dass DNS nicht laufern würde mittels dig:
    # Prüfung auf dem lokalen Host:
    dig @localhost testwebseite.de
    
    # bzw. direkt bei Googles DNS-Servern:
    dig @8.8.8.8 testwebseite.de
    
    # beide Anfragen ergaben das richtige Ergebnis - die Auflösung auf eine IP-Adresse (hier Fake-Daten):
    ;; ANSWER SECTION:
    testwebseite.de.            21599   IN      A       12.123.234.345
  • Schlussfolgerung: die DNS-Auflösung arbeitet korrekt - Ursache für die Probleme muss eine andere sein
  • Ich sah mir die Prozesse an mittels top:
    top
    
    # Ausgabe:
    [...]
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    20821 www-data  20   0  408m  51m 5188 R   22  0.3   0:43.17 /usr/sbin/apach
    20713 www-data  20   0  405m  48m 5180 S   20  0.3   0:48.45 /usr/sbin/apach
    21014 www-data  20   0  404m  47m 5100 S    9  0.3   0:00.63 /usr/sbin/apach
    [...]
  • Zahlreiche apache-Prozesse liefen
  • Das legte nahe, dass ein Angriff gegen den Webserver lief
  • Überprüfung:
    # Anzahl der Verbindungen anzeigen, zusammengefasst nach IP-Adressen, Anzahl absteigend sortiert:
    netstat tulpen | grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr
    
    # Ausgabe:
         12 x.dip0.t-
         11 x.164.1.12%7816
          7 x.dyn.tel
          7 x.dip0.t-
          7 x-002-140-
          4 x.229.168.80%781
          3 x.229.168.71%781
          1 x.dyn.tel
          1 x-46-13-6
          1 x.static.gvt
          1 x-13-1-1.sma.
          1 x.229.168.76%781
          1 x.229.168.68%7816
          1 x.229.168.67%781
          1 x.229.168.66%7816
    # Hinweis: aus Datenschutzgründen jeweils den ersten Teil mit einem x ersetzt...
  • Hier konnte ich zahlreiche Anfragen aus einer bestimmten IP-Range erkennen
  • Eine weitere Prüfung:
    # Anzahl der Verbindungen zu einem Port anzeigen:
    PORT=80 ; echo "Anzahl Verbindungen zu Port $PORT:" ; netstat -n | grep :$PORT | wc -l
    
    # Ausgabe:
    Anzahl Verbindungen zu Port 80:
    117
  • Als nächstes prüfte ich die IP-Range - wem gehört diese?
  • Das war alles der selbe Hoster
  • Damit lag ein DDoS-Angriff als Ursache nahe
  • Ich erhöhte noch die Anzahl der maximal erlaubten parallelen Clients beim Apache, siehe dazu apache.org -> maxclients
  • Und beobachtete anschließend die Anzahl der Verbindungen auf den Port 80 sowie von den IP-Adressen (siehe oben genannte Befehle)
  • Die Anzahl der Verbindungen wuchs sehr schnell an und kamen alle aus dem genannten IP-Adressbereich
  • Danach war klar: hier liegt ein Angriff vor
  • Ich prüfte ferner die Logfiles der einzelnen vhosts in Apache:
    grep x.229.168 /var/www/vhosts/*/statistics/logs/access_log.processed | less
    # Auch hier wurde die IP-Adresse anonymisert durch ein x
    # Kann lange dauern
    # Ausgabe: über alle vhosts Einträge zum genannten IP-Bereich
  • Dabei kam heraus: aus dem selben IP-Adress-Bereich wurden in der Vergangenheit immer wieder Angriffe gegen einzelner Webseiten des Kunden gefahren
  • Am heutigen Tag nur gegen eine bestimmte Webseite

Ursache

  • Ausgehend von der beschriebenen Analyse lag die Ursache also in einem DDoS-Angriff aus einer bestimmten IP-Range auf den Webserver des Kunden

Lösung

  • Ich sperrte den IP-Adress-Bereich über die iptables über die Plesk-Verwaltungssoftware des Servers
  • Also z.B.:
    123.345.567.0/24
  • Anschließend startete ich den Apache-Webserver neu:
    /etc/init.d/apache2 restart
  • Und beobachtete danach die Verbindungen über die oben genannten Befehle. Diese stagnierten in einem realistischen Bereich. Die Webseiten den Kunden sind wieder verfügbar.
  • Der Angriff wurde vorerst erfolgreich abgewehrt.
  • Der Hoster des Angreifers wurde über den Angriff informiert.

Quellen:


Ähnliche Themen im blog:
netstat, iptables, plesk


zurück