TCP挑战ACK报文限速

 

PROC文件tcp_challenge_ack_limit控制每秒钟发送挑战ACK报文的数量。避免遭受Blind In-Window Attacks，包括reset，sync或者数据注入攻击等，详解RFC5961。

初始化

在TCP协议初始化函数tcp_sk_init中赋值为1000。通过PROC文件tcp_challenge_ack_limit可查看此值，并可进行修改。

static int __net_init tcp_sk_init(struct net *net)
{
    /* rfc5961 challenge ack rate limiting */
    net->ipv4.sysctl_tcp_challenge_ack_limit = 1000;
}
$ cat /proc/sys/net/ipv4/tcp_challenge_ack_limit
1000

挑战ACK发送控制
 

核心函数tcp_send_challenge_ack如下。如果挑战ACK报文要能够发送，必须首先满足tcp_invalid_ratelimit变量定义的时间间隔，默认为HZ的一半即500毫秒。详情参见：https://blog.csdn.net/sinat_20184565/article/details/89481607。

算法如下：在首次进入此函数时，挑战时间戳和挑战次数都为空，获取到当前的时间（now的单位秒），此时now必定不等于挑战时间戳，将挑战次数初始化为tcp_challenge_ack_limit设定值的一半，与零至tcp_challenge_ack_limit值之间的随机值的和，并且初始化挑战时间戳。之后，如果再次进入函数时，当前时间还在同一秒内，判断挑战次数是否为零，不成立递减挑战次数，发送挑战ACK报文。

如果再次进入函数时，当前时间已经进入下一秒，重新初始化挑战次数challenge_count和挑战时间戳challenge_timestamp。在同一秒钟内，已经发送了超过挑战次数的ACK报文后，不在发送挑战ACK报文。

/* RFC 5961 7 [ACK Throttling] */
static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb)
{
    static u32 challenge_timestamp;
    static unsigned int challenge_count;

    /* First check our per-socket dupack rate limit. */
    if (__tcp_oow_rate_limited(net, LINUX_MIB_TCPACKSKIPPEDCHALLENGE, &tp->last_oow_ack_time))
        return;

    /* Then check host-wide RFC 5961 rate limit. */
    now = jiffies / HZ;
    if (now != challenge_timestamp) {
        u32 ack_limit = net->ipv4.sysctl_tcp_challenge_ack_limit;
        u32 half = (ack_limit + 1) >> 1;

        challenge_timestamp = now;
        WRITE_ONCE(challenge_count, half + prandom_u32_max(ack_limit));
    }
    count = READ_ONCE(challenge_count);
    if (count > 0) {
        WRITE_ONCE(challenge_count, count - 1);
        NET_INC_STATS(net, LINUX_MIB_TCPCHALLENGEACK);
        tcp_send_ack(sk);
    }
}

 

数据注入攻击

如果接收报文的确认序号小于本地套接口待确认序号，表明为一个已经确认过的序号，并且其确认序号在套接口当前待确认序号减去本地发送窗口之前，内核认为此报文很可能并非对端发送，即其为攻击者构造出来的报文，合法的报文确认序号ACK的范围：((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT)。否则，不在此范围内认为是盲数据注入攻击Blind Data Injection Attack。但是，有可能并非攻击者发送，而是来自对端的报文，此时回复挑战ACK报文，使对端有机会修正其确认序号ACK。

按照RFC5961的描述，为应对数据注入攻击，进一步缩小合法确认序号ACK的范围，要求报文中的确认序号大于套接口第一个待确认序号。合法的报文确认序号范围：(SND.UNA <= SEG.ACK <= SND.NXT)。内核不处理无效确认序号的报文，避免注入非法数据。

static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
{
    u32 prior_snd_una = tp->snd_una;

    /* If the ack is older than previous acks then we can probably ignore it. */
    if (before(ack, prior_snd_una)) {
        /* RFC 5961 5.2 [Blind Data Injection Attack].[Mitigation] */
        if (before(ack, prior_snd_una - tp->max_window)) {
            if (!(flag & FLAG_NO_CHALLENGE_ACK))
                tcp_send_challenge_ack(sk, skb);
            return -1;
        }
        goto old_ack;
    }
    if (after(ack, tp->snd_nxt))
        goto invalid_ack;
	
old_ack:

    SOCK_DEBUG(sk, "Ack %u before %u:%u\n", ack, tp->snd_una, tp->snd_nxt);
    return 0;
}

 

复位RST攻击

如下的TCP报文检查函数tcp_validate_incoming。
为应对攻击者伪造的RST报文，对于TCP头部标志设置了reset位的报文，仅当其序号等于本端套接口待接收的序号时（增加攻击者猜测的序号的难度），或者tcp_reset_check函数结果为真时（其判读RST是否紧随之前的一个FIN报文），本端才可复位此连接。另外一种情况是，当启用SACK时，仅当报文序号等于所有SACK块中最大的数据序号时，本端可复位此连接。

以上条件都不成立，内核认为不合法的RST报文或者为恶意的RST攻击，回应挑战ACK报文，以使得发送不合法报文的对端得以恢复。

static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb, const struct tcphdr *th, int syn_inerr)
{
    /* Step 2: check RST bit */
    if (th->rst) {
        if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt || tcp_reset_check(sk, skb)) {
            rst_seq_match = true;
        } else if (tcp_is_sack(tp) && tp->rx_opt.num_sacks > 0) {
            struct tcp_sack_block *sp = &tp->selective_acks[0];
            int max_sack = sp[0].end_seq;

            for (this_sack = 1; this_sack < tp->rx_opt.num_sacks; ++this_sack) {
                max_sack = after(sp[this_sack].end_seq, max_sack) ? sp[this_sack].end_seq : max_sack;
            }
            if (TCP_SKB_CB(skb)->seq == max_sack)
                rst_seq_match = true;
        }

        if (rst_seq_match)
            tcp_reset(sk);
        else {
            /* Disable TFO if RST is out-of-order and no data has been received for current active TFO socket */
            if (tp->syn_fastopen && !tp->data_segs_in && sk->sk_state == TCP_ESTABLISHED)
                tcp_fastopen_active_disable(sk);
            tcp_send_challenge_ack(sk, skb);
        }
        goto discard;
    }
}

如果RST报文的序号不等于套接口的待接收序号，当时等于待接收序号减一，并且套接口之前接收到了FIN报文，对于主动关闭端，接收到FIN报文之后将进入TCPF_CLOSING状态。对于被动关闭端，接收到FIN报文之后，进入TCPF_CLOSE_WAIT状态，在套接口close之后，转换到TCPF_LAST_ACK状态。

根据内核的注释，对于Mac OSX系统中意外结束的TCP连接（Ctrl+C），OSX将接连发送FIN和RST报文，并且RST报文的序号等于之前的FIN报文序号。

static bool tcp_reset_check(const struct sock *sk, const struct sk_buff *skb)
{
    struct tcp_sock *tp = tcp_sk(sk);
    return unlikely(TCP_SKB_CB(skb)->seq == (tp->rcv_nxt - 1) &&
            (1 << sk->sk_state) & (TCPF_CLOSE_WAIT | TCPF_LAST_ACK | TCPF_CLOSING));
}

 

SYN攻击

对于处在连接阶段的TCP连接，未避免攻击者伪造SYN报文导致接收端误以为对端连接已关闭，需要重新建立而导致的RST报文发送问题，内核改为对接收到的SYN报文不管其序号是否合法，仅回复挑战ACK报文，内容如下：<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>。如果对端确实要重新开始新的连接，在接收到挑战ACK报文之后，可根据其中的确认序号构造一个合法的RST报文先关闭之前的连接。如此处理，攻击者伪造的SYN报文将不能够复位存在的链接了。

static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb, const struct tcphdr *th, int syn_inerr)
{
    /* Step 1: check sequence number */
    if (!tcp_sequence(tp, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq)) {
        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:
        tcp_send_challenge_ack(sk, skb);
        goto discard;
    }
}

 

以上处理，有一个小的弊端，当对端意外重启之后，如果使用相同的TCP的IP地址和端口号重新发起连接，发送SYN报文，并且，其初始序号选择了RCV.NXT-1的值，加入本端的连接还在，等接收到此SYN报文时，将回复挑战ACK报文，其确认序号为RCV.NXT，但是当对端接收到此挑战ACK报文，因为其正好确认了之前发送的SYN报文，对端并不会发送RST报文结束重启之前的连接。导致新连接一直建立不起来，要等到SYN报文超时。不过这属于非常极端情况。

 

内核版本 4.15