Intrusion Detection recommendations

I've been tasked by our company president to learn about, investigate and
recommend an intrusion detection system for our company.

We're a smaller outfit, less than 100 employees, entirely Apple-based.
Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the
world. We are protected by a FreeBSD firewall setup, and we stay current
on updates/patches from Apple and FreeBSD, but that's as far as my
expertise goes.

Initially, what do people recommend for:

1. Crash course in intrusion detection as a whole
2. Suggestions or recommendations for intrusion detection hardware or
3. Other things I'm likely overlooking

if you were comfortable enough with freebsd to use it as a firewall, you
can run your traffic through, or mirror it to, a freebsd box running or
two quite reasonable and powerful open source systems


Bro, SNORT, SGUIL, Tcpdump, and Wireshark are some nice tools.

By itself, a single install of Snort/Bro is not necessarily a complete
IDS, as it cannot inspect the contents of outgoing SSL sessions, so
there can still be Javascript/attacks against the browser, or SQL
injection attempts encapsulated in the encrypted tunnels; I am not
aware of an open source tool to help you with SSH/SSL interception/SSL
decryption for implementation of network-based IDS.

You also need a hand-crafted rule for each threat that you want Snort
to identify...
Most likely this entails making decisions about what commercial
ruleset(s) you want to use and then buying the appropriate

Checkout security onion. Its got a pretty nice suite of tools and can run a (or many) dedicated sensor system and communicate back to a central system.

As for SSL MITM, see the recent nanog thread for a full layer 2 to layer 8 ramifications of that activity.

For ssh mitm, I don't know of any tools. I'm looking for one.

This reminds me to bring up a point that can't be stressed enough:
it's just as important to block *outbound* traffic as inbound. Ask
Anthem. Or Target. Or the ghosts of the Trojans. :wink:

If you have subsets of systems that have no need to make an outbound
connection, ever, then don't let them. "block all log" is not only
your friend here, but it's your instant IDS, because if those systems
aren't supposed to be sending outbound traffic, and so much as a single
packet turns up in the logs, then something is going on that you'd
very much like to find out about. [1]

If you can't block all traffic, fine, block all and then permit
the 5-tuple

  {source, dest, source port, dest port, proto}

that is required to allow the necessary functionality. And again,
*anything* else is a sign of a problem.

And if you can't block all traffic *everywhere*, then at least block
everywhere you can. Start with the Spamhaus DROP and EDROP lists
(actually: block these directionally):

And then, if you can, use these:

And then, if you can, use these:

For example: you have an internal database server. Every night, some
cron job kicks off and builds an exportable subset of that data, which
is then rsync'd to a production web server somewhere. So that internal
database server only needs to reach 1 host on 1 port with 1 protocol.
Block all, then just allow that.

Another example: you sell stuff, but only in the US and Canada. Why
would you allow traffic from Ukraine or Paraguay or Syria to reach
your ecommerce web server? There is no positive outcome for you in
letting that happen. So don't. Use, allow the US and CA,
block the world. (YES, you can still be attacked from those networks,
and YES your IDS/IPS will light up like a Xmas tree when you are, but
at least you won't have to wade through page after page of logs about
attacks from Taiwan...because you dropped their packets on the floor.)

Default-deny is your best friend and should be the first rule in every
firewall everywhere. It's defense-by-default. Default permit is like
allowing everyone into the bank vault and then walking through the crowd
trying to decide who to kick out. So anywhere you possibly can,
block everything and then only allow traffic that's necessary to
accomplish the task(s) at hand.

I don't know if this approach would have saved Anthem or Target or
any of the rest. Maybe. Maybe not. But (a) it may save the next one
and (b) it has a fighting chance of causing intrusions to make enough
noise in the logs that someone will notice and say "That's funny..."
before the roof caves in and Krebs has to write a blog entry about it.


[1] But how will those systems do software updates? From your local mirror,
which is the only system that can reach out to one of the "real" mirrors.

Hello, I don't mean to hijack this thread, but I suppose its related -- I didn't know spamhaus could provide a BGP feed of "bad" prefixes like that (for a price it seems). Is anyone aware of other "free" providers of such naughty prefixes via BGP? I know Team Cymru has a bogon list that you can get via BGP session, just not aware of any others and these seem like a pretty good idea to have setup on your core.


These are all excellent tools for a dedicated knowledgeable network security person to use. The most important element being the dedicated knowledgeable network security person.



The original SANS DDOS task force, and many others since, have emphasized this. Filter your Outbound! Bogons for obvious reasons, BGP3 to keep routing multipliers, non-internals to keep from being used as an amplifier network, the list goes on. Be a good network neighbor.