Changes between Initial Version and Version 1 of GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu-portscanning

Timestamp:

10/30/17 11:58:58 (7 years ago)

Author:

Nabeel Akhtar

Comment:

--

GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu-portscanning

@@ +1 @@
+=  Experiment 4: Handling Intrusion with Ryu Controller - Port Scanning Attack= 
+
+== 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. 
+
+
+{{{
+#!html
+<img src="https://raw.githubusercontent.com/akhtarnabeel/public/master/Figures/MainCT_updated.png" hspace=50>
+ }}}
+
+We use the same PI control for load balancing as in [wiki:GENIExperimenter/Tutorials/NFV/Ryu/LoadBalancePIwithRyu Experiment 2], and you can find details about the PI control there. 
+
+== (1) RINA Distributed Application == 
+(Same as Part (1) RINA Distributed Application in [wiki:GENIExperimenter/Tutorials/NFV/Ryu/LoadBalancePIwithRyu Experiment 2]. )
+
+First we will run a RINA distributed application to collect the VNF load information on the controller node.
+
+{{{
+#!html
+<table id="Table_02" width = "1150" border="0" cellpadding="0" cellspacing="10" >
+ <tr> 
+<td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image068.gif" > </td>
+<td>  We need Java installed on the <i> VNF1, VNF2 </i> and <i> controller </i> nodes to run the RINA application. Check if Java is installed using: java -version. If not, install java on <i> VNF1, VNF2 </i> and <i> controller </i> nodes in new windows (Type Ctrl-C to exit netcat on the sources and destination). To install Java, execute: &nbsp;<span style="background:#c0c0c0; font-size: 10pt"><b>sudo apt-get install openjdk-7-jdk </b> </span> <br>
+<b>(If the install fails, you may first run: sudo apt-get update. In some cases, you may need to first run: sudo add-apt-repository ppa:openjdk-r/ppa followed by: sudo apt-get update.)</b>  
+ </td></tr></table>
+}}}  
+
+
+     1.  In the controller window, download the RINA controller code:
+
+      - ''' cd ~ '''
+      - '''  wget !http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/rina/Control.tar.gz '''
+      - ''' tar -xvf Control.tar.gz '''
+
+
+ 2.     Type ''ifconfig'' to get the IP address of the controller. Save this address as we will need this address to direct the RINA processes on the VNFs to the RINA process on the controller.
+
+ 3.     In a new VNF1 window, download the RINA VNF1 code:
+
+
+      - ''' cd ~ '''
+      - '''  wget !http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/rina/VNF1.tar.gz '''
+      - ''' tar -xvf VNF1.tar.gz '''
+
+ 4.     In a new VNF2 window, download the RINA VNF2 code.
+
+
+      - ''' cd ~ '''
+      - '''  wget !http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/rina/VNF2.tar.gz '''
+      - ''' tar -xvf VNF2.tar.gz '''
+
+ 5.     Now we will change the IP address in the RINA configuration files for VNF1, VNF2 and controller, so these RINA processes can talk to each other.
+ In the VNF1 window, execute:
+
+      - ''' cd ~/VNF1'''
+      - ''' nano ipcVNF1.properties '''
+
+ At the bottom of the file, change the '''''rina.dns.name''''' and '''''rina.idd.name''''' to the IP address of the controller. The following screenshot shows an example.
+
+{{{
+#!html
+<img src="http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/pics/DNSIDDConfig.png" hspace=50>
+ }}}
+
+ In the VNF2 window, execute:
+
+      - ''' cd ~/VNF2'''
+      - ''' nano ipcVNF2.properties '''
+ 
+ At the bottom of the file, again change the '''''rina.dns.name''''' and '''''rina.idd.name''''' to the IP address of the controller.
+
+ In the controller window, execute:
+
+     - '''cd ~/Control/RINA'''
+     - '''nano ipcControl.properties'''
+
+ At the bottom of the file, again change the ''''rina.dns.name'''' and ''''rina.idd.name'''' to the IP address of the controller.
+
+
+
+ 6.     To run the RINA application, follow these steps (make sure you installed Java as noted above):
+
+  o   In the controller window, execute the following commands:
+
+      - ''' cd ~/Control/RINA/'''
+      - ''' ./run_controller.sh '''
+
+  o   In the VNF1 window, execute the following commands:
+
+      - '''cd ~/VNF1/'''
+      - ''' ./run_VNF1.sh '''
+
+
+  o   In the VNF2 window, execute the following commands:
+
+      - '''cd ~/VNF2/'''
+      - ''' ./run_VNF2.sh '''
+
+
+ 
+  You should see output on the controller window as shown below:
+{{{
+#!html
+<img src="http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/pics/subInfo.png" hspace=2>
+ }}}
+
+{{{
+#!html
+<table id="Table_02" width = "1150" border="0" cellpadding="0" cellspacing="10" >
+ <tr> 
+<td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image068.gif" > </td>
+<td>  <i> The RINA application on VNF1 and VNF2 should be run as soon as possible after the RINA application on the controller  is started. If you wait for too long, you will get <b> null</b> values for CPU usage, as the controller's RINA app is not able to subscribe to the CPU load of the VNFs. </i> If this is the case, you should restart all RINA processes.   
+ </td></tr></table>
+}}}  
+
+
+'''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.'''
+
+
+
+{{{
+#!html
+<table id="Table_02" width = "650" border="0" cellpadding="0" cellspacing="10" >
+ <tr> 
+<td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image022.gif" > </td>
+<td>  <i> To stop all RINA processes running on a VM, run <b> killall -v java </b> </i> 
+ </td></tr></table>
+}}}  
+
+
+
+== (2) PI Controller ==
+(Same as Part (2) PI Controller in [wiki:GENIExperimenter/Tutorials/NFV/Ryu/LoadBalancePIwithRyu Experiment 2]. )
+
+{{{
+#!html
+<table id="Table_02" width = "1150" border="0" cellpadding="0" cellspacing="10" >
+ <tr> 
+<td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image068.gif" > </td>
+<td>   The PI-controller gets the load information of VNF1 and VNF2 using RINA's distributed application and makes the load balancing decision. 
+ </td></tr></table>
+}}}  
+
+
+ 
+
+ The figure below shows the block diagram of the Proportional Integral (PI) controlled NFV system.
+
+{{{
+#!html
+
+<table id="Table_02" width = "1150" border="0" cellpadding="0" cellspacing="0" align="center" >
+<tr> 
+<td><img src="http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image074.gif" hspace=2/></td></tr>
+
+<tr><td> <i style="font-size:9px">Block diagram of the PI-controller NFV system. System load L and target load T(s)=T/s of VNF1 is used to compute X, i.e. ratio of traffic diverted to VNF2. K` = K/T.</i></td></tr>
+</table>
+
+ }}}
+
+ The RINA-based distributed monitoring application provides the VNF1 state (average CPU load) information L(t) to the PI controller. The maximum capacity of a VNF instance is T. If the load on VNF1 exceeds T, new traffic flows are forwarded to a second VNF instance, VNF2. Assuming instantaneous feedback / measured load L(t), the PI control equation is given by:
+
+
+{{{
+#!html
+<img src="http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image076.gif" hspace=70>
+
+ }}}
+
+ The code for the PI controller is based on the following algorithm. Input ''IDS,,load,,.txt'' is the file generated by the RINA distributed application. This file has load information of the VNFs.
+
+{{{
+#!html
+<img src="http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image078.gif" hspace=40>
+
+ }}}
+
+  1.     To run the PI-controller, open a new controller window and execute:
+
+         - ''' cd ~/Control/PI_controller '''
+         - ''' python PI_controller.py ~/Control/RINA/NFV1.txt'''
+
+
+
+ Note that here we are directing ''PI_controller.py'' to the ''NFV1.txt'' file that is constantly updated by the RINA distributed application with the load information of VNFs.
+  2.     You should see the VNF state information printed on the screen. A sample output is shown below.
+
+{{{
+#!html
+<img src="http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/pics/PIPic.png" hspace=40>
+
+ }}}
+ Here the target load on VNF1 is 30.0% of CPU usage, i.e. if the CPU load on VNF1 is more than 30.0%, traffic flows will be diverted to VNF2. The `current CPU load` shows the load on VNF1. The next line of the output shows the percentage of flows that will be directed to VNF2 and the last line shows the flows that were being directed to VNF2 before the current control update.
+
+ '''Do not close this window; leave the PI controller running.'''
+
+
+== (3) PI-based Ryu Controller ==
+(Same as Part (3) PI-based Ryu Controller in [wiki:GENIExperimenter/Tutorials/NFV/Ryu/LoadBalancePIwithRyu Experiment 2]. )
+
+ Now we will run the Ryu controller that will get the load balancing decision from the PI-controller and direct the flows accordingly.
+
+ 1.     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:
+
+         - ''' 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]]
+    '''''/users/<!UserName>/Control/PI_controller/NFV_ratio_PI.txt'''''[[BR]]
+    Change the '''''<!UserName>''''' to your user name.[[BR]]
+
+
+ 2.     Now we can run the Ryu controller. Execute
+
+        - ''' /tmp/ryu/bin/ryu-manager --verbose /tmp/ryu/ryu/app/nfv_controller.py'''
+
+ == (4) Run Snort and Generate Traffic == 
+
+ 1.     First we will run Snort IDS on VNF1 and VNF2. In separate windows for VNF1 and VNF2, execute the following command:
+
+          - '''sudo /usr/local/bin/snort -A full -dev -i eth1'''
+
+
+
+ 2.     We will use the iperf application to generate flows between a source and destination. If iperf is not installed on your nodes, execute:
+
+  - ''' sudo apt-get install iperf '''
+
+
+ 3.     Run iperf server on the destination node:
+
+  - ''' iperf -u -s '''
+
+
+ 4.     Now we will generate traffic from the sources (s1 and s2) 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:
+
+  - ''' iperf -u -c destination -t 500 & '''
+
+{{{
+#!html
+<table id="Table_02" width = "1150" border="0" cellpadding="0" cellspacing="10" >
+ <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 500 & </span> multiple times in s1 and s2 nodes. This flow lasts for 500 seconds. For this experiment, you may try to run 2-3 iperf instances. To kill all the flows generated at a node, run <span style="background:#c0c0c0"> killall –v iperf </span> </i> 
+ </td></tr></table>
+}}} 
+
+ 5.     Now if you look at the controller window, which is running the PI-controller, you can see the load on VNF1 has significantly increased. If the load is more than 30%, some percentage of the traffic flows will be diverted to VNF2. 
+
+{{{
+#!html
+<table id="Table_02" width = "700" border="0" cellpadding="0" cellspacing="10" >
+ <tr> 
+<td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image022.gif"> </td>
+<td> <b>OPTIONAL: Review the PI Ryu Controller Code</b> </td> </tr></table>
+}}}
+
+
+The Ryu controller gets the load balancing information from the output text file generated by the PI-controller. Based on the  value of the control variable  (variable X), it sends each new flow to either VNF1 or VNF2. The algorithm for the PI-based OVS controller is shown below.
+
+
+{{{
+#!html
+<img src="http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image092.gif" hspace=40>
+
+ }}}
+
+
+'''Note: You can see in "nfv.config" that the information of the intrusion traffic is located in the file ''/tmp/attacker.txt'' on the controller VM, which is outputted by the RINA distributed application. Make sure the file is empty each time you run this experiment.'''
+
+== (4) Run Snort  == 
+
+''' Note: keep the RINA application processes, PI controller process and PI-based Ryu controller process from the previous 3 steps running in the background. '''
+
+1. We need to first install our own Snort rule on Snort, so that it can detect the intrusion traffic specified in our rule. 
+
+ To install our own rule and configure Snort, in separate windows for VNF1 and VNF2, execute the following commands: 
+    
+    - ''' cd ~ '''
+    - ''' wget !http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/snort/config_snort.sh '''
+    - ''' chmod 755 config_snort.sh '''
+    -  ''' ./config_snort.sh '''
+
+Here we use a simple rule where all ICMP traffic to the ''destination'' node is considered as intrusion traffic, and the rule is specified as follows:  
+
+''' alert icmp any any -> 10.10.1.5 any (msg:"ICMP traffic found to Destination";sid:1000001;) ''' 
+
+in the file ''' /etc/snort/rules/my.rules'''. 
+
+
+2. We then run Snort IDS on VNF1 and VNF2. In separate windows for VNF1 and VNF2, execute the following command:
+
+   - ''' 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: 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: If you want to re-run this experiment, make sure to remove both files: '' /var/log/snort/alert'' on both VNF nodes, and ''/tmp/attacker.txt'' on the controller node. '''
+
+==  (5) Generate Regular and Intrusion Traffic == 
+
+1. In a separate window for destination, start the netcat server by running:
+
+   - ''' nc -u -l 5000 '''  
+
+2. In another separate window for  s1, start the netcat client by running: 
+
+   - ''' nc -u destination 5000'''
+
+3. Type something on the s1 window and you should see it on the destination window.
+
+4. In another separate window for s1,  we will generate attack traffic, which in our case are ICMP messages. To send ICMP messages to the destination, run the following ping command: 
+
+   - ''' ping destination'''
+
+The first few ping messages are able to reach destination since it takes some time for the controller to get the intrusion detection results from the VNFs via the RINA distributed application, but after a few seconds, all following ping messages will not be able to reach the destination, and you should see the following output: 
+
+{{{
+#!html
+<img src="http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/pics/failedPing.png" hspace=50>
+ }}}
+
+5. Type something on the s1 window for netcat and you should NOT see it on the destination window. If you go to the controller window which runs the Ryu controller, you can see that all traffic from the attacker is dropped with the following output:
+
+{{{
+#!html
+<img src="http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/pics/intrusion.png" hspace=50>
+ }}}
+
+6. Restart the netcat server on the destination by running:
+
+   - ''' nc -u -l 5000 ''' 
+
+7. In another separate window for s2, start the netcat client by running: 
+
+   - ''' nc -u destination 5000'''
+
+Notice that using the netcat client side on s2, all messages are able to reach the destination since s2 traffic is not blocked. However, no traffic from s1 reaches the destination since s1 is blocked. 
+ 
+== [wiki:GENIExperimenter/Tutorials/NFV/Ryu/Finish Next: Finish] ==