Keeping logs is an important aspect of maintaining the security of your network, because logs can assist in everything from alerting you to an impending attack to debugging network problems. After an incident has occurred, good logs can help you track down how the attacker got in, fix the security hole, and figure out which machines were affected. In addition, logs can help with tracing the attack back to its source, so you can identify or take legal action against the intruder. In short, log files are worth their weight in gold (just pretend that bits and bytes weigh a lot). As such, they should be given at least as much protection as any other information that’s stored on your servers—even the patent schematics for your perpetual motion machine.
This chapter deals mostly with various ways to set up remote logging, whether you’re setting up a simple central syslogd for your servers to log to, setting up your Windows machines to log events to your syslog server, or using syslog-ng to collect logs from remote sites through an encrypted TCP connection. Using these methods, you can ensure that your logs are sitting safely on a dedicated server that’s running minimal services, to decrease the chance that the logs will be compromised.
Once you have all your logs collected in a central place, what can you do with them? This chapter also covers ways to summarize your logs into reports that are easy to read and understand, so you can quickly spot the most pertinent information. If that’s not fast enough for you, you’ll also learn how to set up real-time alerts that will notify you as soon as a critical event occurs. In some circumstances, responding immediately to an event—rather than waiting around for it to end up in a report that you read the next morning—can save hours of effort.
Finally, you’ll see how to set up a host intrusion detection system (IDS) that goes the extra mile so that you don’t have to; it will monitor your logs, correlate events, and respond to them automatically.
Keep your logs safe from attackers by storing them remotely.
How do you find out when or if an intruder has gained entry into one of your systems? By checking your logs, of course. But what if the intruder modified the logs? In this situation, centralized logging definitely saves the day. After all, if a machine is compromised but the log evidence isn’t kept on that machine, it’s going to be much more difficult for the attacker to cover his tracks. In addition to providing an extra level of protection, it’s much easier to monitor the logs for a whole network of machines when they’re all in one place.
To set up a central syslog server quickly, just start your syslogd with the switch that causes it to listen for messages from remote machines on a UDP port.
Under Linux, do this by specifying the -r command-line option:
# /usr/sbin/syslogd -m 0 -r
Under FreeBSD, run syslogd without the -s command-line option:
# /usr/sbin/syslogd
The -s option causes FreeBSD’s syslogd to not listen for remote connections. FreeBSD’s syslogd also allows you to restrict the hosts from which it will receive messages. To set these restrictions, use the -a option, which has the following forms:
ipaddr/mask[:service]
domain[:service]
*domain[:service]
The first form allows you to specify a single IP address or group of IP addresses by using the appropriate netmask. The service option allows you to specify a source UDP port. If nothing is specified, it defaults to port 514, which is the default for the syslog service. The next two forms allow you to restrict access to a specific domain name, as determined by a reverse lookup of the IP address of the connecting host. The difference between the second and third forms is the use of the * wildcard character, which specifies that all machines ending in domain may connect.
Moving on, OpenBSD uses the -u option to listen for remote connections:
# /usr/sbin/syslogd -a /var/empty/dev/log -u
whereas Solaris’s syslogd uses -T:
# /usr/sbin/syslogd -T
Now, let’s set up the clients. If you want to forward all logging traffic from a machine to your central log host, simply put the following in your /etc/syslog.conf file:
*.* @loghost
You can either make this the only line in the configuration file, in which case messages will be logged only to the remote host, or add it to what is already there, in which case logs will be stored both locally and remotely for safekeeping.
One drawback to remote logging is that the stock syslogd for most operating systems fails to provide any measure of authentication or access control with regard to who may write to a central log host. Firewalls can provide some protection, keeping out everyone but those who are most determined to undermine your logging infrastructure; however, intruders who have already gained access to your local network can easily spoof their network connections and bypass any firewall rules that you set up. If you’ve determined that this is a concern for your network, set up remote logging using public-key authentication and SSL-encrypted connections [Hack #84].