auditd does not audit much

patpro

Active Member

Reaction score: 15
Messages: 213

Hello,

I'm running a FreeBSD 8.2 amd64 web server. Everything is working great, but I need to enable auditd to scrutinize a few things about the server security. It appears that the 8.2 GENERIC kernel already includes "option AUDIT", so I've just modified /etc/security/audit_user, /etc/security/audit_control and launched auditd:

Code:
# cat /etc/security/audit_user 
root:lo,ex,pc:no
www:fc,fd,ex,pc:no
Code:
# cat /etc/security/audit_control 
host:my.host.tld
dir:/var/audit
flags:lo,aa
minfree:5
naflags:lo,aa
policy:cnt,argv,arge
filesz:10M
expire-after:50M
All other files are set to their default values. According to this definition, auditd should log events for www that match "file creation", "file deletion", "execution", "process", and the default "login/out" and "authentication/authorization". In fact, it logs nothing about the user www.

[cmd=]praudit /var/audit/current[/cmd] returns only "lo" events for users accessing the server via ssh.

Did I miss something obvious?
 

dh

Member

Reaction score: 21
Messages: 96

Auditing starts with next login session. For example when you login in as root and then do full apache restart, it will start logging audit trails for www user. There may be more to it than this but that's what I've observed so far.
 
OP
patpro

patpro

Active Member

Reaction score: 15
Messages: 213

I've tried. I've restarted Apache many times, but I don't think running apache can be considered as a "login" for user www. And obviously www will never login, as for many users you are supposed to be able to audit (nobody, ...).

I've even rebooted to make sure. No luck. Of course sudo is not an option, as auditd will follow the real uid of the user, and not the one acquired via sudo.

I've finally made a login attempt via ssh with the login "www". It was properly logged by auditd, but no other events are being logged... even after restarting Apache. It looks like my audit_user file is ignored, as the only things logged are the defaults from audit_control.

edit: I've added "fc" to flags of /etc/security/audit_control, and auditd started to log file creation related events. The weird thing: in 40 minutes, it logged only 3 events for the whole system. I'm pretty sure that's wrong. It's quite a busy web server (around 250 web sites, many php session files created in /var/run...).

It appears that if I login, sudo -s, create a file, the event is not logged., But if I login, create a file, the event is logged. That's insane. I just don't get it.
 
OP
patpro

patpro

Active Member

Reaction score: 15
Messages: 213

I've already read the chapter 17, and googled, without success.

Now that I've waited a bit, and restarted Apache for the 35415th time, auditd has finally realized it must follow www, and I've got around 16K audit trails for that particular user, starting 20 minutes ago (auditreduce -e www /var/audit/current | praudit |grep -c header_ex).

It will grow very fast, it's only 9:35 here in France, so I'll watch this closely.

I still don't understand why auditd waited 1 hour, and needed one more Apache restart to start recording events. I still don't understand why I must put "fc" flag in audit_control for it to be taken into account, and why auditd won't use the content of audit_user (because fd, ex, and pc events are still not accounted for).

And I'm glad I've launched nscd to cache uid/login for my (remote) LDAP users, it reaches 160% CPU when I run this kind of things:
[CMD=""]auditreduce -e www /var/audit/current | praudit |grep -c header_ex[/CMD]
 
OP
patpro

patpro

Active Member

Reaction score: 15
Messages: 213

Ok, it looks like I'm understanding a little better what's going on here.

1- Auditing the user www won't tell you nothing about Apache. www can't login to the system, so there is nothing to audit. Not cool.

2- auditd follows the very originating uid. I never login as root on this server, I use my own personal login, then sudo -Es, then do my admin task (launching Apache for example).
So httpd processes are audited as if they where mine (not even root's, but mine). I've had to specify an audit_user record for my very own uid, so that auditd will follow httpd. Not cool.

3- Hence, of course, the audit trail is greatly polluted by my own activity. You don't think much about your complex bash prompt until this kind of things happens. Not cool.

Finally, I've had to:
- add my own login to audit_user, with flags I've wanted to use on user www
- logout, login
- sudo, restart apache
and auditd started to log events about me, and www.

Then I can list events associated with www by using auditreduce and arguments like "-e www" (effective uid). I though it would be cool if I could use auditreduce to limit the output to an event class, like ex, lo, fd… for example. There is a flag for that too, but it just does not work at all:

do work, ie. returns unlink events (from event class "fd"):
[CMD=""]auditreduce -e www /var/audit/current | praudit | grep unlink[/CMD]

does not work (returns nothing at all):
[CMD=""]auditreduce -e www -c fd /var/audit/current | praudit[/CMD]

Is there anybody around here who really uses auditd, in real life?
 

phoenix

Administrator
Staff member
Administrator
Moderator

Reaction score: 1,277
Messages: 4,099

Instead of $ sudo -Es try using $ sudo su -

That way, it is the same as if you actually logged in as root (using root's ENV, root's shell, root's everything).
 
OP
patpro

patpro

Active Member

Reaction score: 15
Messages: 213

No, it's not the same, the environment is cleared, but the first UID is still mine. I've even tried a direct "su -".

The only thing I've won trying this, is that auditd now logs "fc" events, even if it's not supposed to. Unfortunately, it looks like I'm unable to stop fc events to be logged now... I've stopped auditd for now.

edit: my bad, it looks like I've made a wrong interpretation of what I saw. Some events are both in fd and fc, and I don't find a way to log fd without fc+fd events.
 
OP
patpro

patpro

Active Member

Reaction score: 15
Messages: 213

patpro said:
Then I can list events associated with www by using auditreduce and arguments like "-e www" (effective uid). I though it would be cool if I could use auditreduce to limit the output to an event class, like ex, lo, fd… for example. There is a flag for that too, but it just does not work at all:

do work, ie. returns unlink events (from event class "fd"):
[CMD=""]auditreduce -e www /var/audit/current | praudit | grep unlink[/CMD]

does not work (returns nothing at all):
[CMD=""]auditreduce -e www -c fd /var/audit/current | praudit[/CMD]
I've made a quick comparison with my Mac OS X 10.6, which comes with the exact same audit implementation: it works flawlessly. During the comparison, I've noticed that a typical record from auditd on the Mac starts with "header,..." when the same record would start with "header_ex,..." on my FreeBSD. Then I've noticed that very early auditd files (from my first tests) are reading "header" instead of "header_ex".

I've found out that auditreduce -c XX works on auditd records that start with "header", but does not work on records that start with "header_ex".

I've commented out the host field in audit_control, and now new records are created with "header" instead of "header_ex" on the FreeBSD server. It looks like it closely relates to the bug pr#149806. That allows me to use auditreduce with -c flag.
 

fwaggle

Member

Reaction score: 6
Messages: 62

patpro said:
Is there anybody around here who really uses auditd, in real life?
I did, but an upgrade broke it and I haven't bothered to fix it. What I was doing was auditing Apache for execute events, and I had a little ghetto-IDS set up to alert me on any exec() calls that weren't to things I expect, like php-cgi and such.

csjp@ has written a setaudit program, I'm not sure if it's in base yet, you could check though. You can use that to set the "audit context" or whatever it's called for Apache, then audit trails will behave as you expect and not be polluted by your shell's activity. I think I put mine in the Apache rc script, which I then carelessly blew away one day and didn't bother fixing it.

Audit is pretty much voodoo to me, but I did use it with good effect - I just don't remember how I had it set up. :(
 
OP
patpro

patpro

Active Member

Reaction score: 15
Messages: 213

fwaggle: thank you. I can't find a program named setaudit, only a BSD system call (man 2).
 

fwaggle

Member

Reaction score: 6
Messages: 62

Okay, apparently setaudit won't go into base because it's not really the "right way" to solve the problem. csjp@ is thinking about making it a port, but who knows if that'll happen. :)

You can download it here and build it, I forget what libs etc. it needed: http://www.freebsd.org/~csjp/setaudit.c

I really don't remember much at all about how I had it set up, but I seem to recall I had it in my rc.d script for Apache somehow. Hope that helps some. :)
 
OP
patpro

patpro

Active Member

Reaction score: 15
Messages: 213

Ok, thank you. I'm going to take a look at this.
 
OP
patpro

patpro

Active Member

Reaction score: 15
Messages: 213

I've made a compilation attempt today, but it fails with this error:
Code:
undefined reference to `getauditflagsbin'
. I don't know how to solve this, I don't even know if it solvable at all.
 
OP
patpro

patpro

Active Member

Reaction score: 15
Messages: 213

I have no idea what you are talking about :)
My knowledge about compilation and development is very low.

Ok, trying gcc -lbsm setaudit.c yields to a working binary a.out without any error. Now if you have any piece of information about how to use this program, I'd be very glad :)
 

fwaggle

Member

Reaction score: 6
Messages: 62

Okay, I'll try... but BSM auditing is still pretty much voodoo to me, so I'm trying to piece together the way I had it set up based on experimentation and a very vague memory... so it will require some experimentation on your part.

I had this in /etc/security/audit_user:

Code:
www:ex:
... which I believe will cause www user to audit all execve() style function calls. Don't forget to restart auditd after changing that stuff, and of course make sure it's running (that was my first gotcha when trying to recreate a working setup just now).

The issue is that "www" will never "log in" to set the audit context, which is what setaudit is for. This caused Apache to successfully audit all execve() functions for me:

# setaudit -a www -m ex /usr/local/etc/rc.d/apache22 restart

Then I can see the events through praudit:

# praudit /dev/auditpipe0
Code:
header,167,10,execve(2),0,Thu May 26 14:15:55 2011, + 738 msec
exec arg,/usr/local/bin/php-cgi
exec env,TZ=EST5EDT
path,/usr/local/bin/php-cgi
attribute,755,root,wheel,105,41199924,164635936
subject,www,www,www,www,www,6186,0,0,0.0.0.0
return,success,0
trailer,167
I then used security/bsmtrace to set up a white list of things that were acceptable for Apache to be executing (eg, php-cgi, via mod_fcgid), and had it alert me if anything else ran (ie, perl, python, or php, would indicate someone trying to exec() a long-running script and that one of my scripts got owned). I think I also had it set up to alert, very loudly, on execve() events on anything inside of /tmp.

My setup was definitely not failure-proof, and did provide false-positives (for example, most PHP forum packages can't trust one particular PHP function for some reason or another, IIRC it was something to do with getting the time, and so would exec() a system binary every chance they got to get it) but it did work. Note that if you were running suexec or whatever, you'd probably want to open up the context a bit more than just the www uid.

I have no idea how these exact settings apply to your particular use case, that's an exercise for you to figure out, but setaudit worked for me at one point. Maybe someone much better versed in it than me can point you further in the right direction, and/or correct any mistakes I've made above. :)
 
OP
patpro

patpro

Active Member

Reaction score: 15
Messages: 213

fwaggle: thank you very much. I've tested this very quickly on Mac OS X 10.6, and it's working perfectly. I'll make more tests on FreeBSD as soon as possible.

edit 2011-07-17: I've had more time to experiment on FreeBSD, and I'm almost happy with the result. I've a rc.d script launching Apache with audit enabled, and can change audit flags in /etc/rc.conf (see http://forums.freebsd.org/showthread.php?t=24915 ).

Now I'm trying to use BSMtrace. That's the hard part, apparently :)
 
Top