宋崟川先生是美国领英（LinkedIn）的工程师，也是“IPv6 产业生态圈”和“IPv6 头跳读者群”活跃的技术型群友之一。他维护的网站https://IPv6-CN.com 向广大朋友提供原创和翻译的 IPv6 资料。

宋崟川先生的家庭网络已经接入了 IPv6带宽。9 月 20 日宋先生在微信群里通报：家中路由器的防火墙日志显示 9 月份有三次（截至本文发稿时有六次）来自 AWS 云主机对家庭内网主机 IPv6 地址80 端口的精准扫描。

下面，我们来看一下事件发生的经过，和宋先生对攻击事件的深度分析。

谁在扫描我家的 IPv6 地址？

宋崟川（原创）

在 IPv4 环境下，对 TCP 和 UDP 的端口扫描非常常见，而且攻击者经常扫描整个网络的所有地址。这种肆无忌惮的扫描每分钟可能有几十或上百次。

到了 IPv6 的时代，IPv6 一个子网的大小就是整个 IPv4 地址数量的 2^32 倍，非常不利于攻击者扫描目标网络。通常我们认为在IPv6上对网段的扫描不会发生，起码对于了解 IPv6 的攻击者来说不会选择这样浪费时间。

然而在本文的例子中，我们看到了针对家庭宽带用户的单个 IPv6 地址的单一端口扫描，为什么会发生这样的事情呢？我们作为网络的维护者又应该如何保护好自己，防止受到这种攻击呢？

事件发生经过：

1、网络环境

我家中接入互联网的运营商是AS7922 美国 Comcast 公司。

使用的路由器是思科 ISR（集成业务路由器）。与一般企业网络边界部署的大型路由器相比，除了吞吐量不同，功能和操作方式上没有太大区别，运行 Cisco IOS 系统。

此路由器中防火墙功能的配置使用思科的传统 CBAC（基于上下文的访问控制）模式，通过 ACL 与 inspect 命令跟踪返回的数据包相结合来实现包过滤防火墙和有状态防火墙。

Comcast 使用 DHCP 给我的路由器分配了 1 个 IPv4 地址，使用 DHCPv6-PD （前缀下发）分配了一个/60 大小的前缀，这样我最多有 16 个 /64（这是 IPv6 环境下通行的网络前缀长度，适合给一个 VLAN 分配）大小的 IPv6 子网。

我为家中的设备配置了可以通过IPv4 和 IPv6 访问的 DNS 服务器，这些 DNS 服务器都可以正常返回一个域名的 A 以及 AAAA 记录。

路由器启动一个半月来，IPv6 入站流量有 156GB，IPv4入站流量仅有 384MB。

2、攻击记录

9 月 20 日，在完善家中路由器的防火墙设置时，我发现了三条不寻常的日志（本文撰写时又发现三条）

攻击记录截图

以第一条日志为例，解释一下各个字段的含义：

Sep 10  13:51:36.515 PDT	硅谷当地时间 9 月 10 日13:51:36
%IPV6_ACL-6-ACCESSLOGP	日志产生来源 IPv6 防火墙访问日志
list  ACL-ingress-v6/170 denied	根据 ACL-ingress-v6 的第 170 号规则拒绝了
tcp	TCP
2600:1F18:6058:A200::8(43793)	源 IPv6 地址（TCP 源端口）
(Gi0 0001.0000.0000)	进入路由器的接口和 MAC 地址
2601:1234:abcd:e::1(80)	目的 IPv6 地址（TCP 目的端口）
1  packet	一个数据包

注：源地址和目的地址在不影响理解的前提下都做了适当简化。

• 第 1 条日志中的目的地址简化后保留最后的1，表示这是一个手工分配的地址。

• 第 2-6 条日志中的源地址的 17-64 位被略去，因为与第 1 条重复。

• 所有日志条目中的目的地址第 17-64 位被改写，是出于隐私保护的考虑。

3、日志分析

3.1. 时间

几次扫描分别发生在：下午 1:51，凌晨 1:00，下午 1:28，凌晨 4:47，下午4:44，凌晨 4:19。这些时段我是不会活跃地使用家中网络的，可以排除与我的操作直接相关的实时在线扫描。即这种扫描不是request-response 形式的，而是一种收集与扫描分开的形式。

3.2.源地址

这几次扫描都来自同一个 /64 前缀——2600:1F18:6058:A200::/64，此前缀属于 AS14618 亚马逊 AWS EC2 云主机。

亚马逊云计算的 IPv6 分配策略如下：AWS VPC 会被分配一个 /56，其中有 256 个 /64 的子网可供分配。地址的来源是 Amazon 自己的全球单播地址池。

[出自:jiwo.org]

根据以上分配策略，很容易得出结论，这六次扫描是同一个 AWS 账号所为。

从这几个源地址的接口标识符（IID，即后 64 位）来看，这些主机的角色并不是服务器，而是一些使用 SLAAC 获得前缀自行分配地址的客户机。因为 服务器 的地址通常是方便人类阅读和配置，最起码也是有一定规律的形式。

3.3. 目的地址

除了第 1 条日志条目中的目的地址是手工分配的以外（没有使用 SLAAC），而且此地址对应的设备并不是一直在线。后面第 2-6 条日志的目的地址所在的子网开启了路由器宣告（RA），所以主机会使用 SLAAC 及其隐私扩展生成自己的全球单播 IPv6 地址。

以上结合来看，排除了一直开着的设备 call home 触发扫描的可能性。

通常 Windows 和 Mac 都会生成两个地址，一个叫“ 临时 IPv6 地址（Temporary IPv6 address ）”，默认用于对外发起连接，一个叫“ 公有 IPv6 地址（Public IPv6 address ) ”。

临时地址的接口标识符（即后 64 位）是随机生成的，会在较短的时间内过期，除非应用程序要求使用公有IPv6地址，否则系统默认优先使用临时地址对外发起连接。

公有 IPv6 地址的生命周期有两种，分别叫有效期（Valid Lifetime）30 天，优选期（Preferred Lifetime）7 天。应用程序可以向操作系统请求选择使用相对稳定的公有 IPv6 地址。地址选择的算法详见 RFC 6724。

临时地址的使用不仅能降低此类扫描的风险，还能在如今广告提供商无下限地跟踪用户的环境下尽可能在地址上保护用户的隐私。

3.4. 目的端口

目的端口都是 80，这也是我一眼能识别出这是扫描而不是正常访问的依据，因为我没有在 80 端口上提供服务。攻击者试图连接 TCP 80 端口（即 HTTP 服务使用的端口）的行为目前也没有合适的解释。

由于我的防火墙对 ICMPv6 是放行且不写入日志的（文后附防火墙ACL 部分配置），所以攻击者是否先尝试ping 几个地址无从得知。

以上对日志的分析，引出了一个新问题——

我家内网的 IPv6 地址是如何被攻击者所知晓的？

前面已经讲到，针对 IPv6 的网络扫描，不可能是对一个 /64 内的所有地址进行扫描，一定是针对单独 IPv6 地址的扫描，地址的获得既可以通过猜测，也可以通过采集。

在这个案例中，通过日志中有限的几个条目，以及目的地址处在两个不同的 /64 子网，可以完全排除攻击者使用扫描了整个网络这种愚蠢的方法。

通过对目的地址的分析，可以排除攻击者猜测一些常见的诸如——“::”, “::1”, “::123”, “::abc”, “:192:168:1:1”形式作为接口标识（IID，后 64 位）的 IPv6 地址。

网络中一个使用过/使用中的 GUA IPv6 地址可能出现的位置有：

1)   本机的网络接口配置

2)   本地应用程序日志

3)   本机在 DNS 中的动态条目

4)   应用层协议的 Payload 中嵌入了 IPv6 地址

5)   路由器/多层交换机和同网段其他机器的 ND 缓存

6)   DNS 服务器查询日志

i. DNS 提供商自身的日志

ii. 网络中对 DNS 请求的嗅探和劫持

7)   NetFlow 导出日志

8)   Web 服务器和应用服务器访问日志

i.  所访问网站的日志泄露

a.    一般网站

b.    IPv6 测试网站（志愿加入提供服务，不排除有恶意设置的服务器）

ii.   CDN 提供商的访问日志泄露

9)   代理服务器访问日志

i.   未授权 WPAD 代理配置下发服务造成客户端使用攻击者设置的代理服务器

ii.  透明代理和 HTTP 劫持代理的日志泄露

10)   交换机端口镜像流量

i.  合法或非法嗅探用户流量

（以上十条是我个人的总结，有疏忽和遗漏的地方欢迎大家留言指正。）

由于 IPv6 端到端的特性，任何一个数据包的地址在其整个生命流程中都不大可能被改变。即使有 NPTv6 这种无状态修改前缀的设备在使用，TCP、UDP、ICMP 等不依赖 IPv6 地址进行认证的协议还是不会给攻击者造成任何不便。

所以上述任何一个位置如果被攻击者控制，均会造成客户端 IPv6 地址落入攻击者手中，使其可以为进一步内网渗透做准备。

目前分析较为可能的是某 Web 服务器上的日志被有意无意滥用，造成客户端 IPv6 地址落到攻击者手中，攻击者收集了一定量的数据后开始对这些地址进行了扫描。

运营商控制我上网的管道，有数不清的方法来对付我，不会采用这么 low 的扫描。

4、本案例中发现的基础设施的不足之处 

1)   设备的 IPv6 地址没有跟踪和溯源机制，事后无从追查当时使用某个目的地址的机器是哪一台。

2)   访问控制列表中的放行策略也许还是不够严格，有没有漏网之鱼无从得知。

3)   对每一个自内而外发起的连接/会话没有跟踪，网络上发生了什么，哪些前缀、哪些 协议、哪些 TCP/UDP 端口比其他的要更活跃，流量都去哪里了……这些基础网络情报都没有收集，出现问题没有深入调查的条件。

4)   设备（此案例中是路由器）的日志仅仅保存在设备内存当中，一旦断电重启，本文可能不会出现在读者面前。

5、如何防范此类攻击

• 完善企业网络安全制度。如果IPv4 的安全制度已经成熟可靠，则要尽快将其应用到IPv6 环境下。如果 IPv4 下的安全制度缺失，那么 IPv6 的推广部署则是建立企业安全制度规范的好机会，可以在前人的肩膀上有一个很高的起点。

• 理解并配置 IPv6 防火墙。理解 IPv6 包结构与 IPv4 包的本质不同，即 IPv6 包头是类似链表的结构，而 IPv4 包头是层层嵌套结构。使用白名单模式配置防火墙，只放行已知合法的流量及其返回的数据包。部署支持IPv6 的 IDS/IPS。

• 主机的防火墙也应该打开，只放行本机对外必需的服务。

• 企业环境中应使用有状态DHCPv6 为客户端分配地址，但是不应该让客户端长时间采用同一个地址，而是应该设置较短的地址生命周期，并采用好的随机算法生成客户端后缀。要完成国家对 IPv6 地址溯源的需求，只需要保留好 DHCPv6服务器日志，并定期从接入交换机、AP 上采集 MAC 地址与 IPv6 地址的对应关系即可。切不可图省事，为客户端分配长久不变的地址。这种做法，为自己的网络带来安全隐患的同时，彻底毁掉了 IPv6 为终端客户带来的一点隐私保护措施。

附：我的入站 IPv6 ACL，即将失效，仅供参考，下一步将迁移到新的思科 IOS ZFW 防火墙架构。

【结束】

老赵的一些思考：

宋崟川先生遭遇对内网主机IP地址的精准扫描，虽然是“ 第一次发现 ”，但是绝对不能说这种情况是 “ 第一次出现 ”，因为很可能以前出现了很多次，但是一直没有被发现。只是本次比较偶然被发现。

同时，这种情况不可能仅仅发生在美国的IPv6网络中，中国的IPv6网络有没有遭遇到这种精准扫描？在没有确凿证据的前提下，我们不敢轻易下结论。

但是必须警惕： 我们没有发现，不等于没有发生；很可能已经发生了，并且一直在持续发生，只是我们一直没有发现。

两办《推进IPv6规模部署行动计划》文件的基本原则里明确要求 “ 两并举 、 三同步：发展与安全并举， 网络安全要同步规划、同步建设、同步运行 ”。因此各单位的IPv6升级工作，网络安全工作必须也要同步进行，不能只顾一头。

随着三大电信运营商和CERNET2开通IPv6网络接入服务，现在一些企业、教育、IDC和ISP等单位的网络已经接入了IPv6。但是有几个问题必须引起足够的关注：

a）已接入IPv6的单位，对IPv6网络安全管理是否给予了足够的重视？是否采取了针对IPv6网络安全的必要措施？

b）升级后的IPv6网络是否已经妥善配置良好支持IPv6的防火墙、入侵检测等安全防护设备，可以抵御来自IPv6线路的网络攻击？

c）运维人员的技术能力，是否能满足IPv6网络安全建设和突发事件应急处置的需要？

这几个问题，扪心自问，是做到吗？

IPv6网络有很多新的特性，将会产生很多新的网络安全场景，这些场景与IPv4网络并不一样，所需的防护策略也会不一样。但是，无论IPv6还是IPv4 ，网络安全在本质上并没有根本变化，最关键的问题是网络管理者的安全意识、安全措施、培训技术人员具有应急处置的能力，才是IPv6网络日常运维工作中最核心的部分。

宋崟川先生发现的IPv6网络攻击，为我们敲响了 IPv6 安全警钟。提醒我们对 IPv6 环境下的网络安全绝对不能掉以轻心，尤其是不能抱有侥幸心理，否则可能会吃大亏。