apache日志本身不能拦截请求,需结合mod_security规则实现“发现+阻断”闭环;重点覆盖编码变种(如%2e%2e%2f、..%2f、%c0%ae%c0%ae%2f)而非明文../,规则须全局配置并启用unicode解码,确保phase:2阶段精准拦截。

直接在 Apache 配置中启用日志规则本身不能拦截请求,真正能拦截的是 mod_security 规则,配合对 access_log 的精准监控才能实现“发现+阻断”闭环。生产环境必须兼顾有效性与低误杀,重点不是匹配明文 ../,而是覆盖攻击者实际使用的编码变种和绕过手法。
一、日志层:用正则精准捕获真实攻击载荷
Apache 默认的 %r 字段记录的是解码前原始 URI,所以攻击者发的 %2e%2e%2fetc%2fpasswd 会原样留存——这正是检测关键。别扫 ../,它几乎不会出现在真实日志里。
- 必须覆盖的编码形式:
..%2f、%2e%2e%2f、../、%2e%2e\(Windows)、%c0%ae%c0%ae%2f(UTF-8 超范围绕过) - 命令行实时筛查示例(适配默认 combined 日志格式):
awk '$0 ~ /..%2[fF]|%2e%2e%2[fF]|%2e%2e\\|..[\/]|%c0%ae%c0%ae%2[fF]/ {print $0}' /var/log/apache2/access.log - 注意 query string 里的穿越:如
/api/download?file=..%2f..%2fetc%2fshadow,必须整行扫描$0,不能只切字段
二、拦截层:mod_security 规则要放在全局位置并启用 Unicode 解码
仅靠日志告警是马后炮。拦截必须发生在请求进入应用前,且规则必须作用于解码后的路径,否则绕过极容易。
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 规则必须写在主配置或
<directory></directory>块中,不能 放在<locationmatch></locationmatch>里——后者不覆盖 query 参数 - 启用 Unicode 映射,防止双字节绕过:
SecUnicodeMapFile unicode.mapping 20127
并确保unicode.mapping文件存在且含 UTF-8 映射 - 推荐规则(高置信度,低误杀):
SecRule REQUEST_URI "@rx ../" "id:1001,phase:2,deny,status:403,msg:'Blocked path traversal attempt'"
三、生产环境避坑要点
很多团队规则写了却拦不住,问题常出在细节配置上。
- 不要依赖
mod_rewrite重写拦截:它发生在更晚阶段,部分路径穿越已触发后端读取 - 避免把规则绑在特定路径(如
/files/):攻击可能打在/api/xxx?path=...上,全局生效才可靠 - 检查日志轮转是否影响监控:用
copytruncate会导致tail -F丢最后几秒;改用create+delaycompress - 低 QPS 服务慎用采样:ELK 若只采样 10%,单次探测请求大概率被过滤掉,应全量接入或改用 Filebeat 的
close_inactive: 5m合理设置
四、验证是否真起作用
测试不是看能不能 curl 出 /etc/passwd,而是确认两个信号同时出现:
- access_log 中出现类似
GET /icons/.%2e/%2e%2e/etc/passwd HTTP/1.1的记录 - 该请求返回状态码为
403,且 error_log 中无文件系统访问失败日志(说明没走到后端) - 用
curl -I确认响应头含X-Content-Type-Options: nosniff等防御头,表明 mod_security 已加载









