首次发现对内网主机真实IPv6地址 的 精准扫描

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

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

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

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

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

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

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

目的端口都是 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 地址可能出现的位置有：

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

i. DNS 提供商自身的日志

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 完善企业网络安全制度。如果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 环境下的网络安全绝对不能掉以轻心，尤其是不能抱有侥幸心理，否则可能会吃大亏。

声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如需转载，请联系原作者获取授权。

  如何查询网站ip地址？相信不少电脑小白用户都学习查看网站的ip地址方法，通过CMD命令实现很简单，跟着装机之家学习一下怎样查看网站的ip地址方法吧！

  网站以装机之家官网为例：，我们来看看网站ip地址吧！

  我们在桌面左下角开始菜单，弹出菜单之后点击“运行...”，或者使用Win+R组合快捷键进入运行界面。

  在运行的输入框中输入cmd，并且点击确定：

  这时就进入CMD命令提示符界面：

  在后边输入“ping ”，并敲击回车确定（注意：在ping命令与网址之间有一个空格不能省略，即“ping空格”）：

  这时我们就可以查询到网站的ip了。

  此外，需要说明一下，有的时候查询出来的IP未必是网站服务器的IP地址，有的网站使用了CDN加速，IP地址是CDN服务商提供的，并不是网站的服务器的IP地址。有了解CDN的朋友，不妨百度一下。

  以上就是装机之家提供的怎样查看网站的ip地址方法，希望能够帮助到你。

为了进行测试，本网站需要 JavaScript 以及拉取第三方脚本的权限。

此信息没有消失，说明 JavaScript 已被你的浏览器插件、扩展或设置禁用。

如果使用了这个 Firefox 附加组件，你需要点击两次“临时允许此页面全部脚本”才能正常进行测试。你也可以彻底禁用 NoScript，直到测试完成。

你也可以进行，快速判断 IPv4、IPv6 和双栈连通情况，但得不到详细的评估。