• 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

• 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?
  • Dazu Aufrufen von:
    https://apps.db.ripe.net/search/query.html
  • Dort eingeben einer der IP-Adressen
  • In der erscheinenden Liste den Eintrag netname suchen
  • Diesen netname dann im Suchfeld der folgenden Seite eingeben:
    https://apps.db.ripe.net/db-web-ui/#/fulltextsearch
  • Dort erscheint dann der Eintrag zum Inhaber der Range
• 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

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

• 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:

• linuxaria.com

Ähnliche Themen im blog:
netstat, iptables, plesk

zurück