CSCI 343 - Homework 4
Go forth, my child, and SYN no more
Due by 11:59:59pm, Wednesday 02 November 2016
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.
You may work with a partner for this assignment.
Please use the Piazza forum for discussion of questions and issues with the assignment.
We will be using the DeterLab Cyber-Security Experimentation and Testing Facility to conduct this assignment.
- There is a Student Guide that you may want to take a look at. Especially
Some background readings on the network concepts being used:
Denial of service attacks deny service to legitimate clients by tying up resources at the server with a flood of legitimate-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.
If you feel you need a short introduction to working in the Unix environment, there is an optional Intro to Unix and DETER that you are welcome to work on. Please do not submit anything from this exercise.
- If you don't have an account, contact your instructor ASAP
- Log into DETER.
- Be sure to go to "Edit Profile" and change at least your Name and Phone #
- Create an instance of this exercise by following the instructions here (summarized below), using the values specified
- Under the "Experimentation" menu at the top of the page, click "Begin an Experiment".
- Select csci343 as the Project
- Leave Group set to "Default Group"
- Set the Name field to be username-synflood (e.g., kuperman-synflood)
- Supply a short Description
- In the Your NS File field, download and use synf.ns
- Set the Idle Swap to be 1 and the Max Duration to be 4
- If you would like to start your lab now, check the "Swap In Immediately" box
- Click Submit
- If you didn't swap in the experiment to work on, you can always just
- Click on the "My DETERlab" link on the left hand menu.
- In the "Current Experiments" table, click on the name of the experiment you want.
- Under the "Experiment Options" menu on the left margin, click "Swap Experiment In", then click "Confirm".
- The swap in process will take 5 to 10 minutes. While you're waiting, you can watch the swap in process displayed in your web browser. Or, you can watch your email box for a message letting you know that it has finished swapping in.
You can take a look at the topology file and read through it if you like. Do not modify the topology file!
Especially important are the lines in the NS file
that add support for traffic generation and visualization via SEER:
#Add SEER support to each node
tb-set-node-startcmd $node "sudo python /share/seer/v160/experiment-setup.py Basic"
Once an experiment is swapped in use SEER GUI by clicking at "Launch SEER now" option from here
. (Local copy of the file is here: SEER-16b7.jnlp
The code should work on any computer supporting a reasonably recent version of Java. Once the code starts, choose the "Emulab" interface in the first dialog.
Then, the experiment must be "attached" to the GUI. This is done by choosing Emulab Interface->Attach to Experiment from the GUI and then input Project and Experiment Name. Note: capitalization matters here. Next, you will need to input your username on DETER (for example email@example.com) and the same password you use to log on to DETER. You may want to input your public key into the dialog (SSH Key File) if you have already set up passwordless access to DETER. Otherwise delete the information in the SSH Key File input field and you will be asked for your DETER password.
Once attached, experiment topology is visible in the Topology tab. Right clicking on nodes should open a menu that allows users to open graphs in the Graph tab. Once traffic starts flowing, legitimate traffic will show as green and attack traffic will show as red on these graphs. Notice that you can change the counters to show packets or bytes (selection option on top of a graph). If the Src option in the Graph tab is set to "forward" the attack traffic will show as black. Change it to the IP address option and you should be able to see incoming and outgoing traffic for any node, both legitimate and attack. The rest of this assignment assumes that you have opened the graph that shows traffic reaching and leaving the server node.
Generating legitimate traffic
Create a Web traffic stream between the client and the server nodes by following these steps from Controls tab in SEER:
- Be sure you are on the Control tab first
- Click on Traffic item on the left sidebar
- Click onWeb
- Click on New Web group
- Choose some name for the group
- Choose client node as a client, server node as a server. Choose exponential distribution of think times with lambda 5, scale 1 and max 5. Choose minmax distribution of file sizes with min 1,000 and max 10,000.
- Click Start. Right click on the router node and open its graph. You should be able to see some green traffic now on your graph. Use Print Screen button on your keyboard to capture this graph, paste it into a Word/Google document (or something similar), and include it in your project submission.
Turning off SYN cookies
SYN cookies are often on by default in Linux and FreeBSD. To check if they are on do the following:
# e.g., server.kuperman-synflood.csci343
# or server.kuperman-synflood.csci343.isi.deterlab.net
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
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.
- Click on the Attack item on the left sidebar
- Click on Packet Flooder
- Click on New Packet Flooder
- Choose some name for the group
- Choose attacker node as a participating node. Source field should be 184.108.40.206 and mask 255.255.255.0 to ensure subnet spoofing.
The server node is the target node. Leave the target mask empty. Set protocol to TCP. Leave the length range unspecified. Choose flat attack rate, with high rate of 1,000 packets per second (this is the unit of measure for rate fields in SEER). Set the destination ports to min 80 and max 80 and set the TCP flags field to SYN. Do not specify any other options - you can either delete default values or leave them as they are.
- Click Start. You should be able to see some red traffic now on your graph. Make sure you are looking at a graph of pps not Bps (selection option on top of the graph). Use Print Screen button on your keyboard to capture this graph, paste it into a Word document, and include it in your project submission.
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 using Stop button for each traffic group in SEER
- Start tcpdump on the client
# e.g., client.kuperman-synflood.csci343
# or client.kuperman-synflood.csci343.isi.deterlab.net
ip route get 220.127.116.11
You should see something like this as a result:
18.104.22.168 via 22.214.171.124 dev eth2 src 126.96.36.199
cache mtu 1500 advmss 1460 metric 10 64
Thus the interface name leading to 188.8.131.52 is eth2. To see the traffic flowing type:
sudo tcpdump -nn -i eth2
then generate some traffic, e.g. by starting SEER's Web traffic again. 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. Remind yourself 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 an ACK following a FIN-ACK assign to it the duration of 200 s. Include two graphs in your submission, showing connection duration vs connection start time for the case without and with SYN cookies. Label the graphs so they can be distinguished and indicate on each graph using vertical lines or arrows the start and the end of the attack.
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.
- SEER GUI does not run. The GUI usually requires the latest version of Java so if it does not run this means you need to upgrade your Java version.
- SEER GUI cannot attach the experiment. Very likely reason for this is that you are not typing the correct username and password. Try to SSH into users.deterlab.net with the same username and password you are using to attach the experiment. If this works but you still have problems with attaching email your TA.
- There is no legitimate (attack) traffic on graphs. First verify that the options are set exactly as shown in the pictures that go along with steps 2.4 and 4.4. If this is all fine, SSH to one of your experimental machines and try to ping another two (e.g., ping server and attacker from client). Use short names (e.g., ping server and NOT ping server.YourExperiment.YourProject) in ping commands. If you notice any connectivity problems click on Modify Experiment on your DETER Web page and then click on Submit. The experiment will reset to its original state - this may take several minutes and you will receive an email when it's done. If connectivity problems persist email your TA. Finally, if everything else seems fine it may be that SEER backend has died for some reason (perhaps you rebooted one of the machines without going through Modify Experiment?) To fix this
click on Modify Experiment on your DETER Web page and then click on Submit. The experiment will reset to its original state - this may take several minutes and you will receive an email when it's done. If none of this helped email your TA.
Another reason for missing traffic is if your experiment is not swapped in.
- There is some traffic but it does not look like shown on the graphs. If the shape of the traffic is different this is almost certainly caused by not following the project instructions closely. Verify that SYN cookies are off, that the NS file is exactly like given on this page, and that SEER's settings are exactly as shown in steps 2.4 and 4.4. If this is all fine and you are still having problems email your TA.
If the shape looks similar but there is no red traffic on graphs this is a testbed switch problem - QoS flags get reset. Email your TA who will then contact DETER ops team.
There is one extra-credit question:
- 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?
You should submit a PDF document to blackboard with the following items (label each section):
- Your name and your partner's name (if any)
- Explanation how the TCP SYN flood attack works.
- Explanation how SYN cookies work to prevent denial-of-service effect from SYN flood attack
- Picture of your topology in DETER. Copy this directly from the DETER Web page using high level of detail (clicking on the small picture will open a larger one with detail selection option) so IP addresses are visible.
- Screen shot showing the legitimate traffic flowing to and from the server node in packets per second (pps).
- Screen shot showing the attack traffic flowing to and from the server node in packets per second. Explain why the amount of legitimate traffic increases during the attack (hint, look at tcpdump at the server node).
- Graphs of distribution of client's connection duration for no-SYN-cookies and SYN-cookies cases. Each graph must be labeled and have vertical lines or arrows show the start and the stop of the attack. Explain what happens in each case. Is the attack effective? How can you tell this from the graphs?
- Answers to extra credit questions if any.