Hi There, As I often have greater respect for a much larger portion of this list than the rest of the internet, I am curious what is thought about current IDS/IPS hardware from vendors like Trustwave, Checkpoint, Alert Logic, mod_security, even snort.. etc, and in particular, the sensibility and effectiveness of using them in high-security environments. From a compliance perspective, I don't have much choice. From the costs, infrastructure, and administrative perspectives, I am currently evaluating whether or not I should be leaning towards and IDS or IPS solution, and of course which system/vendor. My understanding is that something like snort requires a fair bit of maintenance and IT-attention, the trade-off being cost, so I am leaning away from this. Between detection and prevention, preventing break-ins seems a bit sillier than trying to actively monitor what's going on and to then look for threats, so this pushes me more towards IDS over IPS. Thoughts, suggestions, flames, are all welcome. Thanks. ~Jason
I agree with you. High rates of false positives, but fairly low rates of false negatives. Once the care and feeding is taken care of (turning off everything and gradually fine tuning to your current traffic helps), they're useful for alerting against unusual traffic leaving your network; not so much against automated attacks coming in the network. My own deployments are specifically to monitor for odd outbound traffic from my office. It's a rapid way to find out about the latest trojan, worm, or other infection my users have brought in on their laptops. That said, the usefulness of an IDP is specifically preventing most automated and known attacks from passing in to your network. By using one of the commercial systems, you gain support, tuning, and the fact that you don't have to spend as much time with the care and feeding or writing/testing new rulesets against your current version. As a compliance feature, I've found most administrators put them in place and promptly turn the reporting off due to the high rate of false positives reducing the signal from the noise. jb
Don't bypass Snort because PFSense package makes it so easy to install and configure. A a one-click install of Snort and the only thing left to do was register and select what you want it to do. Mehma ===
Hi Mehma, I'm hoping you can expand on this - maybe it is just me, but I'm not quite sure what you're trying to say or communicate.
Jason, I was trying to communicate my very small and limited experience with Snort on a PFSense appliance (FreeBSD + pf). The install and configuration is easy. I cannot speak to on-going maintenance on a big network. Mehma ===
Indeed, this is why IDS makes more sense to me, and I am glad to see this confirmed/validated by others here. So I guess this is now just a This is the difficult place I'm in.. to me, the commercial solution means I have someone else looking at and dealing with all of the false positives, which is something that I won't kid myself on - I don't know if I even have the time to be the fine tuning machine.. then again the cost is just plain silly when compared with a snort/bsd setup. Are there any good open source alternatives to Snort that are worth right, which is just silly and a waste of everyone's time. thanks for sharing.. ~Jason
bro-ids may be an alternative for you to consider. There is a port/package like snort and the maintainer had asked for feedback/tests for the new version 1.5.1 in the lists recently. It has a number of features that I felt complemented Snort's list of features. -- Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited 59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6 Phone: (204) 885-9535, E-Mail: email@example.com
Great suggestion! thank you :)
Allow me to speak from another perspective. It all depends on $$, and the network you have and how much leverage the security team has. Usually, the security team does not have as much leverage and needs to play catch up. Understand this - no matter which solution you choose, IDS/IPS/opensource/commercial, *someone* has to dedicate time to watching the logs and alerts, or you might as well not do it. When we implemented ours, my IPS guy spent half a year analyzing the traffic, working out with each team on documenting every single traffic pattern. Once that is done, we flipped the switch and turned the monitoring into prevention mode. And unless you have a huge security team, I'll take every bit of help I can take - I used to be against IPS (preferring IDS instead), but after living with it for 3 years, I'll take IPS to knock off some of the crap. Just don't get ISS crap. Also, snort is good, but you must know what you're doing. Our snort box, running on an old throw away box, and only capturing/analyzing 10 minutes of every hour, is giving us *MORE* useful data than half a mil worth of ISS crap. And the commercial version, sourcefire, is even better. My ex-coworkers at another place just had a shoot out of 10G devices, and sourcefire came out heads and shoulders against everyone else. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk "This officer's men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation. "Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted." -- Gene Spafford learn french: http://www.youtube.com/watch?v=30v_g83VHK4
Care to elaborate? :) <more interesting information> Thanks!
them, IBM is now killing the entire product line? What kills me (and *TAKE NOTE - THOSE WHO REPORT TO PHBs*) is that just a few months ago, we read a report on how ISS's IPS took top billing in some magazine or review. On what we're doing internally, we're capturing data for 10 minutes every hour, and then having the box analyze that data using a variety of tools including snort. It then sends us information on crap such as botnet command/control traffic among other things. Things that we have full packet captures on, that ISS refuses to provide. We also drop it into a graphing tool, so we get nice maps of green/good traffic and red/bad traffic, and you can see that 3 boxes that's talking to all the botnet C&C servers, etc. We're still working on it, and I hope the new(er) servers we are putting in will be able to provide better/more info. Hopefully we'll buy some really beefy servers later in the year so that we can do full analysis. I'll send a list of the tools we used later, have to ping my guy for it :) -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk "This officer's men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation. "Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted." -- Gene Spafford learn french: http://www.youtube.com/watch?v=30v_g83VHK4
I haven't done my indepth homework on commercial solutions - we're a small company with a small budget, and have been reviewing various solutions in the <20k / yr range (trustwave, alert logic, tripwire, etc). But a good point has been brought up about overall access and the depth of information available.. I'll have to dig deeper on this. I don't know if this is a big enough issue for us to overcome the Sounds pretty rockin' - I'm sure it took a while to get that sorted That would be fantastic, I am surely interested in some of the details of how you have put this together. Thanks for sharing! ~Jason
IBM is not killing the ISS product line. They are removing some older Thanks! This sounds very interesting tbh.
I have updated information. Now, it's more along the lines of "we will regroup", change focus, realign focus, etc etc, reinvent themselves. Sorry, this is like the 4th time they are "re-inventing" something or other. GX6116 re-arranges traffic. Bleh Over the past week, we had a system compromised. A vulnerability that is at least 3 months old (PDF and others) that the ISS IPS system claimed to have *BLOCKED*. However, we have evidence, capture on both sides of the IPS (GX5208) that the traffic went through. Only 1 out of the 6 attacks was actually blocked. And the XForce have confirmed that our analysis is correct. They're working on a signature. But it will not make March xpu. No promises on April's xpu. They will provide us a "patch". Bad bad taste in my mouth. My guy wrote a custom signature in snort in a couple of hours. And lets not even talk about the damned SQL Injection signature. Every few months, they "tune" it. A "+" in the URL triggers it. *ANY* URL with a "+" triggers the damned SQL Injection signature... This is such a major WTF?! I'll send a list of the tools we used later, have to ping my guy for it :) What he did is have a cron job. Remember, we are doing this on an old box, so we could only analyze a fraction of the traffic. 10 minutes of every hour. tcpdump, dumps the traffic. A bunch of processes are executed against the pcap file. tcpdstat, 3 snorts - one against VRT ,one against community, and one against custom sigs, other tcp* tools (tcpflow, etc etc). Anything interesting is extracted and archived. Reports are generated. Afterglow generates a nice display so that we can visualize the problems, and executives can look at it and nod knowingly. Alerts are sent off whenever certain thresholds are met. We're looking to hook it into our help desk ticketing system so that we don't have to manually do it :) -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk "This officer's men seem ...
On Wed, 17 Feb 2010 22:59 -0500, "Jason Beaudoin" I use Snort in IDS mode on OpenBSD and am very satisfied with it. It's hard to justify spending 10's or 100's of thousands of dollars for commercial solutions that have the same issues as Snort (false positives, requires tuning and constant monitoring). I have used large IBM/ISS Proventia systems in the past. Some of the commercial offerings will not even give you a terminal so you can use tcpdump... can you believe that? You have the perfect spot on the network and the perfect hardware, but you can only use it in a very limited fashion. Very frustrating. General purpose OpenBSD boxes with big beefy network interfaces cost a lot less and does more. I use FreeBSD to run BASE as the analysis frontend. The OpenBSD Snort sensors ship their alerts to it. I would use OpenBSD for the frontend as well, but BASE is not currently in ports and I have not had time to work on porting it and prefer not to go outside of ports. Also, I would stay away from IPS mode. There are enough network problems as is without something randomly deciding to drop packets. There's no better way to make a network engineer mad than to send them on a wild goose chase trying to figure out why packets are not getting delivered only to find out that the IPS is dropping them because certain SSL traffic looks like a buffer overflow or something. That has been my experience.
They're very-overpriced junk. Let me explain why. First, if you're using a good firewall (like pf on OpenBSD) and you've configured it sensibly (read: default deny-all, bidirectionally) and you've done the other things that good network and system design tell you to do, then you've done far more for your operation's security than any of these overpriced overhyped devices will do for you. Don't forget the value of application-aware proxies behind a stateful packet filter. And don't forget to drop packets to/from as much of the Internet as you can -- see ipdeny.com. (Do you *really* need to allow incoming port 22 connections from Korea? Peru? the US?) Also use the Spamhaus DROP list in your perimeter devices *and* in onboard firewalls just in case there's a configuration screwup. Once you've done this, you can fret a lot less about what particular SQL injection attack is being carried via HTTP...because you're not even allowing [most of] the packets to get anywhere near a web server. Second, these devices are guaranteed to fail when you'll need them most: when an attack comes that they don't have a signature for, won't recognize, and won't stop. (And please don't anyone tell me that this won't happen: the Bad Guys can test against them, too, you know.) See Marcus Ranum's "Six Dumbest Ideas in Computer Security" and note #2: "Enumerating Badness", which is expounds the fundamental error that all these devices make. Quoting Ranum: One clear symptom that you have a case of "Enumerating Badness" is that you've got a system or software that needs signature updates on a regular basis, or a system that lets past a new worm that it hasn't seen before. Yeah. Like that. Third, any sufficiently determined attacker will either bypass or elude these devices. I don't know where you are, what your operation is, etc., but I'll bet that if I *really* wanted to get inside it, that handing out free USB memory sticks (with your company's logo on them) to ...
Hi Rich! I'm not going to argue, and this discussion has certainly brought up a few good points which enumerate why, I had just been hoping that the investment spent would not go towards hardware or a crap system, as agreed, my situation isn't one with overall flexibility - an IDS/IPS is a compliance requirement, but I don't really see a commercial yes, I am considering mod_security for this, though I'm still trying Definitely great suggestions - and while our client-base is international, and we do travel, I can still use this selectively and Here's a great article that exemplifies the results: http://www.informationweek.com/blog/main/archives/2010/02/another_massive.htm indeed, hence the challenge. thank you for sharing! ~Jason
Having looked into BroIDS and a couple of potential options/setups, I'd be interested in hearing anyone's experience working with either or both BroIDS / Snort.. - i like that BroIDS is network-based as opposed to signature, though it doesn't seem like Bro has frontend as polished as one might like.. are the alarms only sent out via mail/etc.. or are there utilities to help parse/graph/htmlize the results? I like the idea of something like BASE for analysis. - anyone running BroIDS / snort who might be able to share the system specs and what sort of traffic / analysis / capturing they are doing? - is BroIDS capable of working in "sentry" mode, as a sensor reporting to one analysis system? I see the options for full capturing and offline analysis, but this is just going to spit out some flat files.. getting them to another system for analysis seems a bit cumbersome.. - in terms of BroIDS/Snort and PF.. who comes first in processing network traffic? - is Bro able to log, compress, store and index events for later reviewing/searching? or should I just have the events forwarded to a central logging server running splunk..? thanks for the insight.. ~Jason
|Ken Chen||[patch] sched: fix inconsistency when redistribute per-cpu tg->cfs_rq shares.|
|Ingo Molnar||Re: [PATCH v3] x86: merge the simple bitops and move them to bitops.h|
|Jan Engelhardt||Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection|
|Dmitry Torokhov||Re: [2.6 patch] input/serio/hp_sdc.c section fix|
|Rafael J. Wysocki||[Bug #16380] Loop devices act strangely in 2.6.35|
|Steven Grimm||Using git as a general backup mechanism (was Re: Using GIT to store /etc)|
|Jeff King||Re: [PATCH] git-reset: allow --soft in a bare repo|
|Johannes Sixt||Re: [PATCH 01/14] msvc: Fix compilation errors in compat/win32/sys/poll.c|
|Johannes Schindelin||Re: [PATCH] Uninstall rule for top level Makefile|
|Shawn O. Pearce||Re: [PATCH v2] Speed up bash completion loading|
|Linux Kernel Mailing List||cgroups: clean up cgroup_pidlist_find() a bit|
|Linux Kernel Mailing List||sony-laptop: Add support for extended hotkeys|
|Linux Kernel Mailing List||IB/core: Add support for masked atomic operations|
|Linux Kernel Mailing List||V4L/DVB (8939): cx18: fix sparse warnings|
|Linux Kernel Mailing List||ipv6 mcast: Check address family of gf_group in getsockopt(MS_FILTER).|
|Inaky Perez-Gonzalez||[PATCH 40/40] wimax/i2400m: add CREDITS and MAINTAINERS entries|
|Karsten Keil||[mISDN PATCH v2 05/19] Reduce stack size in dsp_cmx_send()|
|linux||Re: 2.6.23-rc8 network problem. Mem leak? ip1000a?|
|David Miller||Re: tun: Use netif_receive_skb instead of netif_rx|
|David Miller||Re: [net-next PATCH v2] llc enhancements|
|Matthew Fleming||Re: [RFC] Outline of USB process integration in the kernel taskqueue system|
|firstname.lastname@example.org||Re: OT: 2d password|
|Hartmut Brandt||Re: problem with nss_ldap|
|Andrew Reilly||Re: FreeBSD's problems as seen by the BSDForen.de community|
|Max Laier||Re: Upcoming ABI Breakage in RELENG_7|