On Aug 17, 2009, at 12:58 , Mike Nixon wrote:
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
Yeah, the audit.rules that you have there is the test version that I
hacked together more than two years ago as a "first cut".
It includes a lot of stuff which might or might have not been
installed or needed, just on the off chance. The intent there was to
discuss the rules requirements with your certifier, not to take them
as gospel.
That stuff should have been reviewed some time ago. I will be glad to
refer specific concerns or recommended fixes to the current
development team.
Lenny, you should have dropped me a line about this thread. I only
casually monitor this list, and happened upon it by chance.
Dave Muran-de Assereto
On Mon, Aug 17, 2009 at 11:34 AM, Norman Mark St. Laurent <
[email protected]> 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 <[email protected]>
To:
[email protected]
Cc:
David Flatley/Burlington/i...@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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
<AUDIT1.HTML><AUDIT.RULES><AUDITDESCRIP.HTML>--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
David Muran-de Assereto
[email protected]
XML is like violence: if it doesn't solve your problem, you're not
using enough of it.
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
