This study compares seven freely available (mostly open-source) 
    file/host integrity scanners (file integrity check
    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 corner cases of the filesystem
     (that may e.g. result from an intrusion, or from simple errors of 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 Debian 3.0 Linux system.
    In general, tests were performed only with console logging (stdout/stderr).
    

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

    
    By Rainer Wichmann
    Caveat: The author of
    this study is also the author of one of these file integrity scanners
    (samhain). I.e. this study may be biased, because:
     
    (a) the tests in this study are based on user feedback for samhain and
    the authors personal opinion on what basic functionality a file
    integrity scanner should provide, and 
    
    (b) a bug in samhain found during
    this study was fixed (see the remark on samhain under 
    Remarks on individual programs).
     
    If you think some of the results presented here are incorrect or outdated, 
    you are welcome to point out corrections.
    

    The lack of a trademark sign does not imply the non-existence
    of a trademark.
    

    Content

    What is the focus of this study ?

    Explanation of table rows

    Table of results


    Remarks on individual programs

    Relative speed

    Logging options

    Centralized management: osiris and samhain


    What is the focus of this study ?

    
    This study compares seven freely available (mostly open-source) 
    file/host integrity scanners (file integrity check
    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 corner cases of the filesystem
     (that may e.g. result from an intrusion, or from simple errors of 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 Debian 3.0 Linux system.
    In general, tests were performed only with console logging (stdout/stderr).
    

    
    Thus, while some "features" of these programs
    are mentioned that may be of interest for useability, 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
	     globbing 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 /

	     drwxr-xr-x    2 root     root         4096 Feb 11 20:16 "