TCP SYN flood - USC/ISI
This exercise demonstrates a well-known denial-of-service attack, called TCP SYN flood
. Students will be able to create a real attack using DETER tools, and to observe its effect on legitimate traffic. Afterwards, they will be asked to apply a known defense against SYN flood known as SYN cookies
, repeat the attack and observe the protection.
This exercise helps students learn the following concepts: (1) How TCP/IP works and how its design can be misused for attacks, (2) How easy it is to perpetrate a DoS attack, with fully legitimate traffic and at a low rate, (3) How easy it is to protect machines from this type of attacks via built-in OS mechanisms. Additionally, extra credit questions improve a student's understanding of how networks and TCP/IP work.
All students should have completed an introductory networking course with grade B or better.
Denial of service attacks deny service to legitimate clients by tying up resources at the server with a flood of legiitmate-looking service requests or junk traffic. Before proceeding to the assignment instructions make sure that you understand how TCP SYN flood attack works, which resource it ties up and how, and how syncookies help mitigate this attack.
Each student should load the topology file /share/education/TCPSYNFlood_USC_ISI/synflood.ns
into the DETER testbed to create a new experiment. Do not modify the topology file
but read it through and identify what each directive does.
Once an experiment is swapped in, install Apache on the server node by typing on server node
Similarly, install an attack tool called "flooder" on the attacker node by typing on attacker node
Generating legitimate traffic
Create a Web traffic stream between the client and the server nodes by writing a script at the client that each second gets index.html from the server. You can for example write this script using bash and curl.
Turning off SYN cookies
SYN cookies are often on by default in Linux and FreeBSD. To check if they are on do the following:
sudo sysctl net.ipv4.tcp_syncookies
If you see 1 as the result, SYN cookies must be set to zero for the demo to work. Type the following on the server
sudo sysctl -w net.ipv4.tcp_syncookies=0
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=10000
Verify that SYN cookies are now off by typing on the server
sudo sysctl net.ipv4.tcp_syncookies
Generating attack traffic
Create a SYN flood between the attacker and the server nodes, using the Flooder tool. You can type "flooder" on the attacker node's command line to get a man page for the tool. Examples at this page show how to write a command to send a flood of SYN packets. Make sure to spoof within 22.214.171.124 range (use mask 255.255.255.0).
You will now collect tcpdump
statistics on client
machine with and without syncookies, calculate connection duration and draw graphs of connection duration on y-axis and connection start time on x-axis. Perform the following steps:
- Stop all traffic by stopping your legitimate client's script and flooder.
- Start tcpdump on the client
ip route get 126.96.36.199
You should see something like this as a result:
188.8.131.52 via 184.108.40.206 dev eth2 src 220.127.116.11
cache mtu 1500 advmss 1460 metric 10 64
Thus the interface name leading to 18.104.22.168 is eth2. To see the traffic flowing type:
sudo tcpdump -nn -i eth2
then generate some traffic, restart your client. You will need to discover proper tcpdump options to see only IP traffic and to save recorded traffic into a file. Start tcpdump with these options.
Using a stopwatch perform the following scenario:
- Start legitimate traffic
- After 30 seconds start the attack
- After 120 seconds stop the attack
- After 30 seconds stop the legitimate traffic
- Stop the tcpdump on the client and save the file
- Turn the SYN cookies on and repeat the above steps.
- Using the recorded traffic files and tcpdump to read them, process the output and calculate connection duration for each TCP connection seen in the files.
Connection duration is the difference between the time of the first SYN and of the ACK following a FIN-ACK (or between the first SYN and the first RESET) on a connection. Recall what uniquely identifies a TCP connection, i.e. how to detect packets that belong to the same connection? If a connection did not end with a FIN or a RST, assign to it the duration of 200 s.
What can go wrong
- Experiment cannot be swapped in. First, check the error message you will receive in the email. One possible reason for this is that the NS file was changed from the one listed above. Verify that the file looks exactly like supplied with this exercise. Another reason may be that there is a lack of available nodes in DETER and the error message will say so. This happens ocassionally and usually resources become available in a few hours. If you tried several times and could not find enough resources or could not diagnose why the experiment was not swapping in, forward the error message you get from DETER to your TA.
There are two extra-credit questions:
- Remove spoofing from the attack. Repeat the exercise without SYN cookies and observe and explain the effect. What happens? Can you explain why this happens? For hints run a tcpdump on the server node and look for traffic patterns. Can you modify the attack so that it is effective without spoofing and how would you do this?
- Modify the NS file to introduce point-to-point routes, using the Modify Experiment option. Hint, you need to remove the server's route to lan1 and to add routes from the server to the attacker, and from the server to the client. Then click on Submit. It will take several minutes for the experiment to be restarted and you will receive an email notification once this is done. Now repeat the exercise without SYN cookies and observe and explain the effect. What happens? Can you explain why this happens? For hints run a tcpdump on the server node and look for traffic patterns.
You should submit a Word document with the following items (label each section):
- Explanation how the TCP SYN flood attack works.
- Explanation how SYN cookies work to prevent denial-of-service effect from SYN flood attack
- Your legitimate client script
- Your attack command (for flooder)
- The connecton duration graphs you drew in task 5 (one with SYN cookies, one without SYN cookies). Indicate on the graphs using vertical lines or arrows the start and the end of the attack.
- Explanation what happens in each case. Is the attack effective? How can you tell this from the graphs?
- Answers to extra credit questions if any.