最有效、最易落地的防fork炸弹手段是限制单个用户最大进程数,核心为ulimit -u控制nproc,需配齐软硬限制并确保PAM加载pam_limits.so模块生效。

直接限制单个用户最大进程数,是防 fork 炸弹最有效、最易落地的手段。核心就一条:ulimit -u 控制 nproc,软硬限制必须配齐,且需确保 PAM 加载生效。
ulimit -u 临时限制只对当前 shell 会话生效
运行 ulimit -u 100 后,该终端里任何新进程(包括子 shell、脚本、:(){:|:&};:)一旦超过 100 个,fork() 就会失败并返回 EAGAIN,fork 炸弹当场卡死。但这个设置不会继承到新登录会话,也不影响其他终端或 SSH 连接。
- 验证是否生效:执行
ulimit -u查看当前值;再跑seq 1 150 | xargs -P 150 sleep 0.1 &,会报Resource temporarily unavailable - 注意:root 用户默认不受普通用户的
ulimit限制影响,sudo -u otheruser ulimit -u 50才能模拟目标用户环境 - 别依赖它做长期防护——登出重登就失效,仅适合测试或紧急干预
/etc/security/limits.conf 必须配 soft + hard nproc
要让限制持久化并覆盖所有登录方式(SSH、GUI、su 切换),必须写进 /etc/security/limits.conf,且 soft 和 hard 都得设。只写 soft 没用,因为用户可自行调高(只要不超 hard);只写 hard 则初始值仍是系统默认(通常是 1024 或更高),起不到压制作用。
Linux 安全审计工具,检查 SSH 配置、开放/监听端口、防火墙规则(ufw/iptables/nftables)、失败登录尝试、sudoers 权限...
- 正确写法示例:
alice soft nproc 200和alice hard nproc 200(两行) - 对组生效:用
@developers soft nproc 300,但注意 root 不受组限制 - 通配符
*要慎用——* soft nproc 512会影响所有非 root 用户,包括系统服务账户,可能引发 cron、systemd-user 等异常 - 改完必须重新登录才生效;
su - alice可验证,然后ulimit -u确认数值
PAM 模块 session required pam_limits.so 是前提
没有这行,limits.conf 就是废纸。几乎所有主流发行版默认已启用,但定制系统或容器镜像常被删掉。
- 检查命令:
grep pam_limits.so /etc/pam.d/{login,sshd,su,system-auth} - 缺失时,在
/etc/pam.d/sshd(SSH 登录)或/etc/pam.d/system-auth(通用)中添加:session required pam_limits.so - 注意路径:CentOS/RHEL 用
/lib64/security/pam_limits.so,Debian/Ubuntu 用/lib/x86_64-linux-gnu/security/pam_limits.so,写错路径会导致 PAM 加载失败且无明显报错 - 修改后无需重启 sshd,新连接即生效;旧连接仍按原限制运行
容器环境要用 --pids-limit,ulimit 不起作用
Docker 或 Podman 容器里,ulimit 设置会被 cgroup v2 的 pids.max 覆盖。即使你在容器内执行 ulimit -u 1000,只要宿主机用 --pids-limit=100 启动,实际 fork 上限就是 100。
- 启动容器时加参数:
docker run --pids-limit=100 ubuntu:24.04 - 对应 cgroup 文件是
/sys/fs/cgroup/pids/.../pids.max,值为100表示最多 100 个进程(含线程) - 容器内
ulimit -u显示的仍是宿主机传入的默认值(如 1048576),别被它骗了——真正起作用的是pids.max - Kubernetes 中通过
securityContext.pidsLimit设置,低于 1.20 版本不支持,需确认集群版本
真正容易被忽略的点是:限制值不能拍脑袋定。设太低(比如 nproc 20)会让正常用户连 tmux、多个 vim 实例都打不开;设太高(比如 10000)又失去防护意义。建议从 ps -U $USER --no-headers | wc -l 统计日常峰值,再上浮 30%~50% 作为 hard 限制。另外,root 始终豁免,所以管理账户安全本身不能只靠这一层。

















