Slashdot Mirror


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?"

5 of 264 comments (clear)

  1. Size by chrome · · Score: 5, Insightful

    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 :)

  2. Re:Don't underestimate just paying attention. by Anonymous Coward · · Score: 5, Insightful

    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).

  3. Re:How do I do my job? by Rosco+P.+Coltrane · · Score: 5, Insightful

    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
  4. Don't underestimate what you already have by m0rningstar · · Score: 3, Insightful

    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.

    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 /that/. And then seeing if an IDS is of any additional use.

    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...

  5. Monitoring is expensive by Steeltoe · · Score: 3, Insightful
    While actively monitoring is always preferred, not everybody has the luxury of time to sit in front of the server monitoring every minor detail. Especially on projects for humanitarian organisations you do on your spare time. To be honest, some automation SHOULD be implemented, because a human is simply not a robot and will tire over time. The purpose of computing is exactly that - to alleviate humans of doing boring tasks.

    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:
    • Snort (Network packet sniffer)
      Enough is said about this. Absolutely needed, but useless without intervention. Oinkmaster is nice to use for automatic downloading of new rules.

    • Narc Firewall
      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).

    • BlockIt (Perl script for reactive firewalling)
      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.

    • Samhain (Rootkit and file change detection)
      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).

    • chkrootkit (Another rootkit checker)
      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.. ;*) All emails to root is forwarded to my email-account, cron-jobs and all, and believe me, with the pruning-job done, hardly any email is sent. Days can go without any emails, oh wait, maybe..... *shiver*

    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.