[NEWS] Hardware Defenses against SYN Flooding

From: support@securiteam.com
Date: 08/27/01 

From: support@securiteam.com
To: list@securiteam.com
Subject: [NEWS] Hardware Defenses against SYN Flooding
Message-Id: <20010827162457.49E53138BF@mail.der-keiler.de>
Date: Mon, 27 Aug 2001 18:24:57 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Hardware Defenses against SYN Flooding
------------------------------------------------------------------------

SUMMARY

SYN Flooding is the easiest and most common denial of service attack used
against internet-based servers. The attack utilizes a very common "flaw"
in the way hosts handle incomplete connections to cause the server to
overexert itself causing it to either crash or become unable unresponsive
to legitimate connections. The following is an analysis of existing
solutions to SYN Flooding and how each handled such an attack.

DETAILS

Establishing a TCP connection requires the exchange of three packets: the
first with a SYN (for SYNchronise) bit from the client, then SYN/ACK in
return from the Web server, and finally ACK (for ACKnowledge) back from
the client. The connection is then established; but if there is a delay in
completing the handshake, the server re-tries (sending SYN/ACK) several
times, and waits with the necessary resources to accept the connection
already allocated.

Re-try and timeout periods can add up to over three minutes per bogus
connection, so it is easy to see how even a modest flood of unanswerable
SYN packets can overwhelm a server in short order.

This makes a SYN flood perhaps the most efficient packet attack, devouring
the greatest amount service with the least effort. It fakes the initial
handshake of a TCP connection with spoofed IPs that the target machine is
unable to answer.

Because the handshake is a necessary part of normal Net traffic, malicious
SYN packets are difficult to filter. You can cope with an attack by
changing the number of times your machine will re-try the SYN/ACK
response, but you will also deny legitimate connections if you get too
aggressive.

With this difficulty in mind, <http://www.tech-mavens.com/> TechMavens'
Ross Oliver decided to benchmark several hardware solutions, all in
roughly the same price range, using a homebrew kit to simulate SYN floods
against them. He released his results at last week's USENIX Security
Symposium in Washington.

He established a baseline for his test server (Apache over Red Hat 7.1),
which, when unprotected, crashed at 100 SYNs/sec. The worst performers
were the <http://www.cisco.com/warp/public/cc/pd/fw/sqfw500> Cisco PIX
firewall and <http://www.checkpoint.com/products/firewall-1/index.html>
Checkpoint's Firewall-1 equipped with the SYNDefender module.

The Cisco kit showed no advantage whatsoever, failing at the baseline 100
SYNs/sec. Firewall-1 showed only marginally better results, breaking down
(i.e., refusing connections) at a lame 500 SYNs/sec, which can be exceeded
by only two or three boxes connected by T1, cable or DSL lines.

It is fair to note that while one expects at least some protection from
any firewall, the Cisco kit is not marketed for SYN flood protection as
the Checkpoint kit obviously is.

Netscreen's <http://www.netscreen.com/products/appliances.html#ns100>
Netscreen-100 fared better, breaking down after 14,000 SYNs/sec for a
28-fold performance improvement at roughly the same price.

Only the Top Layer <http://www.toplayer.com/products/hardware/index.html>
AppSafe switch exceeded the test's limits, showing no sign of stress while
sustaining 22,000 SYNs/sec, the maximum Oliver could throw at it with his
rig. This would work out to about one dollar per SYN during a severe
attack, which strikes us as rather economical protection.

The switch distinguishes 'normal', 'suspicious' and 'malicious' traffic
according to user-defined rules, and can be configured to lock out
troublesome IPs for anywhere from fifteen seconds to over a week.

ADDITIONAL INFORMATION

The information has been provided by
<mailto:thomas.greene@theregister.co.uk> Thomas C Greene in Washington of
The Register.

The Register's original article can be viewed by going to the following
link:
 <http://www.theregister.co.uk/content/5/21284.html>
http://www.theregister.co.uk/content/5/21284.html

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Quantcast