Windows does not natively support either sending logs out as syslog messages. There are a number of applications that will translate Windows Event Logs to syslog. A partial list is:
Why Send Event Logs To A Syslog Server?
There are a few good reasons to export Windows Event Logs as syslog messages. Syslog is a basic format and allows logs from many sources to be normalized, stored in a central repository and analyzed by a common system. Many log analysis engines support the direct pulling of Event Logs, but the mechanism to do so is generally pretty clumsy, requiring a batch process that periodically connects to a share and transfers a copy of the entire log file. Such a process is inefficient if the log files are large, and does not provide the benefit of having the logs moved to a log sever/analyzer real time. Logs sent to a separate log server are not at risk of being lost in the event of software or hardware failure or logical attack on the Windows server in question.
The primary down side to exporting Event Logs to syslog is that Event Logs are structured sets of data and the structure is not cleanly retained as the events are converted into a string of plain text. Generally, though, it is possible to parse out the data with some rudimentary analysis of the converted log messages.
I was just catching up on my reading on Technorati and came across this article that details the ways attackers can cover their tracks upon compromising a Windows server. This article should serve as a warning: if your logs are not moved off to a separate server, you will lose visibility and key evidence in the event of a successful attack. This applies to any type of system, whether Windows, Linux, BSD or any other OS.
I strongly encourage the practice of centralizing logs to a hardened log server. For Windows, there are a bunch of good applications that will export Windows Event Logs out to syslog. I recently took a at logging Windows Events to a syslog server using Snare.
It is important to note that in the event of a successful compromise, the attacker will likely still disable logging and auditing, which will cause the stream of logs to the syslog server to cease. The difference, though, is that the events which were captured during the attack remain on the log server, despite the attacker having deleted the local logs. In the ideal case, the attacker does not disable logging and auditing first, opting to clear the event logs later in the attack, providing more evidence in the centralized logs of what was accessed or modified by the attacker.
There are now a bunch of commercial and open source agents that can run on a Windows system to take in Windows Event Logs and send them off to a syslog server. We’ll be looking at the Snare agent in this post.
As of this writing, Snare is compatible with Windows NT, 2000, XP, 2003 and Vista. There is also an agent available for 64 bit Windows versions.
For my test, I am installing on a Windows XP system. Installation is quite straight forward. There are MSI and scripted installers available on the Snare web site for large scale deployments.
The recommended installation has Snare taking control over the Event Log configuration, to synchronize the configurable logging “Objectives” in Snare with the Event Log settings. Read more…
RSS Error: A feed could not be found at http://www.syslog.org/forum/.xml/?type=rss. A feed with an invalid mime type may fall victim to this error, or SimplePie was unable to auto-discover it.. Use force_feed() if you are certain this URL is a real feed.