Are you new here? Subscribe to my RSS feed. Thanks for visiting!

One very important aspect of computer security and hack prevention is the collection and assessment of system log files. In the mind of a hacker, when gaining unlawful entry to a system their first instinct is to cover all traceable tracks. This means deleting log files and possibly even setting up backdoors to enter again at will sometime later in the future. It is important, as a system administrator, to ensure that even if your system has been broken into or tampered with, that you have traceable evidence to figure out exactly what went wrong, and where it went wrong. Hackers tend to tamper with system logs making this sometimes impossible to figure out. Setting up a remote syslog server for all of your servers to send their logs to is how we can ensure that your logs will be completely accurate and un tampered with.

The syslog server configured in this example is an old 486 with an 8GB hard drive, running Slackware Linux 10.2. However, the configuration and commands will work for just about any Linux distribution.

Configuring the syslog server:

The first thing that needs to be done is to set up the syslog daemon (syslogd) to run with remote reception. Here is how that is done:

A (Any distribution): You can locate the PID for syslogd by typing ps -aux | grep “syslogd” and then killing the PID.

root@syslog:~# ps aux | grep syslogd
root 4873 0.0 0.2 1432 596 ? Ss 10:00 0:00 /usr/sbin/syslogd
root@syslog:~# kill -9 4873

Once the process is killed, you need to restart syslogd with the remote reception flag, to allow for incomming logs.

root@syslog:~# /usr/sbin/syslogd -r

B (Slackware Specific): Edit the /etc/rc.d/rc.syslog file.

#!/bin/sh
# Start/stop/restart the system logging daemons.
# Written for Slackware Linux by Patrick J. Volkerding .
syslogd_start() {
if [ -x /usr/sbin/syslogd -a -x /usr/sbin/klogd ]; then
echo -n “Starting sysklogd daemons: ”
echo -n “/usr/sbin/syslogd rm 0″
/usr/sbin/syslogd -rm 0
sleep 1 # prevent syslogd/klogd race condition on SMP kernels
echo “/usr/sbin/klogd -c 3 -x”
# ‘-c 3′ = display level ‘error’ or higher messages on console
# ‘-x’ = turn off broken EIP translation
/usr/sbin/klogd -c 3 -x
fi
}

syslogd_stop() {
killall syslogd 2> /dev/null
killall klogd 2> /dev/null
}

syslogd_restart() {
syslogd_stop
sleep 1
syslogd_start
}

case “$1″ in
’start’)
syslogd_start
;;
’stop’)
syslogd_stop
;;
‘restart’)
syslogd_restart
;;
*)
echo “usage $0 start|stop|restart”
esac

Once the file is saved, restart syslogd by typing:

root@syslog:~# /etc/rc.d/rc.syslog restart

After configuring syslogd to allow remote reception, we now have to tell the server to accept the incomming UDP packets from the server(s). This is done using iptables.

root@syslog:~# iptables -A input -p udp -i eth0 -s 10.0.0.53 -d 10.0.0.210 –dport 514 -j ACCEPT

This rule says that the client machine (10.0.0.53) is allowed to send UDP packets to the syslog machine (10.0.0.210) via port 514, the syslog port. You will need to add a rule for each client machine, by replacing the 10.0.0.53 IP.

Configuring the client machines:

The first step is to tell syslogd on the client machine to send the logs to the new syslog server. Do this by editing /etc/syslog.conf and then restarting syslogd:

root@client:~# vim /etc/syslog.conf
# Added by Adam K. to send logs to the syslog server
*.* @10.0.0.210
root@client:~# killall -HUP syslogd

Now we must tell the client machine (10.0.0.53) to allow the output of UDP packets to the syslog server (10.0.0.210).

root@client:~# iptables -A output -p udp -i eth0 -s 10.0.0.53 -d 10.0.0.210 –dport 514 -j ACCEPT

Once that is done all you need to do now is test.

Restart syslogd again on the client machine, and you should see a message appear in /var/log/messages on the syslog server.

root@client:~# killall -HUP syslogd

root@syslog:~# tail /var/log/messages
Aug 1 10:50:27 client syslogd 1.4.1: restart.

And your all done!

Keep in mind that this is a log server and should be hardened to the fullest extent. You do not want to allow access to from the outside for anything other than logging, and you want to make sure everything is secure. Otherwise, you are defeating the purpose of having a syslog server to begin with.

Good luck and happy logging!

Popularity: 11% [?]

Sponsors