SEARCHING LOG FILES FOR FAILED ACCESS ATTEMPTS
----------------------------------------------


Some of this information comes from:
http://www.cert.org/security-improvement/implementations/i042.01.html


On Redhat AS 3.0 I needed to add the following
dependencies in order to run swatch:
(detailed in the seminal work Hardening Linux)

TimeDate-1.16.tar.gz
swatch-3.1.tar.gz
File-Tail-0.98.tar
Date-Calc-5.3.tar
Bit-Vector-6.3.tar

Basic steps:

Install swatch and dependencies.
Create a configuration file.
Prepare a separate user id to run swatch as.
Prepare the needed email addresses.
Create a specific startup file for demon or cronjob.
Sit back and let the computer do the work.


-The approach or architecture used to analyze the logs will drive
decisions on how the configuration file looks. One method for using
swatch is as a demon watching or tailing a logfile. An alternative
method that might work best in this case is where a cron job
runs and analzes a log or set of logs. To invoke swatch with a
special configuration file to look at a special logfile would look 
something like:

swatch  --config-file /home/rreck/swatchstuff/testconf.txt   --examine /tmp/audit.log 


The configuration file to detect failed attempts to open a file would look like

watchfor   /return,-13/
           mail=rreck


-A drawback from using swatch to detect lines and email someone is that each hit results
in an email. This means its easy to generate dozens/hundreds of emails fast.

The swatch configuration is not very different from simply grepping the activity out of
the log like (grep is faster than swatch):  

grep "return,-13" /tmp/audit.log >>/tmp/fileperms-report.txt
mail admin@somewhere.com < /tmp/fileperms-report.txt
rm -f /tmp/fileperms-report.txt


Why are we looking for return,-13 ?
Questions by Ron Reck and answers by Leigh Purdie, Director - InterSect Alliance Pty Ltd

RON> My question is what part of the log line indicates
RON> "A failed attempt was made to access the file"
RON> I dont see anything that could be carrying this information ?

LEIGH>Good question. The event is actually composed of two key parts - the
      'objective' bit, which is designed to be human readable, and the 'event'
      bit, which is designed to be processed by a computer.

LEIGH >From a human perspective, the 'objective' bit will include the word
       'failed' if there is a problem - it's an easy visual way of identifying
        things, but not ideal from a follow-on processing perspective. From a
        computers perspective, the best thing to look for is the return code.

LEIGH> On file open successes, the returncode will be non-negative. On file
      open failure, a negative number will be returned, and you can actually
      detect the REASON behind the failure by comparing the number against the
      values in /usr/include/asm/errno.h

LEIGH> In the case of your example above,
     > grep "13" /usr/include/asm/errno.h
     > #define EACCES          13      /* Permission denied */