Fork Bombs, gerade Linux Anfänger in gewissen IRC Channeln oder Foren (siehe ubuntuforums.org) fallen ihnen gerne zum Opfer, wenn sie eine der wichtigsten Regeln eines Anwenders missachten: niemals einen Befehl ausführen den man nicht versteht! Doch was steckt hinter den fiesen Sprengsätzen?
Eine Fork Bomb ist eine Form der Denial of Service Attacke gegen ein Computersystem, in dem Prozesse weitere laufende Prozesse erstellen können. Ziel dieser DoS Angriffe ist es, ein System handlungsunfähig zu machen indem man es mit verschiedensten Techniken an seine Grenzen bringt. Mit einer Fork Bomb startet man nun einen Prozess, der wiederum Kindprozesse startet die wiederum Kindprozesse ins Leben rufen. Dieser Spass geht solange weiter, bis auf dem System nichts mehr geht. Dem Anwender oder Admin bleibt nach kurzer Zeit nur noch die Möglichkeit, den Stecker zu ziehen.
Die coolste und weitverbreitetste Fork Bomb ist wohl . ( ) { . | . & } ; . für die Bourne Again Shell. Was passiert im Detail, wenn man sie ausführt? Schön aufgeschlüsselt wird das im Packetfu Blog:
. () { . | . & } ; .
0 1 2 3 4 5 6 7 8 9
0 - Neue Funktion mit Namen definieren
1 - Die Klammern bezeichnen die Funktion, die ohne (optionale) Argumente auskommt
2 - Funktionsblock beginnt
3 - Ruft sich selbst, die gerade erstelle Funktion, rekursiv auf
4 - Öffnet eine Pipe zu einem weiteren Prozess
5 - Ruft sich selbst, die gerade erstelle Funktion, erneut rekursiv auf
6 - Der Fork (in den Hintergrund schieben)
7 - Funktionsblock wird geschlossen
8 - Beenden der Funktionsdeklaration
9 - Ausführen der Funktion
Oder wie von pimpmyshell.de dargestellt bedeutet das in ausgeschriebener Form:
forkbomb() {
forkbomb | forkbomb &
};
forkbomb
Klar soweit? Dann kommen wir automatisch zu der Frage, wie man sich gegen Fork Bombs und DoS Attacken im Allgemeinen schützen kann. Die Prophylaxe ist vor Allem dann wichtig, wenn man anderen Benutzern in irgendeiner Form Zugriff auf die eigenen Maschinen gewährt - ob mit root Rechten oder nicht. Besondere Bedeutung kommt da übrigens auch Webservern und den darauf laufenden Skripten zu. Weiss ein Angreifer, dass eine bestimmte Seite oder Webanwendung besonders viele Ressourcen benötigt, kann er durch gebündelte Zugriffe schon mit einem PC erhebliche Beeinträchtigungen erzeugen.
Abhilfe bietet Linux zum Beispiel mit den PAM Limits Modul an, das (meistens) in /etc/security/limits.conf konfiguriert wird. Auch hier erscheint einem auf den ersten Blick alles recht kryptisch. Zu tief in diese Datei eindringen macht mit Sicherheit für 90% der Leser keinen Sinn, daher gehe ich an dieser Stelle nur auf die wichtigsten und effektivsten Werte und Parameter ein.
Horizontal ist die Datei in <Domain>, <Type>, <Item> und <Value> unterteilt.
Domain kann hier Folgendes sein:
- ein User,
- eine Gruppe (mit @-Präfix),
- die Wildcard * für den Standardeintrag,
- die Wildcard % für das maxlogin Limit.
Type ist
- 'soft' für das Erzwingen eines weichen Limits, das der User bei Bedarf anheben kann, oder
- 'hard' für das Erzwingen eines harten, absoluten Limits, das nur der Superuser verändern darf.
- Gibt man stattdessen ein '-' (Minus) an, gilt es für beide.
Und Item bezeichnet, was wir tatsächlich begrenzen möchten:
- core: maximale Grösse in KB eines Core Files, welches vom Betriebssystem erstellt wird, wenn zum Beispiel ein Programm abstürzt
- fsize: maximale Grösse in KB, die eine Datei haben darf
- nofile: maximale Anzahl gleichzeitig geöffneter Dateien
- rss: maximal verwendbarer Arbeitsspeicher (KB)
- nproc: maximale Anzahl von Prozessen
- maxlogins: maximale Anzahl der Logins für einen User
- locks: maximale Anzahl von Dateisperren die ein User hält
In der Beispielkonfiguration sind wie erwähnt noch weitere Items vorhanden. Um beispielsweise einer Fork Bomb den Riegel vorzuschieben genügt es aber schon, nproc einen Wert zuzuweisen, also die Anzahl von Prozessen, die ein User ausführen darf, einzuschränken. Wir nehmen dazu an, dass alle Benutzer in der Gruppe users sind und legen folgenden Eintrag in der /etc/security/limits.conf an:
@users soft nproc 75
@users hard nproc 100
Ein User darf also 75 Prozesse laufen lassen. Bei Bedarf kann er sein Soft Limit auf 100 hochsetzen, da ist dann aber definitiv Schluss. Wo man die Grenze genau legt ist von System zu System unterschiedlich. KDE oder Gnome mit den zugehörigen Tools, dazu Firefox, Thunderbird, mpd und ein paar X-Shells, da kann es schonmal eng werden. Ausprobieren heisst die Devise. Anzeigen lassen sich die aktuellen Limits übrigens mit dem Befehl ulimit -a.
Weitere Informationen und Quellen:
yigg this
