10.3. Securing a Loghost

We have discussed syslogd's ability to both send and receive messages across a network connection using UDP. While we have covered what a loghost is, what logs it should capture, and how it's configured, we still have not examined why they are useful, how to secure them, or where they fit into your network. We answer each of these questions next.

10.3.1. Benefits of a Loghost

First and foremost, a loghost consolidates logs for applications, network devices, firewalls, and other security appliances across potentially disparate networks. There is an obvious benefit here in terms of convenience: from a shell on one system you have access to logs for all systems from which the loghost accepts messages.

In addition to mere convenience, consolidating your logs also improves your security posture. Centralized logging makes it more difficult for intruders to tamper with or remove evidence of their actions. Having logs stored both locally and on one or more remote machines makes logfile tampering much more difficult. Consolidation also facilitates the work of an incident response team. It's easier for members of this team to correlate events and therefore build an audit trail. Increased log integrity brings with it a higher confidence in the results of an audit that this team conducts. Finally, consolidation of high-integrity logs in one location provides a good starting point for automated log monitoring. We talk more about this later in the chapter.

10.3.2. Loghost System Security

A loghost is a critical piece of your network. It contains a record of events across several systems and is the only authoritative source for event information. Capturing syslog messages is neither a CPU intensive nor a memory demanding task, so the temptation exists to couple this functionality with other system services. Keep in mind that the integrity of your logs is at stake. Build a server with redundant storage that does nothing more than collect, manage, and monitor syslogd messages.

In some circumstances a dedicated logging system is for some reason infeasible. Ensure at the very least that you maintain the "infrastructure server" concept as described in Chapter 3: any services provided should not require user accounts for non systems personnel. Bear in mind that every additional service provides another avenue for potential system compromise.

In environments with several systems personnel groups, it may be necessary to build a separate loghost for every group. If possible, avoid creating situations in which an audit trail you are likely to want will be split across multiple loghosts. If users or data can move between a given set of systems, all these systems should ideally use the same loghost.

Keeping in line with the idea that the loghost is a vital piece of systems infrastructure, it's important to protect this system in a variety of ways. The exact steps you take to do this at the network level are beyond the scope of this book. However, consider restricting access via a local firewall, disabling all services other than ssh, and tightening the configuration of sshd. If the machine is only available to select administrators via public/private key authentication, you have significantly increased the integrity of your logfiles.

10.3.3. Syslog Relay

When deploying a system to act as a loghost, it should be well protected from other systems, as described in the previous section. However, a loghost can only be protected so far after all, UDP traffic must be able to get to the system. When dealing with disparate networks, it may seem necessary to permit UDP traffic from all local networks to the loghost on port 514. If you are the firewall administrator, this may make you uncomfortable. Otherwise, if you take this request to the firewall administrator at your organization, you may suddenly discover that she is unwilling to support your logging architecture.

Fortunately, you have options. Just because syslogd accepts UDP packets containing syslog messages, does not mean it must write them to disk. A server can both receive and send messages. In this context, it becomes a Syslog relay. In this case, only one system for each separate network needs to send traffic to the central loghost server. Figure 10-1 depicts a simple network with two distinct network segments.

Figure 10-1. A simple network layout

The demilitarized zone (DMZ) houses systems to which people can connect over the Internet for vital services with one exception: the backup server. This server is not accessible via the Internet, and provides only backup services to the other systems on the DMZ. It's an ideal server to handle the task of being a syslog relay. All systems on the DMZ can send logs to the backup server, which in turn relays the logs to the loghost on the local area "intranet" network. The only firewall rule required to allow for completely centralized logging in this environment is one that permits UDP traffic from port 514 on the backup server to port 514 on the loghost.

10.3.3.1 Syslog relay configuration

Configuring a system to act as a Syslog relay is remarkably straightforward. In short, you must configure it to be a loghost, and also configure it to send logs to another loghost. On FreeBSD systems, be sure that the -s argument is not passed to syslogd in /etc/rc.conf, allowing the daemon to listen for incoming UDP traffic on port 514. On OpenBSD, the relevant flag is -u, specified in /etc/rc.conf.local. This achieves the "configure as loghost" part of the equation.

Second, adjust syslog.conf to send all logs to the loghost by adding a line as shown in Example 10-4. (We assume that your loghost is accessible via the hostname loghost.)

Example 10-4. Sending logs to a loghost

*.*                                                        @loghost

If your syslog.conf file contains no other entries, all logs will be transmitted to the loghost, whether they originate locally or on a remote system. In general, however, it's useful to keep a copy of your system's logs on the system itself. To do this, add lines similar to the following to your syslog.conf after the line specified in Example 10-4.

+myhostname.mydomain.tld *.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages auth.info                                               /var/log/authlog mail.info                                               /var/log/maillog # and so on...

10.3.4. Conclusion

Whether or not a Syslog relay is needed in your environment, building a loghost to consolidate logs is vital. Of course, after you have configured your systems to log locally and send logs to a central server, you can find yourself with a lot of logs sitting around with limited value. Moreover, dealing with the volume of logs on the loghost server can also be a challenge. Fortunately, there are solutions to the log management problem.