What is a host-based intrusion detection system (HIDS)?

How a HIDS works

A HIDS collects what the host can tell it, compares that with rules or a baseline, and reports what does not fit. Because it runs on the machine it protects, it sees activity that never crosses a network sensor, such as a local user editing sudoers or a process started by cron. Most implementations combine four sources:

• Logs: the authentication log or the systemd journal, the system log and application logs, matched against rules such as repeated login failures.
• File integrity: hashes, owners and permissions of the files that matter (SSH daemon configuration, sudoers, cron, systemd units, system binaries), checked again so that an edit shows as a before and after.
• Processes: what is running, from which executable, with which command line and as which user, usually read from /proc.
• Network: listening ports and established connections, read from the kernel's tables.

Some products add rootkit checks and an active response, such as a firewall block. Many run as an agent on each host reporting to a central manager that holds the rules and stores the alerts.

What a HIDS notices on a Linux server

The signals are ordinary system events. What makes them interesting is the context: who did it, when, and whether anything planned explains it.

• A run of "Failed password" and "Invalid user" lines in /var/log/auth.log (Ubuntu, and Debian with rsyslog), /var/log/secure (Rocky Linux and AlmaLinux) or the journal, followed by "Accepted password" from the same address.
• A new line in an authorized_keys file, root's or anyone else's, which gives someone a way back in that survives a password change.
• A new entry in /etc/cron.d or a user's crontab that downloads a script from an unfamiliar address and runs it.
• A process whose executable lives in /tmp, /var/tmp or /dev/shm, directories any user can write to and not where packaged software runs from.
• A changed sudoers file, a new local account, or a system binary whose hash no longer matches its package.

None of these proves an intrusion; administrators add keys and cron jobs too. A HIDS earns its keep by reporting the change with enough evidence (the text before and after, the source address, the command line) for a person to decide quickly whether it was planned.

Signs a Linux server has been hackedAuth log analyzer

HIDS vs NIDS

A network intrusion detection system (NIDS) watches traffic at a point in the network, such as a mirror port or a gateway, and matches packets and flows against signatures. Snort and Suricata are open-source examples. One sensor covers many machines and sees attacks against hosts that log nothing about them.

A NIDS cannot see inside a server: once traffic is encrypted, or an attacker is logged in, it does not know that a key was added or a cron line changed. A HIDS sees exactly that, but only on its own host, and only while that host can be trusted. NIST's guide to intrusion detection treats them as separate classes and suggests using more than one type.

HIDS, EDR, SIEM and antivirus compared

• HIDS: watches one host's logs, files, processes and connections and alerts on rules or changes. Response, where it exists, is usually limited to actions such as a firewall block.
• EDR (endpoint detection and response): records detailed endpoint activity, often through deeper operating system hooks, and gives an analyst actions such as isolating a host or ending a process. Built mainly for large fleets with a security team watching.
• SIEM (security information and event management): collects logs from many sources, including HIDS alerts, firewalls and applications, and correlates them centrally. It watches no host itself; it depends on what is sent to it.
• Antivirus: scans files, and sometimes memory, for known malicious content. It answers "is this file bad?" rather than "what changed on this server, and who changed it?"
• File integrity monitoring (FIM): one component of most HIDS, also run on its own when a framework asks for it by name.

A small team rarely needs all of these. The usual question is whether one host-based agent covers enough.

EDR vs a Linux agent for small teamsWhat is a security agent?

Open-source examples

OSSEC and Wazuh are open-source HIDS built around an agent on each host and a central manager. Samhain is an open-source host integrity and intrusion detection system, also with a client and server arrangement. AIDE (Advanced Intrusion Detection Environment) is narrower: it builds a database of file attributes and hashes and reports differences when you run a check, which makes it a file integrity tool rather than a full HIDS. What they have in common is that someone has to run them: install the agents, keep the manager alive, tune the rules and read the output.

SecAI vs OSSECSecAI vs Wazuh

What a HIDS cannot do

• It cannot be fully trusted once the attacker has root. Root can stop the agent, change its rules, edit the logs it reads or hide a process; MITRE ATT&CK lists disabling security tools and clearing system logs as known techniques. Sending results off the host, and alerting when a host goes quiet, narrows the gap without closing it.
• It is noisy until tuned. Default rules flag routine administration, updates and backups, and a team flooded with low-value alerts stops reading them.
• It needs care as the server changes: new software, paths and administrators all shift what normal looks like.
• Detection is not prevention. It tells you a key was added; patching, key-only SSH, least privilege and a firewall do the preventing.
• It sees one host. A pattern across many servers only shows when the alerts are brought together.

Where SecAI fits

SecAI's agent is a host-based detector in this sense. On the server itself it reports SSH brute force and any successful login that follows failures or comes from a new source, processes running from temp directories, changes to cron, systemd units, sudoers, accounts and authorized_keys (with the text before and after for persistence files), and outbound connections to destinations the server has not used before. Most detections are alerts with evidence and propose nothing.

The one action it takes without a person is blocking an address seen attacking the server, only on a server set to Automatic: through the firewall the server already runs, expiring on its own after 6 hours (longer for an address that keeps coming back, never more than 7 days), never against the owner's own or trusted addresses, within minutes. It also reports edits to its own systemd unit and alerts when the agent goes offline or receives a stop signal: a gap you are told about, not a gap closed. SecAI is not antivirus and not a SIEM.

Linux threat detection in SecAIDetection coverage, row by row