Defending Against DoS Attacks

by Tina Darmohray and Ross Oliver

The recent Denial of Service, DoS, attacks have proven to be challenging for even the most well-secured sites. Using distributed commandeered systems to launch the attacks resulted in a "win-win" scenario for the attackers: they benefited from access to more horsepower than they own directly, and they covered their tracks more thoroughly since a trace back to the attacking machines simply lead to the other set of victims, the commandeered machines. With this kind of leg up, what kind of countermeasure can organizations use to defend against this type of attack?

By flooding a machine with illegitimate initial SYN packets which won't be acknowledged, you can exceed a systems' limit of connections which are waiting to be established. In this way you can prevent a machine from being able to respond to any legitimate connection requests.

Like most computer security problems there is no single silver bullet that will defend against a DoS attack, but there are ways you can mitigate the problems. The CERT Coordination Center Denial of Service Tech Tip [1] suggests that sites invest in "hot spares" which can be pressed into service in the event that a similar machine is disabled by an attack. Another approach would be to have an arsenal of SYN protectors that can sit in front of your Internet resources and take the brunt of the SYN flood attacks.

We're researching a number of firewall solutions to determine what kind of protection they provide against SYN flood attacks. We determined that some of them offer value-added features that deflect SYN floods. One way they do this by proxying the requests and not passing them on to the victim server unless the 3-way handshake is complete.

In order to test the firewalls we created a test environment to simulate the DoS attacks we'd been seeing in the last several months. Our environment consists of a Linux 2.2.12-20-based attack machine, an NT client machine to fetch web pages, a Linux 2.2.12-20-based victim web server to serve up web pages, and a firewall solution in the middle. Our SYN flooder is a proprietary program that is designed to achieve the maximum possible SYNs/second. Using the shortest ethernet frame size of 64 bytes, the maximum rate of a 10Mb ethernet is 14,880 pps. Our SYN packet is padded to the the minimum ethernet [RFC894] packet size, so the maximum SYN flood rate of a 10Mb ethernet is ~14,880 SYNs per second and a 100Mb ethernet is ~148,800 SYNs/sec.

Test Environment:

        client
                \
                 \
                   firewall   -----   victim web server
                   solution
                  /
                 /
        SYN attacker

We created a script on the client system to continuously request a set of web pages from the victim web server and measured the elapsed time to get the pages under normal network conditions. Then, to test the effectiveness of the firewall solution, we launched the SYN flood attack and determined what effect it had on the elapsed time to get the pages. We used a Checkpoint to test a traditional firewall passing the SYNs on to the victim web server, and a NetScreen-100 to test a solution which proxies SYN requests. Here's what we observed:

DoS demo against traditional firewall solution [Nokia running Checkpoint]:

Output from the client attempting to fetch web pages from the victim web server:

C:\DEMO>fetch web-pages Fetching 21 HTML pages, total 35K of data... Elapsed time: 2.78 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 2.61 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 2.81 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 2.18 seconds Fetching 21 HTML pages, total 35K of data... SYN FLOOD LAUNCHED Elapsed time: 26.02 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 36.07 seconds ................ ATTACK ENDED Fetching 21 HTML pages, total 35K of data... Elapsed time: 2.68 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 2.39 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 2.70 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 2.79 seconds Fetching 21 HTML pages, total 35K of data... ^CTerminate batch job (Y/N)? y C:\DEMO>

Output from the attack machine showing SYN flood rate: [each '%' represents ~ 500 SYNs and is displayed in real time on the attack machine] % flood firewall Rate: 495 SYN/sec %%%%% Rate: 495 SYN/sec %%%%% Rate: 495 SYN/sec %%%%% Rate: 496 SYN/sec %%%%% Rate: 495 SYN/sec %%%%% Rate: 496 SYN/sec %%%%% Rate: 495 SYN/sec %%%%% Rate: 495 SYN/sec %%%%% Rate: 496 SYN/sec %%%%% Rate: 494 SYN/sec

`DoS demo against Proxied-SYN Solution [NetScreen-100]:`

Output from the attack machine showing SYN flood rate: C:\DEMO>fetch web-pages Elapsed time: 1.29 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 0.99 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 0.93 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 0.95 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 0.92 seconds Fetching 21 HTML pages, total 35K of data... SYN FLOOD LAUNCHED Elapsed time: 0.96 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 0.94 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 0.94 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 0.94 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 0.94 seconds Fetching 21 HTML pages, total 35K of data... Elapsed time: 0.91 seconds Fetching 21 HTML pages, total 35K of data... ^CTerminate batch job (Y/N)? y C:\DEMO> Output from the attack machine showing SYN flood rate: % flood netscreen %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%% Rate: 13869 SYN/sec %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%% Rate: 13927 SYN/sec %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%% Rate: 13966 SYN/sec %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%% Rate: 14970 SYN/sec %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%% Rate: 14577 SYN/sec %%%%%%%%%%%%%%%%%%%%% SYN flood attack host type 'flood' for instructions -> What We FoundWith the traditional firewall in place, the victim web server held up to ~500 SYNs/second. Any higher rate of SYN flood rendered the victim web server completely unable to answer requests. When protected by the NetScreen-100 the victim web server showed no noticeable change in ability to serve web pages at ~500 SYNs/second. We continued to turn up the SYN flood rate to determine when a web server protected by the NetScreen-100 would begin to be affected by the SYN flood. Our tests show that the victim web server begins to degrade when the attack goes above ~14000 SYNs/second. We concluded that proxying connection requests offers a significant improvement in protection against SYN flood attacks. We plan to test additional firewalls to determine if they are doing something interesting with SYN handling and if one approach is better than the rest. Check our website, www.iwi.com, for test result updates. References

[1] http://www.cert.org/tech_tips/denial_of_service.html