cgroups本身不识别非法进程，需结合监控检测与手动干预：先定义可疑特征（如CPU/内存异常占用、路径异常），再通过cgroups v2新建隔离组（如/quarantine），设memory.max=50M、cpu.max="100000 100000"，最后将PID写入cgroup.procs即时生效。
Control Groups（cgroups）本身不识别“非法进程”——它只按进程ID或启动方式施加资源约束。所谓“限制非法进程”，实际是指：对未授权、异常高耗、或来源不明的进程，通过主动监控+快速干预，将其纳入cgroups管控。这需要结合检测机制与cgroups操作，而非cgroups自动判断合法性。
识别可疑进程是前提
Linux没有内置“非法进程”标签，需人工或脚本定义可疑特征：
- CPU或内存持续占用超90%且无业务依据（可用
top -b -n1 | head -20筛查） - 属于非标准用户（如
nobody、daemon）但启动了网络服务或大量子进程 - 可执行文件路径异常（如
/tmp/.X11-unix/、/dev/shm/下运行的二进制） - 无对应systemd服务单元、也未在
ps auxf中显示清晰父进程链
用cgroups v2快速隔离（推荐方式）
现代发行版（Ubuntu 22.04+、RHEL 8+、Arch等）默认启用cgroups v2，统一挂载在/sys/fs/cgroup，操作更安全、无竞态：
- 新建隔离组：
sudo mkdir /sys/fs/cgroup/quarantine - 设内存硬上限（防OOM扩散）：
echo 50M | sudo tee /sys/fs/cgroup/quarantine/memory.max - 限CPU使用率不超过1核：
echo "100000 100000" | sudo tee /sys/fs/cgroup/quarantine/cpu.max（即100%配额） - 将进程PID移入：
echo $PID | sudo tee /sys/fs/cgroup/quarantine/cgroup.procs
一旦写入cgroup.procs，内核立即生效，进程内存超50MB会被OOM killer终止，CPU时间被严格节流。
配合systemd实现持久化防护
若该进程由服务启动（如被篡改的sshd、crond子进程），可利用systemd的自动分组能力：
- 编辑
/etc/systemd/system.conf，启用资源默认限制：DefaultMemoryMax=512MDefaultCPUQuota=50% - 为可疑服务单元（如
sshd@*.service）单独加锁：
在/etc/systemd/system/sshd@.service.d/limit.conf中写入：[Service]MemoryMax=256MCPUQuota=30% - 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart sshd
这样即使攻击者通过合法服务派生恶意子进程，也会继承父单元的资源上限。
补充建议：避免误杀与留痕
cgroups是强力工具，但直接杀进程可能丢失取证线索：
- 先用
cgexec -g memory:quarantine --preserve-env strace -f -o /tmp/quarantine.trace /proc/$PID/exe记录其行为 - 限制后检查
/sys/fs/cgroup/quarantine/memory.current和memory.events，确认是否触发OOM - 保留
/proc/$PID/{cmdline,stack,environ}快照，用于后续分析 - 不要依赖
ulimit或setrlimit()——它们仅作用于单进程，无法约束子进程树
本质上，cgroups不是入侵检测系统，而是执行层的“资源闸门”。真正管住非法进程，靠的是把检测逻辑（如auditd规则、fail2ban联动、自定义脚本巡检）和cgroups控制流串起来。
