Sunday, June 19, 2016

Customized File Monitoring with Auditd

In the previous article on auditd, I showed how to use aureport to check stuff monitored by the auditddaemon.
And, I showed how you could, for example, check whether a user had
experienced trouble logging in, which could be interpreted as a
malicious attempt to access a system.
As I said before, aureport is part of a larger toolset that comes with auditd. Using auditdto
monitor some preset events is already quite useful, but where it comes
into its own is when you customize it to monitor whatever you want.

Customized Monitoring Rules

To push your rules into auditd on the fly you use auditctl.
But, before you insert any of your own rules, let's check to see if any
defaults are already in place. Become root (or use sudo) and try this:

auditctl -l
-a never,task

The -l option lists all current active rules and, if
you see the -a never,task line shown above, none of the rules following
it will log anything. This rule, which is often a default in new auditd
installations, is telling the daemon to append (-a) a rule to the task
list (as in the list of tasks the kernel is running -- don't worry about
this just yet), which will stop auditd from ever recording anything.
Because we're not specifying which task, auditd assumes the rule applies to all of them. In plain English, this would read: "Never record anything from any of the tasks the kernel is running."
And, because auditd gives precedence from top to bottom (i.e., the
first rule takes precedence over the ones following it in case of a
conflict), this means nothing will be recorded despite what any of the
other rules say.
You don't want that, so the first thing to do is get rid of this
rule. To delete all rules from a running auditd daemon, you can use:

auditctl -D

If you already have more than one rule and don't want to zap them all, you can also selectively delete only this rule with

auditctl -d never,task

Now the coast is clear, so I’ll show
how to build your own first rule. The typical use for auditd is to have
it monitor files or directories. For example: As a regular user, create
a directory in your /home directory, say…

mkdir test_dir

Now become root and set up a watch on the directory you just made:

auditctl -w /home/[your_user_name]/test_dir/ -k test_watch

The -w option tells auditd to watch the test_dir/ directory for any changes. The -k option tells auditd to append the stringtest_watch(called
a key) to the log entries it creates. The key can be anything you want,
although it is a good idea to make it something memorable and related
to what the rule does. As you will see, this will be useful to filter
out unrelated records when you revise auditd's logs later on.
Now, as a regular user, do some stuff in test_dir/ -- make some subdirectories, create or copy some files, remove some files, or list the contents.
When you're done, take a look at what auditd logged with

ausearch -k test_watch

See the use of -k test_watch here?
Even if you have a dozen more rules logging different things, by using a
key string, you can tell ausearch to only list what you're interested in (Figure 1).

Even with this filter, the amount of information ausearch
throws at you is a bit overwhelming. However, you will also notice that
the information is very structured. The output is actually made up of
three records per event.
Each record contains some keyword/value pairs separated by a "="
sign; some of the values are strings, others are lists enclosed in
parenthesis, and so on. You can read up on what each snippet of information means in the official manual,
but the important thing to take away is that the structured nature of
ausearch's output makes processing it using scripts relatively easy. In
fact, aureport, the tool I showed in the previous article, does a very good job of sorting things out.
To prove it, let's pipe our ausearch output through aureport and see what's what:

This is starting to make sense! You can check who is doing what to which file and when.
One thing you can see in the listing above is that, because I am
using the Plasma desktop, Baloo, KDE's indexing service, is cluttering
the list with irrelevant results. That's because every time you create
or destroy a file, Baloo has to come along and index the fact. This
makes parsing what is going on and checking whether the user is up to no
good, annoyingly hard. So, let's filter Baloo's actions out with a
strategically placed grep:

That's much better. You can now clearly see what the users have
been up to. You can follow how they create some directories and files
and copy others from elsewhere. You can also check what files are being
removed, and so on.
When you have no more use for it, you can remove the above watch with

auditctl -W /home/[your_user]/test_dir/ -k test_watch

One File at a Time

Monitoring whole directories makes for a lot of logged data.
Sometimes it is better to just monitor strategic individual files to
make sure no one is tampering with them. A classic example is to use

auditctl -w /etc/passwd -p wa -k passwd_watch

to make sure nobody is messing with your passwd file.
The -p parameter tells auditd which permissions to monitor. The available permissions are:

r to monitor for read accesses to a file or a directory,

w to monitor for write accesses,

x to monitor for execute accesses,

and a to check for changes of the file's or directory's attributes.

Because there are legitimate reasons for an application to read from
/etc/passwd, you're not going to monitor for that to avoid false
positives. It is also a bit silly to monitor for the execution of a
non-executable file; hence, we tell auditd to only monitor for changes
to passwd's content (i.e., writes) and its attributes.
If you don't specify what permissions to monitor, auditd will assume
it has to monitor all of them. That's why, when you were monitoring the
test_dir/ directory in the first examples, even a simple ls command
triggered auditd.

Permanent Rules

To make your rules permanent, you can include them into /etc/audit/audit.rulesor create a new rules file in the /etc/audit/rules.d/directory. If you have been experimenting with rules using auditctl and you are happy with your current set up, you could do:

to dump your current rules into a rules file called my.rules
and save yourself some typing. If you've been following this tutorial
and used the example rules you saw above, my.rules would end up looking like this:

to have auditd pick up your rules straight away.
Now, every time your system is rebooted, auditd will start monitoring whatever you told it to.

There’s More

I had time to cover only a small portion of auditd’s capabilities
here. But, as you can see, auditd is very powerful, and it can be used
monitor much more than just files and directories, with an insane level
of detail. I plan to visit the more advanced topics in a future article.