阅读 1125

ESTABLISHED 状态的连接收到 SYN 会回复什么?

最初这个问题是读者在我的 TCP 掘金小册的《TCP RST 攻击与如何杀掉一条 TCP 连接》小节中的一个留言提出的:「处于 ESTABLISHED 的连接,为什么还要响应 SYN 包?」,这篇文章就来聊聊这一部分的内容。

通过阅读这篇文章,你会了解到这些知识

  • ESTABLISHED 状态的连接收到乱序包会回复什么
  • Challenge ACK 的概念
  • ACK 报文限速是什么鬼
  • SystemTap 工具在 linux 内核追踪中的使用
  • 包注入神器 scapy 的使用
  • RST 攻击的原理
  • killcx 等工具利用 RST 攻击的方式来杀掉连接的原理

接下来开始文章的内容。

scapy 实验复现现象

实验步骤如下:

在机器 A(10.211.55.10) 使用 nc 启动一个服务程序,监听 9090 端口,如下所示。

nc -4 -l 9090
复制代码

机器 A 上同步使用 tcpdump 抓包,其中 -S 表示显示绝对序列号。

sudo tcpdump -i any port 9090 -nn  -S
复制代码

在机器 B 使用 nc 命令连接机器 A 的 nc 服务器,输入 "hello" 。

nc 10.211.55.10 9090
复制代码

使用 netstat 可以看到此次连接的信息。

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 10.211.55.10:9090       10.211.55.20:50718      ESTABLISHED 9029/nc
复制代码

在机器 B 上使用 scapy,模拟发送 SYN 包,scapy 脚本如下所示。

send(IP(dst="10.211.55.10")/TCP(sport=50718, dport=9090, seq=10, flags='S'))
复制代码

源端口号 sport 使用此次连接的临时端口号 50718,序列号随便写一个,这里 seq 为 10。

执行 scapy 执行上面的代码,tcpdump 中显示的包结果如下。

// nc 终端中 hello 请求包
18:41:51.956735 IP 10.211.55.20.50718 > 10.211.55.10.9090: Flags [P.], seq 3219267420:3219267426, ack 2848436085, win 229, options [nop,nop,TS val 1094540820 ecr 12823113], length 6
18:41:51.956787 IP 10.211.55.10.9090 > 10.211.55.20.50718: Flags [.], ack 3219267426, win 227, options [nop,nop,TS val 12827910 ecr 1094540820], length 0

// scapy 的 SYN 包
18:44:32.373331 IP 10.211.55.20.50718 > 10.211.55.10.9090: Flags [S], seq 10, win 8192, length 0
18:44:32.373366 IP 10.211.55.10.9090 > 10.211.55.20.50718: Flags [.], ack 3219267426, win 227, options [nop,nop,TS val 12988327 ecr 1094540820], length 0
复制代码

可以看到,对于一个 SEQ 为随意的 SYN 包,TCP 回复了正确的 ACK 包,其确认号为 3219267426。

从 rfc793 文档中也可以看到:

Linux 内核对于收到的乱序 SYN 报文,会回复一个携带了正确序列号和确认号的 ACK 报文。

这个 ACK 被称之为 Challenge ACK。

我们后面要介绍的杀掉连接工具 killcx 的原理,正是是基于这一点。

原因分析

为了方便说明,我们记发送 SYN 报文的一端为 A,处于 ESTABLISHED 状态接收 SYN 报文的一端为 B,B 对收到的 SYN 包回复 ACK 的原因是想让对端 A 确认之前的连接是否已经失效,以便做出一些处理。

对于 A 而已,如果之前的连接还在,对于收到的 ACK 包,正常处理即可,不再讨论。

如果 A 之前的此条连接已经不在了,此次 SYN 包是想发起新的连接,对于收到的 ACK 包,会立即回复一个 RST,且 RST 包的序列号就等于 ACK 包的序列号,B 收到这个合法的 RST 包以后,就会将连接释放。A 此时若想继续与 B 创建连接,则可以选择再次发送 SYN 包,重新建连,如下图所示。

estab_syn

接下来我们来看内核源码的处理,

内核源码分析

在这之前,我们需要先了解 SystemTap 工具的使用。SystemTap 是 Linux 中非常强大的调试探针工具,类似于 java 中的 javaagent instrument,可以获取一个内核函数运行时的入参变量、返回值、调用堆栈,甚至可以直接修改变量的值。这个工具详细的使用这里不展开,感兴趣的同学可以自行 Google。

接下来我们来使用 SystemTap 这个工具来给内核插入 probe 探针,以 3.10.0 内核为例,内核中回复的 ack 的函数在 net/ipv4/tcp_output.c 的 tcp_send_ack 中实现。我们给这个函数插入调用探针,在端口号为 9090 时打印调用堆栈。新建一个 ack_test.stp 文件,部分代码如下所示。

%{
#include <net/sock.h>
#include <linux/tcp.h>
#include <linux/skbuff.h>
#include <net/route.h>
%}

function tcp_src_port:long(sk:long)
{
	return __tcp_sock_sport(sk)
}
function tcp_dst_port:long(sk:long)
{
	return __tcp_sock_dport(sk)
}
function tcp_src_addr:long(sk:long)
{
	return ntohl(__ip_sock_saddr(sk))
}
function tcp_dst_addr:long(sk:long)
{
	return ntohl(__ip_sock_daddr(sk))
}
function str_addr:string(addr, port) {
        return sprintf("%d.%d.%d.%d:%d",
                       (addr & 0xff000000) >> 24,
                       (addr & 0x00ff0000) >> 16,
                       (addr & 0x0000ff00) >> 8,
                       (addr & 0x000000ff),
                       port
                )
}

probe kernel.function("tcp_send_ack@net/ipv4/tcp_output.c")
{
       src_addr = tcp_src_addr($sk);
       src_port = tcp_src_port($sk);
       dst_addr = tcp_dst_addr($sk);
       dst_port = tcp_dst_port($sk);
       if (dst_port == 9090 || src_port == 9090)
       {
              printf("send ack : %s:->%s\n",
                     str_addr(src_addr, src_port),
                     str_addr(dst_addr, dst_port));
              print_backtrace();
       }
}
复制代码

使用 stap 命令执行上面的脚本

sudo stap -g ack_test.stp

复制代码

再次使用 scapy 发送一个 syn 包,内核同样会回复 ACK,此时 stap 输出结果如下。

send ack : 10.211.55.10:9090:->10.211.55.20:50718
 0xffffffff815d0940 : tcp_send_ack+0x0/0x170 [kernel]
 0xffffffff815cb1d2 : tcp_validate_incoming+0x212/0x2d0 [kernel]
 0xffffffff815cb44d : tcp_rcv_established+0x1bd/0x760 [kernel]
 0xffffffff815d5f8a : tcp_v4_do_rcv+0x10a/0x340 [kernel]
 0xffffffff815d76d9 : tcp_v4_rcv+0x799/0x9a0 [kernel]
 0xffffffff815b1094 : ip_local_deliver_finish+0xb4/0x1f0 [kernel]
 0xffffffff815b1379 : ip_local_deliver+0x59/0xd0 [kernel]
 0xffffffff815b0d1a : ip_rcv_finish+0x8a/0x350 [kernel]
 0xffffffff815b16a6 : ip_rcv+0x2b6/0x410 [kernel]
复制代码

可以看到这个 ACK 经过了下面这些函数调用。

tcp_v4_rcv
  -> tcp_v4_do_rcv
    -> tcp_rcv_established
      -> tcp_validate_incoming
        -> tcp_send_ack
复制代码

tcp_validate_incoming 函数精简后的部分代码如下所示。

static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
				  const struct tcphdr *th)
{	
	// seq 不在窗口内
	/* Step 1: check sequence number */
	if (!tcp_sequence(tp, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq)) {
		// RST 标记没有设置
		if (!th->rst) {
			if (th->syn)
				goto syn_challenge;
		}
		goto discard;
	}
	
	/* step 4: Check for a SYN。 RFC 5961 4.2 : Send a challenge ack */
	if (th->syn) {
syn_challenge: // 处理 SYN Challenge 的情况
		tcp_send_challenge_ack(sk, skb); // 
		goto discard;
	}
复制代码

tcp_send_challenge_ack 函数真正调用了 tcp_send_ack 函数。 这里的注释提到了 RFC 5961 4.2,说的正是 Challenge ACK 相关的内容。

如果攻击者疯狂发送假的乱序包,接收端也跟着回复 Challenge ACK,会耗费大量的 CPU 和带宽资源。于是 RFC 5961 提出了 ACK Throttling 方案,限制了每秒钟发送 Challenge ACK 报文的数量,这个值由 net.ipv4.tcp_challenge_ack_limit 系统变量决定,默认值是 1000,也就是 1s 内最多允许 1000 个 Challenge ACK 报文。

接下来使用 sysctl 将这个值改小为 1,如下所示。

sudo sysctl -w net.ipv4.tcp_challenge_ack_limit="1"
复制代码

这样理论上在一秒内多次发送一个 Challenge ACK 包,接下来使用 scapy 在短时间内发送 5 次 SYN 包,看看内核是否只会回复一个 ACK 包,scapy 的脚本如下所示。

send(IP(dst="10.211.55.10")/TCP(sport=50718,dport=9090,seq=10,flags='S'), loop=0, count=5)
复制代码

tcpdump 抓包结果如下。

03:40:30.970682 IP 10.211.55.20.50718 > 10.211.55.10.9090: Flags [S], seq 10, win 8192, length 0
03:40:30.970771 IP 10.211.55.10.9090 > 10.211.55.20.50718: Flags [.], ack 3219267426, win 227, options [nop,nop,TS val 45146923 ecr 1094540820], length 0
03:40:30.974889 IP 10.211.55.20.50718 > 10.211.55.10.9090: Flags [S], seq 10, win 8192, length 0
03:40:30.975004 IP 10.211.55.20.50718 > 10.211.55.10.9090: Flags [S], seq 10, win 8192, length 0
03:40:30.978643 IP 10.211.55.20.50718 > 10.211.55.10.9090: Flags [S], seq 10, win 8192, length 0
03:40:30.981987 IP 10.211.55.20.50718 > 10.211.55.10.9090: Flags [S], seq 10, win 8192, length 0
复制代码

可以看到确实是只对第一个 SYN 包回复了一个 ACK 包,其它的四个 SYN 都没有回复 ACK。

RST 攻击

RST 攻击也称为伪造 TCP 重置报文攻击,通过伪造 RST 报文来关闭掉一个正常的连接。

源 IP 地址伪造非常容易,不容易被伪造的是序列号,RST 攻击最重要的一点就是构造的包的序列号要落在对方的滑动窗口内,否则这个 RST 包会被忽略掉,达不到攻击的效果。

下面我们用实验演示不在滑动窗口内的 RST 包会被忽略的情况,完整的代码见:rst_out_of_window.pkt github.com/arthur-zhan…

+0 < S 0:0(0) win 32792 <mss 1460> 
+0 > S. 0:0(0) ack 1 <...>
+.1 < . 1:1(0) ack 1 win 65535 
+0 accept(3, ..., ...) = 4

// 不在窗口内的 RST
+.010 < R. 29202:29202(0) ack 1 win 65535

// 如果上面的 RST 包落在窗口内,连接会被重置,下面的写入不会成功
+.010 write(4, ..., 1000) = 1000 

// 断言服务端会发出下面的数据包
+0 > P. 1:1001(1000) ack 1 <...>
复制代码

执行上面的脚本,抓包的结果如下,完整的包见:rst_out_of_window.pcap github.com/arthur-zhan…

抓包文件中的第 5 个包可以看到,write 调用成功,1000 字节发送成功,write 调用并没有收到 RST 包的影响。

下面来介绍两个工具,利用 RST 攻击的方式来杀掉一条连接。

工具一:tcpkill 工具使用及原理介绍

Centos 下安装 tcpkill 命令步骤如下

yum install epel-release -y
yum install dsniff -y
复制代码

实验步骤: 1、机器 c2(10.211.55.10) 启动 nc 命令监听 8080 端口,充当服务器端,记为 B

nc -l 8080
复制代码

2、机器 c2 启动 tcpdump 抓包

sudo tcpdump -i any port 8080 -nn -U -vvv -w test.pcap
复制代码

3、本地机器终端(10.211.55.2,记为 A)使用 nc 与 B 的 8080 端口建立 TCP 连接

nc c2 8080
复制代码

在服务端 B 机器上可以看到这条 TCP 连接

netstat -nat | grep -i 8080
tcp        0      0 10.211.55.10:8080       10.211.55.2:60086       ESTABLISHED
复制代码

4、启动 tcpkill

sudo tcpkill -i eth0 port 8080
复制代码

注意这个时候 tcp 连接依旧安然无恙,并没有被杀掉。

5、在本地机器终端 nc 命令行中随便输入一点什么,这里输入hello,发现这时服务端和客户端的 nc 进程已经退出了

下面来分析抓包文件,这个文件可以从我的 github 下载 tcpkill.pcap

可以看到,tcpkill 假冒了 A 和 B 的 IP发送了 RST 包给通信的双方,那问题来了,伪造 ip 很简单,它是怎么知道当前会话的序列号的呢?

tcpkill 的原理跟 tcpdump 差不多,会通过 libpcap 库抓取符合条件的包。 因此只有有数据传输的 tcp 连接它才可以拿到当前会话的序列号,通过这个序列号伪造 IP 发送符合条件的 RST 包。

原理如下图所示

可以看到 tcpkill 对每个端发送了 3 个RST 包,这是因为在高速数据传输的连接上,根据当前抓的包计算的序列号可能已经不再 TCP 连接的窗口内了,这种情况下 RST 包会被忽略,因此默认情况下 tcpkill 未雨绸缪往后计算了几个序列号。还可以指定参数-n指定更多的 RST 包,比如tcpkill -9

根据上面的分析 tcpkill 的局限还是很明显的,无法杀掉一条僵死连接,下面我们介绍一个新的工具 killcx,看看它是如何来处理这种情况的。

工具二:killcx

killcx 是一个用 perl 写的在 linux 下可以关闭 TCP 连接的脚本,无论 TCP 连接处于什么状态。

下面来做一下实验,实验的前几步骤跟第一个例子中一模一样

1、机器 c2(10.211.55.10) 启动 nc 命令监听 8080 端口,充当服务器端,记为 B

nc -l 8080
复制代码

2、机器 c2 启动 tcpdump 抓包

sudo tcpdump -i any port 8080 -nn -U -vvv -w test.pcap
复制代码

3、本地机器终端(10.211.55.2,记为 A)使用 nc 与 B 的 8080 端口建立 TCP 连接

nc c2 8080
复制代码

在服务端 B 机器上可以看到这条 TCP 连接

netstat -nat | grep -i 8080
tcp        0      0 10.211.55.10:8080       10.211.55.2:61632       ESTABLISHED
复制代码

4、客户端 A nc 命令行随便输入什么,这一步也完全可以省略,这里输入"hello\n"

5、执行 killcx 命令,注意 killcx 是在步骤 4 之后执行的

sudo ./killcx 10.211.55.2:61632
复制代码

可以看到服务端和客户端的 nc 进程已经退出了。

抓包的结果如下

前 5 个包都很正常,三次握手加上一次数据传输,有趣的事情从第 6 个包开始

  • 第 6 个包是 killcx 伪造 IP 向服务端 B 发送的一个 SYN 包
  • 第 7 个包是服务端 B 回复的 ACK 包,里面包含的 SEQ 和 ACK 号
  • 第 8 个包是 killcx 伪造 IP 向服务端 B 发送的 RST 包
  • 第 9 个包是 killcx 伪造 IP 向客户端 A 发送的 RST 包

整个过程如下图所示

小结

这篇文章介绍了为什么 ESTABLISHED 状态连接的需要对 SYN 包做出响应,Challenge ACK 是什么,使用 scapy 复现了现象,演示了 SystemTap 内核探针调试工具的使用,最后通过修改系统变量复现了 ACK 限速。

文章的最后介绍了杀掉 TCP 连接的两个工具 tcpkill 和 killcx:

  • tcpkill 采用了比较保守的方式,抓取流量等有新包到来的时候,获取 SEQ/ACK 号,这种方式只能杀掉有数据传输的连接
  • killcx 采用了更加主动的方式,主动发送 SYN 包获取 SEQ/ACK 号,这种方式活跃和非活跃的连接都可以杀掉

有问题可以扫描下面的二维码关注我的公众号到联系我。