Set Up a Centralized Server

Creating a central server for system logs makes sense for a couple of reasons. First, any systems that are directly exposed to the Internet are on the front lines, so to speak. If a machine gets compromised, it is important to know what happened . It is likely that the intruder will erase evidence if they can. Keeping logs on a second system will make it more difficult for them to cover their tracks. Second, a centralized server with logs from all networked machines allows administrative staff to keep watch from a single location rather than having to log into all the servers all the time.

Ensure Centralized Logging Dependencies Are Met

Correctly configured network services (DNS and NTP) are helpful in accurate logging. By default a centralized log server will try to resolve the fully qualified domain name (FQDN) of the machines that are sending it information. (You can disable this requirement by adding -x in the configuration.) If the syslog daemon is unable to resolve the address, it will continue to try, which will create unnecessary load and slow logging down dramatically. Likewise, if your systems times are not synced, the centralized log server will put timestamps on events that do not match the timestamps on the machine sending them. This will make sorting events out more confusing than it needs to be, so synchronized time can be helpful in maintaining consistency across the network. By editing /etc/ntp.conf to point at a centralized time source, and by turning on ntpd to run at boot time, you will alleviate timestamp confusion for yourself.

Configure the Centralized Server

syslog can easily accommodate centralized logging. Any server running the syslog daemon can be configured to receive messages from another machine, but by default this option is off. Unless otherwise noted, the following steps will work identically on either SUSE or Red Hat and many other distributions of Linux as well. To enable a server to accept incoming log messages:

Edit the file /etc/sysconfig/syslog. On the line with syslog options, add -r to permit incoming messages, and consider adding -x if you do not have DNS entries for all the machines you want to log. You may also want to change the default mark message to something sensible like 240, which means to make a timestamp every 240 minutes, or 4 times a day. The -- MARK -- message line is an indication that the daemon is running, When you are done the line should look like this:
```
 SYSLOGD_OPTIONS="-r -x -m 240" 
```
Restart the syslog daemon. The changes will not take effect until the syslog daemon is restarted. To restart the daemon without restarting the system, you can execute one of the following two choices in Red Hat:
```
 /etc/rc.d/init.d/syslog stop; /etc/rc.d/init.d/syslog start /etc/rc.d/init.d/syslog restart 
```
In SUSE, use one of the following three choices:
```
 /etc/init.d/syslog stop; /etc/init.d/syslog start /etc/init.d/syslog restart rcsyslog restart 
```
If ipchains or TCP wrappers are used, ensure that connections are permitted to port 514. Port 514 is used by the syslog daemon.

Heads Up

If the network interface security restrictions like iptables or TCP wrappers do not permit connections to port 514, data cannot be logged. Once the network interface will permit connections to port 514, the server is ready to receive incoming messages.

Configure Clients for the Centralized Server

It isn t very hard to set up client machines to a log central location. Edit the /etc/syslog.conf configuration file so that the activity portion uses an @ to point at the logging server, like this:

 authpriv.*                                              @192.168.1.40

Alternatively, you can define a machine in DNS called loghost , which permits you to move the logging to another machine without changing every client machine s syslog configuration. The loghost line would look like this:

 authpriv.*                                              @loghost

Again, you will need to restart the syslog daemon before the changes will take effect. It makes sense to continue to log messages locally to help you debug problems with the server. If you are centralizing logfiles, you can feel free to delete these logfiles as explained in the Manage Logfiles section.