Audit Logs being put into directory "nobody" within "audit"

[JamesOakley]

Looking over my audit logs to track something down, I noticed something strange that I hadn't seen before.

This is a cPanel server, with the rules installed exactly as per the documentation in the Atomicorp wiki.

Therefore, within my modsec2.user.conf is a line

SecAuditLogStorageDir /var/asl/data/audit

That has always worked as it should. Within /var/asl/data/audit is a folder for each date. Within there is a folder for each minute. Within that is a file for each request that is logged.

But the last date in /var/asl/data/audit is 20140310. Then there is a folder called /var/asl/data/audit/nobody. Within there are all the date directories from 20140311 onwards.

Why would this be? I've grepped SecAuditLogStorageDir in all the .conf files that load into Apache, and there is no other line that overwrites the entry in modsec2.user.conf. I didn't change any settings on that date when the behaviour changed.

Is it something in my configuration, or is it a deliberate change from AtomiCorp as to how the logs are organised? It's clearly not critical - suspicious requests are still being blocked, and those blocks are being logged, and I can find the log entries. But it would be helpful at least to know where to look to track down the change. I prefer the old hierarchy - it's easier to keep tidy.

[scott]

That doesnt sound right at all, it should use /var/asl/data/audit/. What version of aum are you using? Also if you could open a support case (don't worry, we don't charge for that!) you could send us your config files there.

[JamesOakley]

What's AUM?

I'm using the ruleset, but not using ASL to install them. Apache 2.4.9, mod_security 2.7.7

Is a support case the best way to try and resolve this?

[scott]

Ahh, ok. Aum (Atomic Updater Modified) is what replaced asl-lite. Its the update & rule management module from ASL. It manages all your config files automatically

The rules themselves cant do anything like that (change paths, etc)

[JamesOakley]

asl-lite used to be available for people with only a rules subscription. Is AUM similarly available?

I use my own bash script that downloads the VERSION file, checks it with the last one installed, then downloads new rules when necessary before testing and restarting Apache. It works well - but all I've changed are the files in your download. The other files, like modsec2.user.conf, have not been touched since I set the server up. So it's hard to see why the behaviour has suddenly changed.

From what you're saying, this isn't normal or correct.

You will know how your rules know to use the date / time folder hierarchy within the specified /var/data/asl/audit. Where is that hierarchic structure defined. It looks like it's somehow morphed into username / date / time instead, so if I knew where to look...

[scott]

asl-lite used to be available for people with only a rules subscription. Is AUM similarly available?

Sure, you can install it with: wget -q -O - http://www.atomicorp.com/installers/aum |sh

Code: Select all

From what you're saying, this isn't normal or correct.

Not at all, especially if you havent touched configs. I'm not sure how a username could have worked its way in there, but now that you mention it this actually could solve a problem we have with environments like mod_ruid2 (this writes files with the permissions of the user). If indeed you've managed to figure out a way to achieve that I'd *LOVE* to see how it happened.

[mikeshinn]

You will know how your rules know to use the date / time folder hierarchy within the specified /var/data/asl/audit. Where is that hierarchic structure defined. It looks like it's somehow morphed into username / date / time instead, so if I knew where to look...

The entire heirarchy is created by modsecurity itself based on whatever you set SecAuditLogStorageDir to. The rules have no control or effect on it. So that dir can only change if:

1) That setting is changed
2) modsecurity itself was changed to append something to that path

If that setting didnt change, check to see if modsecurity was changed on your system, maybe cpanel added this to their modsecurity build.

[JamesOakley]

Thanks Mike

Between you, you gave me the pointers to solve this. It turns out it's not a bug, it's a feature!

My mod_security is built by EasyApache. EasyApache downloads and compiles mod_security from source as part of its Apache build.

If you look in their changelogs, under the entry for 3.24.12, you'll see an entry attributed to their internal case number 76493: "Resolve incompatibility between ModRuid2 and ModSecurity"

They don't explain what this is. I could open a support ticket and ask them, but I don't think I need to. I already knew that modruid2 and mod_security struggle to work together because the log files would need to be world-writeable. You've confirmed that what I was seeing would be an ideal way to solve this problem.

Putting 2 and 2 together, I'd guess that, under case 76493, they introduced a change that modifies the source for mod_security (before compilation) to make it output in a folder hierarchy named after the username. I must have recompiled Apache on the 10th, the day they introduced the change. I would have been prompt with that update, because it included some security-level updates to PHP.

That would explain what I'm seeing. And now that it's explained, it means that I don't need to worry about these new log locations. "This feature is by design".

It may also partially help you with modruid2 support more widely, but that's another matter entirely.

I hope this thread helps anyone else who's noticed the new log locations and is searching for an explanation.

[scott]

Just finished adding that function to mod_security here. The really good news is it doesnt require any change to ASL, the interface adapted to the path change automatically. So very welcome news, this was a really good thread!