Snort's weaknesses

I'm trying to find information on what Snort's weaknesses are.  If you could provide some information, that would be greatly appreciated.

I'm trying to analyze Snort and see if it's suitable tool.
LVL 4
newbiealAsked:
Who is Participating?
 
Rich RumbleConnect With a Mentor Security SamuraiCommented:
There are IDS evasion techniques, such as fragmenting/splitting packets, but snort is not that susceptible to them, well anymore. Please have a look at Frag3 and the Stream preprocessor doc's:
http://www.snort.org/docs/snort_htmanuals/htmanual_261/node33.html
Again fragmentation(evasion) is not limited to snort, and don't forget too that Snort has a commercial offering that uses specialized hardware I(ntel IXP2400) where the NIC's have cache and specialized processing so that links up to 10Gps can be processed.
I use snort at the 1Gps speed, standard dell quad-core p4 2.33 4gig ram and the integrated NIC's. There are some dropped packets, but not much, and I do use 90% of the processor during peak hours.
You would also be surprised how many IDS vendors repackage (and or fork) snort and pass it off as their own.http://www.sourcefire.com/products/snort
The main failing of the Free version of Snort is no real-time service or support. However there are quite a few mailing lists that you can sign up on and receive genuine help and answers to your questions in a reasonable amount of time. There are bugs and problems with snort, like a recent one relating to Frag3 (preprocessor) and by-passing detection by spoofing the TTL I believe, but it was quickly fixed. http://secunia.com/advisories/product/16919/?task=advisories_2008
-rich
0
 
Dave HoweConnect With a Mentor Software and Hardware EngineerCommented:
snort is the definitive open source tool of its class, and a basis for many other open source products.

Its main weakness (particularly in snort-inline mode) is that it is usually packet based - so a pattern that should be matched, but which is split across two packets in a tcp stream can be missed.

it is also pretty slow - which (again) if you are running in inline mode, can lead to considerable latency before packets are forwarded. There are faster scanners, but on the whole this is a common weakness in IDP systems.
0
 
newbiealAuthor Commented:
Is there a remedy to resolve the slowness issue?  Maybe by adding more sensors?
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
Dave HoweConnect With a Mentor Software and Hardware EngineerCommented:
adding a faster machine, usually.  with IDP, usually the snort acts as a gatekeeper, inspecting each packet before it is forwarded. for sniffing nodes, speed is not so much an issue unless it isn't keeping up (in which case it will usually start missing packets - not good, but not noticeable as it has no effect on traffic)
0
 
newbiealAuthor Commented:
What other solutions are there to minimize packet loss?  Or is this just unavoidable and indicative of all IDS tools, not just Snort?
0
 
Dave HoweConnect With a Mentor Software and Hardware EngineerCommented:
it varies, depending on tool. Note that packet loss in an sniffing (IDS) system is not cause for interruption of service, but instead for risking missing a packet that should trigger an alarm. in a active packet filter (IDP) then it is rare that the packet speed causes loss, but instead will induce extra delay in the link due to the allow/deny decision on the packet being required before it is released (or discarded).

Snort is not the worst offender there, but it is certainly the case that there are faster (commercial) systems for IDS and IDP. size and ordering of the ruleset is more of an issue - if the most common path though the ruleset requires you to process almost the entire ruleset, and the ruleset is long, then no solution is going to be running at line speed. if however, many of the packets are decided upon within the first couple of rules, even a comparatively low speed machine could handle gigE traffic at line speed.

Given snort is free, the best path is really to build a test system on available hardware, and use that to estimate the thoughput the system can handle - tuning snort config, particularly for multithread/multicore, tends to be more of an art than a science though.
0
 
newbiealAuthor Commented:
You stated: so a pattern that should be matched, but which is split across two packets in a tcp stream can be missed.

So if Snort is installed inline, shouldn't it analysis packets that have already been reassembled, meaning there shouldn't be an issue with split data packets?  Or am I misunderstanding?
0
 
Dave HoweConnect With a Mentor Software and Hardware EngineerCommented:
you are misunderstanding. this isn't a case of a single packet being broken (fragmented is the term of art used) but the fact that all packets in a tcp stream represent a single "conversation" which is broken up into packet-sized chunks.

it is possible (and there are tools to deliberately do this) that a single request to a webserver (say) is split so that half of the request is in one packet, and half in another - so a packet designed to match on "cmd.exe" say, will match:

GET /windows/cmd.exe http 1.1

but NOT match

GET /windows/c
md.exe http 1.1

even though the web server will "see" the two packets as one "stream" and thus a single line.
0
 
newbiealAuthor Commented:
Good information - thanks!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.