Intrusion Detection recommendations

Mailman List Mirror (Read Only)
1

NANOG'ers,

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

Thank you all in advance for your wisdom.

2

I'd have a look at Alien Vault if you don't want to fork
out heavy money and have a geek enough staff who doesn't
mind butchering it up. It can be plug and play to an extent
yet at the same time, if not configured properly it becomes
useless.

On the other hand, if you don't want to waste precious time
in the event of say incident response to an actual event,
then I would opt for QRadar.

IDS/IPS is a mere buzzword. Detection comes via way of
knowledge: "Who knows/has seen, that N traffic is malicious"
often based on signatures. Then of course you get all the
nifty buzzwords: "but we use heuristic doohickey reverse
nacho cheese technology!" Prevention is a paradox. If it
did prevent then why did you get notified via a tweet that
you were compromised before you even knew you were.

IDS works like this (in theory): Look at all logs, and all
traffic patterns. Compare this data (often) to a config
file of known knowns, if it matches what we have seen then
it MUST be an attack.

IPS works like this: Sell someone an IDS appliance or
software and tell them it's IPS. It won't stop a huge
portion of attacks since it is well... IDS but boy does
it have a cooler name.

ITS (Intrusion Tolerance) works like this: Ok, so we won't
stop them, we can't prevent them, but boy oh boy can we
tolerate them!

All work off of a broken premise of "known knowns" and
not one vendor will ever come clean on this.

I have had the opportunity (or misfortune take your pick)
to have analyzed quite a bit of malware, intrusions, and so
forth. I have seen how rapidly some of the attacks change,
so I know firsthand why IDS, IPS, and others fail. Now
let me be fair... IDS/IPS are good as a HSSS (new buzzword)
Hind Sight Security System, but will only prevent, and
detect what is known.

Your best goal is to perform a combination security and
network analysis PRIOR to implementing any system. In doing
so, you create logic suitable to your environment. For
example, you have a DB that is supposed to ONLY communicate
internally, a better approach would be to go on to that
machine, and use the local machine's firewall rule to
create a rule that says: ONLY CONNECTIONS FROM HERE TO
THERE ARE ALLOWED ALL OTHERS GET BLOCKED, then alert when
something strays.

Most of these systems lack because of the design prior to,
and after their implementations. Organizations haven't
taken the time to map data, processes, and create even
a simple baseline to work with. This leads to these types
of systems (IPS, IDS, SIEM, ITS, blah blah blah) generating
all sorts of false positives. These false positives often
overwhelm the users tasked with the administration of the
systems. Thousands of alerts which often go unchecked until
it is too late.

thee end.

3

Unless you need regulatory-grade IDS, your best bet is a Unified Threat Management (UTM) appliance, essentially any modern enterprise grade firewall such as a Cisco ASA, Fortigate, SonicWall, etc. These all have built-in IDS/IPS options for a fee.

-mel

4

With all due respect, is regulatory-grade IDS the same as
say "military-grade" encryption?

5

Flip over these, or ideally watch the talk before deploying an ASA (or some
other black-box security appliance that tries to be All Things to All People)

https://ruxcon.org.au/assets/2014/slides/Breaking%20Bricks%20Ruxcon%202014.pdf

6

JO,

IDS to meet PCI or HIPAA requirements is "regulatory grade". It meets specific notification and logging requirements. SNORT-based systems fall into this category.

-mel beckman

7

<ramble>tl;dr (even I don't read what I write)

You failed to see the snark in "military grade" crypto
comment. This thought process is what causes many
organizations to fail repeatedly. Relying on what the herd
says. PCI, HIPAA, FINRA, FISMA, and all of the other
regulatory guidelines, standards, baselines, and mandates
spew from the manufacturing industry's ISO (BS pick your
poisonous acronym). Call it SADHD (or Security ADHD) but I
don't get why everyone keeps running around like dogs
chasing their tails.

Let's look at HIPAA where everyone is scrambling to replace
Windows based on the word of the herd. Here is the rule:

"Unsupported and unpatched environments are vulnerable to
security risks. This may result in an officially recognized
control failure by an internal or external audit body,
leading to suspension of certifications, and/or public
notification of the organization's inability to maintain
its systems and customer information"

Do you chuck Windows XP? It'd be easier to in theory but not
in practice, however NO ONE EVER SAID: "thou shall chuck XP"
(http://www.hhs.gov/ocr/privacy/hipaa/faq/securityrule/2014.html)

"The Security Rule was written to allow flexibility for
covered entities to implement security measures that best
fit their organizational needs. The Security Rule does
not specify minimum requirements for personal computer
operating systems"

Organizations keep relying on half-decent guidelines for
remedies to their problems. By you thinking that you are
going to plop in any "regulatory grade" *anything* and find
security, you are doing not only yourself a huge disservice,
but also to your clients. These pieces of technology (IPS,
IDS, FWs, HIPS, NIPS, etc) are only capable of doing what
you tell them to. Neither the Payment Card Industry, NIST,
or even the President of your country (or Premier, or
whatever else) should be telling you how to secure your
organization. YOU need to know the ins and outs, take the
proper steps and THEN use these technologies when you're
done with your risk assessments.

If you're relying solely on what others tell you is
"regulatory-grade" or "military-grade" or any other kind of
grade, your bound to be right up there with Target, Anthem,
Citi, JP Morgan Chase, <snip>a wikipedia-length list of
compromised companies</snip>.

When doing pentesting work, I fill up IPS and IDS with so
many false positives, the analysts are FORCED to ignore the
results while I shimmy my shiny right on by. I know based on
experience what someone is going to do when they see a
kabillion alerts light up their dashboard.

http://seclists.org/incidents/2000/Aug/277

The approach: "Let me cater to what they say I should do"
versus: "Let me figure out what my organization does, needs
to do, and how to get to the proper point" is mind boggling.
I wish there were a statistical database of compromised
companies, and the tools they used, frameworks they followed,
and regulatory nonsense they needed to comply with was listed.
Most of these regulatory mandates are based off of half-baked
models that are partially good when followed thoroughly.
However, they are ONLY partially good when an organization
goes beyond the normal banter: "thou shall apply this" - Does
not mean: plop in an IPS and call it a day. For the most part
though, this practice of half-baked security will continue,
vendors will make bucketloads of money, consumers of IPS/IDS
devices will still complain how much the product sucks, and
I as a pentester... I stay happy as it keeps me steadily
enjoying Five Guys' burgers

</ramble>

8

I am a huge fan of FreeBSD, but for a medium/large business I'd definitely
use a fairly well tested security appliance like Cisco's ASA. Depending on
the traffic you have on your fiber uplink, you can get a redundant pair of
ASAs running for less than $2,000 in the US. I just find it less stressful
to use a solution like ASA rather than worrying about patching your kernel
every so often and worrying about possible vulns in the ipfw/pf codes.
That, and you have to make sure EVERYTHING is taken into account when you
create your rules, which requires some intense knowledge on either ipfw, pf
or both.

I am not an expert in intrusion detection, so with regards to that, I'd
just setup a honeypot and monitor activity. You can also regularly run
penetration tests on your own network and see how well you are protected.
Just make sure the appropriate people know about these tests so you don't
get wrongfully reported.

Rafael

9

Closed-source software is faith-based security.

---rsk

10

What is the alternative then... Does he have the time to become a BSD guru
and master ipfw and pf? Probably not feasible with all other job duties,
unless he locks himself in his mom's basement for the next 5 years.

11

The alternative is to understand what his network does,
what it was designed to do, and what he needs it to do. The
end solution (IPS, IDS, ASA, whatever you want to throw in)
should be just that, an END solution once he has taken the
time to assess risk. This is a concept many miss. As for
"testing" ...

So you own a house, you hire an assessor to analyze your
property, write a report for you on your vulnerabilities.
"You have 12 windows. OMFG Someone can break one of those
windows and steal your family jewels!" Vendor gets paid
and leaves you with a headache. 12 windows? So what...
Behind those windows are a rabid pitbull I never feed.
Wanna take a chance to break in?

Pentest... "So you own a house, same windows, now you're
paying someone to get in." Let me tell you how pentesting
fails. Pentesting fails because most companies get all
bent out of shapes based on Internet history of systems,
and applications crashing from a simple network scan.
Ask your next pentesting client (if this pentesting is
your primary function) to allow you to perform a no-holds
barred pentest including social engineering. You'll get
the deer in headlights look. I discussed this recently
with a client who wanted to be snarky: "Oh you'll never
get in my systems" and I decided to inform him about
reality...

Reality: Hardcore attackers are NOT charging down the
castle road with a log trying to break down the castle
wall. They're sending client side attacks (phishing
emails, waterhole attacks). It's more cost effective for an
attacker to do this versus trying to defeat the router,
the switching with all its VLAN glory (that gets vlan
hoppped), the L7 firewalls, the load balancers, the IPS,
and then the IPS. Its useless, noisy, and just not cost
effective when you think about it.

IPS, IDS does little because they're RARELY applied in a
proper fashion. As for tinkering, geekiness. If you can't
at least wrap your head around the concept, then I don't
know why you'd want to be on this list. Further, IPS/IDS
is better suited to be inverted (Extrusion Detection) as
you WILL NEVER (CAN NEVER) stop someone from knocking on
your door. So you block every APNIC block thinking "Phew
I just blocked 100% of APTs" until you get whacked from a
hosting company in the US. What have you accomplished?

On the EXTRUSION side of the equation, knowing your
network, and how it works makes more sense. Your focus
gets shifted to the following logic: (rule) SHOW ME
ANYTHING LEAVING MY NETWORK THAT IS OVER 1MB ON A
SUNDAY MORNING 2AM ... This anomaly means a hell of a lot
more than watching all of the internet trash that will hit
your door (egree ifaces)

12

By the time you learn enough about security that the box is actually
securing something rather than just filling a checkbox on a form,
mastering ipwf/pf is the least of your worries....

13

Hello Andy,
I believe you are very good set up the way you are in technology. I see you are surrounded by BSD systems everywhere, on servers, mobile and desktop. And I suggest you keep running FreeBSD for this new security requirement you have.
We run FreeBSD as IDS/IPS system on several sites, and pfSense on a couple others. From my experience, we started using Snort, the common path people usually follow, but under certain circumstances, the drop ratio (unprocessed packets) started to raise a lot, and we looked for options. Tried Bro and Suricata and with some help from one of our servers supplier we decided to give Suricata a tuning and special try, and it became our primary option for IDS.
Therefore I strongly suggest you start researching around Bro vs Snort vs Suricata and try to reach your conclusions from your own findings. But if you ask me for suggestion, as a long time user for Snort, I deprecated it in favor of Suricata. So my primary suggestion is Suricata + FreeBSD as IDP. Suricata is a very serious Project with very good software provided.
We run ServerU networking servers, and they are the vendor who supported us. Usually they offer their own software solution called ProApps, it's a system made on top of FreeBSD which you have full root access etc, a plain old good FreeBSD system, but with nice auto update features and a helpful web GUI which allows me to delegate IDS operations to different level of staff operators on my team.
They allow using for their ProApps solution on ServerU hardware, so if intend to add new hardware to your project, it might worth a try. I find the tool very powerful and very complete.
On pfSense side you have a third party package made by community members, it also has a nice GUI, good deployment practices, but is Snort based.
At one special location we needed even more performance for packets capturing, and we added Suricata running in Netmap mode, and it raised performance three times on the same box.
So if you are looking for something easy, ready and supported, go for ServerU+ProApps. If you are looking for plain good open source arranged the way want to, you can have just the same with FreeBSD + Suricata & Friends.
Should you want to do everything by yourself, FreeBSD + Suricata + Barnyard2 + Sguil + Snortsam is my suggested path way to go, with Richard Beijtlichs' books on your hand for good analysis learning and IDS best common operation practices. And maybe I can be of any help, private mail me if you want to.
Regards,

14

tl;dr
dc

-mel

15

Of course it is. You say that like faith is a bad thing.

The illogic of claiming to have no faith in anything is this: it's impractical to assume the role of quality assurance for everything in your life.

The question is your faith reasonable. Ever use an elevator? Faith. Drive a car? Faith. Drive through a green light? Faith. Faith. Faith.

Show me a man who has no faith, and I'll show you a man who is paralyzed. (Not a sexist statement; woman seem to have few problems with Faith).

-mel

16

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

An important thing to realize is that an Intrusion Detection System is
not a "product" you can buy.
And if your org. is 100 people, you should probably think about
engaging some professional security services firms to help,
starting with a basic Info. security and physical security audit from
an independent third party.

An intrusion detection system consists of an infrastructure stack
containing vigilant dedicated human beings, devices, various
software for instrumenting the network in different ways and analyzing
collected data, documentation, business, and security processes
within the organization.

Without enough of all those pieces, there are plenty of off-the-shelf
IPS offerings, BUT using one could very well instill a false
sense of security, because you have no idea if the product is
actually doing a good job at what it is supposed to do, and not just
presenting a "perception" of security mostly by tackling just
whatever bugs or malware is appearing in the news headlines of the
day.

Also, there is the matter of being equipped with suitable analysis and
response plans to be prepared for the time that the IDS alarm actually
goes off, and to be able to determine if it's actually legitimately a
false alarm, something meriting investigation, or if it represents
an emergency.

We're a smaller outfit, less than 100 employees, entirely Apple-based. Macs, iPhones, some Mac Mini servers, etc.

[snip]

17

German Shepherd Dogs are wonderful intrusion detection devices. In a lot of cases they also server as excellent intrusion prevention devices as well.

(Must be Friday night)
:slight_smile:

18

The ASA, like so many network/security appliances anymore, runs Linux (or *BSD) under the hood, however I don't know how old or horribly mangled it is.

jms

19

I know this will come a shock, but there are now a plethora of how-to's
and tutorials and books and FAQs and examples for pf. Getting from zero
to a first-order working configuration, especially for someone already
familiar with FreeBSD (as in this case) should not entail more than a
couple of days of reading and tinkering. And it's most definitely not
necessary to become a BSD guru in order to run:

  pfctl -f /etc/pf.conf

Obviously complex use cases will require more understanding, but that's a
constant regardless of the platform. There's really no point-and-drool
shortcut for actually understanding what your network's doing, why it's
doing it, and how it's doing it in sufficient depth to figure out which
parts of that are goodness and which are dubious -- worse. To quote
Ranum, "How can you call yourself a 'Chief Technology Officer' if you
have no idea what your technology is doing?"

---rsk

20

I am a huge fan of FreeBSD, but for a medium/large business I'd definitely
use a fairly well tested security appliance like Cisco's ASA.

Or maybe Juniper, Cisco's Ironport, IPSO?

They are all FreeBSD based, big and large critical networks ready.

FreeBSD's ipfw codebase exists for longer than most commercial products you
somehow believe to be more mature. So, FreeBSD's firewalling code at least,
as well tested as commercial vendors products.

Depending on
the traffic you have on your fiber uplink, you can get a redundant pair of
ASAs running for less than $2,000 in the US.

For this traffic rate the best part on a commercial product is just
irrelevant: good specifics hardware. Whatever can be done with a USD 2K
Cisco based solution can be done on cheap low capacity x86 hardware with
FreeBSD.

I just find it less stressful
to use a solution like ASA rather than worrying about patching your kernel
every so often and worrying about possible vulns in the ipfw/pf codes.

One does not need to svn update, build kernel, build world if he does not
want to. It's just a matter of adding freebsd-update to crontab (or having
you own manual updating cycle in place).

That, and you have to make sure EVERYTHING is taken into account when you
create your rules, which requires some intense knowledge on either ipfw, pf
or both.

Another point I am completely inclined to disagree.

My team is made up of junior level, trainees, to +20yr experience
professionals.

There is absolutely no relevant learning curve for someone who has
configured a Cisco or Juniper firewall to a PF or IPFW firewall. If the
guys comes from a Linux background he finds ridiculously simple to have a
PF firewall up and running, after all for someone used to that weird
iptables syntax and semantics, a firewall where rules are linear and
natural syntax are a piece of cake.

For new professionals, they quickly learn PF/IPFW better than Linux or
Fortigate which is another product we also have in place (heterogenous /
mixed team and technologies here).

The tool is just the tool, it should a matter of what the tool can or can
not do, but not a matter on how to use it. Cisco ASA and PF are completely
different animals, sure, but learning 'em from scratch or coming from other
animals like Linux or Fortigate is straightforward.

While products like fortigate have a nice GUI interface, it's just limited
and low productive. My team tendo to configura fortinet on CLI, and guess
what? Fortinet team are usually joked by BSD team when they see someone
using Fortinet cli.

It just takes 5 times more to configure several "edit" blocks, creating
objects, putting it all together to have a simple firewall rule in the end,
when the BSD guys do a one line rule with macros and tables sorted all for
equivalent "object" advantages. Nobody cares for GUI in my team, but if a
fancy GUI is required they send pfSense screenshots for the Fortinet guys
just to keep the making fun...

I strongly believe in the idea that open source has it's place and
commercial products have their place on different scenarios and
requirements. And in this scenario Mr Andy is asking about, IMO there's no
reason not to go with open source BSD.

Specially because he seems already familiar with FreeBSD.

I am not an expert in intrusion detection, so with regards to that, I'd

just setup a honeypot and monitor activity. You can also regularly run
penetration tests on your own network and see how well you are protected.
Just make sure the appropriate people know about these tests so you don't
get wrongfully reported.

Not the same thing, same goal or same results.