全网测绘的成本探究

有时候会好奇一个问题，如果不考虑人员、合规等成本，想测绘一次全网的成本是什么样的？尝试做了一些理论计算，形成这篇文章，供各位感兴趣的同学参考。

理论计算

IP地址数量

在开始探讨全网测绘的成本之前，让我们先进行一些简单的理论计算。IPv4地址由32位二进制数字组成，因此在理论上有2^32个不同的地址，换算成十进制，这个数字是4,294,967,296。然而，在现实世界中，并非所有的IP地址都可用于公网，因为有一些特殊的保留地址范围存在。

首先，我们有私有地址空间，包括以下范围：

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16

然后，还有一些其他的保留地址范围，包括：

  • 0.0.0.0/8：当前网络（仅限于源地址）
  • 127.0.0.0/8：本地回环地址
  • 169.254.0.0/16：链路本地地址（用于自动配置）
  • 192.0.0.0/24：IETF 协议相关 （RFC 5736）
  • 192.0.2.0/24：TEST-NET-1，用于文档和示例
  • 192.88.99.0/24：6to4 Relay Anycast
  • 198.18.0.0/15：用于网络性能测试和测量 （RFC 2544）
  • 198.51.100.0/24：TEST-NET-2，用于文档和示例
  • 203.0.113.0/24：TEST-NET-3，用于文档和示例
  • 224.0.0.0/4：多播地址
  • 240.0.0.0/4：保留地址，未来使用

为了计算可用的公网IPv4地址，我们需要从总数中减去这些保留地址。以下是每个保留范围的地址数量：

  • 私有地址空间：
    • 10.0.0.0/8：2^24 = 16,777,216
    • 172.16.0.0/12：2^20 = 1,048,576
    • 192.168.0.0/16：2^16 = 65,536
  • 保留地址：
    • 0.0.0.0/8：2^24 = 16,777,216
    • 127.0.0.0/8：2^24 = 16,777,216
    • 169.254.0.0/16：2^16 = 65,536
    • 192.0.0.0/24：2^8 = 256
    • 192.0.2.0/24：2^8 = 256
    • 198.18.0.0/15：2^17 = 131,072
    • 192.88.99.0/24：2^8 = 256
    • 198.51.100.0/24：2^8 = 256
    • 203.0.113.0/24：2^8 = 256
    • 224.0.0.0/4：2^28 = 268,435,456
    • 240.0.0.0/4：2^28 = 268,435,456
    • 255.255.255.255/32：1

将这些数字相加，我们得到：16777216 + 1048576 + 65536 + 16777216 + 16777216 + 65536 + 256 + 256 + 131072 + 256 + 256 + 256 + 268435456 + 268435456 + 1 = 588514561

现在，我们可以从总数中减去保留地址的数量：4294967296 - 588514561 = 3706452735。

值得注意的是，在现实世界中，并非所有的地址都已经分配和使用，因此实际的可用公网IPv4地址数量略小于37亿，这个结果仅提供了一个用于大致估计的上限值。如果需要实时的、完整的已分配的IP列表，可以通过相关的组织获取。

测绘时间成本

基于IP地址的数量，让我们按SYN扫描来计算一下发送报文所需的时间。

首先，一个TCP SYN报文的大小为54字节（包括14字节的MAC层、20字节的IP报文和20字节的TCP报文）。
1 Gbps的传输速率等于每秒传输125,000,000字节，将这个速率除以每个报文的大小54字节，得到大约2314815个报文每秒。

接下来，我们将使用之前计算得到的可用公网IPv4地址数量（3706452735个）除以每秒发送的报文数量（2314815个），得到约1601秒。

根据2013年ZMap论文的数据，大约有3450万个开放的443端口，大约占IPv4地址空间的百分之一。

考虑到TLS握手的长度，最长的情况下使用RSA算法进行完整的证书链验证和客户端身份验证，总长度可能超过数万字节。最短的情况下使用ECDHE密钥交换算法，并且不进行证书链验证和客户端身份验证，总长度大约在几百字节。

为了折中考虑，我们以5000字节为一个TLS握手的长度来计算。也就是说，约有百分之一的扫描需要占用百倍的带宽。因此，在之前计算的总时长上乘以2，得到3200秒，即54分钟。

这个计算给我们提供了一个大致的时间估计，说明在当前条件下进行全网测绘可能需要约54分钟的时间。

在Zmap论文中有提到：

1
We introduce ZMap, a modular, open-source network scanner specifically architected to perform Internet-wide scans and capable of surveying the entire IPv4 address space in under 45 minutes from user space on a single machine, approaching the theoretical maximum speed of gigabit Ethernet.

Zmaps使用Gb级别的网卡在45分钟扫描完互联网空间的 443 端口，与我们之前的计算结果非常接近，说明我们的计算是有参考意义的。

不妨采用乐观估计，假设互联网是稀疏的，大多数IP只开放一个到数十个端口，且只使用SYN扫描。在这种情况下，我们不需要考虑回包的时间。按照这个假设，要扫描完整个互联网所需的时间可以按以下公式计算：

3706452735（可用的公网IPv4地址数量） × 65536（每个地址可扫描的端口数） ÷ 2314815（每秒发送的报文数量） ÷ 60（转换为分钟） ÷ 60（转换为小时） ÷ 24（转换为天数） ≈ 1215天

也就是说，即使使用了Gb级别的网卡，乐观估计下完成整个互联网的扫描也需要超过一千两百天的时间。

测绘经济成本

不难想到的是，除了时间成本，大流量还需要经济资源。根据当前腾讯云的无折扣价格计算，一个配置为1核1G内存、200Mbps带宽的云主机每月需要17747元。为了达到Gbps级别的网速，需要使用50台这样的云主机。

注：当带宽利用率高于10%时，按带宽计费成本低于按流量计费。

根据计算公式：(1215 / 30) * 17747 * 50 = 35937675

因此，根据理论计算，完成一次完整的互联网IPv4地址空间的扫描成本约为三千万左右。

需要注意的是，这个测算模型主要考虑了发送流量所需的时间。如果我们希望缩短测绘的时间，只需要按比例增加使用的机器数量即可。

上述的时间和经济的估计给我们提供了一个实际情况下的时间框架和资金量级的参考，以更好地理解全网测绘的成本和挑战。

工程实践

当然，仅通过纸面计算成本是不现实的，因为工程实践中需要进行更多的权衡和实际操作。在面对不可接受的成本时，我们可以考虑一些方法来控制成本。

首先，我们并不一定需要对所有地址进行测绘，可以将范围缩小到某个国家或地区，这样数量级会大大减小。

同时，我们可以借鉴单机测绘工具如nmap的做法，在进行全端口测绘之前进行活跃探测。这样可以避免对不活跃的IP进行全端口测绘，从而在很大程度上节省成本。

此外，如果全端口测绘并非刚需，可以参考IANA的端口注册表 和工程实践的经验，实际常用端口的数量相对较少。除非有特定需求，否则在测绘过程中仅关注常见端口的成本会大大降低。

让我们重新计算一下，假设将测绘范围缩小到国内IP的10%和活跃IP的10%，仅测绘600个端口。根据这个假设，成本将从千万级降低到万级。

在缩减成本的同时，我们也需要考虑结果的有效性，这涉及到以下几个问题：

简单的、基于单次 SYN 报文能否保证测绘准确？

毫无疑问的，考虑到丢包率，单次单报文探测肯定存在漏报率。
根据《Census and Survey of the Visible Internet》论文的数据，单个报文在互联网上传输的丢包率约为 2% 左右。因此，单次探测的准确率大约在 98% 左右。对于一些成本敏感、结果要求不高的情况而言，这个准确率已经足够。

如果想识别应用指纹，需要多少报文？

单个 SYN 报文只能检测端口的开放情况。要完成对应用的交互和识别，需要进行完整的 TCP 握手以及后续的应用层交互。

当前的nmap服务探针超过100个，而要完成服务的交互，则需要完成完整的TCP握手以及后续的应用层交互，又是倍数级的消耗。

显然对于单个开放端口用数百个探针进行测绘，扩散到全网成本的基数，又是不可接受的。这就又需要对探针和效果进行取舍。

运行测绘系统是否有其它成本？

还需要注意的是，运行测绘系统还涉及到其他成本，数据存储、数据索引、任务分发、日志收集等等都需要计算、存储、网络资源，随着测绘规模不断地加大，对应存储计算的资源也会相应提升。

写在最后

本文通过粗略的纸面计算，对全网测绘的成本进行了估算，给出了测绘资源消耗的参考值。仅为工作之余闲暇之作，文中计算和推理都有非常多不严谨的部分，结论仅供参考。

参考资料

文档与规范

论文

  • Izhikevich L, Teixeira R, Durumeric Z. LZR: Identifying Unexpected Internet Services[C]//USENIX Security Symposium. 2021: 3111-3128.
  • Durumeric Z, Wustrow E, Halderman J A. ZMap: Fast Internet-wide Scanning and Its Security Applications[C]//USENIX Security Symposium. 2013, 8: 47-53.
  • Heidemann J, Pradkin Y, Govindan R, et al. Census and survey of the visible Internet[C]//Proceedings of the 8th ACM SIGCOMM conference on Internet measurement. 2008: 169-182.

工具

扫一扫，分享到微信

微信分享二维码