Comments

At work we use SonicWall and at home i have ClearOS set up on an old computer i have. Both work well, since i'm working on the CCNA i am interested in see what cisco has for this but that will be further down the road.

Despite the fact that its free, SNORT is the most common choice for corporate and government for IDS solutions. I work for the department of defense, and we use it. And the DOD is known for avoiding open-source when possible. But Snort has kinda become the DeFacto standard.

Despite the fact that its free, SNORT is the most common choice for corporate and government for IDS solutions. I work for the department of defense, and we use it. And the DOD is known for avoiding open-source when possible. But Snort has kinda become the DeFacto standard.

Forgive me for the questions just I am looking at setting up an IPS where I work and have never done it before. Some of the other IPS I was looking at such as Cisco and TippingPoint require hardward as well as software how come snort does not?

Also if I was to implment snort or any otehr type of IPS I would also like to implment Tripwire would that still be needed even with an IPS such as Snort I think it would as they do different jobs.

Snort requires hardware and software just like Cisco and TippingPoint. But if you are using the open source Snort you can customize the hardware (or use what you have available) and you are able to make any changes you'd like to the code. With Cisco and TippingPoint you can customize certain things: signatures, alerts, etc but you really can't alter the proprietary 'black-box' code they provide.

To me, Snort is the way to go if you are just experimenting and learning about running network IDS or IPS on your network. If you are looking for formal support you can always buy the commercial 'Snort' from Sourcefire and get the same type of support and signature subscription agreements you get from Cisco IPS and TippingPoint.

As for using Tripwire, that would be more of a host-based detection/prevention control whereas Snort would be network based. Adding tripwire could definitely add to your defense-in-depth strategy though. Tripwire (from what I remember) will detect changes to monitored files on the system and can alert based on detections. Changes could be caused by network attacks - which the IPS/IDS may not have a signature for - or it could be done from the system console itself.

If you want to check out a very nice pre-made all-in-one Snort/front-end GUI/back-end kitchen sink...check out the Security Onion site. Comes as a pre-built ISO so you can download and start running. Be sure to check out the wiki page to get started and the installation instructions.

You need to define what your requirements are. IPS / IDS comes in many forms (and the commercial variants are generally pretty expensive, typically priced based on throughput capabilities). For the moment I'll assume we're strictly talking about network-based IDS and not host-based. Snort is an absolutely fantastic piece of software and it's the core engine in Sourcefire products (naturally), but the level of granularity and ruleset visibility also presents a learning curve. Anytime you have a powerful, flexible solution, you're going to have complexity which may seem overwhelming at first.

HP TippingPoint and Cisco (and others) also have purpose-built appliances, but they present information in a different way. Some give you more data, some less, and it depends if you want a system that's more analysis-oriented with lots of flow data, user / OS context, event correlation, etc., or if you're looking for a dumb toaster that sits inline and drops stuff without giving you too much detail.

I've used products at both ends of the spectrum and I'll argue for one over the other depending on the organization's expectations. If you don't have staff with resources to perform low-level analysis of events down to the packet level with knowledge of how intrusions and monitoring evasions work, then you might not gain a whole lot by using an appliance solution that provides a ton of data. On the other hand, if you like to get your hands dirty and want to see the packets which triggered the events as well as the corresponding rule syntax, then some of the solutions out there will come up short. I'll always argue for the latter unless it's pretty obvious that the organization just wants a compliance checkbox. In that case, you could also just leverage IPS functions that might already be built into your firewall (like a number of UTM solutions out there as well as security modules for ASAs, etc.).

Security Onion is a good solution, but it's based on Network Security Monitoring (NSM) principles where you capture a copy of all traffic the sensor sees. If the wire that the sensor is monitoring passes 1 GB of traffic in an hour, you need 1 GB of disk space to accommodate for all of that. NSM relies on being able to drill down and see the entire traffic session flow for each event, or even events that the IDS engine didn't recognize (for example if you were to hear about something from a user, you could go back in time a few hours and look up the connection sessions for that IP and retrieve all traffic associated with it, payload and all, assuming your disk still has space for it and new traffic captures haven't overwritten the old one). The solution also leverages OSSEC as an open source host-based IDS as well.

SO also allows you to choose between Snort or Suricata for an IDS engine. You can also use Snorby or Sguil for the front-end interface management. However, there's no commercial support for SO and if something breaks, you'll be digging through the SO forum archives or Googling a lot to troubleshoot database issues, etc.. SO is not really designed for inline operation, so if you need to drop traffic as an IPS, SO wouldn't be the way to go, although I believe you can technically set it up to be an IPS.

SecurityOnion is a godsend if you want to try it out. I remember my first Snort setup years ago - hours were spent on installing and configuring the OS, mysql, LAMP stack, Snort, ACID... These days, SecurityOnion allows you to have a fully working IDS just by booting from CD/ISO.

“You don’t become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process.” (c) xkcd #896
GetCertified4Less - discounted vouchers for certs

Another question would you deploy Tripwire on all your servers or just the ones that are most valuable to you?

Depends on the business requirements and outcomes of cost/benefit analysis... Maintaining any system has an associated cost...

“You don’t become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process.” (c) xkcd #896
GetCertified4Less - discounted vouchers for certs

Another question would you deploy Tripwire on all your servers or just the ones that are most valuable to you?

Its probably just me, but based on my understanding, tripwire detects changes to (presumably) system files. Wouldnt these files be changed every day during the normal course of business? Especially when installing a program, we know files are going to be added, modified and deleted, its one of the reasons I hate Spybot S&D. You can alert all day on a change, but if the admin doesnt really know what is happening and what should be happening...

Tripwire is not a set-it-and-forget-it program. Its white list hashes must be updated every time system or app patches are applied. Tripwire is not used to monitor files that are dynamically changing (i.e., log files)

Traditional host / network-based IDS / IPS solutions expect the users of those products to have a level of low-level sensitivity of their environments. Detection systems which are configured to detect any type of change are generally purposed to look for unexpected changes on asset properties of high importance. If you get an alert that /etc/foo.conf is different from a previous check a day earlier (even if someone put a simple whitespace in the file accidentally), it indicates an integrity violation. If it's an expected change such as due to an update during a maintenance window, then it's not a big deal. But if it's something new, then it's suspicious.

If people are constantly making changes to key files that you want to monitor but there's no change-control or documentation involved, then it becomes much more problematic. IDS / IPS systems are better utilized when there's a baseline profile of expected known-good characteristics to compare against. Otherwise it just becomes noise.