On Mon, Apr 02, 2001 at 09:30:32PM -0700, Dan Trainor said sometin like...
> Good evening, all.
>
> Earlier today, I was thinking of all these different IDS packages, and
> how they work. Although I am relatively new to the idea, as well as the
> implementation, I do have a lot of questions, and I do think that most
> of them are worth looking into. One such question was.
>
> I have heard of IDS implementations "adapting" to their surroundings,
> such as network activity, legit user logins, etc etc. Would it be
> possible, over time, to make the IDS "think" that attacks which occur
> very often are normal behavior? With this, the IDS would ease up on or
> just ignore this activity, thinking that the attacks are part of normal
> network traffic. Perhaps the IDS would "forget" what was bad, and what
> wasn't?

The basic premise that most "learning" IDS work on is a ruleset that the deployer creates. For example, in theory what you mentioned may be possible, a system could see repeated attacks and think nothing of them if the deployer also feels the same way; if I were to deploy one on my network with is repeatedly attacked using, say, an RPCBind exploit, I could do one of two things: if I feel confident that my system/network is not vulnerable to these attacks, I could build them into my ruleset. The second possibility is just to leave everything in place as it is, and let the IDS do it's work.

Let me backtrack for minute. When configuring your network or system IDS, such as port sentry for a system, you have the option to tell it some very basic information about your system. For example, in this particular senario, port sentry comes with 3 standard (but customizable) options:

1. "just awareness" - logging of connections to unauthorized ports, but no action is taken and not many ports are defined
2. "standard" - logging of connections to ports, with a few more ports added to the list
3. "advanced" - logging of connections to ports, a long list of them, and using something like ipchains or iptables to then block the attacker from accessing that particular port, or you can change it to block the attacker from connecting to your system at all.

Host Sentry may have been a better example of a true "learning" IDS, but it's not very advanced just yet.

With these 3 options in Port Sentry, you can stick with the standard one or you can define additional ports to be monitered. Going back to my first example of an RPC exploit (port 111), say I repeatedly get attacked because I run a high profile site with RPC running internally, so the port appears to be open when scanned. Although the attack comes regularly, I have already designated that any external connections to this port are bad, and while port sentry is designed to adapt to "regular" traffic, it still will not think this is ok.

In the example of Host Sentry (which detects logon/user anomolies) the ruleset is built while you run are running the tool, it creates a database of all users, how they login (ssh/telnet/ftp, etc), how often they do it and how often they mistype passwords, etc.

If I am repetedly getting connections from an attacker who *thinks* he is using a valid account, (assuming the system disagrees - acct is expired, no longer exists, etc) Host Sentry will not see this as normal. Although it is merely building a database of account access and login attempts, it cross references wih the system on something like this and see's "hey, this guy tries to get in regularly, but no mater how many tries, he's still not allowed!" and then takes appropriate action in keeping him out (adding him to a hosts.deny file, iptables/ipchains blocking, etc).

I hope this has been clear and helps you with your question.

Keep in mind that not all IDS are alike, they have different functions and different uses, and you should make sure you understand HOW and FOR WHAT they are used before you implement them into your system. An imporperly deployed IDS can cause severe disabilities in your network.

--
Bram Shirani
TricareSW (bram.shiranitricaresw.af.mil)
Network/Security Administrator

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]