public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: "Norman Mark St. Laurent" <mstlaurent@conceras.com>
To: David Flatley <dflatley@us.ibm.com>
Cc: linux-audit@redhat.com
Subject: Re: buffer space
Date: Mon, 17 Aug 2009 11:34:28 -0400	[thread overview]
Message-ID: <4A897884.6030703@conceras.com> (raw)
In-Reply-To: <OF5956BB72.51CBF8D6-ON85257615.004E4644-85257615.005179A7@us.ibm.com>

Hi David,

I too would like to know what version of SECSCAN you are using for the 
"required watches".  I run the STIGS, SECSCAN, and a myriad of 
vulnerability analysis tools (outside looking in -->  inside looking 
around) on systems that I ISSE and provision.  I do not recall "required 
watches" that need to be set with this tool, but I maybe off a version 
and I may need to visit another sight to pick up the latest and greatest....

I know SECSCAN would like the System to be configured to HALT on audit 
failure using the disk_ful_action_setting in /etc/audit/auditd.conf.  It 
would also like the system to be configured to halt on audit disk error 
as well as the audit data to be synchronously flushed to disk to avoid 
data loss.  To do this (respectfully) I have set in my KickStarts and 
Satellite:

perl -npe 's/disk_full_action = SUSPEND/disk_full_action = HALT/' -i 
/etc/audit/auditd.conf
perl -npe 's/disk_error_action = SUSPEND/disk_error_action = HALT/' -i 
/etc/audit/auditd.conf
perl -npe 's/flush = INCREMENTAL/flush = SYNC/' -i /etc/audit/auditd.conf

Currently I set the /var/log/audit logs to rotate daily for 90 days...  
in /etc/logrotate.d/audit  and the capp.rules ; nispom.rules in 
/usr/share/doc/audit* all work great and provide nice examples to comply 
with Security Policy.

Because of the logrotation and the way aureport works, I have written a 
wrapper script to be able to search and report all the log files.  
Something of this type would help the Security Officers look threw the 
log files.  The script also keeps a pristine copy of the log files for 
investigation with digital sigs to watch the tampering  (as well as 
aide) for investigation if need be --> this keeps processing the files 
(MAC Times) and a pristine copy separated.

I am very interested in finding our more about these set watches that 
are required in SECSCAN.

Best regards,


Norman Mark St. Laurent
Conceras | Chief Technology Officer and ISSE



David Flatley wrote:
>
> Thanks Steve!
> If I were to move all the rotated logs to another directory, say 
> /home/logs. So instead of doing "ausearch -i" to capture all the 
> information in the rotated logs in
> /var/log/audit directory. I would do "ausearch -i -f /home/logs" , 
> correct?
>
> Backlog is set to 12288 right now.
>
> The SECSCAN requires many -w (watches) and a fair amount of syscalls. 
> I modified the syscalls to add your recommendation for using 
> "arch=b32" and "arch=b64".
> Because I was getting errors restarting the auditd on some of their 
> recommendations one of which was mount?
>
> Another setting I believe was doing me in was the log size is 20 megs 
> and I allow 8 rotated logs. But I had admin_disk_full set to 160 and 
> the action was suspend.
> So this could have been tripping me up also.
>
> I would like to be able to do the audit log extractions (ausearch and 
> aureport) when I get say 8 - 20 megs logs. I see I can do an exec on a 
> script in max_log_file_action.
> So if I set the max_log_file to 160, I can then run a script to move 
> the rotated logs and process them, thus not stopping auditd and 
> keeping things working? I would set the
> max rotated logs to 10 to allow the new rotated log space then move 
> the logs as you suggest.
>
> Thanks.
>
> David Flatley CISSP
>
>
>
>
> Inactive hide details for Steve Grubb ---08/13/2009 02:29:34 PM---On 
> Thursday 13 August 2009 10:56:50 am David Flatley wrote: > Steve Grubb 
> ---08/13/2009 02:29:34 PM---On Thursday 13 August 2009 10:56:50 am 
> David Flatley wrote: > Red Hat 5.3 running audit 1.7.7-6
>
>
> From: 	
> Steve Grubb <sgrubb@redhat.com>
>
> To: 	
> linux-audit@redhat.com
>
> Cc: 	
> David Flatley/Burlington/IBM@IBMUS
>
> Date: 	
> 08/13/2009 02:29 PM
>
> Subject: 	
> Re: buffer space
>
>
>
>
> On Thursday 13 August 2009 10:56:50 am David Flatley wrote:
> >   Red Hat 5.3 running audit 1.7.7-6
> > Rotating logs at 20 megs and allowing 8 logs
> > Rules have watches and syscalls from the SECSCAN recommendations, 
> and have
> > added some of Steve Grubb's recommendations.
>
> I would be curious what the SECSCAN recommendations are. Never heard 
> of it...
>
>
> > When we extract and archive the audit logs we get "Error receiving audit
> > netlink packet (No buffer space available) an "error sending signal info
> > request"
> > Our extract is: stop auditd then create a file and run ausearch -i > 
> file
> > then run an aureport -i > file then once that is done we delete all the
> > logs and restart auditd.
>
> I think this is your problem. If you have audit rules loaded and stop 
> auditd,
> then audit events are going to pile up in the queue waiting for auditd to
> download them. At some point the kernel will decide auditd doesn't 
> exist and
> will dump all events to syslog. This probably is not what you want either.
>
> I would recommend calling "service auditd rotate" and then grab logs
> audit.log.1 -> audit.logs.7 and move them away to another directory 
> for post  
> processing the contents.
>
> You may also want to check you backlog size settings too.
>
>
> > If I run this manually it works fine but if I have it running it in 
> a cron
> > we get Kernel panics, lockups and log data loss plus the buffer 
> messages.
>
> Shouldn't really make a difference.
>
> -Steve
>
>
> ------------------------------------------------------------------------
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

  parent reply	other threads:[~2009-08-17 15:34 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-13 14:56 buffer space David Flatley
2009-08-13 15:29 ` Matthew Booth
2009-08-13 18:28 ` Steve Grubb
2009-08-17 14:49   ` David Flatley
2009-08-17 15:07     ` Steve Grubb
2009-08-17 15:36       ` Norman Mark St. Laurent
2009-08-17 16:38       ` David Flatley
2009-08-17 16:52         ` LC Bruzenak
2009-08-17 17:06           ` David Flatley
2009-08-17 17:15             ` LC Bruzenak
2009-08-17 17:24               ` LC Bruzenak
2009-08-17 21:18                 ` David Flatley
2009-08-17 17:32               ` David Flatley
2009-08-17 17:46                 ` LC Bruzenak
2009-08-17 18:01                   ` Steve Grubb
2009-08-17 18:13                     ` Norman Mark St. Laurent
2009-08-17 18:14                     ` LC Bruzenak
2009-08-17 18:46                       ` Norman Mark St. Laurent
2009-08-17 19:37                         ` Steve Grubb
2009-08-17 19:46                           ` Norman Mark St. Laurent
2009-08-18 13:02                           ` David Flatley
2009-08-18 15:09                             ` LC Bruzenak
2009-08-18 15:53                               ` Steve Grubb
2009-08-27 17:21                           ` David Flatley
2009-08-27 17:32                             ` Steve Grubb
2009-08-27 17:45                               ` David Flatley
2009-08-27 18:45                                 ` Steve Grubb
2009-08-27 17:33                             ` LC Bruzenak
2009-08-23  4:12       ` D.A. Muran-de Assereto
2009-08-17 15:34     ` Norman Mark St. Laurent [this message]
2009-08-17 16:58       ` Mike Nixon
2009-08-23  4:32         ` David Muran-de Assereto
2009-08-23 16:12           ` Mike Nixon
2009-08-23 20:24             ` David Muran-de Assereto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A897884.6030703@conceras.com \
    --to=mstlaurent@conceras.com \
    --cc=dflatley@us.ibm.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox