Die Nutzen einer Fork-Bombe ist zwar fraglich, dennoch finde ich es relativ interessant, wie man ein Linux-System durch ein einfaches Bash Scriptes in die Knie zwingen kann.
Das nachfolgende Script macht nichts anderes, als sich selbst fortlaufen zu reproduzieren. Das Ergebniss ist, dass der Speicher langsamer frei gegeben wird, als das script neuen anfordert. Als erstes wird somit binnen Sekunden der freie RAM knapp, danach versucht das Betriebssystem durch swapping neuen Speicher frei zu geben, was alles in allem in einem „abgestürzten“ System endet. „Abgestürzt“ deshalb, weil das System eigentlich noch läuft, jedoch durch die massive Ressourcen Nutzung des Scriptes keine Zeit mehr hat sich um den Rest sinnvoll zu kümmern.
PATH=. echo 'fork-bomb.sh & fork-bomb.sh' > fork-bomb.sh chmod 755 fork-bomb.sh; /bin/bash fork-bomb.sh
Weitere tödliche Linux Befehle sind unter http://www.junauza.com/… zu finden.
Schutz for Fork-Bomben
Fork-Bomben sind auf Single-User Systeme nicht besonders relevant, da nur ein User davon betroffen ist. Anders sieht es allerdings aus, wenn es um Terminalserver geht. Hier trifft eine Fork-Bombe i.d.R. mehrere Benutzer auf einen Schlag, daher sollte über eine Begrenzung der Systemressourcen nachgedacht werden. Pam (Pluggable Authentication Modules) bietet hierzu eine Möglichkeit solange das Programm das PAM Modul nutzt.
Um dies zu nutzen stellen Sie sicher, dass in der Datei /etc/pam.d/login das pam_limits Modul auch aktiviert ist.
session required pam_limits.so
In der Datei /etc/security/limits.conf können anschließend Systemressourcen pro Benutzer, Gruppe oder für alle Benutzer limitiert werden. Welche Einstellungen möglich sind, kann man der Konfigurationsdatei entnehmen.
#<domain> can be: # - an user name # - a group name, with @group syntax # - the wildcard *, for default entry # - the wildcard %, can be also used with %group syntax, # for maxlogin limit # #<type> can have the two values: # - "soft" for enforcing the soft limits # - "hard" for enforcing hard limits # #<item> can be one of the following: # - core - limits the core file size (KB) # - data - max data size (KB) # - fsize - maximum filesize (KB) # - memlock - max locked-in-memory address space (KB) # - nofile - max number of open files # - rss - max resident set size (KB) # - stack - max stack size (KB) # - cpu - max CPU time (MIN) # - nproc - max number of processes # - as - address space limit (KB) # - maxlogins - max number of logins for this user # - maxsyslogins - max number of logins on the system # - priority - the priority to run user process with # - locks - max number of file locks the user can hold # - sigpending - max number of pending signals # - msgqueue - max memory used by POSIX message queues (bytes) # - nice - max nice priority allowed to raise to values: [-20, 19] # - rtprio - max realtime priority # - chroot - change root to directory (Debian-specific) # #<domain>
Beispiel:
@group1 hard nproc 128 user1 soft priority 0 * - nproc 200
Im oben genannten Beispiel, darf
- group1 max. 128 Prozesse starten. Hardlimit, mehr geht nicht.
- user1 Prozesse max. mit der Priorität 0 versehen. Da es ein Softlimit ist, kann der Benutzer dieses jedoch manuell überschreiben (siehe ulimit).
- jeder andere Benutzer darf max. 200 Prozesse starten Hard- & Softlimit (-).
Vorsicht ist bei der Limitierung von cpu geboten. Hier wird die CPU Zeit in Minuten limitiert. Auf einem Desktop System kann jedoch eine Anwendung schnell mal für einige Minuten sehr viel CPU Zeit anfordern, was beim erreichen des Schwellenwertes zum beenden aller User Prozesse führt für den dieses Limit gilt. Ergo => Abmeldung des Benutzers.
Nach dem speichern der Datei /etc/security/limits.conf gelten die vorgenommen Änderungen für alle neuen Prozesse. Meldet sich also ein Benutzer nach der Änderung an, greifen seine Limiterungen sofort.