1. 项目概述：为什么我们需要一个自动化的漏洞监控平台？

还在为每天手动启动扫描器、导入目标、等待结果、再手动整理报告而头疼吗？对于安全工程师、渗透测试人员，甚至是负责业务安全的开发同学来说，这种重复性劳动不仅效率低下，更关键的是无法实现“持续监控”。一个刚上线的接口、一次不经意的配置变更，都可能引入新的安全风险，而手动扫描的滞后性让我们往往在漏洞被利用后才后知后觉。

这个项目的核心，就是利用 xray 的被动代理模式，搭建一个7x24小时不间断运行的 Web 漏洞监控平台。它的工作原理非常巧妙：你只需要像平常一样，通过浏览器或者自动化测试工具去访问你的 Web 应用，所有的 HTTP/HTTPS 流量都会经过这个代理。xray 在后台默默地分析这些流经的请求和响应，实时进行漏洞检测。一旦发现潜在风险，比如一个未经验证的重定向、一个可能存在 SQL 注入的参数，它会立刻告警并生成详细的报告。

想象一下这个场景：开发团队正在进行每日的冒烟测试，他们的所有测试流量都经过了你搭建的代理。测试进行的同时，安全检测也在同步进行。测试还没结束，一份包含所有可疑风险点的报告已经生成。这不仅仅是效率的提升，更是将安全能力左移，无缝嵌入到研发流程中的关键一步。告别手动发包，意味着告别被动响应，转向主动、持续的监控。接下来，我将带你从零开始，在5分钟内核心理清思路，并用详实的步骤搭建起这个平台。

2. 核心思路与架构设计：被动代理如何成为“隐形哨兵”？

在动手之前，我们必须彻底理解“被动代理模式”这个核心概念，以及整个平台的运作架构。这决定了我们搭建的是一台“智能监控设备”，而不是一个简单的“扫描器”。

2.1 主动扫描 vs. 被动代理：理念的差异

传统的漏洞扫描（主动扫描）就像派出一支侦察部队，主动对目标阵地（Web应用）进行全方位的、系统性的探测。它会根据预设的字典和规则，向目标发送大量精心构造的请求包。这种方式优点是全面、系统，但缺点同样明显：噪音大（可能触发WAF或风控）、无法覆盖需要特定上下文或登录状态的请求、并且是“一次性”的。

而被动代理模式，则是在你（或你的测试流量）通往目标的“必经之路”上，安装了一个“隐形哨兵”。这个哨兵（xray）不主动发出任何请求，它只做两件事：1.监听所有流经的 HTTP/HTTPS 流量；2.分析这些流量中的请求和响应数据。它的检测完全依赖于实际发生的业务交互。因此，它的检测结果具有极高的相关性：凡是能被检测到的漏洞，其请求必定是应用本身能够正常处理并响应的。这极大地减少了误报，并且能覆盖到那些需要复杂交互流程（如多步登录、购物车）才能触发的漏洞点。

2.2 平台核心架构拆解

一个完整的、可用的监控平台，通常由以下几个核心组件构成：

1. 代理枢纽（xray）：这是核心引擎。运行在被动代理模式下，开启一个本地端口（如 7777），等待流量接入。它负责流量转发、漏洞检测引擎调度、规则匹配和初步的日志记录。
2. 流量来源：这是漏洞检测的“素材”来源。可以是：
   • 人工测试流量：安全测试人员或开发人员将自己的浏览器代理设置为 xray 的地址，其所有上网行为（针对目标域）都将被检测。
   • 自动化测试流量：在 CI/CD 流水线中，Selenium、Playwright 等UI自动化测试工具产生的流量，通过代理指向 xray。
   • 爬虫流量：使用 xray 自带的爬虫（rad）或其它爬虫工具，将代理设置为 xray，对目标进行爬取，同时进行安全检测。
3. 报告与告警系统：这是平台的“输出终端”。xray 支持多种报告格式，如 HTML、JSON。我们需要一个机制来持久化存储这些报告，并在发现高危漏洞时及时通知负责人（如通过钉钉、企业微信、邮件或Webhook集成到内部告警平台）。
4. 配置与管理层：包括 xray 自身的配置文件（定义检测规则、排除误报域名、设置反连平台等），以及可能需要的脚本，用于平台的启动、停止和状态监控。

在这个项目中，我们将聚焦最核心、最轻量的组合：xray（代理+检测引擎） + 浏览器（人工测试流量） + 本地文件报告。先让核心流程跑通，后续你可以在此基础上，轻松地接入自动化测试流水线或搭建更复杂的分布式监控网络。

注意：被动代理模式检测的“深度”和“广度”完全依赖于流经它的流量。如果某个功能点或接口从未被访问，那么它永远不会被检测到。因此，确保测试流量的覆盖率是发挥该平台价值的关键。

3. 五分钟快速部署：从下载到运行

理论清晰后，我们进入实战环节。以下步骤假设你在一个 Linux/macOS 终端或 Windows 的 PowerShell/CMD 环境下操作。

3.1 第一步：获取 xray 可执行文件

xray 是开源的，你可以从其官方 GitHub 仓库下载最新版本。为了速度，我们通常使用国内镜像或社区提供的下载链接。

# 以 Linux 64位系统为例，下载并解压 wget https://download.xray.cool/xray/linux_amd64/xray_linux_amd64.zip unzip xray_linux_amd64.zip # 解压后你会得到几个文件，最重要的是 `xray_linux_amd64` 这个二进制文件 # 赋予它可执行权限 chmod +x xray_linux_amd64 # 为了使用方便，可以将其移动到系统路径或重命名 sudo mv xray_linux_amd64 /usr/local/bin/xray

对于 Windows 用户，过程类似：下载xray_windows_amd64.zip，解压，你会得到一个xray_windows_amd64.exe文件。你可以把它放在一个固定的目录，并将该目录添加到系统的 PATH 环境变量中，或者直接在文件所在目录打开命令行操作。

3.2 第二步：生成基础配置文件

xray 的强大之处在于其高度可配置性。首次运行前，我们需要生成一个默认配置文件。

# 运行以下命令，会在当前目录生成一个 `config.yaml` 文件 xray gencode

这个config.yaml文件就是 xray 的大脑。里面包含了所有插件的启用状态、检测规则强度、反连平台配置、输出格式等。对于初次搭建监控平台，我们主要关注几个关键部分：

• plugins: 这里列出了所有漏洞检测插件。默认是全部开启的。如果你只想针对性地检测某类漏洞（例如只检测 SQL 注入和 XSS），可以将其它插件设为false，这能提升扫描速度和减少干扰。
• mitm： 被动代理（MITM）相关的配置。其中listen定义了代理服务器监听的地址和端口，默认为127.0.0.1:7777。你可以根据需要修改，例如改成0.0.0.0:7777以允许同一网络内其他机器将流量转发过来。
• reverse： 反连平台配置。这是检测一些“盲”类型漏洞（如 Blind SQLi、SSRF、反序列化）的关键。它需要一个公网可访问的服务器来接收目标应用的回连请求。对于内网测试或初次体验，可以暂时不配置，但这会使得相关漏洞的检测能力大打折扣。
• http： HTTP 请求相关的配置，如代理链、超时时间、请求头等。

3.3 第三步：启动被动代理服务

有了配置文件，启动服务就一行命令：

# 默认使用当前目录下的 config.yaml xray webscan --listen 127.0.0.1:7777 --html-output report.html

让我们拆解这个命令：

• webscan： 指定进行 Web 漏洞扫描。
• --listen 127.0.0.1:7777： 明确指定以被动代理模式运行，并监听本机 7777 端口。这个参数会覆盖配置文件中的mitm.listen设置。
• --html-output report.html： 指定将漏洞报告输出为 HTML 格式，文件名为report.html。当扫描结束时，这个文件会包含所有漏洞的详细信息。你也可以使用--json-output report.json输出 JSON 格式，便于后续用脚本处理。

执行命令后，如果看到类似下面的输出，说明代理服务已经成功启动并正在等待流量：

[INFO] 2024-05-15 10:00:00 [+] starting web server on http://127.0.0.1:7777 [INFO] 2024-05-15 10:00:00 [+] starting web server on http://[::1]:7777 [INFO] 2024-05-15 10:00:00 [+] starting MITM server on 127.0.0.1:7777

此时，你的 Web 漏洞监控平台的核心——代理检测引擎——已经处于运行状态了！它就像一个已经架设好的摄像头，只等“车辆”（HTTP流量）通过。

3.4 第四步：配置浏览器流量导向

现在，我们需要让流量“流经”这个摄像头。以 Chrome 浏览器为例（Firefox、Edge 等设置类似）：

1. 安装浏览器代理管理插件，如SwitchyOmega。这是最灵活的方式。
2. 在 SwitchyOmega 中新建一个情景模式，命名为 “Xray Proxy”。
3. 代理协议选择HTTP，代理服务器填写127.0.0.1，端口填写7777。
4. 保存并应用这个情景模式。

或者，你也可以直接设置系统代理（不推荐，因为会影响所有网络流量）：

• Windows： 设置 -> 网络和 Internet -> 代理 -> 手动设置代理 -> 打开，地址填127.0.0.1，端口填7777。
• macOS： 系统设置 -> 网络 -> 高级 -> 代理 -> 勾选 Web 代理 (HTTP) 和安全 Web 代理 (HTTPS)，地址填127.0.0.1，端口填7777。

实操心得：强烈推荐使用 SwitchyOmega 这类插件。你可以配置“自动切换”规则，例如，仅对*.yourcompany.com的域名流量走 xray 代理，其他日常网站（如谷歌、视频站）直连。这样既能进行安全测试，又不影响正常上网体验。

3.5 第五步：开始测试并查看报告

完成代理设置后，用浏览器访问你想要测试的 Web 应用（例如公司内部的管理后台http://admin.internal.com）。

此时，观察运行 xray 的命令行窗口，你会看到滚动的日志，显示它正在接收、转发并分析请求：

[INFO] 2024-05-15 10:00:05 [+] received request: GET /login HTTP/1.1 [INFO] 2024-05-15 10:00:05 [+] sending request to target... [INFO] 2024-05-15 10:00:05 [+] received response, starting detection...

在你进行登录、浏览页面、提交表单等操作的过程中，xray 会实时进行分析。如果发现潜在的漏洞，它会立即在命令行中打印出告警信息，例如：

[WARNING] 2024-05-15 10:00:10 [SQL Injection] [Medium] http://admin.internal.com/user?id=1' (parameter: id)

当你完成一轮测试，在命令行中按下Ctrl+C终止 xray 进程。此时，它会将本次会话中检测到的所有漏洞汇总，并生成你在启动命令中指定的report.html文件。

用浏览器打开这个report.html，你会看到一个结构清晰、内容详尽的漏洞报告，包括漏洞类型、风险等级、受影响URL、请求/响应详情以及修复建议。至此，一个最基础的、可用的 Web 漏洞监控平台已经搭建完成。

4. 进阶配置与优化：打造企业级监控能力

基础的搭建只是第一步。要让这个平台真正成为团队信赖的“安全哨兵”，还需要进行一系列进阶配置和优化，使其更稳定、更智能、更适合集成到自动化流程中。

4.1 配置深度解析：让检测引擎更聪明

默认的config.yaml已经很强大了，但针对企业内网环境，我们通常需要做一些定制化调整以减少误报和无关噪音。

1. 排除特定域名或路径：在测试时，我们可能不想扫描第三方服务（如 CDN、统计代码）或已知的误报源。在config.yaml中找到mitm下的restriction部分，或直接使用passive插件下的excludes配置。

   # 示例：排除对 example.com 和所有图片、样式文件的扫描 plugin: passivescan excludes: - ".*\.example\.com.*" - ".*\.(jpg|png|gif|css|js)$"

   这个配置能显著提升扫描效率，避免引擎在无关的静态资源上浪费算力。

2. 调整插件敏感度：某些插件（如dirscan目录扫描、phantasm幻影攻击）可能产生较多扫描请求或误报。你可以在对应插件的配置中调整detection的强度（如low,medium,high），或者关闭一些攻击性较强的检测模块。

3. 配置反连平台（Reverse）：这是提升检测深度的关键。你需要一台具有公网 IP 的服务器（云服务器即可）。

   • 在服务器上运行xray reverse命令，它会生成一个配置文件，里面包含了服务端监听的地址和端口。
   • 将配置文件中的token和http监听地址（如http://your-server-ip:8080）填入你本地config.yaml的reverse部分。
   • 这样，当 xray 检测需要目标服务器回连的漏洞时，它会使用这个反连地址作为 payload 的一部分。一旦漏洞存在，目标服务器会尝试连接你的反连平台，xray 从而确认漏洞。

4.2 报告与告警集成：从静态文件到实时通知

本地 HTML 报告适合人工查看，但对于自动化监控，我们需要更结构化的数据和实时告警。

1. JSON 报告与持续集成：使用--json-output vulns.json参数。JSON 格式易于被脚本解析。你可以写一个简单的 Python 脚本，在每次扫描结束后读取vulns.json，提取高危漏洞，并将其结果集成到 Jenkins、GitLab CI 或 GitHub Actions 的流水线报告中，实现“安全门禁”。

2. Webhook 实时告警：xray 社区版暂不支持直接的 Webhook，但我们可以通过一个“中间件”脚本实现。思路是：xray 启动时同时启动一个简单的 HTTP 服务（可以用 Python Flask 快速编写），这个服务监听一个端口。然后修改 xray 配置，使用--html-output http://localhost:5000/report这样的方式？不，这不行。更实际的方法是：

   • 编写一个脚本，定时（比如每10秒）检查 xray 的日志文件或解析其内存中的漏洞队列（这需要一定开发能力）。
   • 或者，使用 xray 的--log-file参数将日志输出到文件，然后用tail -f命令配合grep监控关键字（如[HIGH]、[SQL Injection]），一旦匹配到，就触发一个调用 Webhook 的脚本。
   • 一个更优雅但需要定制的方式是，修改 xray 的源码，在漏洞发现的回调函数里加入调用 Webhook 的逻辑，然后重新编译。这对于普通用户门槛较高。

   一个折中的、可操作的方案是使用文件监控。让 xray 输出 JSON 报告到一个固定文件，然后使用像inotifywait(Linux) 或watchdog(Python库) 这样的工具监控这个文件的变化。一旦文件被更新（即扫描结束或发现新漏洞），监控脚本就立即读取 JSON 文件，解析漏洞，并通过 HTTP 请求将告警信息发送到钉钉、企业微信或自建的告警平台。

4.3 部署模式演进：从单机到分布式

• 后台持久化运行：在服务器上，我们不会一直开着终端运行 xray。可以使用nohup或systemd将其配置为系统服务。

  # 使用 nohup 简单后台运行 nohup xray webscan --listen 0.0.0.0:7777 --html-output /var/log/xray/report_$(date +%Y%m%d_%H%M%S).html > /var/log/xray/xray.log 2>&1 & # 使用 systemd (更专业) # 创建服务文件 /etc/systemd/system/xray.service

  systemd服务文件示例：

  [Unit] Description=Xray Passive Proxy Service After=network.target [Service] Type=simple User=nobody ExecStart=/usr/local/bin/xray webscan --listen 0.0.0.0:7777 --html-output /opt/xray/reports/report.html Restart=on-failure RestartSec=10s [Install] WantedBy=multi-user.target

  然后使用sudo systemctl start xray和sudo systemctl enable xray来启动和设置开机自启。

• 多目标与负载均衡：当需要监控多个不同业务线或大型应用时，单一代理可能成为瓶颈。可以考虑：

  1. 多实例部署：为不同业务团队部署独立的 xray 实例和代理端口。
  2. 上游代理池：使用 Nginx 或 HAProxy 作为流量入口，根据请求的域名或路径，将流量转发到后面对应的不同 xray 实例。这实现了简单的负载均衡和路由。

• 与 Rad (浏览器爬虫) 联动：这是实现“无人值守”自动化扫描的利器。Rad 是长亭开发的智能浏览器爬虫，可以模拟真人操作点击页面。你可以让 Rad 爬取目标网站，同时将其代理设置为 xray。

  # 在一个终端启动 xray 代理 xray webscan --listen 127.0.0.1:7777 --html-output rad_scan.html # 在另一个终端，使用 rad 爬虫，并指定代理为 xray rad -t https://target.com -http-proxy 127.0.0.1:7777

  Rad 会自动化浏览网站，产生的所有流量都经过 xray 检测，非常适合对公开业务进行定期的自动化安全巡检。

5. 常见问题与排查实录

在实际搭建和运行过程中，你肯定会遇到各种各样的问题。这里我记录了几个最典型的情况和解决方案，希望能帮你快速排雷。

5.1 代理设置成功，但 xray 无任何日志输出

• 症状：浏览器已设置代理为127.0.0.1:7777，访问网站正常，但运行 xray 的终端没有任何请求日志。
• 排查思路：
  1. 检查 xray 是否真的在监听端口：运行netstat -an | grep 7777(Linux/macOS) 或netstat -ano | findstr 7777(Windows)。如果看不到LISTEN状态，说明 xray 没启动成功或端口被占用。
  2. 检查浏览器代理插件规则：确认代理规则是否正确应用。在 SwitchyOmega 中，检查当前激活的情景模式是否正确，以及规则是否匹配你访问的域名。可以尝试先设置为“全局代理”模式测试。
  3. 检查系统防火墙：特别是 Windows Defender 防火墙或 Linux 的iptables/ufw，可能会阻止本地回环地址（127.0.0.1）的代理通信。尝试暂时关闭防火墙测试。
  4. HTTPS 流量解密：对于 HTTPS 网站，xray 需要安装自己的 CA 证书到系统或浏览器的受信任根证书颁发机构，才能解密并分析加密流量。否则，你只能看到 CONNECT 方法的日志，看不到具体的请求和响应内容。
     • 解决方法：启动 xray 后，用浏览器访问http://127.0.0.1:7777（注意是 HTTP），xray 会提供一个页面让你下载其 CA 证书。下载后，手动导入到操作系统或浏览器的信任证书库中。这是一个关键且必需的步骤！

5.2 扫描报告误报太多或漏报严重

• 症状：报告里充满了“无关紧要”的告警，或者明显有漏洞的地方却没扫出来。
• 排查与优化：
  1. 误报多：
     • 调整插件配置：关闭一些高误报率的插件，或在插件配置中调高检测阈值。例如，phantasm（幻影）插件有时攻击性较强。
     • 精细配置excludes：将已知的静态资源、第三方服务域名加入排除列表。
     • 分析误报类型：如果某个特定类型的误报反复出现（如某个特定的 JSON 接口总是报“JSONP 敏感信息泄漏”），可以考虑为该 URL 或参数添加白名单规则（在配置文件中寻找whitelist相关配置）。
  2. 漏报严重：
     • 检查流量覆盖率：被动代理完全依赖于流经的流量。确保你的测试（手动或自动）覆盖了所有功能点、所有参数。尝试使用 Rad 爬虫进行更全面的探索。
     • 启用反连平台：没有反连平台，像 Blind SQLi、SSRF、反序列化这类“盲”漏洞几乎无法被有效检测。配置反连是提升检测深度的首要任务。
     • 更新 POC 库：xray 的漏洞检测能力依赖于其内置的 POC 库。定期更新 xray 到最新版本，以获取社区贡献的最新漏洞检测规则。
     • 检查 HTTPS 解密：确认 CA 证书已正确安装，且浏览器信任了该证书。否则，xray 看到的只是加密的密文，无法进行有效分析。

5.3 性能问题：扫描速度慢或占用资源高

• 症状：xray 进程 CPU 或内存占用很高，浏览器访问网站变慢。
• 优化建议：
  1. 限制并发和速率：在config.yaml的http部分，可以调整max_conns_per_host（每主机最大连接数）和pipeline等参数，限制 xray 向目标发送请求的速率，避免对目标造成压力。
  2. 禁用非必要插件：在plugins部分，只开启你关心的漏洞类型插件。例如，如果目标是一个纯静态展示站，可以关闭sqldet,cmd_injection等动态漏洞插件。
  3. 升级硬件：xray 的检测引擎在进行规则匹配和语法分析时比较消耗 CPU。对于高流量场景，考虑使用性能更好的服务器。
  4. 分布式部署：如前所述，对于大型监控需求，可以将流量按业务拆分到多个 xray 实例上。

5.4 与 AWVS、Burp Suite 等工具联动

很多同学关心如何将 xray 与已有的工具链结合。最常见的是与 AWVS 或 Burp Suite 联动。

• 与 Burp Suite 联动：Burp 本身就是一个强大的代理和测试平台。你可以将 Burp 的上游代理设置为 xray。

  1. 启动 xray，监听127.0.0.1:7777。
  2. 在 Burp Suite 中，进入User options->Connections->Upstream Proxy Servers。
  3. 添加一个规则，将目标范围（如*.target.com）的流量，通过代理127.0.0.1:7777转发出去。 这样，你的测试流程是：浏览器 -> Burp Suite -> xray -> 目标网站。你可以在 Burp 里进行手动测试、重放、爬取，所有这些流量都会经过 xray 进行被动漏洞检测。两者优势互补。

• 与 AWVS 联动：思路类似。在 AWVS 的扫描配置中，通常有设置代理（Proxy）的选项。将 AWVS 的扫描器代理设置为 xray 的地址。这样，AWVS 主动扫描产生的所有请求，也会被 xray 分析一遍。你可以同时获得 AWVS 的深度扫描结果和 xray 的实时被动检测结果，交叉验证，提高漏洞发现的全面性。

搭建并优化好这个平台后，它就不再是一个简单的工具，而是一个融入研发流程的持续安全监控节点。无论是每日的自动化测试，还是每次上线前的回归验证，亦或是针对某个新功能的专项评估，这个“隐形哨兵”都能在后台提供不间断的安全守护。真正的价值不在于某一次扫出了多少个漏洞，而在于建立了一种随时可用的、低成本的、自动化的安全反馈机制。