应直接查日志中..%2f、%2e%2e%2f等编码路径穿越特征，因攻击者极少用明文../；apache默认记录解码前uri，故需匹配各类编码变种并整行扫描%r字段。
怎么看 Apache 日志里可疑的路径穿越请求
直接查 ..%2F、%2e%2e%2f、..\/ 这类编码或混合写法，比肉眼扫 ../ 有效得多——因为真实攻击者几乎从不发明文点点斜杠。
- Apache 默认日志（
%r字段）记录的是解码前的原始 URI，所以 URL 编码字符会原样保留，%2e%2e%2fetc%2fpasswd就是典型信号 - 注意大小写变种：
%2E%2E%2F、%c0%ae%c0%ae%2f（UTF-8 超范围绕过）也得纳入正则匹配范围 - 用
awk或grep -E实时过滤时，别只匹配..，它可能藏在 query string 里（比如/api/file?path=..%2F..%2Fetc%2Fshadow），要整行扫描$1（即%r字段）
如何用 mod_security 快速拦截越权路径访问
靠日志告警是被动响应，真正能拦住请求的，还是得在 Apache 接入层做规则。mod_security 是最直接的选择，但默认规则集（CRS）对路径穿越覆盖不全，尤其对非标准编码和嵌套绕过。
- 手动加一条 SecRule，匹配解码后的 REQUEST_URI：
SecRule REQUEST_URI "@rx \.\./" "id:1001,deny,status:403,msg:'Path traversal detected'" - 必须开启
SecUnicodeMapFile并配置 UTF-8 映射，否则像%c0%2e这类双字节绕过会被放过 - 避免把规则放在
LocationMatch里——它只作用于匹配路径，而攻击可能出现在任意 endpoint 后面的 query 中；应放在全局Directory /或主配置中
为什么 access.log 里看不到 403/404 却仍有越权风险
因为很多路径穿越尝试根本没走到 Apache 的文件系统校验阶段——它们被后端应用（如 PHP、Node.js）自己解析并执行了，日志只记下“成功”的 200 响应，但返回内容可能是敏感文件。
- 典型表现：日志里有
"GET /download?file=../config.yaml HTTP/1.1" 200，但你根本没实现这个接口逻辑——说明后端代码做了不安全的拼接 - 此时 Apache 日志本身不报错，但你要关联后端错误日志（如 PHP 的
error_log）看是否出现file_get_contents(): open_basedir restriction这类警告，那是越权已被触发的痕迹 - 更隐蔽的是 302 跳转：请求
/avatar?id=../../.env返回 302 +Location: /files/.env，Apache 只记下两个 302，但第二个请求可能真把文件吐出来了
logrotate 和日志采样对监控效果的实际影响
线上环境日志滚动频繁、单文件过大时，实时 grep 容易漏掉窗口期外的请求；而 ELK 类方案若只采样 10%，低频探测行为基本不会被捕获。
-
logrotate配置里加copytruncate是常见做法，但它会导致正在写的日志文件被清空，tail -F可能丢失最后几秒日志——改用create+delaycompress更稳妥 - 如果用 Filebeat 收集，确保
close_inactive: 5m不设太短，否则高频小请求的日志文件可能被提前关闭，造成偏移量错乱 - 对低 QPS 服务，别依赖统计阈值（比如“1 分钟超 5 次”才告警）；单次
..%2fproc%2fself%2fmaps就该立刻触发人工核查
真正难防的不是大张旗鼓的 ../../../etc/passwd，而是夹在正常业务参数里的 img=photo.jpg&dir=%2e%2e%2flogs%2f ——这种字段语义模糊、编码随意、位置多变，得靠字段级解析，不能只盯 URI 路径部分。
