From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [RFC] programmatic IDS routing Date: Wed, 19 Mar 2008 14:40:02 -0400 Message-ID: <200803191440.02743.sgrubb@redhat.com> References: <200803191302.48434.sgrubb@redhat.com> <28772.1205949942@turing-police.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <28772.1205949942@turing-police.cc.vt.edu> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Valdis.Kletnieks@vt.edu Cc: Linux Audit List-Id: linux-audit@redhat.com On Wednesday 19 March 2008 14:05:42 Valdis.Kletnieks@vt.edu wrote: > On Wed, 19 Mar 2008 13:02:48 EDT, Steve Grubb said: > > files. In order for the IDS system to be able to distinguish an open of a > > watched file from an open of a *special* watched file that an alert > > should be sent for, I'd like to propose a standard way of alerting the > > IDS that this record needs additional scrutiny. > > Why do we need special handling for something the IDS should be able to do > for itself? Something has to tell the IDS what to do for these 3 particular detections. It could come from a configuration file that it reads, or it could come from the event stream that it reads. Its just a matter of *where* the instructions come from. > If your IDS system doesn't already have a copy of the list of > "special" watched files, you have *bigger* problems. Not really, just think about the advantages of this approach. o You do not need to express host:file relationships if you are checking aggregate logs o You always have a matching audit rule to make sure you get the data you need o The event when recorded to disk has the meaning associated with it in case you wonder why something didn't get classified the way you thought it should o This technique is higher performance since you do not need iterate across a list of all files for each incoming event. o If the target file has a hardlink that is manipulated, the IDS won't be fooled because a different path showed up in the event stream. (This might even come into play for mount tricks that alter paths.) These are the easy ones that I can think up easily. While we are at it, the disadvantages to using the IDS configuration file approach: o The config file will become a mess when you get to this one entry that contains all file names one after another. Or you will have 2 config files one for the options and one for the files. You will of course need 2 more files for the other 2 detections, so now you have 4 config files to setup. o No guarantee that any audit rules exist to give you the events you need. o Lower performance o Uses more system memory o Susceptible to path name tricks o Code will be far more complicated and harder to read or understand due to size. o You have to be very careful to keep aggregate server rules in sync with remote system. -Steve