Setting up several keys in audit.rules file

dunamin · 03-16-2011, 03:45 PM

I am trying to lock down a server using audit.rules. I intend to use ausearch to review certain entries from time to time. I noticed that it's possible to assign a "key" to each rule and then use `ausearch -k` to show only the records that have that key.

Unfortunately, the key feature seems broken. I started with the following rule in audit.rules:

Code:

-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -k deny

I do a `cat /etc/shadow` and a `ausearch -ts today -k deny` and it seems all went well. Now, I want a special key for /etc/shadow, so I added a new rule:

Code:

-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -F path=/etc/shadow -k shadow

I restarted auditd and did a `cat /etc/shadow` and a `ausearch -ts today -k shadow`. The new record did not show up. When doing a `ausearch -ts today`, I found that the key for the new record is still "deny" not "shadow" as I expected. I tried putting the "shadow" rule before and after the "deny" rule, and it didn't help. If I completely removed the "deny" rule, the key would finally work for "shadow".

I feel totally stumped. I have certain scenarios that I want to be keyed in certain ways. The /etc/shadow shown above was just an example for a more complex set of filters that I want to build. I would rather not have to type it in each time I do an ausearch. Did I do something wrong? Is there an easier solution?

Here is my failing audit.rules:

Code:

# First rule - delete all
-D

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

# Feel free to add below this line. See auditctl man page
-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -k deny
-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -F path=/etc/shadow -k shadow

unSpawn · 03-16-2011, 07:02 PM

Quote:

Originally Posted by dunamin

I restarted auditd and did a `cat /etc/shadow` and a `ausearch -ts today -k shadow`. The new record did not show up.

If you tested this as root account user then both your rules won't trigger on exit=-EACCES. Did you? Why not place a watch and use '-w /etc/shadow -p r -k shadow'? This would get syscalls logged too. What's the reason behind the need for specific syscalls?

Quote:

Originally Posted by dunamin

I have certain scenarios that I want to be keyed in certain ways.

Interesting. As you said you are locking down the machine could you please elaborate?

dunamin · 03-16-2011, 10:08 PM

Thanks for writing back. I triggered /etc/shadow with a normal user account, not root. I'll try the `/etc/shadow -p r -k shadow` to see if the shadow key shows up.

I have two main goals with this setup:
1. Log anything possibly suspicious.
2. Create a filter for very unusual bad stuff.

I used the syscall flavor of rules since it will log every time someone gets a permission denied regardless of the file's path. There's a utility that when not run as root will attempt to open a config file in /etc and fail. I know the name of the utility, the name of the /etc file and the user who always does this. I want to filter out those types of events using a key.

To hopefully simplify the problem, I was picturing some piece of code that would look like this:

Code:

if (status==permission_denied){
 if (file==/etc/shadow) then key=a;
 else key=b;
}

I wonder if audit.rules can even express such logic. I'm starting to think that I will just have to make an uglier filter on the ausearch side of things.

unSpawn · 03-17-2011, 05:56 PM

Quote:

Originally Posted by dunamin

I triggered /etc/shadow with a normal user account, not root.

OK.

Quote:

Originally Posted by dunamin

Log anything possibly suspicious.

As MAC operates on top of DAC you do understand proper hardening prior to this is required, right?

Quote:

Originally Posted by dunamin

To hopefully simplify the problem, I was picturing some piece of code that would look like this:

Code:

if (status==permission_denied){
 if (file==/etc/shadow) then key=a;
 else key=b;
}

I wonder if audit.rules can even express such logic.

I do too. Haven't tried this yet but how about exclusion as in:

Code:

-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -F path!=/etc/shadow -k deny
-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -F path=/etc/shadow -k shadow

?

dunamin · 03-22-2011, 01:34 PM

Thanks again for your advice. I still seem stuck. Here's the latest update:

1. I tried the path!=/etc/shadow and get an invalid argument error.
2. I don't have too much MAC configured yet, but I may start adding more. I was trying to figure out how best to use it so any advice is welcomed. But I would like to keep things fairly simple for the other admins on the team.
3. ausearch does not allow the same fields identified by auditctl so it's not easy to filter out certain scenarios after they have happened.

At this point, I'd settle for a tool that will easily filter out unwanted records from audit logs.

slimm609 · 03-22-2011, 05:22 PM

have a look in /usr/share/doc/audit-<version>/ there are rules files in there that will be a really good start. stig.rules is a mostly DOD STIG compliant version of the rules

unSpawn · 03-23-2011, 11:40 AM

Quote:

Originally Posted by dunamin

I tried the path!=/etc/shadow and get an invalid argument error.

Shame creating exclusions this way doesn't work. I don't know if you want to pursue it but if you could ask this on the SELinux users mailing list I'd love to read the developers replies or ideas...

Quote:

Originally Posted by dunamin

I don't have too much MAC configured yet, but I may start adding more. I was trying to figure out how best to use it so any advice is welcomed. But I would like to keep things fairly simple for the other admins on the team.

IMHO "simple" is not as good a reference point as "effective" would be. I'd say log what you need to know about, where need is determined by the placement of the server, its purpose, the services it runs, the type of accounts it gives access to et cetera. If you're looking at the STIG rules also have a look at CAPP rules as they complement each other in some ways.

Quote:

Originally Posted by dunamin

ausearch does not allow the same fields identified by auditctl so it's not easy to filter out certain scenarios after they have happened.

Could you give us an example of that?

Quote:

Originally Posted by dunamin

At this point, I'd settle for a tool that will easily filter out unwanted records from audit logs.

That would be a good starting point because you can only know about events you log.

dunamin · 03-23-2011, 05:36 PM

Thanks for the suggestions everyone. Here's an example of what I was hoping ausearch could do:
`ausearch -ts today -F path=/etc/shadow`

or better yet:
`ausearch -ts today -F path!=/etc/shadow -F uid!=punkadmin|ausearch -F <another criteria>|ausearch ...`

Of course, it would be only for what is already logged, but it opens the search beyond trying to create the proper keys beforehand. I'm starting to think sed/awk/grep/perl scripting of /var/log/audit is my best bet. It looks like each event really has several lines, so this does not sound like an easy approach. Maybe the samples mentioned by slimm will generate some new ideas.

Thanks again everyone for the help.

unSpawn · 03-23-2011, 08:08 PM

Quote:

Originally Posted by dunamin

Thanks for the suggestions everyone. Here's an example of what I was hoping ausearch could do:
`ausearch -ts today -F path=/etc/shadow`

or better yet:
`ausearch -ts today -F path!=/etc/shadow -F uid!=punkadmin|ausearch -F <another criteria>|ausearch ...`

Hmm. Say I have a rule

Code:

]# auditctl -l | awk -F': ' '/ssh_.*C/ {print $2}'
exit,always watch=/etc/ssh/ssh_config perm=rwxa key=CFG_ssh

then I can use the "-f" equivalent of "-F":

Code:

]# ausearch -ts today -f /etc/ssh/ssh_config -ui 500 --just-one
----
node=name type=PATH msg=audit(1100000897.368:1235): item=0 name="/etc/ssh/ssh_config" inode=201 dev=01:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0
node=name type=CWD msg=audit(1100000897.368:1235):  cwd="/home/logname"
node=name type=SYSCALL msg=audit(1100000897.368:1235): arch=40000003 syscall=5 success=yes exit=4 a0=d0f0a6 a1=8000 a2=1b6 a3=9caeba0 items=1 ppid=7460 pid=7461 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=111 comm="ssh" exe="/usr/bin/ssh" subj=user_u:system_r:unconfined_t:s0 key="CFG_ssh"

and knowing the session get an account of anything logged in that session:

Code:

ausearch -ts today --session 111

or what the UID has been doing before getting all hungry:

Code:

]# ausearch -ts 03/23/2011 11:00:00 -ui 500 -te 03/23/2011 12:00:00 -k WARN_trace | wc -l
11552

Unfortunately ! is an unsupported option...