As a Windows NT/2000 Infrastructure Engineer in my past life (while working for a major search engine) I found myself scratching my head when I was told that Windows was not a currently supported device. My reaction beyond was: “Well... wait, what?” I couldn’t fathom why we were not logging the biggest gorilla in the server market. But of course... that was over three years ago, and things have changed quite a bit.

LogLogic now, and for the last 2+ years, has had full Windows parsing support, but the question often comes... “How does LogLogic gather Windows logs?”

    This blog entry is a short piece to talk about the options available currently for Windows logging, and some of the challenges you may face, with, or without, a LogLogic appliance.

    While the rest of the free-world received the memo on using syslog (which is UDP based), and syslogNG (which is TCP based) and pretty much a standard on the side of unix/linux and network devices, Microsoft (as always) went and decided to do things differently. (Not “Think Different” but rather “Think Proprietary.”)

    Instead of using an industry standard Microsoft decided that logging Windows events only to the local machine was a better approach. They created the Windows Event Viewer which stores the two piece events local on the machine. Which leads me to my next piece.

What’s a windows event comprised of?

Well, Windows events are a two piece unit. The header, or top half of the windows event, is some very basic information about the event. It gives you information about the event such as date/ time/ action/Windows Event ID/, etc.

The second part is the body. The paragraph in the body of the event is actually read from a string-dll somewhere on the drive which gives a description of the event. The Windows Event Viewer looks at the registry for the location of the .dll, and then reads directly from the actual .dll on the hard disk. They appear as one event in the event log.

Challenges with the Windows Event Viewer:

Now, my frustration with Windows storing all of the Windows events locally is that if a Windows server goes down, you do not have a reference or central correlation point to figure out what had broken the box. Instead, you need to get the Windows operating system up and running before you can actually look at the log data, and figure out the root cause of why it had broken. In my own humble opinion, this is putting the cart before the horse. Fix the machine to get the logs but I need the logs to troubleshoot the problem with the machine. A classic catch 22.

The way syslog works is log-messages are written to a central log-file (each flavor of UNIX/ Linux has a different repository often found in /var/log and then they are sent over the wire to one or more destinations that the administrator has chosen.

Why is this beneficial?

Well, central correlation of windows logs can help you figure out the scope of a breach or track user activity (via source IP or account username if you like), helps you keep an eye out for problems that may take place silently or under the radar which can hurt you. Event  such as a full hard drive, or a service which is flapping. Windows, when it creates an error event, either dumps a message into the GUI or into the Event Viewer. If you don’t log into the box very often, you can be blind-sided when your backups fail, your MS SQL DB runs out of space, your tables begin getting corrupted, or your application doesn’t have anymore swap space... which could then causes the box to go down. It’s best to know these things when they happen vs. finding out afterward that a catastrophic failure could have been avoided.

So, how do I get Windows events to my syslog server or LogLogic appliance? Here are a few options that I’ve tested.

SNARE by Intersect Alliance:

Snare is very light-weight application that was offered under the GPL. It comes free of charge for the low-end version, and there’s a paid version with more features.

    SNARE installs as an agent, and has a basic UI that you can use to configure and re-start the service. It installs quick and easily and converts windows events to UDP based syslog. You can do some filtering straight from the GUI, and is very quick to send syslog messages to its destination, however it only sends new messages that are created. There’s no way to log any previous events.

    The bad news is that you don’t have the ability to grab all of the older Windows Events from the Event Viewer in addition to the new ones as they happen. It also doesn’t keep a watermark so if the software re-boots, or the destination is unavailable, UDP syslog messages will just push their way out the door, and never look back. You have to specify TCP which is an option.

    If you are bound by ANY compliance requirement (PCI, HIPAA, SOX, NIST, GLBA, etc.) you can’t just lose logs if a destination appliance goes down, or your service re-starts. You need to save 100% of log data. Period. Also, I mentioned it’s an agent. As a former Windows Engineer, the thought of rolling out an agent to well over 200 servers just did NOT appeal to me. That was too resource intensive both for the team who had to do the roll-out and the local machine resources we needed for the agent to run.

Lasso by LogLogic:

Now keep in mind that I had a part in the development of the Lasso software, so I’m  biased, but part of the reason Lasso is where it is, is because we at LogLogic saw the inefficiencies of the other options, and built an all encompassing solution that was as versatile as possible. We played with everyone else’s toys to see what features we needed/wanted, and road-mapped them. We’re building the best Windows event collector, one dot release at a time.

So... Lasso can be used in two separate ways. One is as an agent, and the other as an agent-less client-server application. The agent mode is very straight forward. Lasso monitors itself, and forwards any logs to the destination of your choice. It’s very straight forward.

Now, the beauty of Lasso lies in a few particular features.

Lasso can pull ALL log-data in the event logs. That’s not just the real-time creation of logs that are sent, but rather, the logs which have been in the event viewer for a while.

Lasso also transfers via TCP only, and can queue up those messages on the local Lasso client/server to hold until the destination becomes available.

Lasso is open source and is available on Sourceforge from the following link: http://sourceforge.net/projects/lassolog

Ntsyslog

This is a great freeware application for converting windows event log s into syslog. This was designed to work with both Windows NT and Windows 2000. They also have a version for XP that I tested. So, much like SNARE for Windows, the Ntsyslog is a service, with a lightweight gui which can filter the log-data you send, and sends that data in real-time. No collection of the previous log-data. The only trouble I saw with this agent was the format with which the logs arrived. These logs ended up in general syslog on a LogLogic appliance, as the format was not recognized as Windows. It still might be useful for moving NT logs over to either LogLogic or a syslog server of your own. Other than that it was a great little utility, it’s freeware, and you can find here: NtSyslog

Winlogd

Description - Winlogd is a syslog client for Windows that allows the Event Log to talk to syslog. Now, I can’t vouch for this product, as I wasn’t able to install it. The installer was complaining about a missing .DLL, and the box I was using to test was a brand-new clean install. You can give it a shot. It is freeware, and you can find the URL here: Winlogd