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.
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?
-Steve