Workerman易受Slowloris攻击原因及防御方法

Workerman 因其常驻进程模型默认不主动治理连接，缺乏内置的慢速攻击防护机制，导致在未加防护的情况下极易遭受 Slowloris 攻击——攻击者只需发送不完整的 HTTP 请求头并周期性续命，即可长期占用 Worker 进程，耗尽连接资源，引发服务拒绝；真正有效的防御并非依赖框架补丁，而是必须手动构建三层防线：在连接层限制单 IP 并发数、在协议层严格设定请求头接收超时（建议 10–15 秒）与包大小上限、在部署层强制通过 Nginx 等反向代理隔离外网直连，并采用 Redis 等外部存储实现多进程共享连接计数——安全不在配置的复杂度，而在于你是否敢于对每一个 TCP 连接的生命周期负起全责。

Workerman 本身不会“主动”受 Slowloris 攻击，但它若直接暴露 HTTP 或 WebSocket 服务（尤其是未套 Nginx/Apache、未设连接超时、未限制并发），就极易被 Slowloris 类攻击打穿——根本原因不是框架有漏洞，而是它默认不替你做应用层连接治理。

Workerman 为什么容易被 Slowloris 打中？

• Workerman 是常驻进程模型，每个连接由 PHP 进程长期持有，不依赖传统 Web 服务器的连接复用或自动清理机制
• 它默认不限制单 IP 并发连接数、不校验请求头完整性、不强制设置读超时（worker->connection_class 中的 $connection->max_package_size 和 $connection->recv_timeout 都需手动配）
• 若用 HttpServer 直接监听 0.0.0.0:80，攻击者可绕过所有反向代理防护，直连 PHP 进程，一个慢连接 = 一个 Worker 进程/线程被长期占用
• Slowloris 的核心是“发一半头、不结束、定期续命”，而 Workerman 的 HttpProtocol 解析器在没收到 \r\n\r\n 前会一直等待，不触发超时就卡死在那里

常见错误现象：

• top 显示 PHP 进程数飙升，CPU 不高但内存缓慢上涨
• netstat -ant | grep :80 | wc -l 持续 >500，且大量 ESTABLISHED 状态连接无数据收发
• 正常用户访问变慢或直接 Connection refused，日志里却看不到明显错误

怎么在 Workerman 中堵住 Slowloris 入口？

Workerman 不提供开箱即用的防慢速攻击模块，必须手动加三道防线：

• 连接层限速：在 Worker 启动前设置全局连接约束

  Worker::$pidFile = './workerman.pid';
  Worker::$logFile = './workerman.log';
  // 限制单 IP 最大连接数（防 IP 泛洪）
  $worker = new Worker('http://0.0.0.0:80');
  $worker->count = 4;
  $worker->onConnect = function($connection) {
    // 记录 IP 连接数，超限直接 close
    $ip = $connection->getRemoteIp();
    $conn_count = $_SERVER['connections'][$ip] ?? 0;
    if ($conn_count >= 10) {
        $connection->close();
        return;
    }
    $_SERVER['connections'][$ip] = $conn_count + 1;
  };
  $worker->onClose = function($connection) {
    $ip = $connection->getRemoteIp();
    $_SERVER['connections'][$ip] = max(0, ($_SERVER['connections'][$ip] ?? 1) - 1);
  };

• 协议层超时：强制给每个连接设读超时和头接收上限

  $worker->onMessage = function($connection, $request) {
    // 实际业务逻辑前，先检查是否已超时
  };
  // 更关键的是在 onWorkerStart 中设置连接级 timeout
  $worker->onWorkerStart = function($worker) {
    foreach($worker->connections as $connection) {
        // 注意：必须在连接建立后立即设，不能只靠 onConnect
        $connection->sendTimeout = 60;
        $connection->recvTimeout = 30; // 关键！30秒内没收完 header 就断
        $connection->maxPackageSize = 10240; // 防超长畸形 header
    }
  };

• 部署层隔离：绝不裸奔，必须前置反向代理

  • 用 Nginx 做第一道闸门：配置 client_header_timeout 15s、client_body_timeout 15s、keepalive_timeout 30s
  • 开启 limit_conn 按 IP 限流，例如：limit_conn addr 10
  • 把 Workerman 改为监听 127.0.0.1:2346，只允许 Nginx 转发，屏蔽外网直连

容易忽略的细节：超时值不是越大越好

• $connection->recvTimeout = 30 看似宽松，但对 Slowloris 来说，30 秒足够它发 2–3 个垃圾 header 字段并续命成功
• 真实生产环境建议设为 10～15 秒：正常浏览器发完完整 GET 请求头远快于 1 秒，超过 10 秒未完成基本可判定异常
• onClose 回调里清理计数器必须用 max(0, ... -1)，否则并发 close 可能导致负数，后续判断失效
• $_SERVER['connections'] 是进程内变量，多进程下不共享——这意味着你得用 Redis 或 pcntl_fork 外部存储做全局计数，否则单机多 Worker 时限制形同虚设

真正的防护不在框架里，而在你敢不敢把连接生命周期管到底。

今天关于《Workerman易受Slowloris攻击原因及防御方法》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！