[RFC] programmatic IDS routing

[Linda Knippers]

Steve Grubb wrote:
> Hi,
> 
> In working on the IDS piece of the audit system, there are 3 detections that I 
> need to solve: watched files, watched execution, and making an executable. In 
> this particular case, an admin may have watches and several things for 
> archival purposes, but may want an alert if something changes in specific 
> 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.
> 
> The key field has been in all syscall records for at least 8 kernel releases, 
> so I think it is well established that it could be used by this point. It is 
> 32 char's long. This is longer than what most people will ever need. What I'd 
> like to do is to use this field for 2 purposes. One is to continue using it 
> as is. The other could be to tell the IDS that this record needs review.

Rather than using the key for two purposes and introducing special key
words, couldn't an admin just tell the IDS which he's are of interest?
And what the priority of each one is?

> If a key field starts with "ids-" then we could parse it for a specific set of 
> uses. We need to be able to distinguish: file, exec, and mkexe. Each of these 
> would alert the IDS as to which alert category this fits under. Next, IDMEF 
> has 4 severity ratings: info, low, medium, and high. These could be shortened 
> to: inf, low, med, hi. This means you could tell the IDS that this is an 
> execution attempt that means medium severity by this, "ids-exec-med".
> 
> To continue to be able to use the key field for searching, I would propose 
> just adding a comma to separate the ids part from the searchable part. So, 
> you could do something like this: "ids-file-med,shadow-password". auditctl 
> can be fixed so that when it spots "ids-" in the key field, it will check 
> that only valid types and severities are being used. This would not affect 
> what auditd does in any way.
> 
> Thoughts? Comments?

I think it makes more sense to leave the key alone and introduce
something that optionally associates keys with IDS properties.

-- ljk
> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit