April 15th, 2003, 06:50 PM
Fork bomb prevention / cure
As I'm running a shell server, as I mentioned here,
Some kind soul (you know who you are I assume) decided it would be really fun to run fork bombs.
I am running Linux, 2.5.67 at the moment and I'm not averse to the idea of patching the kernel.
Do you know a way I can
a. Limit the number of processes per user (like you can in Irix and is setup by default in some commercial Unix)
b. Limit the total memory usage per user
c. Some other solution which will prevent fork bombs from hanging the machine, for instance reserve a number of processes or memory for root.
I can usually kill them off but it does effectively DoS the system by making everything very slow until I do.
April 15th, 2003, 10:22 PM
Slarty, you may use ulimit. (i think it's a shell built-in .
ulimit -u 20
ulimit -n 50
Would allow the user to create 20 processes and open 50 files. There are plenty of options, check man ulimit or bash documentation. I don't know all of them :/
Then, once you have built up your mind, put it on /etc/bashrc, after checking who is logged (if user !=root, set limits). Have fun.
Found in a diary:
\".... and yes, since i am a l337 hax0r, i am also using vi to write this. ^[[D^[[B^ exit ^X^C quit :x :wq dang it :w:w:w :x ^C^C^Z^D\"
April 15th, 2003, 10:52 PM
Yes, thankyou for your reply. I had basically already figured it out by the time you posted that, sorry
As far as I can tell, one way is to put ulimit statements in /etc/profile, that way they always get executed when people log in.
However in ssh there are ways to log in without executing /etc/profile, therefore people can bypass it.
I can see that under Debian, Redhat etc, where you have PAM, you can use pam_limit which will enforce these limits on all sessions, which is good.
Trouble is, I'm running Slackware at the moment. Still, I can change.
April 16th, 2003, 05:57 AM
Hehe, one nasty thing to do with fork bombs (kids don't do it!) would be to intercept SIGQUIT and fork 2 more processes before dying... so the sysadmin is actually doing more harm than good (unless he's kill -9 'ing from start...)
On the other side, dunno for linux, but in openbsd you can configure maxproc in login.conf for whichever login class you want to restrict.
Credit travels up, blame travels down -- The Boss
April 16th, 2003, 01:45 PM
pam limits slarty....use pam limits. You can all but destroy someones ability to use a forkbomb.
I will go into detail later if you like, if I have time today..if not, drop by irc sometime and I'll fill you in.
Antionline in a nutshell
\"You\'re putting the fate of the world in the hands of a bunch of idiots I wouldn\'t trust with a potato gun\"
Trust your Technolust
April 16th, 2003, 01:57 PM
Hogfly, ammo, thankyou.
I have already discovered pam_limits. While it was not obvious immediately (for instance googling for "Fork bomb" and "Linux" gives you lots of src code for fork bombs and the like).
pam_limits is a godsend, it does lots of good stuff.
As I'm running Slackware on my shell server which doesn't have PAM, I had build PAM, and rebuild sshd to use it (having uninstalled the old one).
Now users get strict process limits, and if they try to create a fork bomb it still works, but it no longer consumes all resources. This is good.