X

Intrusion Detection Systems Lab using GENI Desktop


Lab Goals

  1. To get confortable using GENI Desktop
  2. To get you acquainted with different Intrusion Detection Systems (IDSs)
  3. To install an IDS on a real machine on GENI
  4. To use the IDS to detect Distributed Denial of Service Attacks
  5. To create and study IDS rules
  6. To study IDS logs 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 control 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 duplicate the traffic that goes to the victim to another machine called the monitor. This is pretty powerful, duplicating traffic that goes through a switch to a monitor, dedicated machine, and decentralizing the monitoring of the network for attacks. The following videos give a good introduction on SDN and Openflow:

Part 1: Setting up the topology

  1. For this lab you need to make sure your GENI account is working and you are able to login into it
  2. Log into your GENI account and on the top right of the website hover with your mouse on "Tools", and on the drop-down menu you should see "GENI Desktop" in one of the options, click it.
  3. On the page that will be opened there will be a big button saying "Authorize GENI Desktop", click on it. Then there will be another pop-up window asking you where your account is located, select the corresponding option for your account. There will be a new pop-up to process the request. Then whenever you see the in the initial pop-up the button "Authorize", click it.
  4. Now you will be on a page where all your slices, if you have any, will be listed. For this lab we will create a new slice, so click the big button "Create New Slice". Select an appropiate name, and select on the drop-down list the rightful project.
  5. On the page you will now see a message saying that you do not have any allocated resources under your slice. So select the option "Paste Text"

    There you will paste all the content from the following RSpec file, and then select the option "Show RSpec".

    On this page you will now see your topology, now you must click on "Site 1" and select an aggregate just like it is shown in the screenshot

    Now simply click the button "Allocate resources using this RSPEC". Now you have to wait until the resources are allocated properly. In the scenario that one of your nodes fails on the process of being allocated, you must wait until you can delete all the resources to then allocate them all over again. Notice that GENI Desktop automatically added an extra node titled GDGN0 (Which stands for GENI Desktop Global Node Zero), this is needed in order for GENI Desktop features to work on your topology.

    You might notice that GENI Desktop generally takes a little longer to reserve the resources, please be patient. Your nodes will turn Yellow, and then as they become available they will start turning green until all of them are available. Once your nodes are available, your topology needs to be "initialized" by GENI Desktop so the features will be available.

    Once your topology is successfully allocated, depending on your browser, there will be a window saying that "your connection is not private". Your connection actually is private and correctly encrypted, this alert is just shown because the SSL certificate is self-signed by the University of Kentucky. Depending on your browser, simply click Advanced, and "Proceed..."

Before the next step you need to know a couple things of GENI Desktop!

  1. With GENI Desktop you have the ability to connect to your nodes through the website, to do this on the left menu click the "SSH" button. A small window will show up with two buttons. To open a SSH connection to the controller for example, click on the Controller on the topology visualizer (Jacks) and then on the SSH window that opened on GENI Desktop click either "Open Browser Tab SSH" or "Open Browser Window SSH", whichever your preference is. You will use the same SSH window for all your connections, you just need to select different nodes on the visualizer to open connections to different nodes.
  2. Another important detail for this tutorial is to know how to paste things into the SSH terminals that you open to your nodes. To paste something in the terminals on GENI Desktop you need to make right click on it, and select "Paste from browser", then on the pop-up paste whatever content you need to paste and click OK.

Part 2: Setting up your nodes; Controller

  1. First we will set-up the controller! The controller is just a regular machine, we need to set it up in order for it to work as a controller for the virtual switch in our topology so it may indicate what happens with the different flows in the network. To set-up the controller open up an SSH connection it it, and use the following commands:

    • sudo git clone https://github.com/noxrepo/pox.git
    • cd pox/ext
    • sudo wget http://www.gpolab.bbn.com/experiment-support/NFVApps/pox-intro-ctrlapps.tar.gz
    • sudo tar xvfz pox-intro-ctrlapps.tar.gz
    Having executed these commands you have installed POX, which is software written in Python designed to function as a controller for virtual switches using OpenFlow. The Controller is the "brain" of the switch and one of the powerful components of the SDN architecture. It can program the switch to do things in real time, easily, such as redirect a flow, drop it, or duplicate it!

Part 3: Setting up your nodes; Monitor

  1. Now we will set-up the monitor! To get the monitor working, you first need to open a SSH connection to the Monitor node.
  2. On the monitor we will install Snort, which is an intrusion detection system. We will use snort to detect DDoS attacks so we can mitigate them on the Lab. To install snort execute the following command to install snort:

    • sudo apt-get install snort -y

      • At some point during the installation of snort you will be asked for a home network range. Enter: 255.240.0.0/12. This is the mask applied to the machines in the network of the topology.
  3. To finish setting-up the monitor you need to make the following, execute the following command

    • sudo nano /etc/snort/rules/community-virus.rules
    Then on the editor that shows up comment out the lines 19 and 20 by adding pound signs (#) in front of the line, just like so:
    • Now press "Ctrl + X" to complete the changes
    • Enter: "Y"
    • Now simply hit Enter, so the file is saved under the same name
    • The monitor is ready!
  4. Think about what you just did and answer the following questions:
    1. What is the purpose of Snort IDS?
    2. Why do we need to add a home network range?

Part 4: Setting up your nodes; OVS

  1. Now we need to set-up the virtual switch so it listens to the Controller in order to install the flows in the flow table. This switch relays packets like a regular switch but it is also highly programmable using the OpenFlow framework! First, we need to figure out what is the interface of the controller in the OVS, and what is the IP of it. To find out the interface of the Controller on the OVS, go to GENI Desktop and on the visualizer Click on the Node that is between the OVS and the Controller and on the other box on GENI Desktop you will see two IPs, write down the one under "OVS". (In my case I have to write down 10.10.4.2)
  2. Now you need to open a SSH connection to the OVS and run the command:

    • ifconfig
    Now compare the IPs with the one you wrote down on the previous step, the matching interface will be the one that corresponds to the Controller. In my case I realized that the interface for the Controller in the OVS is eth3, please write yours down!
  3. Now we need to figure out the IP of the Controller so we can later point the OVS to such. To find out the IP of the Controller you need to open an SSH connection to it through GENI Desktop and execute the following command:
    • ifconfig
    Please write down the IP that shows up on eth0, 172.17.1.26 in my case
  4. Now you will execute the following commands on the OVS:

    • sudo ovs-vsctl add-br br0
    • Now, for every "eth" interface on the OVS EXCEPT eth0 and the interface of the Controller (The one you found in the previous step) execute the following command:

      • sudo ovs-vsctl add-port br0 <eth Interface>
    • sudo ovs-vsctl set-controller br0 ptcp:6634 tcp:<IP of the Controller>:6633
    • sudo ovs-vsctl set-fail-mode br0 secure
  5. Your OVS is now ready!
  6. Think about what you just did and answer the following questions:

    1. What is the OVS (Openflow Virtual Switch)? What does a switch do?
    2. Why do we need a controller for the switch?

Part 5: 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 the monitor in action, we must first start duplicating traffic using the controller on our topology (the "brain of the switch") 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 requires 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
    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!

    • You will need to verify if the traffic is duplicated to the monitor. How can you do this? Hint: a tool that records network traffic may be useful. Describe your methodology and commands that you have used. Include screenshots.

Part 6: 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 5 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!

Part 7: Experiment with the detection of different attacks


  1. Study the slowloris code. Explain what each part of the code does in detail.
  2. Submit a snort rule that detects Slowloris with an explanation why it works, why it is sensitive AND specific. Include screenshots of logs that prove that your rule has been triggered by the attack.
  3. Add your rule at the end of the following file: /etc/snort/rules/dos.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 slowhelix code. Check the snort alert file to see if your rule worked!
  6. Things to consider: did you configure the HOME_NET properly? Go to /etc/snort/snort.conf, and look for the word "HOME". Then, modify this address to apply to your home network.
  7. Things to consider: Where are the snort log files? Usually log files in the linux operating system are in the folder: /var/log.

Part 8 (graduate level): Open ended experimentation


  1. Run three different network attacks from the attacker to the victim:
    1. A privilege escalation attack of your choice where you use Metasploit. Note that the attack may not be completed depending if the victim VM has the specific weakness or not. Try to find an attack that may be exploitable for the specific VM (or make the VM exploitable). At the end, you mainly need to gather traffic data and raise an alert with snort about the attack. It will be good to have the attack running to completion (extra credit!!), but not necessary.
    2. A host scan with nmap using additional arguments that you will find in the man page.
    3. A brute force password attack using your favorite tool, such as hydra or any other tool. You will need to create a fake account on the user with an easy password for the brute force attack to work. You will also need to enable ssh on the user node. The goal is to capture the network traffic and the attack with snort.
  2. Save tcpdump traces for each attack that you run and save them in a file with a characteristic name. You can monitor these attacks either on the victim machine or on the monitor, since attacks are replicated. Download these to your personal computer and view them with wireshark. You may use winscp in windows or sftp in any Unix based machine (Mac, Linux) to download files from GENI to your computer.
  3. v. Create three custom rules for snort that alert when your attacks are running. Create realistic tests where you run a sample of regular traffic (ping, netcat, iperf, etc.) simultaneously with your attack. The user can emulate regular traffic. Check if your snort alerts generate any false positives and calibrate.
  4. What to include in your report:
    1. Description of the attacks: commands you ran, regular traffic that you added to make the experiment more realistic, etc.
    2. Three tcpdump screenshots that you examined manually and include part of your attack with a short description of the attack vector.
    3. The three alerts and a proof that they worked using screenshots and snort logs.

Survey