Host-based intrusion detection system
From Wikipedia, the free encyclopedia
A host-based intrusion detection system (HIDS) is an intrusion detection system that focuses its monitoring and analysis on the internals of a computing system rather than on its external interfaces (as a network intrusion detection system (NIDS) would do).
Contents |
[edit] Overview
A HIDS will monitor all or part of the dynamic behavior and of the state of a computer system. Much as a NIDS will dynamically inspect network packets, a HIDS might detect which program accesses 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, whether in RAM, in the file-system, or elsewhere; and check that the contents of these appear as expected.
One can think of a HIDS as an agent that monitors whether anything/anyone - internal or external - has circumvented the security policy that the operating system tries to enforce.
[edit] Monitoring dynamic behavior
Many computer users have encountered tools that monitor dynamic system behavior in the form of anti-virus (AV) 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 given program should or should not access one or another system resource. The lines become very blurred here, as many of the tools overlap in functionality.
[edit] Monitoring state
The principle of operation of a HIDS depends on the fact that successful intruders (crackers) will generally leave a trace of their activities. (In fact, such intruders often want to own the computer they have attacked, and will establish their "ownership" by installing software that will grant the intruders future access to carry out whatever activity (keyboard logging, identity theft, spamming, botnet activity, spyware-usage etc.) they envisage.
In theory, a computer user has the ability to detect any such modifications, and the HIDS attempts to do just that and reports its findings.
Ideally a HIDS works in conjunction with a NIDS, such that a HIDS finds anything that slips past the NIDS.
Ironically, most successful intruders, on entering a target machine, immediately apply best-practice security techniques to secure the system which they have infiltrated, leaving only their own backdoor open, so that other intruders can not take over their computers. (Crackers are a competitive bunch...) Again, one can detect (and learn from) such changes.
[edit] Technique
In general a HIDS uses a database (object-database) of system objects it should monitor - usually (but not necessarily) file-system objects. A HIDS could also check that appropriate regions of memory have not been modified, for example - the system-call table comes to mind for Linux, and various vtable structures in Microsoft Windows.
For each object in question a HIDS will usually remember its attributes (permissions, size, modifications dates) and perhaps create a checksum of some kind (an MD5 hash or similar) for the contents, if any. This information gets stored in a database for later comparison (checksum-database). Note that a matching MD5 hash does not provide a complete guarantee that an intruder or other unauthorised user has not tampered with the target file. Recent (2004) research has resulted in claims (still under debate) that the probability of such tampering may exceed what one might hope.
[edit] Operation
At installation time - and whenever any of the monitored objects change legitimately - a HIDS must initialise its checksum-database by scanning the relevant objects. Persons in charge of computer security need to control this process tightly in order to prevent intruders making un-authorized changes to the database(s). Such initialisation thus generally takes a long time and involves cryptographically locking each monitored object and the checksum databases or worse. Because of this, manufacturers of HIDS usually construct the object-database in such a way that makes frequent updates to the checksum database unnecessary.
Computer systems generally have many dynamic (frequently changing) objects which intruders want to modify - and which a HIDS thus should monitor - but their dynamic nature makes them unsuitable for the checksum technique. To overcome this problem, HIDS employ various other detection techniques: monitoring changing file-attributes, log-files that decreased in size since last checked, and a raft of other means to detect unusual events.
Once a system administrator has constructed a suitable object-database - ideally with help and advice from the HIDS installation tools - and initialized the checksum-database, the HIDS has all it requires to scan the monitored objects regularly and to report on anything that may appear to have gone wrong. Reports can take the form of logs, e-mails or similar.
[edit] Protecting the HIDS
A HIDS will usually go to great lengths to prevent the object-database, checksum-database and its reports from any form of tampering. After all, if intruders succeed in modifying any of the objects the HIDS monitors, nothing can stop such intruders from modifying the HIDS itself - unless security administrators take appropriate precautions. Many worms and viruses will try to disable anti-virus tools, for example. Sadly, a lot of them succeed in doing so.
Apart from crypto-techniques, HIDS might allow administrators to store the databases on a CD-ROM or on other read-only memory devices (another factor militating for infrequent updates...) or storing them in some off-system memory. Similarly, a HIDS will often send its logs off-system immediately - in some instances via one-way communications channels, such as a serial port which only has "Transmit" connected, for example.
One could argue that the trusted platform module comprises a type of HIDS. Although its scope differs in many ways from that of a HIDS, fundamentally it provides a means to identify whether anything/anyone has tampered with a portion of a computer. Architecturally this provides the ultimate (at least at this point in time) host-based intrusion detection, as depends on hardware external to the CPU itself, thus making it that much harder for an intruder to corrupt its object and checksum databases.
[edit] See also
- Intrusion detection system (IDS)
- Network intrusion detection system (NIDS)
- Protocol-based intrusion detection system (PIDS)
- Application protocol-based intrusion detection system (APIDS)
- Tripwire (software) - a pioneering HIDS
- Trusted Computing Group
- Trusted platform module
- Cfengine - can be instructed to check most anything on Unix machines (and fix when needed)
[edit] External links
 |
The external links in this article may require cleanup to comply with Wikipedia's content policies. Please improve this article by removing excessive or inappropriate external links. Please remove this tag when this is done. (talk) |
- A comparison of most the Open Source HIDS
- OSSEC - an Open Source HIDS
- AFICK (an open source HIDS)
- Samhain - an Open Source HIDS
- Beltane (for use with Samhain)
- Osiris - an Open Source HIDS
- md5deep - an Open Source HIDS
- Aide - an Open Source HIDS that aims to do what tripwire does
- Snort - an Open Source NIDS
- serverM - an Open Source HIDS for Linux/Mac OS X
