Redux: NIDS, fragrouter, and off-topic sanity [WAS: Snort exploit]

[Greg Shipley <gshipley () neohapsis com>]

I was browsing last week's BUGTRAQ posts and found the thread on Snort,
fragrouter, and the supposed perils of NIDS evasion interesting.  Not
because these were necessarily ground-breaking topics, but more because
I'm amazed that people consider NIDS evasion, well, news.  Marty's comment
about the media having a field day on Snort's supposedly new failure(s) is
interesting in itself, as it drives home a) the fact that members of the
media are obviously turning to BUGTRAQ for news, but more importantly, b)
that the maturity of BUGTRAQ as a watchdog org has really come a long way.
However, these facts are good for keeping the heat on vendors to fix
flawed products, but bad for misunderstanding known issues.  But I
digress....

A couple of comments about NIDS/evasion/normalization/other stuff that
some list members may, or may not, find useful:

- evasion vs. bugs: It shouldn't be news that many NIDS products can be
evaded in many ways.  Most of these "failures" are known design challenge
that NIDS vendors have faced for years.  However, I would be careful in
suggesting that they are bugs.  In many ways, posting to BUGTRAQ about
many of these NIDS evasion techniques would be synonymous to me posting a
discovery that I can tunnel non-compliant app traffic through my stateful
packet filtering firewall with ease.  Most veteran security practitioners
would probably respond with "No duh, Greg, use a proxy-based firewall if
you are concerned with this 'problem.'"  (read: known design issue)


- fragmentation and evasion: As many people pointed out, market leading
commercial firewalls such as Cisco's PIX and Checkpoint's Firewall-1 *DO
NOT* forward re-assembled packets that have been fragmented at Layer-3.
They may re-assemble them for internal inspection, but they spit them back
out onto the wire they way they received them.  And why do I mention
layer-3, you ask?  Because some higher-level protocols (RPC!) support
similar types of "fragmentation" - more things that can stymy that weary
NIDS.  Evasion techniques can executed at Layer-3 (IP fragmentation, for
example, that presents a challenge to the average NIDS as fragmented
packets can be re-assembled one of a gazillion ways) all the way up to
layer-7 (HTTP UNICODE, for example, which Mike Hall at Cisco was telling
me had TENS of THOUSANDS of combinations).  The point being that
possessing the layer-3 through layer-7 smarts to handle the bazillion ways
to evade inspection is an impressive challenge - AND ONE THAT THE FIREWALL
VENDORS FACE AS WELL.  Checkpoint FW-1 doesn't even perform TCP sequence
number inspection, but I'm not seeing BUGTRAQ posts on this topic...but I
digress again....

Getting back on the topic at hand, again, back to the firewall analogy: if
you have a firewall that understands layer-7 protocols (Gauntlet, Raptor,
Sidewinder, etc.) then there is some hope for application-level checking,
but if you're using a product that is closer to a stateful packet filter
(Netscreen, Checkpoint, Cisco, etc.) you're more limited in what you can
do, inspection-wise.  Again, these are design issues, IMHO, and many of
them are faced by the NIDS space as well...which leads me to:


- normalization options: Commercial firewalls that normalize traffic, even
at layer-7, are coming.  I know of one (OneSecure IDP), and I know others
are on their way.  If people are really concerned about stopping as many
types of NIDS evasion techniques as possible, then they may wish to
consider looking at in-line normalizers, or pressure their vendors at
adding this functionality.  As a side note, I found Handley, Kreibic, and
Paxson's USENIX paper on the subject quite interesting, as they identified
something like 70 points of "normalizations" for IP, TCP, UDP, and ICMP
alone.  (See Appendix A at:
http://www.aciri.org/vern/papers/norm-usenix-sec-01.pdf)


- Comparing the anti-virus (AV) world to NIDS: Perhaps a relevant
comparison on some levels, but let's not forget that NIDS products vary in
design and inspection capabilities.  There are NIDS products on the market
(ISS' BlackICE, Intrusion.com's SecureNetPro, etc.) that have the ability
to perform Layer-7 protocol analysis/decoding, and can, in turn, detect
some unknown attack types.  For example, I know BlackICE detected some of
last year's IIS overflows before it was specifically programmed to (read:
the alert wasn't sig based, it was protocol based).  There are limitations
to signature models, yes.  And updating your IDS, much like updating your
AV solution, is important.  But grouping every NIDS product into the same
category and simply stating that it's not as accurate as, say, an AV
solution, is, well, misleading, IMHO.


- IDS devices as an actual defense mechanism: I will humbly suggest that
most NIDS solutions, in their current form, are monitoring/policy
compliance devices, not access-control ones.  I continue to be amazed at
people comparing NIDS to access-control mechanisms like firewalls.  Apples
vs. oranges, IMHO, but a topic for another time (and perhaps, another
list).


- NIDS placement: Again, more holy war material - are we using NIDS
primarily for reporting/trending, or trying to catch the wily hacker?
IMHO, stating definitively where a NIDS should or should not go
inside/outside the firewall is silly without knowing what the deployer's
requirements/goals are.


- "problems with Snort" - Snort seems to be the NIDS whipping boy these
days, and while I'm sure Snort (as any product) will be plagued by
specific challenges only relevant to it, there's a good chance that things
that affect Snort, probably affect many other NIDS solutions as well.


In short, most (all?) of these issues have been debated, adnauseam, on the
Security-Focus IDS list.  In the future these conversations might be
better served in that forum, unless we want to go down the path of
flushing out known product design failures in BUGTRAQ.  I apologize if I
sound crabby, I just know that this list will most likely become MORE
crabby, if its members INBOXes are pounded every time someone figures out a
new spin to an already known design failure.  We should, IMHO, be careful
about classifying what is new, and what is simply a twist on an old friend
(or enemy)...

I'll shutup now.

For whatever it's worth,

-Greg