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

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information