Tools of the Trade: Part 2

Welcome back to our continuing discussion of the various tools of the Linux trade.

This article is the second of a three-part series that takes a look at some of the common tools you can use on your own systems to spot holes, look for potential problems, and then take steps to tighten your grip on the system.

Last time, I took you through a brief introduction to "honey pots," Ethereal, and the venerable nmap. This time, we'll take a look at a few more common tools, namely tcpdump and Tripwire.

tcpdump

Tcpdump is a network traffic analysis tool originally created by the Network Research Group at Lawrence Berkley National Lab. As the name implies, tcpdump allows you to "dump" TCP traffic to screen or file for later analysis. Actually, tcpdump also serves as a back-end program to many other network analysis tools such as snort and shadow. The underlying traffic capture library, libcap, is also used in other tools such as Ethereal (which we discussed last time), tcptrace, and many others. You can find out more details on these tools from the tcpdump web site. Tcpdump comes with most Linux distributions by default so you don't have to grab it yourself.

Like many other tools, tcpdump can only be used by the root user. There are many other tools, including some commercial tools, that provide slightly different or more elegant output than tcpdump. However, tcpdump is a good raw tool that can help you understand other tools and your network.

By default, tcpdump reads all the traffic from the default network interface (usually eth0M) and spews all the output to the console. For many reasons, primarily the data whips up the screen at a rather uncontrollable rate on a busy network; this is probably not always the behavior you want or need. Thus, tcpdump includes many command options to change the behavior into something more manageable.

Let's take a look at a typical packet you might capture using tcpdump. This output was captured without any command-line options given to tcpdump.

This packet is a download session from a web server. How do I know that? Well a little experience for one thing, and I set it up that way. But let me break down the packet into more detail for you.

Notice the destination port on archive.progeny.com is www, port 80. Therefore, this is a web session. Notice that the source and destination addresses are resolved. "Mallard" is the name of my machine. You can restrict the output to show IP addresses and numbers instead of the resolved host name (use the -n option) or you can not show some things such as the time stamp (use the -t option).

TCP flags

There are several TCP flags you might encounter when using tcpdump. They are s, ack, f, r, p, urg, and . (period). I'll describe them briefly here.

TCP Flag

Flag in tcpdump

Flag Meaning

SYN

s

Syn packet, a session establishment request. The first part of any TCP connection.

ACK

ack

Ack packet, used to acknowledge the receipt of data from the sender. May appear in conjunction with other flags.

FIN

f

Finish flag, used to indicate the sender's intention to terminate the connection to the receiving host.

RESET

r

Indicates the sender's intention to immediately abort the existing connection.

PUSH

p

Signals the immediate push of data from the sending host to the receiving host. For interactive applications such as telnet, the main issue is the quickest response time, which this "push" flag signals.

URGENT

urg

Urgent data should take precedence over other data. For example, a Ctrl-C to terminate a FTP download.

Placeholder

.

If the connection does not have a syn, finish, reset, or push flag set, this placefolder flag will be found after the destination port. Note that it also appears in conjunction with the ack flag.

Understanding the information provided by tcpdump takes a bit of time and practice. It does help to have a good TCP reference book such as TCP/IP Illustrated, Volume 1 by Dr. Richard Stevens.

Another session in tcpdump

Do you have any additional tips concerning how to use tcpdump and Tripwire to protect your Linux server.Post your comments

Let's look at something with more meat. Remember last time I showed a TCP session using Ethereal. Well, let's look at a similar session in tcpdump. For the purposes of this illustration, I've cut out a bunch of extraneous data.

For this particular packet dump, I used the following command: tcpdump -l -vvv -x -X > tcpdat & tail -f tcpdat. This command makes tcpdump give both Hex and ASCII output in a very verbose mode.

OK. We've connected to the remote system. Notice the last line. The fact that we're waiting for a login ID is clear. Now, understand that with telnet, every keystroke is sent to the remote system as a separate packet. With that in mind, look at the very last character of the next few packets. Note: some packets have been removed as they are echo packets sent from the server back to the client system.

Oh my! someone is trying to log in as root. First of all, you should never log in as root directly. It's safer to log in as yourself and then issue the su command to become root. Let's see what else we have.

We now know the password for the root account to this box is "homebase." We know that's the last character because of the next few packets which show the remote system information confirming a successful login.

With a little more experimentation and familiarity with tcpdump, you can do much more. Once again, if this same session used Secure Shell (SSh) instead, the attacker would not be able to capture any of this information, it would be garbage and of no use at all.

I hope I've showed you just how easy it is to look at packets on a network. There is much much more to it than what I've showed here, but this should give you a starting point for further learning.

Tripwire

Tripwire is a unique tool in that it doesn't really stop an attacker from compromising your system. However, Tripwire can tell you which files have been changed or replaced since the last run.

Tools such as Tripwire are often used on a honey pot system. You can see and log what the intruder changes this way very easily. Tripwire uses a database that includes all the information about your system that you want to log. This database is created the first time you run Tripwire. Then, it's used in successive audits to compare what has changed and what has not.

In many configurations, there are files that change all the time, such as those found in user's home directories so you don't want to include those in the audit. However, files that rarely change such as the programs in /usr, /sbin, /bin, and so forth, are prime targets for inclusion in the database. It depends on your needs and the programs you run.

Installing Tripwire

You can install Tripwire in one of two ways. You can either download the source code and compile it yourself (recommended for any security tool) or you can download the RPM or Debian packages and install that way. As I write this, the latest version of Tripwire is 2.3.1-2.

Place the source in an accessible location such as /usr/local/src. Then uncompress it in the normal way:

Compiling Tripwire from source is different from most Linux applications, there's no config script for example. Before compiling Tripwire, look over the makefile and make any changes you need. The makefile is well documented, so take your time reading. You'll learn a lot in the process. Be sure you also have gtcc 2.95.2 or greater as well or Tripwire will not compile properly. The makefile makes many references to gmake, which on Linux systems at least is the same as make. In fact you may find both commands with one sym-linked to the other.

Tripwire can be compiled in one of two configurations, debug or release. Debug is useful if you are a developer and want to know more about the internals of Tripwire and such or if you're testing out a new version before putting on a production system. Release is the mode you'll use on a production system and the one we'll concentrate on here. Once you've made the modifications you want to the makefile, you compile tripwire with the following command:

$ make release

Once finished, you actually install Tripwire using the supplied install script. You must be root to run it:

The install script copies all the Tripwire programs, libraries, and man pages to their proper places on the system. It also places the default policy and configuration files in /etc/tripwire/. The install script will also prompt you for site key passwords and local key passwords, compile the default policy and configuration files, and finally sign these files with the site key. Remember these passphrases as they cannot be recovered. You have been warned!

Tripwire's files

Tripwire uses four files in the working of its magic: the policy file, the configuration file, the database file, and the report files. Some of these files exist in two formats: binary and text.

The text version is what you edit to configure how you want Tripwire to work. Then, you run twadmin to compile the text files into the binary files it uses. You should then move the text files to a floppy or CD media and delete them from the system. This way, an intruder cannot change what Tripwire reports to cover his tracks.

The policy file /etc/tripwire/tw.pol is used by you as the administrator to specify how Tripwire checks the system. The policy file consists of various rules, each of which specify a system object that Tripwire monitors, and describe what changes to that object should be reported or ignored.

The configuration file /etc/tripwire/tw.cfg stores system-specific information such as the location of the Tripwire data files and the settings used for notification via email when violations occur.

A good sample policy and configuration file comes with the Tripwire source code. In the beginning, you can use them as a starting point instead of trying to create your own until you become more familiar with how Tripwire works.

The database file /var/lib/tripwire/$(HOSTNAME).twd is central to the integrity assessment strategy. Tripwire uses the rules specified in the policy file to create a "snapshot" of the system. Ideally, this snapshot should be of a clean install so you are guaranteed of being in a known secure state. The database file is then used as a "baseline" during integrity checks. The current state of the system is compared against this database to determine if any changes have been made since the database was created.

The report files /var/lib/tripwire/$(HOSTNAME)-$(DATE).twr are produced every time the integrity check is run. Usually, you run an integrity check at a set interval using the cron facility. The results of that check, including any changes (additions, deletions, or modifications) that violate the policy file rules, are stored in a report file. Summary results of the integrity check are stored in the report file which can be viewed in a variety of formats at varying levels of detail.

Once everything is set up, you're ready to begin using Tripwire. Tripwire consists of a few different applications: twadmin compiles the text files into binary files used by Tripwire while twprint allows you to take a binary config file and get the ASCII text out of it. Because these programs are administrative, you'll want to remove them from your system once everything is set up. Removing them will prevent an intruder from using the admin programs to change what Tripwire looks for and so forth.

The main application is called tripwire. Use tripwire to create your initial database like this:

# tripwire -m i

The -m tells Tripwire what mode to use, in this case, initialization mode. Now that the database is created, you run comparisons on your system with the following command:

# tripwire -m c

You should put this into a crontab or shell script file. How often you run Tripwire depends on your level of paranoia. If you are really paranoid, you might run it every couple hours. If you're not that paranoid, once a day may be sufficient. Remember, you have to look over the reports generated by Tripwire, so if you do it too often, the task may become too daunting. But again, that's entirely up to you. What do the reports look like you ask? Like this.

There is more to it than this, but the files can be large depending on your system. If you find that you are changing some files that Tripwire compares (new versions of applications for example) you can always update Tripwire's database with the command:

# tripwire -m u

Conclusions

There are many things you can do to avoid use of some tools like tcpdump and Ethereal. You can use a switched network for a start to avoid "broadcasting" your packets to every workstation on your network. Note: This doesn't stop somone from sniffing traffic going from your network to the Internet, or from capturing data from the Internet (such as a remote user) destined for your network. But it does narrow down the ability to use such tools internally, unless they are being run on the source or destination machine (such as one of your servers).

Another thing to do, is get rid of any network protocol that transmits text in the clear. This means telnet and FTP to start. You should also look at getting rid of the Berkley "R commands" such as rdist, rlogin, et al. You should be using SSh for all remote access and server to server synchronization. If you really need the Berkley "R commands," consider running them over an encrypted SSh session instead.

Tripwire is a great tool for tracking changes to your system. Depending on how "paranoid" you are and how often you run it, you can find a change very quickly, hopefully before the intruder has a chance to stop Tripwire from running and trash any logs. But hey, that's where tools like syslog come in. We'll take at look at this tool next week along with the venerable snort.

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