|
apropos
by Tina Darmohray Tina Darmohray, co-editor of ;login:, is a consultant on Internet firewalls and network connections and fre-quently gives tutorials on those subjects. She was a founding member of SAGE.
and Ross Oliver
"Hot Spares" For DoS Attacks 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 has resulted in a "win-win" scenario for the attackers: they benefit from access to more horsepower than they own directly, and they cover their tracks more thoroughly, since a trace back to the attacking machines simply leads to the other set of victims, the commandeered machines. With this kind of leg-up to contend with, what kind of countermeasure can organizations use to defend against this type of attack?
As with 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
(< 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 is 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-20based attack machine, an NT client machine to fetch Web pages, a Linux 2.2.12-20based 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 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.
We created a script on the client system to 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
[The SYN flood attack was launched here.]
Fetching 21 HTML pages, total 35K of data...
[The SYN flood attack ended here.]
Fetching 21 HTML pages, total 35K of data...
Output from the attack machine showing SYN flood rate (each "%" represents ~500 SYNs and is displayed in realtime on the attack machine):
% flood firewall
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
Output from the attack machine showing SYN flood rate:
% flood netscreen
Rate: 13869 SYN/sec
Rate: 13927 SYN/sec
... With the traditional firewall in place, the victim Web server held up to about 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 ~14,000 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 <http://www.iwi.com> for test result updates.
Recall that SYN flood attacks succeed by exploiting the TCP three-way handshake. To establish a TCP connection, two machines negotiate a triple exchange consisting of
|
 Need help? Use our Contacts page.
First posted: 22 Nov. 2000 ah Last changed: 22 Nov. 2000 ah |
|
Issue index