New to audit. Need help configuring audit to meet NISPOM req's

New to audit. Need help configuring audit to meet NISPOM req's

[Fields, Randy (Space Technology)]

Hello All,
I'm a linux administrator and computer security rep with a small NIS domain all running RHEL 4.4 ES on x86 platforms. 
I'm looking for any help, scripts, or just copies of configuration files so that I can learn from your examples while studying the man pages.

Here are the list of items that I need to accomplish and I greatly appreciate any help that you can provide.
1) I need to configure a test box to meet NISPOM audit requirements. (any examples of /etc/auditd.conf and /etc/audit.rules would be great)
2) Then test it by acting as a user and trying to access files such as /etc/passwd and /etc/shadow.
3) Then report that data to prove to auditors that the tool is collecting the events.

Thank you in advance. Feel free to e-mail me directly to avoid any unwanted cluttering of the message boards.
Randy Fields
randy.fields@ngc.com 

Re: New to audit. Need help configuring audit to meet NISPOM req's

[Steve Grubb]

On Tuesday 27 February 2007 03:25:18 Fields, Randy (Space Technology) wrote:
> Here are the list of items that I need to accomplish and I greatly
> appreciate any help that you can provide. 1) I need to configure a test box
> to meet NISPOM audit requirements. (any examples of /etc/auditd.conf and
> /etc/audit.rules would be great) 2) Then test it by acting as a user and
> trying to access files such as /etc/passwd and /etc/shadow. 3) Then report
> that data to prove to auditors that the tool is collecting the events.

I'd like to include a generic NISPOM configuration in the next set of audit 
packages. Can anyone share some of their contents? I could take a guess at 
it, but would rather have something that has gone through review. I am not 
wanting your site sensitive file locations, but generally this:

1) any syscall auditing you turned on
2) any files you needed to audit in /etc that are not site sensitive
3) any files in /var that needed to audit.

I think all other pieces of the audit system are embedded in the appropriate 
utilities so audit message generation is automatic. The report tool created 
to meet NISPOM is aureport.

Send it to me privately if you do not want your email address public. I would 
appreciate the help...and so would other people in the linux-audit community.

Thanks,
-Steve

RE: New to audit. Need help configuring audit to meet NISPOM req's

[Johnston Mark (UK)]

Hey guys,

Is there a place where I can get all the supported syscalls for audit
version 1.2.9-6.4. There are a couple of things that I'm trying to do
like watching for the shutdown and init command (looking for system
reboots), and looking for changes to the date (I've got the time part).

Thanks
Mark

-----Original Message-----
From: linux-audit-bounces@redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: 28 February 2007 03:01
To: linux-audit@redhat.com
Subject: Re: New to audit. Need help configuring audit to meet NISPOM
req's

On Tuesday 27 February 2007 03:25:18 Fields, Randy (Space Technology)
wrote:
> Here are the list of items that I need to accomplish and I greatly
> appreciate any help that you can provide. 1) I need to configure a
test box
> to meet NISPOM audit requirements. (any examples of /etc/auditd.conf
and
> /etc/audit.rules would be great) 2) Then test it by acting as a user
and
> trying to access files such as /etc/passwd and /etc/shadow. 3) Then
report
> that data to prove to auditors that the tool is collecting the events.

I'd like to include a generic NISPOM configuration in the next set of
audit 
packages. Can anyone share some of their contents? I could take a guess
at 
it, but would rather have something that has gone through review. I am
not 
wanting your site sensitive file locations, but generally this:

1) any syscall auditing you turned on
2) any files you needed to audit in /etc that are not site sensitive
3) any files in /var that needed to audit.

I think all other pieces of the audit system are embedded in the
appropriate 
utilities so audit message generation is automatic. The report tool
created 
to meet NISPOM is aureport.

Send it to me privately if you do not want your email address public. I
would 
appreciate the help...and so would other people in the linux-audit
community.

Thanks,
-Steve

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



This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address below) immediately.
O2 (UK) Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85

Syscalls

[Johnston Mark (UK)]

My apologies, let me create a new thread ...

Hey guys,

Is there a place where I can get all the supported syscalls for audit
version 1.2.9-6.4. There are a couple of things that I'm trying to do
like watching for the shutdown and init command (looking for system
reboots), and looking for changes to the date (I've got the time part).

Thanks
Mark

-----Original Message-----
From: linux-audit-bounces@redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Johnston Mark (UK)
Sent: 28 February 2007 11:03
To: linux-audit@redhat.com
Subject: RE: New to audit. Need help configuring audit to meet NISPOM
req's

Hey guys,

Is there a place where I can get all the supported syscalls for audit
version 1.2.9-6.4. There are a couple of things that I'm trying to do
like watching for the shutdown and init command (looking for system
reboots), and looking for changes to the date (I've got the time part).

Thanks
Mark

-----Original Message-----
From: linux-audit-bounces@redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: 28 February 2007 03:01
To: linux-audit@redhat.com
Subject: Re: New to audit. Need help configuring audit to meet NISPOM
req's

On Tuesday 27 February 2007 03:25:18 Fields, Randy (Space Technology)
wrote:
> Here are the list of items that I need to accomplish and I greatly
> appreciate any help that you can provide. 1) I need to configure a
test box
> to meet NISPOM audit requirements. (any examples of /etc/auditd.conf
and
> /etc/audit.rules would be great) 2) Then test it by acting as a user
and
> trying to access files such as /etc/passwd and /etc/shadow. 3) Then
report
> that data to prove to auditors that the tool is collecting the events.

I'd like to include a generic NISPOM configuration in the next set of
audit 
packages. Can anyone share some of their contents? I could take a guess
at 
it, but would rather have something that has gone through review. I am
not 
wanting your site sensitive file locations, but generally this:

1) any syscall auditing you turned on
2) any files you needed to audit in /etc that are not site sensitive
3) any files in /var that needed to audit.

I think all other pieces of the audit system are embedded in the
appropriate 
utilities so audit message generation is automatic. The report tool
created 
to meet NISPOM is aureport.

Send it to me privately if you do not want your email address public. I
would 
appreciate the help...and so would other people in the linux-audit
community.

Thanks,
-Steve

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



This electronic message contains information from O2 which may be
privileged or confidential. The information is intended to be for the
use of the individual(s) or entity named above. If you are not the
intended recipient be aware that any disclosure, copying distribution or
use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone
or email (to the numbers or address below) immediately.
O2 (UK) Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in
England and Wales: 1743099. VAT number: GB 778 6037 85




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

Re: Syscalls

[Steve Grubb]

On Wednesday 28 February 2007 06:07:28 Johnston Mark (UK) wrote:
> Is there a place where I can get all the supported syscalls for audit
> version 1.2.9-6.4. There are a couple of things that I'm trying to do
> like watching for the shutdown and init command (looking for system
> reboots), and looking for changes to the date (I've got the time part).

Yes, this is the place. What do you need help with?

-Steve

RE: Syscalls

[Johnston Mark (UK)]

We're trying to setup auditing to match a few policy requirements. The
ones that I'm struggling with are the following:

1) Using auditd to check for system start/stop. In "man syscalls" it
shows shutdown, but auditd doesn't like it when I use this for a system
call. Would also have been nice to track any time someone uses init.

2) Use aureport to show logins (failed and successful). I've logged into
our system with failed and successful tries, and it's visible in
audit.log, but it doesn't show anything under aureport, the count is 0.

3) Were trying to log anytime someone is unsuccessful in doing
something. We've tried the open command with success!=0 as per the
example in the man page, but we get a whole bunch of stuff in the logs,
not the failed attempts

4) Were trying to track all usage by the root user, again we are getting
a whole bunch of other stuff in the logs, not actions by the user root
only.

5) We are trying to track changes to the system date and time. I've been
using the example in capp.rules, but all we get is ntpd, not the usage
of date, which we would like.

Thanks
Mark 



-----Original Message-----
From: linux-audit-bounces@redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: 28 February 2007 11:44
To: linux-audit@redhat.com
Cc: Johnston Mark (UK)
Subject: Re: Syscalls

On Wednesday 28 February 2007 06:07:28 Johnston Mark (UK) wrote:
> Is there a place where I can get all the supported syscalls for audit
> version 1.2.9-6.4. There are a couple of things that I'm trying to do
> like watching for the shutdown and init command (looking for system
> reboots), and looking for changes to the date (I've got the time
part).

Yes, this is the place. What do you need help with?

-Steve

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



This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address below) immediately.
O2 (UK) Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85

Re: Syscalls

[Marcus Meissner]

On Wed, Feb 28, 2007 at 12:23:45PM -0000, Johnston Mark (UK) wrote:
> We're trying to setup auditing to match a few policy requirements. The
> ones that I'm struggling with are the following:
> 
> 1) Using auditd to check for system start/stop. In "man syscalls" it
> shows shutdown, but auditd doesn't like it when I use this for a system
> call. Would also have been nice to track any time someone uses init.
> 
> 2) Use aureport to show logins (failed and successful). I've logged into
> our system with failed and successful tries, and it's visible in
> audit.log, but it doesn't show anything under aureport, the count is 0.

Since you seem to be using SLES 10 SP1 Betas, this feature is not in there
at this time.
 
Ciao, Marcus

Re: Syscalls

[Steve Grubb]

On Wednesday 28 February 2007 07:23, Johnston Mark (UK) wrote:
> We're trying to setup auditing to match a few policy requirements. The
> ones that I'm struggling with are the following:
>
> 1) Using auditd to check for system start/stop. In "man syscalls" it
> shows shutdown, but auditd doesn't like it when I use this for a system
> call. Would also have been nice to track any time someone uses init.

shutdown is not system shutdown, its socket shutdown. If this has to be 
tracked, probably the best thing to do is for us to patch init to record 
changes to runlevels.

> 2) Use aureport to show logins (failed and successful).

We patched openssh, login, and gdm to support this. aureport should pick up 
the USER_LOGIN records in the audit logs.

> I've logged into our system with failed and successful tries, and it's
> visible in audit.log, but it doesn't show anything under aureport, the count
> is 0. 

Sounds like your distro is unpatched.

> 3) Were trying to log anytime someone is unsuccessful in doing
> something. We've tried the open command with success!=0 as per the
> example in the man page, but we get a whole bunch of stuff in the logs,
> not the failed attempts

You probably want:

-a always,exit -S open -F exit=-13

the -13 is -EACCES from errno.h.

> 4) Were trying to track all usage by the root user, again we are getting
> a whole bunch of other stuff in the logs, not actions by the user root
> only.

I am still looking at this. I think we need to patch bash for this.

> 5) We are trying to track changes to the system date and time. I've been
> using the example in capp.rules, but all we get is ntpd, not the usage
> of date, which we would like.

We patched hwclock in util-linux to provide an audited way to set time. Going 
forward, I think we should apply a similar patch to coreutils.

-Steve

Re: Syscalls

[Valdis.Kletnieks]

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

On Wed, 28 Feb 2007 08:28:47 EST, Steve Grubb said:
> > 4) Were trying to track all usage by the root user, again we are getting
> > a whole bunch of other stuff in the logs, not actions by the user root
> > only.
> 
> I am still looking at this. I think we need to patch bash for this.

A patch to bash would be necessary, but not sufficient.

A malicious root user (or any user wanting to bypass a logging login shell)
could just 'vi /tmp/foo', and then use '!your_command_here -h -x -Q 3' or
whatever they wanted to do.  Or launch a copy of Emacs and start 'shell.el',
or just launch a copy of perl, and type 'system("command");' at it, or.....

Probably what's *really* needed is a sebek-style logger that traces all
terminal activity on that connection. http://www.honeynet.org/tools/sebek/
but somebody would have to retarget that code to talk to the audit daemon
rather than an external server on another box.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 226 bytes --]

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

Re: Syscalls

[Steve Grubb]

On Wednesday 28 February 2007 08:28, Steve Grubb wrote:
> > 1) Using auditd to check for system start/stop. In "man syscalls" it
> > shows shutdown, but auditd doesn't like it when I use this for a system
> > call. Would also have been nice to track any time someone uses init.
>
> shutdown is not system shutdown, its socket shutdown. If this has to be
> tracked, probably the best thing to do is for us to patch init to record
> changes to runlevels.

In the interim, you should also be able to set watches on the common 
utilities:

-w /sbin/init -p x -k runlevel
-w /sbin/telinit -p x -k runlevel
-w /sbin/halt -p x -k runlevel
-w /sbin/poweroff -p x -k runlevel
-w /sbin/reboot -p x -k runlevel

There might be a couple more. 

-Steve

Re: Syscalls

[Steve Grubb]

On Wednesday 28 February 2007 09:53, Valdis.Kletnieks@vt.edu wrote:
> A malicious root user (or any user wanting to bypass a logging login shell)
> could just 'vi /tmp/foo', and then use '!your_command_here -h -x -Q 3' or
> whatever they wanted to do.  

I don't think any security target or standard assumes that you have a 
malicious root user. I think that crosses the line from recording what 
actions are performed to potential criminal investigation.

> Probably what's *really* needed is a sebek-style logger that traces all
> terminal activity on that connection. http://www.honeynet.org/tools/sebek/
> but somebody would have to retarget that code to talk to the audit daemon
> rather than an external server on another box.

Yeah, a keylogger is what you'd need and that probably goes beyond what audit 
should be doing. If you want to record a lot of data, then you could also 
add:

-a always,entry -S execve -F 'auid>=500' -F uid=0

-Steve

Re: Syscalls

[James W. Hoeft]

Steve Grubb wrote:
> On Wednesday 28 February 2007 09:53, Valdis.Kletnieks@vt.edu wrote:
>> A malicious root user (or any user wanting to bypass a logging login shell)
>> could just 'vi /tmp/foo', and then use '!your_command_here -h -x -Q 3' or
>> whatever they wanted to do. Â 
> 
> I don't think any security target or standard assumes that you have a 
> malicious root user. I think that crosses the line from recording what 
> actions are performed to potential criminal investigation.

In our world, the primary purpose of audit logs is to support a criminal 
investigation - and malicious root user is assumed. Two options were 
presented: ensure audit files are immutable and if system isn't auditing 
shut it down; or put root password under two-man control. (couldn't 
accomplish first in time frame, so had to go with second, which is an 
incredible pain for the admins - hope to change that with next 
generation/selinux).

>> Probably what's *really* needed is a sebek-style logger that traces all
>> terminal activity on that connection. http://www.honeynet.org/tools/sebek/
>> but somebody would have to retarget that code to talk to the audit daemon
>> rather than an external server on another box.
> 
> Yeah, a keylogger is what you'd need and that probably goes beyond what audit 
> should be doing. If you want to record a lot of data, then you could also 
> add:
> 
> -a always,entry -S execve -F 'auid>=500' -F uid=0
> 
> -Steve

Jim

Re: Syscalls

[Steve Grubb]

On Wednesday 28 February 2007 07:23:45 Johnston Mark (UK) wrote:
> ) We are trying to track changes to the system date and time. I've been
> using the example in capp.rules, but all we get is ntpd, not the usage
> of date, which we would like.

ntpdate & date uses the syscall settimeofday...so...

-a always,exit -S settimeofday

hwclock writes to /dev/rtc and that's why its patched.

-Steve