从TTL值发现网络中的中间人攻击

文章

Hao Ma · 十二月 23, 2024 阅读大约需 6 分钟

技术支持团队在不同的项目中发现了类似中间人攻击的情况，和各位分享一下。

我们的系统一般是安装在内网里，没有恶意的中间人攻击的风险。但是在有些医院发现了这样的情况：IT在网络中安装了某种网络监控或者嗅探的设备，它会在通信通道中模拟其中一方，或者双方的通信节点，以截获通信双方的网络流量。通常它不影响双方的通信，但偶尔，它会中断双方的连接，造成业务的中断。实质上这也是一种中间人攻击的情况，只不过这是用户允许的行为，偶然出现了故障。

我们看看以下的例子:

以下的wireshark抓包截图中， 172.18.1.131和172.18.1.145在正常的通信过程中，忽然收到了RST消息，造成了TCP连接上的复位。

其中172.18.1.131是intersystems的health connect系统，它在序号50134的包里面首先发送了RST，因此客户怀疑是不是Health Connect出错，中断了连接，也就把问题提交了InterSystems的技术支持。

我们的技术支持检查了各种内部日志，没有发现任何错误，咨询了InterSystems的网络专家，才发现这是个网络层的错误，也就是说：这个RST不是Health Connect发送的，同样，序号50135的RST消息，也不一定是172.18.1.145发送的，这是中间网络层的行为。经过客户的证实，发现客户在网络层安装的监控工具，不知道什么原因，触动了某种安全机制，它模拟两个系统，分别向对方各发送了一个RST消息。

我们的技术人员之所以发现了疑似中间人攻击的情况，是基于仔细研究了RST消息中的TTL值。

IP 数据包中的 TTL(Time To Live)是什么：

当 IP 数据包在网络中传输时，TTL 用于防止数据包在网络中无限循环转发。发送方在创建 IP 数据包时设置一个初始 TTL 值，通常为 64、128 或 255 等。每经过一个路由器，TTL 值就会减 1。当 TTL 减为 0 时，路由器会丢弃该数据包，并向源地址发送一个 ICMP（Internet Control Message Protocol）超时消息。TTL确保网络中的数据包不会无限制地循环，避免网络拥塞。同时，TTL 也可以帮助网络管理员诊断网络问题，例如通过观察 TTL 值的变化来确定数据包经过的路由路径。可以通过 IP 数据包中的 TTL 值来大致判断路由信息，但这种方法并不十分精确，只能提供一些有限的线索。

为了理解上面一段话的意思，我们向不同的目的地发ping包观察一下TTL值:

hma@CNMBP23HMA ~ % ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.132 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.162 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.151 ms
^C
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.132/0.148/0.162/0.012 ms
hma@CNMBP23HMA ~ % ping bjsvmse01
PING bjsvmse01.iscinternal.com (172.19.85.68): 56 data bytes
64 bytes from 172.19.85.68: icmp_seq=0 ttl=64 time=10.388 ms
64 bytes from 172.19.85.68: icmp_seq=1 ttl=64 time=6.013 ms
64 bytes from 172.19.85.68: icmp_seq=2 ttl=64 time=4.614 ms
^C
--- bjsvmse01.iscinternal.com ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.941/5.778/10.388/2.050 ms
hma@CNMBP23HMA ~ % ping www.baidu.com
PING www.a.shifen.com (110.242.68.4): 56 data bytes
64 bytes from 110.242.68.4: icmp_seq=0 ttl=52 time=14.167 ms
64 bytes from 110.242.68.4: icmp_seq=1 ttl=52 time=12.411 ms
64 bytes from 110.242.68.4: icmp_seq=2 ttl=52 time=12.560 ms
^C
--- www.a.shifen.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.411/13.046/14.167/0.795 ms
hma@CNMBP23HMA ~ % ping www.intersystems.com
PING e9933.b.akamaiedge.net (104.124.163.63): 56 data bytes
64 bytes from 104.124.163.63: icmp_seq=0 ttl=42 time=173.183 ms
64 bytes from 104.124.163.63: icmp_seq=1 ttl=42 time=170.947 ms
64 bytes from 104.124.163.63: icmp_seq=2 ttl=42 time=169.031 ms
64 bytes from 104.124.163.63: icmp_seq=3 ttl=42 time=171.195 ms
64 bytes from 104.124.163.63: icmp_seq=4 ttl=42 time=168.908 ms
64 bytes from 104.124.163.63: icmp_seq=5 ttl=42 time=169.736 ms

上面我分别发送ICMP到4个地址：127.0.0.1，bjsvmse01, www.baidu.com, www.intersystems.com, 从对端响应消息中显示的TTL值分别是64, 64, 52, 42。

TTL=64是Linux系统的TTL初始值。在linux系统ping 127.0.0.1时返回的当然就是64。第二个服务器bjsvmse01返回TTL也是64, 说明它和我的本机在同一个网络，他们中间没有路由器的转接。

第3个第4个ping返回的消息中的TTL分别是52和42, 理解为：从Baidu.com的服务器到我的本机，经过了64-52=12个路由，而从intersystems.com到我的本机经过了64-42=22个路由。因为intersystems.com的服务器在国外，经过更多路由。从ping的结果看，响应时间也更长，平均响应要100多ms。

有了TTL的知识，我们来看看前面医院里的RST是怎么回事。

首先是RST的包，可以看到TTL是128。这就不对了。 128是Windows系统的TTL初始值，而我们技术人员已经知道了， Health Connect是安装在一个Linux系统上，如果是Health Connect发出的RST，TTL应该是低于64的.

我们去和一个正常工作的从这个服务器发出的TCP消息来比较，比如上面的HTTP消息，下面的截中可以看到TTL是64，这是对的。本来这两个服务器就在一个网络里。

因此，结论就是：抓包中显示为从Health Connect 172.1.18.131发出的RST消息，因为TTL不对，应该不是真的从Health Connect服务器发出的。 类似的情况出现在不同的客户的不同医院环境，所以我们认为维护或者支持任何可能应该了解一下这个情况。如果遇到，请及时和医院的IT工程师了解情况。

有关TCP消息中的TTL值，再补充几点：

如果源和目的服务器不在一个网络，TTL值不是64和128，也可以用来判断是否是真实的服务器发送的消息。我们有个支持的工单里，发现了正常工作的TTL是62，而发送了一个错误的TCP消息，TTL是57，这也是可疑且需要网络工程师确认的。
上面的例子中，从Health Connect对端，也就是172.18.1.145也发出了一个无法理解的RST消息。一个TCP端，收到一个RST消息后，不需要也不应该再回复，所以这个RST和上面Health Connect发出的RST没有关系。检查这个RST, 它的TTL值是128，而正常通信时从这个服务器发出的消息也是128，显然这是个Windows系统，所以这样的情况下，只通过TTL是无法判断消息来源的身份真假的。除非在不同的地方，比如在中间的交换机上和该服务器上分别抓包比较，才可以得到线索。
网络路径中的某些设备（如防火墙、代理服务器等）对数据包进行了特殊处理。这些设备可能会修改数据包的 TTL 值，以确保数据包能够在网络中存活足够长的时间到达目的地. 典型的是当ping 8.8.8.8，也就是 Google 的公共 DNS 服务器的时候，收到的TTL可能是不同的值，下面的截图中TTL是111，如果您也测试一下，您可能发现这个值是150， 170等等，这时不只是源服务器的操作系统，LINUX/UNIX/Windows的初始值起作用，而是在中间网络设备将这个值做过特殊处理。

hma@CNMBP23HMA ~ % ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=111 time=50.109 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=111 time=45.896 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 45.896/48.002/50.109/2.107 ms
hma@CNMBP23HMA ~ %

因此，关于TTL值的局限性，有这样的说法：

准确性有限：
- 由于网络中的路由可能会动态变化，TTL 值推断出的路由信息可能并不完全准确。
- 一些网络设备可能会对 TTL 值进行修改或干扰，导致推断结果不准确。
不完整性：
- 对于一些复杂的网络环境，如使用 VPN（Virtual Private Network）、代理服务器或网络地址转换（NAT）的情况，TTL 值可能无法准确反映真实的路由路径。