Blind Data Injection Attack

     TCP has historically been considered to be protected against spoofedoff-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destinationports) in combination with the 32-bit sequence number(s).  A combination of increasing window

sizes and applications using longer-termconnections (e.g., H-323 or Border Gateway Protocol (BGP) [RFC4271]) have left modern TCP implementations more vulnerable to thesetypes of spoofed packet injection attacks.

     Many of these long-term TCP applications tend to have predictable IPaddresses and ports that makes it far easier for the 4-tuple (4-tupleis the same as the socket pair mentioned in RFC 793) to beguessed.Having guessed the 4-tuple correctly, an attacker can inject a TCPsegment with the RST bit set, the SYN bit set or data into a TCPconnection by systematically guessing the sequence number of thespoofed segment to be in the current receive window.  This can causethe connection to abort or cause data corruption.  This documentspecifies small modifications to the way TCP handles inbound segmentsthat can reduce the chances of a successful attack.

attack method

RST - Where an attacker injects a RST segment hoping to cause the

     connection to be torn down. "RST segment" here refers to a TCPsegment with the RST bit set.

SYN -  Where an attacker injects a SYN hoping tocause the receiverto believe the peer has restarted andtherefore tear down theconnectionstate.  "SYN segment" hererefers to a TCP segment with

SYN bit set.

DATA -  Where an attacker tries to inject a DATAsegment to corruptthe contents of the transmission.  "DATA segment" here refers toany TCP segment containing data.

 

attack goal

      the goal is for theattacker to cause one of the two endpoints of the connection to incorrectly tear downthe connection state, effectively aborting the connection.

tcp:RFC 5961 5.2 Blind Data Injection Attack Mitigation

    RFC 5961 5.2 [Blind DataInjection Attack].[Mitigation] All TCP stacks MAY implement the following mitigation.  TCP stacks  that implement this mitigation MUST add an additional input check to any incoming segment.  The ACKvalue is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=

 SND.NXT).  All incoming segmentswhose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. Move tcp_send_challenge_ack() before tcp_ack() to avoid a forwarddeclaration.

author	Eric Dumazet <[email protected]>	2012-10-21 19:57:11 (GMT)
committer	David S. Miller <[email protected]>	2012-10-22 18:29:06 (GMT)
commit	354e4aa391ed50a4d827ff6fc11e0667d0859b25 (patch)
tree	26a9eab79c239f1e0f27b469a5ed06c9a111a1d2
parent	46baac38ef633b08168d27df7b02eb14578fb760 (diff)
tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation
RFC 5961 5.2 [Blind Data Injection Attack].[Mitigation]

  All TCP stacks MAY implement the following mitigation.  TCP stacks
  that implement this mitigation MUST add an additional input check to
  any incoming segment.  The ACK value is considered acceptable only if
  it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
  SND.NXT).  All incoming segments whose ACK value doesn't satisfy the
  above condition MUST be discarded and an ACK sent back.

Move tcp_send_challenge_ack() before tcp_ack() to avoid a forward
declaration.

Signed-off-by: Eric Dumazet <[email protected]>
Cc: Neal Cardwell <[email protected]>
Cc: Yuchung Cheng <[email protected]>
Cc: Jerry Chu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Diffstat
-rw-r--r--	net/ipv4/tcp_input.c	43	
1 files changed, 25 insertions, 18 deletions
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 432c366..60cf836 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3552,6 +3552,24 @@ static bool tcp_process_frto(struct sock *sk, int flag)
 	return false;
 }
 
+/* RFC 5961 7 [ACK Throttling] */
+static void tcp_send_challenge_ack(struct sock *sk)
+{
+	/* unprotected vars, we dont care of overwrites */
+	static u32 challenge_timestamp;
+	static unsigned int challenge_count;

       /* now的計算是以秒爲單位，所以tcp_send_challenge_ack 函數對於1s秒內前 sysctl_tcp_challenge_ack_limit次的Old ack 回覆ACK處理，之後就不處理了，直接返        * 回，返回的結果是這種類型的old ack無效當做沒有接受處理了。

        */
	u32 now = jiffies / HZ;
+
+	if (now != challenge_timestamp) {
+		challenge_timestamp = now;
+		challenge_count = 0;
+	}
+	if (++challenge_count <= sysctl_tcp_challenge_ack_limit) {
+		NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPCHALLENGEACK);
+		tcp_send_ack(sk);
+	}
+}
+
 /* This routine deals with incoming acks, but not outgoing ones. */
 static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
 {
@@ -3571,8 +3589,14 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
 	/* If the ack is older than previous acks
 	 * then we can probably ignore it.
 	 */
-	if (before(ack, prior_snd_una))
+	if (before(ack, prior_snd_una)) {
+		/* RFC 5961 5.2 [Blind Data Injection Attack].[Mitigation] */

               /*ack應答序號在(SND.UNA - MAX.SND.WND) <= SEG.ACK <=SND.NXT)之外時，表示這個ACK可能有攻擊的嫌疑，需要檢查*/
+		if (before(ack, prior_snd_una - tp->max_window)) {
+			tcp_send_challenge_ack(sk);
+			return -1;
+		}
 		goto old_ack;
+	}
 
 	/* If the ack includes data we haven't sent yet, discard
 	 * this segment (RFC793 Section 3.9).
@@ -5241,23 +5265,6 @@ out:
 }
 #endif /* CONFIG_NET_DMA */
 
-static void tcp_send_challenge_ack(struct sock *sk)
-{
-	/* unprotected vars, we dont care of overwrites */
-	static u32 challenge_timestamp;
-	static unsigned int challenge_count;
-	u32 now = jiffies / HZ;
-
-	if (now != challenge_timestamp) {
-		challenge_timestamp = now;
-		challenge_count = 0;
-	}
-	if (++challenge_count <= sysctl_tcp_challenge_ack_limit) {
-		NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPCHALLENGEACK);
-		tcp_send_ack(sk);
-	}
-}
-
 /* Does PAWS and seqno based validation of an incoming segment, flags will
  * play significant role here.
  */