LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Security Week: October 20th, 2014
Linux Advisory Watch: October 17th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
Setting up a Linux Log Server to enhance System Security. Print E-mail
User Rating:      How can I rate this item?
Features 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: chl0ie
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 chl0ie@roadrunner.nf.net

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

Comments
Good articleWritten by Sara on 2006-03-21 16:35:39
Good article, chl0ie, this still relavant 6 years later.  
 
I think someone (Al) is jealous.
NiceWritten by Mike on 2006-05-10 18:00:39
Nice article, helped me when I needed it. Slackware still rules.
syslogsWritten by 1triniboy on 2006-07-14 09:58:35
Thank you very much for the info. It was helpful. 
Thanks again
good workWritten by rony on 2006-10-21 07:22:33
really helpful chloie
Updated firewall ruleWritten by Fjor on 2006-11-13 10:18:01
Using the new iptables facility, the logserver rule should be: 
 
iptables -A INPUT -s IP-OF-CLIENT -p udp --dport 514 -j ACCEPT 
 
The --dport option must have two dashes.
Ass Sec AnalystWritten by PenTestr on 2008-09-19 01:50:41
Nice Article with simplisity 
Written by Slayrow on 2009-02-03 10:31:36
Cool !!!

Only registered users can write comments.
Please login or register.

Powered by AkoComment!

 
< Prev   Next >
    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Hacker Halted 2014: Johnny Long Calls for Hackers for Charity Volunteers
RIPS – Static Source Code Analysis For PHP Vulnerabilities
Finding a Video Poker Bug Made These Guys Rich—Then Vegas Made Them Pay
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.