X

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:

RSpec and Python code you will need for this lab

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

  1. Installing analyze.py

    • Open the Topology that you prepared for this lab on GENI Desktop
    • In the case that you had closed your slice, and you are re-opening it again with GENI Desktop, it will tell you that it needs to "install keys". Just wait for a short time and then the GENI Desktop tools will become available on the left of the screen again.
    • Now that all your tools on GENI Desktop are available, you will click the button on the left menu that says "File Upload - Direct". A small window on GENI Desktop will show up.
    • On the topology visualizer click on the Monitor. Then on the File Upload window click on the "Set Selection" button
    • Now click on the "Choose Files" button and select analyze.py from your computer and then click "Upload Files to Nodes"
    • Go ahead and open an SSH window to the Monitor and execute the following command:

      • sudo nano analyze.py
    • Now on the editor that is opened on the SSH window after you executed the last command, find the line where the "HOST" is defined, it looks like this:

      Change the IP there to the IP of your Controller (The one you wrote down during the set-up of your topology) which is 172.17.1.26 in my case. Then press "Ctrl + X", then "Y", lastly just hit Enter to keep the same name of the file
    • Now you have to execute the following command to change the location of the file in the node:

      • sudo mv analyze.py ../../opt/analyze.py
    • analyze.py is now installed!
  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:

    • Open a SSH Window to the Monitor and execute
    • cd /opt/
    • sudo python analyze.py
    • analyze.py is now running!

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

  1. Installing correlate.py

    • The installation is very similar to that of analyze.py. You need to first upload correlate.py to the Controller. To do this, make sure the "File Upload - Direct" is open, then click on the Controller node on the visualizer, click "Set Selection" on the Upload file window and then select the correlate.py and upload it.
    • We need to find the IP of the OVS, to do this, open a SSH window to the OVS and run the command ifconfig and copy down the IP that shows up on eth0 (172.17.1.29 in my case)
    • Open a SSH Window to the Controller and execute the following command

      • sudo nano correlate.py
    • Now edit the line that contains "ovsAddress", and change the IP address to the IP of the OVS, the one you found in the previous step. It should look like this:
    • Now press "Ctrl + X"
    • Enter: "Y"
    • Hit Enter, to keep the same file name
    • correlate.py is now installed!
  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:

    • Open a SSH window to the Controller
    • cd /opt/
    • sudo python correlate.py
    • correlate.py is now running!

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

  1. Installing mitigate.py

    • Similar to the previous parts of the tutorial, you will upload another file to the Controller, this time it will be mitigate.py. Upload it using the same instructions, and then move it to the /opt/ directory as well
    • Now you will edit the file using the following command:

      • sudo nano /opt/mitigate.py
      • (If you get an error executing the above command, you might not have moved the file to the opt directory correctly)
    • On the editor find the line #10, the one that contains "ovsAddress='172.17.2.16'", change the IP to the one we found on the previous step, the IP of the OVS (172.17.1.29, in my case).
    • Save the changes the same you have done before. ("Ctrl + X", "Y" and "Enter")
  2. Understanding

    • The mitigator script, via the controller, tells the OVS to add a new flow rule in which the port that needs attention has all incoming traffic dropped.
  3. Running mitigate.py

    • You do not need to run any commands for mitigate.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: 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 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 will use a neat feature of GENI Desktop to visualize the traffic to the Victim so we can compare regular traffic to the DDoS attack, and then see how it is mitigated. To use this feature click on "Passive Graphs" button that is located on the left of the screen on GENI Desktop.

    On the window that will open-up on GENI Desktop, you will have to change the settings:
    • First, click the button "LiveUpdate", such that the graph will update constantly reflecting the traffic on the network.
    • Now, click on "Graphs" to disable all the ones currently enabled and then click on "Total Traffic", which is the graph we are interested in
    • Under "Nodes", only enable the Victim. The victim is the node that will receive both the normal and malicious traffic.
    • After you have made the previous changes on the settings of the Graph window, click the button "ApplyConfig"
    • IMPORTANT: If you click other nodes on the visualizer, the graph will automatically display the last node that you clicked. So make sure when running the actual experiment, the Victim is selected on the graph, else you will not see the experiment displayed on this graph! To check what node is being used to create the graph check on the position shown here:
    • 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
    • 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
    • In the scenario that everything goes as planned, and the DDoS attack is mitigated, you should barely be able to notice any difference in the traffic and your graph should look similar to this:

      The traffic that you can appreciate in there is regular traffic that we generated from the User to the Victim using iPerf. If your graph seems to mark higher traffic at some point, it might be due the fact that the DDoS attack was not mitigated successfully
      if it was, you should see a message on the Controller's saying that correlation and mitigation happened.
  4. 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.

Part 5: Create your own rule!

  1. Now that you understand what an IDS is and what Snort is for, it is your turn to create your own rule for Snort, your own alert, and then test it.
  2. The rule you create should be based on what you did on the Part 4 of the tutorial.
  3. Add your rule at the end of the following file: /etc/snort/rules/<rule>.rules
  4. Your alert should have a characteristic message, such as "Dr. X snort alert" and a sequence number that is higher than 10,000 (Numbers lower than 10,000 are reserved and used by Snort)
  5. Test your alert by running the same DDoS attack you ran earlier. Check the snort alert file to see if your rule worked!

Survey