ashleyknowles.net

I stumbled on a seemingly unique requirement this week to log file access for a Windows network share. Of importance, was the logging of object deletions, and writes. For most Windows admins, this probably sounds like a simple task of setting up group policies or local security policies to audit object access, and the required auditing policies on the objects requiring this level of logging.

Okay, so you’ve setup your auditing, and it’s been logging for yay long. An SMB (say 50 users) I set this up for, managed to generate 1GB of logs in 24 hours, purely from setting object Write and Delete auditing on a network share. This leads to the reason for this article.

1GB of logs is a hell of a lot of data, and we all know the Windows Event Viewer is hardly capable of searching these logs quickly and easily. Furthermore, your security log is going to fill up really quick, and, depending on your policy, events will be over written, or the security log will be full, resulting in non-admin users effectively being locked out of their systems.

Further again, one month down the track, you are faced with the inability to trace who deleted that important management report…

I suspect there are probably numerous commercial packages available for analysis of event logs, and effective archiving of event logs. However, for the Windows admin with limited budget, and time constraints, we’re going to discuss my preferred method, using Syslog to centrally log events.

Syslog is a daemon which runs on Linux and UNIX machines. It is essentially the Windows equivalent of the Event Log service. Under CentOS5 (and most derivatives of Red Hat I would suspect), these logs are stored in `/var/log/`. These logs are archived, or ‘rotated’, by a Cron scheduled task which runs `logrotate`. Syslog also has the ability to receive log messages from other hosts, making it extremely nifty for centralisation of log data, and even more so, the ability to analyse the data contained within.