Network Intrusion Detection and Prevention?
c0dyd asks: "Lately, computer attacks have gained much popularity in the news; however, it is not often that we hear of new software, hardware or 'appliances' that combat malicious code attacks and data intrusions. Obviously, the need is present. I've searched thoroughly for network intrusion detection and prevention systems, but the choices and technologies seem somewhat limited or proprietary-- Snort appears an obvious open source solution for intrusion detection but many users many find it lacking in intrusion prevention capabilities. What do you, the experienced network admin, use for detecting intrusions on the network and how does your network react to those intrusions?"
The biggest problem facing anyone looking at implementing an IDS into an existing system is the size of the network.
... :)
:)
If you're doing 500mbit/sec+ of traffic, it requires a somewhat beefy snort box just to process that data let alone do something about anything that looks like an attack.
Snort CAN do it, it just takes a lot of effort to pair down the ruleset to the point where it can handle your traffic. But, pairing down the ruleset has some drawback
Or, if you can segregate your network, that can help a lot too. But unfortunately, a lot of networks suffer from a lack of design and you end up with huge VLANs that span thousands of hosts, and other nightmares.
IMHO If you're worried about intrusion, start with host security. If you have a huge farm of linux boxes, then great. Use iptables and keep everything up to date. If you MUST have sun boxes, try not to put them on the edge of your network - NAT specific ports via linux NAT firewalls. Same goes for windows machines. Don't bare them to the internet for any reason.
Have some aggressive ACLs on your border routers. Don't allow SSH into all your machines directly. Use jumphosts. Consider using token based authentication, like SecurID. Consider Kerberos to replace the use of public key auth in your ssh infrastructure.
once you have that down, putting in an IDS can wait
A bandwidth graph may help you catch a noisy worm or a script kiddy. It's almost useless against a determined intruder.
Any good intruder knows to be quiet and spread their attack out over hours or days. Hence they are practically invisible to any sort of bandwidth analysis, until they start downloading larger amounts of your data (at which point it is often too late).
I get about 1000 probes and somewhere near 50 IDS events a day. Something tells me I won't like what I have to deal with if my firewall/IDS starts telling me about it in emails.
All of these logs are history. Fortunately I'm running Linux and 99% of these probes and attacks are of little interest and are no threat.
Now, when you get a tool that will tell me when at attack is about to happen, that's when I want to know about that tool. Especially if it can not only give me advance warning, but warnings appropriate for what it is guarding.
We should start referring to processes which run in the background by their correct technical name... paenguins.
I know you're trying to be funny (or troll, I don't know), but your comment is actually unfair: the entire software engineering world (not just OSS) is built on people sharing competences. Formal education and self-teaching only account for a small part of a computer engineer's know-how.
Asking Slashdot is as good a way as any to reach a wide audience and get a handful of good advices amongst the hundreds of trolls. All it takes is asking, and you never know what precious tidbit of information you might get.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Two words: Address spoofing.
Bad guys would not need zombies anymore for a DDOS: They would simply "attack" a couple of people like you with a forged source address, and let you do the dirty work. Bad Idea[tm] indeed.
Using the same analogy, though, you don't necessarily want your burglar alarm calling the cops every time someone tries to open a door on your house that you know is locked, or looks in a window.
All too often I look back at month old logs and see "hey, that's cool, somone was trying to hack us"
This is why you need to review your logs on a daily basis, or at the very least keep a monitoring program of some kind open that you check once in a while throughout the day. Ideally you've got someone who's entire job this is, but unless you're business is of sufficient size this isn't really feasible or necessary. Automatic monitoring/notification is nice, but shouldn't be relied on totally.
Sometimes it's not about you.
We're not talking about preventing DDOSs against you; we're talking about provoking your system into initiating a DOS on some other unfortunate victim by poking at your watchdog (junkyard dog?) software with packet probes that have forged source addresses--the addresses the blackhats want DOSed.
In other words, bad guys poke at you, you fire back and hit the wrong guy. Lather, rinse, repeat.
Doesn't seem like a good idea to me.
Welcome to the Panopticon. Used to be a prison, now it's your home.
I have to admit that I'm just not a big IDS/IPS fan. FAR too few people have the time (at least in my experience) to use them well. It doesn't matter what the product is.
/that/. And then seeing if an IDS is of any additional use.
What is generally lacking is a policy (which, sadly, security is mostly about) and a concrete idea of what to do when an 'attack' is detected.
And people then buy an expensive new IDS, or spend time to implement one, or whatever. Think it's exciting for a while. And then I come back 3 months later and it's turned off in the corner.
And in the meantime people aren't exploiting the information they already have. Not just the bandwidth graphs but firewall logs, system logs, etc. I personally would recommend finding an event correlation system (anyone know of a good open source one?) along the lines of Netforensics or the former Protego and implementing
IPS -- I haven't had enough personal experience with an in-line IDS to make even a remotely intelligent comment. I like the idea of such a platform but it (as MJR frequently points out) falls foul of being an 'allow everything not specifically denied' platform and thus limited. This is not an outright condemnation, since otherwise you run into best being the enemy of good, but it's something to be considered...
For real enterprise needs, companies like counterpane not only install the intrusion detection devices; but offer services that monitor them just like the physical alarm companies do.
......
:)
"real enterprise" doesn't need another log parser tied to an email notification service. It needs insurance. It needs another company to pass the buck to when they get hacked. I'm sure counterpane does a bang up job, but what you're talking about should only take a developer a few months to put together. Then you'd have the local expertise of the developer and the source.
An intrusion detection device without anyone responding to it is as silly as a silent burglar alarm that noone responds to.
The one feature I'd look for in an intrusion detection device is that it can quickly escalate a detected intrusion attempt to real people (through email, phone, calls, etc).
So multiple blaring alarms that noone responds to? I mean, if you've got an IDS without proper email integration, you've done it wrong. Snort does it already, based on attack type even.
Furthermore an admin running an ids that doesn't check it every day is USELESS. Uhm. No offense.
I set up my scripts so I am emailed ONLY on new activity not seen before. So I find ways to silence minor attacks/alerts which does not interest me in conjunction with finding automatic ways to react on attempts.
I can recommend this setup:
Enough is said about this. Absolutely needed, but useless without intervention. Oinkmaster is nice to use for automatic downloading of new rules.
Perl script for iptables/ipchains. Fast and easy to set up, however any decent firewall will do. Narc allows for user-customization/hacking, which is a plus for those who wants to learn ipchains/iptables and do more advanced stuff than a GUI can offer. I like to fiddle with the rules myself for outgoing packets, which very few firewalls supports. It's nice to know your computer is not sending out traffic you don't know what is. By blocking everything outgoing by default, I will catch stuff in the logs and adjust the rules when I know what it is (not recommended while in production).
Blocks hosts temporarily and permanently based on SSH-logs, snort-alerts and firewall-logs. Nice and easy to extend even if you don't know perl, but have patience to test alot. The maintainer is cool about accepting patches. Yes, you need a list of hosts to never block, and yes a dedicated cracker can spoof IP addresses to DOS you. However, I'll deal with that when somebody does just that. It depends how important your service is I guess.
I set up Samhain to email me of EVERY change in the root filesystem. However, I run Samhain with the silent option just after every upgrade at night. So upgrades are done automatically and silently without alerting me (Debian Stable - Sarge).
It's in the Debian-tree. Can't hurt to use more than one checker. This one is less spammy than Samhain and checks for other kinds of signatures in the system.
This might seem much, but I consider it a bare minimum for an install I'm not going to watch over continuously. Running Linux doesn't make you secure, and even with all this, I know I'm still vulnerable to:
A) Crackers hacking over time. Little by little they may do a portscan and find out enough to do a:
B) Full-scale successful attack. Reactive firewalls just won't stop it, and then you're cracked.
C) DOS. Automatic blocking based on IP and DSL-connection is just not enough to stop DOS and DDOS.
However, with a hardware firewall in front, I feel a bit more secure..
One interesting project is a firewall based on snort: Hogwash. The project is in need of maintainers though. However the idea is cool: To block based on snort-alerts in real-time. This can actually be useful to block intrusions before they can do harm other than DDOSing. I for one will accept the increase in latency if it means my network is that much more secure. I really hope this one will take off one day.
http://www.debunkingskeptics.com/