Re: 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 software 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 https://www.bro.org/ or https://www.snort.org/ two quite reasonable and powerful open source systems randy
On Sat, Feb 14, 2015 at 2:38 AM, Randy Bush <randy@psg.com> wrote: 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 subscriptions.
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 https://www.bro.org/ or https://www.snort.org/ two quite reasonable and powerful open source systems
randy -- -JH
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. On February 14, 2015 12:57:29 PM CST, Jimmy Hess <mysidia@gmail.com> wrote:
On Sat, Feb 14, 2015 at 2:38 AM, Randy Bush <randy@psg.com> wrote:
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 subscriptions.
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 https://www.bro.org/ or https://www.snort.org/ two quite reasonable and powerful open source systems
randy -- -JH
!DSPAM:54df9aed198762108866735!
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sat, Feb 14, 2015 at 12:57:29PM -0600, Jimmy Hess wrote:
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; [...]
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. ;) 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): http://www.spamhaus.org/drop And then, if you can, use these: http://okean.com/asianspamblocks.html And then, if you can, use these: http://ipdeny.com/ 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 ipdeny.com, 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. ---rsk [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. Thanks -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Rich Kulawiec Sent: Saturday, February 14, 2015 3:29 PM To: nanog@nanog.org Subject: Re: Intrusion Detection recommendations On Sat, Feb 14, 2015 at 12:57:29PM -0600, Jimmy Hess wrote:
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; [...]
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. ;) 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): http://www.spamhaus.org/drop And then, if you can, use these: http://okean.com/asianspamblocks.html And then, if you can, use these: http://ipdeny.com/ 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 ipdeny.com, 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. ---rsk [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.
+10 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. --p -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Rich Kulawiec Sent: Saturday, February 14, 2015 4:29 PM To: nanog@nanog.org Subject: [EXTERNAL]Re: Intrusion Detection recommendations . . . 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. ;) . . . .
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. --p -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Jimmy Hess Sent: Saturday, February 14, 2015 12:57 PM To: Randy Bush Cc: North American Network Operators' Group Subject: [EXTERNAL]Re: Intrusion Detection recommendations On Sat, Feb 14, 2015 at 2:38 AM, Randy Bush <randy@psg.com> wrote: 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 subscriptions.
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 https://www.bro.org/ or https://www.snort.org/ two quite reasonable and powerful open source systems
randy -- -JH
participants (6)
-
Charles N Wyble -
Colin Bodor -
Darden, Patrick -
Jimmy Hess -
Randy Bush -
Rich Kulawiec