Windows 2003 / 2008 event logging to Syslog

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.

If you’re preference here is to run a Linux system with Syslog, then by all means, go for it, that’s my preferred option also. However, this instance required no additional hardware, and was a “quick” project. A proper setup might involve a virtual machine running CentOS5 with Syslog-ng instead. For all intensive purposes, if you’re reading this to find out how to log from Windows to syslog, without all the Windows syslog nitty gritty, skip the next few paragraphs.

Moving on from Linux etc, you’re a Windows admin. We don’t have a Linux system available to us to shoot our syslog messages to. I had to do a bit of searching to find something that seemed to do what I needed it to, Google upon Google, all I could find was references to a piece of software, which used to be freeware, called Kiwi Syslog Server. It seems, they have been taken over, and now the product isn’t quite free. That said, however, you can download the 30 day trial, after inputting your life story. This trial version, allegedly reverts to basic functionality when it reaches the end of the time limit.

Features of the Free version

• GUI-based syslog manager
• Messages are displayed in real-time as they are received
• 10 virtual displays for organizing your messages
• Message logging or forwarding of all messages, or based on priority or time of day.
• Auto-split the log file by priority or time of day
• Receives messages via UDP, TCP or SNMP
• Forwards messages via UDP or TCP
• Automatic log file archiving based on a custom schedule
• Messages per hour alarm notification with audible sound or e-mail
• Log file size alarm notification with audible sound or e-mail
• Daily e-mailing of syslog traffic statistics
• Minimizes to the system tray
• Maintains source address when forwarding messages to other syslog hosts
• Syslog statistics with graph of syslog trends (Last 24 hrs/Last 60 mins.)
• Syslog message buffering ensuring messages are not missed under heavy load
• DNS resolution of source host IP addresses with optional domain removal
• DNS caching of up to 100 entries to ensure fast lookups and minimise DNS lookups
• Pre-emptive DNS lookup using up to 10 threads
• Comes with 5 cool skins to change the look of the program
• Selectable display font, display color, and background wallpaper
• Also available as an NT Service
• RFC3164 send and receive options
• Context based help
• Free for use for as long as you want

Brilliant.

So we installed Kiwi Syslog Server onto one of our Windows 2003 servers, and basically just started the service. Kiwi comes with a handy GUI console which shows Syslog messages as they flow in, which I found pretty cool. Of course, if your reading this with a Linux background, you’d just use `tail -f /var/log/messages’, for example, to achieve the same result.

Moving on, we need our file server (or whatever server) to send syslog messages to our syslog server. I wrote a blog article on my old site detailing the installation and use of a nifty little Windows service named “evtsys”. The program was literally a download, copy to `C:\windows\system32` and execute as follows:

evtsys -i -h syslogserver

This would install the evtsys service and tell it to push syslog messages to “syslogserver”. Originally, I was impressed with evtsys, however, it had two major problems on the systems I originally used this tool on. Firstly, it would frequently just stop. Whether this was an issue with x64 compatibility or not, I have no idea. Secondly, it would send absolutely EVERY event log entry to your syslogserver. This can both be a good thing and a bad, depending on your requirements.

I decided to give evtsys another go this time around for my client’s Windows 2008 Server. However, I was very disappointed to find that the service would simply start, then stop… Weird? As some of you may have realised, Windows Vista / 2008 has a different layout in terms of the Event Viewer. This led to evtsys cracking a darky. So back to the drawing board.

Google google google… I eventually decided to click on to “SNARE”. I had clicked it a few times, but didn’t seem to see a download link, or any buzz words to suggest it would do what I wanted. Until I read a bit further… SNARE is a god send.

Where evtsys failed, SNARE delivered. Firstly, it recognised the Windows 2008 event log structure. Awesome. Secondly, it’s been running for a week or so with no issues. Bonus. Lastly, you can tell SNARE what messages to send to your syslog server. Jackpot!

Back to the start of this article, I mentioned the event logs would take up considerable amounts of space in short periods of time. SNARE allows us to send only the messages we want to the syslog server. SNARE comes predefined with some handy little rules, and with a bit of tweaking, I had messages popping up in Kiwi in no time.

Of note in setting up SNARE, you must specify the port to send syslog messages to. SNARE wasn’t specifically written to interface with syslog, it just happens to be almost exactly the same. That said, setting the port to 514 for syslog, and enabling the syslog headers, makes everything just work.

And that’s pretty much all there is to it. There’s lots of little consideration you need to make when setting all of this up, and if at all possible, you should plan this a little before shooting in and just doing it. If you’re not strapped for time, you may just find a better way to do it for your requirements. For me, this was a simple solution, with minimal time outlay. If I could do it again, I would almost certainly use a Linux server with Syslog-ng.

Considerations:

• Event Log file size
  You might still want to set the size of your event logs to say, 32mb. This allows for a “buffer” so to speak, as sometimes it may just be quicker to open Event Viewer and scroll through events locally. This is definitely the case if you are doing a server health check, as those pretty red error icons don’t show up in syslog.
• Network traffic
  WAN links will probably cop a flogging if you send syslog data across them. I’d suggest not doing this, and setting up branch syslog servers if possible. Furthermore, I haven’t investigated actual network usage as such, it may be worthwhile monitoring the traffic on your network to benchmark this.
• Disk space
  Disks are cheap now, but if you plan on running an old Pentium 4 generic white box with a 20GB disk as a Linux server to run syslog, be aware that your log files will grow quickly, and whilst logrotate can handle rotating these pretty well, it would be beneficial to check how quickly these grow in your environment.
• Auditing policies
  More is less. Don’t tick “full control” for your auditing policy on an object. This will create numerous additional entries in your logs are just plain useless. You don’t want to know about people opening a folder and looking merely at filenames. You might be interested in who opens what file, however. Additionally, the “read permissions” auditing policy is useless also in my opinion. I pretty much only log the basics – writes to an object, permission changes, and deletions – of course, check the object auditing policy options when you tick them for further details.
  
• Action/reaction
  Consider the full version of Kiwi, or, a Linux syslog server. Using the full version of Kiwi allows for actions to be processed when certain messages are logged – i.e. run a command line, send an email, etc. If using Linux syslog, consider using Swatch.
• Group policy / local security policy
  In addition to setting your audit policy on the object itself, you need to enable auditing of Object Access in either a group policy object, or the local security policy. Group policy is handy if you *can* drop all of the servers you want to monitor into one OU, but sometimes the logical organisation of your group policies and your OU’s just won’t permit this without affecting more computers then you need, or not enough.  Local security policy is quick and easy, and takes effect immediately, but, at the loss of being “centrally managed”.
  

source: ashleyknowles - Windows 2003 / 2008 event logging to Syslog