Skip to content

Analyse einer DDOS-Attacke

Tagsüber führe ich ein unscheinbares Leben als Administrator für fensterbasierende Operationssysteme, Mausschubser und Käffchenjunkie. Nach Feierabend aber brauch ich ab und an mal was, was die Nerven beruhigt. Was vielleicht erheitert. Etwas entspannendes. Was den Kreislauf runterfährt. Etwas bei dem ich schon fast in meditative Trance verfallen kann. Kurz um: Ich administriere Linux und halte die Jungs auf Abstand, die meinen Internetservern was böses wollen.

"Analyse einer DDOS-Attacke" vollständig lesen

Es wurde mal wieder zeit für mich...

Nach über 2 Jahren wurde es für mich mal wieder Zeit für einen Erste-Hilfe Kurs. An diesem Wochenende konnte ich diesen mit den Kollegen vom 1. Flensburger Lauftreff absolvieren. Durchgeführt wurde der Kurs von Sandra und Ralf vom DRK Flensburg. Interessierte Teilnehmer und zwei klasse Dozenten haben die Zeit wie im Fluge vergehen lassen. Einiges war ja bei mir noch hängengeblieben. Aber vieles hatte sich auch aus dem Gehirn bereits wieder verabschiedet. Aber auch eine Wiederholung gab es. Ich weiss noch, dass ich beim letzten Kurs diese Schocklage auch nicht hinbekommen habe. Irgendwie hab ich das wohl nicht so mit Schock.

Es hat sich aber mal wieder gezeigt, dass man die Erste-Hilfe immer mal wieder auffrischen sollte. Die Kurse sind zum einen nicht teuer, zum anderen solltet Ihr aber einmal beim Arbeitgeber nachfragen. Die übernehmen teilweise dafür die Kosten. Und wenn Du dich an Deinen Führerschein-Kurs erinnerst und da noch so viele komplizierte Dinge zu lernen waren, solltest Du auf jeden Fall nochmal vorbeischauen. Da hat sich in den Jahren viel geändert. Inzwischen weiß man, dass einiges was man früher gelernt hat, gar nicht notwendig war oder es gibt wesentlich einfachere Wege der Ersten-Hilfe. Also auf zum nächsten Kurs. Wir hoffen zwar alle, dass wir das nie anwenden müssen, aber wenn es doch mal notwendig wird, ist der Kurs Gold wert.

Python nur für mich...

Sehnsüchtig warte ich auf das nächste Debian Release. Eigentlich ist Testing schon für die meisten Anwendungen stabil genug. Aber es warten noch ca 200 Bugs, die als Releasekritisch eingestuft sind. Somit ist noch ein bischen Zeit, indem ich die Wartezeit von Squeeze zu Wheezy überbrücken muss. In diesem Falle bin ich kürzlich über das Python Modul fabric gestolpert. Echt interessant und es verlangte nach Tests. Allerdings ist die in Squeeze enthaltene Version doch recht betagt...

Also mal schauen, ob ich nicht neuere Python Versionen und Module installiert bekomme, ohne dabei alles in die Systempfade installieren zu müssen. Python bietet dort interessante Möglichkeiten. Mit dem Programm pip lassen sich module bequem nachinstallieren. Aber auch dort ist die Squeeze Version so alt, dass es noch nicht die Möglichkeit gibt die Module in das Homeverzeichnis eines einzelnen Users zu installieren. pip selbst gibt an ein Replacement für easy_install aus den Setuptools zu sein. Und easy_install ist in der bei Squeeze mitgelieferten Version in der Lage ins User-Verzeichnis zu installieren. Viola. Installationspfad gefunden...

Als erstes installiert man eine aktuelle Version von pip. Wird easy_install mit der Option --user aufgerufen, erfolgt die Installation in das Verzeichnis $HOME/.local des aktuellen Users.

easy_install --user pip

Ist die Installation erfolgreich durchgelaufen, befindet sich im Verzeichnis $HOME/.local/bin ein Executeable namens pip in der neuen Version.

Ist pip installiert, gibt es nur noch eines zu tun. Der Pfad für die Suche nach den Binarys sollte angepasst werden:

PATH=$HOME/.local/bin:$PATH
export PATH


Den Schnipsel packt man am besten in die .bash_profile, damit es nach dem nächsten Login auch noch gültig ist. Einen Funktionstest kann man in der Shell ganz einfach mit which python durchführen. Es muss python in $HOME/.local/bin/ angezeigt werden.

Damit ist das erste Zwischenziel erreicht und ich kann mit
pip install fabric
die aktuelle Version von fabric installieren.

Kür


Zusätzlich wird jetzt noch das Python Packet virtualenv installiert. Virtualenv ermöglicht es einen python-Interpreter mit allen Abhängigkeiten in ein extra Verzeichnis zu installieren. Die Dateien aus /usr/ und Co werden bei dieser Version nicht angefasst. Es ist also auch möglich eine neue Version eines Moduls sauber zu installieren, ohne die OS-gelieferte Version zu deinstallieren oder zu überschreiben.

easy_install --user virtualenv

virtualenv ~/mypython

Virtualenv erwartet als Parameter den Pfad zur neuen Python-Umgebung. Beim Aufruf wird der Python-Interpreter und einige Basis-Programme und Librarys von Python in das angegebene Verzeichnis übertragen.

Möchte ich diese Installation anstatt jener in $HOME/.local/ nutzen, muss ich entsprechend der o.g. Anleitung die PATH-Umgebungsvariable anpassen.

noch ein kleiner Tip...


Ein Python-Script beginnt so wie viele andere Scripte unter Unix auch mit der Angabe des Interpreters. Meistens steht dort #!/usr/bin/python in der ersten Zeile und das Script wird mit dem angegebenen Interpreter ausgeführt.

Trägt man statt dessen in den Scripten

#!/usr/bin/env python

ein, sucht das Programm env nach einem Interpreter mit dem Namen python in den Verzeichnissen, die in $PATH angegeben sind. Welcher Interpreter verwendet wird, hängt jetzt also von der Reihenfolge der Verzeichnisse in $PATH ab. Dies funktioniert nach gleichem Prinzip im Übrigen auch mit perl, php...

Happy coding.

Die Sache mit dem Kernelupdate

Schon seit vielen Jahren baue ich nur noch Linux-Kernels selber, wenn es wegen Treibern o.ä. gar nicht anders geht. Ansonsten bleibt immer der Kernel aus der Distribution drauf. Das sichert auch ein anständiges Update mit dem Packetmanager des Systems.

Wie immer werfe ich mein Update also mit aptitude safe-upgrade an und lasse den Kernel mit updaten. Geht immer Problemfrei. Aber heute hatte ich mal wieder so einen Mist-die-Installation-ist-schon-älter-Effekt. Das ist beim Debian absolut nichts schlimmes. Aber zu erkennen ist es daran, dass ich der /boot-Partiton nur 100MB gegönnt habe. Das hat früher immer ausgereicht. Aber neue Kernels werden auch immer größer. Und so kam es, dass beim Update die Initramdisk für den 3.2er Kernel keinen Platz mehr fang.


update-initramfs: Generating /boot/initrd.img-3.2.0-4-686-pae

gzip: stdout: No space left on device
cpio: Fehler beim Schreiben: Datenübergabe unterbrochen (broken pipe)
E: mkinitramfs failure cpio 1 gzip 1
update-initramfs: failed for /boot/initrd.img-3.2.0-4-686-pae with 1.
dpkg: Fehler beim Bearbeiten von initramfs-tools (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
initramfs-tools


Ein df -h zeigte auch gleich an, dass die Partition voll ist. Hätte ich so rebootet wäre das System nicht mehr hochgekommen. Was bei einem Webserver ohne Zugriff auf eine lokale Konsole fatal ist.

Gelöst bekommt man das Problem ganz einfach. Einmal ein dpkg -l linux-image-* abschicken und ich kann sehen, welche Kernels noch alle Installiert sind. Mit der Ausgabe rollt man das Problem jetzt von hinten auf und deinstalliert die alten Kernels einfach in aufsteigender Versionsnummer bis nur noch die notwendigen Kernels vorhanden sind. Das sieht dann so aus: aptitude remove linux-image-2.6-686 linux-image-2.6.32-5-686 linux-image-3.0.0-1-686-pae linux-image-3.1.0-1-686-pae.

Beim Deinstallieren des Kernels werden auch die Init-Ramdisks, die beim installieren eines Kernels erstellt werden, wieder mit entfernt. Ich hab also danach wieder genug Platz frei.

Das schöne daran ist, dass der Debian-Packetmanager auch gleich mitbekommt, dass der aktuelle Kernel nicht vollständig installiert ist. Nachdem die alten Kernels deinstalliert sind, baut der also automatisch die fehlende Initramdisk nach und das System ist wieder bootfähig.

Der Ablauf ist absolut nichts schwieriges. Aber er taucht bei mir so selten auf, dass ich nicht vor einem Update auf die Größe der /boot Partition schaue. Also dachte ich mir, ich präg mir das jetzt mal durch Bloggen ein...