buffer space

Mon Aug 17 16:58:57 UTC 2009

Attached are is the audit.rules file from SECSCN 4.3.  There is a v4.4 now
available but I don't have it handy.  Also attached are two docs which
explain SECSCN's auditd configuration expectations.

-Mike

On Mon, Aug 17, 2009 at 11:34 AM, Norman Mark St. Laurent <
mstlaurent at conceras.com> wrote:

> 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 at redhat.com>
>>
>> To:
>> linux-audit at redhat.com
>>
>> Cc:
>> David Flatley/Burlington/IBM at 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
>>
>
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20090817/6cc02262/attachment.htm>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20090817/6cc02262/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AUDIT.RULES
Type: application/octet-stream
Size: 5598 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20090817/6cc02262/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20090817/6cc02262/attachment-0002.htm>