Linux DevCenter    
 Published on Linux DevCenter (http://www.linuxdevcenter.com/)
 See this if you're having trouble printing code examples


Tools of the Trade: Part 3

by Carl Constantine
07/13/2001

Welcome back! Today I'm going to take a look at some of the common tools that you can use on your own systems to spot holes, to look for potential problems, and tighten your grip on the system.

Last time, I took you through a brief introduction to tcpdump and Tripwire. This time, we'll take a look at syslog and last but not least, snort.

Syslog

Have you ever looked in your /var/log directory and wondered, "Where'd all those log files come from?" Chances are they were created by syslog, the system logging facility. syslog actually consists of a couple different tools that were originally part of the BSD distributions.

syslog has been ported to Linux and many other Unix operating systems (Solaris, HP-UX, etc.) and keeps all the same functionality of the original program. In some cases, a few functions have been added but nothing has been removed. I would consider syslog to be more of a "system" rather than a tool.

There are four parts to syslog; a syslogd daemon process, a klogd daemon process, a programming interface syslog.h, and a configuration file /etc/syslog.conf which is the key to the whole system. The programming interface is used by many other programs, such as Tripwire, to log activity on your system. Unless you're writing a security tool, or want to incorporate syslog in some other application you are writing, you won't use the programming interface.

The main crux of the syslog system is the /etc/syslog.conf file. It controls what logs are created and when. A separate utility that isn't part of syslog (but maybe should be) called logrotate will compress logs and create new ones on a daily basis or however long you want. The result is something that looks like this:

Screenshot.

syslog's configuration file is relatively simple to read and modify as you see fit. Let's take a quick look.

Comment on this articleWe're looking for tips and pointers on effective use of syslog and snort.
Post your comments

Previously in this series:

Tools of the Trade: Part 1 -- In this first of a three-part series, Carl Constantine covers tools and techniques that system administrators can use to protect their networks, including discussion of nmap, Ethereal, and how to set up honey pots.

Tools of the Trade: Part 2 -- In the second part of this ongoing series, Carl Constantine shows you how to use tcpdump and Tripwire to protect your Linux server.

syslog.conf

The syslog.conf file is used by both syslogd and klogd. It consists of three parts. The first is the log file type (called a facility) you want to keep, the level (or priority) at which you wish to log events, and an action to take -- basically where you want the log to go. Both the facility and priority are case sensitive so be careful what you type. The log type, or facility, can be one of the following:

There are a couple others but they should not be used. The priority for the log level can be one of the following:

Again there are a couple others, but they should no longer be used. syslog also supports the use of wildcards in the configuration file. So for example, you can log all mail logs regardless of the priority or all priorities regardless of the log type. Let's look at a small section:

#  /etc/syslog.conf	Configuration file for syslogd.

# First some standard logfiles.  Log by facility.

auth,authpriv.*              /var/log/auth.log
*.*;auth,authpriv.none       /var/log/syslog
#cron.*                      /var/log/cron.log
daemon.*                     /var/log/daemon.log
kern.*                       /var/log/kern.log
lpr.*                        /var/log/lpr.log
mail.*                       /var/log/mail.log
user.*                       /var/log/user.log
uucp.*                       /var/log/uucp.log

In this example, I'm logging authorizations to /var/log/auth.log, and mail logs to /var/log/mail.log, but I'm not logging cron messages as that line is commented out. As an added bonus, I'm logging everything (*.*) to /var/log/syslog.

Well, this is all very nice, but all the logs are located on the local system. If a black hat gets into your system, deleting the logs behind him will be the last thing he does as he heads out the door. To help prevent this, you can log to a remote host by using "@hostname" in the action section of the log. For example:

#  /etc/syslog.conf	Configuration file for syslogd.

# First some standard logfiles.  Log by facility.

auth,authpriv.*           @logger
kern.*                    @logger
lpr.*                     @logger
mail.*                    @logger

Here, I'm logging all authorization, kernel, printing, and mail logs to a remote machine called logger. Logger must be defined in /etc/hosts. You can use this to send logs from several machines to a single machine on your network.

Having a central log host may not be enough to stop a determined cracker. You might want to take added protection by having hard copy printouts of your log files or sending email to your logs to various IDs. You can do this using cron or a utility such as logrotate. I highly recommend logrotate.

There is much more that you can do with syslog. You can restrict logging to certain logs for example. Here's a full syslog.conf file for your perusal. Check it against the man page for syslog.conf and see if you can figure out all it's doing.

#  /etc/syslog.conf	Configuration file for syslogd.

# First some standard logfiles.  Log by facility.

auth,authpriv.*           @logger
*.*;auth,authpriv.none    @logger
#cron.*                   /var/log/cron.log
daemon.*                  -/var/log/daemon.log
kern.*                    @logger
lpr.*                     -/var/log/lpr.log
mail.*                    /var/log/mail.log
user.*                    root, joeuser
uucp.*                    -/var/log/uucp.log

#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info           -/var/log/mail.info
mail.warn           -/var/log/mail.warn
mail.err            /var/log/mail.err

# Logging for INN news system
#
news.crit           /var/log/news/news.crit
news.err            /var/log/news/news.err
news.notice         -/var/log/news/news.notice

#
# Some `catch-all' logfiles.
#
*.=debug;\
  auth,authpriv.none;\
  news.none;mail.none   -/var/log/debug
*.=info;*.=notice;*.=warn;\
  auth,authpriv.none;\
  cron,daemon.none;\
  mail,news.none        @logger

#
# Emergencies are sent to everybody logged in.
#
*.emerg				*

#
# I like to have messages displayed on the console, 
# but only on a virtual console I usually leave idle.
#
#daemon,mail.*;\
#  news.=crit;news.=err;news.=notice;\
#  *.=debug;*.=info;\
#  *.=notice;*.=warn	/dev/tty8

# The named pipe /dev/xconsole is for the `xconsole' 
# utility.  To use it, you must invoke `xconsole' 
# with the `-file' option:
# 
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if 
# you have a reasonably busy site..
#
daemon.*;mail.*;\
  news.crit;news.err;news.notice;\
  *.=debug;*.=info;\
  *.=notice;*.=warn	|/dev/xconsole

Before I leave syslog, remember that many other tools such as Tripwire and snort can use the syslog facility. I recommend you check out how to implement logs in the tools you choose to use on your network.

Snort

Last but not least, we come to the venerable snort. snort is developed by Marty Roesch (with many other developers now participating), and is based on the same libpcap utility as tcpdump. It works on any form of Unix and also has a Windows client. Because of snort's power and flexibility, it's fast becoming the intrusion detection system of choice by many people. The nice folks at HoneyNet Project advocate snort.

snort is a nice lightweight utility that packs quite a powerful punch. It can perform real-time traffic analysis and packet-logging on IP networks, protocol analysis, content searching/matching, and can detect many different attacks and probes. Like many other utilities, snort uses a rule-based language to describe traffic that it will collect or pass and also includes a detection engine with a plug-in architecture to further expand on snort's capabilities.

The web site, www.snort.org has a rule creation system so you can develop your own rule sets. In addition, you can download literally thousands of different filters from the web site that were contributed or developed by the security community.

snort can be used in three different ways: as a packet sniffer like tcpdump, a packet logger, or a full-blown intrusion detection system (IDS). snort will create files in tcpdump binary format or its own ASCII-based format and can even log to an XML file. Additionally, there are a few different add-ons to snort to make logging and interpreting the data somewhat easier.

A simple snort command might look something like this:

snort -i eth1 -A fast -l logdir -F filterfile -c rulefile

The first thing to note is snort can only be run by the root user. As for the rest of the command, it breaks down as follows:

-i

The interface to read from. If none is specified, the default interface (usually eth0) is used.

-A

Stands for "Alert Mode." snort can use one of four modes: fast, full, none, and unsock. "Fast" writes the alerts to the default "alert" file in a single-line style. "Full" does the same, but writes out the full decoded header as well as the alert message. "None" turns off alerting. "Unsock" stands for Unix socket and is an experimental mode to send alerts over a standard Unix socket to anther machine. Note: you can achieve the same task by logging to syslog and having syslog send the log to a remote machine.

-l

Tells snort to log all output to the directory specified by logdir. All plain text alerts and packet logs go into this directory. The default directory is /var/log/snort.

-F

Uses the filters file specified by filter file. The filter file is in the same format (called BDF or Berkley Packet Filter) as a tcpdump filter file.

-c

Reads the ruleset specified by rule file.

If you've already captured packet data using tcpdump or some other tool that supports the tcpdump binary format, you could process the file with this command instead:

snort -A fast -l logdir -F filterfile -c rulefile -r TCPdumpfile

In this example, I'm telling snort to get its input from TCPdumpfile using the -r option instead of specifying an Ethernet interface. \

Snort rules

Snort stores all its configuration files in /etc/snort by default. All the rules are also stored in this directory. Let's take a look at a couple rules.

alert tcp 24.80.0.0/17 any -> 48.0.0.0/16 666 (msg:"The beast is coming!!!";)

This rule generates an alert on any TCP packet with a source IP in the range 24.80.0.0 through 24.80.127.255 (any port) with a destination IP in the range 48.0.0.0 through 48.0.255.255 (port 666). The alert record is labeled "The beast is coming!!!".

Why would you do this? Well, say you know that a cracker is trying to gain access to your system. However, the intruder seems to never be at the same machine twice (he's using DHCP, for example) but you've seen attempts from various IP addresses in the source range. Not only that, the intruder has tried similar attacks against several of your systems in the destination range. Here's one from the snort distribution itself:

alert tcp any any -> $HOME_NET 25 (msg:"Happy 99 Virus"; content:"X-Spankska\: Yes"; flags: PA;)

This rule looks for packets from any source and any port that are destined to your home network on port 25. $HOME_NET is defined in the /etc/snort/snort.conf file. Furthermore, the packet must contain the string "X-Spankska\: Yes" and the TCP Flags must be set to PUSH-ACK. The alert is labled "Happy 99 Virus". Rules such as this can help you detect known viruses attached to incoming e-mail.

The snort web site contains an exhaustive document on how to create rules to meet virtually every situation.

Resources

Web sites:

HoneyNet Project

The SANS Institute

Security Portal

Linux Administrator's Security Guide

Root Prompt

Linux System Administrator's Guide

Books:

Network Intrusion Detectsion, 2nd Ed. (New Riders) ISBN: 0-7357-1008-2

Intrusion Signatures & Analysis (New Riders) ISBN: 0-7357-1063-5

Maximum Linux Security (SAMS) ISBN: 0-672-31670-6

Linux Network Administrator's Guide, 2nd Edition (O'Reilly) ISBN: 1-56592-400-2

Practical Unix and Internet Security (O'Reilly) ISBN: 1-56592-148-8

Running Linux, 3rd Edition (O'Reilly) ISBN: 1-56592-469-X

Linux System Security (Prentice Hall) ISBN: 0-13-015897-0

Snort filters

As mentioned previously, snort filters are BDF filters, the same as those used by tcpdump. The filters can be specified on the command-line or in a filters file using the -F option noted above.

In order to create a good filter, you must:

Conclusions

System security is a 24/7 job. There always seems to be something to do. You can start your trek toward better security by making sure you keep all security patches for your system completely up-to-date. From there, you should perform regular audits of your system to keep track of potential "holes" that may open up, or try to catch someone in the act of trying to break into your system.

There are many other tools available, SHADOW, portsentry, ACID, and many more -- just take a look at freshmeat.net or securityportal.com -- each has strengths and weaknesses. Take appropriate measures to lock down your network, disable telnet, FTP, and the BSD r-commands and use secure replacements. Download, compile, and install some of the security tools I've talked about in this series to get the big picture of your network.

Above all, keep up-to-date. Don't give up. If even after taking some precautions, your site gets broken into, don't be dismayed. Learn from it and plug the leaks!

Happy tracking!

Carl Constantine works for Open Source Solutions, Inc. (www.os-s.com) as a Linux Trainer and Programmer.


Previously in this series:

Tools of the Trade: Part 1

Tools of the Trade: Part 2

Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.