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
This archive was generated by hypermail 2b30 : Mon Apr 22 2002 - 12:50:33 PDT