It is very difficult to compromise a system without altering a system file, so file integrity checkers are an important capability in intrusion detection. A file integrity checker computes a checksum for every guarded file and stores this. At a later time you can compute a checksum again and test the current value against the stored value to determine if the file has been modified. A file integrity checker is a capability that you should expect to receive with any commercial host based intrusion detection system.
The primary checksum that was used for this was a 32 bit CRC (Cyclic Redundancy Check). Attackers have demonstrated the ability to modify a file in ways the CRC checksum could not detect, so stronger checksums known as cryptographic hashes are recommended. Example of cryptographic hashes include MD5, and snefru.
One of the challenges in using a file integrity checker is the false positive problem. When you update files or apply system patches this changes the file. Creating the initial database of signatures is easy, keeping it up to date is much harder. However, even if you only run the checker once (when you first install the system) this can still be very valuable. If there is ever concern that the system was compromised you can run the checker again to determine which files have, or have not been modified.
The other challenge with a file integrity checker is that you have to have a pristine system when you create the first reference database. Otherwise you may be creating cryptographic hashes of a compromised system while feeling warm and fuzzy that you are implementing good security. It is also very important that you store the reference database offline or an attacker may be able to compromise the system and hide their tracks by modifying the reference database.
The integrity checker tools include tripwire, (ftp://coast.cs.purdue.edu/pub/tools/unix or www.tripwiresecurity.com) L5, and SPI (SPI is available for US Government users only from http://ciac.llnl.gov).