🛡️ 10-02: NIDS vs. HIDS¶

📌 Two Places to Watch for Intrusions¶

An intrusion detection system needs data to inspect, and that data can come from two fundamentally different vantage points:

The network — the traffic flowing between machines
The host — the logs, files, and processes on a single machine

This gives us two categories of IDS: Network-based (NIDS) and Host-based (HIDS).

🌐 Network-Based IDS (NIDS)¶

A NIDS monitors traffic on the wire — it inspects packets as they travel across a network segment, looking for malicious patterns or anomalies (using the signature-based and anomaly-based techniques from 10-01: IDS/IPS Concepts).

Popular tools: Snort, Suricata, Zeek (formerly Bro)

How It Sees Traffic¶

A NIDS is typically connected to a SPAN/mirror port on a switch, or a network tap, so it receives a copy of every packet passing through that point
It does not need to be installed on every machine — one NIDS sensor can watch traffic for an entire subnet

What It Can Detect¶

Port scans and network reconnaissance
Exploit traffic targeting a known vulnerability (e.g., a malformed packet matching a known CVE)
DDoS traffic patterns
Command-and-control (C2) beaconing to a known malicious IP

What It Cannot See¶

Encrypted traffic (TLS/HTTPS) — a NIDS generally can't inspect the contents of encrypted payloads without a decryption proxy
Activity that happens entirely on the host and never touches the network (e.g., a malicious script run locally, a local privilege escalation)

🖥️ Host-Based IDS (HIDS)¶

A HIDS runs as an agent on a single machine and monitors that machine's internal state: system logs, file integrity, running processes, registry changes (on Windows), and user activity.

Popular tools: OSSEC, Wazuh, Tripwire

How It Sees Activity¶

Installed directly on the endpoint (server, workstation) as software
Reads local log files (e.g., /var/log/auth.log, Windows Event Logs)
Monitors file integrity — hashing critical system files and alerting if they change unexpectedly
Tracks process creation, user logins, and privilege escalations

What It Can Detect¶

Unauthorized file modifications (e.g., a system binary being replaced by malware)
Local privilege escalation attempts
Suspicious login patterns (e.g., repeated failed logins, logins at unusual hours)
Malware that never generates unusual network traffic

What It Cannot See¶

Broader network activity — a HIDS only knows about its own host, so it's blind to a port scan happening across the network or an attack targeting a different machine
Requires an agent to be installed and maintained on every host you want to protect — this doesn't scale as easily as one NIDS sensor watching a whole subnet

🗺️ Where Each Is Deployed (Network Diagram Description)¶

Picture a typical corporate network:

                [ Internet ]
                     |
                [ Firewall ]
                     |
         ┌──────── SPAN/Mirror Port ─────────┐
         |                                     |
   [ Core Switch ]  ---------------->   [ NIDS Sensor ]
         |
   ┌─────┼─────────────┬───────────────┐
   |                    |               |
[ Web Server ]   [ DB Server ]   [ Employee Workstation ]
   |                    |               |
[ HIDS Agent ]   [ HIDS Agent ]   [ HIDS Agent ]

The NIDS sensor sits off to the side, plugged into a switch's mirror port, watching all traffic that flows through the core switch — one sensor covers many machines.
A HIDS agent runs inside each individual server or workstation, watching only what happens locally on that machine.
A NIDS is well-placed at network chokepoints (perimeter, between network segments/VLANs, in front of a DMZ); a HIDS is well-placed on high-value individual assets (domain controllers, database servers, critical workstations).

⚖️ NIDS vs. HIDS Comparison¶

Feature	NIDS	HIDS
Vantage point	Network traffic (the wire)	Single host (logs, files, processes)
Deployment	One sensor covers many hosts	One agent per host
Visibility into encrypted traffic	Limited (can't read TLS payloads)	Full (sees traffic after decryption on the host)
Detects network-wide attacks (scans, DDoS)	✅ Yes	❌ No
Detects local file tampering / malware	❌ No	✅ Yes
Scalability	Easy to scale across a subnet	Must install/maintain agents everywhere
Example tools	Snort, Suricata, Zeek	OSSEC, Wazuh, Tripwire

🤝 Why Mature Security Programs Use Both¶

Neither approach alone gives full visibility:

A NIDS can see an attacker scanning the network and sending exploit traffic, but it goes blind the moment traffic is encrypted or the attacker is already operating locally on a compromised host.
A HIDS can see what happens after the attacker lands on a machine (file changes, new processes, privilege escalation), but it has no idea what's happening on the wire or on other machines.

💡 Defense in depth: combining NIDS (network-wide visibility) with HIDS (deep host-level visibility) closes the blind spots that either one has on its own. Most enterprise Security Operations Centers (SOCs) feed alerts from both NIDS and HIDS sensors into a central SIEM (Security Information and Event Management) system for correlated analysis.

📌 Key Takeaways¶

NIDS monitors network traffic on the wire (e.g., Snort, Suricata); HIDS monitors a single host's logs, files, and processes (e.g., OSSEC).
A NIDS is deployed at network chokepoints via a mirror port/tap and covers many machines from one sensor.
A HIDS is deployed as an agent on individual high-value hosts and only sees that host's activity.
NIDS struggles with encrypted traffic and can't see purely local activity; HIDS struggles to see network-wide patterns like scans or DDoS.
A mature security program layers both, feeding alerts into a central SIEM for full visibility — this is a form of defense in depth.