logging

Pot Of Syslog-NG Tricks Version 2

Correcting bad or duplicate time and date stamps

Trying to accept logs from applications or devices into syslog-ng, but end up seeing two date and time fields in the resulting log coming out of syslog-ng?  This happens because syslog-ng is not able to understand the format that the date and time stamp arrive in.  Here’s an easy way to fix that problem.  Use a template to only use the “message” part of the incoming log:

source s_net { udp(); };
destination d_file{ file(“/var/log/application.log” template(“$MSG\n”)); };
log { source(s_net); destination(d_file); };

Including the facility & priority of a message syslog-ng output

To add the written form of the facility and priority to logs coming out of syslog-ng, such as “local1:info”, use the following template.

destination d_file {
file(“/var/log/messages”
template(“$FACILITY:$PRIORITY $MSG\n”; template_escape(no))); };

Alternatively, to add the numeric severity, use this:

destination d_file {
file(“/var/log/messages”
template(“$PRI $MSG\n”; template_escape(no))); };

Configuring syslog-ng as a relay

Syslog-ng is pretty straight forward to configure as a relay.

source s_net { udp(); };
destination d_net{ udp(“192.168.0.1″ port(514)); };
log { source(s_net); destination(d_net); };

Designing A Log and Event Monitoring Program

Ultimately, as with all IT security programs, log monitoring programs are designed to address risks to data confidentiality, integrity and availability.  Risks come in many types:

• Hardware failure
• System compromise
• User error
• Rogue administrator

An organization’s program around log & event monitoring needs to be based on the specific risks that exist in that organization.  Consider two these two scenarios:

Scenario 1: The IT department of a large public corporation manages a large number of critical business systems, including systems that contain the company’s financial information, payroll information and client data.  This company cares deeply about the confidentiality, integrity and availability of it’s applications.

Scenario 2: A small Internet-based retailer of custom soaps is owned by a family.  Dave, a member of the family that owns the business, is technically savvy and has colocated a server to run the retailer’s web site.  Dave manages the server and the web site.  Dave also cares deeply about the confidentiality, integrity and availability of his company’s web site. Read more…

Running Syslog-NG on Windows

This post describes running syslog-ng as a server on Windows.  In another post, we describe how to send Windows Event Logs to syslog.

There are many great commercial syslog servers for Windows.  There are not many options for those looking for a free alternative.  One option is Aonaware.  Another option is to install syslog-ng through cygwin.  Cygwin is a Linux-like environment run inside a windows command shell.  Cygwin runs on all current desktop and server versions of Windows.  In this post, we will walk through setting up syslog-ng on a windows host.

1. First, visit the Cygwin website to download the setup.exe application.  Save, then run setup.exe.
2. Choose “Install From Internet”
3. Select the directory to install into and the user to install for (leave this as “all users”).
4. Enter the directory for local packages. Accepting the default location is fine.
5. Choose your Internet connection type (direct or proxy)
6. Select a site to download from.  Any one should be fine.
7. At the “install packages” window, type is “syslog” in the search box.  You will see “Admin” below.  Expand the admin section, and you will see syslog-ng.  Click the word “skip” until you see 3.0.1 (or whatever the latest supported version is).
8. Also choose the following packages:
   1. Admin/cygrunsrv
   2. Editors/VIM
   3. Gnome/glib
9. Finish the installation. Read more…

Pot Of Syslog-NG Tricks Version 1

Fixing Duplicate Date and/or Hostname Problems

Some devices send syslog messages with improperly formatted headers, which can cause syslog-ng to append a new set of header information, meaning that the host name and/or date appear twice in the logs.  A simple way to solve this is using a template:

source s_net { udp();};
destination d_file { file(“/var/log/file.log” template(“$MSG\n”)); };
log {source(s_net); destination(d_file); };

The template function in the destination definition tells syslog-ng to discard the header from the received message and only keep the actual message data, which is contained in the variable $MSG.   Syslog-ng inserts the proper header, using the date the log was received and the host the log came from, resulting in a normal syslog message. Read more…

Configuring SUDO for Effective Activity Monitoring Via Syslog

I have discussed in previous posts the importance of administrators using SUDO to provide individual accountability.  SUDO provides command-by-command accounting of actions performed by administrators, with logs sent as standard syslog events looking like this:

Feb  4 19:23:23 bsd sudo:    jerry : TTY=pts/0 ; PWD=/usr/home/jerry ; USER=root ; COMMAND=/bin/ps -x
Feb  4 19:23:34 bsd sudo:    jerry : TTY=pts/0 ; PWD=/usr/home/jerry ; USER=root ; COMMAND=/usr/bin/vi /etc/passwd
Feb  4 19:23:59 bsd sudo:    jerry : TTY=pts/0 ; PWD=/usr/home/jerry ; USER=root ; COMMAND=/usr/bin/tail -100 /var/log/messages

We can see pretty clearly all the actions I took above: the user “jerry” performed a number of actions, including one that is potentially concerning: vi /etc/passwd.  The action on /etc/passwd requires some investigation.

First, we need to be sure that an administrator can’t cover his tracks by deleting logs.  This is best accomplished by streaming the logs to a hardened syslog server, where the administrator doesn’t have the ability to delete logs.  Read more…

Segregating Logs From Different Log Files On A Centralized Log Server Using Syslog-NG

In this post, I will demonstrate a way to capture logs from a series of log files, and relay those logs to a central log server, where the logs will be separated into log files, as they existed on the original host.

Reading from files

Syslog-ng has the ability to pull log data from files, then treat those logs as any other source, like this:

source  s_file_abclog { file(“/var/log/abc.log” follow_freq(1));};

In this way, you can handle log data from applications that do not have native support for syslog.

Then, you can send that data to a central log server, like this:

source  s_file_abclog { file(“/var/log/abc.log” follow_freq(1));};

destination d_remote{udp(“192.168.0.3″ port(514)); };
log { source(s_file_abclog); destination(d_remote);}; Read more…

Configuring The Snare Windows Client And Syslog-NG To Work Together

In a previous post, we looked at installing Snare to log Windows events to a syslog server.  Here, we will configure syslog-ng to accept messages from Snare and implement a few simple customizations, including storing the logs in individual files.  We will assume that Snare is operational for the purposes of this guide.  Please see the post referenced above for help with installing Snare.

For this test, I am running syslog-ng 3.0.1 on FreeBSD 7.1 and Snare 3.14 on Windows XP.

First, we will start with a very basic configuration that logs to /var/log/messages:

source src {
internal();
udp(port(514));
};
destination messages { file(“/var/log/messages”); };

log {source(src); destination(messages);};

Read more…

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…