What NIDS Sees

From Endpoint to Network

In Modules 1 and 2, you spent your time inside the SIEM — correlating Windows Event IDs, parsing Syslog, building detection rules against log data generated on the host. That perspective is essential. But it has a fundamental blind spot: endpoint logs tell you what happened on a machine, not what happened between machines.

Think about lateral movement. An attacker compromises a workstation, dumps credentials, and uses PsExec to move to a domain controller. The source workstation logs a Type 3 (Network) logon event. The domain controller logs an incoming 4624. If you're watching both hosts, you can correlate the activity. But what if the attacker pivots to a Linux server that doesn't forward logs to your SIEM? Or routes through a network appliance that generates no endpoint telemetry at all?

This is where network detection changes the game. A sensor sitting on the wire sees every packet that crosses a network segment — regardless of whether the source or destination is enrolled in your EDR, forwarding logs, or even running an operating system you control.

Core principle: Endpoint detection sees what happens ON a host. Network detection sees what happens BETWEEN hosts. A mature SOC needs both perspectives — and the ability to pivot between them.

Module 3 shifts your viewpoint from the endpoint to the wire. You'll learn to read network traffic the way you learned to read Windows Event logs — not as raw data, but as evidence of attacker behavior.

What Is a NIDS?

A Network Intrusion Detection System (NIDS) is a sensor that monitors network traffic for malicious activity, policy violations, and protocol anomalies. Unlike host-based tools that run on individual endpoints, a NIDS watches the traffic flowing across a network segment.

NIDS detection works through two primary mechanisms:

Signature-based detection compares network traffic against a database of known attack patterns. When a packet (or sequence of packets) matches a rule, the NIDS generates an alert. This is fast, precise, and the primary detection mode you'll use in Module 3 labs.

Protocol anomaly detection identifies deviations from expected protocol behavior. A DNS response containing an executable payload, an HTTP request with a 50KB User-Agent header, or a TLS handshake with impossible cipher suites — these don't match a specific attack signature, but they violate what normal traffic looks like. Suricata's protocol parsers enable this kind of detection.

In CyberBlueSOC, Suricata is your NIDS. It's an open-source, high-performance engine capable of real-time intrusion detection, inline prevention (IPS mode), and network security monitoring. It processes traffic at multi-gigabit speeds using multi-threaded architecture.

NIDS vs HIDS vs EDR

To understand where NIDS fits, compare it against the other detection layers you've already studied:

Click to enlarge

Each layer catches things the others miss. A NIDS detects the C2 beacon that the EDR didn't flag because the endpoint used a legitimate process (living-off-the-land). The EDR catches the in-memory payload that the NIDS couldn't see because the traffic was encrypted. The HIDS catches the config file modification that neither the NIDS nor the EDR was looking for. This is why defense-in-depth works — and why you need to understand all three.

Sensor Placement — Where You Tap the Wire

A NIDS can only detect what it can see. Sensor placement determines your network visibility, and getting it wrong means entire attack paths go undetected. There are three primary deployment modes:

Network TAP (Test Access Point)

A TAP is a physical hardware device inserted into a network link. It creates an exact copy of all traffic passing through and forwards it to the sensor. The original traffic is unaffected — the TAP is completely passive.

TAPs are the gold standard for network monitoring. They introduce zero latency, drop zero packets (even under extreme load), and are invisible to attackers — there's no IP address to probe, no MAC to discover, no management interface to exploit.

SPAN / Mirror Port

A SPAN (Switched Port Analyzer) or mirror port is a switch configuration that copies traffic from one or more ports (or VLANs) to a designated monitoring port where the sensor is connected. It's configured entirely in software — no additional hardware required.

SPAN is the most common deployment in labs and smaller environments because it's free and easy to configure. The trade-off: under heavy load, the switch prioritizes production traffic and drops mirrored packets. You might miss 2-5% of traffic during peak periods — which could be exactly the packets containing the attack.

Inline / IPS Mode

In inline mode, the sensor sits directly in the traffic path — every packet must pass through it. This enables active prevention: the sensor can drop, reject, or modify malicious packets before they reach the target.

The upside is obvious — you can block attacks in real time. The downside is equally obvious — if the sensor fails, crashes, or misconfigures a rule, it disrupts production traffic. Inline sensors also add latency to every connection.

Placement Comparison

Click to enlarge

Strategic Placement

In a real enterprise, you don't place one sensor and call it done. Critical placement points include:

• Internet boundary (between firewall and internal network) — catches inbound attacks, C2 callbacks, exfiltration
• DMZ segments (web servers, email servers, DNS) — high-value targets, first to be probed
• Server VLAN boundaries — lateral movement between servers
• Between trust zones — connections between development, production, and management networks

Each placement point requires its own sensor (or a dedicated TAP feeding traffic to a central sensor farm). The more segments you monitor, the harder it is for an attacker to move undetected.

The Five-Tuple and Beyond

When a NIDS processes a packet, it extracts structured metadata at multiple layers. Understanding this metadata is critical because it's what you'll query, filter, and hunt through in EveBox.

The 5-Tuple

Every network connection is uniquely identified by five fields:

1. Source IP — Where the traffic originates
2. Source Port — The ephemeral port on the client
3. Destination IP — Where the traffic is headed
4. Destination Port — The service port (80, 443, 53, 445, etc.)
5. Protocol — TCP, UDP, or ICMP

The 5-tuple is always visible, even when traffic is encrypted. It's the foundation of every network investigation.

Protocol Metadata

Beyond the 5-tuple, Suricata's protocol parsers reassemble streams and extract application-layer metadata:

Flow Data

Suricata also tracks connection-level statistics:

• Connection duration — a 30-second DNS connection is normal; a 4-hour one screams tunneling
• Bytes transferred — 500 bytes to a C2 server every 60 seconds is a beacon; 500 MB outbound to a foreign IP is exfiltration
• Packet counts — useful for identifying scan patterns (thousands of SYN packets with no corresponding ACKs)

Defense in Depth — NIDS + SIEM + EDR

No single detection layer catches everything. Defense-in-depth means deploying overlapping layers so that what one misses, another catches. Here's how NIDS complements the tools you've already learned:

What SIEM Sees (But NIDS Adds)

Your SIEM (Wazuh in CyberBlueSOC) correlates log events from endpoints, servers, and applications. It's excellent at detecting authentication anomalies, policy violations, and configuration changes. But the SIEM only sees what's written to a log. If an attacker communicates over a protocol that doesn't generate log entries — or targets a device that doesn't forward logs — the SIEM is blind.

NIDS fills this gap by monitoring the network layer directly. DNS tunneling, C2 beaconing over HTTPS, and SMB lateral movement all generate network traffic that NIDS detects — even if the endpoints involved never write a log entry about it.

What EDR Sees (But NIDS Adds)

Your EDR (Velociraptor in CyberBlueSOC) provides deep visibility into endpoint behavior — process execution, memory operations, file system changes. But EDR only covers managed endpoints. Unmanaged devices (IoT sensors, legacy systems, contractor laptops, network printers) are invisible to EDR.

NIDS sees traffic from every device on the monitored segment, managed or not. When that unpatched network printer starts beaconing to a C2 server, the EDR won't notice — but the NIDS will.

The Overlap Is the Point

Click to enlarge

How Suricata Processes Traffic

Now that you understand what NIDS sees and where sensors sit, let's look at how Suricata — the specific engine you'll use in every Module 3 lab — turns raw packets into actionable intelligence.

Multi-Threaded Packet Processing

Suricata's architecture is built for speed. Unlike single-threaded engines that process one packet at a time, Suricata distributes packets across multiple CPU cores simultaneously. Each thread handles packet decoding, stream reassembly, and rule matching in parallel. This design lets Suricata handle multi-gigabit traffic on modern hardware without dropping packets.

Rule Matching

Suricata evaluates every packet (and reassembled stream) against its loaded ruleset. A rule specifies:

• Header conditions: protocol, source/destination IP, ports, direction
• Content matches: byte patterns, strings, or regular expressions in the payload
• Flow conditions: established connections, direction (to_server / to_client)
• Metadata matches: HTTP URI, DNS query, TLS SNI, file hash

When a packet matches a rule, Suricata generates an alert with the rule's signature ID (SID), message, severity, and classification. You'll write and customize these rules in Lesson 3.2.

Protocol Parsers

Raw packets are useful, but reassembled streams are where the real detection happens. Suricata includes protocol parsers for HTTP, DNS, TLS, SMB, FTP, SSH, SMTP, and more. These parsers:

• Reassemble TCP streams into complete application-layer transactions
• Extract protocol-specific fields (HTTP headers, DNS queries, TLS certificates)
• Enable keyword matching against structured data (e.g., match on http.uri instead of searching the raw payload)

The EVE Log — eve.json

Everything Suricata detects is written to the EVE log (eve.json) — a single JSON log file with one event per line. EVE stands for "Extensible Event Format," and it's the primary output you'll analyze.

EVE event types include:

alert    — Rule triggered, possible threat detected
http     — HTTP transaction logged (request + response)
dns      — DNS query and response captured
tls      — TLS handshake details (SNI, JA3, cert info)
flow     — Connection summary (duration, bytes, packets)
fileinfo — File extracted from network stream (hash, size, type)

Each EVE line is a self-contained JSON object with the 5-tuple, timestamp, event type, and type-specific fields. This structured format is what makes programmatic analysis, SIEM integration, and EveBox visualization possible.

EveBox — The Analyst Interface

Raw eve.json is machine-friendly but not analyst-friendly. EveBox reads the EVE log and provides a web-based interface for browsing, filtering, and investigating alerts. It groups related alerts, provides packet-level detail, and lets you escalate or archive events during triage.

In Module 3 labs, Suricata processes PCAPs at startup and writes events to eve.json. EveBox reads from the same file and presents the alert queue you'll work through.

What's Next

You now understand what a NIDS sees, where sensors are placed, what metadata gets extracted, and how Suricata turns raw packets into structured events. In Lesson 3.2 — Suricata Rules and EveBox, you'll learn how Suricata rules are structured, how to read and write custom detection signatures, and how to use EveBox to manage the alert queue. That lesson sets the foundation for Lab 3.1, where you'll triage the "Operation Wire Tap" alerts hands-on.