CentOS安全中设置TasksMax限制进程数防fork

在CentOS服务器上防止fork炸弹攻击，最直接有效的手段就是通过systemd的TasksMax参数来限制每个服务单元可创建的最大进程数。具体操作是编辑目标服务的unit文件，在[Service]段加入TasksMax=500（数值根据实际需求调整），然后执行systemctl daemon-reload重载配置即可生效。这个方法从系统内核层面卡住了进程膨胀的上限，比单纯修改ulimit或/etc/security/limits.conf更精准、更可控，因为它是针对每个服务单独设限，而不是全局一刀切。

fork炸弹的本质是一个进程不断调用fork()系统调用创建子进程，子进程再继续fork，短时间内耗尽系统进程表和内存资源，导致系统崩溃或无法响应。传统的ulimit -u设置虽然能限制用户级别的进程数，但它是全局性的，而且对已经以root运行的服务进程约束力有限。TasksMax是systemd的cgroup机制提供的能力，它直接作用于服务单元的进程树，能从根源上把单个服务能fork出来的进程总数锁死。

很多运维人员第一反应是改/etc/security/limits.conf，在里面加一行"* hard nproc 500"。这个方法确实能限制进程数，但有三个明显短板：第一，它是针对用户的，如果服务以root运行，root用户通常不受这些限制；第二，它无法区分不同服务，所有进程共享同一个上限；第三，修改后需要重新登录或重启服务才能生效，灵活性差。而TasksMax是systemd原生支持的参数，直接绑定到具体的service单元上，修改后daemon-reload即可，粒度细、生效快、可追溯。

另外还有一种方案是通过cgroup手动设置pids.max，但那需要直接操作/sys/fs/cgroup/pids/目录下的文件，操作繁琐且重启后容易丢失。TasksMax本质上就是systemd帮你自动管理cgroup的pids控制器，封装得更好、更稳定。对于CentOS 7及以上版本（使用systemd作为init系统），这是最推荐的方案。

第一步，找到你要限制的服务对应的unit文件。以nginx为例，执行以下命令查看文件位置：

systemctl status nginx

输出中会显示Loaded行，比如"Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)"，这就是unit文件的路径。

第二步，不要直接修改/usr/lib/systemd/system/下的文件，因为系统更新会覆盖它。正确做法是用override机制：

systemctl edit nginx

这会打开一个编辑器，自动创建/etc/systemd/system/nginx.service.d/override.conf文件。在里面写入：

[Service]
TasksMax=500

这里的500是示例值，你需要根据服务的正常运行需求来设定。比如一个Web服务器正常情况下连接数在200左右，设500就留了足够余量；如果是数据库服务，可能需要设到2000甚至更高。关键原则是：设一个比正常峰值高但远低于系统总进程上限的值。

第三步，保存退出后执行：

systemctl daemon-reload
systemctl restart nginx

这样配置就生效了。你可以通过以下命令验证TasksMax是否正确设置：

systemctl show nginx | grep TasksMax

输出应该显示TasksMax=500。

设太低会影响服务正常运行，设太高则失去防护意义。建议按以下方法确定：先在正常负载下观察进程数，用这个命令：

ps -eo pid,ppid,cmd | grep nginx | wc -l

或者更精确地统计某个服务的进程树：

systemd-cgls /system.slice/nginx.service

记录正常运行时的进程总数，然后乘以1.5到2倍作为TasksMax的值。比如正常是300个进程，就设450到600。同时要考虑突发流量的情况，Web服务器在高并发时进程数会飙升，要预留缓冲空间。

还有一个技巧：可以先设一个较高的值观察一周，然后逐步下调到稳定运行的最低安全值。这样既不影响业务，又能把防护做到位。

TasksMax实际上是systemd通过cgroup的pids控制器来实现的。当你设置TasksMax=500时，systemd会在该服务对应的cgroup目录下自动写入pids.max=500。你可以手动验证：

cat /sys/fs/cgroup/pids/system.slice/nginx.service/pids.max

应该输出500。这意味着即使进程试图fork超过500个子进程，内核会直接拒绝fork()调用，返回EAGAIN错误，进程无法继续创建子进程。这不是杀进程，而是从源头阻止新进程的诞生，非常优雅。

需要注意的是，TasksMax统计的是该cgroup下所有进程的总数，包括主进程和子进程。如果主进程本身算1个，那实际能fork的子进程数是TasksMax-1。另外，线程（thread）在Linux下也被视为轻量级进程，同样会被计入TasksMax的限制。如果你的服务使用了大量多线程，要把线程数也算进去。

单靠TasksMax不能解决所有安全问题，它只是防fork膨胀的一道关卡。建议同时做以下几件事：

第一，设置系统级的进程数上限。编辑/etc/systemd/system.conf，在[Manager]段加入：

DefaultTasksMax=4096

这是所有没有单独设置TasksMax的服务的默认上限，防止某个被遗忘的服务无限fork。

第二，限制用户级别的进程数。在/etc/security/limits.conf中添加：

* hard nproc 2048
root hard nproc 4096

这是第二道防线，防止非服务进程（比如用户手动执行的脚本）造成进程泛滥。

第三，启用systemd的OOMKill和内存限制。在override.conf中可以同时加：

[Service]
TasksMax=500
MemoryMax=2G
OOMScoreAdjust=-100

MemoryMax限制服务的最大内存使用，OOMScoreAdjust设为负值让该服务在内存紧张时优先被杀而不是系统关键进程。这样即使进程数被限制住了，也不会因为内存泄漏拖垮整个系统。

第四，部署进程监控告警。用Prometheus+node_exporter或者简单的cron脚本定期检查进程数，一旦接近TasksMax的80%就触发告警。例如：

#!/bin/bash
CURRENT=$(ps -eo pid,ppid,cmd | grep nginx | wc -l)
MAX=500
THRESHOLD=$((MAX * 80 / 100))
if [ $CURRENT -gt $THRESHOLD ]; then
    echo "WARNING: nginx process count $CURRENT exceeds threshold $THRESHOLD" | mail -s "Process Alert" admin@example.com
fi

CentOS 7使用systemd 219+，完整支持TasksMax。CentOS 8和CentOS Stream同样支持，而且systemd版本更新，功能更完善。但如果你还在用CentOS 6（SysV init），这个方法完全不适用，因为没有systemd。CentOS 6只能依赖ulimit和/etc/security/limits.conf来做类似的限制。

另外要注意，某些服务可能本身就需要大量子进程，比如PHP-FPM、Java应用服务器。对这类服务设TasksMax时要特别谨慎，建议先在测试环境验证，确认不影响正常业务后再上生产。如果设得太低导致服务频繁报错，可以通过journalctl查看：

journalctl -u nginx -f

如果看到"fork: Resource temporarily unavailable"之类的错误，说明TasksMax设低了，需要调高。

还有一个容易忽略的点：TasksMax只对通过systemd启动的服务有效。如果你手动在终端运行一个程序，或者通过cron启动的脚本不在任何service单元管理下，TasksMax管不到它。所以全局的limits.conf和DefaultTasksMax仍然是必要的补充。

曾经有一台CentOS 7服务器跑着一个自研的消息队列服务，某天突然CPU飙到100%，SSH几乎连不上。排查发现是服务进程fork了上万个子进程，把进程表撑满了。当时的解决办法是紧急kill掉父进程，但重启后又复发。后来的根治方案就是给这个服务加了TasksMax=300，同时把服务代码里的递归fork逻辑改成了进程池模式。从那以后再也没出过类似问题。这个案例说明，TasksMax不仅是防护手段，更能倒逼开发人员优化代码架构，从根本上消除fork炸弹的隐患。

总结一下核心要点：TasksMax是CentOS上防fork攻击最精准的systemd级别手段，通过systemctl edit创建override配置，设一个合理的上限值，配合全局DefaultTasksMax、limits.conf和监控告警，就能构建起多层防护。不要等出了事才补救，提前配置好，成本几乎为零，效果却非常显著。