Testing Document - DDOS Traffic Shaping Simulator

Transcription

1 Testing Document - DDOS Traffic Shaping Simulator Authors Inbar Shabi Anatoly Cherner

2 1. Functional Requirements 1.1 Client Graphical presentation of virtual network # Requirement Test Expected Result 1 Defining target/s computer to attack The user will define target computer in the *.ini file (configuration file). Special icon will symbolize the target computer and attack will be pointed towards it. 2 Network illustration Load trough the simulator a *. Net file with the routers and edges appropriate detail, as the file structure. network illustration should look as follows: The core, edge, and access routers are illustrated explicitly (by icons). The computers connected to the access routers are illustrated by clouds. The bots and target computers are illustrated by icons, and are explicitly connected to the access routers Simulation controllers and tools # Requirement Test Expected Result 3 Load 4 Configure Press on the load file button Load the simulator s configuration files: - *.ini - *.net 1. Change one of the scenario properties (Attack type, Start/end attack tu, Attack Client will load the scenario and the following will be shown: - Network graph - Network s routers - Attackers, targets computer (in clouds). The scenario properties have been changed according to the user choice.

3 5 Display statistics 6 Start 7 Pause 8 Rewind 9 Forward frequency, Num of attackers, Target s policy, Filtering routers) in *.ini file. 2. Load the file and check whether the configurations changed. 1. Start the scenario. 2. Check that the statistics (at the right panel) are being updated. Press on the start button. Press on the pause button. Press on the Rewind button. Press on the forward button. At the Gui right panel, presentation of statistics about: - Traffic in the network - Filtering routers - The target computer Are being displayed in a real-time presentation. The will start, and packets will start moving in the network graph. The will pause and the network animation will be freeze. After pressing this button, the will run backward. After pressing this button, the will run forward. 1.2 Server # Requirement Test Expected Result 10 load network Provide the server a *.net file with the same pattern as described in ADD. Server will simulate and create a network with all hardware devices: edge, core and access routers connected by links. 11 load configuration file 12 Legitimate traffic 13 Creating DDos attacks Provide the server a *.ini file with the same pattern as described in ADD. Define legal traffic in the *.ini file. Define one attack traffic (udp/ tcp/ icmp/ smurf/ fraggle/ Server will create the appropriate attack and legal objects with attackers, targets and legitimate hosts. The server will create and simulate legal botnet object. Server will create the appropriate attack as described in *.ini file.

4 14 Parallel attacks 15 filtering algorithms 16 Filtering policy 17 Filtering algorithms as plug-ins 18 output Statistic data TcpSyn/ pushack) in the *.ini file. Define more than one attack traffic (udp/ tcp/ icmp/ smurf/ fraggle/ TcpSyn/ pushack) in the *.ini file. Define in the *.ini file, one of the filtering algorithms (none, online, offline) on the routers. There is attribute in the *.ini file to define the target policy vector. Add a filtering algorithm class to the server. Load the simulator till the attacks will finish Server will create the appropriate attack as described in *.ini file. - Each of the filtering routers will be defined as in the file. - Only online algorithm will work as predicted, the rest two ( none and online ) will work as mock up. The policy vector/s by which the organization should filter the traffic in the network. It will be included in the *.ini file. The filtering algorithm will be executed with no problem and the expected result of the algorithm will occurred. Three *.csv files will be created and will contain the statistics about: tu, target computers and filtering routers. Online algorithm testing We have defined specific routers to run the online algorithm (and the rest routers other one). We calculate the expected amount of packets to reach the target computer and then check it by output files and debug-mode in the server side. Statistics testing In order to test the correctness of the statistics calculations: - We have run different attack scenarios with specified policy vector. - Calculate the expected result. - Check in the output files (*.csv files) that the results are as expected. ** Those testing made together with Polina Zilberman and the test example are attached to this document.

5 2. Non Functional Requirements 2.1 Testing system speed Test: In order to check that the system requirements are fulfilled, we measured by timer the time it takes to load the application. Expected result: it takes less than 1 min to load the application. 2.2 Testing system capacity Test: try to run the with more than one *.net files each scenario. Expected result: the option to add another one is not possible. Test: try run the with different *.net files contains up to 400 routers. Expected result: they loaded correctly. Test: press the rewind/forward option Expected result: the GUI shows the previous/future sessions respectively. 2.3 Testing system throughput Test: run the and check the statistics GUI and output files. Expected result: The *.csv output files and GUI present statistics each time unit (the time unit is show in the output files). 2.4 Testing system usability Test: deliver the prototype of the system to the users and examine their opinion and advices for making the much more usability. Expected result: the user is satisfied. 3. Unit testing During our code process we have created small functions to test the method we build. After each change in code, we executed those functions and verified that the changes didn t affect the old functionality. 4. User interface testing We test the UI manually by verifying each button reacts correctly to the required functionality.

6 5. Integration testing We define an interface between the client and server modules. Each function that sends data to the client was internal checked in the server and in client also. The client outputs the server messages so it easy to track any defects or uncorrected data sends.

7 6. Appendix Example scenarios (both use the same test.net ) Test.net ===================================================================== *Vertices 9 1 'V1' 'V2' 'V3' 'V4' 'V5' 'V6' 'V7' 'V8' 'V9' *Edges *NetworkDevice 1 Core 2 Core 3 Core 4 Edge 5 Edge 6 Access 7 Access 8 Edge 9 Access *PC_Access *Backplan

8 ===================================================================== testini_0.ini *LegalTraffic: IdOfBotnet,Type, Frequency, Start, End, CpuUsage, MemoryUsage 1 tcpsyn *BotnetAttack: Type, Frequency, Start, End, CpuUsage, MemoryUsage 2 tcp *BotnetAccessTarget 1 <9,1> 2 <9,1> *BotnetAccessZombie 1 <6,5> <7,3> 2 <6,5> <7,7> *TargetVectors 9 <1,tcp=150,tcpSyn=50,tmax=200> *Filtering 1 none 2 none 3 none 4 online 5 online 6 none 7 none 8 none 9 none testini_1.ini *LegalTraffic: IdOfBotnet,Type, Frequency, Start, End, CpuUsage, MemoryUsage 1 tcpsyn tcp

9 3 tcpsyn tcp tcpsyn tcp *BotnetAttack: Type, Frequency, Start, End, CpuUsage, MemoryUsage 7 tcpsyn tcp tcpsyn tcp tcpsyn tcp tcpsyn tcp *BotnetAccessTarget 1 <9,1> 2 <9,1> 3 <9,1> 4 <9,1> 5 <9,1> 6 <9,1> 7 <9,1> 8 <9,1> 9 <9,1> 10 <9,1> 11 <9,1> 12 <9,1> 13 <9,1> 14 <9,1> *BotnetAccessZombie 1 <6,5> <7,3> 2 <6,5> <7,7> 3 <6,0> <7,0> 4 <6,5> <7,5> 5 <6,0> <7,3> 6 <6,5> <7,0> 7 <6,1> <7,2> 8 <6,10> <7,10> 9 <6,5> <7,0> 10 <6,5> <7,10> 11 <6,5> <7,5>

10 12 <6,10> <7,10> 13 <6,0> <7,1> 14 <6,10> <7,10> *TargetVectors 9 <1,tcp=150,tcpSyn=50,tmax=200> *Filtering 1 none 2 none 3 none 4 online 5 online 6 none 7 none 8 none 9 none =====================================================================