2:25 a.m.
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(a)ngc.com
9 p.m.
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
5:02 a.m.
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(a)redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: 28 February 2007 03:01
To: linux-audit(a)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(a)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
5:07 a.m.
New subject: Syscalls
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(a)redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Johnston Mark (UK)
Sent: 28 February 2007 11:03
To: linux-audit(a)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(a)redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: 28 February 2007 03:01
To: linux-audit(a)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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
5:43 a.m.
New subject: 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
6:23 a.m.
New subject: Syscalls
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(a)redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: 28 February 2007 11:44
To: linux-audit(a)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(a)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
6:25 a.m.
New subject: Syscalls
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
7:28 a.m.
New subject: Syscalls
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
8:53 a.m.
New subject: Syscalls
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.
9:25 a.m.
New subject: Syscalls
On Wednesday 28 February 2007 09:53, Valdis.Kletnieks(a)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
1:24 p.m.
New subject: Syscalls
Steve Grubb wrote:
On Wednesday 28 February 2007 09:53, Valdis.Kletnieks(a)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
9:17 a.m.
New subject: Syscalls
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
8:41 p.m.
New subject: Syscalls
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
6505
days inactive
6507
days old
linux-audit@lists.linux-audit.osci.io
12 comments
6 participants
participants (6)
-
Fields, Randy (Space Technology) -
James W. Hoeft -
Johnston Mark (UK) -
Marcus Meissner -
Steve Grubb -
Valdis.Kletnieks＠vt.edu