Re: New IDS best practise

["Mark W. Jeanmougin" <mark.jeanmougin () cchmc org>]

Maymann,

First, if you're a "global, multi-site organization" then call 
Sourcefire. Their central management console just plain rocks. Their 
3500 & 4500 (1gbit & 2gbit) sensors are fantastic. It may not be cheap, 
but it is the kind of reliability, supportability, and "just works" 
nature that keep my bosses happy. I used to work for a very global 
Fortune 50, and now I'm at a very large, but regional company. The 
Sourcefire solution is what I've seen keep the suits happy.

/Sourcefire advertisement. :)

(I'm just a happy customer. I have no ties, financial or otherwise, to 
Sourcefire.)

Your questions:

On 11/16/2011 02:59 PM, Michael Maymann wrote:
> 1. Where would be the best place(s) to put IDS(s), if we aim to have
> a centralised view - e.g. can this be set-up as 1 central master
> (e.g. Snorby) and site slaves (e.g. Snort) on each FW LAN ?

1. I've got IPS sensors all over my network. Like two dozen of the 
stupid things. :) I'm not sure I'd go "all in" like this again. 
Certainly not as quickly as I did. Start at your borders. Put IPS behind 
/ in front of any firewall or VPN technology. Have them in front of your 
F5 load balancers, your email web gateway, things like that.

The one sensor which sees all my outbound Internet traffic gives more 
value than the 20 internal sensors combined. (That's an exaggeration, 
but not by much. When one considers then amount of time to maintain the 
20 sensors vs 1 sensor, then it is no contest)

> 2. How would it best be implemented - what would be the preferred steps.

This is a little vague, to me. I'm not sure what you're going after here.

> 3. What could be the typical pitfalls - e.g. would traffic possibly slow
> down because everything needs to go to a 100mbit port where IDS is
> located, etc.

This gets into your overall architecture. It seems like you want to make 
sure that deploying IPS doesn't slow down traffic too much. That's the 
same boat that everyone's in. The solution is to size your IPS sensor to 
the traffic which it observes.

Ten years ago, it was simple to get the fastest Intel CPU, load snort, 
and you'd be able to analyze most Internet pipes. Now, it isn't so 
simple. You need to worry about multi-threading on multi-core CPU's. In 
1997, 10k employees would share a T1, now half that many can saturate a 
100Mbit pipe. But, single thread CPU performance hasn't really changed 
that much. (Intel's first 3.0GHz processor was in 2002. 10 years later, 
they aren't that much faster)

As my mathematician friends would say: This is a previously solved 
problem. Many vendors (*cough* Sourcefire *cough*) have solved the 
multi-core and sizing problem. Just tell them your traffic load and 
they'll hook you up with the hardware and software which works for you.

If you want to roll your own, there are better people than I to help you 
with that. I'd just say that labs are your friend. Use "tcpdump -s 0 -w 
outfile.pcap" to get a copy of data from where you'll put your IPS 
sensor. Then, in your lab, use tcpsplit & tcpreplay to run the 
production data through your sensor. This isn't that hard (I'm happy to 
help) and will make your deployment go much easier.

> To begin with we would especially like to detect reverse ssh/corkscrew -
> any ideas how to do this properly in a set-up like ours, with or without
> IDS ?

I wasn't familiar with corkscrew. A Google search tells me that it is 
outbound ssh over https. This paragraph makes me think that you're 
looking for outbound traffic, data ex-filtration, and things like that. 
Unless you're doing SSL decryption (like 
http://www.sourcefire.com/security-technologies/cyber-security-products/3d-system/ssl-encryption-decryption 
) then I don't see how a network device can determine what is https vs 
ssh over ssl. They're going to look the same.

Those are my 2 cents...

MJ


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!