Opfer und Täter zugleich: Wenn der Spieleserver für eine DoS-Attacke missbraucht wird

Behauptete ich an irgendeiner Stelle, dass das mit dem Spieleserver ein kleines Projekt werden solle, dem nicht viel Zeit gewidmet würde? Ich muss im Delirium gewesen sein. Zugegebenerweise es geschieht nicht jeden Tag, dass ich plötzlich entdecke, dass mein OpenArena-Server als Verstärker und Waffe in einer DoS-Attacke auf Webserver und andere unbescholtene Dienste im Internet dient.
Als ich am Samstag auf meinem Server einloggte um ein paar Webseiten von linuxiuvat.de anzupassen, wollte ich kurz den monatlichen Traffic-Verbrauch überprüfen. Ein nützliches Werkzeug dafür ist z.B. slurm, das ich letzten Sommer mal mit meinen anderen favorisierten Systemmonitoren für die Konsole vorgestellt habe. Slurm zeigt übersichtlich den ein- und ausgehenden Netzwerkverkehr in Echtzeit an, konzentriert sich dabei aber nur auf das Wesentliche. Eine detaillierte Aufschlüsselung des Traffic lässt sich mit iftop darstellen, was sich kurz danach noch als nützlich erweisen sollte.
Zu meiner Überraschung signalisierte slurm, dass mein ausgehender Traffic bei 2-3 MB/s lag. Ok, hier werden die Systemadministratoren von Ex-Megaupload sicher schmunzeln, für meinen kleinen vServer war das aber schon eine ganze Menge.
Nur zum Vergleich: Ich habe 1000 GB Traffic frei im Monat, danach wird die Anbindung von 100 Mbit auf 10 Mbit gedrosselt. Momentan liegt mein monatlicher Verbrauch bei ca. 20 GB, obwohl ich vier Spieleserver und einen Webserver online habe. Da ist also noch etwas Luft nach oben...

Netzwerkanalyse

Fasziniert starrte ich also auf slurm und konnte mir über diese Zahl keinen richtigen Reim machen, weswegen ich mir mit iftop die Sache genauer anschaute.


Interessanterweise zeigte sich hier, dass von Port 27960 viel Netzwerkverkehr in Richtung mehrerer Webserver ging, die allesamt keine wirkliche Beziehung zu meinem OpenArena-Server hatten, der auf Port 27960 lauschte. Mit Hilfe von tcpdump konnte ich herausfinden, dass eine Unmenge von getstatus-Kommandos an den OpenArena-Server gesendet wurden, der daraufhin anstandslos Servervariablen und die Anzahl der Spieler an den Webserver übermittelte, womit dieser natürlich gar nichts anfangen konnte. Eine gute Einführung zu tcpdump gibt es im Wiki von ubuntuusers.de.
tcpdump -i eth0 udp and port 27960 -w traffic.log
Mit diesem Befehl lassen sich sämtliche UDP-Pakete, die von und zu Port 27960 geschickt werden "mitschneiden". Ein grafisches Netzwerkanalyse-Werkzeug wie Wireshark, kann später bei der Analyse der Daten helfen.


Wie diese Variablen für meinen Server aussehen, lässt sich z.B. auf der Statusseite von dpmaster.deathmask.net nachschauen.

Nachforschungen

Nach kurzer Recherche im Internet fand ich schon mehrere Beiträge, die ähnliche Probleme beklagten. So zum Beispiel im OpenArena-Forum, bei ioquake.org und im Forum von UrbanTerror. Allen war gemein, dass es sich hier immer um auf Quake3 basierende Spiele handelte.
Hier fiel dann auch das Stichwort: DRDoS-Attacke, was für Distributed-Reflected-Denial-of-Service-Attacke steht. Dabei wurde meinem OpenArena-Server eine falsche Absenderadresse mitgeteilt (IP-Spoofing), so dass dieser die normalerweise harmlose getstatus-Abfrage an einen Webserver leitete. Durch die hohe Anzahl von Anfragen und die relativ großen Pakete, die verschickt wurden, entstand ein Verstärkungseffekt, der noch größer ausgefallen wäre, wenn ich mehrere verwundbare OpenArena-Server installiert gehabt hätte.
Die Täuschung beschränkte sich aber nicht nur auf einen Webserver, sondern gleich auf mehrere, was den Traffic natürlich in die Höhe schnellen ließ. Ich schrieb daraufhin einen Fehlerbericht für Debian mit der Nummer #665656. Innerhalb kürzester Zeit konnte der Paketbetreuer für OpenArena einen Patch einspielen, der die getstatus-Anfragen an den Server begrenzt. Eine Sicherheitsankündigung gab es hierzu auch schon.

Fazit

Ich war ehrlich gesagt überrascht, dass ich derjenige war, der diesen Fehler schließlich an Debian gemeldet hat, obwohl es den Anschein hatte, dass einige vor mir Betroffene auch Debian benutzen. Der Paketbetreuer reagierte sehr schnell und ich denke durch den Fehlerbericht und die Sicherheitsankündigung ist das Problem prominent sichtbar gemacht worden. Der Bug betraf nicht nur OpenArena, sondern praktisch alle Spiele, die eine ungepatchte Quake3-Engine benutzen, so z.B. auch Tremulous.
Ich hatte vor kurzem notwendige Firewallregeln für den Spieleserver vorgestellt, die auch in dieser Form berechtigt sind. Um den Server aber gegen solche DRDoS-Angriffe abzusichern, braucht man auch hinreichende Regeln, die am besten automatisch und dynamisch hinzugefügt werden. Trafficbegrenzung per IP fällt mir hier als Stichwort neben fwlogwatch ein, dass ich schon einsetze.
Insgesamt gibt es gerade zur Netzwerkprotokollierung und -überwachung noch eine Menge zu lernen. Das Ganze soll nicht darüber hinwegtäuschen, dass bisher alles andere wunderbar funktioniert hat und das Projekt wirklich Spass macht. Auf der anderen Seite ist man aber auch dafür verantwortlich, dass der Server nicht Amok läuft und für finstere Zwecke missbraucht wird. Denial-of-Service-Attacken fallen in Deutschland unter Computersabotage und können mit bis zu drei Jahren Freiheitsstrafe geahndet werden. Ich hoffe der Richter lässt in diesem Fall Milde walten. 😉

7 Replies to “Opfer und Täter zugleich: Wenn der Spieleserver für eine DoS-Attacke missbraucht wird”

  1. Das wüsste ich auch gerne. Vemutlich ist es aber ein ganzes Botnetz. Durch die gefälschte Absenderadresse lässt sich mit meinen Möglichkeiten nicht einmal feststellen, wer der echte Absender ist. So etwas kann nur der ISP feststellen.

  2. Eine Loesung waere OUTGOING zu sperren, bzw. nur 80 und 443 zu Rejecten. Das nervt natuerlich wenn man wget&curl nutzen will auf der Maschine. Man muesste dann halt jeden Rechner einzeln Eintragen (ja das nervt). Zwar OT, aber bei fast allen (0815) Einbruechen auf Maschinen wird via http(s) Zeugs nachgeladen, damit haette (hat) man das komplett unterbunden. Mache ich privat auch nicht, aber waere eine Idee wenn man paranoide Sicherheit usw. steht ;-). Aber schoen zu sehen, dass so schnell ein Patch draussen war.

  3. Ich benutze jetzt die hier beschriebene Methode, die mit Hilfe des recent-Moduls von IPTables überprüft wie wie viele Anfragen in einem Zeitintervall eingetroffen sind und dann dementsprechend den Traffic freigibt oder DROPed.
    Da ich bei ufw bleiben wollte, habe ich die Regeln in /etc/ufw/before.rules gepackt und zusätzlich noch so etwas hinzugefügt:

    -A ufw-before-input -p udp –sport 80 –dport 27960 -j DROP

    Also genau das was du im ersten Satz vorgeschlagen hast, aber nur auf Port 27960 beschränkt. Alle Anfragen, die von Port 80 oder 443 an OpenArena kommen, werden gnadenlos fallengelassen und das filtert doch schon eine Menge weg im Moment. 🙂
    Danke für den Tipp mit dem globalen Blocken von OUTGOING für die http und auch ftp Ports. Ich werde mir das mal genauer anschauen. Sollte tatsächlich jemand in den Server einbrechen, wäre das tatsächlich eine weitere Hürde um Schadcode nachzuladen.

Schreibe einen Kommentar zu Anonymous Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.