最重要的原因最先说：从安全的角度来看，我们已经不能继续忽视IPv6了。
最近，Akamai的研究人员与马克斯・普朗克信息研究所（Max Planck Institute for Informatics）合作，对IPv6地址空间的大规模漏洞扫描行为进行了首次实证研究。结果发现，网络上的各种扫描器已经开始扫荡IPv6空间。由于IPv6空间的扫描难度远高于IPv4，因此目前与IPv6有关的扫描活动还并不算太多。
总的来看，相关扫描流量主要集中于少数几个活跃来源。从地理位置方面来看，两个最活跃的来源均来自中国；从扫描流量来源的顶级网络来看，还有一些网络安全公司正在从云提供商的地址空间中发起扫描。
这类扫描器通常并不会使用单个128位IPv6地址发出扫描流量，而是会使用最大达到整个/32空间的无数个地址前缀来发起探测，这可能是为了逃避检测。因而直接后果就是：对这些扫描器的检测和封堵将变得异常困难。
为什么现在要开始关注这些？Akamai认为，如果针对IPv6的漏洞扫描继续变得更普遍，那么业界可能就迫切需要提供可靠的IPv6扫描活动检测和阻断技术。因为这很可能导致新的安全问题。
延伸阅读，了解Akamai cloud-computing
背景简介
无论攻击者、研究人员或防御者，大家都会通过网络扫描来找出/暴露出连接到互联网的设备中存在的漏洞。虽然这样做的目标大相径庭，但由于IPv4有数以万计的持续来源，任何人只需要进行扫描，就能发现或抵御网络威胁。当软件中发现新漏洞后，攻击者会争先恐后扫描不同的地址空间，寻找容易受到攻击的主机，并进行利用或攻击。与此同时，爬虫网络也会不断扫描地址空间，借此寻找新的可利用目标从而横向传播。安全公司和研究人员也会扫描地址空间，以确定不同地址空间的属性并发现薄弱点。总而言之：IPv4空间很忙。
那么IPv6呢？有人在扫描IPv6空间吗？我们是否有必要多多关注一下这方面？
答案很简单：从安全的角度来看，我们已经不能继续忽视IPv6了。上文提到的研究所产生的最新论文即将在ACM Internet Measurement Conference 2022大会上发表，论文中提到，我们使用在Akamai边缘服务器上获得的防火墙日志来阐述IPv6互联网上正在进行的扫描活动。在超过15个月的时间里，我们一直在研究：谁在扫描，他们在扫描什么，以及在识别和阻止此类扫描方面我们面临的最大挑战是什么。
为何对IPv6空间进行的扫描更困难？
IPv4地址空间包含大约40亿个地址，现如今，只要有网络带宽足够大的计算机，整个IPv4地址空间可以在大约一小时内扫描完毕。同样，低带宽的IoT爬虫只能生成并扫描随机的IPv4地址以便横向移动。只要有足够的时间，随机生成目标地址通常就足以找到有反应、可利用的主机。
但另一方面，IPv6的地址长度高达128位，可以包含大约10的38次方个地址，这要比IPv4地址空间的规模大好几个数量级。以现如今的技术能力来说，整个IPv6地址空间至少需要数万亿年的时间才能扫描完毕。这使得对整个空间进行完整扫描成了一种不切实际的做法，那么如果攻击者想要进行扫描，就需要首先通过其他方式找到目标地址，例如使用IPv6的命中列表（Hitlist），或使用DNS将域名解析为IPv6地址。虽然浩如烟海的IPv6使得攻击者很难通过随机扫描的方式寻找目标，但并不意味着我们可以完全忽视这种做法。这有些类似于“隐性安全性（Security by obscurity）”的思想，而根据这种思想，最佳做法是直接“阻断”扫描操作，从而“保护”IPv6。
为何很难检测到针对IPv6进行的扫描操作？
在IPv4空间中，每个能被路由的地址每天都会收到数以千计的扫描数据包，这是有人扫描整个IPv4空间，或有人以随机方式生成目标地址并借此查找有漏洞的主机所导致的结果。因此只需要监测未使用的前缀（“暗网”）中抵达的扫描流量，我们就可以通过一种直接的方法研究IPv4空间中的整体网络扫描活动趋势。
然而当涉及到IPv6时，第一个挑战在于找到一个足以看到足够程度扫描流量的“有利位置”。正如上文所述，随机地以整个IPv6空间为目标是不现实的。因此监测暂未使用的IPv6前缀（和IPv4一样，也属于“暗网”）上所产生的流量，这种方式几乎无法发现任何扫描流量。这时候就要由Akamai智能边缘平台发挥作用了！我们在超过1300个网络中运行了数十万台服务器，每台服务器都承载着客户的内容，由于我们在响应DNS请求时需要返回这些服务器的地址，因此这些服务器的IPv6地址就已经暴露到互联网上了。因此，它们可以被扫描器发现，并成为公开可用的IPv6命中列表的一部分。
第二个挑战是如何准确定位并隔离IPv6扫描源。由于攻击者与合法扫描源都在积极扫描，隔离对于了解目前的扫描情况就显得至关重要。此外，如果一个网络想要阻止来自恶意攻击者的流量，那么在生产环境中，隔离就变得更重要了。在研究扫描流量时，我们注意到一些扫描器并不使用单一128位源IPv6地址来发出自己的扫描探针，而是会从/64、/48，甚至/32等不太具体的前缀所包含的无数源地址发出扫描流量。毕竟IPv6的庞大规模使得这种做法完全可行，任何一个扫描器都可以轻松获得一个巨大的IPv6分配（例如直接从区域性互联网注册机构（RIR）那里获得一个/32空间，或者直接购买某些互联网服务提供商的服务，这些服务商可以为每个用户分配一整块/48前缀）。我们发现，将流量分散到多个前缀上有助于规避检测，因为每个源地址可能只发出了一个数据包。另外一些扫描器甚至还在IPv6地址中的可用位里编码了扫描信息。
我们如何监测出大规模IPv6扫描？
Akamai的防火墙会记录发送到我们边缘主机上的未经请求的流量，其中就包含扫描流量。在扫描检测方面，我们的依据是：一个特定来源，至少要以我们自己服务器的100个IP地址为目标，这有些类似于早期IPv4大规模扫描的检测机制。
如上文所述，由于一些扫描器使用更大的前缀来发出流量，我们首先将展示在不对流量进行聚合（/128源）情况下发现的扫描器，随后会展示首次将来自一个/64源的所有数据包聚合在一起后发现的扫描器，最后还有对来自一个/48源的所有数据包聚合后的结果。
2021和2022年的IPv6扫描趋势
图1：不同的源聚合程度下，每周检测到的IPv6扫描来源
图1展示了从2021年1月到2022年3月，我们每周检测到的扫描器数量。从图中可以看到，源数据包的聚合程度会对检测到的扫描器来源数量产生巨大影响。总的来说，我们发现在整个时期内，扫描器的数量相对稳定，每周活跃的扫描器来源大致都在10到100个之间，与针对IPv4空间进行扫描的数十万个扫描器相比，这个数量不值一提。从2121年11月开始，/128扫描源有一个明显的增量，但我们发现所有这些/128源都可以聚合成一个/64，并且都是被同一个扫描者所使用的，那是一家美国的网络安全公司。
对IPv6扫描流量进行的聚合
图2：每周的扫描数据包数量（/64源聚合）
图2展示了每周捕获的扫描数据包数量，并且我们将每周最活跃和第二活跃扫描器与其他所有扫描器来源分开显示了。令人震惊的是，我们发现，基本上，无论在什么时间，都有一个最活跃的扫描器发出了绝大部分扫描流量（最高占到每周总流量的92%），而其他不那么活跃的扫描器只产生了很少量的流量。那么这就引出了另一个问题：这个最活跃的扫描器到底是谁？
扫描的来源网络
下表列出了按照扫描流量的数据包数量降序排序的前20个扫描流量来源网络（自治系统，AS）。此外我们还针对每个网络，列出了检测到存在扫描器的/48前缀、/64前缀以及/128前缀的数量。对于每个网络，我们还列出了网络类型和来源国家/地区。
表：按照数量排名前20的扫描来源网络（AS）
我们注意到，如果来自/48的聚合流量满足有关扫描的定义，但来自/64的聚合流量无法满足定义，那么/48的扫描源数量可能会超过/64或/128（例如排名第18位的AS）。
我们发现，扫描活动是严重集中的：前五个源网络几乎占据所有扫描流量的93%。尤其值得注意的是，最活跃的两个源网络都是位于中国的数据中心，紧随其后的是一些网络安全公司以及大型云提供商。总的来说，我们发现大部分扫描流量都来自数据中心/云提供商，排名前20的来源没有一个是面向最终用户的ISP。
进一步分析每个AS内部的扫描源后，我们发现不同网络之间存在着惊人的差异。虽然最活跃的扫描源的全部流量都来自一个128位源地址，但我们发现一些网络（例如排名第18位的AS）中，同一个扫描器会从超过1000个不同的/48前缀发出扫描流量。同时，第18位的AS在所有记录在案的扫描流量中占比还不到0.1%，但在按照活跃的来源前缀对网络进行排序时，其中可能会出现分析偏差。
挑战和结论
我们在研究IPv6扫描时遇到了一个很重要的问题：在识别单一扫描者的过程中，使用怎样的前缀大小才是合适的？如上表所示，答案要看情况：虽然排名第1的AS中的扫描器可以，并且应当用它所采用的单一128位IPv6地址加以识别，但排名第18的AS中的扫描器则需要聚合到整个/32前缀中。一般来说，聚合到如此长的前缀，可能导致无法区分个别的扫描源，特别是在云提供商的环境中，个人用户经常也可以被分配/64、/9，甚至更具体的前缀。在实践中，如果要通过扫描检测来封锁某些地址，那么太“粗粒度”的聚合可能导致无意中封锁了合法来源。
我们的初步分析发现，目前以IPv6空间为目标的扫描器数量依然还相对较少，相比IPv4世界中那些知名的扫描器，数量更加不值一提。IPv6扫描流量高度集中，少数源地址占据了支配地位。我们认为，如果IPv6空间的漏洞扫描行为变得更加普遍，这种情况可能也将迅速产生变化。识别和正确定位IPv6扫描源已成为一个迫在眉睫的挑战。
如果对这个研究的结果感兴趣，欢迎阅读我们的论文。
这篇文章的内容感觉还行吧？有没有想要立即在 Linode 平台上亲自尝试一下？别忘了，现在注册可以免费获得价值 100 美元的使用额度，快点自己动手体验本文介绍的功能和服务吧↓↓↓
出海云服务，选择Akamai Linode！
欢迎关注Akamai ，第一时间了解高可用的MySQL/MariaDB参考架构，以及丰富的应用程序示例。
