# OSSEC HIDS: host intrusion detection, log analysis and file integrity in one agent

> OSSEC is a GPL-2.0 host-based intrusion detection platform written in C, combining log analysis, file integrity checking, rootkit detection and active response. Here is how its manager and agent model works, how to install it, and where it stops being the right tool.

**ossec/ossec-hids** — OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.

- Repository: https://github.com/ossec/ossec-hids
- Website: http://www.ossec.net
- Stars: 5,059 · Forks: 1,072
- Language: C
- License: GPL-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/ossec-ossec-hids

## What OSSEC actually watches, and who ends up running it

OSSEC is a host-based intrusion detection system. The README describes it as "a full platform to monitor and control your systems" that mixes HIDS, log monitoring and SIM/SIEM functions into one open source package. The topics attached to the repository name the same ground: file integrity management, policy monitoring, PCI-DSS and NIST 800-53 compliance, rootkit detection.

The unit of deployment is the host, not the network. OSSEC reads files and logs on the machine it is installed on, which is the opposite of a network IDS that inspects packets on a span port. That distinction matters when you plan coverage: an OSSEC deployment tells you what changed on a server and what its logs say, not what crossed the wire between two servers.

The people who end up running it are system and security engineers comfortable with Linux, a config file, and a service they own. The repository is C with an install.sh at the top level, an etc/ directory for configuration and a src/ directory for the build. There is no hosted control plane in the README. You supply the manager host.

## Manager, agent and the alert path between them

The architecture is a manager plus agents. The manager holds the rules, receives events, and stores alerts. Agents run on monitored hosts, collect local data and forward it. The repository layout supports this reading: etc/ holds configuration, active-response/ holds the response scripts, and src/ holds the C sources that build the manager, agent and local binaries.

Data flows in one direction for detection: an agent sees a log line or a changed file, applies its side of the configuration, and ships the event to the manager. The manager decodes it, matches it against rules, assigns a severity level, and decides whether to alert or to fire an active response. Active response is the part that separates OSSEC from a pure log shipper: the manager can trigger a script on the agent, and the active-response/ directory exists for exactly that.

File integrity monitoring is the other visible mechanism. The README ships a FIM screenshot and an SSH brute force screenshot, which reflects the two demos the project leads with. FIM works by hashing watched paths and comparing against a stored baseline, so the first run establishes state and later runs report drift. That also means your first scan is not a detection event, and a noisy first run is normal.

## Installing OSSEC HIDS and running a first agent

The README does not carry install commands. It points to the downloads page at ossec.net and to the documentation at ossec.net/docs, and it notes that the development version is a git clone away. The repository does contain install.sh at the top level, so the supported path is to obtain a release and run that script, or to clone and build from src/.

Start by cloning the development tree, which is what the README describes as "just a simple git clone away":

```bash
git clone https://github.com/ossec/ossec-hids.git
cd ossec-hids
```

The installer is interactive and asks which install type you want. Run it from the repository root:

```bash
sudo ./install.sh
```

According to the repository layout, install.sh drives the build and asks you to choose between a server, an agent, a local install and a hybrid. Pick agent on the host you want to monitor and server on the host that will receive alerts. The etc/ directory is where the resulting configuration lands, and it is the file you edit to point an agent at its manager.

On the manager side, the configuration you care about first is the rule set and the list of agents. The documentation at ossec.net/docs is the reference for the exact keys, because the README does not reproduce them. After the installer finishes, the service is managed by the init script the installer placed on the system, and the first thing to check is that the agent shows up on the manager.

If you only want to evaluate, a local install on a single machine is the smallest footprint: it runs the manager and agent together and writes alerts locally, so you can see detections without a second host.

## Where OSSEC is the wrong tool

OSSEC is host-based, and that is a hard boundary. If your problem is east-west traffic between containers, DNS tunnelling, or a TLS session you cannot decrypt, a host agent has nothing to read. You need something that sees packets, and OSSEC will not become that.

The manager is a single point of aggregation. The README does not document a clustered or highly available manager, and the repository has no such component in its top-level layout. If the manager is down, agents have nowhere to send events, and you have a gap in coverage. Plan for that gap rather than assuming the platform handles it.

Configuration is file-based and rule-based. There is no documented web console in the README; the screenshots show alert output, not an administration UI. A team that expects to click through dashboards will spend its first week in config files. The project also predates modern container-native tooling, so if your fleet is ephemeral containers, an agent that expects a persistent host and a baseline file is awkward.

Finally, the README is thin on operational detail. It documents what OSSEC is, where to download it, and where to find docs. It does not document upgrade or rollback procedure, which means you should read CHANGELOG.md and the documentation site before you upgrade a production manager.

## OSSEC versus network-based detection and versus Wazuh

The clearest alternative in kind is a network intrusion detection system. A NIDS inspects traffic on a monitored interface and flags patterns in packets; OSSEC inspects the host and flags patterns in logs and file state. They answer different questions. A NIDS can see an exploit attempt against a service before it writes anything to disk. OSSEC can see the file that changed after the exploit succeeded, and the log line the service wrote on the way out. Many environments run both, and the choice is not either-or.

The more direct fork in the road is Wazuh, which descends from OSSEC and is the project most teams compare against when they outgrow a single manager. The practical difference is scope of the surrounding platform: OSSEC ships as a manager, agents and a rule set, while the Wazuh lineage adds a search and dashboard layer around the same agent concept. If you want the agent model with a queryable interface out of the box, that is the direction to look. If you want a small C codebase you can read end to end and a config you fully control, OSSEC is the smaller thing to own.

A third option is a commercial EDR agent. Those bundle detection content, a hosted console and vendor support. The trade is cost and data leaving your network. OSSEC keeps the data on your manager, which is often the reason people pick it.

## Licence, maintenance and the cost of upgrading

OSSEC is licensed under GPL-2.0. The README also states that the project ships a modified version of zlib and small parts of OpenSSL (sha1 and blowfish), plus software from the cJSON project. Those bundled components matter if you redistribute a build, because their terms travel with the code. This is not legal advice; if you embed OSSEC in a product you ship, have counsel read the LICENSE file and the notices in the README.

The repository is not archived, and the last push was on 2026-09-17. Recent releases listed are 4.3.0 on 2026-08-25, 4.2.0 on 2026-08-02 and 4.1.0 on 2026-05-27, while the README header reads OSSEC v4.4.0. That version drift between the README header and the release list is worth checking against CHANGELOG.md before you pin a version in your own build pipeline.

Upgrade cost is mostly re-testing your rule set. Custom rules and decoders live in etc/, and a version bump can change how existing rules match. The README does not document a rollback procedure, so keep the previous install tree and your etc/ directory under version control before you upgrade a manager. Agents and manager should be upgraded together, since an agent newer than its manager has no documented compatibility guarantee.

## Conclusion

Adopt OSSEC when you need host-level log correlation, file integrity checking and a response hook on servers you control, and you are willing to run a manager plus agents yourself. Do not adopt it if you want a managed cloud SIEM with no server to operate, or if your estate is mostly Windows endpoints and you have no appetite for the agent build. Before committing, verify that the release you download from the ossec.net downloads page matches the version in CHANGELOG.md, and read install.sh to confirm which manager, agent or local install type your platform supports.

## FAQ

### What is OSSEC HIDS?

OSSEC is an open source host-based intrusion detection system. The README describes it as a full platform that mixes HIDS, log monitoring and SIM/SIEM functions, and it is written in C under GPL-2.0.

### Is OSSEC legit?

It is a real open source project: the repository at ossec/ossec-hids is public, not archived, licensed GPL-2.0, and the README points to releases on ossec.net and to documentation at ossec.net/docs.

### What is the difference between HIDS and NIDS?

A HIDS such as OSSEC runs on the host and watches logs, files and local state. A NIDS watches network traffic. OSSEC's own scope is host-based, so it does not inspect packets between machines.

## Sources

- [License: GPL-2.0](https://github.com/ossec/ossec-hids/blob/main/LICENSE)
- [ossec/ossec-hids on GitHub](https://github.com/ossec/ossec-hids)
- [Project website](http://www.ossec.net)
- [README](https://github.com/ossec/ossec-hids/blob/main/README.md)
- [Releases](https://github.com/ossec/ossec-hids/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ossec-ossec-hids