question

question

[David Flatley]

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


    If you would indulge my simpler in comparison question of the group. I
am setting up audit
on heavy usage systems. I have setup my auditd.conf to rotate the files
once they get to 70
meg and allow up to 12 rotated files. I created a cron that runs hourly to
look and see if
a ninth rotated file exists and if so run "ausearch -i" outputted to a file
and store the
file, then remove the rotated files. I run the cron to avoid losing data if
there is alot of activity
and rotated files are rolled off. I also have to balance performance with
auditing in this
arrangement.
   My question is: is there a better way to do this?
       Thanks.

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

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

Re: question

[Steve Grubb]

On Friday 31 October 2008 14:21:12 David Flatley wrote:
>     If you would indulge my simpler in comparison question of the group. I
> am setting up audit on heavy usage systems. I have setup my auditd.conf to
> rotate the files once they get to 70 meg and allow up to 12 rotated files.

You don't need to limit the files to 12 unless you are short on disk space. 
you can use keep_logs as the max_log_file option and one will not be lost.


> I created a cron that runs hourly to look and see if a ninth rotated file
> exists and if so run "ausearch -i" outputted to a file and store the
> file,

You shouldn't need to ausearch the file? Are you doing that to split the file 
on a time hack? In that case you can just about as easily do a "service 
auditd rotate" and force auditd to end at a certain time rather than by size.


> then remove the rotated files. I run the cron to avoid losing data if 
> there is alot of activity and rotated files are rolled off. I also have to
> balance performance with auditing in this arrangement.

Perhaps we need the capability of switching out partitions used for logging? 
Maybe that could be solved by using the space left action exec capability to 
run a custom program that re-writes the audit config file or changes a 
symlink to point to another config file to point to a new dir and then sends 
sighup to the parent (auditd).

Maybe some others have ideas about how they solve the same problem. If we need 
to make changes to the audit daemon to make this smoother, let me know what's 
needed.

-Steve

Re: question

[David Flatley]

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

    Thanks for the reply Steve.




On Friday 31 October 2008 14:21:12 David Flatley wrote:
>     If you would indulge my simpler in comparison question of the group.
I
> am setting up audit on heavy usage systems. I have setup my auditd.conf
to
> rotate the files once they get to 70 meg and allow up to 12 rotated
files.

You don't need to limit the files to 12 unless you are short on disk space.

you can use keep_logs as the max_log_file option and one will not be lost.

Disk space is not a problem if the day's logging is collected and stored,
which is required,

> I created a cron that runs hourly to look and see if a ninth rotated file
> exists and if so run "ausearch -i" outputted to a file and store the
> file,

You shouldn't need to ausearch the file? Are you doing that to split the
file
on a time hack? In that case you can just about as easily do a "service
auditd rotate" and force auditd to end at a certain time rather than by
size.

Yes and then I could use ausearch -if <file> when I need to look at the
logs
after they have been moved to storage. Or apply the ausearch -i when I do
the>
storage of the file, I do this to convert from numerical to text on the
file.

> then remove the rotated files. I run the cron to avoid losing data if
> there is alot of activity and rotated files are rolled off. I also have
to
> balance performance with auditing in this arrangement.

Perhaps we need the capability of switching out partitions used for
logging?
Maybe that could be solved by using the space left action exec capability
to
run a custom program that re-writes the audit config file or changes a
symlink to point to another config file to point to a new dir and then
sends
sighup to the parent (auditd).

Maybe some others have ideas about how they solve the same problem. If we
need
to make changes to the audit daemon to make this smoother, let me know
what's
needed.

-Steve

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

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

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

Re: question

[LC Bruzenak]

On Fri, 2008-10-31 at 15:50 -0400, Steve Grubb wrote:
> On Friday 31 October 2008 14:21:12 David Flatley wrote:
> ...
> 
> Perhaps we need the capability of switching out partitions used for logging? 
> Maybe that could be solved by using the space left action exec capability to 
> run a custom program that re-writes the audit config file or changes a 
> symlink to point to another config file to point to a new dir and then sends 
> sighup to the parent (auditd).
> 
> Maybe some others have ideas about how they solve the same problem. If we need 
> to make changes to the audit daemon to make this smoother, let me know what's 
> needed.

David, I will have similar requirements and I've been thinking about
this also. Not sure about you, but my audit data has the following
requirements (and others):
* archive to off-site storage
* restore from archive
* search capabilities (mostly covered in ausearch and audit-viewer)
* robust (cannot lose any data received)
* etc.

Like you, I'm planning a periodic shift. This enables straightforward
time-based restore/search for humans. Ideally, it would be totally
automated, as in:

1: shift auditing to a new R/W partition each month.
2: Make the previous month audit data RO.
3: archive the previous month to tape/DVD
4: put the RO partition back into the "available" queue
5: ensure the current audit is also mirrored over to a big storage area
with all the past data on it.
6: Send an email to the administrator that all the above has
successfully occurred.

Steve, as my testing progresses I'll add comments in this area. I had
thought a cron-activated logrotate on the month would cover this, but it
means 2 admin areas; if there is a way to do it inside the audit
structure, that would be preferable to me. It would simplify/consolidate
the config rpm(s) I create. Anything you could do to help facilitate a
scheme as described above would be welcome.

David, a couple of questions for you:
* Have you looked at the audit-viewer, and do you intend to use this?
* I assume "heavy usage systems" means lots of audit data...are your
rules tuned appropriately? This is critical for me - one over-zealous
rule will add a flood of unhelpful info.
* You mention "balancing performance"  - are you talking about
per-machine or network (via aggregation)? When reading your post I
assumed aggregation from my own perspective but you didn't actually
specify so I thought maybe I should ask. I'm aggregating all audit from
several machines to a single audit machine for
storage/review/adminstration. You?

Thx,
LCB.

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

Re: question

[David Flatley]

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

    Sorry I am in error on the storage question. I do have limited storage
on some of my systems and depending on my rules
and what is running on the systems this could cause an issue. Presently I
am using the S.T.I.G. recommendations but I may
have to use more extensive rules which I am in the process of testing.







Thanks for the reply Steve.

Inactive hide details for Steve Grubb <sgrubb@redhat.com>Steve Grubb
<sgrubb@redhat.com>


On Friday 31 October 2008 14:21:12 David Flatley wrote:
>     If you would indulge my simpler in comparison question of the group.
I
> am setting up audit on heavy usage systems. I have setup my auditd.conf
to
> rotate the files once they get to 70 meg and allow up to 12 rotated
files.

You don't need to limit the files to 12 unless you are short on disk space.

you can use keep_logs as the max_log_file option and one will not be lost.

Disk space is not a problem if the day's logging is collected and stored,
which is required,

> I created a cron that runs hourly to look and see if a ninth rotated file
> exists and if so run "ausearch -i" outputted to a file and store the
> file,

You shouldn't need to ausearch the file? Are you doing that to split the
file
on a time hack? In that case you can just about as easily do a "service
auditd rotate" and force auditd to end at a certain time rather than by
size.

Yes and then I could use ausearch -if <file> when I need to look at the
logs
after they have been moved to storage. Or apply the ausearch -i when I do
the
storage of the file, I do this to convert from numerical to text on the
file.

> then remove the rotated files. I run the cron to avoid losing data if
> there is alot of activity and rotated files are rolled off. I also have
to
> balance performance with auditing in this arrangement.

Perhaps we need the capability of switching out partitions used for
logging?
Maybe that could be solved by using the space left action exec capability
to
run a custom program that re-writes the audit config file or changes a
symlink to point to another config file to point to a new dir and then
sends
sighup to the parent (auditd).

Maybe some others have ideas about how they solve the same problem. If we
need
to make changes to the audit daemon to make this smoother, let me know
what's
needed.

-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

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

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

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

Re: question

[David Flatley]

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








On Fri, 2008-10-31 at 15:50 -0400, Steve Grubb wrote:
>> On Friday 31 October 2008 14:21:12 David Flatley wrote:
> ...
>
>> Perhaps we need the capability of switching out partitions used for
logging?
>> Maybe that could be solved by using the space left action exec
capability to
>> run a custom program that re-writes the audit config file or changes a
>> symlink to point to another config file to point to a new dir and then
sends
>> sighup to the parent (auditd).
>>
>> Maybe some others have ideas about how they solve the same problem. If
we need
>> to make changes to the audit daemon to make this smoother, let me know
what's
>> needed.

>David, I will have similar requirements and I've been thinking about
>this also. Not sure about you, but my audit data has the following
>requirements (and others):
>* archive to off-site storage
>* restore from archive
>* search capabilities (mostly covered in ausearch and audit-viewer)
>* robust (cannot lose any data received)
>* etc.
  Yes my requirements are very similar.

>Like you, I'm planning a periodic shift. This enables straightforward
>time-based restore/search for humans. Ideally, it would be totally
>automated, as in:

>1: shift auditing to a new R/W partition each month.
>2: Make the previous month audit data RO.
>3: archive the previous month to tape/DVD
>4: put the RO partition back into the "available" queue
>5: ensure the current audit is also mirrored over to a big storage area
>with all the past data on it.
>6: Send an email to the administrator that all the above has
>successfully occurred.

>Steve, as my testing progresses I'll add comments in this area. I had
>thought a cron-activated logrotate on the month would cover this, but it
>means 2 admin areas; if there is a way to do it inside the audit
>structure, that would be preferable to me. It would simplify/consolidate
>the config rpm(s) I create. Anything you could do to help facilitate a
>scheme as described above would be welcome.

>David, a couple of questions for you:
>* Have you looked at the audit-viewer, and do you intend to use this?
No, have not looked at it, really would like to use Tivoli compliance
insight manager.
>* I assume "heavy usage systems" means lots of audit data...are your
>rules tuned appropriately? This is critical for me - one over-zealous
>rule will add a flood of unhelpful info.
Yes I am in the process of evaluating rules, using S.T.I.G.
recommendations.

>* You mention "balancing performance"  - are you talking about
>per-machine or network (via aggregation)?
Yes per machine, network is not an issue.

>When reading your post I
>assumed aggregation from my own perspective but you didn't actually
>specify so I thought maybe I should ask. I'm aggregating all audit from
>several machines to a single audit machine for
>storage/review/administration. You?
I remove the logs daily per machine and store them per system.

>Thx,
>LCB.

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

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

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

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

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

Re: question

[Steve Grubb]

On Sunday 02 November 2008 21:42:47 David Flatley wrote:
> Presently I am using the S.T.I.G. recommendations but I may
> have to use more extensive rules which I am in the process of testing.

Are you using the stig.rules from the audit package or something else? If I 
were you, I'd spend some time making sure your rules are tuned. Assuming that 
you have keys on you rules, you can run a key report to see what is causing 
you the most events: aureport --start this-week --key --summary. 

Then you'd want to dig into some of those records and see what kinds of things 
are happening. Assuming you have a key of delete and you wanted to see what 
syscalls are the most often logged:

ausearch --start this-week -k delete --raw | aureport --syscall --summary -i

Assuming that shows unlinkat the most prevalent syscall:

ausearch --start this-week -k delete -sc unlinkat --raw | 
aureport --user --summary -i

And so on until you see what is causing so much logging. This doesn't help 
with the archiving, but could help you get the right audit data recorded.

-Steve

Re: question

[David Flatley]

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



    I am actually using the suggested parameters from the STIG for UNIX
guide. I have searched and found
the stig.rules on the internet and we are going to try them. I also saw the
nispom.rules but apparently they are
for Red hat 5 Kernel 2.6.25 it says in the file?    We are not using keying
but will once we get the stig.rules installed
they appear to be using the -k flag.
    We are using audit 1.0.15 and I see 1.0.16 is on the Red Hat site, is
there a compelling reason to update to the
1.0.16 version of audit?.
     Thanks Steve.



                                                                       
                                                                       
                                                                       
                                                                       




On Sunday 02 November 2008 21:42:47 David Flatley wrote:
> Presently I am using the S.T.I.G. recommendations but I may
> have to use more extensive rules which I am in the process of testing.

Are you using the stig.rules from the audit package or something else? If I

were you, I'd spend some time making sure your rules are tuned. Assuming
that
you have keys on you rules, you can run a key report to see what is causing

you the most events: aureport --start this-week --key --summary.

Then you'd want to dig into some of those records and see what kinds of
things
are happening. Assuming you have a key of delete and you wanted to see what

syscalls are the most often logged:

ausearch --start this-week -k delete --raw | aureport --syscall --summary
-i

Assuming that shows unlinkat the most prevalent syscall:

ausearch --start this-week -k delete -sc unlinkat --raw |
aureport --user --summary -i

And so on until you see what is causing so much logging. This doesn't help
with the archiving, but could help you get the right audit data recorded.

-Steve

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

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

[-- Attachment #1.3: pic28634.gif --]
[-- Type: image/gif, Size: 1255 bytes --]

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

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

Re: question

[Steve Grubb]

On Monday 03 November 2008 12:21:23 David Flatley wrote:
> I am actually using the suggested parameters from the STIG for UNIX
> guide. I have searched and found the stig.rules on the internet and we are
> going to try them. I also saw the nispom.rules but apparently they are
> for Red hat 5 Kernel 2.6.25 it says in the file?

Yes, those rules use some recent kernel functionality in order to cover all 
the requirements. Those recent kernel updates are in the RHEL5 kernels and 
should work. They will take some re-engineeing to get working on RHEL4.


> We are not using keying but will once we get the stig.rules installed
> they appear to be using the -k flag.

On RHEL4, you can only use keys on the file watches. RHEL5 you can use them on 
both syscall and file watches.


>     We are using audit 1.0.15 and I see 1.0.16 is on the Red Hat site, is
> there a compelling reason to update to the
> 1.0.16 version of audit?.

The change log

1.0.16
- Update time handling for ausearch and aureport to add more keywords
- Fix the ausearch on keyword to tolerate records with no key (#402941)
- num_logs option wasn't working right on shifts (#325561)
- In auditd, resume logging on SIGUSR2 (#325561)
- ausearch needed update for escaped acct fields (#353241)
- Fix parsing filterkeys in fs_watch records

So, this has some fixups for using keys.

-Steve