How to handle polluted security event logs?

Question

everyone!

I've been tasked with solving a problem with the way we manage event logs from our file server. Currently, we have a script that exports all security entries, once a week, to a backed up folder.

Well, i've been checking these logs a couple days ago, and noticed A LOT of entries were missing. It turns out there were so many events our 128mb limit would quickly fill, overwriting the oldest entries. We always have an average of 130k entries.

Upon further investigation, i discovered some things:

Most of these entries aren't even relevant. What we want is to log file creation, access and deletion from a single drive (d:), primarily. Having file auditing for the rest of the server is also desirable, as it would be useful in some cases. Not our major concern though.
Those "undesired" entries are mostly like this: entries about an Arcserve agent checking random files. I found the following command somewhere on the internet, and if it really reveals what i think it does, then 96k logs (or almost 75%) are the result of this application fiddling around.

get-eventlog security -Message "*caagstart*"
I found this GPO applying audit parameters on this specific server. I think, though, that this alone wouldn't make every single file on it be audited - i expected to find any auditing entry (or SACL, as i think it's called) pinpointing which folders should be audited. Coudn't find any. I read somewhere icacls would tell me which folders are currently being audited, but i coudn't manage how to make it work.

I think i could create some script to delete these Arcserve-related logs a couple times a day, but this solution doesn't seem to be a good one. I could also set up some kind of log server to collect and process these events, but that also seems exagerated - all we want is to be able to check, if ever needed, who created, modified or deleted a file. Raising the maximum file number is another solution that does not feel quite right.

Is there any way we could prevent this application from generating log entries? Does anybody recommend anything else i could do?

Oh, by the way: this is a WS2012R2 server.

Does your group policy allow auditing of SAM, File System, and Privilege use? Also it is auditing Success and Failure? — JukEboX, Mar 13 '17 at 20:50
It's only auditing success file system events. Do you recommend any change? — gabpalves, Mar 14 '17 at 12:03
What is the value of this security option: `Audit: Audit the use of Backup and Restore privilege`? — Greg Askew, Mar 14 '17 at 14:56
In the local security policies, disabled. In the GPO, not defined. — gabpalves, Mar 14 '17 at 19:42

score 1 · Answer 1 · answered Mar 14 '17 at 14:36

1

You cannot selectively delete logs from the security event log, since that compromise the integrity of the audit log. You can however, in most cases, define what makes it into the log.

Increasing the size of the log is something you should definitely do, and there is nothing wrong with that. Even increasing the size of the log to 1Gb shouldn't cause any problems.

When you audit a folder, you can specify which user is being audited. Since the Arcservce agent service likely runs under a unique user account (and if it doesn't, change it so that it does), you should be able to change your auditing so that it doesn't include that user account.

Finally, getting a log management solution - while not necessary in this case - is not an overkill. There are plenty of solutions out there that work well with smaller and larger installations. Some of them (e.g. EventSentry) let you define exactly which logs to store, and which to exclude.

answered Mar 14 '17 at 14:36

Lucky Luke

1,634
1
11
12

Increasing the log file size will use more ram. Removing auditing of arcserve is useful, or you could set up a log aggregation server with would subscribe to the logs of the fileserver. – Jim B Mar 14 '17 at 14:46
While I haven't compared the RAM usage of two identical servers with different event log sizes, I very much doubt that increasing the event log size will increase the RAM usage. The event log is stored on disk, a larger event log size would simply retain data longer and use up more disk space. – Lucky Luke Mar 14 '17 at 18:13
Actually its not (well it is but anything in memory is eventually on disk). The security log is in memory pages. I'll see if there is a doc someplace, but it's been that way since nt4 – Jim B Mar 15 '17 at 00:16
In fact here's a question with an answer to why someones ram usage was huge when they increased the log size: http://serverfault.com/questions/586200/security-log-eating-ram – Jim B Mar 15 '17 at 00:22
Hmm, interesting, looks like you are correct - apparently it's in a memory-mapped file. I'll have to look into this a bit more. Thanks! – Lucky Luke Mar 15 '17 at 04:51

How to handle polluted security event logs?

1 Answers1