Fork bomb prevention / cure
Results 1 to 6 of 6

Thread: Fork bomb prevention / cure

  1. #1
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207

    Fork bomb prevention / cure

    Dear All,

    As I'm running a shell server, as I mentioned here,

    http://www.antionline.com/showthread...177#post618177

    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)

    or

    b. Limit the total memory usage per user

    or

    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.

    Ideas appreciated

    Slarty

  2. #2
    Member
    Join Date
    Dec 2002
    Posts
    88
    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\"

  3. #3
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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.

  4. #4
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    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.

    Ammo
    Credit travels up, blame travels down -- The Boss

  5. #5
    Computer Forensics
    Join Date
    Jul 2001
    Posts
    672
    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

  6. #6
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •