That's not true, Snort development continues in the open and contributions are still taken from the community. We don't use the community to market our commercial solutions at all, in fact we have strict prohibitions against marketing commercial solutions on the Snort mailing lists.
Stiennon takes the next wrong step by saying that we're preventing the ENTIRE OPEN SOURCE COMMUNITY from developing threat mitigation technology. Completely wrong. You can still add your own patches to Snort either as a contribution to the project or as an external patch, Sourcefire does nothing to prevent that.
We also don't require that you install anything other than Snort when you grab it from snort.org, getting and installing Snort today is just like it was before Sourcefire started. If you don't have the problems that Sourcefire solves (scalability and manageability for the mid to large enterprise) you'd probably barely notice we're out there.
Snort is developed at Sourcefire these days, the company I started and where I still serve as CTO. I am the lead developer on the Snort 3.0 project right now which is undergoing restructuring after the initial few releases showed performance issues that we weren't ready to live with.
Snort 2.x is developed by Sourcefire's engineering team, we release several updates a year to the code and updates to detection almost weekly via the Sourcefire VRT. I don't work on the 2.x code base day to day anymore but I do contribute from time to time. Snort 2.9.0 is slated for release this fall and continues 12 years of development on the engine technology which includes some significant innovation in the field of intrusion detection.
My issue with Suricata is that it has implemented the exact same *detection model* as Snort, it does nothing new from a detection standpoint but wraps it in a multithreaded framework that they're trying to call innovation all on its own. True innovation would be to develop a new way of detecting threats on the wire and they haven't done that, they effectively have implemented the same idea as Snort (processes Snort rules, buffers streams into chunks before processing, etc) on a slower software platform. They implemented what is effectively a Snort fork and did so at taxpayer expense, they got the government to pay them to develop something that the government already gets for free (Snort's detection model) with less features and lower performance.
Someday Suricata might be a really interesting engine but to go out to the press in a concerted push and advance the idea that "Snort is dead" reflects a stunning amount of hubris and wishful thinking. Snort is the most widely deployed IDS/IPS on the planet, there have been millions of downloads and there are hundreds of thousands of registered users and the community is still growing steadily. Snort's engine development is still moving forward and we have plans to continue to innovate in the field of intrusion detection. If the Suricata team wants to displace it they have a tremendous amount of work to do, they're not even close yet.
ACID is no longer being actively maintained, if you want ACID's functionality you should go get BASE! Better yet, go get SGUIL and use Snort as part of a Network Security Monitoring, you'll be glad you did.
Snort supports in-line (intrusion prevention) operation on Linux as of version 2.3.0. There is also the snort-inline project which maintains a different code branch that includes support for divert sockets on FreeBSD as well as some in-line focused mods.
Sourcefire (my company) builds commercial-grade IPS using Snort as the foundation technology and it works well. We're continuing to improve the technology on an ongoing basis as it's central to our IPS offerings. If you want to run an IPS to try out the technology, Snort is certainly suitable today.
As I type this I'm sitting at gate C27 at DFW. All the outlets that I've spotted in my seating area are turned off, so I can't charge my laptop batteries or my ipod or my cell phone. Now, luckily I charged everything up at the hotel last night, but I've got my PowerBook screen dialed down to 4 pips to conserve battery power for my next (3 hour) leg and I'm not using my iPod as I sit here waiting on my 1.5 hour layover.
What kind of braindead beancounter decided that this was a good idea? My "quality of life" in this terminal is being lowered because (as jlehtira pointed out above) they didn't want to pony up the $0.01 to let me avoid fun things like having to stare at my screen accreting photons and compulsively watching my battery meter slowly trickle down.
Thank you DFW, thank you American Airlines, thank you for making my travel experience that much worse (let's not talk about the connection I missed last night because AA had us sitting on the tarmac for 45 minutes after landing waiting for a f'in gate!) because you wanted to save a penny. Of course, due to the high quality experience that I've had here I'll be flying United next time and buying that magazine, lunch and delicious java chip frappuccino in their Chicago, Denver or SFO hubs where you can plug into any goddamn wall outlet in the airport and it works.
Hey, let's do some fun math. DFW handles about 5M passengers per month. Let's say 10% of them plug in to "leech" power and each one stays plugged in for an hour at.6 cents per hour per passenger. That's a whopping $36,000 per year lost to leeches!!!!! How will they possibly absorb that kind of cost with naught but $4 bottles of water and $7 ham sandwiches to serve as a basis for revenue in the terminals?
Hey DFW, stick a fricken crowbar in your wallet and pony up, 100k+ mile fliers like myself are paying attention.
Once again, with feeling:
IDS is a network monitoring technology
IPS is anaccess control technology
We use IDS to let us know what's happening on our networks, how our policy is being enforced by our access control mechanisms and when there are security failures.
We use IPS to "shoot down" attacks that are in flight before they can complete and affect the target.
Confusing the two is the name of the game for IPS vendors because the FW vendors have deep pockets and the IPS guys didn't want to rock the boat at first. In-line network IPS is only useful as long as you have time to provision new detection signatures before attacks/worms come out, they are deterministic and therefore have a very tough time dealing with the unknown (and yes, I know they have the ability to do rate-based blocking in some cases, that's deterministic too). The natural progression for IPS technology is as a feature on a firewall, not as a stand alone independent product, it's just an enhancement to access control technology after all. The natural progression of IDS will remain as a stand alone product or perhaps it will disappear into the infrastructure of the network itself (e.g. switches), but it is going to be a necessity as long as people need to have visibility into what's happening outside the purview of their access control technologies. In-line network IPS only watches/defends your peering points, NIDS monitors everything if deployed properly.
To claim that IDS is "dead" is to basically say that people should put on blinders and only watch the peering points, not a very realistic proposition in my opinion. IPS is not a replacement for IDS, those who say so either don't understand the role of IDS or they're selling something.
The article missed a few key points so I'll try to set the record straight here.
First off, my presentation was about making the case for Passive Network Discovery Systems (PNDS), a "new" technology that I created over at Sourcefire. The basic idea of a PNDS is to discover the composition and topology of your network via a mix of passive OS fingerprinting and passive application layer protocol discovery and the other information that you can infer from that data, such as network topology and asset vulnerabilities. I sought to show how that technology could improve a variety of network security technologies by using the example of how Snort (and other IDS) works today and how it could be improved by integrating the information that comes from a PNDS.
Sourcefire has developed a product called RNA that performs the PNDS functions that I outlined during my talk. Note that it is a proprietary technology that we developed commercially and it is a completely separate product from Snort or the Sourcefire IDS sensors. We are not going to be integrating the functionality of RNA into Snort, we're going to be modifying Snort to take advantage of the information that a system like RNA can generate. In the best case scenario, RNA has a very different deployment profile than an IDS.
I said that IDS has had trouble in the market because of its complexity and the requirement that users perform extensive tuning of IDSes in general in order to get maximum benefit from them. There are a lot of things that factor into this problem, but the root cause of almost all IDS problems today is that we don't have automated methods for provisioning them nor do we have effective methods of data reduction available that are automated, persistent and real-time. PNDS addresses that problem head on in a way that is appropriate for real-time processes like IDS in ways that traditional scanning technologies have a very tough time providing.
I then went on to say that we're planning on making changes to Snort to enable it to leverage the information that a system like RNA provides and make it into a true target-based IDS, redefining how IDS operates and hopefully revitalizing it as a technology. Snort will still be available for free and will still operate in "classic" mode where it doesn't leverage this info for people who don't have passive discovery technologies (or even active ones) so that they can still continue to use it.
Snort is not going to be doing the configuration policy enforcement (i.e. the "block OS X on my network" function), RNA is. RNA is capable of seeing devices on the network and discovering their attributes in real-time and communicating that data to our management console where it can be analyzed for policy compliance and where appropriate remediation responses can be executed. Not to get too deep into the marketing, but there are good engineering reasons for wanting to do this that include worm/virus containment, real-time IDS policy updates and some other really useful mechanisms for performing policy enforcement.
We're making mods to Snort because we believe that we can make a truly next-generation IDS capability that is easier to deploy, manage and get valuable information out of due to the effect of RNA. This approach directly addresses all the arguments of the "IDS is dead" crowd while at the same time making IDS a much more impactful technology while greatly reducing the overhead requirements on users.
I've got a few comments, and seeing as I'm Snort's author I thought people would care for once.:)
First off, I'm not just Snort's author, I'm also the founder of Sourcefire. Sourcefire was started once it became apparent that enough commercial/governmental users wanted commercial support to make it a viable business model. Raising the VC was not easy, try going into a venture capatalist's office sometime and telling them about how you want to build a product company around a core technology that's free. I talked to something like 12 different investment firms before we got the time of day from anyone, VC wasn't really looking for the next big Open Source story in 2001, they were trying to figure out what the hell happened to all their investments.
Sourcefire eventually got funded, but we did it the old fashion way by building the product on a shoestring and then selling it into big accounts. Once we made a few hundred kilobucks from my living room (i.e. the original Sourcefire corporate campus), we finally got some attention and (eventually) money. Let me reiterate, it was not easy.
The author of the article could have saved some money on books (and so can you) if you simply read the USAGE file and the SnortUserManual.pdf file that should be incuded with your Snort download. Both of those files have quickstart information that will let you get up and running with Snort in about 15-30 minutes. Snort was designed to be easy for people who are used to using Linux, keep that in mind when using it for the first time. If you're getting lots of little log files, try using the -b switch at the command line, it'll log to a single file in pcap binary format (like ethereal/tcpdump). Additionally, read the FAQ and check out the mailing lists, they're invaluable.
Finally, the security vulnerabilities that were located in Snort this past spring led us to perform an internal and two external independent paid security audits of the Snort code base, funded by Sourcefire. We're also excersizing additional diligence when evaluating contributed code and looking at the code we're developing internally at Sourcefire. It should be noted, all the code that is developed for Snort at Sourcefire is released under the GPL, we're dedicated to always keeping Snort free and making it the best IDS we can.
Slashdot Mirror
That's not true, Snort development continues in the open and contributions are still taken from the community. We don't use the community to market our commercial solutions at all, in fact we have strict prohibitions against marketing commercial solutions on the Snort mailing lists.
Stiennon takes the next wrong step by saying that we're preventing the ENTIRE OPEN SOURCE COMMUNITY from developing threat mitigation technology. Completely wrong. You can still add your own patches to Snort either as a contribution to the project or as an external patch, Sourcefire does nothing to prevent that.
We also don't require that you install anything other than Snort when you grab it from snort.org, getting and installing Snort today is just like it was before Sourcefire started. If you don't have the problems that Sourcefire solves (scalability and manageability for the mid to large enterprise) you'd probably barely notice we're out there.
I should know, I wrote it.
Snort is developed at Sourcefire these days, the company I started and where I still serve as CTO. I am the lead developer on the Snort 3.0 project right now which is undergoing restructuring after the initial few releases showed performance issues that we weren't ready to live with.
Snort 2.x is developed by Sourcefire's engineering team, we release several updates a year to the code and updates to detection almost weekly via the Sourcefire VRT. I don't work on the 2.x code base day to day anymore but I do contribute from time to time. Snort 2.9.0 is slated for release this fall and continues 12 years of development on the engine technology which includes some significant innovation in the field of intrusion detection.
My issue with Suricata is that it has implemented the exact same *detection model* as Snort, it does nothing new from a detection standpoint but wraps it in a multithreaded framework that they're trying to call innovation all on its own. True innovation would be to develop a new way of detecting threats on the wire and they haven't done that, they effectively have implemented the same idea as Snort (processes Snort rules, buffers streams into chunks before processing, etc) on a slower software platform. They implemented what is effectively a Snort fork and did so at taxpayer expense, they got the government to pay them to develop something that the government already gets for free (Snort's detection model) with less features and lower performance.
Someday Suricata might be a really interesting engine but to go out to the press in a concerted push and advance the idea that "Snort is dead" reflects a stunning amount of hubris and wishful thinking. Snort is the most widely deployed IDS/IPS on the planet, there have been millions of downloads and there are hundreds of thousands of registered users and the community is still growing steadily. Snort's engine development is still moving forward and we have plans to continue to innovate in the field of intrusion detection. If the Suricata team wants to displace it they have a tremendous amount of work to do, they're not even close yet.
ACID is no longer being actively maintained, if you want ACID's functionality you should go get BASE! Better yet, go get SGUIL and use Snort as part of a Network Security Monitoring, you'll be glad you did.
Snort supports in-line (intrusion prevention) operation on Linux as of version 2.3.0. There is also the snort-inline project which maintains a different code branch that includes support for divert sockets on FreeBSD as well as some in-line focused mods.
Sourcefire (my company) builds commercial-grade IPS using Snort as the foundation technology and it works well. We're continuing to improve the technology on an ongoing basis as it's central to our IPS offerings. If you want to run an IPS to try out the technology, Snort is certainly suitable today.
What kind of braindead beancounter decided that this was a good idea? My "quality of life" in this terminal is being lowered because (as jlehtira pointed out above) they didn't want to pony up the $0.01 to let me avoid fun things like having to stare at my screen accreting photons and compulsively watching my battery meter slowly trickle down.
Thank you DFW, thank you American Airlines, thank you for making my travel experience that much worse (let's not talk about the connection I missed last night because AA had us sitting on the tarmac for 45 minutes after landing waiting for a f'in gate!) because you wanted to save a penny. Of course, due to the high quality experience that I've had here I'll be flying United next time and buying that magazine, lunch and delicious java chip frappuccino in their Chicago, Denver or SFO hubs where you can plug into any goddamn wall outlet in the airport and it works.
Hey, let's do some fun math. DFW handles about 5M passengers per month. Let's say 10% of them plug in to "leech" power and each one stays plugged in for an hour at .6 cents per hour per passenger. That's a whopping $36,000 per year lost to leeches!!!!! How will they possibly absorb that kind of cost with naught but $4 bottles of water and $7 ham sandwiches to serve as a basis for revenue in the terminals?
Hey DFW, stick a fricken crowbar in your wallet and pony up, 100k+ mile fliers like myself are paying attention.
Once again, with feeling:
IDS is a network monitoring technology
IPS is anaccess control technology
We use IDS to let us know what's happening on our networks, how our policy is being enforced by our access control mechanisms and when there are security failures.
We use IPS to "shoot down" attacks that are in flight before they can complete and affect the target.
Confusing the two is the name of the game for IPS vendors because the FW vendors have deep pockets and the IPS guys didn't want to rock the boat at first. In-line network IPS is only useful as long as you have time to provision new detection signatures before attacks/worms come out, they are deterministic and therefore have a very tough time dealing with the unknown (and yes, I know they have the ability to do rate-based blocking in some cases, that's deterministic too). The natural progression for IPS technology is as a feature on a firewall, not as a stand alone independent product, it's just an enhancement to access control technology after all. The natural progression of IDS will remain as a stand alone product or perhaps it will disappear into the infrastructure of the network itself (e.g. switches), but it is going to be a necessity as long as people need to have visibility into what's happening outside the purview of their access control technologies. In-line network IPS only watches/defends your peering points, NIDS monitors everything if deployed properly.
To claim that IDS is "dead" is to basically say that people should put on blinders and only watch the peering points, not a very realistic proposition in my opinion. IPS is not a replacement for IDS, those who say so either don't understand the role of IDS or they're selling something.
First off, my presentation was about making the case for Passive Network Discovery Systems (PNDS), a "new" technology that I created over at Sourcefire. The basic idea of a PNDS is to discover the composition and topology of your network via a mix of passive OS fingerprinting and passive application layer protocol discovery and the other information that you can infer from that data, such as network topology and asset vulnerabilities. I sought to show how that technology could improve a variety of network security technologies by using the example of how Snort (and other IDS) works today and how it could be improved by integrating the information that comes from a PNDS.
Sourcefire has developed a product called RNA that performs the PNDS functions that I outlined during my talk. Note that it is a proprietary technology that we developed commercially and it is a completely separate product from Snort or the Sourcefire IDS sensors. We are not going to be integrating the functionality of RNA into Snort, we're going to be modifying Snort to take advantage of the information that a system like RNA can generate. In the best case scenario, RNA has a very different deployment profile than an IDS.
I said that IDS has had trouble in the market because of its complexity and the requirement that users perform extensive tuning of IDSes in general in order to get maximum benefit from them. There are a lot of things that factor into this problem, but the root cause of almost all IDS problems today is that we don't have automated methods for provisioning them nor do we have effective methods of data reduction available that are automated, persistent and real-time. PNDS addresses that problem head on in a way that is appropriate for real-time processes like IDS in ways that traditional scanning technologies have a very tough time providing.
I then went on to say that we're planning on making changes to Snort to enable it to leverage the information that a system like RNA provides and make it into a true target-based IDS, redefining how IDS operates and hopefully revitalizing it as a technology. Snort will still be available for free and will still operate in "classic" mode where it doesn't leverage this info for people who don't have passive discovery technologies (or even active ones) so that they can still continue to use it.
Snort is not going to be doing the configuration policy enforcement (i.e. the "block OS X on my network" function), RNA is. RNA is capable of seeing devices on the network and discovering their attributes in real-time and communicating that data to our management console where it can be analyzed for policy compliance and where appropriate remediation responses can be executed. Not to get too deep into the marketing, but there are good engineering reasons for wanting to do this that include worm/virus containment, real-time IDS policy updates and some other really useful mechanisms for performing policy enforcement.
We're making mods to Snort because we believe that we can make a truly next-generation IDS capability that is easier to deploy, manage and get valuable information out of due to the effect of RNA. This approach directly addresses all the arguments of the "IDS is dead" crowd while at the same time making IDS a much more impactful technology while greatly reducing the overhead requirements on users.
I hope this clears things up for people!
First off, I'm not just Snort's author, I'm also the founder of Sourcefire. Sourcefire was started once it became apparent that enough commercial/governmental users wanted commercial support to make it a viable business model. Raising the VC was not easy, try going into a venture capatalist's office sometime and telling them about how you want to build a product company around a core technology that's free. I talked to something like 12 different investment firms before we got the time of day from anyone, VC wasn't really looking for the next big Open Source story in 2001, they were trying to figure out what the hell happened to all their investments.
Sourcefire eventually got funded, but we did it the old fashion way by building the product on a shoestring and then selling it into big accounts. Once we made a few hundred kilobucks from my living room (i.e. the original Sourcefire corporate campus), we finally got some attention and (eventually) money. Let me reiterate, it was not easy.
The author of the article could have saved some money on books (and so can you) if you simply read the USAGE file and the SnortUserManual.pdf file that should be incuded with your Snort download. Both of those files have quickstart information that will let you get up and running with Snort in about 15-30 minutes. Snort was designed to be easy for people who are used to using Linux, keep that in mind when using it for the first time. If you're getting lots of little log files, try using the -b switch at the command line, it'll log to a single file in pcap binary format (like ethereal/tcpdump). Additionally, read the FAQ and check out the mailing lists, they're invaluable.
Finally, the security vulnerabilities that were located in Snort this past spring led us to perform an internal and two external independent paid security audits of the Snort code base, funded by Sourcefire. We're also excersizing additional diligence when evaluating contributed code and looking at the code we're developing internally at Sourcefire. It should be noted, all the code that is developed for Snort at Sourcefire is released under the GPL, we're dedicated to always keeping Snort free and making it the best IDS we can.