This paper concerns about the TCP protocol vulnerability which gives space for a DoS (Denial of Service) attack called SYN flood. Discussion of different tcp stack implementations in different operating systems is also provided with sources to patches and further information. Also deeper understanding to the Transmission Control Protocol (TCP) is given. Analysis of the results of the SYN flood attack with logs are provided with explanations. Also working source code both for detecting syn flood attack on network segment and also generating the attack itself.
The Transport Control Protocol (TCP) is connection oriented and reliable, in-sequence delivery transport protocol. It provides full duplex stream of data octets (8-bit bytes). It is the main protocol for the internet and is widely used in extra- and intranets. Most todays services on internet relay on TCP. For example mail (SMTP, port 25), old unsecure virtual terminal service (telnet, port 23), file transport protocol (FTP, port 21) and most important in this case also is the hyper text transfer protocol (HTTP, 80) better known as the world wide web services (WWW). Almost everything uses TCP someway to do their communications over the network - at least the interactive ones. This takes us to the point. What if these services are denied for some reason? SYN flood is one example to this. Let's look at the format of tcp packet.
TCP Header Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header Format.[1]
The underlaying IP packet contains the source ip (internet protocol) address and target ip address. To grant simultaneous access to the TCP module, TCP provides an interface called a port. Ports are used by the kernel to identify network processes from each other. They are strictly transport layer entities. Together with an IP address, a TCP port provides an endpoint for network communications. At any given moment all Internet connections can be described by four numbers. The source IP address and source port and the destination IP address and destination port completes this. Different services are bound to 'well-known' ports so that they may be located on a standard port on different systems.[1]
TCP packet contains unique sequence and acknowledgement numbers compared to other packets in the same connection. The Initial Sequence Number (ISN) is random integer between 0 and 4,294,967,295. After each sent packet the sequence number counter is incremented by one. Data offset tells the current This enables the right ordering of the packets if they get scrambled in the network. From the figure you can see that there is these URG,SYN,ACK,RST,PSH and FIN bits.
The Transport Control Protocol (TCP) is connection oriented protocol and thus uses handsaking to start transmission of data. When two hosts A and B want to make a TCP connection they use three-way handsaking. The TCP packet contains some bits to make some difference between different kind of packets.
1 A ----------------SYN-----------------> B 2 A <---------------SYN/ACK-------------- B 3 A ----------------ACK-----------------> B
At first (1) the client is telling the server that it wants to establish a connection. This is the SYN flag's only purpose. The client then tells the server that the sequence number field is valid, and should be checked. The client sets the sequence number field in the TCP header to it's ISN (Initial Sequence Number). The server, upon receiving this segment (2) responds with it's own ISN (that is why the SYN flag is on) and an acknowledgement (ACK) of the clients first segment (which is the client's ISN+1). The client then sends ACK to the server's ISN (3). Now handsake is completed and connection established. Data transfer may take place. [2]
There are many weaknesses in the TCP protocol and we are going to get deeper with the problem in the handsaking transaction. Consider again the handsaking. What if the machine A sends a fake packet to machine B. Fake because the source address (should be the B's IP address), is unreachable host in this network segment. Target machine B accepts the syn packet and tries to send SYN/ACK packet to the fake address. The answer will never get to the target. Request For Comments file number 1122 (rfc1122) gives good advices:
Address Validation Reject OPEN call to invalid IP address x Reject SYN from invalid IP address x Silently discard SYN to bcast/mcast addr x [3]
Here the x means that it MUST be implemented. Unfortunately as the flood is possible with fake source address (demonstrated below) this address validation schema hasn't been used (except the third one)! The fact that two first advices aren't followed it is possible to to do syn flood DoS attack.
There is also quite similar DoS attack called RST flood which isn't covered in this white paper. By sending RST packets with correct sequence numbers (packets can be sniffed from the network) the activating (in the handsaking phase) tcp connection can be torn down quite effectively. The purpose and effect of this kind of attack is similar to syn flood DoS attack.
As with many other DoS attacks the SYN flood doesn't do any physical damage for the information in the machine. Nor does it make any damage to physical devices. The nature of DoS attacks are to deny something from users or other machines/processes. It may not sound very severe but when you think it more deeply it is very unpleasent effect in the growing and more commercial internet. The www browsers are used almost for every access to internet resources nowadays. WWW services are used more and more. Little by little comes the electronic cash possibilities and other growing services. Browser is the main tool in the internet communications. For example with syn flood you can deny access to the port 80 where the http server resides in a vulnerable machine. The mail server, ftp, telnet and ssh. The list is quite long.
TCP/IP protocol family is old but still suffers in many vulnerabilities. It is easy to get programs from the internet (rootshell) which exploit these bugs in the protocol. Many mailing lists (bugtraq) are quite aware of these bugs and contain fresh information about recent vulnerabilities in many areas including protcoll family in the internet. It's never ending fight between crackers/hackers and administrators/security officers. It is also bit frustrating sometimes to make the operating system secure when there is with high probability more bugs. What about the fact then that everything is almost in computers ... and soon every computer is in the internet. Well let's stay in the subject :)
It is not hard to listen the network. With root access to some machine on the same segment you usually can sniff the whole segments data. This requires a bit capacity from the sniffing machine but packet filtering is usually done quite effectively in the example programs. In the ethernet segment the network interface card is needed to put in promiscuous mode. After that it accepts all ethernet packets in the segment and delivers them to the upper layer.
So what we can do is listen the network and scan for syn packets. Syn flooders can be noticed if the traffic isn't overwhelming. Fact is that the syn packet changes every time (if done a bit wisely). The source port can be changed and also the source address which should still be unreachable from the network segment. Source port is usually somehow random. With randomness the target host can't filter away packets from specific ports or hosts.
There is possibilities to block the attack as it has been done for many operating systems allready. A way to fix this is to increase the kernel maximum number of half open connections allowed (SO_MAXCONN) higher number than the default value. A program could scan the syn packets that do not get followed with ACK and clean the half open connections by sending a RST packet. This frees the port and allows connections to happen again. [4]
There is patches and information for many operating systems and from different endors
Internet is full of different kinds of programs and hacks/cracks. Take your favourite search engine and be smart when you use those key words.
I downloaded several programs from the internet but used only two of them actively. They were all quite similar and mainly for two purposes: detecting and generating syn flood. The source code from the great magazine, phrack issue 48 was a bit modified so it didn't work at first. I also modified a bit the code. The sniffer I used to catch the syn packets and log them was SYNWatch . There is something wrong with the source port numbers with this program. This can be seen when comparing the netstat output and log entries. Otherwise it works just fine. I didn't have time to correct the problem in SYNWatch as it wasn't a big deal in my experiments (ports could be verified with netstat on the target machines except NT).
Linux version 2.0.30 I attacked had a patch for syn flood attack. This means that the service flooded is still available even the flood is going on. When I flooded the port 22 the netstat output was like this for the ssh service (port 22).
Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 1 10.0.0.61:22 10.0.0.100:57441 SYN_RECV tcp 0 1 10.0.0.61:22 10.0.0.100:57697 SYN_RECV tcp 0 1 10.0.0.61:22 10.0.0.100:57953 SYN_RECV tcp 0 1 10.0.0.61:22 10.0.0.100:58209 SYN_RECV tcp 0 1 10.0.0.61:22 10.0.0.100:58465 SYN_RECV
And few lines from log:
... Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.61 sport: 101 dport: 22 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.61 sport: 101 dport: 22 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.61 sport: 101 dport: 22 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.61 sport: 101 dport: 22 ...
I could still log in with ssh from another machine with no problem or delay. So this DoS attack doesn't affect anymore in version 2.0.30 of Linux. This is true because the patch came already to the previous kernel version 2.0.29. What we can learn from these lines is that the backlog queue with ssh in Linux machine is 5 structures.
Windows NT 4.0 (10.0.0.31) was vulnerable to syn flood attack. Here is the state of the machine before syn flood.
Reported on \\PAPPI
Date: 3/30/98
Time: 9:14:12 PM
Data: Current
Activity Interval: 5.000 seconds
Computer: \\PAPPI
Object: TCP
Connection Failures 0.000
Connections Active 10.000
Connections Established 11.000
Connections Passive 6.000
Connections Reset 0.000
Object: Server
Sessions Errored Out 0.000
Sessions Forced Off 0.000
Sessions Logged Off 0.000
Sessions Timed Out 0.000
Object: Memory
Pool Paged Allocs 7967.000
Pool Paged Bytes 5701632.000
Available Bytes 24510464.000
Object: Process _Total SNMP tcpsvcs
% Processor Time 100.000 0.000 0.000
Object: Processor
Interrupts/sec 154.974
% User Time 3.200
% Processor Time 14.000 Object: System
System Calls/sec 5262.719
Total Interrupts/sec 154.974
I flooded different ports and different amounts of packets from 10.0.0.61 to this machine 10.0.0.31. NT had http-server which couldn't handle connections while in flood loop (flooding port 80). Quite amazing is that NT came up more quickly than Solaris 2.5. Here is the report after playing a bit with syn packets:
Reported on \\PAPPI
Date: 3/30/98
Time: 9:31:40 PM
Data: Current
Activity Interval: 1.000 seconds
Computer: \\PAPPI
Object: TCP
Connection Failures 400.000
Connections Active 14.000
Connections Established 4.000
Connections Passive 603.000
Connections Reset 3.000
Object: Server
Sessions Errored Out 0.000
Sessions Forced Off 0.000
Sessions Logged Off 2.000
Sessions Timed Out 0.000
Object: Memory
Pool Paged Allocs 8086.000
Pool Paged Bytes 5808128.000
Available Bytes 23490560.000
Object: Process _Total SNMP tcpsvcs
% Processor Time 99.964 0.000 0.000
Object: Processor
Interrupts/sec 109.795
% User Time 1.000
% Processor Time 4.034 Object: System
System Calls/sec 616.846
Total Interrupts/sec 109.795
And a little piece of log also:
... Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 110 dport: 80 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 110 dport: 80 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 110 dport: 80 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 110 dport: 80 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 110 dport: 80 ...Two flooders at the same time
... Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 91 dport: 64 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 98 dport: 40 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 91 dport: 64 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 98 dport: 40 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 91 dport: 64 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 98 dport: 40 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 91 dport: 64 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.31 sport: 98 dport: 40 ...
While NT 4.0 was still vulnerable to this kind of attack, it handles
the situation more quickly than Solaris 2.5 which has bigger
expiration time in TCP stack for syn packets.
I couldn't get in this machine (account wasn't configured and I was too busy for hacking into a FreeBSD :). Of course I could send packets to the machine and then test the result by trying to connect the specific port. I flooded the telnet port (23) with continous flood and then tried to connect to the machine (10.0.0.41). Connection was succesfull. This means that FreeBSD isn't vulnerable to this kind of DoS attack anymore.
Here is some log lines...... Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.41 sport: 113 dport: 23 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.41 sport: 113 dport: 23 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.41 sport: 113 dport: 23 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.41 sport: 113 dport: 23 Thu Jan 1 02:25:40: SYN Received: saddr:10.0.0.100 daddr: 10.0.0.41 sport: 113 dport: 23 ...
It was a pleasure to notice that there was not much to do when the target host was vulnerable. Complete denial of service. Doesn't use much network capacity and is very efficient. The timings can be adjusted so that only minimum amount of packets will be send with maximum time interval. Hard to notice if can't figure out possible attack.
It is important to notice this fact that SYN flooding requires so small amount of network traffic and is still effective. When considering other network DoS attacks such as ICMP_ECHO floods (ping floods), mail bombs, mass mailing list subscriptions and others to be effective, all of these attacks require an attacker to transmit huge amounts of network traffic. Not only does this make these attacks more noticable on both ends by decreasing the amount of available bandwidth but it also adds to the general traffic problems of the Internet. "SYN flooding can be deadly effective with as little as 360 packets/hour." [2]
Every time a client SYN arrives on a valid port (a port where a TCP server is listen()ing), a backlog structure must be allocated. If there were no limit, a busy host could easily exhuast all of it's memory just trying to process TCP connections. However, there is an upper limit to amount of concurrent connection requests a given TCP can have outstanding for a given socket. This limit is the backlog and it is the length of the queue where incoming (as yet incomplete) connections are kept. This queue limit applies to both the number of imcomplete connections and the number of completed connections that have not been pulled from the queue by the application by way of the accept() call. If this backlog limit is reached, we will see that TCP will silently discard all incoming connection requests until the pending connections can be dealt with. [2]
And some common values of backlogs from the phrack 48 magazine for comparison to my own tests:
OS Backlog BL+Grace Notes ---------------------------------------------------------------------- SunOS 4.x.x: 5 8 IRIX 5.2: 5 8 Solaris Linux 1.2.x: 10 10 Linux does not have this grace margin. FreeBSD 2.1.0: 32 FreeBSD 2.1.5: 128 Win NTs 3.5.1: 6 6 NT does not appear to have this margin. Win NTw 4.0: 6 6 NT has a pathetic backlog. [2]
I have the values for Solaris 2.5 a little bit upper. It is also interesting to notice that different servers had different effects to the maximum available connections in Solaris and Linux.
Patches are available for many operating systems which you can notice from upper part of this paper. These correct the problem with quite nice solutions but are still a bit workarounds for the protocol. TCP protocol still has the vulnerabilities. In RFC1122 (reference number 3) there are many good suggestions for better tcp/ip implementations and advices also for different layers of the internetworking model.
Yes, there is this next generation internet protocol (IPv6) with IPSec and so on. It will also correct this problem and many others which are specific for ip version 4.
It was nice to get "hands on" work with special laboratory network where there was different machines with different operating systems. I didn't have very much time for doing this but the tests were interesting and joyfull to do. It is also noticeable that it's not hard to do these kind of attacks when you have the access to the internet. From there you can find with a bit searching plenty of stuff to use. But most interesting and challenging is to find out yourself the bugs and other holes!