-
Ah! So you're looking for discussion on ideas for what you'd like the 'perfect' IDS to be then eh? Now that I can provide, but only in english because (as you can tell from my previous post) my coding syntax isn't what it once was.
I'd like to see a RealTime (yes, there's that nasty word again), monitoring system from which I can exempt specific user ip's. I most certainly wouldn't want to frag my boss or the (l)user down the hall who signs my paycheck were I the Admin of a major company - and I'm quite sure others wouldn't want that either....However, I'd like to see it be able to 'strike back' at an intruder, with checks in place.
IE: Intruder breaks in. IDS spots yet another 'authorized' account logging in at an odd time or from a strange location (yes, this more than likely is how it catches them).
It queries me by setting off a bell, whistle, or popup. If I don't answer within a certain time limit (say 30 seconds) it permits the login, but logs everything that user does - every single keystroke and mouse click. It also logs the IP address from which that user logs, and attempts to backtrace to find his point of origin, including isp 'abuse' email address, etc. It also makes a log of the method he used to get in - the username/pass he used, whether or not he bruteforced this user/pass, etc. I don't necessarily want to completely frag the guy, but I DO want to know who he is, why he's there, how he got in, and how to report him should need arise.
If I do respond in time, I get the 'decision gate' with which I either let the guy in (he's a permitted user), or don't. If I opt not to let the guy in, the defenses go up (see above).
I want all of this to be 'fire and forget' so when the intruder tries at 3am my blackberry doesn't go off, but I don't want it to forget to check with me when I'm there. I want the logs of the previous night to be right on my desktop because I'll want to review them every morning when I get to my desk - and I'll want them to be in quick, easy to read format so even my idiot boss can understand them (who, when, what account, whether or not a file was added or deleted) - the detailed and technical log can be in a different location and can be tougher to get to.
I also want my IDS to watch traffic within my network for unusual activity and alert me to it - Joe Bookkeeper has no business looking at the blueprints for my latest invention, and Fred Luser doesn't need to be playing Quake on company time, and Gina Lolabridiota has no business putting her boyfriend's pic on the desktop of her workstation (yes, I'm IT Nazi - It's MY Freakin network.)
If the IDS alerts me to such activity, I want the power to stop that user NOW. Full denial of all network access to him, period, with a nasty little note popping up on his desktop telling him what a scumbag he is, to call me, explain why he was doing what he was doing, and maybe if I'm feeling particularly nice and he bribes me accordingly, I MIGHT restore his access rights - or I might have him fired. If such activity is taking place after hours when I'm not at my desk, it should be logged the same way as described previously in this dissertation.
While I'm at it, since I'm daydreaming here - I want my IDS to brew coffee for me and have a fresh cup ready at my desk when I arrive in the morning, be female, redheaded, give good oral sex, and call me Master :D
Any other wishlist stuff y'all would like to add?
-
Hi, i'm designing an IDS for university. Actually more of an IPS. It's based on a layered architecture like this:
netfilter --> modified iptables, libiptc, libipq code --> anomaly detection based IDS
where each layer is more complex (slower, smarter) and less frequently activated than the last. e.g. the system recieves a large spike in SYN packets which are passed up through the layers. According to current network conditions ( kept track of by a dynamic 'normality profile' ) the anomaly detection layer will determine if the increase represents an attack. If so, the system will pass a command back down through the layers to block the source IP at kernel level (netfilter). Note that after the blocking action the malicious packets will be dropped _before_ they get to the IDS layer, thereby not slowing it down. It's great for detecting scans and DoS attacks for this reason.
interested to hear anyones thoughts on this
To answer one of the poster's questions - you must use c or assembly really, and preferably most of it at kernel level. i find anything else is too slow, although i admit i have not tried perl for the text processing bits. btw don't let people tell you not to re-invent the wheel - it needs doing!