Administrator's Blog

Die Idee schien einfach und gut zu sein. Einen vServer bei Server4You für weniger Euro im Monat mieten und dabei Serverstandort USA wählen. Dann über Squid (Proxy) entspannt Youtube und Hulu schauen. Soweit die Theorie.

In der Praxis stellt es sich allerdings so dar, dass offenbar die IP-Range (50.30.32.0 - 50.30.47.255) von Server4You bei YouTube auf Blacklist ist. Ich habe es nicht geschafft, ein hier gesperrtes Video über den Proxy zu schauen, stets werde ich als aus Deutschland kommend erkannt. Zuerst hatte ich die Browserkennung in Verdacht, aber selbst auf Konsole mit lynx kommt der Fehler:

Unfortunately, this video is not available in Germany because it may
contain music for which GEMA has not granted the respective music
rights.
Sorry about that.

Das Reverse-Lookup war der nächste Verdacht, denn das lautetet xxx.vserver.de - also wurde das auch fix auf eine .com Domain gelenkt - ebenfalls ohne Erfolg. Leider habe ich nirgends eine Info gefunden, warum das so ist. Bei einem anderen Anbieter, der direkt in den USA sitze, geht das Ganze problemlos.

Hat ein Leser vielleicht einen Hinweis dazu?

Nachdem kürzlich leider mein nagelneues iPhone 4S 32GB bei einem Einbruch gestohlen wurde (Kripo ermittelt und hat auch die IMEI, womit sie die Täter orten will bzw. es vielleicht sogar bereits getan hat), musste schnellstens Ersatz her. Natürlich war die erste Idee, bei der Telekom nachzufragen, denn dort habe ich schließlich mehrere Verträge und auch das 4S bezogen.

Nachdem meine Mail an die Kundenbetreuung nach einer knappen Woche nicht beantwortet wurde und die Hotline wie so oft durch Unwissenheit, was in solch einem Spezialfall zu tun sei, auffiel, war guter Rat teuer. Der heisse Tipp des Hotline-Menschen war, ich solle doch eine Mail an die Kundenbetreuung schreiben mit Diebstahlanzeige etc. Das hatte ich ja aber vor einer Woche bereits getan, sogar der Polizeibericht hing als Scan dran.

Gut, also mal den "Web 2.0 Support" der Telekom in Form des Twitter-Accounts @Telekom_Hilft bemüht. Dort wechseln sich anscheinend diverse Mitarbeiter ab und lesen die vorherigen Tweets zum Thema nicht, trotz dass ich extra immer brav "Reply" genutzt habe. Erst wurde mir ein weiterer neuer Vertrag, dann ein plötzlich ein Netlocked-iPhone 4 (ohne S) angeboten. So richtige Infos zu Preisen etc. bekam ich aber über Twitter nicht. Einen Vertrag habe ich ja aber schon, ich will einfach nur ein neues iPhone 4S und bin natürlich auch bereit, dafür zu zahlen. Die Versicherung kommt ja immerhin für den Neupreis des entwendeten Gerätes auf.

Eine weitere Woche später - ein neues 4S war längst bei Apple bestellt - kam dann noch ein Brief von der Telekom. Darin wurde mir allen Ernstes als "Ersatz für mein entwendetes iPhone 4S" ein netlocked iPhone 4 mit 32 GB für 729 EUR angeboten. Hallo? Ich zahle doch nicht den vollen Originalpreis eines veralteten iPhone 4, welches auch noch netlocked ist, obwohl mir ein 4S geklaut wurde. Irgendwie ziemlich sinnlos, dieses Angebot. Das iPhone 4S ist aber, warum auch immer, als Ersatz bei Diebstählen nicht verfügbar.

Inzwischen ist mein 4S von Apple bereits eingetroffen und die Telekom kann mich mal gerne haben, vermutlich am Ende der Vertragslaufzeit auch als Kunden. Ein wenig mehr Entgegenkommen bei einem Diebstahl sollte bei einem langjährigen Kunden doch drin sein, oder?

Ob das natürlich jetzt bei Vodafone oder O2 besser gelaufen wäre, kann ich nicht sagen. Der Ablauf bei der Telekom war zumindest eine herbe Enttäuschung.

Es soll ja vorkommen, dass ein Server von extern z.B. mit sehr vielen HTTP-Anfragen lahmgelegt werden soll. In so einem Fall ist guter Rat teuer, um Schaden vom Server und der darauf laufenden Websites bzw. Applikationen abzuwenden. Oft hilft einem auch der ISP dabei, verlassen kann man sich darauf freilich nicht. So wurde kürzlich bei einem Fall der Kunde zwar sogar von Hetzner über die DDOS-Attacke informiert Gegenmaßnahmen wurden aber nicht getroffen. Im schlimmsten Fall droht sogar die Sperrung der IP seitens Hetzner, was natürlich zum Teil auch nachvollziehbar ist.

Serverseitig kann man aber auch etwas tun, z.B. das kleine Shell-Script (D)DoS Deflate laufen lassen. Dieses kleine Script prüft ganz einfach per netstat, welche IP eine in der Config definierte Anzahl von Verbindungen überschreitet und sperrt diese wirksam direkt via iptables (diese Variante bevorzuge ich, es wird einfach DROP auf alle Pakete von der Quell-IP angewendet) oder via apf (Advanced Policy Firewall). Das Script hilft natürlich nur, wenn der Server noch erreichbar ist und arbeitet, d.h. wenn die Attacke nicht die die komplette Bandbreite verbraucht oder zu extrem ist.

Zur "Installation", die im Wesentlichen aus ein paar Downloads via wget und der Einrichtung eines Cronjobs funktioniert, holt man sich einfach wie auf der Website angegeben das Script install.sh von einem Server. Alternativ habe ich das Ganze hier nochmals als Mirror hinterlegt: ddos.tar (20 KByte). Den Tarball einfach z.B. nach /usr/local/ entpacken und es kann losgehen.

In der ddos.conf kann man via NO_OF_CONNECTIONS angeben, ab wievielen Verbindungen eine IP gesperrt wird. Das muss man einfach testen bzw. es kommt sehr darauf an, was auf dem Server normalerweise los ist. Bei zu niedrigen Werten läuft man natürlich Gefahr, auch "normale" User zu sperren. Mit BAN_PERIOD legt man dann fest, wie lange die IP gesperrt werden soll. Die eigene IP kann man übrigens mit einem Eintrag (neue Zeile) in der Datei ignore.ip.list whitelisten, 127.0.0.1 ist default auf der Whitelist

Jetzt kann man direkt ./ddos.sh ausführen und sieht auch direkt den Output den im Script ausgeführten netstat, das konkret so aussieht:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Alle IPs mit einer Connection-Anzahl > NO_OF_CONNECTIONS werden nun also für BAN_PERIOD Sekunden gesperrt. Ein Cronjob, der am besten im Abstand läuft, wie auch BAN_PERIOD gesetzt ist, rundet die Config ab.

Erfolge kann man dann ganz einfach z.B. via iptables -L -nv sehen. Diese recht rudimentäre Lösung kann bei kleineren Angriffen durchaus nützlich sein und hat sich schon mehrfach im Einsatz bewährt. Hilfreich sind übrigens auch weitere IP-Adressen und kurze TTL im DNS, um schnell reagieren zu können.

Sollte der Angriff nur auf einzelne Dienste wie z.B. Apache durchgeführt werden, lohnt auch ein Blick auf Fail2Ban.

Prozess-Informationen (ps oder pstree) und CPU- und Speicherauslastung eines Linux-Systems (top, vmstat oder free) gehören wohl zu den am häufigsten benutzten Kommandos eines Admin, der für Linux-Server verantwortlich ist. In den meisten Fällen schaut man nach einem SSH-Connect ja erstmal, was auf der Maschine so los ist, zu der man sich gerade verbunden hat.

Für mich ist das schon fast eine Obsession, schließlich bin ich Statistik-Fan. Neben dem auf jedem System vorhandenen top (welches man auch ganz gut anpassen kann) haben sich mit der Zeit noch ein paar andere Tools in meine tägliche Nutzung eingefügt, die auf keinem Server fehlen.

Klarer Favorit und inzwischen nahezu 100%iger Ersatz für top ist für mich htop. Grafisch ansprechender aufbereitet zeigt es die Auslastung der einzelnen CPU-Cores live mit einem Balken an und fühlt sich generell irgendwie moderner an. Ein weiterer Vorteil ist, dass htop schneller startet als top, da top erst einige Daten sammelt. Weitere Unterschiede sind hier aufgelistet. In Debian und CentOS ist es aus der Distribution problemlos zu installieren.

Das Schweizer Taschenmesser der "Tops" ist aber atop. Es zeichnet sich vor Allem dadurch aus, dass es deutlich mehr Statistiken und Daten liefert als top, nämlich z.B. "Disk Utilization" und "Network Utilization" je Prozess. Außerdem loggt atop periodisch diverse Systemparameter, die sich dann mit dem mitgelieferten Tool atopsar darstellen lassen. Dafür läuft dann allerdings permanent ein atop Prozess auf dem System.

Wer keinen eigenen Dienst laufen lassen möchte oder atop nicht nutzt, die Systemlast aber trotzdem permanent überwachen möchte, kann sich atsar mal anschauen. Hier wird im Grunde wie bei atop der Zustand periodisch geloggt und man kann im sich problemlos die Loadavg oder Disk Utilization der letzten Tage anschauen.

Weitere Live-Tools für diverse Anwendungsfälle, die ich häufig sinnvoll einsetze sind zum Beispiel apachetop, womit sich live sehen lässt, welche Dateien am häufigsten aufgerufen werden, oder iotop. Mit iotop kann man schön sehen, was gerade an I/O auf den Platten los ist und welche Prozesse dafür verantwortlich sind.

Zum Schluss noch der Hinweis auf ein "grafisches" Tool auf der Shell, womit sich der Traffic von Netzwerk-Interfaces ziemlich gut darstellen lässt: nload. Hiermit sieht man recht gut, was gerade an Traffic über ein bestimmtes Interface geht samt Durchschnittswerten.

Natürlich gibt es noch dutzende weiterer Tools. Hinweise oder Tipps in den Kommentaren dazu sind natürlich erwünscht