Re: OT: opinions on IDS / IPS solutions

Previous thread: Installer caching selections across different installations... how? by Matt Van Mater on Wednesday, February 17, 2010 - 5:22 pm. (3 messages)

Next thread: write uhid0 error EIO by Kemtole Ernesto on Wednesday, February 17, 2010 - 11:16 pm. (1 message)
From: Jason Beaudoin
Date: Wednesday, February 17, 2010 - 8:59 pm

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

From: Johan Beisser
Date: Wednesday, February 17, 2010 - 9:28 pm

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

From: mehma sarja
Date: Wednesday, February 17, 2010 - 9:47 pm

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
===

From: Jason Beaudoin
Date: Thursday, February 18, 2010 - 7:30 am

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.

From: mehma sarja
Date: Thursday, February 18, 2010 - 7:55 am

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
===



From: Jason Beaudoin
Date: Thursday, February 18, 2010 - 7:54 am

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

From: Vijay Sankar
Date: Thursday, February 18, 2010 - 8:08 am

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: vsankar@foretell.ca

From: Jason Beaudoin
Date: Thursday, February 18, 2010 - 8:17 am

Great suggestion! thank you :)

From: bofh
Date: Thursday, February 18, 2010 - 8:56 am

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

From: Laurens Vets
Date: Thursday, February 18, 2010 - 9:48 am

Care to elaborate? :)

<more interesting information>

Thanks!

From: bofh
Date: Thursday, February 18, 2010 - 12:59 pm

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

From: Jason Beaudoin
Date: Thursday, February 18, 2010 - 3:43 pm

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

From: Laurens Vets
Date: Saturday, February 20, 2010 - 3:31 am

IBM is not killing the ISS product line.  They are removing some older 

Thanks! This sounds very interesting tbh.

From: bofh
Date: Thursday, March 4, 2010 - 9:32 pm

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 ...
From: Brad Tilley
Date: Thursday, February 18, 2010 - 6:18 am

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.


From: Rich Kulawiec
Date: Friday, February 19, 2010 - 5:52 am

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 ...
From: Jason Beaudoin
Date: Sunday, February 21, 2010 - 10:16 am

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

From: Jason Beaudoin
Date: Monday, February 22, 2010 - 9:53 pm

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

Previous thread: Installer caching selections across different installations... how? by Matt Van Mater on Wednesday, February 17, 2010 - 5:22 pm. (3 messages)

Next thread: write uhid0 error EIO by Kemtole Ernesto on Wednesday, February 17, 2010 - 11:16 pm. (1 message)