该项目使用 Ansible 生成 BATS 测试文件，以验证关于网络基础设施的安全假设。测试从探测机器（"探测节点"）运行，Prober 部署在这些节点上。
此工具旨在对自有网络进行可重现的自动化测试。它支持多个探测节点同时运行测试，每个节点对被测网络有不同的视角——例如，来自外部区域的视角、来自内部区域的视角，以及来自 DMZ 内部的视角。
使用 Prober 探测未经授权的网络可能是违法的。
在用于将测试部署到探测节点的 Ansible 主控节点上：
ansible（当然！）python*-netaddr（在 GNU/Linux 上）/ py*-netaddr（在 FreeBSD 上）在探测节点本身：
bashsshnmapdig/kdigtestssl在审查结果（*.tap 文件）的系统上，你可能希望安装 tappy。结果保存在每个探测节点上的本地 git 仓库中（默认位置为 /var/run/prober/results/，有关配置选项请参见下文），每次扫描运行完成时都会以日期作为标签提交，以便进行历史记录和轻松比较。
使用 Ansible 将测试生成到探测节点。探测节点可以是任何 FreeBSD 或 GNU/Linux 主机，只要能够安装 Prober 的依赖项即可。它不需要专用于测试，但建议这样做——一个中等规模网络的扫描将耗时数小时，占用大量 CPU，并产生大量流量。
在不同的机器上部署 Prober 是有意义的，以便从不同的观测点检查你的网络状况（例如：内部网络、DMZ、互联网）。
在探测节点的测试目录中，会创建一个 run-tests.sh 脚本来方便运行测试。测试的运行方式确保在任何时候都有最多 <simultaneous_tests_count> 个测试同时运行——此变量是控制探测扫描使用多少资源和带宽的主要方式。
测试结果随后保存到本地 git 仓库中，提交时以给定运行完成的日期作为标签（对于某些耗时较长的探测运行，该日期可能与开始日期不同）。
如果基础设施包含超过几台主机，使用像 Mitogen 这样的工具可以显著加快测试生成速度。
准备一台 Debian 或 FreeBSD 服务器作为探测节点（我们称之为 prober.example.com），确保你有 SSH 访问权限并且可以 sudo。
复制 示例 inventory 为 inventories/test/。
在该 test inventory 中：
group_vars/all.yml，根据你的需要设置 zone_nameserver、zone_domains、address_blocks；假设我们添加 example.com 作为唯一一个要探测的域hosts 文件，在 [prober-nodes] 部分配置你的 prober.example.com 探测节点；假设你将 tested_zone 设置为 。你现在可以 ssh 进入探测节点，检查 /opt/prober/ 中生成的测试。满意后，你可以通过执行 /opt/prober/run_tests.sh 来运行它们。结果将保存在 /var/run/prober/results 中。
配置变量（在 probers.yml 中定义）：
tests_directory（默认值：/opt/prober）：
探测节点上测试文件（*.bats 文件）生成到的目录。
results_repo_directory（默认值：/var/run/prober/results）：
测试结果（*.tap 文件）仓库的目录；该目录会初始化一个 git 仓库，并创建一个 tap/ 子目录用于实际结果；
结果会提交到 git 仓库，提交以 yyyy-mm-dd 格式的日期作为标签（例如，对于 2020 年 3 月 19 日完成的测试，提交标签为 2020-03-19）。
simultaneous_tests_count（默认值：20）：
同时运行的测试数量。
prober_dev（默认值：未定义）：
跳过某些在开发机器上没有意义的任务（如设置 cron 或 ）。
区域在 ./data/<zone_name>.yml 文件中定义，顶级键为字符串 "tested_zone_settings"，其中包含以下键：
name：区域名称，与文件名（不含扩展名）匹配；例如："internal"、"external"、"dmz"default（可选）：该区域所有主机的默认设置^" 字符开头）匹配多个 FQDNdefault 键、每个正则键和每个域键又可以包含以下键：
resolve：主机是否应解析到相关的 IP 地址（布尔值 true/false，或字符串 "skip"）ping：主机是否应响应 ping（布尔值 true/false，或字符串 "skip"）ports：允许开放的第 4 层端口列表（子键 "tcp" 和 "udp"，每个包含一个整数数组，定义允许开放的端口，或字符串 "skip"），以及要深度检查的启用 TLS 的端口（tls 子键，包含一个以端口号为键、TLS 服务类型或字符串 "skip" 为值的字典）ports: "skip" 是以下内容的缩写：
TLS 服务类型是 支持的任何类型，用于 选项； 用于 HTTPS 测试（包括头部）；或 用于通用 TLS 测试。
：除非端口也在 键中标记为开放，否则 TLS 测试运行。你可以在此处查看示例配置：data/example.yml。
全局默认值在 probers.yml 中定义。对于每个被探测的主机，这些值会与相关区域默认值、匹配主机名的正则键，最后与特定主机设置进行 combine。
这意味着在给定区域中，特定主机设置优先于正则匹配键的设置，正则匹配键又优先于区域默认值，而区域默认值又优先于全局默认值。
ports 键的处理有些特殊：如果在配置继承链中的某处列出了某些端口，则在链中较低的位置无法将其移除，只能添加更多端口号，或者通过 "skip" 完全跳过特定协议的端口测试。
区域文件的选择基于每个探测节点设置的 tested_zone 变量。
某些测试在单个 IP 地址的上下文中有意义，无论有多少域/主机名解析到该地址；例如，检查某些端口是否开放。例如，假设 a.example.com 和 b.example.com 指向同一个 IP 地址。根据上面的示例配置，这意味着端口 8080/tcp 和 8443/tcp 都应开放，并且预期端口 8443/tcp 上提供 HTTPS 服务。
某些测试在特定域/主机名与 IP 地址组合的上下文中有意义；例如，针对特定域名在特定 IP 地址上呈现的 TLS 证书是否有效。
这两种测试通过生成两个独立的目标列表来实现：
<ip-address> <hostname1> (<hostname2> <hostname3> ... <hostnameN>)<ip-address> <hostname>一些测试文件仅针对第一个列表中的目标生成（例如，开放端口测试），而一些测试文件仅针对第二个列表中的目标生成（例如，TLS 相关测试）。
如果某些端口未开放，则某些测试没有意义。仅当在给定区域中配置了相关的 TCP 端口为 open 时，才会为该主机生成 TLS 相关测试。
默认情况下，如果在 ports.tcp 键中配置了任何已知的启用 TLS 的端口为开放，则会为其生成 TLS 测试。已知启用 TLS 的端口列表在 default_host_settings 变量 中定义。
总体而言，Prober 与其他类似工具或服务的区别通常体现在以下方面的组合：
Shodan 扫描互联网以发现暴露的系统。Prober 扫描你自己的基础设施，从你需要的尽可能多的观测点验证你对它的假设。它通过定义明确的测试和定期、计划的运行来关注结果的可重现性，并尝试为每个测试的假设提供布尔型“通过/失败”结果（同时提供完整的扫描结果数据以供检查）。
BitSight 验证他们认为合理的关于你基础设施的假设，而不让你控制或了解扫描何时进行，也不提供原始扫描数据。Prober 验证你自己对基础设施的假设，按照你的计划进行，并提供完整的原始扫描数据以供检查。
Natlas 似乎更接近 Shodan（扫描以发现暴露的主机，并显示查询结果），但能够自托管（因此也可以像 Prober 节点一样，将 Natlas Agent 部署在基础设施内外的不同位置）。Prober 定期扫描你的基础设施，以验证你对自己的基础设施的假设，这些假设在配置中表达。
Logo 基于 Magnifying Glass by verry obito, ID; CC-By 和 Network by Creative Stall, PK; CC-By，来自 The Noun Project。
test复制 示例区域配置 为 data/<tested_zone>.yml（因此在本例中为 data/test.yml）并进行编辑；至少，tested_zone_settings.name 键必须包含 tested_zone（即 test）。
导出你的 DNS 区域并保存为 data/<dns_zone>.zone（在本例中为 example.com）。
运行 playbook：
ansible-playbook prober.yml -i inventories/test/ -vvv
这将在探测节点上生成测试，并设置一个 cron 作业，使其每天凌晨 01:00 运行。
zabbixports:
tcp: "skip"
udp: "skip"
tls: "skip"
-t/--starttls"https""tls""tcp"skip：是否完全跳过该主机（布尔值）