Re: Preventing layer 3/4 evasions

On Jan 7, 2008, at 8:36 AM, Martin Roesch wrote:

> 1) Inline normalization
>
> * Pros: Removes traffic anomalies so the codepaths for anti-evasion
> mechanisms are simpler. One scrubber allows all devices behind it
> to enjoy a normalized packet stream. Doesn't have to care about or
> track the network it's protecting so the normalization technology is
> simpler and, in theory, very robust.
>
> * Cons: Deploying an inline device has very different requirements
> for uptime, latency and performance across the device than the
> passive devices it's aiding. Some organizations react very
> negatively to introducing inline packet mangling devices. Packet
> scrubbers can also interfere with some useful functions like passive
> OS fingerprinting. Provides no coverage for evasive attackers
> behind the device.

Although I 100% agree with this as a 'con.' it is more of a downside
of IPS in general and much less so for the concept of "fixing" the
stream. If, however, you do want to buy and use an IPS instead of an
IDS then this is, in my opinion, the best choice for anti-evasion. The
upside being you know that an otherwise detectable attack using an
evasion technique won't slip by your IPS. The downside is that you
could be attacked and not know it. If you do get any alert at all it
will be some sort of traffic or stream reassembly anomaly not the
higher level attack. For the majority of IPS users this is just fine
because the are buying IPS to stop attacks first and detect them second.

The other two techniques are best applied to IDS situations where IPS
is undesirable.
>
>
> 2) Network profiling and context-based analysis
>
> * Pros: Doesn't require an inline device and concomitant political/
> technical signoff. Able to profile all devices continuously
> (assuming optimal deployment) and dynamically update IDS/IPS.
> Gathered information has uses beyond just straight anti-evasion.
>
> *Cons: Getting full coverage of the network can be challenging. Bad
> profiles skew the anti-evasion models. Data management and
> communication can be a challenge. Network traffic analyzers have to
> be modified to work with the data produced by the context generator.
>
> 3) Bifurcation.
>
> Well, suffice to say I just think bifurcation is a bad idea.

I disagree. Bifurcation is a great idea with many many many terrible
implementations. However, bifurcation is the only provably correct
method to detect evasions in all cases. Whether the target system
profile is statically configured or dynamically derived there is
always a chance it is wrong (much higher chance it is wrong when it is
static, of course). When it is wrong evasion can be successful.
Bifurcation does not assume a target and tries all possible methods of
reassembly. There is a chance of false positive when one possible
reassembly contains an attack match but the target will not reassemble
it that way.
The downsides kill it, of course, the amount of code to implement
bifurcated analysis is horrific. The expected performance penalty for
the overhead of multiple processing paths is also painful to
contemplate.

I'm not convinced that a good bifurcating analysis system is
impossible but I have yet to see one. System profiling is the best
fallback for IDS as long as it is right about the target more often
than a static configuration and cannot be manipulated by the attacker.

>
>
>> - Do you all feel that existing approaches (like Snort's, or
>> perhaps some commercial implementation of #1) are adequate, or is
>> there a need for a more robust solution?
>
> I think that the methods we've deployed in Snort and the ones we're
> working on for the next generation of Snort engine are certainly
> adequate. It seems to me that evasion is moving much more heavily
> to layer 7 anyway so perhaps it's a moot point.

The point may be moot for IPv4. I think there are a whole lot of fun
layer 3/4 techniques available in the grey areas between IPv4 and IPv6
and in layer 3/4 techniques specifically targeted at popular IDS/IPS
systems.

-J