File Integrity and Anti-DDoS Utilities

In my previous article, I walked you through the usage of tripwire. While tripwire is the most well-known of the file integrity utilities, it is not the only utility available for this purpose.

All file integrity utilities create a database of hashes representing a baseline of the files on a system. For this reason, the best time to create the database is just after installing and configuring the system and before connecting it to the Internet. When deciding upon which utility to use, the following factors come into play:

• The license
• The algorithm(s) used to create the hashes
• Ease of use
• Complexity of configuration file(s)

I've summarized the license and algorithms for three utilities in the following table:

aide

As for the ease of use and complexity of the configuration files, let's check out aide and yafic and see how they compare to tripwire. I'll start with aide:

$ cd /usr/ports/security/aide
$ make install clean

Related Reading The Complete FreeBSD Documentation from the Source By Greg Lehey

You'll note that both this build and the yafic build will be much quicker than tripwire, and you won't be prompted to agree to any licenses. Unlike tripwire, you also won't be prompted to create any keys. This is an important distinction, as it affects how you actually use the file-integrity utility.

tripwire introduced the ability to sign its databases two years ago with version 2.3.1. Before then, it was up to the administrator to place all tripwire files onto removable media, such as a floppy, and to ensure that media was actually removed from the computer. If you didn't remove the tripwire database, an intruder could simply update the database after modifying your files. You'll remember from the last article that the new system requires you to know both the local and the site passphrases to update the tripwire database. This means that you should be safe storing the database on the hard drive, if you choose secure passphrases.

This is where ease of use becomes a matter of preference, and your level of paranoia. With tripwire, you must generate keys and remember your passphrases. With other utilities, you instead must remember to move your database to a floppy, and then insert the floppy when you check the database and remove it when you are finished.

Let's return to aide. There are three main sources of documentation for this utility: man aide, man aide.conf, and www.cs.tut.fi/~rammer/aide/manual.html.

The install will create a /var/db/aide directory; by default, it only contains an empty databases/ subdirectory.

Unlike the tripwire install, an initial database is not initialized for you. To initialize the database:

$ cd /var/db/aide
$ aide --init
Cannot access config file:/var/db/aide/aide.conf:No such file or directory
No config defined
Configuration error

Note that you cannot initialize a database until you create a configuration file. Fortunately, a sample file is available. Unlike tripwire, which has separate policy and configuration files, aide only has one configuration file. I'll start by copying over the default configuration file, and then I'll repeat the initialization command:

$ cp /usr/local/etc/aide.conf.sample /var/db/aide/aide.conf
$ aide --init

This command creates an ASCII text file called /var/db/aide/databases/aide.db.new. Again, it is important to note the distinction between this database and a tripwire database. A tripwire database is not ASCII text and it can only be understood by the tripwire utilities. Furthermore, it is signed, meaning you have to know the correct passphrase in order to modify the database. An aide database is ASCII text and is unsigned; in short, anyone can modify this database. It is important that you move this database to a floppy and remove the floppy from your floppy drive. When you move the database, you'll also want to rename it like so:

$ mount -t msdos /dev/fd0 /mnt
$ mv databases/aide.db.new /mnt/aide.db
$ umount /mnt

To make your life easier when you use the database, you should also edit the configuration file to point to the floppy. Open aide.conf in your favorite editor and look for these two lines:

database=file:///var/db/aide/databases/aide.db
database_out=file:///var/db/aide/databases/aide.db.new

Change them to:

database=file:///mnt/aide.db
database_out=file:///mnt/aide.db.new
database_new=file:///mnt/aide.db.new

Now, whenever you want to check the database:

$ mnt -t msdos /dev/fd0 /mnt
$ aide --check

aide will display any changes it finds. If you're not a speed reader, you can use the compare switch to go through the changes:

$ aide --compare

You'll find the output to be very different from a tripwire report. If you are unfamiliar with mtime and ctime, you may find my understanding filesystems article useful.

Once you've resolved any changes, you can update the database with:

$ aide --update

When you're finished, don't forget to unmount the floppy and remove it from the floppy drive:

$ umount /mnt

I found that the default configuration file worked well without any changes, other than the edit to point to the floppy. Unlike tripwire, I didn't have to resolve any errors. I also found the syntax of the file a little more logical. Both tripwire and aide allow you to get as complex as you like in your configuration file; I'll leave it up to you to decide which file you consider to be easier to work with. On the plus side, I found the aide command-line utility much easier to use than tripwire.

I've successfully used aide in the past, but the current port has an error that prevents the successful write of the new database. I've emailed the maintainer, so it is quite likely that the error will have been resolved by the time you read this article.

Yet Another File Integrity Checker

Now, let's move on to yafic, or "yet another file integrity checker":

$ cd /usr/ports/security/yafic
$ make install clean

This utility is the youngest of the file integrity utilities, so the documentation is quite lean. Your choices are man yafic, man yafic.conf, and sourceforge.net/projects/yafic/.

This utility is similar to aide in that you should keep the database on a floppy, as it will not be signed. Again, a sample configuration file is created for you: /usr/local/share/examples/yafic/yafic.conf.sample.

Copy and rename that file so it doesn't have the sample extension. Here, I've copied it to root's home directory:

# cd
# cp /usr/local/share/examples/yafic/yafic.conf.sample yafic.conf

Now, I'll see what happens when I type yafic:

$ yafic
nothing done; use -c, -u, or -l options

Okay, it wants one of three options. From man yafic, those three options do the following:

• -c checks the database.
• -u updates the database (or initializes a new database).
• -l lists entries in the database.

So, I'll mount a floppy and try again:

$ mount -t msdos /dev/fd0 /mnt
$ yafic -u yafic.db

When using yafic, make sure you are in the directory containing yafic.conf and that you specify the name of the database you wish to create or check.

Once you've created the initial database, unmount the floppy and remove it from the floppy drive. Whenever you want to check the database, remount the floppy, cd to the directory containing yafic.conf, and use the -c (check) switch:

$ yafic -c yafic.db

Again, any changes will be displayed to your screen. If you prefer to read the changes at a slower pace, redirect the output to a file:

$ yafic -c yafic.db > changes
$ more changes

Once you've resolved your changes, use the -u switch to update the database. Don't forget to unmount the floppy and remove it from the floppy drive when you are finished.

File Integrity Utilities Summary

You've probably noticed that all of these file integrity utilities follow the same routine:

• Initialize a database.
• Check the database.
• Update resolved changes into the original database.
• Repeat on a regular basis.

Ultimately, since it is you who will have to follow the routine, choose the utility whose switches and configuration file make the most sense to you. I encourage you to try all three utilities and choose the one that most fits your personality.

DDoS Testing Utilities

As promised, I also want to take a look at DDoS testing utilities. If you've never been to Dave Dittrich's page, you're in for a treat. This is a definitely bookmarkable site with tons of valuable information, and is the resource for DDoS information on the Internet. His actual DDoS page is staff.washington.edu/dittrich/misc/ddos/.

If you're unfamilar with the term DDoS, it stands for Distributed Denial of Service. Basically, this type of attack looks for vulnerable hosts. Once a host is infected, it will in turn look for other vulnerable hosts to infect. Once enough hosts are infected (potentially hundreds of thousands), they are used to launch a collective attack against a target. For example, you may remember hearing about the DDoS attack against the root DNS servers.

Several utilities in the ports collection can determine if your FreeBSD computer or the computers in your network have been infected by a DDoS agent. The three most common Unix DDoS agents and the types of packets they use are:

For details on each DDoS agent, see David Dittrich's DDoS page.

Let's start with ddos_scan, the utility created by Dittrich:

$ cd /usr/ports/security/ddos_scan  
$ make install clean

This will install an executable at /usr/local/sbin/dds and a file at /usr/local/share/doc/ddos_scan/README. The file contains a lot of useful information regarding DDoS, and I highly recommend that you take the time to read it.

This utility is designed to scan an entire network, looking for infected hosts. Its syntax is:

$ dds A.B.C.D/mask

For example, if your network has a network ID of 192.168.10, specify your network and mask as follows:

$ dds 192.168.10.0/24

If you only want to scan your own machine, simply give the IP address with no mask:

$ dds 192.168.10.1

When running this utility, it's good to receive no output. That means the utility didn't find any infected hosts. The README file shows examples of what the output will be and what to do about it, if an infected host is found.

This is a good utility to run as a cron job. If you're new to cron, check out "Getting cron to Do Our Bidding." Remember to give the full path to dds in your crontab entry.

The NIPC (National Infrastructure Protection Center) has released a similar utility. At the moment, their web site is at www.nipc.gov, but that will slowly transition to www.dhs.gov. This utility was designed to scan only the local machine for DDoS agents, so it is suitable if you only have one FreeBSD computer. To build this port:

$ cd /usr/ports/security/find_ddos
$ make install clean

It will install an executable at /usr/local/sbin/find_ddos and a document at /usr/local/share/doc/find_ddos/README.

To run this utility, simply type:

$ find_ddos
Running with the following default options:
find_ddos -g files -l LOG -p /tmp /

This material and tool is furnished on an "as is" basis.  There are no
warranties of any kind, either expressed or implied as to any matter
including, but not limited to, warranty of fitness for a particular purpose
or merchantability, exclusivity or results obtained from use of the
material.  There is no warranty of any kind with respect to freedom from
patent, trademark, or copyright infringement.

If the program "find_ddos" generates a log file revealing unlawful access
of a tested system, system administrators are encouraged to contact their
local FBI field office or the NIPC.

Please review the README file before continuing.

Do you accept these terms? yes

In the future, you can run this tool with the "-y" option from the
command line to acknowledge these terms

Logging output to: LOG
WARNING: Unable to scan running processes.
This will happen if the /proc directory is not a procfs.

Scanning "/tmp"...
Scanning "/"...

No DDOS tools found.

Editor's Note: Astute reader Erik Johansson pointed out that find_ddos could in fact be run from cron, contrary to what the original article stated. Dru suggested the following revision.

The output of this utility clearly indicates whether or not a DDoS agent was found. Note that if you want to include this check in a cron job, you'll need to include the y switch to indicate acceptance of the license. However, if you just try this:

% /usr/local/sbin/find_ddos -y

you'll receive this error:

Usage: find_ddos [-g grabdir] [-l logfile] [-p] [-v] [-V]
	[-x exclude1] directory

If no parameters are given, the following defaults are used:

find_ddos -g files -l LOG -p /tmp /

If any parameters are given, the defaults are not used. In that
case, you must specify a directory to scan, or you can just use '-p' to
scan memory only. 

This will work and will scan memory, /tmp, and /:

% /usr/local/sbin/find_ddos -y -g files -l LOG -p /tmp /

Cleaning a DDoS Agent

The final utility I'd like to cover is meant to be used if you find a DDoS agent running on your network:

$ cd /usr/ports/security/zombiezapper
make install clean

The install will create an executable at /usr/local/bin/zz and a directory, /usr/local/share/doc/zz/, containing the files USAGE and tekpaper.txt. USAGE gives detailed instructions on how to use the utility. Read it if you are ever unfortunate enough to have infected computers in your network.

In addition to trinoo, tfn, and stacheldraht, zz recognizes trinoo for Windows and shaft. It works over a network and was designed to stop infected machines from continuing to flood the network.

It is important to realize that all three DDoS tools are only effective as long as the attacker has not changed the default ports used by the DDoS attacks.

In the next series of articles, I'd like to take a look at how DHCP works and how to set up a DHCP server using a FreeBSD computer.

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.

Read more FreeBSD Basics columns.

Return to the BSD DevCenter.

Copyright © 2009 O'Reilly Media, Inc.