logging

Establishing a Hardened Syslog Log Server

Maintaining a reliable and secure repository of logs is important for many reasons: establishing a foresnic trail of evidence in the case of fraud or attack, and enabling event correlation across many devices, among others.  Particularly in regulated industries, management should enact controls that prevent security, application and system logs from being tampered with.

Many organizations choose to consolidate their logs on to a centralized syslog server.  Many devices and just about all UNIX-like operating systems (Linux, free/net/open BSD, Solaris, AIX) support syslog natively.  Windows-based systems require a tool to convert event logs to syslog.

Syslog is a simple protocol and is easy to wrap some very effective security around.  The goal is remove as many opportunities for the central syslog server to be compromised as practical.  There are 3 aspects to hardening a syslog server that we’ll cover:

1. The operating system
2. The network
3. The application
4. The users and administrators Read more…

On The Importance of Centralized Windows Event Logging

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.

Logging Windows Events To Syslog Using Snare

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…

Interesting ssh Brute Force Attack From Botnet

I have been the subject of a pretty persistent brute force attack, where the attacker is attempting to ssh in with thousands of different host names and presumably weak passwords.  Anyone who has run a server for a while has been the subject of such attacks.  Typically, you can see the attack starting with names that start with A and work down to Z.  I do not recall, though, a time where the attack was coming from several (well, hundreds actually) hosts.  The ones I have seen in the past were all from one IP address.  Some times, I would see several attacks running simultaneously from different hosts, but it was clear they were not related. Read more…

Native MySQL support in syslog-ng

So, apparently I’ve been living under a rock.  One of the biggest criticisms I’ve had about syslog-ng for a long time is the terribly convoluted process to get logs into MySQL.  I was looking through the syslog-ng mailing list and saw someone asking for help with getting the script to work for piping logs into MySQL, and the response was something like “why don’t you just use the native support for interfacing with MySQL?”.  Now I’ll need to find something else to complain about.

I have yet to play with this interface, but I’m building a system now to test bed it with.