Archive for April, 2009

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 server as a warning: if your logs are not moved off to a central server, you will lose visibility and key evidence on attacks.  This applies to any type of system, whether Windows, Linux, BSD or any other UNIX 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 probably 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 a better case, the attacker does not disable logging and auditing first, opting to clear the event logs later in the attack, providng 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…

What To Look For In A Compliance Report From Logs

Reports from system logs for compliance generally have the same basic requirements regardless of the standard being measured – whether PCI, SOX or FFIEC.  There are some foundational requirements for compliance reporting of logs to be considered effective:

• The data/time are synchronized throughout the environment.  This is vital to be able to correlate events between systems and to real-world events, such as security cameras, badge systems, etc.
• System, security and audit logs are sent to and stored on a system where users/administrators of monitored systems do not have access.   Logs will not be an effective identifier of fraud, theft or other nefarious acts if the perpetrator of those acts has the ability to remove log evidence of his activities.   Subscribing to a Log Management Service is a good way to address this concern.
• Individuals who access controlled systems should not have access to update or modify the scripts and/or software the produces the security reports.

The key elements for compliance log reports are: Read more…

Why Using A Log Management Service Might Be Right For You

There are a growing number of Managed Security Service Providers (MSSP’s), such as IBM and Symantec, and Verisign, and other companies, such as Savvis, offering an outsourced service to collect and retain system logs, generally called a log management service (LMS).  The initial instinct for many would be to reject such a crazy thought as outsourcing log management, but there are some big advantages, and some things to consider. 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.

A Simple Way To Detect Web Server Compromise

When an attacker finds a vulnerability that can be exploited on your site, he normally does a few things:

• Upload some remote control software
• Look for interesting files, or additional sites on the server, etc
• Upload a defacement page, rootkit, iframe browser exploits, or any number of things

You can use your web logs as a burglar alarm to notify you that someone has broken in.  It won’t stop them, but it may give you a chance to.  Here’s how it works:

• Read more…

Creative Use of System Logs to Ensure Policy Compliance

Organizations that need to minimize the risks associated with managing technology infrastructure implement robust policies on access management, change management and the like.

Having robust and well understood policies is important and expected of most organizations.  However, organizations such as the FFIEC expects that financial institutions apply detective controls to affirmatively identify policy violations where ever possible.

Read more…