Snort up For Revamp, says Creator
A reader writes:"The creator of Snort, the open-source network-based Intrusion Detection System (IDS), says the software is up for an overhaul. Martin Roesch has told the AusCERT conference IDS has failed to impress the market, citing the inability of many to minimise the number of false alarms triggered by the monitoring devices. The next iteration will include "passive discovery" features."
not meant as a joke but i think it could also have to do with the psychological fact that Snort just sounds like something you want to distance yourself from. I wouldn't associate myself with a program called mucus-mouth no matter how good it was.
A GOOD firewall will be doing more then just blocking ports. It will analyze packets to determine the type of comunication being used. Which is not to say such things can't be circumvented, but it is much harder then just using a proxy.
The problem, and what this article is in many ways about, is dealing with false positives when checking for spacific types of network traffic.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
umm no, not completely, in order to attack your network the data has to become unencrypted at some point in time. When it does it becomes traceable and you'd then be able to analyze it. It may be a bit harder and require an IDS box on the inside of the network, too.
-- Tim
TKrabec Pahh
"...If the new software detects an Apache server running on Linux, it will only look for attacks relevant to that configuration, instead of monitoring the device for an attack that would affect a Cisco router or Windows server..."
This have 2 serious drawbacks:
1. If someone is trying to brute-force attack your servers sending probes for every known exploit (aka. nessus), disabling alarms for software/services you don't run will not show the real size of the attack.
2. In case of an infection similar to code red you won't be able to know wich infected servers are "attacking" you, so there is no way to block them in the router, firewall or reporting the virus-generated traffic to their ISP.
Of course, that only works if the attacker has the firewall password/snmp info anyway. And if the attacker has the password in the first place, he won't need snort anyway.
"But what if he _installs_ a firewal?" If he has access to the cabling, all he has to do is cut it. Perfect internal DoS.
Besides, if you really want to do that, go grab a copy of FIRE (no, I won't find the URL for you). Give ettercap a go. A couple of ARP packets, and you can take any windows machine off the local network (provided they aren't more than one router away).
Most IDS vendors focus on ever more accurate alerts, but once they trigger they wash their hands of the problem. The end user must decide if the alert is truly significant to their situation and priorities. It's like having an anti-virus product cry wolf but never give any reasons for its identification of malware or background on its findings.
An alternative to the "alert-centric" point of view is "Network Security Monitoring," which concentrates on giving analysts information to conduct at least rudimentary network-based investigation. Where most IDS care only about alerts, NSM-centric operations combine alert, session, full-content, and statistical data to give analysts a chance to identify and escalate incidents.
A tool which uses Snort to generate alert data, combined with session and full content data from other sources, is Sguil.
The April 2004 Sys Admin magazine features Sguil and a few other NSM tools.
A book due in July, The Tao of Network Security Monitoring (also at Amazon.com) is all about NSM.
Anything vendors can do, like Sourcefire's work with Snort, helps with more accurate identification. Just remember creating alerts is only the first step.
All of the IPS fans out there should remember that their "prevention" depends on correctly identifying intrusions. All IDS and IPS products can be bypassed, which drives the need for audit-centric tools (especially using session data) which are content neutral and don't care about triggers, encryption, and so on.
Helevius
Could this revamp be due to pressure from companies which have built commercial offerings on Snort? Guardent's SDA tool is basically a Snort box, x86 linux on commodity hardware. How many other money-making ventures out there depend on Snort, and what influence do they have over the Marty?
I want to delete my account but Slashdot doesn't allow it.
If you are interested, read more about how Swatch and syslog are used in a large production environment.
Hulk SMASH Celiac Disease
We ended up putting together a little access db that we could generate rules for snort based on critieria like port, os, etc. Eventually we turned this into the first Snort rules site snort.rapidnet.com which is now down. I would imagine that any problems someone might have with Snort (or other IDS) is the correct config for a given scenario or situation.
You have to give props to guys like Marty who make a really great, free product that the little guys can use to conduct homegrown (not homeland) security.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
The real problem with Snort, and this is coming from someone that has administrated Snort systems in two major companies, is management's lack of understanding that it takes labor to maintain these systems. They want something that they can just pay for up front and will work with no additional tuning or labor costs.
This is the true failing of Snort and other IDS systems as well. They require labor to tune the ruleset and configuration to a network. They require constant updates and someone that can create signatures on the fly. They require someone that has a knowledge of TCP/IP protocols, routing, networking and the ability to analyze data and follow leads.
Working with Snort is kind of like being a detective. The alerts are clues and you have to dig through a lot of other logs, traceroutes, whois, calling people on the phone and find out what they are doing, etc. It's all labor intensive and no one in management wants to dedicate the resources necessary to make it really work.
I could spend all day working on Snort, but I have to monitor firewalls, email, viruses, go to meetings, train people and type on slashdot once in a while. And IPS is no different, it is not something you can just put in and leave forever and feel safe.
Management needs to realize they need people on site to deal with the New World Order of constant hacking attempts. IDS admins are jobs needing to be filled, that's why Snort is not living up to the "promise". Management somehow twisted the promise of Intrusion Detection into some automaticlly, always upgraded intrusion prevention system that requires no labor, no upkeep and you never have to spend any more on it. They continue to live in a fantasy world and one day will end up hacked even though they got a raise for cutting their security budgets by 25% for the year.
A cut -n- paste job from a previous post. Sorry, but I am too lazy to rewrite the thing.
My personal opinion is IPS's have been mislabeled since the beginning (aren't marketers wonderful). Take this definition I found in some Usenet archives (circa 1992):
"a combination of a security policy with some of the components
above. Specifically, an implementation of the given policy that
is enforced by a combination of screening and/or routing." [1]
Geeze, seems like IPS would fit right in there. Now the final jeopardy question, what was that a definition of? If you guessed "firewall" then you get the big prize. So that's it, you heard it here folks, an IPS isn't the evolution of a IDS, but instead part of the evolution of a firewall. If you look at the history of firewalls, you'll see that early on there were huge flame wars over Packet Filtering and Application Firewalls. In the end, the packet filtering FW won out. Seems to me packet filtering FWs used less resources and could handle faster networks and as those speeds approached full duplex 100mb links, application FWs got left in the dust.
Fast forward to 2003 and the designers of IDS software have made huge progress in detecting potential attacks, system's CPU/RAM/etc have increased phenomally, and the 'normal' speed of network have sorta leveled out. So, application FWs are back in the picture. Vendors with short term memory loss label this 'new' product an Intrusion Prevention System and advertise it as the replacement for your IDS. Those vendors give it a new label for good reason. There is no way they want to bang heads with the big FW companies and more importantly, their implementations of IDS have been huge failures within their customers networks and they need something to market as 'new and improved' (again).
I say (most) vendors of IDS and 'IPS' products failed because they sold the product as an INTRUSION Detection System when they really had an ATTACK detection system. An INTRUSION Detection System implies the IDS can detect an event and determine its nature (malicious vs non-malicious). If the attack was malicious, an IDS will help you determine if it successful. If the attack was successful, the analyst should be able to use the data collected by the IDS to determine the impact on the system in question and finally what steps are needed for remediation. The 'IDS' vendors instead force fed us near worthless systems that can display an 'event'. Many won't give us any details on how they determined it was an 'event' and most can't give us any supporting data about 'attack' beyond a src/dest IP addr and port. If we are lucky, we get a whole packet too. No analysis can be done with the console, instead one must go to the targeted machine and pull out his/her host forensics kit or pay a 'Security Consulting' firm $600/hour to recommend you wipe and rebuild the system.
Soon customers begin to ask "what do I do with this event" and later "I spent XXX hours tracking this down only to find the attack didn't happen or wasn't successful". The vendor noticing the agnst in his customer's voice replies with "we are working on ways to reduce 'false-positives' and in the future we will use IPS technology to prevent attacks too." and thus the birth of "IDS is Dead". I expect FW vendors to incorporate more and more attack detection features from IDSes (duh) and have true hybrid Packet Filtering/Application FWs, but the fact is we will still need IDS. IDS done the right way of course (we call it Network Security Monitoring), but that is a whole other rant.
Bammkkkk
www.sguil.net
The Analyst Console for NSM
whinge, whinge,
* too many false positives, then tune your sensors - but then again _YOU_ will have to know and understand your network and its traffic.
* requires too much time/labor/knowledge to use/setup/maintain - since when did the security industry stay static, or more likely since when did the otherside put their feet up and say, "enough is enough", we have created enough virii/worms/ddos apps/exploits...
LOL, 'greyfeld' had it right in the last paragraph. Spend some money on Security you tight-fisted sods and stop bleating about how it hurts your budget so much - or your job will be on the line not mine; when the site is hacked and the customer databases are ripped, sales figures erased, and the backups failed (as they always do).
I use (daily) a few of the top commercial IDS/IPS apps depending on the customer, and snort is still a favorite for what it is.
So to get a feel on how ppl are comparing this to other IDS/IPS apps, a few questions;
Q1. So how much money was invested in the latest McAfee IPS, and how much was that compared to the latest version of Snort?
Q2. How many IDS/IPS style companies did snort.org take over in the last few months compared to Cisco.com?
Moh.