Re: IDS: Snort detecting distributed syn floods

[nick black <dank () reflexsecurity com>]

On 2005-01-13, THolman () toplayer com <THolman () toplayer com> wrote:
> Detecting a SYN Flood is all very well, but what are you going to do once
> you find out you're under attack ?

Agreed. To elaborate for the original poster, discrete resource-based
attacks such as SYN floods are one of the prime examples of where IPS
can excel, especially compared to IDS. I hope the following description
of our product's upcoming release's capabilities is illustrative rather
than overly product-centric; there's no panacea, but an intelligent
blend of heuristics, deterministic techniques and stochastic queueing
can, I assure you, alleviate the pain of all but the most overwhelming
floods.

First, the positioning of an IPS product such as ours allows SNT, or
"sequence number translation" akin to NAT. I believe this was first
pioneered by Toplayer's AppSafe, but is also present in OpenBSD and
NetScreen products (this is no authoritative list, just trying to give
credit where credit's due). Essentially, a network device can devote
many more resources to half-open connections, and analysis of them, so
move said connections there:

        - IPS intercepts the initial SYN, sends a SYN-ACK (with the
           benefit of both more allocatable resources, greater
           knowledge of the threat domain and presumably more history)
        - If the SYN's are being spoofed or otherwise unanswered (simple
           DDoS zombie clients, lack of egress policing leaving zombie
           uplinks supersaturated, etc), the half-open is eventually
           timed out or pressured out by LRU, etc. As the number of
           these closings increases, the IPS can make the decision to
           identify and filter worthless half-opens more rigorously
        - Should the three-way handshake complete, the IPS SNAT's a
           connection to the original dest, claiming to be the source.
           The server will respond; should it not, the IPS can attempt
           to determine why, perhaps lowering RED/etc thresholds if the
           server appears already overwhelmed. If the server does indeed
           respond with a SYN-ACK, the IPS need merely apply a constant
           delta to SN's in both directions.

Furthermore, techniques such as non-parametric CUSUM (a stateless
feedback algorithm, see Wang/Zhang/Shin) or spectral analysis
(Cheng/Kung/Tan) can be applied by a special-purpose IPS. Such
methodologies implemented on end hosts seems prohibitively expensive,
not to mention suboptimal from an information-aggregation standpoint.

As the number of SYNs goes up, my experience has been that the useful
SYNs -- those which will complete the handshake and make proper use of
the proffered service -- will appear more and more statistically
anomalous when compared against the onslaught. If this thesis proves
correct, scaling back analysis in proportion to the load should pay off.
Very few SYN flooding tools generate retransmits with a friendly 
exponential backoff, for instance. By dropping the majority of SYNs
early, perhaps even erroneously, we keep our cycles free to determine
what properties lie outside the norm.
           
-- 
nick black                  "np:  the class of dashed hopes and idle dreams."


--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from 
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
--------------------------------------------------------------------------