服务器突然响应迟钝、SSH连不上、甚至直接宕机，很多时候并不是流量攻击，而是一个普通用户或失控的脚本瞬间耗尽了系统资源。在Debian系统里，最典型的场景就是fork炸弹和进程/内存资源耗尽。解决这个问题的核心思路不是事后杀进程，而是通过limits.conf和cgroups做前置限制，让系统在资源被榨干前就阻断异常行为。

理解fork炸弹和资源耗尽的本质

fork炸弹本质上是一个递归创建进程的函数，它通过无限制地自我复制，瞬间填满进程表。经典的bash实现只有十几个字符：:(){ :|:& };:。这段代码定义了一个名为冒号的函数，函数体内部通过管道调用自身两次并放入后台，执行后进程数呈指数级增长。Debian默认情况下，普通用户并没有严格的进程数限制，这意味着一个用户就能让整个系统失去响应。资源耗尽则不限于进程数，还包括内存、文件句柄、CPU时间等，比如一个内存泄漏的Java应用、一个无限打开文件的后台任务，都能把系统拖垮。

使用/etc/security/limits.conf做基础限制

limits.conf是PAM模块pam_limits.so的配置文件，它能对用户或组设置各种资源上限。这是最直接、最传统的防御手段。编辑/etc/security/limits.conf，加入以下配置：

# 限制所有用户最大进程数
*               hard    nproc           4096
*               soft    nproc           2048

# 限制所有用户最大文件打开数
*               hard    nofile          65536
*               soft    nofile          1024

# 限制某个特定用户的内存锁定和地址空间
someuser        hard    memlock         65536
someuser        hard    as              4194304

这里需要特别注意几个关键点。nproc是进程数限制，hard表示硬限制，用户无法超越；soft是软限制，用户可以自行提升到hard值。nofile是文件描述符数量，很多服务类程序对此有较高要求。memlock和as分别控制锁定内存和地址空间大小，单位是KB。配置完成后，确保/etc/pam.d/common-session和/etc/pam.d/common-session-noninteractive中包含session required pam_limits.so，否则配置不会生效。用户重新登录后，用ulimit -a就能看到限制已应用。这个方案的优点是简单可靠，缺点是不够灵活，无法对CPU、IO等资源做精细化控制，而且对已经在运行的进程无效。

用cgroups v2实现动态资源管控

Debian从11版本开始默认使用cgroups v2，它统一了v1中分散的子系统，提供了更强大的资源隔离能力。cgroups的核心思想是把进程放入控制组，然后对整个组施加资源限制。对付fork炸弹，最有效的是设置进程数上限。首先确认系统已挂载cgroups v2：mount | grep cgroup2，输出应包含cgroup2 on /sys/fs/cgroup type cgroup2。

创建一个用户切片来限制所有普通用户：

# 为用户切片创建配置目录
mkdir -p /etc/systemd/system/user-.slice.d

# 创建限制配置文件
cat > /etc/systemd/system/user-.slice.d/50-limits.conf << EOF
[Slice]
TasksMax=2048
MemoryMax=4G
MemoryHigh=3G
CPUQuota=200%
IOWeight=100
EOF

# 重载systemd并重启用户切片
systemctl daemon-reload
systemctl restart user-.slice

TasksMax直接限制了该切片内所有进程的总数，这是防fork炸弹最关键的参数。MemoryMax是硬性内存上限，达到后进程会被OOM Killer处理；MemoryHigh是软性限制，达到后会触发内存回收但不会立即杀死进程。CPUQuota=200%表示最多使用2个CPU核心的计算能力，这个值可以按需调整。IOWeight控制IO调度权重，数值越小优先级越低。这些参数组合在一起，即使某个用户触发fork炸弹或内存泄漏，影响也被牢牢控制在切片内部，不会波及整个系统。

针对特定服务使用systemd资源控制

对于单个服务，直接在unit文件中配置资源限制更为精准。以Nginx为例，执行systemctl edit nginx，添加：

[Service]
TasksMax=512
MemoryMax=1G
CPUQuota=150%
LimitNOFILE=65535
LimitNPROC=512
Restart=always
RestartSec=5

LimitNOFILE和LimitNPROC是ulimit风格的硬限制，作用于该服务进程及其子进程。Restart策略也很重要，当服务因资源超限被kill后能自动恢复。对于数据库这类重IO服务，还可以加上IOReadBandwidthMax=/dev/sda 100M和IOWriteBandwidthMax=/dev/sda 100M来限制磁盘读写速率，防止一个慢查询把磁盘IO打满。systemd的资源控制实际上底层也是调用cgroups，但配置更直观，且与服务的生命周期绑定，服务停止限制自动解除。

临时应对与应急恢复手段

如果系统已经中招，首要任务是恢复控制权。fork炸弹爆发时，普通用户可能连登录都无法完成，因为shell本身就需要fork新进程。此时需要root用户通过物理终端或已建立的特权SSH连接（使用ControlMaster复用连接）登录。root的进程通常不受普通用户limits限制，但如果root也被卡住，可以尝试使用内核参数sysctl kernel.pid_max临时调低最大进程ID，但这属于非常手段。更实用的做法是提前配置好Magic SysRq键：echo 1 > /proc/sys/kernel/sysrq，紧急时通过Alt+SysRq+f手动调用OOM Killer，或者Alt+SysRq+e向除init外的所有进程发送SIGTERM。事后分析日志/var/log/syslog和journalctl -k可以找到OOM Killer的详细记录，确认是哪个进程、哪个cgroup触发了限制。

进阶：使用systemd-logind自动分配资源

Debian的systemd-logind本身就会为每个登录用户创建cgroup，并且可以通过/etc/systemd/logind.conf进行全局调控。修改以下参数：

UserTasksMax=2048
MemoryHigh=4G
MemoryMax=5G

这比手动配置user-.slice更加简洁，且对所有通过logind管理的会话（SSH、TTY、图形界面）都生效。配置后执行systemctl restart systemd-logind，新登录的用户就会自动受到限制。这种方式适合桌面环境和多用户开发服务器，能有效防止单个用户无意或恶意地耗尽资源。

监控与告警不可或缺

限制只是防御，监控才能提前发现问题。安装prometheus-node-exporter并配合Grafana，可以实时查看每个cgroup的CPU、内存、进程数变化。重点关注node_cgroup_processes和node_cgroup_memory_current_bytes这两个指标。设置告警规则，当某个用户切片的进程数在短时间内暴涨或内存使用率超过80%时，自动发送通知。另外，systemd-cgtop命令能实时显示各cgroup的资源占用，类似top但按控制组聚合，排查问题时非常直观。

把limits.conf的静态限制、cgroups的动态隔离、systemd的服务级控制以及完善的监控结合起来，Debian系统就具备了从预防到发现再到快速恢复的完整能力。资源限制不是一劳永逸的配置，需要根据实际业务负载持续调优，但一旦建立好这套机制，fork炸弹和资源耗尽类的攻击就会从致命威胁降级为可管理的异常事件。