limit指令通过cpuquota、memorymax、tasksmax、limitnofile等参数限制服务资源使用，控制单个服务失控后的破坏半径，防范dos风险。

使用 Limit 指令（实际为 systemd 中的资源限制机制，如 LimitCPU、MemoryLimit 等）可有效约束服务进程的资源使用，降低其被恶意利用导致系统级拒绝服务（DoS）的风险。关键不在于“完全阻止攻击”，而在于“限制单个服务失控后的破坏半径”。

明确可用的 Limit 类型及作用

systemd 通过 .service 单元文件中的 [Service] 段落支持多种资源限制指令，常见且实用的包括：

• CPUQuota=：限制服务在单位时间内最多使用 CPU 的百分比（如 CPUQuota=20% 表示最多占用 1 个逻辑 CPU 的 20%，即约 0.2 核）。比 LimitCPU 更精准，推荐优先使用。
• MemoryMax=：硬性内存上限（如 MemoryMax=512M），超出时内核会 OOM-kill 该服务进程。这是防内存耗尽型 DoS 的核心手段。
• TasksMax=：限制服务能创建的最大进程/线程数（如 TasksMax=100），防止 fork 炸弹类攻击或连接数失控。
• LimitNOFILE=：限制打开文件描述符数量（如 LimitNOFILE=1024），可缓解高并发连接耗尽系统句柄的问题。

修改服务单元文件并重载配置

以限制 nginx 服务为例：

1. 执行 sudo systemctl edit nginx.service（推荐方式，避免直接修改原始文件）；
2. 在编辑器中输入：

[Service]
CPUQuota=30%
MemoryMax=384M
TasksMax=64
LimitNOFILE=2048

保存退出后，运行 sudo systemctl daemon-reload 使配置生效；

最后重启服务：sudo systemctl restart nginx。

注意：若服务由模板实例（如 httpd@.service）启动，需对对应实例（如 httpd@site1.service）单独设置，或在模板文件中统一定义。

验证限制是否生效

限制配置后务必验证，避免误配导致服务异常：

• 查看当前应用的限制值：systemctl show nginx.service | grep -E "(CPU|Memory|Tasks|NOFILE)"；
• 实时监控资源使用：systemd-cgtop（按 Ctrl+T 切换树状视图），重点关注 /system.slice/nginx.service 所在行；
• 模拟压力测试（如用 ab 或 wrk 高并发请求），观察服务是否在达到 MemoryMax 或 TasksMax 后被自动终止（journal 日志中会出现 OOM killed 或 tasks limit exceeded 提示）。

配合其他防护形成纵深防御

仅靠 Limit 指令不能替代网络层或应用层防护：

• 前端应部署反向代理（如 Nginx、Traefik）启用连接速率限制（limit_req）、连接数限制（limit_conn）；
• 内核参数调优：如 net.core.somaxconn、net.ipv4.tcp_max_syn_backlog 防 SYN Flood；
• 启用 systemd 的 RestartSec= 和 StartLimitIntervalSec= 防止服务频繁崩溃重启（防 crash-loop DoS）；
• 敏感服务建议运行在独立 cgroup v2 层级下，并启用 ProtectSystem=strict、RestrictAddressFamilies= 等安全加固选项。