If a break-in occurs and you want to track the cracker down, the system administrator will first check the log files for evidence of a break-in, so she must be 100% SURE that the log files are valid and haven't been tampered with.

Setting up a Linux Log Server to enhance System Security.
Author: This email address is being protected from spambots. You need JavaScript enabled to view it.
Date: August 18, 2000

Preface

Hackers and Crackers. Two words that have placed "ph33r" in the hearts of e-commerice merchants, .com's worldwide, internet service providers and everyone else thats connected to the net. In the age of the Internet, high speed connections and "always online" modem technology, Hackers and Crackers are (as I write this) scanning and probing the internet looking for vunerable machines to break into.

NOTE: REAL (talented) Hackers and Crackers do not normally partake in whats called "Script Kiddie" behavour. Whats a "Script Kiddie"?, perhaps Lance Spitzner describes it best...

"The script kiddie is someone looking for the easy kill. They are not out for specific information or targeting a specific company. Their goal is to gain root the easiest way possible. They do this by focusing on a small number of exploits, and then searching the entire Internet for that exploit. Sooner or later they find someone vulnerable

Some of them are advanced users who develop their own tools and leave behind sophisticated backdoors. Others have no idea what they are doing and only know how to type "go" at the command prompt. Regardless of the their skill level, they all share a common strategy, randomly search for a specific weakness, then exploit that weakness."

They might attack a web server in New York, a mail server in Australia or even a home users machine in Toronto, regardless of WHERE these servers are located, its only a matter of time before someone, skilled or not tries to break in. This type of activity, probing entire networks looking for that one vunerabile machine can be somewhat compared to a pack of lions scouting a herd of wild buffalo looking to attack the weak and the injured.

Introduction

What does all this hacker talk have to do with the subject of todays paper? Well as a hacker myself, I understand how a hacker thinks and how a hacker works. When a hacker breaks into a system, the first thing she will want to do is to hide and stay hidden, not wanting to alert anyone that there system has just been broken into. To do this, most hackers will modify system logs to remove any evidence of there existance. These log files hold critical system information that could place the hacker in jail if shes cought. If a break-in occurs and you want to track the cracker down, the system administrator will first check the log files for evidence of a break-in, so she must be 100% SURE that the log files are valid and haven't been tampered with.

So how can you be 100% sure log files are valid? easy, setup a machine (and old 486 will do just fine) on your network that does one thing and one thing only, it collects logs from other machines on your network. Even if a hacker breaks into your primary system (perhaps your webserver for example) and tampers with the logs, you will still have another set of log files that have NOT been altered in any way.

Before we start: I will demonstrate how to setup a Linux Log Server using Slackware 7.0 but the commands used will work for just about any up to date version of Linux out there. On the command line there are many different ways to execute the same thing, so if the commands listed in this paper do not work for you, try another method. Make sure you have /etc/hosts setup on each machine on your network so other machines know who "logserver" is and its address on your network. A simple echo "192.168.0.2 logserver" >> /etc/hosts will do nicely.

The "client machine's" ip address is 192.168.0.1 and the "logserver's" ip address is 192.168.0.2, both run slackware 7.0 and both belong to a functional, internal network setup with ip masquerading. Also, commands typed at the console will be in bold text.



Configuration

Step #1. Configuring the client machines logging facilities.

The first step when setting up your log server is to configure your linux machines syslog daemon to send there log files to an alternate location, the logserver. /etc/syslogd.conf is the configuration file that controls how linux will log data and where it will log it. Use your favourite text editor (pico or vi for example) and add the following line: 

  [root@slackware]# vi /etc/syslogd.conf

  *.*  [hit tab a few times] @logserver

NOTE: This will tell syslogd to send logs to a machine called "logserver"

Step #2. Restart syslogd on the client machine.

After making your changes, restart syslogd so it will start with its new configuration. 

  [root@slackware]# killall -HUP syslogd

Step #3. Configure your client machines firewall.

If your client machine is running a firewall, then you need to add a rule that will allow outgoing udp packets from the client machine to the logserver.

[root@slackware]# /sbin/ipchains -A output -p udp -i eth0 -s 192.168.0.1 -d 192.168.0.2 514 -j ACCEPT

NOTE: this rule is only for users who are running a firewall on there machine. It allows outgoing udp packets on the client machine (192.168.0.1) on port 514 (syslog port) to the loghost (192.168.0.2). If your not running a firewall, disgard it.

Step #4. Configure the logserver for "remote reception".

Now that we have configured the client's machine to send log files to a machine called "logserver", lets setup the log server so that it accepts incoming logs from other machines. To stop the syslog daemon, you can find its process ID (PID) and kill it, then restart syslogd with "remote reception" enabled. 

  [root@logserver]# ps -aux | grep "syslogd"
  root      1292  0.0  0.2  1404  176 ?        S    Aug10   0:00 /usr/sbin/syslogd

The process ID of syslogd is "1292" so we need to stop syslogd, make the change and then restart it. 

  [root@logserver]# kill 1292 
  (or try kill -9 1292 if the process did not terminate)

Now that the syslog daemon has be shutdown, we can now start it again with "remote reception" enabled. 

  [root@logserver]# /usr/sbin/syslogd -rm 0
NOTE: the -r means "remote reception" and the -m 0 turns of the annoying "--MARK--" timestamp.

Step #5. Verify the logserver's syslog daemon is correctly configured.

Verify that syslogd has been restarted with remote reception enabled by checking /var/log/messages (or /var/log/secure on some systems) 

  [root@logserver]# cat /var/log/messages

Near the bottom you should see..

  Aug 11 21:20:30 logserver syslogd 1.3-3: restart. (remote reception)

Yup it worked. The linux machine called "logserver" is now setup for remote reception of log files from other machines on the network.



Step #6. Configure your firewall.

If your logserver is running a firewall, then you need to add a rule that will allow incoming udp packets from the client machine to the logserver.

[root@logserver]# /sbin/ipchains -A input -p udp -i eth0 -s 192.168.0.1 -d 192.168.0.2 514 -j ACCEPT

This rule is only for users who are running a firewall on their logserver. It allows incoming udp packets from the client machine (192.168.0.1) on port 514 (syslog port) to the logserver (192.168.0.2) If your not running a firewall, disgard it.

Step #7. Verify everything works correctly.

The last step is to verify that everything is working correctly. To do that, log out of your client machine and log back in, then go to your log server and check /var/log/messages (or /var/log/secure on some systems) and you should see the login from the client machine. If something does go wrong, make sure your network is setup correctly (ie are you able to ping other machines on your network? and is /etc/hosts setup on each machine?) make sure you have your log servers syslog daemon setup for remote recetpion (/usr/sbin/syslogd -rm 0) and make sure after you edit /etc/syslog.conf on the client machine you restart the syslog daemon (killall -HUP syslogd). 

  [root@slackware]# logout
  Login: root
  Password: xxxxxxxx

Now check your logservers log file (/var/log/messages or /var/log/secure) and you should see something like this 

  [root@logserver]# cat /var/log/messages

  Aug 14 18:36:19 slackware login[2893]: ROOT LOGIN on `tty2'

NOTE: We are logged onto the logserver and root's login on the client machine showed up in our log files. So everything is working correctly. Congrats.

Conclusion

When setting up a machine to act as your log server, be sure its as secure as possible and that its only collecting logs from other machines on your network. It should NOT do anything other then that. It should not be running XWindows, a web server, ftp server, mail server etc. Make sure that your log server only does what its supposed to do and nothing more.

Just because you have your log files re-directed to a separate machine dose NOT make your logs untouchable but it does however guarantee that you'll have one set of reliable logs and reliability is everything.

Biography:

Chl0ie is a 21 year old, female Linux cracker from Canada who works as a "Micro Computer Support Specialist". Her facination with Linux and Network Security / Network Administration started about 2 years and in March, 2001 she will be attending the Basser Computer Science Department at the University of Sydney, Australia studying "Unix Network Administration and Network Security". You can reach chl0ie at This email address is being protected from spambots. You need JavaScript enabled to view it.

Remember, "Linux is user friendly, its just picky about its friends" :>