Host-Based Intrusion Detection System (HIDS)¶
Intro¶
ANMS Host-Based Intrusion Detection System (HIDS) service is based on the open-source solution “OSSEC” (Open-Source Security), an open-source project that was later acquired by TrendMicro in 2009.
OSSEC performs log analysis and correlation, file integrity checking, rootkit detection, time-based alerting and active response. The OSSEC HIDS project has been gaining widespread use and is quickly being deployed within organizations around the world as a method of protecting systems at the host level after attacks have made it past network defences. Intrusion detection is the act of detecting events that have been deemed inappropriate or unwelcome by the business, organizational unit, department, or group. This can be anything from the emailing of company secrets to a competitor, to malicious attacks from a host on the Internet, to the viewing of inappropriate Web content during your lunch break.
Service Overview¶
Network IDS vs Host-Based IDS¶
Network intrusion detection systems have become widely used over the past decade because of the impressive capability to provide a granular view of what is happening on your network. The NIDS monitors network traffic using a network interface card (NIC) that is directly connected into your network. A signature or pattern is used to match specific events, such as an attack attempt, to traffic seen on your network. If the traffic seen on your network matches your defined IDS signature, an alert is generated. An alert can also trigger an action, such as logging the alert to a file, sending an email to someone with details of the alert, or following an action to address this alert, such as adding a firewall rule to block the traffic on another device.
An HIDS detects events on a server or workstation and can generate alerts similar to a NIDS. An HIDS, however, is able to inspect the full communications stream. NIDS evasion techniques, such as fragmentation attacks or session splicing, do not apply because the HIDS is able to inspect the fully recombined session as it is presented to the operating system.
Encrypted communications can be monitored because your HIDS inspection can look at the traffic before it is encrypted. This means that HIDS signatures will still be able to match against common attacks and not be blinded by encryption. An HIDS is also capable of performing additional system level checks that only IDS software installed on a host machine can do, such as file integrity checking, registry monitoring, log analysis, rootkit detection, and active response.
OSSEC HIDS FEATURES¶
File Integrity Checking
Every file on an operating system generates a unique digital fingerprint, also known as a cryptographic hash. This fingerprint is generated based on the name and contents of the file. An HIDS can monitor important files to detect changes in this fingerprint when someone, or something, modifies the contents of the file or replaces the file with a completely different version of the file.
Registry Monitoring
The system registry is a directory listing of all hardware and software settings, operating system configurations, and users, groups, and preferences on a Microsoft Windows system. Changes made by users and administrators to the system are recorded in the system registry keys so that the changes are saved when the user logs out or the system is rebooted. The registry also allows you to look at how the system kernel interacts with hardware and software.
An HIDS can watch for these changes to important registry keys to ensure that a user or application isn’t installing a new or modifying an existing program with malicious intent. For example, a password management utility can be replaced with a modified executable and the registry key changed to point to the malicious copy.
Rootkit Detection
A rootkit is a program developed to gain covert control over an operating system while hiding from and interacting with the system on which it is installed. An installed rootkit can hide services, processes, ports, files, directories, and registry keys from the rest of the operating system and from the user. Several types of rootkits are currently available:
Firmware: A firmware rootkit is just as it sounds, a rootkit installed with your firmware. This type of rootkit is difficult to detect because you will typically have to inspect the compiled installation package prior to installing it on your firewall, router, switch, or appliance.
Virtualized: A virtualized rootkit installs between the system hardware and the operating system to intercept system calls. This type of rootkit is typically loaded at boot time and treats your operating system as a virtual machine. Any interaction you have with your computer is inspected and silently altered at the leisure of the installed rootkit.
Kernel level: A kernel level rootkit replaces code associated with the system’s kernel, typically through device drivers or loadable kernel modules, to hide the rootkit processes from the rest of the system. These rootkits can be very difficult to detect once installed because the kernel level rootkit tricks your system into reporting that nothing is out of the ordinary.
Library level: A library level rootkit will patch or hook into system calls to hide information about the attacker from the system.
Application level: An application level rootkit, one of the most common types of rootkits, replaces a known application binary with the attacker’s own copy of the binary. This is commonly referred to as a “trojanized” version of the original binary; drawing reference from the story of the Trojan Horse used to conceal Greek soldiers during the Trojan War
Active Response
The Active Response feature within OSSEC can run applications on an agent or server in response to certain triggers. These triggers can be specific alerts, alert levels, or rule groups. The active response framework is also what allows an OSSEC administrator to start a syscheck scan or restart OSSEC on a remote agent.
Active response allows you to automatically execute commands or responses when a specific event or set of events is triggered.
The benefits of active response are enormous, but also risky. For example, legitimate traffic might generate a false positive and block a legitimate user/host if the rules are poorly designed. If an attacker knows that your HIDS blocks a certain traffic signature, the attacker could spoof IP addresses of critical servers in your infrastructure to deny you access. This is essentially a DoS attack that prevents your host from interacting with that IP address.
Firewall Rules¶
| Source | Destination | Protocol | Port | Direction |
|---|---|---|---|---|
| All OSSEC Agents | ANMS OSSEC Manager | UDP | 1514 | Outbound |
| All OSSEC Agents | ANMS OSSEC Manager | TCP | 1515 | Outbound |
