wiki:GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu

Version 11 (modified by Nabeel Akhtar, 7 years ago) (diff)

--

Experiment 3: Handling Intrusion with Ryu Controller

Overview

In this experiment, we will use the Ryu controller to handle intrusion traffic. The system is the same as the one used in Experiment 2, 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, its information will be passed to the Ryu controller via the RINA distributed application, and then the Ryu controller will block the intrusion traffic by updating the OpenFlow rules on the OVS switch.

We use the same PI control for load balancing as in Experiment 2, and you can find details about the PI control there.

(1) RINA Distributed Application

Same as Part (1) RINA Distributed Application in Experiment 2.

(2) PI Controller

Same as Part (2) PI Controller in Experiment 2.

(3) PI-based Ryu Controller

Same as Part (3) PI-based Ryu Controller in Experiment 2.

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.

  1. 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 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
  1. In another separate window for s1, start the netcat client by running:
  • nc -u destination 5000
  1. Type something on the s1 window and you should see it on the destination window.
  1. 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:

  1. 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:
  1. Restart the netcat server on the destination by running:
  • nc -u -l 5000
  1. 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.

Next

Next: Finish?