Context Navigation

HandlingIntrusionwithRyu-portscanning

Timestamp:: 10/31/17 16:32:35 (6 years ago)
Author:: matta@cs.bu.edu
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu-portscanning

-                      v46
+                      v47
 == Overview ==
 In this experiment, we will use the Ryu controller to handle intrusion traffic generated using Port Scanning application Nmap. The system is the same as the one used in [wiki:GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu Experiment 3], where we use a RINA distributed application to get the intrusion detection results from the VNFs (i.e., Snort) as well as the load of the VNFs. When an intrusion is detected by VNFs, the information will be passed to the Attack Analyzer residing on controller node via the RINA distributed application. Attack Analyzer informs the Ryu controller about the attack, which then blocks the intrusion traffic by updating the OpenFlow rules on the OVS switch.
+In this experiment, we will use the Ryu controller to handle intrusion traffic in the form of port scans generated by the Nmap application. The system is the same as the one used in [wiki:GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu Experiment 3], where we use a RINA distributed application to get the intrusion detection alerts from the VNFs (i.e., Snort) as well as the load of the VNFs. When an intrusion is detected by the VNFs, the information will be passed to the Attack Analyzer residing on the controller node via the RINA distributed application. The Attack Analyzer informs the Ryu controller about the attack, which then blocks the intrusion traffic by updating the OpenFlow rules on the OVS switch.
 …
 == (1) RINA Distributed Application ==
 RINA distributed application collects the CPU load of VNF1 and VNF2, as well as any Snort alerts generated by Snort applications running on VNF1 and VNF2. These Snort alerts are collected on Controller node and saved in file /tmp/snortalerts by RINA distributed application.
+The RINA distributed application collects the CPU load of VNF1 and VNF2, as well as any Snort alerts generated by the Snort applications running on VNF1 and VNF2. These Snort alerts are collected on the Controller node and saved in file /tmp/snortalerts by the RINA distributed application.
 …
-'''Note: the RINA distributed application also passes the intrusion detection results from the VNFs to the Ryu controller. This information is not used in this experiment, but will be used in [wiki:GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu Experiment 3] when handling intrusion traffic.'''
 {{{
 …
  Now we will run the Ryu controller that will get the load balancing decision from the PI-controller and direct the flows accordingly.
 .     First we will update the ''port.config'' file to direct the controller to the ''NFV_ratio_PI.txt'' file generated by the PI-controller, which has the load balancing decision information. In a new controller window, execute:
+.     First we will update the ''nfv.config'' file to direct the controller to the ''NFV_ratio_PI.txt'' file generated by the PI-controller, which has the load balancing decision information. In a new controller window, execute:
          - ''' nano /tmp/ryu/ryu/app/nfv.config'''
    o   Change the value of '''controller_type''' to '''PI''' [[BR]]
    o   Change the value of '''''file_path_pi''''' to the text file that has the PI controller`s  output.[[BR]]
+   o   Change the value of '''''file_path_pi''''' to the text file that has the PI controller's  output.[[BR]]
     '''''/users/<!UserName>/Control/PI_controller/NFV_ratio_PI.txt'''''[[BR]]
     Change the '''''<!UserName>''''' to your user name.[[BR]]
 …
 ''' Note: keep the RINA application processes, PI controller process and PI-based Ryu controller process from the previous 3 steps running in the background. '''
 . We need to first configure snort so that we can use our rules, or snort’s build-in rules to detect the intrusion traffic.
+. We need to first configure Snort so that we can use our rules, or snort’s build-in rules to detect the intrusion traffic.
 To configure Snort, in separate windows for VNF1 and VNF2, execute the following commands:
 …
     - ''' ./config_snort.sh '''
+. Make sure that file /etc/snort/rules/my.rules is empty. This file contains any custom rules to generate snort attack alerts. For this experiment, we will be using snort build-in rules for detecting port-scanning attack.
+. Update “/etc/snort/snort.conf” to enable port scanning functionality of Snort. You can update it by uncommenting following line and updating it with following information
+. Make sure that file /etc/snort/rules/my.rules is empty. This file contains any custom rules to generate Snort attack alerts. For this experiment, we will be using Snort build-in rules for detecting port-scanning attack.
+. Update “/etc/snort/snort.conf” to enable the port scanning functionality of Snort. You can update it by uncommenting the following line:
+    - ''' preprocessor sfportscan: proto  { all } memcap { 10000000 } sense_level { low } '''
+ and updating it as follows
     - ''' preprocessor sfportscan: proto  { all } memcap { 10000000 } sense_level { medium } logfile { /var/log/snort/alert } '''
 …
    - ''' sudo /usr/local/bin/snort -A full -dev -c /etc/snort/snort.conf -i eth1'''
    ''' Note: exit from previous instances of snort if they are still running from earlier experiments before you run this instance of snort. '''
+   ''' Note: exit from previous instances of Snort if they are still running from earlier experiments before you run this instance of Snort. '''
+   ''' Note: this command is different from [wiki:GENIExperimenter/Tutorials/NFV/Ryu/LoadBalancePIwithRyu Experiment 2], where the file ''/etc/snort/snort.conf '' specifies which rule files to load. '''
+When Snort detects intrusion traffic, it will save the alert messages into the file '' /var/log/snort/alert''. The RINA distributed application keeps reading this alert file, and pass any intrusion information to the Ryu controller which will block the intrusion traffic.
+   ''' Note: this command is different from [wiki:GENIExperimenter/Tutorials/NFV/Ryu/LoadBalancePIwithRyu Experiment 2]. Here we specify the file ''/etc/snort/snort.conf '' to indicate which rule files to load. '''
+When Snort detects intrusion traffic, it will save the alert messages into the file '' /var/log/snort/alert''. The RINA distributed application keeps reading this alert file, and passes any intrusion information to the Ryu controller which will block the intrusion traffic.
+== (5) Run Attack Analyzer ==
+The Attack Analyzer reads the Snort alerts saved on the Controller node and makes decisions about which IP addresses to block. The Attack analyzer is the “brain” on the attack control system. It reads the file ''/tmp/snortalert'', which is generated by RINA on controller node and outputs ''/tmp/attacker.txt'' file which has the IP addresses of all the nodes that the Attack Analyzer decides to block based on Snort alerts.
+Open a separate window for the Controller, and run the attack analyzer. [[BR]]
+''' cd ~/Control/AttackAnalyzer/ '''
+''' python !AttackAnalyzer.py -f /tmp/snortalert ''' [[BR]]
 ''' Note: If you want to re-run this experiment, make sure to remove ''/tmp/attacker.txt'' and ''/tmp/snortalert'' files on the controller node. '''
-== (5) Run Attack Analyzer ==
-Attack Analyzer reads the snort alerts saved on Controller node and makes decisions about which IP addresses to block. Attack analyzer is the “brain” on the attack control system. It reads the file ''/tmp/snortalerts'', which is generated by RINA on controller node and outputs ''/tmp/attacker.txt'' file which has IP address of all the nodes that Attack Analyzer decides to block based on snort alerts.
-Open a separate window for Controller, run attack analyzer. [[BR]]
-''' cd ~/Control/AttackAnalyzer/ '''
-''' python !AttackAnalyzer.py -f /tmp/snortalert ''' [[BR]]
 == (6) Generate background traffic ==
 …
 '''iperf -u -s '''
 . Now we will generate traffic from the sources 1 (s1) to the destination node using iperf and see how it effects the CPU utilization at VNF1 and VNF2 running Snort IDS. Note that if we run multiple instances of iperf, we can generate significant load on the VNF instances. To run iperf client on a source, execute:
+. Now we will generate traffic from source s1 to the destination node using iperf and see how it affects the CPU utilization at VNF1 and VNF2 running Snort IDS. Note that if we run multiple instances of iperf, we can generate significant load on the VNF instances. To run iperf client on a source, execute:
 ''' iperf -u -c destination -t 5000 & '''
 …
  <tr>
 <td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image068.gif" > </td>
 <td>  <i>Note that you can run multiple instances of iperf by running <span style="background:#c0c0c0"> iperf -c destination -t 5000 & </span> multiple times in s1 node. This flow lasts for 5000 seconds. For this experiment, you may try to run 4-5 iperf instances to generate load of around 50% on both VNF1 and VNF2. To kill all the flows generated at a node, run <span style="background:#c0c0c0"> killall –v iperf </span> </i>
+<td>  <i>Note that you can run multiple instances of iperf by running <span style="background:#c0c0c0"> iperf -c destination -t 5000 & </span> multiple times in the s1 node. This flow lasts for 5000 seconds. For this experiment, you may try to run 4-5 iperf instances to generate load of around 50% on each of VNF1 and VNF2. To kill all the flows generated at a node, run <span style="background:#c0c0c0"> killall –v iperf </span> </i>
  </td></tr></table>
 }}}
 …
 == (7) Generate Intrusion Traffic ==
 . We will generate attack traffic from source 2 (s2), so only s2 is blocked by the system. In a separate window for source 2 (s2), ping destination:
+. We will generate attack traffic from source s2, so only s2 is blocked by the system. In a separate window for source s2, ping the destination:
 ''' ping destination'''
 …
 Your ping should reach the destination and it should not be blocked.
 . Install port scanner application nmap on s2
+. Install the port scanner application Nmap on s2
 ''' sudo apt-get update '''
 …
 ''' wget !https://raw.githubusercontent.com/akhtarnabeel/public/master/NFV-GENI/PortScanAttack.sh '''
 change file permissions so you can run it
+change the file permissions so you can run it
 ''' chmod 777 !PortScanAttack.sh '''
 . Run the file to create an attack
+. Generate the port scanning attack by typing
 ''' ./!PortScanAttack.sh '''
 Attack file has following content
+The !PortScanAttack.sh file has the following content
 {{{
 …
  }}}
+Every 0.2 seconds, source node generates a ping to destination node and the output of ping is saved in ''ping.log'' file.
+Soon after starting ping message, nmap is used to attack destination.
+. As soon as the attack is detected, you will see the IP address appearing on the window for ''!AttackAnalyzer.py''. All traffic from this IP address is blocked by AttackAnalyzer. At this point, you can stop the ''PortScanAttack.sh '' file by typing Ctrl+C.
+. We can use ping output file (ping.log) to measure how long it took to detect the attack. Since each ping request are made 0.2 seconds apart, we can count the number of successful pings. To open ping.log file, type
+Every 0.2 seconds, the source node generates a ping to the destination node and the output of the ping is saved in ''ping.log'' file.
+Concurrently with these pings, Nmap is used to attack the destination using port scans.
+We will count how many pings will go through before the system detects the port scans and blocks source s2.
+. As soon as the attack is detected, you will see the IP address of the attacking source s2 appearing on the controller window where the ''!AttackAnalyzer.py'' is running. All traffic from this IP address is blocked by the OVS switch as instructed by the Ryu controller. At this point, you can stop the attack generated by ''PortScanAttack.sh '' by typing Ctrl+C.
+. We can use the ping output file (ping.log) to measure how long it took to block the attack. Since ping requests are made 0.2 seconds apart, we can count the number of successful pings. To open the ping.log file, type
 ''' cat ping.log '''
 Here is sample output
+Here is a sample output
 …
 Here you can see that only first 13 out of total 422 ping request went through. Since each ping request is made at 0.2 seconds apart, it took 0.2x13 = 2.6 seconds to detect and block the attacker.
+Here you can see that only the first 13 out of a total of 422 ping requests went through. Since ping requests are made every 0.2 seconds, it took 0.2x13 = 2.6 seconds to detect and block the attacker.
 …
 == (8) Re-run experiment without load balancer ==
 We will re-run the experiment without load balancer to see the effects of load balancer. You should detect attack quickly using load balancer.
 To re-run the experiment, you can keep everything running and just remove ''/tmp/attacker.txt'' and ''/tmp/snortalert'' files on the controller node. Now, re-do the attack (by running !PortScanAttack.sh in section (7)) without load balancer
 . Stop PI-controller load balancer that we started in (2) above by pressing Ctrl+C on its terminal window.
 . Make sure the value of X is equal to 0 in file '' ~/Control/PI_controller/NFV_ratio_PI.txt ''. If it is not 0 (zero), open it in editor and make it 0. This will make sure that none of the traffic is send to VNF2. To open the file, use
+We will re-run the experiment without the load balancer to see the effects of load balancing. You should detect the attack more quickly using the load balancer.
+To re-run the experiment, you can keep everything running and just remove the ''/tmp/attacker.txt'' and ''/tmp/snortalert'' files on the controller node. Now, re-do the attack (by running !PortScanAttack.sh in Section (7)) without the load balancer.
+. Stop the PI-controller load balancer that we started in (2) above by pressing Ctrl+C on its terminal window.
+. Make sure the value of X is equal to 0 in file '' ~/Control/PI_controller/NFV_ratio_PI.txt ''. If it is not 0 (zero), open it in the editor and make it 0. This will make sure that none of the traffic is sent to VNF2. To open the file, use
 …
 You will need to run experiment multiple times and take average of values with and without load balancer. On average, you should see that using load balancer helps in quickly detecting and stoping the attack.
+You will need to run the experiment multiple times and take the average of the time taken to block the attack, with and without the load balancer. On average, you should see that using the load balancer helps in quickly detecting and stopping the attack.