Fork bombs are malicious code snippets that rapidly create new processes, consuming system resources and potentially crashing the system. Here’s how ulimit in bash can help prevent them:
1. Check your current limit:
Run ulimit -u to see the current maximum number of processes allowed per user. A high limit like 128,038 makes your system vulnerable.
╭──(john㉿DESKTOP-PF01IEE)───╮ ╰───────────────────────────╾╯(~)-(172.20.81.236)┋ ulimit -u 5000 |
2. Set a temporary limit:
Use ulimit -S -u <number> to temporarily set a lower limit for just your current session. For example, ulimit -S -u 5000 set the limit to 5000 processes.
╭──(john㉿DESKTOP-PF01IEE)───╮ ╰───────────────────────────╾╯(~)-(172.20.81.236)┋ ulimit -S -u 5000 |
3. Set a permanent limit for your user:
Edit the /etc/security/limits.conf file (requires root access). Add a line like:
<username> hard nproc <number>Here is an example.
╭──(john㉿DESKTOP-PF01IEE)───╮ ╰───────────────────────────╾╯(~)-(172.20.81.236)┋ cat /etc/security/limits.conf # /etc/security/limits.conf # #This file sets the resource limits for the users logged in via PAM. #It does not affect resource limits of the system services. # #Also note that configuration files in /etc/security/limits.d directory, #which are read in alphabetical order, override the settings in this #file in case the domain is the same or more specific. #That means, for example, that setting a limit for wildcard domain here #can be overridden with a wildcard setting in a config file in the #subdirectory, but a user specific setting here can be overridden only #with a user specific setting in the subdirectory. # #Each line describes a limit for a user in the form: # #<domain> <type> <item> <value> # #Where: #<domain> can be: # - a 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 # - NOTE: group and wildcard limits are not applied to root. # To apply a limit to the root user, <domain> must be # the literal username root. # #<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 file descriptors # - 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> <type> <item> <value> # #* soft core 0 #root hard core 100000 #* hard rss 10000 #@student hard nproc 20 #@faculty soft nproc 20 #@faculty hard nproc 50 #ftp hard nproc 0 #ftp - chroot /ftp #@student - maxlogins 4 john hard nproc 5000 # End of file |
Replace <username> with your actual username and <number> with a suitable limit. Consider your typical workload and multiply the needed processes by 2 to be conservative.
4. Set a system-wide limit (caution):
This is usually not recommended as it affects all users and could hinder legitimate activities. If necessary, add a similar line * instead of a username, but proceed with caution.
Important notes:
- Root users are not affected by
ulimit. They need other measures like system-wide resource limits or controlling root access itself. - Choose a sensible limit. Too low will cause issues with regular use, while too high leaves room for fork bombs. Consider your typical processes and add some buffer.
ulimitonly sets a soft limit. Processes can exceed it, but eventually, system resource limits will stop them. Hard limits that are defined in/etc/security/limits.confare stricter.
Remember, preventing fork bombs is just one part of system security. Be cautious about running untrusted scripts or code, and keep your system updated with security patches.