Denial of Service (DOS) Testing Sample Test Plans - Ixia

Denial of Service (DOS) TestingSample Test Plans

ContentsOverview of Denial of Service functionality in IxChariot..................................3A brief outline of the DoS attack types supported in IxChariot...................... 4Test Case 1: Ping Attack on Oracle Traffic........................................................5Test Case 2: VoIP and TCP SYN Attacks...........................................................8Copyright © 2005 Ixia. All rights reserved.The information in this document is furnished forinformational use only, is subject to changewithout notice, and should not be construed as acommitment by Ixia. Ixia assumes noresponsibility or liability for any errors orinaccuracies that may appear in this document.Ixia and the Ixia logo are trademarks of Ixia. Allother companies, product names, and logos aretrademarks or registered trademarks of theirrespective holders.Ixia26601 W. Agoura RoadCalabasas, CA 91302Phone: (818) 871-1800Fax: (818) 871-1805Email:info@ixiacom.comInternet: www.ixiacom.com Copyright © Ixia, 2005Denial of Service (DOS) Testing: Sample Test Plans

Denial of Service (DOS) Testing: Sample Test PlansDenial of Service (DoS) attacks are a reality for most organizations with connections to the public Internet. In order toprotect yourselves from the potential hazards of network hackers and malicious coders, a set of devices and softwarebasedtools such as DUTs, intrusion detection systems (IDS), remote access solutions (VPN) and sophisticated routers andL4-7 application switches have been developed to effectively block malicious traffic and protect the organization’s dataand information infrastructure.Leveraging the advanced functionality of Ixia hardware, IxChariot is now capable of generating line-rate traffic thatemulates common DoS attack types while at the same time generating and measuring the performance of applicationtraffic (VoIP, Internet, enterprise) that is being sent over the network.This test primer outlines how IxChariot software can be used on an Ixia platform to:• assess the impact of DoS traffic on existing network traffic• measure the performance of devices responsible for denying DoS traffic network access• determine the performance of network devices that are being attacked (e.g. servers, routers, WLAN access points)Overview of Denial ofService functionality inIxChariotT he test cases for IxChariot’s integratedDoS/application traffic emulation can besplit into two principal groups:• generating DoS/application trafficbetween two Ixia ports and measuringthe performance of the overall network• directing DoS traffic against aspecific device (e.g. firewall) whilegenerating and measuring theperformance of application traffic beingsent between two IxChariot PerformanceEndpointsIn each case, performance measurementsneed to be taken with both DoS filtering/blocking solutions being enabled as well asdisabled. Copyright © Ixia, 2005Denial of Service (DOS) Testing: Sample Test Plans

A brief outline of theDoS attack typessupported in IxChariotIxChariot has the ability to produce severalcommon types of DoS attacks, as explainedbelow. Keep in mind that such attacksare created within Ixia-specific hardware,generated directly using Field ProgrammableGate Arrays (FPGA), and as such, thismalicious traffic can be generated in speedsranging from zero to the full wire speed ofthe interface.SYN AttackEvery TCP connection begins with asingle TCP SYN flag being sent from theclient host to a server. In response toreceiving such a flag, the server typicallyallocates resources and then sendsa TCP SYN-ACK packet back towardthe client host station. A SYN attackoverwhelms the victim computer witha rapid succession of SYN packets,causing it to over allocate resources andeither crash or wait for the allocatedresources to time out.Teardrop AttackFragmented packets that continuouslyoverlapping offsets are sent from aclient to a server. The server cannotreconstruct the original payload fromthe fragmented overlapping packets andeventually crashes.Ping AttackAn ICMP Ping Request is sent to aserver at a high rate, causing bandwidthproblems on the server’s network.Ping of Death (POD) AttackICMP Ping Requests are sent froma client to a server; however, eachpacket is a fragment of a complete PingRequest of extremely large size. Thismay cause the server to over allocateresources and crash.Unreachable Host AttackAn “ICMP Host Unreachable” messagemay be sent to a server that is already incommunication with another host. Thiswill likely cause the server to drop thatconnection. Test case examplesThree test cases are observed in thefollowing sections. These simple test casesshow how to set up IxChariot for testingthe performance of networks and specificdevices when being loaded with both DoSand standard application traffic.Figure 1 shows the setup that will beused for the test cases outlined below. Alladdresses used in the course of testingappear in this Figure, including both IPv4 andIPv6 addresses. Only two physical Ixia portsare used in this scenario. Copyright © Ixia, 2005Denial of Service (DOS) Testing: Sample Test Plans

Test Case 1: Ping Attackon Oracle TrafficObjectiveIn this test case, you will create a typicaltraffic pattern of Oracle traffic, operating overa known port. After measuring throughput,response time and transaction rates, youwill start a DoS Ping attack and compare theresults.Methodology1. Create an Oracle transaction as per thefollowing criteria:• Endpoint 1 and Endpoint 2 networkaddresses assigned as per your setup• Set up the “How does the Consoleknow Endpoint 1” address using the Ixiamanagement address, e.g.; 10.0.3.1.Similarly, set up a management addressfor the “How does Endpoint 1 knowEndpoint 2?” address, e.g.; 10.0.3.2• Use a sample script such as Oracle_AP_Tier2_Invoice_Mult_Dist.scr” scriptfor this pair.• Edit the script so that it usesTCP port 2321. Also, use minimumtransaction delays and unlimited senddata rate.• Replicate pairs n times according toyour traffic volume. In this case, the pairwas replicated 19 times so that thereare a total of 20 Oracle traffic flows inthis test.• Set the run time for 1 minute. Besure to choose the ‘Batch mode’ runoption.• In the resulting charts, you may wantto display a total rather than the resultsof each individual script.. Ensure that the DUT allows all traffic(rules not enforced) to pass through togenerate a set of baseline test results.3. Run the transaction and record resultsin the “No DoS/No DUT” column in table1 below. See Figure 2 for a typical resultsscreen.4. Now instruct the DUT to enforce its rules,and then re-run the transaction. Record theresults in the “No DoS/DUT” column in table1 below. This should tell you whether or notthe DUT is affecting traffic rates. Note thatthe DUT should be set up to defend againstthe DoS Ping attack, which will be used in asubsequent step.5. Now instruct the DUT to NOT enforce itsrules and insert a DoS attack. This particularattack should emanate from Endpoint 1 andtarget Endpoint 2.6. Depending on the capabilities of your DUTand the available network bandwidth, youmay want to override the stream line rate(e.g. 15%). Also, ensure that the “Measurehardware performance pair statistics”checkbox is in the UNCHECKED position.This will ensure that the target CPU (in thiscase, the Ixia CPU) handles the details of theincoming ICMP Ping requests. See Figure 3for a description of what this should look like.Run and record the results in the “DoS NoDUT” column of table 1. For a comparativelook at results with DoS and no DUT, seeFigure 4.7. Now enable the DUT and re-run thetransaction. Record the results in the “DoS /DUT” column in table 1 below.8. The completed table should give you agood comparative analysis of how well yourDUT can protect internal hosts from DoS Pingattacks. Copyright © Ixia, 2005Denial of Service (DOS) Testing: Sample Test Plans

DescriptionNo DoSNo DUTNo DoSDUTDoSNo DUTDoSDUTThroughput AverageThroughput MinimumThroughput MaximumThroughput AverageThroughput MinimumThroughput MaximumThroughput AverageThroughput MinimumThroughput MaximumTable 1: Comparative test table for enterprise application traffic with DoS attack traffic.Figure 2: Typical results for no DoS and no DUT. Copyright © Ixia, 2005Denial of Service (DOS) Testing: Sample Test Plans

Figure 3: Setting up for DoS Ping attacks.Figure 4: Comparative results for DoS and no DUT Copyright © Ixia, 2005Denial of Service (DOS) Testing: Sample Test Plans

Test Case 2: VoIP andTCP SYN Attacks Copyright © Ixia, 2005ObjectiveThis test case will observe what happens ina VoIP environment when a series of SYNattacks are directed at a host. It will showhow VoIP connections can be sabotagedwhen the DUT is not configured correctly.MethodologyA communication channel will be set upbetween two sets of Performance Endpoints,creating several VoIP conversations. A TCPSYN attack will be launched against one ofthe endpoints from a third location. The DUTwill initially allow the attack to proceed. Inthe second iteration, the DUT will be trainedto disallow any TCP connection attemptsfrom the third party location.Figure 1 will be used to model theattack. The VoIP conversations will existbetween the 172.176.25/24 and the192.168.10/24 networks. Another networkwill be superimposed on the same physicalconnection as the 172.176.25/24 network,utilizing an address from the 123.227.25/24network.Note that IxApplifier will be used to installan address range of 172.176.25.101 to172.176.25.120 on the public side of theDUT, and address range of 192.168.10.101to 192.168.10.120 on the private side. Also,the third party address of 123.127.25.100will be installed on the external port. It willtarget address 192.168.10.101 on theinternal port, using the DUT as a gateway ataddress 123.227.25.1.1. Set up VoIP pairs between internaland external clients. The VoIP traffic willtravel in both directions; that is, half of theconnections will have Endpoint 1 on theprivate side of the DUT, and half will haveEndpoint 1 on the public side. Set up a totalof 20 pairs. See the setup in Figure 5.. Ensure that the DUT rules enforcement isturned off.3. Set up the attacking port to use ahardware performance pair. Select theIPv4_Syn_Port80_74Bytes.str pattern. Makesure “Measure hardware performance pairstatistics” is left unchecked so that thevictim port (internal port) responds to theattack. Finally, override the stream line rateand set up a very low rate of attack. You mayhave to experiment a bit with this number. Agood starting point is 0.01%. The objectiveis to slowly overwhelm the victim port as thetest is underway.4. Set the run time for 1 minute, and runthe test. You should see the MOS scoresregistering an almost perfect performanceup to the point that the victim processorgets overwhelmed with TCP requests. At thatpoint, the MOS scores will cease to exist,indicating that no more data is coming infrom the victim port.5. If the target port did not crash, go back tostep 3 and adjust the stream line rate higher.You should not have to go any higher than5% to see the detrimental results of a TCPSYN attack.6. Turn on DUT rule enforcement. Thereare several things that can be done to theDUT, depending on the sophistication of thefiltering required. If the DUT terminates andproxies TCP connections, then you couldturn on TCP SYN-Cookies to stop the effectsof the SYN attack. The simplest method isto simply filter on the malicious address,123.227.25.100. This may not be practicalin the real world, but it can demonstrate theDUT’s ability to filter on undesirable sourceaddresses.7. Run the test again and ensure that theMOS scores stay at their near-perfect levelsthroughout the test.Denial of Service (DOS) Testing: Sample Test Plans

Figure 5: VoIP setup Copyright © Ixia, 2005Denial of Service (DOS) Testing: Sample Test Plans