Apache 不直接执行 Java 代码，恶意扫描监控应由 mod_security（Apache 层）或 Java 应用 Filter/网关（应用层）实现，需结合 URL 解码、频次统计、多维特征与日志联动。
Apache 本身不直接解析或执行 Java 代码，所以“Java 中 Apache 利用请求路径监控恶意脚本扫描行为”这个说法存在概念混淆。实际场景中，通常是 Java Web 应用（如基于 Spring Boot、Tomcat）部署在 Apache HTTP Server（作为反向代理）后面，而真正的请求路径分析和恶意扫描识别，应由后端 Java 应用或 Apache 的模块（如 mod_security）来完成。
Apache 层：用 mod_security 拦截常见扫描路径
Apache 可通过 mod_security（开源 WAF 模块）基于请求路径匹配规则，识别并拦截典型扫描行为。例如：
- /phpmyadmin/、/wp-admin/、/shell.php、/test.jsp 等非业务路径被高频访问
- 路径中含明显攻击特征：/..%2fetc%2fpasswd（目录遍历）、/index.jsp?cmd=whoami（命令注入参数）
- 同一 IP 短时间内发起大量 404 路径请求（如暴力探测 /admin.jsp、/backup.zip）
需启用 SecRule REQUEST_URI 配合正则与异常评分机制，而非简单 deny——避免误杀爬虫或合法调试请求。
Java 应用层：在 Filter 或网关中统一记录与判断
若 Apache 仅作代理，真实路径分析应在 Java 侧进行。推荐在 Servlet Filter 或 Spring Cloud Gateway 中实现：
立即学习“Java免费学习笔记（深入）”；
- 提取
HttpServletRequest.getRequestURI()和getRemoteAddr() - 维护内存或 Redis 中的 IP 访问频次窗口（如 60 秒内 > 50 次 404）
- 对高危路径关键词预编译正则：
.*\.(jsp|php|asp|sh|py)(\?.*)?$、.*/(admin|cfg|backup|git)/.* - 命中规则时记录日志、返回 403、或触发限流/封禁（如写入黑名单至 Nginx 或网关配置）
关键细节：避免误判与绕过
单纯匹配路径字符串容易被绕过或误伤。需注意：
- URL 解码后再匹配（防止
%2e%2e%2f绕过..检查） - 忽略静态资源路径（如
/static/、/assets/），避免干扰前端构建产物 - 区分内部健康检查（如
/actuator/health）与恶意探测（可结合 User-Agent、Referer、请求头完整性判断） - 不依赖单一维度，建议组合：IP + URI + 状态码 + 请求频率 + 头部异常性
补充建议：日志联动与可视化
将可疑请求路径写入结构化日志（如 JSON 格式含 client_ip、uri、status、matched_rule），接入 ELK 或 Grafana Loki：
- 实时看板统计 Top 扫描路径、Top 恶意 IP
- 设置告警：某 IP 10 分钟内触发高危规则 ≥ 5 次
- 导出数据供威胁情报平台更新规则库
不复杂但容易忽略——真正有效的监控，靠的是分层检测 + 上下文判断 + 快速反馈闭环。
