Changes between Version 5 and Version 6 of GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu


Ignore:
Timestamp:
05/17/17 18:52:42 (2 years ago)
Author:
Nabeel Akhtar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu

    v5 v6  
    67673. Type something on the s1 window and you should see it on the destination window.
    6868
    69 4. In another separate window for s1,  send ICMP messages to destination by running the following ping command:
     694. In another separate window for s1,  we will create attack traffic, which in our case are ICMP messages. To send ICMP messages to destination, run the following ping command:
    7070
    7171   - ''' ping destination'''
     
    7878 }}}
    7979
    80 If you go to the controller window which runs the Ryu controller, you can see it drops all ICMP messages from the attacker with the following output:
    81 
     805. 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 it drops all traffic from the attacker with the following output:
    8281
    8382{{{
     
    8685 }}}
    8786
    88 Meanwhile, you can type messages on the netcat client side on s1, and all messages are still able to reach destination since only ICMP messages are blocked from s1.
     876. Restart the netcat server on destination by running:
     88
     89   - ''' nc -u -l 5000 '''
     90
     917. In another separate window for s2, start the netcat client by running:
     92
     93   - ''' nc -u destination 5000'''
     94
     95Notice that using the netcat client side on s2, all messages are able to reach destination since s2 traffic is not blocked. However, no traffic from s1 reaches destination since s1 is blocked.
    8996 
    9097== Next ==