buffer space

buffer space

[David Flatley]

[-- Attachment #1.1: Type: text/plain, Size: 1108 bytes --]


  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.
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.
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.
I added "-r 0" to the audit.rules but it does not seem to work. We run a
very similar configuration on Red Hat ES and AS 4 with no problems.
We are testing the subject systems and running a looping regression test
that can fill the audit logs in a little over an hour at the present
settings.
Thoughts or ideas??
 Thanks.

David Flatley CISSP
I.T. Specialist, Managing Consultant
Member: ISC2, ISACA, Center for Internet Security


[-- Attachment #1.2: Type: text/html, Size: 1233 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[Matthew Booth]

On 13/08/09 15:56, 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.
> 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"

Where do you get these messages? Are they in /var/log/messages?

> 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.

You don't want to be stopping auditd. I'd either look harder into the 
command line arguments to ausearch and aureport and combine ussage with 
'service auditd rotate', or use a different collection mechanism.

Also, how are you stopping auditd? Are you using 'service auditd stop'? 
If so, you are losing data because it removes audit rules when it stops. 
If you are using somethine else like SIGSTOP, the kernel is sensitive to 
the audit daemon not being responsive. This is likely to cause problems.

Can you post the exact script you're using?

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

Re: buffer space

[Steve Grubb]

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

Re: buffer space

[David Flatley]

[-- Attachment #1.1.1: Type: text/plain, Size: 4351 bytes --]


   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





                                                                                                                                              
  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


[-- Attachment #1.1.2: Type: text/html, Size: 5586 bytes --]

[-- Attachment #1.2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]

[-- Attachment #1.3: ecblank.gif --]
[-- Type: image/gif, Size: 45 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[Steve Grubb]

On Monday 17 August 2009 10:49:55 am David Flatley wrote:
>  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?

Yes.

> Backlog is set to 12288 right now.

ok

>  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".

Are there any public references to this standard?


> Because I was getting errors restarting the auditd on some of their
> recommendations one of which was mount?

Yes, that is correct. Mount is syscall 165 on x86_64 and 21 on i386.


>  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.

If the partition was 320Mb or smaller, then yes that would be a problem. But I 
also think the fact that its being suspended is sent to syslog.


>   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?

Yes, I think so. But if you are hooking max_log_file action, then you would 
need to send sigusr1 to ppid to get auditd to rotate the log and open another 
one. If you don't, auditd will still have an open descriptor to the file.

-Steve

Re: buffer space

[Norman Mark St. Laurent]

Steve,

I maybe able to get the Red Hat Federal Team a copy of SECSCAN...  If 
Justin and Gunnar do not already have a copy....

Best regards,

Norman Mark St. Laurent
Conceras | Chief Technology Officer and ISSE
Phone:  703-965-4892
Email:  mstlaurent@conceras.com
Web:  http://www.conceras.com

Connect. Collaborate. Conceras.



Steve Grubb wrote:
> On Monday 17 August 2009 10:49:55 am David Flatley wrote:
>   
>>  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?
>>     
>
> Yes.
>
>   
>> Backlog is set to 12288 right now.
>>     
>
> ok
>
>   
>>  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".
>>     
>
> Are there any public references to this standard?
>
>
>   
>> Because I was getting errors restarting the auditd on some of their
>> recommendations one of which was mount?
>>     
>
> Yes, that is correct. Mount is syscall 165 on x86_64 and 21 on i386.
>
>
>   
>>  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.
>>     
>
> If the partition was 320Mb or smaller, then yes that would be a problem. But I 
> also think the fact that its being suspended is sent to syslog.
>
>
>   
>>   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?
>>     
>
> Yes, I think so. But if you are hooking max_log_file action, then you would 
> need to send sigusr1 to ppid to get auditd to rotate the log and open another 
> one. If you don't, auditd will still have an open descriptor to the file.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>   

Re: buffer space

[David Flatley]

[-- Attachment #1.1.1: Type: text/plain, Size: 4740 bytes --]


>> Because I was getting errors restarting the auditd on some of their
>> recommendations one of which was mount?

>Yes, that is correct. Mount is syscall 165 on x86_64 and 21 on i386.
-a exit,always -S mount     fails on auditd restart

>>   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?

>Yes, I think so. But if you are hooking max_log_file action, then you
would
>need to send sigusr1 to ppid to get auditd to rotate the log and open
another
>one. If you don't, auditd will still have an open descriptor to the file.

I am in error, I meant space_left_action because there is an exec for
this.>>
I was going to do the "service auditd rotate" then move all the audit.log.*
to
another directory so that ausearch -i and aureport -i could run on the
logs.
The core for me is to keep audit running while dealing with log
generation..
Our regression test can generate 8 20 meg rotated logs in an hour. So if I
can
get audit to kick off the extraction script at certain points then that
would
fix my situation.

   Thanks.

David Flatley CISSP





                                                                                                                                              
  From:       Steve Grubb <sgrubb@redhat.com>                                                                                                 
                                                                                                                                              
  To:         David Flatley/Burlington/IBM@IBMUS                                                                                              
                                                                                                                                              
  Cc:         linux-audit@redhat.com                                                                                                          
                                                                                                                                              
  Date:       08/17/2009 11:08 AM                                                                                                             
                                                                                                                                              
  Subject:    Re: buffer space                                                                                                                
                                                                                                                                              





On Monday 17 August 2009 10:49:55 am David Flatley wrote:
>  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?

Yes.

> Backlog is set to 12288 right now.

ok

>  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".

Are there any public references to this standard?


> Because I was getting errors restarting the auditd on some of their
> recommendations one of which was mount?

Yes, that is correct. Mount is syscall 165 on x86_64 and 21 on i386.


>  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.

If the partition was 320Mb or smaller, then yes that would be a problem.
But I
also think the fact that its being suspended is sent to syslog.


>   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?

Yes, I think so. But if you are hooking max_log_file action, then you would

need to send sigusr1 to ppid to get auditd to rotate the log and open
another
one. If you don't, auditd will still have an open descriptor to the file.

-Steve


[-- Attachment #1.1.2: Type: text/html, Size: 6228 bytes --]

[-- Attachment #1.2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]

[-- Attachment #1.3: ecblank.gif --]
[-- Type: image/gif, Size: 45 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[LC Bruzenak]

On Mon, 2009-08-17 at 12:38 -0400, David Flatley wrote:\
> 
> I am in error, I meant space_left_action because there is an exec for
> this.
> I was going to do the "service auditd rotate" then move all the
> audit.log.* to
> another directory so that ausearch -i and aureport -i could run on the
> logs. 

David,

I do not think this is entirely accurate.
It is one of my own issues. I am doing the same type thing.
This is necessary on a system with large amounts of audit data (as
aggregated systems tend to be).
I am also moving stuff out of the standard directory.
However, IIUC, the ausearch options will only work on specific files.
If you move the rotated files off to another directory you will lose the
ability to search the directory with a single ausearch command. If there
were a "-id" option (input directory, or similar) which allowed this I
believe it would work better.

Otherwise you could possibly cat the files into one large one, but this
is not optimal IMHO.

Steve recently patched the disk threshold code to auto-reset, which is
nice. You probably want this; it sounds as if we are doing similar
functions. I also have SECSCN issues/mitigations.

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: buffer space

[David Flatley]

[-- Attachment #1.1: Type: text/plain, Size: 126 bytes --]

     Lenny:

  I was going to move the rotated logs into /home/logs and use "ausearch -i
-f /home/logs".


David Flatley CISSP

[-- Attachment #1.2: Type: text/html, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[LC Bruzenak]

On Mon, 2009-08-17 at 13:06 -0400, David Flatley wrote:
> Lenny:
> 
> I was going to move the rotated logs into /home/logs and use "ausearch
> -i -f /home/logs".
> 
> 
> David Flatley CISSP
> 
> 

David,

It won't work like that; exactly the issue I described:

[root@slim root]# mkdir logs-test
[root@slim root]# cd !$
cd logs-test
[root@slim logs-test]# auditctl -m "TEST message"
[root@slim logs-test]# service auditd rotate
Rotating logs:                                             [  OK  ]
[root@slim logs-test]# cp /var/log/audit/audit.log.1 .
[root@slim logs-test]# ausearch -i -f `pwd` -m USER
<no matches>
[root@slim logs-test]# grep TEST audit.log.1
node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191
uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message:
exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18 res=success)'


LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: buffer space

[LC Bruzenak]

On Mon, 2009-08-17 at 12:15 -0500, LC Bruzenak wrote:
> On Mon, 2009-08-17 at 13:06 -0400, David Flatley wrote:
> > Lenny:
> > 
> > I was going to move the rotated logs into /home/logs and use "ausearch
> > -i -f /home/logs".
> > 
> > 
> > David Flatley CISSP
> > 
> > 
> 
> David,
> 
> It won't work like that; exactly the issue I described:
> 
> [root@slim root]# mkdir logs-test
> [root@slim root]# cd !$
> cd logs-test
> [root@slim logs-test]# auditctl -m "TEST message"
> [root@slim logs-test]# service auditd rotate
> Rotating logs:                                             [  OK  ]
> [root@slim logs-test]# cp /var/log/audit/audit.log.1 .
> [root@slim logs-test]# ausearch -i -f `pwd` -m USER
> <no matches>
> [root@slim logs-test]# grep TEST audit.log.1
> node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191
> uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message:
> exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18 res=success)'
> 
> 
> LCB.
> 

David,

I should have been more diligent. The input switch was supposed to be
"-if" IIUC. The "-f" switch is looking for a filename inside the record.

[root@slim logs-test]# ausearch -i -if `pwd` -m USER
<no matches>

[root@slim logs-test]# ausearch -i -if `pwd`/audit.log.1  -m USER
...
----
node=slim type=USER msg=audit(08/17/2009 12:10:52.265:305135) : user
pid=8191 uid=root auid=lcb ses=4172 subj=user_u:user_r:user_t:s0
msg='TEST message: exe=/sbin/auditctl (hostname=?, addr=?,
terminal=pts/18 res=success)' 
...

This is what you want to do right - search inside a directory other
than /var/log/audit with multiple audit logs inside the directory?

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: buffer space

[David Flatley]

[-- Attachment #1.1: Type: text/plain, Size: 2160 bytes --]

On Mon, 2009-08-17 at 12:15 -0500, LC Bruzenak wrote:
> On Mon, 2009-08-17 at 13:06 -0400, David Flatley wrote:
> > Lenny:
> >
> > I was going to move the rotated logs into /home/logs and use "ausearch
> > -i -f /home/logs".
> >
> >
> > David Flatley CISSP
> >
> >
>
> David,
>
> It won't work like that; exactly the issue I described:
>
> [root@slim root]# mkdir logs-test
> [root@slim root]# cd !$
> cd logs-test
> [root@slim logs-test]# auditctl -m "TEST message"
> [root@slim logs-test]# service auditd rotate
> Rotating logs:                                             [  OK  ]
> [root@slim logs-test]# cp /var/log/audit/audit.log.1 .
> [root@slim logs-test]# ausearch -i -f `pwd` -m USER
> <no matches>
> [root@slim logs-test]# grep TEST audit.log.1
> node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191
> uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message:
> exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18 res=success)'
>
>
> LCB.
>

David,

I should have been more diligent. The input switch was supposed to be
"-if" IIUC. The "-f" switch is looking for a filename inside the record.

[root@slim logs-test]# ausearch -i -if `pwd` -m USER
<no matches>

[root@slim logs-test]# ausearch -i -if `pwd`/audit.log.1  -m USER
...
----
node=slim type=USER msg=audit(08/17/2009 12:10:52.265:305135) : user
pid=8191 uid=root auid=lcb ses=4172 subj=user_u:user_r:user_t:s0
msg='TEST message: exe=/sbin/auditctl (hostname=?, addr=?,
terminal=pts/18 res=success)'
...

This is what you want to do right - search inside a directory other
than /var/log/audit with multiple audit logs inside the directory?

LCB.

   Yes but not search for anything specific. Actually all I want to do is
convert the
logs from kernel text to regular notation (ausearch -i) to start with. I
like Steve's
idea of doing "service auditd rotate", then moving all the rotated logs to
another
directory to run the "ausearch -i" on the logs. This way auditd can keep
running and
processing the logs does not effect auditd. So what you did is pretty much
what I want
to do with the -if instead of just the -f.
  Thanks Lenny!


David Flatley CISSP

[-- Attachment #1.2: Type: text/html, Size: 2890 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[David Flatley]

[-- Attachment #1.1.1: Type: text/plain, Size: 4114 bytes --]


>> Lenny:
>>
>> I was going to move the rotated logs into /home/logs and use "ausearch
>> -i -f /home/logs".
>>
>>
>> David Flatley CISSP
>>
>>

>David,
>
>It won't work like that; exactly the issue I described:
>
>[root@slim root]# mkdir logs-test
>[root@slim root]# cd !$
>cd logs-test
>[root@slim logs-test]# auditctl -m "TEST message"
>[root@slim logs-test]# service auditd rotate
>Rotating logs:                                             [  OK  ]
>[root@slim logs-test]# cp /var/log/audit/audit.log.1 .
>[root@slim logs-test]# ausearch -i -f `pwd` -m USER
><no matches>
>[root@slim logs-test]# grep TEST audit.log.1
>node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191
>uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message:
>exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18 res=success)'
>
>
>LCB.

  UGH this is a wrench in the works...
  I was hoping to grab all the rotated logs, process them while still
allowing audit
to run with no interruptions. Problem I run into is I run ausearch -i
> /tmp/file and then
do ausearch -i /nfs/file with auditd stopped, then compare files and if
they are the same in
size then delete the /tmp/file. I do this to make sure I get the log in the
nfs archive directory
and the /tmp is a backup if there is a problem. If audit is running there
is no way the files will
be equal in size while processing the /var/log/audit data in two different
intervals.

  Thanks for feedback on this Lenny.


David Flatley CISSP




                                                                                                                                              
  From:       LC Bruzenak <lenny@magitekltd.com>                                                                                              
                                                                                                                                              
  To:         David Flatley/Burlington/IBM@IBMUS                                                                                              
                                                                                                                                              
  Cc:         linux-audit@redhat.com, Steve Grubb <sgrubb@redhat.com>                                                                         
                                                                                                                                              
  Date:       08/17/2009 01:16 PM                                                                                                             
                                                                                                                                              
  Subject:    Re: buffer space                                                                                                                
                                                                                                                                              






On Mon, 2009-08-17 at 13:06 -0400, David Flatley wrote:
> Lenny:
>
> I was going to move the rotated logs into /home/logs and use "ausearch
> -i -f /home/logs".
>
>
> David Flatley CISSP
>
>

David,

It won't work like that; exactly the issue I described:

[root@slim root]# mkdir logs-test
[root@slim root]# cd !$
cd logs-test
[root@slim logs-test]# auditctl -m "TEST message"
[root@slim logs-test]# service auditd rotate
Rotating logs:                                             [  OK  ]
[root@slim logs-test]# cp /var/log/audit/audit.log.1 .
[root@slim logs-test]# ausearch -i -f `pwd` -m USER
<no matches>
[root@slim logs-test]# grep TEST audit.log.1
node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191
uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message:
exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18 res=success)'


LCB.

--
LC (Lenny) Bruzenak
lenny@magitekltd.com



[-- Attachment #1.1.2: Type: text/html, Size: 5915 bytes --]

[-- Attachment #1.2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]

[-- Attachment #1.3: ecblank.gif --]
[-- Type: image/gif, Size: 45 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[LC Bruzenak]

On Mon, 2009-08-17 at 13:32 -0400, David Flatley wrote:
> >> Lenny:
> >> 
> >> I was going to move the rotated logs into /home/logs and use
> "ausearch
> >> -i -f /home/logs".
> >> 
> >> 
> >> David Flatley CISSP
> >> 
> >> 
> 
> >David,
> >
> >It won't work like that; exactly the issue I described:
> >
> >[root@slim root]# mkdir logs-test
> >[root@slim root]# cd !$
> >cd logs-test
> >[root@slim logs-test]# auditctl -m "TEST message"
> >[root@slim logs-test]# service auditd rotate
> >Rotating logs:                                             [  OK  ]
> >[root@slim logs-test]# cp /var/log/audit/audit.log.1 .
> >[root@slim logs-test]# ausearch -i -f `pwd` -m USER
> ><no matches>
> >[root@slim logs-test]# grep TEST audit.log.1
> >node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191
> >uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST
> message:
> >exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18
> res=success)'
> >
> >
> >LCB.
> 
>   UGH this is a wrench in the works...
>   I was hoping to grab all the rotated logs, process them while still
> allowing audit
> to run with no interruptions. Problem I run into is I run ausearch -i
> > /tmp/file and then
> do ausearch -i /nfs/file with auditd stopped, then compare files and
> if they are the same in 
> size then delete the /tmp/file. I do this to make sure I get the log
> in the nfs archive directory 
> and the /tmp is a backup if there is a problem. If audit is running
> there is no way the files will 
> be equal in size while processing the /var/log/audit data in two
> different intervals.

It's a problem for me too.
I was thinking about just patching the ausearch code to behave as
desired...but hoping Steve beat me to it so there was a greatly reduced
chance of bad code...
:)

As for the archive issue, what I am planning is to make a snapshot of my
current audit log directory (technically the partition on which this
lives; that's another SECSCN issue), then rsync the snapshot over to a
backup server (via crossover network connection) and finally release the
snap mount. Then I do not have to compare file sizes ... and really the
size is only one indicator of correctness. You'd probably need a
checksum activity.

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: buffer space

[Steve Grubb]

On Monday 17 August 2009 01:46:03 pm LC Bruzenak wrote:
> >   UGH this is a wrench in the works...
> >   I was hoping to grab all the rotated logs, process them while still
> > allowing audit
> > to run with no interruptions. Problem I run into is I run ausearch -i
> >
> > > /tmp/file and then
> >
> > do ausearch -i /nfs/file with auditd stopped, then compare files and
> > if they are the same in
> > size then delete the /tmp/file. I do this to make sure I get the log
> > in the nfs archive directory
> > and the /tmp is a backup if there is a problem. If audit is running
> > there is no way the files will
> > be equal in size while processing the /var/log/audit data in two
> > different intervals.
>
> It's a problem for me too.
> I was thinking about just patching the ausearch code to behave as
> desired...but hoping Steve beat me to it so there was a greatly reduced
> chance of bad code...

#cat `ls /var/log/audit/a* | sort -r` | ausearch -i
#cat `ls /var/log/audit/a* | sort -r` | aureport

cat can open more than one file at a time,

-Steve

Re: buffer space

[Norman Mark St. Laurent]

cat --> zcat  for the gzip files...  THANKS Steve...  Very Nice....

Norman Mark St. Laurent
Conceras | Chief Technology Officer and ISSE
Phone:  703-965-4892
Email:  mstlaurent@conceras.com
Web:  http://www.conceras.com

Connect. Collaborate. Conceras.



Steve Grubb wrote:
> On Monday 17 August 2009 01:46:03 pm LC Bruzenak wrote:
>   
>>>   UGH this is a wrench in the works...
>>>   I was hoping to grab all the rotated logs, process them while still
>>> allowing audit
>>> to run with no interruptions. Problem I run into is I run ausearch -i
>>>
>>>       
>>>> /tmp/file and then
>>>>         
>>> do ausearch -i /nfs/file with auditd stopped, then compare files and
>>> if they are the same in
>>> size then delete the /tmp/file. I do this to make sure I get the log
>>> in the nfs archive directory
>>> and the /tmp is a backup if there is a problem. If audit is running
>>> there is no way the files will
>>> be equal in size while processing the /var/log/audit data in two
>>> different intervals.
>>>       
>> It's a problem for me too.
>> I was thinking about just patching the ausearch code to behave as
>> desired...but hoping Steve beat me to it so there was a greatly reduced
>> chance of bad code...
>>     
>
> #cat `ls /var/log/audit/a* | sort -r` | ausearch -i
> #cat `ls /var/log/audit/a* | sort -r` | aureport
>
> cat can open more than one file at a time,
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>   

Re: buffer space

[LC Bruzenak]

On Mon, 2009-08-17 at 14:01 -0400, Steve Grubb wrote:
> 
> > It's a problem for me too.
> > I was thinking about just patching the ausearch code to behave as
> > desired...but hoping Steve beat me to it so there was a greatly
> reduced
> > chance of bad code...
> 
> #cat `ls /var/log/audit/a* | sort -r` | ausearch -i
> #cat `ls /var/log/audit/a* | sort -r` | aureport
> 
> cat can open more than one file at a time,
> 
> -Steve

Told you so!
:)

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: buffer space

[Norman Mark St. Laurent]

Depending if you are using logrotate.d/audit  and how it numbers the 
files as it rotates... 

audit.log.1.gz
audit.log.2.gz
...
audit.log.89.gz
audit.log.90.gz

The sort below will but the list in exact order....

zcat `ls /var/log/audit/*.gz | sort -t. --key=3,2n` | ausearch -i

Thank u Steve...

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

Web:  http://www.conceras.com

Connect. Collaborate. Conceras.



LC Bruzenak wrote:
> On Mon, 2009-08-17 at 14:01 -0400, Steve Grubb wrote:
>   
>>> It's a problem for me too.
>>> I was thinking about just patching the ausearch code to behave as
>>> desired...but hoping Steve beat me to it so there was a greatly
>>>       
>> reduced
>>     
>>> chance of bad code...
>>>       
>> #cat `ls /var/log/audit/a* | sort -r` | ausearch -i
>> #cat `ls /var/log/audit/a* | sort -r` | aureport
>>
>> cat can open more than one file at a time,
>>
>> -Steve
>>     
>
> Told you so!
> :)
>
> LCB.
>
>   

Re: buffer space

[Steve Grubb]

On Monday 17 August 2009 02:46:30 pm Norman Mark St. Laurent wrote:
> Depending if you are using logrotate.d/audit  and how it numbers the
> files as it rotates...
>
> audit.log.1.gz
> audit.log.2.gz
> ...
> audit.log.89.gz
> audit.log.90.gz
>
> The sort below will but the list in exact order....
>
> zcat `ls /var/log/audit/*.gz | sort -t. --key=3,2n` | ausearch -i

For this to work right, it has to be in descending order. So, add a -r to the 
sort command.

-Steve

Re: buffer space

[Norman Mark St. Laurent]

Ok,

For some reason sort -r will not work with sort -t. --key=3,2n options

I tried:

sort -r -t. --key=3,2n
sort -t. -r --key=3,2n
sort -t. --key=3,2n -r

But....

zcat `ls /var/log/audit/*.gz | sort -t. --key=3,2n` | tac | ausearch -i

works like a champ.  Gotta luv linux..

Thnks..


Norman Mark St. Laurent
Conceras | Chief Technology Officer and ISSE
Phone:  703-965-4892
Email:  mstlaurent@conceras.com
Web:  http://www.conceras.com

Connect. Collaborate. Conceras.



Steve Grubb wrote:
> On Monday 17 August 2009 02:46:30 pm Norman Mark St. Laurent wrote:
>   
>> Depending if you are using logrotate.d/audit  and how it numbers the
>> files as it rotates...
>>
>> audit.log.1.gz
>> audit.log.2.gz
>> ...
>> audit.log.89.gz
>> audit.log.90.gz
>>
>> The sort below will but the list in exact order....
>>
>> zcat `ls /var/log/audit/*.gz | sort -t. --key=3,2n` | ausearch -i
>>     
>
> For this to work right, it has to be in descending order. So, add a -r to the 
> sort command.
>
> -Steve
>
>
>   

Re: buffer space

[David Flatley]

[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]

   When I do "service auditd rotate"  I am getting in the /var/log/messages
the following:

Error receiving audit netlink packet (No buffer space available)
Error sending signal_info request (No buffer space available)

  At the same time I am running a regression test that is generating 20 meg
audit logs every six to eight minutes.

 Is this a concern?

David Flatley

[-- Attachment #1.2: Type: text/html, Size: 453 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[LC Bruzenak]

On Tue, 2009-08-18 at 09:02 -0400, David Flatley wrote:
> When I do "service auditd rotate" I am getting in
> the /var/log/messages the following:
> 
> Error receiving audit netlink packet (No buffer space available)
> Error sending signal_info request (No buffer space available) 
> 
> At the same time I am running a regression test that is generating 20
> meg audit logs every six to eight minutes.
> 
> Is this a concern?
> 
> David Flatley 
> 

David,

What I believe is happening is that you are generating an abnormal
amount of audit data in your regression test. That's OK, but I think
when you do the rotate the auditd suspends disk writes while it waits
for the rotate to complete. 

IIRC, the rotate starts with the highest number log, rolls it to the
next higher number. Then it decrements the counter and repeats. So
log.13->log.14, then log.12->log.13, etc., and eventually moves
audit.log to audit.log.1. Then a new audit.log is created and the flow
resumes.

While this happens, you are stacking up events from the kernel and
eventually run out of space. On some machines where the log files are in
the hundreds (I had around 300) I have seen the rotate take an
appreciable amount of time.

So you are probably dropping events when you get the above messages and
I guess that is for you to decide if you are concerned about this for
the duration of the test.

This sounds like an instance of where you know that some application
will generate huge amounts of AVC data you do not want to see in the
logs, and ideally you would block those events with a rule. However,
last week I believe, Steve noted that under the current kernel code (and
probably auditctl rules) you cannot selectively exclude AVCs.

LCB.
-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: buffer space

[Steve Grubb]

On Tuesday 18 August 2009 11:09:58 am LC Bruzenak wrote:
> On Tue, 2009-08-18 at 09:02 -0400, David Flatley wrote:
> > When I do "service auditd rotate" I am getting in
> > the /var/log/messages the following:
> >
> > Error receiving audit netlink packet (No buffer space available)
> > Error sending signal_info request (No buffer space available)
> >
> > At the same time I am running a regression test that is generating 20
> > meg audit logs every six to eight minutes.
> >
> > Is this a concern?

It sounds like you have a system that is auditing a lot of data. Since you are 
doing regression testing, I would not be too concerned. But in general, you 
can increase the priority boost for auditd and see if it gets more time slots 
to drain the queue, make the log files larger, but fewer of them so rotate is 
faster, increase the backlog buffer some more, or adjust what you are auditing.


> What I believe is happening is that you are generating an abnormal
> amount of audit data in your regression test. That's OK, but I think
> when you do the rotate the auditd suspends disk writes while it waits
> for the rotate to complete.
>
> IIRC, the rotate starts with the highest number log, rolls it to the
> next higher number. Then it decrements the counter and repeats. So
> log.13->log.14, then log.12->log.13, etc., and eventually moves
> audit.log to audit.log.1. Then a new audit.log is created and the flow
> resumes.
>
> While this happens, you are stacking up events from the kernel and
> eventually run out of space. On some machines where the log files are in
> the hundreds (I had around 300) I have seen the rotate take an
> appreciable amount of time.

This is true.

But having looked at the audit requirements and the given/suggested rules, 
they are badly in need of correction. I would say those audit rules is the 
root cause of the problem.

-Steve

Re: buffer space

[David Flatley]

[-- Attachment #1.1: Type: text/plain, Size: 283 bytes --]

   When auditd starts and reports an error on a line in the audit.rules,
does auditd continue to run with the rest of the rules?
Or does auditd stop waiting for a correction to the rules file? An example
would be on syscalls for fchown32 or umount.
    Thanks.


David Flatley CISSP

[-- Attachment #1.2: Type: text/html, Size: 343 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[Steve Grubb]

On Thursday 27 August 2009 01:21:43 pm David Flatley wrote:
>    When auditd starts and reports an error on a line in the audit.rules,
> does auditd continue to run with the rest of the rules?
> Or does auditd stop waiting for a correction to the rules file?

It depends on whether or not its processed a "-i" directive in the rules. If 
not, it stops. If so, it continues.

-Steve

Re: buffer space

[David Flatley]

[-- Attachment #1.1.1: Type: text/plain, Size: 1305 bytes --]


      Can you give me an example of the use of -i
          Thanks.

David Flatley CISSP


                                                                       
  From:       Steve Grubb <sgrubb@redhat.com>                          
                                                                       
  To:         David Flatley/Burlington/IBM@IBMUS                       
                                                                       
  Cc:         linux-audit@redhat.com                                   
                                                                       
  Date:       08/27/2009 01:32 PM                                      
                                                                       
  Subject:    Re: buffer space                                         
                                                                       





On Thursday 27 August 2009 01:21:43 pm David Flatley wrote:
>    When auditd starts and reports an error on a line in the audit.rules,
> does auditd continue to run with the rest of the rules?
> Or does auditd stop waiting for a correction to the rules file?

It depends on whether or not its processed a "-i" directive in the rules.
If
not, it stops. If so, it continues.

-Steve


[-- Attachment #1.1.2: Type: text/html, Size: 3067 bytes --]

[-- Attachment #1.2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]

[-- Attachment #1.3: ecblank.gif --]
[-- Type: image/gif, Size: 45 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[Steve Grubb]

On Thursday 27 August 2009 01:45:06 pm David Flatley wrote:
>   Can you give me an example of the use of -i

## First rule - delete all
-D

## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192

## Set failure mode to panic
-f 2

## Ignore any errors and keep loading
-i

....

Re: buffer space

[LC Bruzenak]

On Thu, 2009-08-27 at 13:21 -0400, David Flatley wrote:
> When auditd starts and reports an error on a line in the audit.rules,
> does auditd continue to run with the rest of the rules?
> Or does auditd stop waiting for a correction to the rules file? An
> example would be on syscalls for fchown32 or umount. 
> Thanks.
> 
> 
> David Flatley CISSP
> 

David,

You can always run "sudo auditctl -l" to see which ones are loaded.

LCB.
-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: buffer space

[D.A. Muran-de Assereto]

Quoting Steve Grubb <sgrubb@redhat.com>:

> On Monday 17 August 2009 10:49:55 am David Flatley wrote:
<snip>
>>  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".
>
> Are there any public references to this standard?
No, there are not. The SECSCN Linux audit checking module was  
something I hacked together in a vacuum a couple of years ago. The  
"theory" was to try to satisfy DCID 6/3 auditing requirements at the  
time. Not sure if the code has been modified since then; it was a  
"best guess, first cut" standard at the time. I am checking with the  
current development team to see if they've made any significant  
changes since then.


Dave Muran-de Assereto

Re: buffer space

[Norman Mark St. Laurent]

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

Re: buffer space

[Mike Nixon]

[-- Attachment #1.1: Type: text/plain, Size: 6037 bytes --]

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@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@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
>>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>

[-- Attachment #1.2: Type: text/html, Size: 7364 bytes --]

[-- Attachment #2: AUDIT1.HTML --]
[-- Type: text/html, Size: 6262 bytes --]

[-- Attachment #3: AUDIT.RULES --]
[-- Type: application/octet-stream, Size: 5598 bytes --]

##
## This file contains a sample audit configuration.  The rules can be
## copied and pasted into your audit.rules file usually located in the
## /etc/audit/ directory. 
## Note: All settings should be tested on a non-production system prior
## to implementation on any production system.

## Remove any existing rules
-D

## Increase buffer size to handle the increased number of messages.
## Feel free to increase this if the machine panic's
-b 8192

## Set failure mode to panic
-f 2

## Operations on file system objects - by default, only monitor
## files and directories covered by filesystem watches.

## Changes in ownership and permissions
-a entry,always -S chmod -S fchmod -S chown -S fchown -S lchown
## Enable *32 rules if you are running on i386 or s390
## Do not use for x86_64, ia64, ppc, ppc64, or s390x
#-a entry,always -S fchown32
#-a entry,always -S chown32
#-a entry,always -S lchown32

## File content modification. Permissions are checked at open time,
## monitoring individual read/write calls is not useful.
#-a entry,always -S creat -S open -S truncate -S ftruncate
## Enable *64 rules if you are running on i386, ppc, ppc64, s390
## Do not use for x86_64, ia64, or s390x
#-a entry,always -S truncate64
#-a entry,always -S ftruncate64

##Unauthorized access attempts to files (unsuccessful). Use b64 for 64 bit architecture
-a exit,always arch=b32 -S creat -S open -S truncate -S ftruncate -F exit=-EACCES -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access

#-a exit,always arch=b64 -S creat -S open -S truncate -S ftruncate -F exit=-EACCES -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access


## directory operations
-a entry,always -S mkdir -S rmdir

## moving, removing, and linking
-a entry,always -S unlink -S rename -S link -S symlink

## special files
-a entry,always -S mknod

## Other file system operations
-a entry,always -S mount
## Enable umount rule if you are running on i386,ppc,ppc64,s390,s390x,ia64
## Do not use for x86_64
-a entry,always -S umount
## Enable umount rule if you are running on i386,ppc,ppc64,s390,s390x,ia64
## Do not use for ia64
#-a entry,always -S umount2

## success and failure of binding user security attributes to a subject
##
## Enable if you are interested in these events
##
-a entry,always -S clone
-a entry,always -S fork
-a entry,always -S vfork
## For ia64 architecture, disable fork and vfork rules above, and
## enable the following:
#-a entry,always -S clone2

##
## modifications of the default setting of permissive or restrictive
## rules, all modifications of the initial value of security attributes
##
## Enable if you are interested in these events
##
-a entry,always -S umask

##
## changes to the time
##
-a entry,always -S adjtimex -S settimeofday

##Recommended File System watches. Please add any other sensitive files and 
##directories to this list.

##
## successful and unsuccessful attempts to read information from the
## audit records; all modifications to the audit trail
##
-w /var/log/audit/ -k LOG_audit
-w /var/log/audit/audit_log -k LOG_audit_log
-w /var/log/audit/audit_log.1 -k LOG_audit_log
-w /var/log/audit/audit_log.2 -k LOG_audit_log
-w /var/log/audit/audit_log.3 -k LOG_audit_log
-w /var/log/audit/audit_log.4 -k LOG_audit_log

## 
## modifications to audit configuration that occur while the audit
## collection functions are operating; all modications to the set of
## audited events
##
-w /etc/audit/auditd.conf -k CFG_auditd.conf
-w /etc/audit/audit.rules -k CFG_audit.rules
-w /etc/libaudit.conf -p wa -k CFG_libaudit.conf

-w /etc/ntp.conf
-w /etc
-w /var/spool/at
-w /etc/at.allow
-w /etc/at.deny
-w /etc/cron.allow
-w /etc/cron.deny
-w /etc/cron.d/
-w /etc/cron.daily/
-w /etc/cron.hourly/
-w /etc/cron.monthly/
-w /etc/cron.weekly/
-w /etc/crontab
-w /var/spool/cron/root
-w /etc/anacrontab
-w /etc/group
-w /etc/passwd
-w /etc/gshadow
-w /etc/shadow
-w /etc/shadow.OLD
-w /etc/security/opasswd
-w /etc/sudoers
-w /etc/login.defs
-w /etc/securetty
-w /var/log/faillog
-w /var/log/lastlog
-w /etc/shells
-w /etc/profile
-w /etc/bashrc
-w /etc/csh.cshrc
-w /etc/csh.login
-w /etc/hosts
-w /etc/sysconfig/
-w /etc/dhcpd.conf
-w /etc/dhclient-eth0.conf
-w /etc/inittab
-w /etc/rc.d/init.d/
-w /etc/rc.d/init.d/auditd
-w /etc/rc.local
-w /etc/rc.sysinit
-w /etc/xinetd.conf
-w /etc/xinetd.d/
-w /etc/ld.so.conf
-w /etc/ld.so.conf.d/
-w /etc/localtime
-w /etc/sysctl.conf
-w /etc/modprobe.conf
-w /etc/pam.d
-w /etc/pam_smb.conf
-w /etc/aliases
-w /etc/postfix/
-w /etc/mail/access
-w /etc/mail/access.db
-w /etc/mail/aliases
-w /etc/mail/domaintable
-w /etc/mail/domaintable.db
-w /etc/mail/helpfile
-w /etc/mail/local-host-names
-w /etc/mail/mailertable
-w /etc/mail/mailertable.db
-w /etc/mail/Makefile
-w /etc/mail/sendmail.cf
-w /etc/mail/sendmail.mc
-w /etc/mail/submit.cf
-w /etc/mail/submit.mc
-w /etc/mail/trusted-users
-w /etc/mail/virtusertable
-w /etc/mail/virtusertable.db
-w /etc/ssh/sshd_config
-w /etc/stunnel/stunnel.conf
-w /etc/stunnel/stunnel.pem
-w /etc/vsftpd.ftpusers
-w /etc/vsftpd/vsftpd.conf
-w /etc/httpd/conf/
-w /etc/httpd/conf.d/
-w /etc/issue
-w /etc/issue.net
-w /etc/samba/smb.conf
-w /etc/samba/smbpasswd
-w /etc/samba/secrets.tdb
-w /etc/my.conf
-w /etc/syslog.conf
-w /etc/snmp/snmpd.conf
-w /etc/resolv.conf
-w /etc/nsswitch.conf
-w /etc/host.conf
-w /etc/yp.conf
-w /var/yp/binding
-w /etc/ldap.conf
-w /etc/krb5.conf
-w /etc/krb.conf
-w /etc/krb.realms
-w /etc/initlog.conf
-w /etc/default/
-w /etc/firmware/microcode.dat
-w /etc/fstab
-w /etc/auto.master
-w /etc/auto.misc
-w /etc/hosts.allow
-w /etc/hosts.deny
-w /etc/exports

[-- Attachment #4: AUDITDESCRIP.HTML --]
[-- Type: text/html, Size: 5509 bytes --]

[-- Attachment #5: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[David Muran-de Assereto]

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 <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
>>>
>>
>> --
>> Linux-audit mailing list
>> Linux-audit@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
>>
> <AUDIT1.HTML><AUDIT.RULES><AUDITDESCRIP.HTML>--
> 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.

Re: buffer space

[Mike Nixon]

[-- Attachment #1.1: Type: text/plain, Size: 8666 bytes --]

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@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@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@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
>>>>
>>>>
>>> --
>>> Linux-audit mailing list
>>> Linux-audit@redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-audit
>>>
>>>  <AUDIT1.HTML><AUDIT.RULES><AUDITDESCRIP.HTML>--
>> 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.
>
>

[-- Attachment #1.2: Type: text/html, Size: 11136 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: buffer space

[David Muran-de Assereto]

(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@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@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@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
>>>>>
>>>>>
>>>> --
>>>> Linux-audit mailing list
>>>> Linux-audit@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/linux-audit
>>>>
>>>> <AUDIT1.HTML><AUDIT.RULES><AUDITDESCRIP.HTML>--
>>> 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.
>>
>>

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.