A Host-based Intrusion Detection System (HIDS) is a special category of an Intrusion-Detection System which focuses its monitoring and analysis on the internals of a computing system rather than its external interfaces (Network Intrusion Detection System NIDS).
Overview
A HIDS will monitor all or part of the dynamic behavior and state of a computer system. Much like a NIDS will inspect network packets a HIDS might consider which program is accessing what resources and assure that say a word-processor hasn't suddenly and inexplicably started modifying the system password database. Similarly a HIDS might look at the state of a system, its stored information, be that in RAM or the file system or elsewhere, and check that it is still ok.
A HIDS can be thought of as an Agent that monitors whether the Security policy that the Operating System is supposed to enforce was circumvented somehow.
Monitoring Dynamic behavior
Most people are familiar with tools that monitor dynamic system behavior in the form of Anti-Virus packages. While AV programs often also monitor system state, they do spend a lot of their time looking at who is doing what inside a computer - and whether a program should or should not be accessing one or another system resource. The lines become very blurred here, as many of the tools overlap in functionality.
Monitoring State
The principle of operation of a HIDS is that a successful intruder (cracker) will generally leave a trace of their activities and in fact want to own the computer being attacked by installing software that will grant the intruder future access to carry out whatever activity (Keyboard logger, Identity theft, Spamming, botnet, Spyware etc.) is desired.
Such modifications ought, in theory, be detectable, and the HIDS attempts to do just that and report its findings.
Ideally a HIDS works in conjunction with a NIDS, such that anything that slips past the NIDS is found by the HIDS.
Ironically the first things most intruders do is to apply best practice techniques to secure the system being attacked, leaving only their own Backdoor open, so that other intruders can not take over their computers. Crackers are a competitive bunch. Again, such changes can be detected and learnt from.
Technique
In general a HIDS uses a database of system objects it should monitor (object-database). These are mostly file-system objects, but do not have to be. There is no reason why a HIDS could not check appropriate regions of memory have not been modified for example - the system-call table comes to mind for Linux - and various vtable structures in Windows could similarly be checked.
For each object in question a HIDS will usually remember its attributes (permissions, size, modifications dates) and perhaps create a checksum of some kind for the contents, if any. An MD5 hash or similar. This information is stored in a database for later comparison (checksum-database). Note that an MD5 hash is not a complete guarantee that a target file has not been tampered with. Recent (2004) research has resulted in claims (still being debated) that the probability of such is not quite as low as one would hope.
Operation
At installation time - and whenever any of the objects are supposed to change - the checksum-database has to be initialized by scanning the relevant objects. This is a process that needs to be tightly controlled, to avoid intruders making un-authorized changes to the database(s). It is thus generally time-consuming, involves crypto-graphically locking the object and checksum databases or worse. As a result, the object-database is usually constructed in such a way that makes frequent updates to the checksum database unnecessary.
There are many dynamic (frequently changing) objects in a computer system that intruders want to modify - and a HIDS thus wants to monitor - but are unsuitable for the checksum technique. To overcome this various other detections techniques are employed. Monitoring changing file-attributes, log-files that got smaller since last we looked and a raft of other means to detect unusual events.
Once a suitable object-database has been constructed by the system administrator - with help and advice from the HIDS installation tools it is hoped - and the checksum-database has been initialized, the HIDS is ready to regularly scan the objects and report on anything that has gone wrong. Reports can be in the form of logs, e-mails or similar.
Protecting the HIDS
A HIDS will usually go to great lengths to prevent the object-database, checksum-database and its reports from being tampered with in any way. After all, if an intruder has managed to modify any of the objects the HIDS is monitoring, there is nothing to stop them from modifying the HIDS itself - unless precautions are taken. Many worms and viruses will try to disable AV tools for example. Sadly, a lot of them succeed in doing so.
Apart from crypto-techniques, HIDS might allow administrators to put the databases on a CD-ROM or other read-only memory (hence the desire for infrequent updates...) or storing them in some off-system memory. Similarly the logs are often sent off-system immediately - in some instances via one-way communications channels, such as a serial port which only has Transmit connected for example.
It could be argued that the Trusted Platform Module is a type of HIDS. Although its scope is different in many ways from that of a HIDS, fundamentally it provides a means to identify whether a portion of the computer has been tampered with. Architecturally this is the ultimate (at least at this point in time) of Host-based intrusion detection, as it is based on hardware that is external to the CPU itself, thus making it that much harder for an intruder to corrupt its object and checksum databases.
See also
External links
