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,
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
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:
syslog's configuration file is relatively simple to read and modify as you see fit. Let's take a quick look.
We're looking for tips and pointers on effective use of syslog and snort.
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 file is used by both
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:
local0 to local7
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
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
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.
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 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
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.
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:
The interface to read from. If none is specified, the default interface (usually
Stands for "Alert Mode."
Uses the filters file specified by filter file. The filter file is in the same format (called BDF or Berkley Packet Filter) as a
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 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 126.96.36.199/17 any -> 188.8.131.52/16 666 (msg:"The beast is coming!!!";)
This rule generates an alert on any TCP packet with a source IP in the range 184.108.40.206 through 220.127.116.11 (any port) with a destination IP in the range 18.104.22.168 through 22.214.171.124 (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.
snort web site contains an exhaustive document on how to create rules to meet virtually every situation.
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
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:
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!
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.