fork bomb und maxproc

Z

Zephyrus

Debian und FreeBSD
Hallo erstmal. :)

Mein erster Beitrag hier und gleich geht's dick zur Sache. ;)

Ich habe mich den ganzen Tag fleissig durch FreeBSD Wikis, Foren, HowTos, etc. gelesen und komme als Debian-Umsteiger mittlerweile gut mit FreeBSD zurecht. Natürlich habe ich mir zu allen Dingen meine Notizen gemacht und zum schluss wollte ich dann noch die Fork Bomb testen.

Natürlich nicht um mir mein System zu zerschießen (nur Virtuelle Maschine gewesen) aber es ist passiert. Dabei ist mir aber was interessantes aufgefallen:

Ich habe in der /etc/login.conf bei default einen maxproc von 300 eingetragen und mehrmals die Fork Bomb laufen lassen und das ganze per Top in einer Zweiten Session überwacht. Natürlich kamen nach den ersten 600 Prozessen dann die Warnungen aber nach ca. 1891 Prozessen und ca. 30 Sekunden gingen die Prozesse wieder zurück und die Fork Bomb lief nicht mehr. Keine Ahnung warum, klappte aber so mehrfach.

Dann dachte ich mir, probier mal maxproc 100 aus, müßte dann doch noch weniger Prozesse werden und schneller gehen. Irrtum. Bei maxproc 100 fing sich das System garnicht mehr ein und schnellte weit über 2000 Prozesse, weiter konnte ich aufgrund der Rasenden Fehlermeldungen nichts mehr erkennen :D

Auch ein CTRL+C oder CTRL+D half bei maxproc 100 nicht mehr, das System war absolut nicht mehr ansprechbar. Einloggen über ein drittes Terminal war ebenfalls nicht mehr möglich. Gut das es nur eine Virtuelle Maschine war aber wie kann man sich effektiver auf einem Produktivsystem vor sowas schützen?

Viele Grüße
Zephyrus
 
Danke. Ein durchaus sehr interessanter Thread. Jedoch scheinen die dort auch zu keiner wirklichen Lösung gekommen zu sein. Da ich das ganze heute mit FreeBSD 6.0 getestet habe, probiere ich es morgen mal mit einem frischen 6.1er aus.

Ich hatte jedoch folgende Werte schon gesetzt:
sysctl kern.securelevel=1

/etc/rc.conf
kern.securelevel_enable="YES"
kern.securelevel="1"

/etc/login.conf
bei default und root:
:maxproc=100:\

Ich werds mal zusätzlich noch mit maxprocperuid ausprobieren und mir die anderen Parameter ansehen. Mich hats halt nur gewundert, wieso bei 100 das System in die Knie ging und bei 300 sich erholt hat. Eigentlich müßte es ja andersherum sein, oder?
 
Zephyrus schrieb:
Danke. Ein durchaus sehr interessanter Thread.
Zum Vergrößern anklicken....
:)

Jedoch scheinen die dort auch zu keiner wirklichen Lösung gekommen zu sein.
Zum Vergrößern anklicken....
Ich bin noch an der Thematik dran.
Leider zog sich das Ganze ("richtige" Hardware statt qemu) leider etwas länger als erhofft!

/etc/login.conf
bei default und root:
:maxproc=100:\

Ich werds mal zusätzlich noch mit maxprocperuid ausprobieren und mir die anderen Parameter ansehen.
Zum Vergrößern anklicken....
Nach meinen Tests, die Du gerne verifizieren kannst, hatte ich den Eindruck,
dass FreeBSD als effektiven Wert das Minimum aus maxproc und kern.maxprocperuid bestimmt und verwendet.
Das ist bis jetzt nur empirisch bestimmt.
Der Quellcode wäre noch durchzugraben.

Mich hats halt nur gewundert, wieso bei 100 das System in die Knie ging und bei 300 sich erholt hat. Eigentlich müßte es ja andersherum sein, oder?
Zum Vergrößern anklicken....
In der Theorie: JA.
Aus der praktischen Erfahrung heraus erstaunt mich das nicht.
Wenn Du von 300 auf 100 runtergehst, dann ist der Schwellenwert (in erster Näherung) auch nach einem Drittel der vorher benötigten Zeit erreicht.
Ich bin zwar kein Mess- und Regeltechniker, aber mit dem was in in Abitur und Studium konfrontiriert wurde, würde ich mal den Vorschlag machen,
den Wert von 100 auf 50 runter zu setzen und nochmal zu testen.

Vielleicht fängst Du Dir ja auch durch die VM noch einen Seiteneffekt ein.

Die Mail wurde gerade mit Firefox unter icewm mit maxproc 64 geschrieben.
Das hat bis jetzt gereicht.
Andernfalls nach:
Code: 
maxproc limit exceeded by uid XXX, please see tuning(7) and login.con
in /var/log/messages Ausschau halten!
 
maxproc limit exceeded by uid XXX, please see tuning(7) and login.con
Zum Vergrößern anklicken....

Da brauch ich garnich erst in die Logfiles schauen, damit hat er mir meinen ganzen Bildschirm zugepflastert :D

Naja ich setze eh morgen nen 6.1er auf richtiger Hardware zum testen auf und kann dann ruhig mal damit testen. Wenn der weg stirbt, ist das nicht so wild. Notfalls setz ich ihn neu auf und falls Hardware beschädigt wird, tausch ich die halt aus.

Ich meld mich, wenn ich neues rausgefunden habe.

Edit:
Würde man SSH-User mit ihrer Shell in ein Jail sperren (müßte ja gehen), dann dürfte ja nur seine eigene Shell abkratzen und nicht der ganze Server, oder? Das wäre doch auch ein Lösungsansatz.
 
Zuletzt bearbeitet:
Ich meld mich, wenn ich neues rausgefunden habe.
Zum Vergrößern anklicken....
Viel Spass!

Würde man SSH-User mit ihrer Shell in ein Jail sperren (müßte ja gehen), dann dürfte ja nur seine eigene Shell abkratzen und nicht der ganze Server, oder? Das wäre doch auch ein Lösungsansatz.
Zum Vergrößern anklicken....
Das auch noch in meiner TODO-Liste.
Auf Grund mangelnder praktischer Erfahrung, in der Theorie ja :)
 
@Zephyrus
tib schrieb:
Nach meinen Tests, die Du gerne verifizieren kannst, hatte ich den Eindruck,
dass FreeBSD als effektiven Wert das Minimum aus maxproc und kern.maxprocperuid bestimmt und verwendet.
Das ist bis jetzt nur empirisch bestimmt.
Der Quellcode wäre noch durchzugraben.
Zum Vergrößern anklicken....
Ich habe in den Quellcode gesehen.

Beim Login wird der Wert von maxproc aus /etc/login.conf.db geleben und auf RLIMIT_NPROC gemappt.
Anschliesend wird RLIMIT_NPROC mit kern.maxprocperuid verglichen (src/sys/kern/kern_resource.c).
 
fork(2) erzeugt nie mehr prozesse als durch maxproc erlaubt.

entweder ist dein Kernel gehackt worden oder du machst irgendwas falsch.

auf bald
oenone
 
Legt euch eine login Klasse fork mit maxproc=42 an. Legt einen User fork an der in dieser Klasse ist. Wechselt mit 'su -l fork' (und nicht mit 'su fork', hierbei wird die login.conf nicht eingelesen!) auf diesen Account. tippt limits und seht, dass der User maxproc 42 hat. Kompiliert eine forkbomb und startet sie.

ps auxwww | grep fork | wc -l liefert euch vmtl 44 zurück. 42 mal die forkbomb, eine shell und euer grep. Hier getestet unter FreeBSD 6.1-STABLE.

Die sysctl ist das limit das FreeBSD aufgrund der Hardware "errechnet". Es gilt für User die in ihrer login-Klasse unlimited haben. Für Nutzerbeschränkungen ist es das falsche Werkzeug (auch wenn es vmtl funktioniert), dafür ist die login.conf da.
 
Elessar schrieb:
ps auxwww | grep fork | wc -l liefert euch vmtl 44 zurück. 42 mal die forkbomb, eine shell und euer grep. Hier getestet unter FreeBSD 6.1-STABLE.
Zum Vergrößern anklicken....

Falsch... 1*shell + 41*fork = 42 prozesse.. mehr kann der user nicht anlegen. die restlichen 2 zeilen sind dann grep (manchmal oder manchmal auch nicht, durch grep -v grep kann das entfernt werden) und su.

auf bald
oenone

PS: root kann immer unbegrenzt viel Prozesse starten... testet das also nicht als root und auch nicht wie Elessar sagte, ohne -l oder - im su.
 
Zuletzt bearbeitet:
Gnarf, ich glaube ich muss nochmal in Lesen 3 oder so.

Ja, 41 bombs, 1 shell, 1 grep und einmal noch das su ;)
 
PS: root kann immer unbegrenzt viel Prozesse starten... testet das also nicht als root und auch nicht wie Elessar sagte, ohne -l oder - im su.
Zum Vergrößern anklicken....

Ich denke da liegt der Hund begraben. Zwar kann man auch für root die Prozesse beschränken aber in meinem Fall hat er das nicht gefressen. Liegt aber sicher eher an mir als an der Technik ansich.

Danke jedenfalls allen für die ausführliche Diskussion - und vor allem auch sachliche :)

Super Forum hier!
 
Im Fall von root wird das maxprocperuid limit überhaupt nicht ausgewertet, root kann daher immer bis kern.maxproc (globales limit) Prozesse erzeugen.

Wenn du willst, das root maxprocperuid Einstellungen (sysctl oder login.conf) beachtet, musst du security.bsd.suser_enabled auf 0 setzen würde ich sagen. Das dürfte aber ein interessantes Systemverhalten verursachen. Das teste ich jetzt nicht.
 
Elessar schrieb:
Im Fall von root wird das maxprocperuid limit überhaupt nicht ausgewertet, root kann daher immer bis kern.maxproc (globales limit) Prozesse erzeugen.
Zum Vergrößern anklicken....
Das die Werte in /etc/login.conf und maxprocperuid nicht angezogen werden konnte ich empirisch bestätigen.

Wenn du willst, das root maxprocperuid Einstellungen (sysctl oder login.conf) beachtet, musst du security.bsd.suser_enabled auf 0 setzen würde ich sagen. Das dürfte aber ein interessantes Systemverhalten verursachen. Das teste ich jetzt nicht.
Zum Vergrößern anklicken....

Beim Versuch den Wert auf 0 zu setzen ist des System eingefroren!
Googeln ergab folgendes:

Code: 
security.bsd.suser_enabled - if (1), the root user is also the super-user, and passes privilege checks. Don't unset this, as the semantics are complicated!

Gibt es irgendwo, außer dem Quellcode, noch Informationen darüber?
 
Das hatte ich erwartet, deshalb hab ich es nicht ausprobiert.
Mir ist keine weiterführende Doku zu diesem sysctl bekannt.
 
mal ein ganz dumme Zwischenfrage...

ein root-user im Jail hat also auch keine Limits. Denn wie ich mich erinnere sind doch Jails bis jetzt nicht limitierbar.

Oder hat sich da inzwischen was dran geändert?
 
tib schrieb:
Wahrscheinlich wird dann das Hochfahren des Betriebssystems nicht funktionieren.
Zum Vergrößern anklicken....
Interessanterweise läst sich das System booten.

Allerdings ist kein Login möglich, weder als root noch als normaler Nutzer.

Dafür erscheinen viele "Operation not permitted" auf der Konsole.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben