buffer space
David Muran-de Assereto
dmuran at tuad.org
Sun Aug 23 20:24:06 UTC 2009
(Top Post, sorry)
I gathered all that from the discussion, although I came to it late,
and am talking to the current developers to see what can be done about
it. I am just as opposed to wasting taxpayers dollars as you are, and
am sorry that SECSCN is being treated the same way as the SRR is
treated in the DoD community.
There is documentation from authoritative sources discussing variances
and custom configurations; all of the IC C&A compliance guidance I am
familiar with covers those points. At least in the DoDIIS and DNI
communities, we routinely accredit systems based on an understanding
of the total risk environment, and in my experience, do not adhere
slavishly to the output of a tool. More to the point, the new NIST
800-53-based process should be even more responsive to your needs
while still ensuring that appropriate security controls are in place.
That, in itself, however, will not fix problems with tools. The "test"
ruleset, especially file watches, was put together based on regulatory
auditing requirements for system configuration files, and purposely
covers all the ones I could think of and had seen on deployed systems.
Generally, if a file is not specifically called out by tool or test
engineer it is not audited; that goes double for files from uncommon
system daemons or servers. Thus, the output was supposed to stimulate
conversation between system developers/integrators and the less-
technical certifiers. In the absence of a qualified test engineer, I
don't really see any other way to do an assessment of the system;
whatever tool is used has to be able to look for things which a
certifier will not know to look for. To reiterate, the intent of
SECSCN is not and was never to produce a Mosaic pronouncement of law.
The SECSCN "code" itself is naive, and should perform more analysis
before uttering pronouncements. This naivete is the direct result of
it being a largely unfunded effort put together to serve a perceived
need. I live in the fervent hope that the C&A community, having
recognized the value of the tool, will make it into a formal program
and fund it.
Dave Muran-de Assereto
Technical Lead
DNI CAT
On Aug 23, 2009, at 12:12 , Mike Nixon wrote:
> Unfortunately your 'test version' rules are being used in the
> production
> version releases of SECSCN. As I mentioned before, those rules came
> from
> SECSCN version 4.3. Version 4.4 is now available but I strongly
> suspect that
> the rules are the same in both versions. Even more unfortunate,
> many C&A
> reps demand 'compliance' with SECSCN recommendations and insist that
> those
> rules are implemented exactly as written. My colleagues and I spend
> a lot
> of time, effort and (*taxpayer*) dollars trying to convince
> certifiers and
> accreditors that the rules as written are not appropriate for
> operational
> systems and must be modified to avoid adversely impacting
> functionality.
> The law of unintended consequences demands that no good deed goes
> unpunished. I appreciate whatever work you contributed to
> developing SECSCN
> I just wish there was some documentation, from an authoritative
> source, that
> instructed compliance personnel about the importance and necessity of
> customized configurations.
>
> -Mike Nixon, CISSP
> LTC Engineering Associates, Inc.
>
> On Sun, Aug 23, 2009 at 12:32 AM, David Muran-de Assereto
> <dmuran at tuad.org>wrote:
>
>>
>> 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 <
>>> 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
>>>>
>>>> <AUDIT1.HTML><AUDIT.RULES><AUDITDESCRIP.HTML>--
>>> Linux-audit mailing list
>>> Linux-audit at redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-audit
>>>
>>
>> David Muran-de Assereto
>> dmuran at tuad.org
>>
>> XML is like violence: if it doesn't solve your problem, you're not
>> using
>> enough of it.
>>
>>
David Muran-de Assereto
dmuran at tuad.org
XML is like violence: if it doesn't solve your problem, you're not
using enough of it.
More information about the Linux-audit
mailing list