Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Integrity Checkers

Integrity checkers are very useful for finding Trojan programs and backdoors like Rootkit. Theoretically they are also useful for maintenance, but in reality this goal is pretty difficult to achieve.  Please note that many existing program can be used to create a pure man integrity checker. Tar with -d mode is an obvious candidate (star is actually a better tool), but even ls -l along with diff is an extremly useful tool.

Perl-written (or Python-written) integrity checkers are more flexible and thus have an edge over C-written tools like Tripwire. Mixed TCL+C tools are probably the most flexible approach, but both Perl and Python are OK "as is".  Perl based checkers are now moved to a separate page: Perl-based Integrity checkers

The most popular integrity checker for Unix, Tripwire never was able to supersede its beginning as a student project. A free version of Tripwire realistically can only be used in a limited way for static servers like appliances.  A commercial version is a little bit more flexible, but not by much and is overly complex for the pretty primitive functionality provided. Moreover an introduction of central console for all Tripwire instances created an additional security risk.

The fairy tails that Tripwire can detect or prevent host intrusions as a standalone application are not credible. Theoretically it can, but the tool itself is so inflexible that it largely defeats its purpose.  As a result its reports are by and large ignored. This is classic "crying wolf" situation and is typical for many other integrity checkers.  On Linux in most case you might have more success with RPM-based checking that with Tripwire.

If you really have some time to spend you can install Tripwire on a regular server;  just do not try to write all-encompassing rulebase, this is a proven road to nowhere ;-). Older versions of tripwire are strictly file oriented and you need to list all the files and directories you need to check. Newer version (commercial version 4.0 and later) permit specification of all files in the directory (better late then never ;-)

Still the best policy in using Tripwire is to limit yourself to a few critical system and configuration files (for example used in the rootkits), plus several critical configuration files.  Actually control of configuration files is more important and here Tripwire while weak, can at least can provide some return on investment. If you are thinking about using Tripwire for tracking changes, please think again. This is possible by writing custom scripts, but there are better tools for the same purpose.  One problem is that if you do not compare with the baseline, you compare with the set of attributes. Also if you control both directory and a file in this directory, then for each change Tripwire will complain twice. In old times there was an option  -loosedir which would prevent tripwire from complaining about directory modification time updates that can filter out some noise. Later it became a configuration option. 

The real challenge for integrity checkers is not super-duper change detection (the path taken by many useless security tools) but intelligent report about changes.  That's where most of those program fail and that's why they did not get sufficient traction despite extremely promising idea. 

Old News ;-)

[Jan 23, 2010] Samhain Labs file integrity checkers

Interesting but semi-useless study of integrity checker with equally semi-useless comparison table ;-)

What is the focus of this study ?

There are many reviews which focus on features and tell colourful stories of guys sitting in a server room and watching alerts whooshing over the terminal screen. This one is hopefully different.

This study compares eight free (open-source) host/file integrity checkers (file integrity monitoring programs) with respect to the implementation of the core functionality, i.e. questions like:

• Can the program check all files that you may want to check?
• Can the program handle quirks / oddities / corner cases of the filesystem (that may e.g. result from normal system activity, from an intrusion, or from errors of shell users)?
• Does the program warn about an incorrect configuration (which may cause it to check not in the way you intended)?

The results presented here are based on test runs, and sometimes also on investigation of the source code. All test were performed on a Ubuntu Linux system (6.06 for most programs, 9.04 for OSSEC which was tested end of 2009). In general, tests were performed only with console logging (stdout/stderr). Client/server systems (osiris, OSSEC, Samhain) were tested in a client/server setup with client and server on the same machine.

Thus, while some "features" of these programs are mentioned that may be of interest for usability, the focus of the study was on testing the scanner's functionality, not on listing and/or comparing their features.

Explanation of table rows

Version

The version number of the file integrity scanner.

Date

The release date of the file integrity scanner. For PGP signed source code, this is the date of the PGP signature, otherwise the date listed on the web site, or in the source.

PGP signature

Is the distributed source code PGP-signed ?

If there is no signature, it may be possible to put a trojan into the source code (this has happened in the past with several high-profile security-related programs)!

Language

The programming language of the file integrity scanner.

Required

Requirements (other than compiler or interpreter).

Log Options

What channels are supported for logging?

DB sign/crypt

Does the scanner support signed or encrypted baseline databases?

Conf sign/crypt

Does the scanner support signed or encrypted configuration files?

Name Expansion

Does the scanner support expansion of file names (shell-style patterns or regular expressions) in the configuration file?

Duplicate Path

Does the scanner check the configuration file for duplicate entries of files/directories (possibly with a different checking policy for the duplicate)? Strict checking of the configuration file can help to avoid user errors.

PATH_MAX

Can the scanner handle a file whose path has the maximum allowed length (4095 on Linux)?

Root Inode

Can the scanner handle the "/" directory inode? This is the file with the shortest possible path, and also the only one with a "/" in its filename, so it may expose programming bugs (and you do want to check that inode).

Non-printable

Can the scanner handle filenames with weird or non-printable characters? And if it can handle them internally, can it report results in a useful way? Checked filenames were:

bash$ ls -l --quoting-style=c /
-rwxr-xr-x 1 root root 0 Feb 11 20:16 "\002\002\002\002"

As "\002" is non-printable, incorrect reporting will result in a report about removal of the root directory ("/"), if this file is removed ...

bash$ ls -l --quoting-style=c /opt
-rwxr-xr-x 1 root root 0 Feb 11 19:51 "this is_a_love_song\b\b\b\b\b\b\b\b\bwrong_filename"

As "\b" is backspace, incorrect reporting will result in a report for the non-existing file "this is_a_wrong_filename"

bash$ ls -l --quoting-style=c /opt
-rwxr-xr-x 1 root root 0 Feb 11 19:51 "this_has\n_a_newline"

If filenames are not properly encoded, the newline may easily corrupt the baseline database.

No User

Can the scanner handle files owned by a non-existing user (UID with no entry in /etc/passwd)?

No Group

Can the scanner handle files owned by a non-existing group (GID with no entry in /etc/group)?

Lock

Can the scanner handle files if another process has acquired a mandatory (kernel-enforced) lock on it (yes, Linux has that kind of locks)? It is possible to open() such a file for reading, but the read() itself will block, so the scanner will hang indefinitely, unless precautions are taken. On Linux, mandatory locking requires a special mount option, thus cannot usually be enforced by unprivileged users.

Race

File integrity scanners first lstat() a file to determine whether it is a regular file, then open() it to read it for checksumming. In between these two calls, a user with write access to the directory may replace the file with a named pipe. As a result, the open() call will block and the scanner may hang indefinitely, unless precautions are taken.

/proc

Is the scanner able to scan the /proc directory? On Linux, at least some files in /proc are writeable and can be used to configure the kernel at runtime, so you may want to check these files. However, files in /proc may be listed with zero filesize, even if you can read plenty of data from them. Almost all scanners "optimize" by not checksumming zero-length files, which is incorrect in the Linux /proc filesystem. Additionally, some files may block on an attempt to read from them.

/dev

Has the scanner problems with the /dev directory? Does it allow to check device files (e.g. for correct permissions)?

New/Del

Can the scanner report on missing (deleted) or newly created files?

[Oct 23, 2008] Another File Integrity Checker 2.12 by Gerbier Eric

Overly complex. The author tried to do too much and complexity failed him. Due to complexity is not modifiable by a regular sysadmin.

About: afick is another file integrity checker, designed to be fast and fully portable between Unix and Windows platforms. It works by first creating a database that represents a snapshot of the most essential parts of your computer system. You can then run the script to discover all modifications made since the snapshot was taken (i.e. files added, changed, or removed). The configuration syntax is very close to that of aide or tripwire, and a graphical interface is provided.

Changes: The code now works with perl 5.10. On Windows, afick_planning now sends a report instead of a summary and uses the "LINES" macro. On Unix, a new MOUNT macro allows you to use a remote database in afick_cron. Udev files were removed from scan. The tar.gz installer was recoded to display better diagnostics.

[Aug 10, 2007] Host Integrity Monitoring Best Practices for Deployment by Brian Wotring

Brian Wotring is the lead developer for the Osiris project and CTO of Host Integrity

Mar 31, 2004 (securityfocus.com)

This article is written with the open source host integrity applications Osiris and Samhain in mind, however the material presented is certainly not unique to these applications.

... ... ...

The basic idea behind host integrity monitoring applications is that they detect and report on change to the system. It gets most interesting when a change is unauthorized or unwanted. Much of the monitoring is focused on the file system. However, other environmental vectors can be monitored as well. For example, Samhain has the ability to search for rootkits and monitor login and logout activities. Osiris has the ability to monitor the state of loaded kernel extensions and the details of changes to the local user and group databases. Detected change is reported in the form of log files, syslog, the Windows Event Viewer, and possibly emailed to an administrator.

... ... ...

To better appreciate the role a host integrity system serves, imagine you find a new link to /etc/passwd that has been created in /tmp, a new kernel module that gets loaded without your knowledge, or a new user gets mysteriously created. How would you know if and when these types of changes occurred? There are commands that can be used to look for these happenings, but how would you know if and when to run them? What if these commands that you depend on for finding such changes were altered to hide specific information? Now, imagine you have hundreds of hosts that need to be monitored regularly to look for changes such as these.

Table One, below, compares features of some popular host integrity applications.

	Samhain	Osiris	INTEGRIT	AIDE
Monitors Files	yes	yes	yes	yes
Monitors Kernel	yes	yes	no	no
Platforms	Linux, FreeBSD, AIX 4.x, HP-UX 10.20, Unixware 7.1.0, Solaris 2.6, 2.8, and Alpha/True64	Windows NT/2k/XP, Mac OS X, Linux, Solaris, FreeBSD, OpenBSD	Linux, FreeBSD, Solaris, HP-UX, Cygwin	Linux, FreeBSD, OpenBSD, AIX Unixware 7.1.0, Solaris True64, BSDi, Cygwin
Multiple Administrators	no	yes	no	no
Supports Modules	no	yes	no	no
License	GPL	BSD style	GPL	GPL
Centralized Management	yes	yes	no	no
Signed Databases	yes	no	no	no
Database Integration	yes	no	no	no

Table One: a comparison of popular host integrity applications

More information on the above products can be found on their websites:

Samhain - http://la-samhna.de/samhain/
Osiris - http://osiris.shmoo.com
INTEGRIT - http://integrit.sourceforge.net/
AIDE - http://www.cs.tut.fi/~rammer/aide.html

[May 2, 2005]  The Second Commandment of system administration (NewsForge)

NewsForge takes a look at integrity checkers. "Each integrity checker is a little different, so do some research before deciding on one. There are many excellent integrity checking applications out there, but the one I recommend and prefer is called afick (Another File Integrity ChecKer).

Afick offers several advantages over integrity checkers such as Tripwire and AIDE.

The first and foremost difference is that afick is written in Perl, which gives it the advantage of speed. Afick finishes the initialization of the database that stores filesystem attributes almost a minute faster than AIDE.

Being written in Perl also means that afick is highly portable between operating systems."

A comparison of several host/file integrity checkers (scanners) By Rainer Wichmann

Table of results (alphabetic order)

	AIDE	FCheck	Integrit	Nabou	Osiris	Samhain	Tripwire
Version	0.10	2.07.59	3.02	2.4	4.0.5	1.8.4	2.3.1-2
Date	Nov 30, 2003	May 03, 2001	Sep 08, 2002	Aug 30, 2004	Sep 27, 2004	Mar 17, 2004	Mar 04, 2001
PGP Signature	YES	NO	YES	YES	YES	YES	NO
Language	C	Perl	C	Perl	C	C	C++
Required	libmhash	md5sum (or md5)		PARI/GP library + about 11 Perl modules	OpenSSL 0.9.6j or newer	GnuPG (only if signed config/database used)
Log Options	stdout, stderr, file, file descriptor	stdout, syslog	stdout	stdout, email	central log server (email+file on server side)	stderr, email, file, pipe, syslog, RDBMS, central log server, prelude, external script, IPC message queue	stdout, file, email, syslog
DB sign/crypt	NO	NO	NO	sign	NO	sign	sign+crypt
Conf sign/crypt	NO	NO	NO	NO	NO	sign	sign+crypt
Name Expansion	regex	NO	NO	see remarks	regex	glob (shell-style)	NO
Duplicate Path	NO	NO	NO	NO	NO	Warns	Exits
PATH_MAX	OK	OK	NO	OK	NO	OK	OK
Root Inode	see remarks	NO	OK	NO	OK	OK	OK
Non-printable	NO	NO	NO	NO	NO	OK	OK
No User	OK	OK	OK	see remarks	OK	OK	OK
No Group	OK	OK	OK	see remarks	OK	OK	OK
Lock	OK	Hangs	Hangs	Hangs	Hangs	Times out	Hangs
Race	Hangs	Hangs	Hangs	Hangs	Hangs	OK	Hangs
/proc	NO	NO	Hangs	Hangs	NO	OK	NO
/dev	OK	OK	OK	OK	OK	OK	OK
Crea/Del	OK	OK	OK	OK	OK	OK	OK

Host Integrity Monitoring Using Osiris and Samhain

By Brian Wotring

• Paperback: 450 pages
• Publisher: Syngress; 1 edition (June 1, 2005)
• Language: English
• ISBN: 1597490180
• Product Dimensions: 9.2 x 7.1 x 0.9 inches
• Shipping Weight: 1.6 pounds. (View shipping rates and policies)
• Average Customer Review: based on 5 reviews.

Excellent one-of-a-kind book on an overlooked security discipline, August 7, 2005
 

Reviewer:

Richard Bejtlich "TaoSecurity.com" (Washington, DC) - See all my reviews

Host Integrity Monitoring Using Osiris and Samhain (HIM) is an excellent book on a frequently overlooked security discipline. Most people who hear about host integrity monitoring nod their heads and agree that performing it is a good idea. These same people usually don't implement HIM, and frequently cannot count the number of hosts, operating systems, and applications working in their enterprise. Thankfully, HIM provides a way to use open source tools to help remedy this situation. Consistent with the Visible Ops methodology, HIM provides guidance on how to keep track of host integrity.

When writing HIM, author Brian Wotring could have easily concentrated on the program he coded -- Osiris. Luckily for readers, Brian chose to address his program and another open source host integrity monitor -- Samhain. By comparing and contrasting these two programs, readers learn more about each and understand the capabilities and limitations of each application's approach to the HIM problem. Consistent with this dual methodology, Brian explains how to install Osiris on both Unix and Windows platforms. (Samhain is mainly a Unix solution.)

The first third of the book provides background information on HIM rationales and planning. I was initially inclined to skip ahead, but I found the explanations of monitoring various system elements to be helpful. Brian's view of security closely mirrors my own, but he approaches it from a host-centric view. He still accepts that prevention eventually fails and that preparation for incident response is a necessity, not a luxury. Brian also correctly uses the term "threat" and recognizes threats are not vulnerabilities. Bravo.

The middle third and some of the final third of the book deal exclusively with installing and configuring Osiris and Samhain. The instructions are wise and very thorough. I was impressed by guidance on how to compile and install Osiris on Windows from source, using MinGW and MSYS. I also liked the book's frequent use of FreeBSD as a Unix reference platform.

I found a few minor issues with HIM, and one major drawback that prevented a five star review. First, I disagree with the statement on p 19 that "most attacks originate from within the network by authorized users." The annual CSI/FBI study has repeatedly shown this to not be true; rather, insider attacks, when they do occur, are typically more damaging that those perpetrated by outsiders. Second, I found some minor rough editing, e.g. "Nimbda" repeatedly used in place of "Nimda." Third, and most important, it would have been extremely helpful to have shown case studies of Osiris and Samhain in action when detecting configuration changes and/or intrusions. I left the book with a lot of ideas on installation and configuration, but it would have been helpful to see case studies on using host-based data to identify intrusions.

I am adding HIM to my recommended reading list for system administrators. HIM gives administrators the documentation and theory they need to add another critical tool to their security arsenal. I would like to see a second edition that adds case studies, and perhaps chapters on using Radmind for open source change management.

[Jan 26, 2006] Sys Admin v15, i02 File Integrity Assessment via SSH 

This is a logical centralization approach. Without some kind of management tool like Tivoli the suggested implementation is not scalable.

security incident and as a host-based intrusion detection tool to help detect unauthorized file system changes (this also makes them useful monitoring tools for existing change control procedures, though that is not the focus of this article). The concept is simple: the administrator creates a configuration file that lists the critical system files and directories that the FIA tool should monitor, then uses the FIA tool to create a database that tracks common parameters about those files, such as permissions and ownerships, file size, and MAC times, along with one or more cryptographic checksums over the file contents (typically via common hashing algorithms like MD5, SHA-1, etc.). The FIA tool is then re-run periodically, and the current state of the file system is compared to the values stored for the various files in the database -- if there are any discrepancies, the files are flagged as having been modified and a report is generated.

The canonical problem with FIA tools, however, is protecting the database generated by the FIA tool, as well as the binary for the FIA tool itself, from unauthorized tampering by attackers who gain root access to the system. After all, if the attacker installs a rootkit and then updates the FIA database for the system to reflect the new state of the file system, then the administrator may be unaware of the attacker's changes. Similarly, the attacker could modify the FIA tool binary to either ignore or lie about the state of files installed by the attacker.

Lately, however, I've been experimenting with a different approach. The concept is to store FIA databases and binaries for the various systems being monitored on a central, highly secure system on a protected network -- call this the FIA management server. Periodically from cron, we run a script on the FIA management server that uses scp to copy the FIA database and binary to a given system and then runs the FIA tool on that remote system via SSH. Any report output and/or updates to the FIA database can then be pulled back to the FIA management server via scp, and all traces of the FIA tool can then be removed from the remote system.

Slashdot Host Integrity Monitoring Using Osiris and Samhain

I've been using Tripwire [sourceforge.net] (and Tripwire Portable [frenchfries.net]) for years. Recently I have started using Samhain in its place and have been quite happy with it. Some useful features that it has which Tripwire doesn't is the ability to monitor kernel system call tables for changes (a common attack vector), and to run as a daemon to alert on changes immediately. Its definitely worth a look.

Bob Bruen's review of Host Integrity Monitoring Using Osiris and Samhain by Wotring, Brian and Potter, Bruce, Syngress 2005, IEEE Cipher, E68 Sep 19, 2005

Syngress 2005.
ISBN 1-597490-18-0. $44.95. Index, three appendices.

Reviewed by  Bob Bruen   09/16/05

We all know and love Tripwire, even if we still use the non-commercial version. It was one of, if not the, first complete tool for managing file integrity. The name comes from the alarm set off because a file was changed in some way. There are other tools that are popular and are still free. This book covers two of those tools, Osiris and Samhain.

Host intrusion detection systems are not quite as widespread in use as the network intrusion detection systems, generally because the number of hosts can be large. Each one requires time and attention, making a network approach more efficient, but not necessarily more effective. It seems that a blended approach would be useful and that appears to be common. The important machines on the network get good host monitoring and the less important are left to fend for themselves. The minimal blending is simply running an NIDS and some HIDS.

A still better approach might be to really integrate both approaches so that there is a distributed set of HIDS with a central management system. Perhaps this could part of the non-commercial version. Moreover, it would nice to have a sophisticated method to manage change on a host. After all, system file changes should be thoughtfully managed anyway. The intruder changes can be caught up the relentless change management system. Without any criticism of file integrity monitoring, it is not enough by itself because other things happen on a system and intruder code can be hidden in places other than the disks.

Osiris came into being as a few Perl scripts which eventually evolved into a extensive and sophisticated package. The architecture is geared toward central management with encrypted communications. The hosts will naturally require a client to be installed, which is a drawback of any HIDS, but otherwise nothing is stored on the host. The central manager does the heavy lifting. This is not unlike an application which needs to be installed on every computer on the LAN, something that is done all the time, but it is still overhead.

Samhain is similar to Osiris in its architecture of client, server and manager, but the clients initiate communication with the server. The Osiris manager initiates the communication with the clients required to keep a port open. The local situation will probably dictate which is the preferred method. Samhain offers the ability to run different scans on different schedules instead of running everything at one time. Both Osiris and Samhain run on Linux, BSD and Windows, but not with the exact same feature set or ease of configuration. This can be a bit of a problem, but still helpful in a heterogeneous environment.

Although the book is about Osiris and Samhain, there is a wealth of information about host integrity monitoring systems (HIMS). The advances in rootkits, intrusion techniques and defenses require us to update what we know. Anything learned ten years ago may still be valuable, just incomplete for today's environment. I always like books that are well written and provide good information, so I recommend Wotring's work to help bring you up to date

[Feb 20, 2005] ONLamp.com Avoiding Trojans and Rootkits

Trojans, rootkits, and DDoS agents are a sad reality. It's a little disheartening to think that software exists which, given a chance, can install unwanted files on your system, overwrite or destroy your own files, send your data or user input elsewhere, or use your computer to attack another system.

The more advanced among you may be smiling and smugly thinking "that's why I run a Unix system". True, there are fewer nasties out there which target Unix systems, but they do exist. Further, as the Unix user base increases, so will the amount and frequency of exploits against Unix systems. Fortunately, as a FreeBSD user, there are many utilities available to you, as well as many good habits that you can teach yourself. The next two articles will discuss these utilities and habits. 

[Feb 20, 2005] SANS Intrusion Detection FAQ How to Examine a Unix Box for Possible Compromise

To identify a potential compromised Unix box is some what of an arcane art, though there are some simple things to look for.

• Examine syslog entries, process table, and file systems to see if there are any "odd" messages, processes, or files. Examples are 2 inetds running, ssh running as EUID root but not UID root, core files for RPC services in /, new setuid/setgid programs, files quickly growing in size, df not closely matching du, perfmeter/top/BMC Patrol/SNMP monitors not matching vmstat/ps output, Higher than normal outbound network traffic.
• Check the /etc/passwd & /etc/shadow for accounts that don't belong or should not have passwords.
• Check the /.rhosts, /etc/hosts.equiv, /.ssh/known_hosts and ~/.rhosts for new entries that don't belong.
• If you see anything that you suspect, then install a sniffer on a second host, and watch for connections to/from that host, and at the same time, back the machine up as evidence for later analysis and evidence. Then contact your local CERT for assistance in examining the other hosts in your network, and recovering your site.

Always keep an eye on the un-seen trust relationships. Who mounts who via NFS? Who has who in their .rhosts, .shosts, or hosts.equiv? Who has a .netrc from that host?

[Feb 18, 2005] NewsForge Check your filesystems' integrity with afick

Title		Check your filesystems' integrity with afick
Date		2005.02.18 3:00
Author		Brian Warshawsky
Topic

http://software.newsforge.com/article.pl?sid=05/02/14/1620218

With new threats showing up every day, administrators find it increasingly hard to establish continued trust with their filesystems. Luckily, it's easier than you might think to maintain omniscient control of your filesystem. Through effective use of a filesystem integrity checker, you can keep a watchful eye on every aspect of an important machine's filesystem.

There are several filesystem integrity checker applications, both commercial and open source. I chose to deploy afick, because it is written in Perl, which makes it lightweight and easily portable between different operating systems. Though by nature designed for the command line, afick also has an optional Webmin module and a graphical interface written in perl-Tk.

For this article we will focus on the command-line implementation on a SUSE Enterprise 8.0 server, but what you see here should be applicable to just about any *nix distribution.

Installation

You can either download and build afick from the source code, or, if you're using a package-based distribution, you can install from an RPM or Debian binary packages. Let's walk through building it from source. To begin, download and unpack the latest version, navigate to the afick directory, and run the following command:

# perl Makefile.pl

Since you aren't installing the GUI, you can safely ignore any errors about missing perl-Tk modules.

Next, type make install to install the console tool. When your machine finishes copying all the necessary files, afick will be installed on your system. Installation is only half the battle, though. The real fun lies in the configuration and testing phase.

Configuration

Afick begins by creating a database of values representing the current state of your filesystem. When you run it later in update mode, afick compares the current filesystem to the original and notes changes.

The exact attributes of your filesystem that are checked are controlled by a configuration file. Afick provides a default configuration file for both Linux and Windows in the directory where it was originally unpacked. In our case, we are interested in the file linux.conf. You can modify a wealth of options in this file, but we will focus only on the essentials.

Afick provides multiple ways to check every file and directory on your system, so no one configuration file is going to work for everyone. For instance, I am running PHPNuke on a Web server that includes forums, which are going to change constantly as users post items and change their preferences. I don't want those changes dumped into my mailbox every day, possibly burying something important. Someone else with a static Web site, however, might want to see that that content is never changed unexpectedly, and would therefore closely monitor that directory. It takes a bit of trial and error to fine-tune afick (or any other integrity checker for that matter) for your specific needs.

Let's begin by initializing the database with the command:

# afick -c /[path_to_linux.conf]/linux.conf -i

The -c tells afick where to find the configuration file it should use, while the -i instructs it to make an initial copy of the filesystem database. This process will take a few minutes. Once it has finished, let your server run for a while, then compare the databases with this slightly different command:

# afick -c /[path_to_linux.conf]/linux.conf -k

The -k argument tells afick to compare the current filesystem against the database specified in the first line of the linux.conf file, which is the initial database. Any changes will be noted on stdout.

Repeat this process a few times until you're getting a feel for what is changing and how so. For instance, if you've got busy log files somewhere outside of /var, they might produce a bundle of changes every time you run afick, which will create white noise around potentially useful data. After you've got a list of repeat offenders, you can tune the linux.conf file.

The linux.conf file actually has a decent description of all the file attributes you can monitor, including device, inode, permissions, owner, last time modified, and several others. You can even create your own rule sets for certain types of files and directories. For instance, you don't want afick reporting warnings about the individual files in /var/log being modified, as these files are going to be modified almost constantly on some systems. To create a rule set that would check the user and group ownership, the device they reside on, and the permissions, you would first add:

#alias
specialrule = u+g+d+p

Then, to apply this custom rule to the /var/log directory, you would add the following line to the =/Dir section of the conf file:

/var/log specialrule

If you want to define a rule set that ignores the /tmp directory, checks only the files ending in .backup in /root, and ignores all files in /home/user that end in .old, you would add the following lines to the alias section of the config file.

!/tmp
/root/*.backup special_rule
exclude_re := /home/user/.*\.old

Afick recognizes the standard Unix wild cards and regular expressions in rule sets. With a little bit of tweaking, you can tune afick to completely monitor your filesystem in all the necessary places, while ignoring the spots that would generate useless noise.

After you've spent some time tweaking your configuration file you need to ensure that afick itself cannot be modified. The most secure way to accomplish this is to put the database, found by default at /var/lib/afick/afick.pag, somewhere that is write-only. Unfortunately a diskette isn't an option because of the size of the afick database; my database is roughly 15MB for a 4GB server. I recommend using an Iomega Zip disk for a couple reasons. Primarily, you can switch a Zip disk from read-only to read-write with the flip of a switch. This is convenient because every time you make a change to your filesystem you'll need to update the database to clear the warnings that afick will produce every time it runs thereafter, which could lead to wasting a lot of CDs if you tried to deploy the database on a CD-R.

No matter where you store your database, you still need to tell the configuration file where to find it. Mount your Zip drive (or your CD) and copy /var/lib/afick/afick.pag to your mount point. Then change the entry for the database location in the first section of the config file to represent the path to your removable media.

database=/mnt/zip/afick

In addition to storing the database on read-only media, I also choose to err on the side of paranoia, and I keep my config file on read-only media as well. In this case, it's a diskette that I've write-protected. This doesn't prevent afick from being run with a separate config file created locally on the server, but it does allow me to be sure that no small detail within the file can be changed without someone physically touching my servers.

Automating it

The final step in configuring afick is automating it. (Note that this is not strictly necessary if you wish to run afick only after certain tasks.) The easiest way to automate afick is with the afick.cron script included in the original directory where you unpacked the source code. If you installed via an RPM, then afick.cron was implemented upon your installation, and should be emailing root as changes occur. If you followed the instructions here and installed from source, you have to add it manually. At your command prompt, just type:

crontab -e
0*/2 * * * root /[path_to_afick.cron]/afick.cron

Then save and exit the editor. This tells your operating system to run afick once every two hours and mail the results, if any, to root.

Updating it

Every time you make a change to a filesystem, you'll want to update the afick database. Unfortunately, this is a point where security can begin to become an inconvenience. You must physically be at the server to change the Zip disk to read-write mode so the database can be updated.

To initiate update mode, simply replace the -k in the afick command line with -u. This will update the database to include any changes that have happened since the last time afick was run. Since afick will continue using the new database to ensure file integrity, you should always run afick once in compare mode before updating it, to be sure that the database you are about to create won't report recently compromised system commands or files as legitimate. As a further level of protection, afick has built-in integrity checks it performs on its own executables to ensure that afick itself hasn't been modified.

On a short side note, you can also use the update feature of afick to monitor exactly what changes a program's installation procedure makes to a filesystem by using the update feature immediately before and immediately after the installation. This is extremely useful in situations where you cannot verify the authenticity of an application before you install it. Just make sure when you test it with afick that you don't do so on a mission-critical machine. You can also use afick for retroactive testing to ensure uninstalling the software actually returns your filesystem to its previous state.

The future of afick

Afick is a work in progress. In recent conversations, developer Eric Gerbier said he intends to include in future releases a daemon-enabled version that doesn't rely on cron to run afick, thus delivering real-time filesystem monitoring. An option to export afick's results in HTML/XML is in the works for version 3.0, due out sometime in the next few months.

No system will ever be completely safe from malicious users and unauthorized access. If a machine under your control becomes compromised, you must have the proper precautions in place to quickly mitigate the damage and restore services. With a file integrity checker such as afick in place, when that dreaded day comes, you will be prepared to determine exactly what has happened (or is happening) and react accordingly.

In order for afick, or any other file integrity checker, to work as needed, you'll need to take special care in observing the general actions and changes in your filesystem in order to correctly and efficiently craft your configuration rules. Once you've done that, it's just a matter of staying on top of the ever-changing filesystem. Update regularly and update often, so as to catch problems as they begin, and not when it's too late. If you make these practices a regular part of your daily administration routines, you'll be prepared to react efficiently to a breach in security should the need arise.

Brian Warshawsky has built, supported, and administered mission-critical IT infastructure for the United States Naval Research Laboratory, Virginia Commonwealth University, RichmondAir Wireless, and is currently employed by Sungard Collegis at Virginia State University.

[Dec 2, 2004] Sys Admin Magazine v13, i12 Entrap A File Integrity Checker

Ed Schaefer and John Spurgeon

Verifying the integrity of files is an important systems administration task. Well-known systems administration authority Æleen Frisch says that "minimally, you should periodically check the ownership and permissions of important system files and directories." One method for verifying files is to take a snapshot of the system in a pristine state and compare it against subsequent snapshots.

You can use a product such as Tripwire (http://www.tripwire.com), or create your own such as our Entrap utility. Entrap is a suite of Korn shell scripts that compares two snapshots of a system and reports the differences. When two snapshots are compared, Entrap reports information about files that have been added, deleted, and modified.

An Entrap snapshot includes the file characteristics displayed by the command ls -ild, as well as optional file signatures, such as md5. Filtering rules may be set up to instruct Entrap to ignore specific files and/or attributes when comparing two snapshots.

In this column, we'll explain Entrap's configuration file. We'll discuss the commands used to take a snapshot, filter snapshots, and compare two snapshots. We'll review the directory structure, present an Entrap example, and include a high-level description of the Entrap scripts. We conclude with what's in the tarball and possible Entrap enhancements.

www.rpm.org homepage - RPM Package Manager

The stated early (10 November 2002) roadmap for that new rpm-4.2 release is to include:

a) file classes (think: sanitized file (1) output in dictionary, per-file index).

b) file color bits (think: 1=elf32, 2=elf64).

c) attaching dependencies to files, so that a refcount is computible.

d) replacing find-{provides,requires} with internal elfutils/file-3.39.

e) install policy based on file color bits

f) --excludeconfig like --excludedocs with the added twist that an internal Provides: will be turned off, exposing a Requires:. This will provide a means to install all %config files from a separate package if/when necessary.

and teaching tripwire to read file MD5's from an rpm database.

rpm-4.2 will be the next release of rpm.

changetrack is a program to monitor changes to files. If files are modified one day, and the machine starts working incorrectly some days later, changetrack can provide information on which files were modified, and help locate the problem. Changetrack will also allow recovery of the files from any stage.

Homepage: http://changetrack.sourceforge.net/
Tar/GZ: http://changetrack.sourceforge.net/change3_16.tar.gz
Debian package: http://packages.debian.org/stable/utils/changetrack.html
Demo site: http://changetrack.sourceforge.net/cgi-bin/changeweb.cgi

From: aleph1@securityfocus.com
Date: Thu Oct 18 2001 - 12:29:56 PDT

1. Writing Tripwire Policy Files

Tripwire Policy File Generator 0.62
  by Pjotr Prins (http://freshmeat.net/users/pjotrp/)
  Monday, October 15th 2001 13:11

Categories: System :: Installation/Setup, System :: Logging, System ::
Systems Administration

About: Tripwire Policy File Generator uses a Perl script -  mktrippol.pl -
that writes a Tripwire policy file from  an existing Linux setup. While it
targets ROCK Linux  it can really be used for any system. The script  reads
its commands from a Tripwire policy  file 'template' using name expansions.
It has a few  nice facilities like list expansion, directory walks,
variable adding  etc.

Changes: Support for tripwire installations in /opt/tripwire/sbin/.

License: GNU General Public License (GPL)

URL: http://freshmeat.net/projects/mktwpol/


--
Elias Levy
SecurityFocus
http://www.securityfocus.com/
Si vis pacem, para bellum

Hello, everyone:

For those not familiar with Tripwire, it is an intrusion detection tool that
tracks unauthorized modification of critical system files. The home site of
Tripwire is http://www.tripwire.org

I have been setting it up on our company's systems at my new job, and ran
into a problem. The default policy file listed so many non-existent files
that it would have been very tedious to go through every one of them and
comment it out by hand. To my surprise, I could not find a tool that would do
this automatically, so I quickly put together a simple perl script to solve
the problem:

--begin---
#! /usr/bin/perl

while (<>)
{
  if ($_ =~ /(\/[\w\-\.\/]+)/ && !($` =~ /#/))
  {
    $_ = "#$_" if (! -e "$1");
  }
  print $_;
}
---

Input is the default policy source file on STDIN or as first argument, output
on stdout is the new policy source file. Some pedants will probably comment
that my regexp does not cover every legal character you could possibly find
in a file. However, such characters are not found in the default policy file
names, so I did not worry about it.

Let's hope somebody finds this useful. If you know of an easier solution for
this problem, I would like to hear about it.

--
Sasha Pachev
Create online surveys at http://www.surveypro.com/

Recommended Links

---

In case of broken links please try to use Google search. If you find the page please notify us about new location

• Open Directory - Computers Security Intrusion Detection Systems
• [ packet storm ] - packetstorm.securify.com
• Finding Evidence of Your Cracker LG #36
• Intrusion Detection Primer
• Other potentially useful links from Brazil
• Osiris [hostintegrity.com]
• Samhain [sourceforge.net]

Reference

• Intrusion Detection FAQ
• FAQ Network Intrusion Detection Systems
• Linux Security Administrator's Guide by Dave Wreski, dave@nic.com
• Indicators of UNIX Host Compromise by Paul C. Brutch, Tasneem G. Brutch, and Udo Pooch

Recommended Articles

Host Integrity Monitoring Best Practices for Deployment by Brian Wotring

MD5 Tools

Claymore 0.2 by Sam Carter, Platforms: Linux
Size: 4.75Kb
Score: Notscoredyet

Claymore is an intrusion detection, and integrity monitor system. This release is a little more polished than before, but it still assumes that you know how to setup a crontab file. It is still fully functional, :-). To accomplish it's design goals, it reads in a list of files stored in flat ASCII, and uses md5sum to check their integrity against that recorded earlier in a database. If the database is placed on a read-only medium such as a write-protected floppy, then it should provide an infallible record against remotely installed trojan horses. Thus by monitoring the integrity of the file system, claymore will serve as an aid in intrusion detection.

Etc

Integrity checking utility (ICU) 0.1

Andreas Östling
http://nitzer.dhs.org/ICU/ICU.html

ICU (Integrity Checking Utility) is a PERL program used for executing AIDE filesystem integrity checks on remote hosts from an ICU server and sending reports via email. This is done with help from SSH.

Sentinel (develpment status: active?)

Download Sentinel for Linux (tar.gz file) - Available [ Sentinel v1.2.1c+ ] [ Sentinel v1.2.1c ] Sentinel is a fast file scanner similar to Tripwire or Viper with built in authentication using the RIPEMD 160 bit MAC hashing function. It uses a single database similar to Tripwire, maintains file integrity using the RIPEMD algorithm and also produces secure, signed logfiles. Its main design goal is to detect intruders modifying files. It also prevents intruders with root/superuser permissions from tampering with its log files and database. Disclaimer: this is not a security toolkit. It is a single purpose file/drive scanning program. Available versions are for linux (tested on all current Slackware and RedHat releases), with Irix versions soon to be added on.The tool can be downloaded from: http://zurk.sourceforge.net/zfile.html