Re: Use of the audit subsystem

On Wed, 31 May 2006, Derek Tattersall wrote:

> I recently installed the audit code on my current system.  It comes up and 
> works fine, the logs rotate properly and all is copacetic.  Now I would like 
> to develop audit policies for a few typical installations.
>
> 1) Departmental server.  Serves files, mail, web proxies and
>   application proxies.  What are the appropriate events to audit to
>   enhance the IT security in an environment that probably doesn't
>   have an IT staff.
> 2) Workstation.  Used as an application client, with e-mail, web and
>   network services.  Probably has access to printers and file
>   servers.  Is potentially exposed to spam and malware.
> 3) Routers and infrastructure servers.  Provide network services,
>   DHCP, network address translation, routing, PXE, proxies etc.
>   How best to audit this box.
>
> For each of these types of IT provider, we need to monitor activity for 
> security purposes first, and perhaps also for cost accounting. The audit 
> daemon provides records with varying degrees of importance. How should we 
> separate and report so as to achieve the timeliness that we need.
>
> I'm trying to put together a white paper on the use of auditing to 
> complement the excellent installation and operation information in the 
> Handbook.  All suggestions are welcome.

Hmm.  I enthusiastically support the above activities, but unfortunately don't 
have a lot of information likely to be appropriate to the above environments. 
For workstations and servers, the general starting point will be the logging 
of authentication events and exec events, since those provide moderate insight 
into the security context.

Right now, only a limited number of user applications generate 
application-layer audit records -- most records are generated by the kernel, 
and offer accurate but very fine-grained views onto the behavior of the 
application, which can make it hard to see the big picture.  For example, the 
kernel can audit the system calls performed by the login command, but what you 
really want is for login to tell you who logged in.  We've modified login and 
a number of critical system management tools to do this, but you may find that 
other tools, such as Samba, require similar modifications.  In many cases, 
Sun, Apple, or other organizations have already added BSM support to 
applications -- our support in SSH is, in fact, the Sun support, which we just 
turned on, so it may be a question of starting to compile ports or packages 
with audit support that already exists.

An important part of your best practices documentation may be audit reduction 
-- you may find that for a week, you want to keep all file accesses, but after 
one week, you want only to keep login information.  This can be done using the 
auditreduce command line tool, and right now there's not really any practice 
documentation on using it effectively.

Robert N M Watson