[Snort-users] New IDS best practise
Mark W. Jeanmougin
mark.jeanmougin at ...14628...
Thu Nov 17 08:51:46 EST 2011
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
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
) 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...
More information about the Snort-users