- Intrusion Detection Systems Lab -


Lab Goals


  1. To get you acquainted with different Intrusion Detection Systems (IDSs)
  2. To install an IDS on a real machine on GENI
  3. To use the IDS to detect Distributed Denial of Service Attacks
  4. To create and study IDS rules
  5. 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. This is pretty powerful, and, in more complicated topologies, can allow for the duplication of traffic through a switch to a monitor, a machine decentralized from the network and dedicated to monitoring for attacks. We call this a mirroring port. We will see its value when we install a Monitoring node where all traffic that goes through the switch is duplicated to it through the morriring port. The following videos give good introductions to SDN and Openflow:

Prerequisites


  1. You will need basic command line knowledge to complete this lab. Codecademy has a great tutorial on this topic.
  2. In this lab, you will implement a computer network attack, Denial of Service (DoS). This attack is designed to deprive services, such as web content, from legitimate users. From Wikipedia: "In computing, a denial-of-service attack is a cyber-attack where the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to the Internet." You can watch a video about this attack and read more about recent DDoS attacks using the Internet of Things interconnected devices.
  3. To analyze the computer network traffic from this attack, we will use tool called Wireshark. Here is a quick video tutorial for this tool, or you can watch the video below, made by College of Charleston undergrad Thomas Setzler.
  4. Iperf is a tool that is used through command line to generate computer network traffic that resembles regular usage of a computer network. You can read more about this tool here.
  5. Hping3 is another computer networking tool that you will use. This tool, with the proper command line options, can generate a flood of computer network traffic that can overwhelm and take over networking resources. You can read more about this tool here.
  6. Snort is an Intrusion Detection System that alerts about computer network attacks by crossckecking their characteristics against a database of attack signatures. You can learn more about Snort by reading the original publication and the manual.

Part 1: Setting up the topology


  1. Create a new slice under the corresponding project.
  2. Click the "Add Resources" button located on the page of your newly created slice.
  3. Click the URL option.
  4. Paste the following link into the input box: http://mountrouidoux.people.cofc.edu/CyberPaths/files/IDSLabEasyRSpec.txt . Alternatively you may access our github repository with RSpecs and other scripts.
  5. Then, click on the "Select" button.
  6. Your topology should now be loaded and look similar to the picture below.
  7. Now, click on "Site 1", select one of the available aggregates from the dropdown menu on the left, and reserve the resources.
  8. Then, wait some time until all your resources are ready. You can check the status of these by going to the page of your slice. If the background color of a given node is gray, then that node is not yet available; if it is green, then it is ready.

Part 2: Setting up your nodes; Node: Monitor


  1. Now that your topology resources are reserved and available for you to log into (for help on how to log into the nodes, please refer to one of the previous guides: Windows users or Mac users), we need to set up different things on each node. Let's get started with the Monitor.
  2. We must set up the intrusion detection software (Snort, in our case) so the Monitor node can act like an Intrusion Detection System (IDS) and monitor our topology.
  3. On the Monitor, execute the following command to install snort:
    sudo apt-get install snort -y
  4. At some point during the installation of snort, you will be asked for a home network range. Enter: 10.10.0.0/16. This is the subnet mask applied to the machines in the network of the topology. For more information about subnets, please watch this video.
  5. Think about what you just did, and answer the following question:
    1. What is the purpose of the Snort IDS?

Part 3: Setting up your nodes; Node: Openflow Virtual Switch (OVS)


  1. Now, we need to set up the last node, the OVS. This switch relays packets like a regular switch, but it is also highly programmable since it uses the OpenFlow framework! Log in to your OVS node.
  2. Login to the OVS node and run ifconfig, you should see several interfaces listed, like eth0, eth1, eth2...
  3. Now, login to the monitor node and run ifconfig on the Monitor, and find which interface on the OVS has an IP that matches up with the Monitor's eth1 IP (for example: if the Monitor's eth1 IP is 10.10.3.1, find which interface on the OVS has the IP 10.10.3.2).
  4. Now, go back to the OVS node. First, we need to setup the switch by adding a bridge:
     sudo ovs-vsctl add-br br0
  5. Since this is a learning switch, we will delete all the IPs from the interfaces that are connected to it:
    sudo ifconfig eth1 0
    sudo ifconfig eth2 0
    sudo ifconfig eth3 0
    sudo ifconfig eth4 0
  6. Now we will need to add the interfaces to the bridge, i.e., our OVS switch:
    sudo ovs-vsctl add-port br0 eth1
    sudo ovs-vsctl add-port br0 eth2
    sudo ovs-vsctl add-port br0 eth3
    sudo ovs-vsctl add-port br0 eth4
  7. Use the following command to verify that the interfaces have been added:
     sudo ovs-vsctl show
  8. Only one command needs to be executed in order to set up the traffic mirroring for the Monitor. However, we need to look at the interfaces first.

  9. Now, go back to the OVS node. There, execute the following command. Here, ethM represents the interface that matches with the Monitor's IP, and ethX, ethY, and ethZ are the three remaining interfaces besides eth0 and lo:
     sudo ovs-vsctl -- set Bridge br0 mirrors=@m \
                	-- --id=@ethX get Port ethX \
                  	-- --id=@ethY get Port ethY \
                  	-- --id=@ethZ get Port ethZ \
    	  	-- --id=@ethM get Port ethM \
    		-- --id=@m create Mirror name=mymirror select-dst-port=@ethX,@ethY,@ethZ select-src-port=@ethX,@ethY,@ethZ output-port=@ethM
  10. This command creates a mirror port for the switch, i.e., all the traffic that goes through the switch is copied to this port and as a consequence it is sent to the monitor. Thus, if the user is sending traffic to the victim, this traffic will be seen both by the victim and the monitor.
  11. Verify that everything works:
    1. Run ping between the attacker and the victim. Does it go through?
    2. While running ping between the attacker and the victim, run tcpdump on the proper monitor interface (how will you find this?). Verify that the ping is mirrored to the monitor machine.
  12. 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 did we add a Monitor to the topology and have all the network traffic mirrored to this machine?

Part 4: Experimenting - Running an Internal Attack


    This means that a local node in the network has been compromised, either because it was vulnerable, i.e., without latest patches, with weak passwords, etc., or because a social engineering attack took place. We will be running such an attack and then write a custom rule to detect it with Snort IDS.

  1. To start Snort, you need to open another terminal for the Monitor and enter the following command:
    sudo snort -c /etc/snort/snort.conf -A fast -i eth1
  2. Now, we need to simulate normal traffic on our network to have something to which we can compare the DDoS attack. In a real network, regular traffic such as email exchange, web browsing, etc. take place at the same time as an attack. This makes it more difficult to distinguish the attack traffic from network traffic, and thus good monitoring with accurate, robust, signature or behavior based rules is important. 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
  3. To start the traffic simulation, 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, it is 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 that 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.
  6. If your nodes cannot ping each other, verify that you have done the following:
    1. Do all the nodes belong to the same subnet? To verify this, log in to all the nodes (attacker, victim, user, monitor). Run ifconfig. Do all your nodes belong to the same subnet? If you do not understand subnets, watch the following video.
    2. If the hosts do not belong to the same subnet, you will need to use the ifconfig command to fix the problem. The command "sudo ifconfig eth(num) (node_IP) netmask (node_netmask)" will change a specific port's IP address and netmask to node_IP and node_netmask, respectively.

Part 5: Create your own rule!


  1. Now that you understand what an IDS is and what Snort is used for, it is your turn to create a Snort alert and test it.
  2. The rule you create should be based on what you did in Part 5 of the tutorial.
  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 same DDoS attack you ran earlier. 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 6: 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 7 (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.