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

The Operating System

Hardening

• The first step is to research a hardening guide for your operating system.  Search google for “hardening X”, where X is the name of your operating system, such as Redhat, FreeBSD, etc.
• Generally, you will want to disable just about every service execpt for sshd and the syslog server process.
• Do not run a local dns server on the system.  This can be a source of compromise if an exploit is found.

Management Processes

Key processes need to be maintained to ensure the integrity of the log server.  We won’t go into detail on how to accomplish these, as any mature IT organization will have functioning version of these processes.

• Patch Management
• Vulnerability scanning
• User Account Management
• Control of root access

The Network

Segregate the syslog server from the rest of the network servers with a firewall.  On the firewall, we will want to open just the port needed for syslog logs to flow from clients to the server – generally UDP/514.  Opening other ports, such as SSH may be desirable, but will increase the exposure of the server.  An alternative approach is to require authentication to the segmenting firewall, which will enable an additional set of ports, such as SSH.  We will, of course, want to log the authentication successes and failures.  Additionally, we will want to prevent the syslog server from initiating any connections outbound to the Internet.

Firewall rule summary:

• Deny all ports in to syslog server
• Allow UDP/514 to the syslog server
• Allow TCP/22 to the syslog server if authenticated
• Deny all ports outbound from the syslog server
• inbound/outbound ports requires to support authentication system (such as RSA) – Optional

The Application and Protecting the Logs

• Run syslog service in chroot environment
• Configure the syslog service to store logs in partition that is writable only to the syslog user.
• Create a script, to be run via cron as root, to move logs out of to the area accessible to syslog user, preferably on a daily basis.

The Users and Administrators

• Separation of duties – administrators with access to the syslog server should not also perform administrative duties on other servers.
• Authentication – Users should be required to use a 2 factor authentication system, such as RSA one time tokens.

Summary

What is described here is probably far beyond what most organizations will want to implement to protect their logs.  This should serve as a list of “best practices” that can be implemented, depending on the perceived threats in a given organization.  Logs are very critical, and serious consideration should be paid to each of the recommendations.  The depth of protections that may need to be applied to a logs provides a good example of why a Log Management Service should be considered.