工作来源
IMC 2024
工作背景
2013 年 ZMap 横空出世，成为了扫描工具的标杆之作。十年间，ZMap 也在不断进步，开发团队在研发过程中学到了很多。
2024 年 1 月 1 日到 3 月 31 日间，35.4% 的 IPv4 TCP 扫描都来自 ZMap。
全局来看，TCP 扫描最多的端口是 23、6379 和 8080 端口，而 ZMap 扫描最多的端口是 8080、8728 和 80 端口。
美国的安全公司大量使用 ZMap，但俄罗斯使用 ZMap 的比例则很低。
安全公司和云服务商长期使用 ZMap 进行扫描，扫描流量最大的自治系统是 Goolge Cloud。并且，PaloAltoNetworks 也使用 GCP 为其 Xpanse 攻击面管理产品提供数据支撑。当然，僵尸网络早已将 ZMap 和 msscan 等大规模扫描工具纳入工具箱中。
只有 3% 的 HTTP 服务运行在 80 端口，只有 6% 的 TLS 服务运行在 443 端口。因此，只扫描分配的端口是不够的。另外，传输层服务和应用层服务识别分开，ZMap 主要在传输层处理，应用层转移到 LZR 和 ZGrab。
ZMap 项目的开发者众多，但九成的代码都是由五个人编写的。大部分外部开发者都来自工业界，学术界贡献有限，且学术界对核心功能的升级往往会演化成新工具（XMap、ZMapv6 等）而非合并到主分支。
工作设计
IP地址与端口生成
IP+端口：ZMap 可以无状态地伪随机扫描 IPv4 地址空间，最初 ZMap 扫描单个端口上的所有 IPv4 地址（水平扫描）。目前 Zmap 也在随机化中支持了多端口，随机选择池子中从 IP 升级为 IP+端口。
生成器：加法群生成器映射到乘法群生成器，平均需要四次可以生成可用的生成器，使得每次扫描创建新的地址空间排列。
响应去重：最初使用 bitmap 进行过滤，但如果合并考虑端口需要的内存将从 512MB 上升至 35TB。转向使用 Judy 数组维护最后 IP+端口响应的滑动窗口，默认 106 容量的窗口可以过滤几乎所有重复响应。
扫描分片
无互斥分片机制使得 ZMap 可以将扫描任务跨机器拆分
交错分片：每个分片一次按步迭代，偏移一步。分片的最后一个索引没有封闭，容易出现问题。
连续分片：将乘法组划分为按递增顺序排列的值域，每个值域中仍然按递增顺序排列。元素会在组中被伪随机地迭代，还不会出现偏差。
数据包构造
ZMap 尽可能使用最小的数据包进行探测，但任何 TCP/IP 选项都不填会影响探测效果。例如包含 SA、TS、WS、MSS 选项，可以让命中率提高 1.5% 到 2%。甚至，选项的顺序也会影响探测效果，模拟常见操作系统可以最大程度提高覆盖率。当然，增加了 TCP 选项后数据包变大，扫描速率会有所下降。
工作评估
ZMap 最初想做成一个框架，但后来发现研究人员基本上不直接写入数据库，连接数据库的输出模块成为了负担，后续 ZMap 删除了这部分模块。建议：构建小型、简单、易于理解、易于测试、易于使用且可组装使用的测量工具，而不是构建复杂的软件框架。尽量不要使用专有格式，在 CSV、JSON Lines、BSON 和 AVRO 等常用格式上对输出进行标准化。
命令行使用是最快捷的方式，但这种方式限制了该工具集成到大型系统中的潜力。建议：工具拆成两个组件（库与包装库的命令行），这样不仅可以保持灵活高效，还可以构建更大规模的系统。
ZMap 对外输出数据、日志、实时更新数据和完成后的元数据，这样可以帮助用户对执行情况进行持续跟踪，并排除故障或者重现结果。建议：生成单独的数据流、元数据流、日志流，不要混在一起，下游处理会非常复杂。
JSON 和 CSV 都提供了相当的灵活性，但下游处理 JSON 通常不支持如此灵活。创建容易处理难的情况要尽量避免。建议：输出的每个字段都要使用单一的、明确的类型，并且一个字段的类型不依赖于另一个字段的值。避免使用带有动态键值映射，尽量使用静态文档类型的列表，如 JSON Schema、ZSchema 等。
编写 ZMap 时，C/C++ 是唯一可用的语言，但使用 C/C++ 引入了许多编程问题。建议：使用 Rust 或 Go 等现代语言进行开发，降低开发成本、提高开发效率。
工作思考
进行主动测量一定要注意道德准则要求，有道德的金条还是高尚一些的吧。
全网扫描肯定会为互联网带来影响，进行必要范围和必要频率的扫描，尽量降低对互联网的影响。在扫描时要通过绑定反向 DNS 等手段介绍扫描行为，让被扫描方可以联系到扫描方，并提供简单的退出机制。
声明：本文来自威胁棱镜，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
