- Correlation and Mitigation using SDN Lab -


Lab Goals

  1. To get you acquainted with Software Defined Networking (SDN) concepts
  2. To analyze Snort alerts in real time.
  3. To study traffic flow rules and understand them.

Quick introduction to Software Defined Networks (SDN)

    This lab is using a powerful network architecture, Software Defined Networking (SDN). SDN is a flexible, agile, and fully programmable network paradigm. Openflow is the framework that offers this standardization and programmability for the software swiches that are used in SDN architectures. In the SDN architecture the network and controle plane are separated, offering a logically centralized controller that can be easily programmable and as you can see in the lab that follows can instruct the Openflow Virtual Switch to change configurations in real time. In our case the controller instructs the switch to drop the malicious flow of the Denial of Service attack. Furthermore, the controller can offer useful information about the network, i.e., information about the flows that are going through the switch that includes source and destination IP addresses, source and destination MAC addresses, ports, and other useful statistics. The following videos give a good introduction on SDN and Openflow: We have performed a webinar that explains in detail the code and research behind this lab. You are strongly encouraged to watch this webinar.

Preliminary steps, RSpec, and Python code you will need for this lab


Part 1: analyze.py - Installing, Understanding and Running

  1. Installing analyze.py

    • Connect to the "Monitor" node through SSH
    • Execute the following command: cd /opt/
    • Now you will open the file analyze.py that was provided to you using a text editor (such as Notepad, Notepad++, etc...), then go ahead and edit the line that contains "HOST = '172.17.2.2'" (line 71, to be exact) and set the constant HOST to the IP of your Controller (The one you figured out on the set-up portion of the Lab).

      Then, you will create the file analyze.py by executing the following command:
      • sudo nano analyze.py
      • Your terminal should look like this:
      • Now copy everything from the analyze.py you have in the text editor (where you modified the constant HOST), and paste it in your terminal (To paste in the terminal simply use Right Click). Your terminal should now look like this:
      • Now press Ctrl + X
      • Press Y
      • Press Enter
  2. Understanding what analyze.py does

    • Read the python code. What do you think this script is doing? What are its main parts?
    • How does the script read a tcpdump (copy paste the command)? What information does it extract?
    • Copy paste in your report the line of code that sends information to the correlator. What does the monitor send to the correlator? Why do you think it sends this information?
  3. Running analyze.py - Execute the following commands:

    cd /opt/
sudo python analyze.py
    That is how you make analyze.py run!

Part 2: correlate.py - Installing, Understanding and Running

  1. Installing

    • Connect to the Controller node through SSH
    • Execute the following commands:

      • cd /opt/
      sudo nano correlate.py
    • Now open on a text editor, like you did for part one, the correlate.py file that was provided to you. Edit the line that containsovsAddress = '172.17.2.16' and set the variable to the IP of the OVS (You can figure this out by running "ifconfig" on the OVS, and the IP that shows on eth0 will be the IP of the OVS)
    • Copy everything from the text editor, and paste it on the terminal (Like you did for part one)
    • Now press Ctrl + X
    • Press Y
    • Finally, press Enter
  2. Understanding

    • The correlator script starts by setting up an initial flow table of the network by running a flow dump on the OVS IP address. Copy paste the code that is creating this flow table.
    • Next, the script checks the information from the monitor by first making sure the incoming information is indeed an alert. Copy paste this code. What else does the script look for in the data sent from the monitor? Why?
    • How does the correlator verify if an attack has occured? Is there any case the monitor sent a false alert? Explain your answer.
    • The script then verifies that each flow from the flow dump correlates with what is already established within our flow table.
    • If the script finds an inconsistency within our flow table and the flow dump, the script either calls the mitigator script, mitigate.py (if the port number from the flow dump is associated with a different IP address), or adds the new flow to our flow table (if the port number from the flow dump is not in our flow table).
  3. Running - Execute the following commands:

    cd /opt/
sudo python correlate.py
    That is how you make correlate.py run!


Part 3: mitigator.py - Installing, Understanding and Running

  1. Installing

    • Open another SSH connection to the Controller
    • Execute the following commands:
      											cd /opt/
sudo nano mitigate.py
    • Open in a text editor the mitigator.py file you were provided, and edit the line that contains ovsAddress = '172.17.2.16' (Line 10). Set the variable to the IP of your OVS (The one you found in the previous part of the lab)
    • Copy everything from the mitigator.py file that you edited on the text editor
    • Then, paste it on the terminal by making a Right Click
    • Use Ctrl + X
    • Press Y
    • Hit Enter
  2. Understanding

    • What is the function of the mitigator script? Research the Openflow commands that are used in the script and explain what they do.
  3. Running mitigator.py

    • You do not need to run any commands for mitigator.py, given that it is executed automatically by correlate.py through the next line of code 
      os.popen('sudo python mitigate.py ' + str(targetPort) + ' ' + str(targetIP), shell=True)

Part 4: Experimenting - Running an Internal Attack

    An internal attack means that the attack is coming from machines connected directly to the network switch. We will be running such an attack in order to see how correlation and mitigation takes place on an internal attack.

    In order to see correlation and mitigation in action, we must first start duplicating traffic from our controller on our topology to our monitor. This allows our monitor to view the traffic of the network.

  1. To duplicate the traffic you need to first, figure out the corresponding interface (like eth1, eth2 ...) of the Monitor in the OVS (You can use the GENI topology visualizer and "ifconfig" for this) and then execute the following commands on the Controller to start the duplication:

    cd pox
./pox.py --verbose DuplicateTraffic --duplicate_port=<interface on the OVS that corresponds to the monitor>
  2. Now to start Snort you need to first figure out the interface of the OVS in the Monitor, you can figure this out by running "ifconfig" on the Monitor and comparing the IPs with the node between the Monitor and OVS, once you have figured out this, execute the following command on the Monitor's terminal:

      sudo snort -c /etc/snort/snort.conf -A fast -i <interface on the Monitor that corresponds to the OVS>
  3. Now, we need to simulate normal traffic on our network to have something to which we can compare the DDoS attack. To simulate traffic on the network we will use iPerf. iPerf requieres a Sever and a Client to generate traffic, so we will use the Victim as the Server and the User as the Client to simulate traffic. To start the server on the Victim execute the following command:
    iperf -s
    Now go ahead and start the scripts that you installed in Part 2, so whenever snort detects a DDoS attack these mitigate such. Start the scripts in the following order: correlate.py (On the controller) and then analyze.py (On the monitor). For instructions on how to start these scripts, refer to the Part 2 on the respective "Running" portion.

    To start the traffic simulation, now we need to make the iperf client start communicating with the Server. We will start a communication that will last two minutes (120 seconds) with the following command on the User:

      iperf -c victim -t 120
  4. Finally time to run the attack! To run the attack go to the terminal of the Attacker and execute the following command:

      sudo timeout -sHUP 20s hping3 -i ul -S --flood --rand-source -p 80 victim
  5. Trust but verify!

    • First you will need to verify if there were messages send from the monitor to the correlator. How can you verify this? Think creatively, look at analyze.py and consider the data that will prove that the monitor sent an alert.
    • Next, you should verify if the correlator received anything. Again think about the traffic, the correlate.py and how you can use code and networking tool to verify everything has worked.
    • Finally, you will need to verify if the attacker was blocked. You need to place all the above evidence (screenshots, logs, code changes) in your report.