Notfall-Konsole

B

blindOracle

Active Member
Hi Leute!

Knifflige Frage an Alle...

Ich habe einen FreeBSD-Webserver in einem RZ stehen, leider dort ohne KVM-over-IP-Zugriff.

Neuerdings scheint diese Maschine wohl diversen DDos-Atacken ausgesetzt zu sein.

Es ist stets der Eingriff des RZ-Personals nötig die Maschine zu resetten, da FreeBSD wohl zum Selbstschutz alles beendet was gerade rumidled, auch SSH.

Jetzt wäre meine Idee gewesen, über /etc/ttys einen Telnet- oder SSH-Zugriff einzurichten, der ja dann über Prozess 1 (init) gestartet würde, somit nicht diesem Idle-Kill unterliegt.

Jedoch ist das scheinbar garnicht sooo trivial.

Jetzt ist meine Frage, ob das hier schonmal jemand gemacht hat?

Ich scheitere derzeit daran, dass ein SSH-Server mit einer anderen Config-Datei scheinbar nicht gestartet wird, nach anpassen der /etc/ttys und kill -1 1.
Rufe ich den sshd mit der angepassten Config direkt über die shell auf, gehts??
Selbiges Verhalten mit Telnetd


Ich danke für alle Ideen und wünsche einen schönen Restsonntag


BlindOracle
 
Ich habe nachgelesen, dass es eine Grenze für die maximale Anzahl der parallel laufenden Prozesse gibt.

Wird Diese erreicht, bzw. überschritten, so werden zum Schutz des Systems, Prozesse die scheinbar nichts tun, beendet um das System als solches lauffähig zu halten.

So?
 
Das macht Linux. FreeBSD kann eine maximale Anzahl an Prozessen verwalten, diese ist durch deine Hardware beschränkt. Angezeigt wird dies im sysctl(1) "kern.maxproc". Ein weitere, tieferes Limit kann man in /etc/login.conf für jede Login-Klasse seperat definieren. Dies ist sogar sinnvoll, damit eine Forkbombe das System nicht zum Stillstand bringen kann.
Wird das Limit erreicht, können keine weiteren, neuen Prozesse gestartet werden. Bereits vorhandene Prozesse laufen natürlich weiter. Das gleiche gilt übrigens bei Speichermangel, dort wird das Programm abgeschossen, was zuviel Speicher ziehen möchte. Anders als Linux schießt FreeBSD niemals willkürlich Prozesse ab und kann daher auch nie in die legendäre Situation geraten, dass der Kernel sich durch ein SIGKILL an init(1) selbst den Hahn zudreht.
 
Eine Forkbombe kann schon zu wahllosem Abschießen führen, nämlich dann wenn sie den ganzen Speicher aufbraucht (deswegen ist ein Prozesslimit auch so wichtig). Da ein einzelner Prozess der Bombe doch recht klein ist, werden erst alle größeren abgeschossen. Ganz vorne auf der Liste ständen da normalerweise ein X-Server, Datenbanken, Webserver, Mailserver ...
 
Ja, das stimmt. Es resultiert aber nicht daher, dass FreeBSD sagt "Hey, X11 ist groß -> STIRB!", stattdessen wird X11 abgeschossen werden, wenn er wieder auf die CPU kommt, was automatisch Speicheraktivität nach sich zieht. Es ist halt gerade der aktive Prozess, es gibt keinen Speicher, also muss er sterben. Und da große Prozesse normalerweise auch oft auf die CPU kommen, bekommt man sie mit einer Forkbombe in Sekunden tot :)

Der letzte Absatz hier war Murks. Root hat 10 Prozesse für sich reserviert und kann die Bombe daher problemlos abschießen. Danke an Tron für den Hinweis.
 
Zuletzt bearbeitet:
Yamagi schrieb:
Das gleiche gilt übrigens bei Speichermangel, dort wird das Programm abgeschossen, was zuviel Speicher ziehen möchte. Anders als Linux schießt FreeBSD niemals willkürlich Prozesse ab und kann daher auch nie in die legendäre Situation geraten, dass der Kernel sich durch ein SIGKILL an init(1) selbst den Hahn zudreht.
Zum Vergrößern anklicken....
Hmm, und was tut der Kernel, wenn es zufällig der init-Prozess ist, der als letzter ein malloc() versucht? Verprobt er vorher die PID, um init nicht abzuschießen? Denn ich habe beobachtet, dass sich das System durchaus selbst abwürgt, wenn ein Kernel-Prozess zu exzessiv Speicher allokiert (ZFS lässt grüßen)...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben