– By Michael D. Bauer –
Dedicated host-based IDSes tend overwhelmingly to rely on integrity checking. In theory, host-based IDSes should use a much broader category of tools. Commercial IDS products, such as ISS RealSecure and Marcus Ranum’s Network Flight Recorder, both of which I categorize as Network IDSes, can use sophisticated methods (such as traffic analysis) on a single host, if desired.
Integrity checking involves the creation and maintenance of a protected database of checksums, cryptographic hashes, and other attributes of a host’s critical system files (and anything else you don’t expect to change on that system). The integrity checker periodically checks those files against the database: if a file has changed, an error or alert is logged. Ideally this database should be stored on a read-only volume, or off the system altogether, to prevent its being tampered with.
The assumption here is that unexpected changes may be the result of some sort of attack. For example, after “rooting” a system, a system cracker will often replace common system utilities such as ls, ps, and netstat with “rootkit” versions, which appear to work normally but conveniently neglect to list files, processes, and network connections (respectively) that might betray the cracker’s presence. (See http://www.chkrootkit.org/ for a script that can be used to detect installed rootkits and for links to many other related sites and articles.)
By regularly checking system utilities and other important files against the integrity checker’s database, we can minimize the chances of our system being compromised without our ever knowing it. The less time between a system’s compromise and its administrators’ learning that it’s been compromised, the greater the chance its administrators can catch or at least evict the intruders before too much damage is done.
Integrity checking has a beautiful simplicity: we don’t necessarily care how a monitored file has been changed; we mainly care that it has. To be effective, an integrity checker doesn’t need to be smart enough to know that /bin/ls no longer shows files belonging to the user evild00d; it only needs to know that /bin/ls has been altered since the last legitimate system update. Having said that, a good integrity checker will also tell us which external characteristics of /bin/ls have changed: its size, modification date, physical location (inode), etc.
Any integrity checker with an untrustworthy database is worthless. It’s imperative to create this database as soon as possible after installing the host’s operating system from trusted media. I repeat: installing, configuring, and maintaining an integrity checker is not worth the effort unless its database is initialized on a clean system.
Another thing to keep in mind with integrity checkers is that they are not proactive (unless one or more of your perimeter systems is a honeypot — a “sacrificial lamb” that will set off alerts when compromised so you can prevent other systems from being compromised too. However, I wouldn’t count on attackers obliging you by attacking the honeypot system first!) In most cases, by the time your integrity checker registers an alert, you’ve only got a small chance of intervening before a serious compromise occurs. Furthermore, the attacker may tamper with or altogether suppress the alert before it reaches you.
This does not mean that integrity checking is futile! On the contrary, the first step in incident response is learning that something has occurred in the first place, and if you install an integrity checker properly, you do have a better chance of learning about attacks soon enough to take meaningful action. If the worst happens, data from your integrity checker can be invaluable in figuring out what happened and in rebuilding your system if need be.
However, if you wish to do everything possible to detect attacks before they succeed, you’ll also need to deploy something more sophisticated — i.e., something in addition to integrity checking systems, which truly are your last line of defense.
This is an excerpt from Building Secure Servers with Linux by Michael D. Bauer, which has just been released by O’Reilly & Associates.
