Rick Moen <[EMAIL PROTECTED]> writes: > And this is _another_ reason why a properly targeted file-based IDS is a > really capital idea -- as is alertness about what is and is not aberrant > system behaviour. I can even make this point in a Debian-relevant way. > All hail to the Debian Project's sysadmins, who in November 2003 showed > everyone how to do it right: http://linuxgazette.net/issue98/moen.html
Yup. IDS systems are wonderful. But they do require discipline. I've seen a depressing number of people deploy an IDS and then never bother to update the database. When you have >1MB of changes reported every day that you've trained yourself to ignore, you're just wasting CPU. That's really the take-home point with all of these discussions. There are a lot of great security tools available if you're paying attention and really think about what you're doing, clear anomalies, and make sure that everything they report really *is* unusual. If you don't do those things, and most unskilled users won't, then it's all about the defaults. If the defaults don't get it right, it's pretty much a lost cause. This is, for example, one of the reasons why I think Debian's logcheck package is such a good idea. It scans your system logs and mails you anomalies, and *lots of Debian developers use it and submit patches to filter out all the expected output*. The latter is vital. Because clued Debian users and developers keep the rule set up to date, it's actually usable for someone who doesn't know what they're doing since the reports aren't full of noise that isn't actually a problem. (It could, of course, be better, but I think it's quite good already.) Of course, even a good log checking program isn't as good as an IDS with a database in secure media (I personally use network file systems with strong ACLs requiring separate authentication; it's not ideal, but it requires a sophisticated attacker to compromise) since many attackers immediately wipe out the logs. logcheck is probably more useful for catching hardware failure than for catching security, although it can pick up security-related problems (such as piles of ssh password cracking attempts that remind you that you forgot to add an iptables rule for ssh). -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
