Changes between Version 46 and Version 47 of GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu-portscanning
- Timestamp:
- 10/31/17 16:32:35 (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu-portscanning
v46 v47 3 3 == Overview == 4 4 5 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.5 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. 6 6 7 7 … … 14 14 == (1) RINA Distributed Application == 15 15 16 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 byRINA distributed application.16 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. 17 17 18 18 … … 116 116 117 117 118 '''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.'''119 120 121 118 122 119 {{{ … … 200 197 Now we will run the Ryu controller that will get the load balancing decision from the PI-controller and direct the flows accordingly. 201 198 202 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:199 1. 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: 203 200 204 201 - ''' nano /tmp/ryu/ryu/app/nfv.config''' 205 202 206 203 o Change the value of '''controller_type''' to '''PI''' [[BR]] 207 o Change the value of '''''file_path_pi''''' to the text file that has the PI controller `s output.[[BR]]204 o Change the value of '''''file_path_pi''''' to the text file that has the PI controller's output.[[BR]] 208 205 '''''/users/<!UserName>/Control/PI_controller/NFV_ratio_PI.txt'''''[[BR]] 209 206 Change the '''''<!UserName>''''' to your user name.[[BR]] … … 218 215 ''' Note: keep the RINA application processes, PI controller process and PI-based Ryu controller process from the previous 3 steps running in the background. ''' 219 216 220 1. We need to first configure snort so that we can use our rules, or snort’s build-in rules to detect the intrusion traffic.217 1. We need to first configure Snort so that we can use our rules, or snort’s build-in rules to detect the intrusion traffic. 221 218 To configure Snort, in separate windows for VNF1 and VNF2, execute the following commands: 222 219 … … 226 223 - ''' ./config_snort.sh ''' 227 224 228 2. 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. 229 230 3. 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 225 2. 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. 226 227 3. Update “/etc/snort/snort.conf” to enable the port scanning functionality of Snort. You can update it by uncommenting the following line: 228 229 - ''' preprocessor sfportscan: proto { all } memcap { 10000000 } sense_level { low } ''' 230 231 and updating it as follows 231 232 232 233 - ''' preprocessor sfportscan: proto { all } memcap { 10000000 } sense_level { medium } logfile { /var/log/snort/alert } ''' … … 236 237 - ''' sudo /usr/local/bin/snort -A full -dev -c /etc/snort/snort.conf -i eth1''' 237 238 238 ''' Note: exit from previous instances of snort if they are still running from earlier experiments before you run this instance of snort. '''239 ''' Note: exit from previous instances of Snort if they are still running from earlier experiments before you run this instance of Snort. ''' 239 240 240 ''' 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. ''' 241 242 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. 241 ''' 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. ''' 242 243 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. 244 245 246 == (5) Run Attack Analyzer == 247 248 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. 249 250 Open a separate window for the Controller, and run the attack analyzer. [[BR]] 251 252 ''' cd ~/Control/AttackAnalyzer/ ''' 253 254 ''' python !AttackAnalyzer.py -f /tmp/snortalert ''' [[BR]] 243 255 244 256 ''' Note: If you want to re-run this experiment, make sure to remove ''/tmp/attacker.txt'' and ''/tmp/snortalert'' files on the controller node. ''' 245 257 246 == (5) Run Attack Analyzer ==247 248 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.249 250 Open a separate window for Controller, run attack analyzer. [[BR]]251 252 ''' cd ~/Control/AttackAnalyzer/ '''253 254 ''' python !AttackAnalyzer.py -f /tmp/snortalert ''' [[BR]]255 256 257 258 == (6) Generate background traffic == 258 259 … … 265 266 '''iperf -u -s ''' 266 267 267 3. 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:268 3. 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: 268 269 269 270 ''' iperf -u -c destination -t 5000 & ''' … … 274 275 <tr> 275 276 <td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image068.gif" > </td> 276 <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 bothVNF1 and VNF2. To kill all the flows generated at a node, run <span style="background:#c0c0c0"> killall –v iperf </span> </i>277 <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> 277 278 </td></tr></table> 278 279 }}} … … 280 281 == (7) Generate Intrusion Traffic == 281 282 282 1. 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), pingdestination:283 1. 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: 283 284 284 285 ''' ping destination''' … … 286 287 Your ping should reach the destination and it should not be blocked. 287 288 288 2. Install port scanner application nmap on s2289 2. Install the port scanner application Nmap on s2 289 290 290 291 ''' sudo apt-get update ''' … … 296 297 ''' wget !https://raw.githubusercontent.com/akhtarnabeel/public/master/NFV-GENI/PortScanAttack.sh ''' 297 298 298 change file permissions so you can run it299 change the file permissions so you can run it 299 300 300 301 ''' chmod 777 !PortScanAttack.sh ''' 301 302 302 303 303 3. Run the file to create an attack304 3. Generate the port scanning attack by typing 304 305 305 306 ''' ./!PortScanAttack.sh ''' 306 307 307 Attack file hasfollowing content308 The !PortScanAttack.sh file has the following content 308 309 309 310 {{{ … … 312 313 }}} 313 314 314 Every 0.2 seconds, source node generates a ping to destination node and the output of ping is saved in ''ping.log'' file. 315 316 317 Soon after starting ping message, nmap is used to attack destination. 318 319 320 4. 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. 321 322 323 324 5. 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 315 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. 316 317 Concurrently with these pings, Nmap is used to attack the destination using port scans. 318 319 We will count how many pings will go through before the system detects the port scans and blocks source s2. 320 321 322 4. 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. 323 324 325 326 5. 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 325 327 326 328 ''' cat ping.log ''' 327 329 328 330 329 Here is sample output331 Here is a sample output 330 332 331 333 … … 336 338 337 339 338 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.340 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. 339 341 340 342 … … 342 344 == (8) Re-run experiment without load balancer == 343 345 344 We will re-run the experiment without load balancer to see the effects of load balancer. You should detect attack quickly usingload balancer.345 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 balancer346 347 1. Stop PI-controller load balancer that we started in (2) above by pressing Ctrl+C on its terminal window.348 349 350 2. 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 sendto VNF2. To open the file, use346 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. 347 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. 348 349 1. Stop the PI-controller load balancer that we started in (2) above by pressing Ctrl+C on its terminal window. 350 351 352 2. 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 351 353 352 354 … … 356 358 357 359 358 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.360 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. 359 361 360 362