From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Nixon Subject: Re: buffer space Date: Sun, 23 Aug 2009 12:12:27 -0400 Message-ID: References: <200908131428.52924.sgrubb@redhat.com> <4A897884.6030703@conceras.com> <79E985B3-3176-478F-B4F9-D538BC0B33D3@tuad.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1620189165==" Return-path: Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.5]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7NGCfnO006685 for ; Sun, 23 Aug 2009 12:12:41 -0400 Received: from mail-fx0-f221.google.com (mail-fx0-f221.google.com [209.85.220.221]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7NGCUU6029977 for ; Sun, 23 Aug 2009 12:12:31 -0400 Received: by fxm21 with SMTP id 21so1105159fxm.3 for ; Sun, 23 Aug 2009 09:12:30 -0700 (PDT) In-Reply-To: <79E985B3-3176-478F-B4F9-D538BC0B33D3@tuad.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Muran-de Assereto Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1620189165== Content-Type: multipart/alternative; boundary=001517447dc619fde70471d15e86 --001517447dc619fde70471d15e86 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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@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 >>>> >>>> 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 >>>> >>>> >>> -- >>> Linux-audit mailing list >>> Linux-audit@redhat.com >>> https://www.redhat.com/mailman/listinfo/linux-audit >>> >>> -- >> Linux-audit mailing list >> Linux-audit@redhat.com >> https://www.redhat.com/mailman/listinfo/linux-audit >> > > David Muran-de Assereto > dmuran@tuad.org > > XML is like violence: if it doesn't solve your problem, you're not using > enough of it. > > --001517447dc619fde70471d15e86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Unfortunately your 'test version' rules are being used in the produ= ction version releases of SECSCN. =A0As I mentioned before, those rules cam= e from SECSCN version 4.3. Version 4.4 is now available but I strongly susp= ect that the rules are the same in both versions. =A0Even more unfortunate,= many C&A reps demand 'compliance' with SECSCN recommendations = and insist that those rules are implemented exactly as written. =A0My=A0col= leagues=A0and I spend a lot of time, effort and (taxpayer) dollars t= rying to=A0convince certifiers and accreditors that the rules as written ar= e not appropriate for operational systems and must be modified to avoid adv= ersely impacting functionality.

The law of unintended consequences demands that no good deed= goes unpunished. =A0I=A0appreciate=A0whatever work you contributed to deve= loping SECSCN I just wish there was some documentation, from an=A0authorita= tive=A0source, that instructed=A0compliance=A0personnel about the importanc= e 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@tuad.org> wrote:

On Aug 17, 2009, at 12:58 , Mike Nixon wrote:

Attached are is the audit.rules file from SECSCN 4.3. =A0There is a v4.4 no= w
available but I don't have it handy. =A0Also attached are two docs whic= h
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 r= equirements 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@con= ceras.com> wrote:

Hi David,

I too would like to know what version of SECSCAN you are using for the
"required watches". =A0I run the STIGS, SECSCAN, and a myriad of = vulnerability
analysis tools (outside looking in --> =A0inside looking around) on syst= ems
that I ISSE and provision. =A0I 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. =A0It<= br> would also like the system to be configured to halt on audit disk error as<= br> well as the audit data to be synchronously flushed to disk to avoid data loss. =A0To do this (respectfully) I have set in my KickStarts and Satellit= e:

perl -npe 's/disk_full_action =3D SUSPEND/disk_full_action =3D HALT/= 9; -i
/etc/audit/auditd.conf
perl -npe 's/disk_error_action =3D SUSPEND/disk_error_action =3D HALT/&= #39; -i
/etc/audit/auditd.conf
perl -npe 's/flush =3D INCREMENTAL/flush =3D SYNC/' -i /etc/audit/a= uditd.conf

Currently I set the /var/log/audit logs to rotate daily for 90 days... =A0i= n
/etc/logrotate.d/audit =A0and 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. =A0Someth= ing
of this type would help the Security Officers look threw the log files. =A0= The
script also keeps a pristine copy of the log files for investigation with digital sigs to watch the tampering =A0(as well as aide) for investigation = if
need be --> this keeps processing the files (MAC Times) and a pristine c= opy
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=3Db32= " and
"arch=3Db64".
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<= br> 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 <sgru= bb@redhat.com>

To:
linux-audit@red= hat.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:
=A0Red 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 aud= it
netlink packet (No buffer space available) an "error sending signal in= fo
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<= br> 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 exis= t
and
will dump all events to syslog. This probably is not what you want either.<= br>
I would recommend calling "service auditd rotate" and then grab l= ogs
audit.log.1 -> audit.logs.7 and move them away to another directory for<= br> post =A0processing 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@red= hat.com
https://www.redhat.com/mailman/listinfo/linux-audit

<AUDIT1.HTML><AUDIT.RULES><AUDITDESCRIP.HTML>--
David Muran-de Assereto
dmuran@tuad.org
XML is like violence: if it doesn't solve your problem, you're not = using enough of it.


--001517447dc619fde70471d15e86-- --===============1620189165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1620189165==--