Case Study In Not Managing Logs: DigiNotar

I started a new security podcast recently and in the first episode, I covered the security breech at DigiNotar, the Dutch certificate authority.  One of the prominent findings in the forensic report that was released publicly was the unreliability and unavailability of logs – because, in one case, an administrator erased logs on a server to free up space, and in others, the attacker deleted logs to cover his tracks.  Forwarding ALL logs, whether from Windows systems, firewalls, switches, etc, to a central logging server with very limited access is very key to both forensic analysis after an attack, but also proactive alerting that might indicate an attack is underway, giving time to react before data is lost or damaged.

Be the first to comment - What do you think?  Posted by admin - December 8, 2012 at 4:14 pm

Categories: Logging, Security   Tags:

The Importance Of Remote Logging

Many people will recall the downfall of the Dutch Certificate Authority DigiNotar last year after it was discovered that attackers had compromised the CA’s servers and generated illicit certificates for some major internet sites.  Fox-IT was contracted to investigate the breach and has issued it’s final report.  A notable element in the report was that DigiNotar stored it’s log files on the servers themselves.

The news article on Threatpost includes an except from the report:

“The investigation by Fox-IT showed that all eight servers that managed Certificate Authorities had been compromised by the intruder. The log files were generally stored on the same servers that had been compromised and evidence was found that they had been tampered with. Consequently, while these log files could be used to make inconclusive observations regarding unauthorized actions that took place, the absence of suspicious entries could not be used to conclude that no unauthorized actions took place,”

This really highlights the importance of moving logs to a different server for storage and analysis.  If you aren’t pushing your logs to a logging server, please consider doing so.

Be the first to comment - What do you think?  Posted by mutex - November 1, 2012 at 3:58 pm

Categories: Logging   Tags:

Instructions For Tunnelling Syslog Over SSH Using Syslog-NG

Here’s an interesting article on establishing an ssh tunnel between a client and syslog server for the purpose of securely transmitting syslog messages.

Be the first to comment - What do you think?  Posted by mutex - July 4, 2012 at 5:23 pm

Categories: Logging   Tags: ,

Good Writeup On Implementing A Log Analysis System With Open Source Tools

This post introduces an end to end solution for analyzing logs using:


Graylog2 (though the post points out that Graylog2 hasspoke shortcomings)




Be the first to comment - What do you think?  Posted by mutex - June 17, 2012 at 10:54 pm

Categories: Logging   Tags: , ,

Recent Articles On Logging Standards

There have been a few interesting articles on logging standards recently. First is this one from Dark Reading on the state of logging standards.

Next, is an article from Network World on Mitre’s Common Event Expression (CEE).

Be the first to comment - What do you think?  Posted by admin - April 20, 2012 at 10:45 am

Categories: Logging   Tags:

Samoa’s Time Zone Change Shows The Downside To Using Local Time For Time Stamps in Logs

Naked Security has a good post about Samoa’s move across the international date line.  Using a single time base can be very valuable in recreating the history of an event or incident.  Even if the clocks of all systems are synched using NTP, stitching together logs from systems in different time zones can be tedious, and such a thing generally happens as the result of something bad, where time is of the essence.  The Naked Security post points out that there is even more peril than previously thought in using local time, when the local time changes due to some legal mandate.

Sadly, Samoa is going to completely miss my birthday this year.

Be the first to comment - What do you think?  Posted by admin - December 30, 2011 at 12:45 am

Categories: Log Management, Logging   Tags:

Logging and Syslog Best Practices

In this post, I will cover a basic set of best practices for managing logs. Depending on your specific objectives, regulatory requirements, and business constraints, there are likely to be a number of additional best practices.

  • Forward syslog messages from clients to a secure syslog server.
  • Enable NTP clock synchronization on all clients and on the syslog server. It is very important for all systems
    reporting logs to be using the same time server, so that logs are all synchronized. Without doing this, it can be difficult or impossible to accurately determine the sequence of events across systems or applications.
  • Group “like sources” into the same log file. (i.e. mail server, MTA, spamassassin and A/V scanner all report to one
  • Use an automated tool to establish a baseline of your logs and escalate exceptions as appropriate.
  • Review your records retention policy, if applicable, and determine if anything kept in logs falls under that policy. If so, establish retention periods based on the records policy.  Legal requirements for keeping logs vary by jurisdiction and application.
  • The “sweet spot” for log retention appears to be one year.  Shorter than 1 year, and it is likely that key data would be unavailable in the wake of a long running attack, and longer than one year is most likely wasting disk space.
  • Include logs and log archives in a standard backup process for disaster recovery.
  • Change read/write permissions on logs files so they are not accessible to unprivileged user accounts.

Have more suggestions for logging best practices? Post them in a comment below.

16 comments - What do you think?  Posted by admin - October 4, 2010 at 9:16 pm

Categories: Compliance, Log Management, Logging, Policy   Tags:

Reading Logs From A File In Syslog-NG

I had previously written a little snippet on how to pull logs in from a file, however there is a substantial amount more to consider when configuring syslog-ng to read from a file, so I have dedicated this post to reading logs from a text file.

The basic structure for reading logs from a text file looks like this:

source s_file {

destination d_messages{

log {

The source file driver has a lot of options which can you help to tailor the import of logs into syslog.

One of the first, and most important settings to consider when reading logs in from the file is the “flags(no-parse)” option on the source file statement.  By default, syslog-ng expects the lines in the text file being read to be in the format of a syslog message, and will attempt to parse out the relevant fields, like date/time, severity, program, etc.  However, most applications that write custom log files don’t use a standard syslog format, and so we need a way to tell syslog-ng that the whole log record in our log file is the “log message”, and not a syslog-formatted message.  We accomplish this with the “flags(no-parse)” option, which looks like this in the config file: Read more…

15 comments - What do you think?  Posted by admin - July 25, 2010 at 11:28 am

Categories: Logging   Tags:

Pot Of Syslog-NG Tricks Version 3

Retaining the original hostname of the origin of syslog messages through a Syslog-NG relay

In some environments, syslog messages are concentrated and relayed through an intermediate syslog server.  One of the big deficiencies of the stock syslogd that comes with many Linux/UNIX operating systems is that they don’t provide the ability to keep the hostname or IP address of the original sender of the syslog message as it is transmitted through the syslog relay server.  Syslog-NG provides an option that, when used on the relay server, retains the host name of the originating system.  A basic relay syslog-ng.conf file might look like this:

source s_net { udp(); };
destination d_net { udp(“”); };
log { source(s_net); destination (d_net); };

Simply adding the keep-hostname(); statement to the source definition tells syslog-ng to retain the original host’s name in the syslog message as it is relayed through.  The resulting config file would look like this:

source s_net { udp(keep-hostname();); };
destination d_net { udp(“”); };
log { source(s_net); destination (d_net); };

And that’s all there is to it. Read more…

3 comments - What do you think?  Posted by admin - April 15, 2010 at 1:55 pm

Categories: Logging   Tags:

Log Analysis and Log Correlation Basics

Log data can provide benefits beyond the obvious notification of system events and security happenings.  Aggregated logs from a system or from multiple systems can provide a more complete picture of problems when those logs are correlated together.  To any experienced administrator, this is obvious.  Consider the following environment:

Read more…

14 comments - What do you think?  Posted by admin - March 15, 2010 at 3:54 pm

Categories: Log Management, Logging   Tags: ,

Recent Posts in the Syslog Forum

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.

Next Page »