Apache日志中识别Slowloris攻击需自定义格式记录%T（处理秒数）和%D，重点筛查同一IP在短时间内大量%T＞10秒、请求头极简（如仅GET / HTTP/1.1）的请求，并结合mod_status实时观察R状态连接异常堆积。
Apache日志里怎么看Slowloris攻击的请求模式
Slowloris不靠流量洪泛，而是用极低速率维持大量半开连接，Apache默认日志（combined格式）本身不记录连接时长或状态变化，所以单看access.log里的200或408响应码容易误判——它常伪装成合法但“卡住”的HTTP请求。
真正能暴露问题的是：同一IP在极短时间内发起大量未完成的HTTP请求头（只发GET / HTTP/1.1\r\n，不发空行、不发body），且这些请求长时间停留在reading request headers或reading request entity状态。
- 必须启用
%T（处理总秒数）和%D（微秒级处理时间）字段，否则看不出“慢” - 推荐自定义日志格式：
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %T %D" slowloris - 攻击者常复用User-Agent（如
python-requests/2.*）或留空，但更关键的是看%T值是否普遍>10秒，且%r内容极简（无Host、无Accept等头部）
用awk+sort快速筛出可疑IP和长耗时请求
别打开ELK或写Python脚本——先用Linux原生命令验证是否存在异常模式。核心逻辑是：按IP分组，统计其%T > 5秒的请求数，再按数量倒序。
假设日志路径是/var/log/apache2/access.log，执行：
awk '$12 > 5 {print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -20
这里$12对应上面slowloris格式中%T所在列（需根据实际字段位置调整）；若用combined格式，默认没有%T，结果全是0。
-
uniq -c前必须sort，否则不计数 - 攻击IP通常单分钟内出现50+条
%T > 10记录，而正常用户极少超过3秒 - 注意排除CDN或反向代理IP（如
X-Forwarded-For需在日志格式中显式记录并替换%h）
mod_status页面暴露的实时连接状态比日志更直接
Apache自带的mod_status（启用后访问/server-status?auto）能实时看到每个连接的当前状态，Slowloris连接几乎全卡在R（Sending Reply）或W（Sending Reply）以外的状态，尤其是W（Sending Reply）其实是误导——它实际常停在R（Reading Request Headers）。
- 检查
httpd.conf是否启用了ExtendedStatus On，否则看不到详细状态码 - 直接curl
curl "http://localhost/server-status?auto" | grep 'R\|W' | wc -l，若返回值远超并发设置（如MaxRequestWorkers 150），且大量是R状态，基本可确认 -
mod_status不记录历史，只能抓活口；配合netstat -anp | grep :80 | grep ESTABLISHED | wc -l对比，若ESTABLISHED连接数持续高于日志请求数，就是慢速连接占着坑不干活
为什么fail2ban配default规则防不住Slowloris
fail2ban默认的apache-badbots或apache-noscript规则依赖404/403错误码频次，而Slowloris请求往往能通过初始解析（返回200或408），甚至故意构造合法但无意义的路径（如GET /?a=1 HTTP/1.1）来绕过匹配。
- 必须自定义filter，匹配日志中
%T > 15且%r包含HTTP/1.1但不含Host:或Accept:等标准头 - action要选
iptables-multiport而非apache-nobots，后者只是返回403，对已建立的慢连接无效 - 最有效的其实是改Apache配置：
Timeout 10（降低全局超时）、LimitRequestFields 50（防头部膨胀）、启用mod_evasive或mod_security做连接速率限制
日志分析只是第一道眼线，真正拦住Slowloris得靠连接层控制——比如Timeout设太大会让防御形同虚设，但设太小又可能误杀弱网用户，这个平衡点得结合你服务的实际延迟分布调。
