Network detection

Why it matters

Host logs show what happened on a machine. A network intrusion detection system (IDS) shows what crossed the wire: scans, exploit attempts, malware calling home, data leaving. It also covers devices that cannot run agents, such as printers, cameras and network appliances. SOC analysts read IDS alerts every shift, and the skill is not memorising signatures but deciding quickly what an alert means and whether it matters.

IDS, IPS and how they detect

• An IDS watches a copy of traffic (from a span port or network tap) and raises alerts. It does not block anything.
• An IPS (intrusion prevention system) sits inline and can drop matching traffic. That is more protective but riskier: a bad rule can block legitimate users.

Detection works in two main ways:

Snort and Suricata are the best-known open-source signature engines. Zeek takes a different approach: it writes detailed logs of every connection, DNS query, HTTP request and TLS handshake, which analysts use for hunting. Security Onion bundles Suricata, Zeek and a search interface into one free distribution for labs and real networks.

Anatomy of a rule

Snort and Suricata share a rule format. Here is a simple local rule:

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"LOCAL SSH connection attempt from outside"; flow:to_server,established; sid:1000001; rev:1;)

• alert: the action (an IPS could use drop).
• tcp $EXTERNAL_NET any -> $HOME_NET 22: protocol, source, direction and destination. The variables are defined in the engine's configuration.
• msg: the text analysts see.
• flow: match only traffic going to the server on an established connection.
• sid and rev: the unique signature ID and its revision. Local rules use IDs of 1,000,000 and above.

Most teams do not write most rules themselves. They use curated rulesets such as the free Emerging Threats Open set and add a few local rules.

Reading an alert

Suricata writes alerts in JSON to eve.json (and a one-line summary to fast.log). A trimmed alert:

{
  "timestamp": "2026-10-23T09:41:12.512+0000",
  "event_type": "alert",
  "src_ip": "10.0.5.23",
  "src_port": 51544,
  "dest_ip": "198.51.100.77",
  "dest_port": 80,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "signature_id": 2100498,
    "signature": "GPL ATTACK_RESPONSE id check returned root",
    "category": "Potentially Bad Traffic",
    "severity": 2
  },
  "http": { "hostname": "198.51.100.77", "url": "/uid/index.html" }
}

Read it in this order:

1. What fired? The signature name and ID. Look up the rule text to see exactly what it matches. This one matches the text uid=0(root) in a response, which is what the Linux id command prints for the root user.
2. Which direction? Internal 10.0.5.23 fetched a page from external 198.51.100.77. The suspicious content came back in the response.
3. Was it allowed or blocked? allowed: this is an IDS, so the traffic went through.
4. How severe? Suricata severity 1 is the highest; 2 is medium.
5. What is the context? Which host is 10.0.5.23, who uses it, and is this a known test? Pivot to Zeek, proxy or DNS logs for the same IP and time.

Here the honest answer is often "it depends". This exact signature is used by the test page testmynids.org to confirm an IDS works, so an alert during an admin's setup test is benign. The same alert from a production web server's outbound traffic would be alarming: it could mean an attacker ran id through a web shell.

True and false positives

• True positive: the alert fired and the bad thing really happened.
• False positive: the alert fired but nothing bad happened (for example, a rule matching a harmless file).
• Benign true positive: the rule matched correctly, but the activity is authorised, such as a scheduled vulnerability scan.
• False negative: something bad happened and nothing fired. These are the dangerous ones, and you only find them by hunting or after an incident.

Tuning means reducing false positives without creating false negatives: suppressing a rule for one known scanner IP, adjusting thresholds, or disabling rules for software you do not run. Record every tuning change and why.

Encrypted traffic

Most web traffic is TLS, so signatures cannot see inside it. Network detection still sees metadata: destination IPs and ports, DNS names, TLS server names (SNI), certificate details, connection timing and size. Beaconing (a host connecting to the same rare domain every 60 seconds) stands out even when the content is encrypted.

Common mistakes

• Escalating on the signature name alone. Always check direction, context and the rule text.
• Placing the sensor where it cannot see. A sensor outside the firewall sees internet noise; one inside sees what actually got through and internal movement.
• Never tuning. Thousands of ignored alerts train analysts to miss the real one.
• Running a sensor on networks you do not own. Capturing other people's traffic without authorisation can be illegal.

Quick recap

• An IDS alerts; an IPS can block. Signatures are precise; anomaly detection is broader but noisier.
• Snort and Suricata use rules with an action, header and options including msg and sid.
• Read an alert by signature, direction, action, severity and context, then pivot to other logs.
• Classify as true positive, false positive or benign true positive, and tune carefully.

Try it

Open the Do tab to run Suricata on your own virtual machine and read a test alert.