Changes between Version 5 and Version 6 of GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu
- Timestamp:
- 05/17/17 18:52:42 (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GENIExperimenter/Tutorials/NFV/Ryu/HandlingIntrusionwithRyu
v5 v6 67 67 3. Type something on the s1 window and you should see it on the destination window. 68 68 69 4. In another separate window for s1, send ICMP messages to destination by runningthe following ping command:69 4. 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: 70 70 71 71 - ''' ping destination''' … … 78 78 }}} 79 79 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 80 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 it drops all traffic from the attacker with the following output: 82 81 83 82 {{{ … … 86 85 }}} 87 86 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. 87 6. Restart the netcat server on destination by running: 88 89 - ''' nc -u -l 5000 ''' 90 91 7. In another separate window for s2, start the netcat client by running: 92 93 - ''' nc -u destination 5000''' 94 95 Notice 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. 89 96 90 97 == Next ==