Open-Source NSM Stack: Suricata, Zeek & rsyslog

While endpoint telemetry is critical, the network remains the ultimate source of truth. Attackers can tamper with endpoint logs, hide processes, and disable AV/EDR agents - but they cannot hide their packets as they traverse the wire. Building a best-of-breed open-source Network Security Monitoring (NSM) stack eliminates blind spots and provides the deep forensic data necessary for modern threat hunting.

This architecture brings together three foundational, industry-standard open-source tools: Suricata (signature-based IDS/IPS), Zeek (protocol analyzer and metadata generation), and rsyslog (high-performance log collection and routing). Together, they deliver the capabilities of commercial Network Detection and Response (NDR) platforms that often cost hundreds of thousands of dollars annually.

---

Component Architecture Overview

A robust NSM stack separates threat detection (Suricata), protocol analysis (Zeek), and log delivery (rsyslog) to maximize performance and flexibility.

Component	Primary Function	Why It’s Essential
Suricata	Intrusion Detection/Prevention (IDS/IPS)	Inspects network traffic against known malicious signatures (e.g., Emerging Threats) to identify exploits, malware C2, and lateral movement in real-time.
Zeek	Network Protocol Analysis & Metadata	Transforms raw network traffic into structured, queryable logs (HTTP, DNS, TLS, SMB, etc.) regardless of port, providing the context needed for threat hunting and incident response.
rsyslog	High-Speed Log Routing	Acts as the central nervous system, efficiently collecting JSON logs from Suricata and Zeek, filtering, buffering, and securely transmitting them to the central SIEM, Data Lake, or storage backend.

---

Component 1: Suricata (The Detection Engine)

Suricata is a high-performance, open-source Network IDS, IPS, and Network Security Monitoring engine. It is highly scalable, supporting multi-threading to leverage multi-core CPUs for gigabit and 10-gigabit traffic analysis.

Core Capabilities:

• Signature Matching: Uses standard rule formats (compatible with Snort) to flag malicious patterns.
• Protocol Identification: App-layer protocol inspection regardless of the port being used.
• File Extraction: Can extract files traversing the network (e.g., over HTTP, SMB) for malware analysis.
• EVE JSON Output: Generates extensive, parseable JSON logs of alerts, anomalies, and metadata.

Configuration Example - Tuning suricata.yaml

To optimize Suricata for high-speed traffic, tuning the capture method (like AF_PACKET) and multi-threading allocation is critical:

# suricata.yaml
af-packet:
  - interface: eth1
    threads: auto           # Automatically scale based on CPU cores
    cluster-id: 99
    cluster-type: cluster_flow # Balance traffic by flow
    defrag: yes
    use-mmap: yes
    tpacket-v3: yes

# EVE JSON output configuration
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: eve.json
      types:
        - alert:
            payload: yes             # Include packet payload in alert
            payload-printable: yes
        - http:
            extended: yes
        - dns:
            query: yes
            reply: yes
        - tls:
            extended: yes
        - files:
            force-magic: yes

Suricata rules management is typically automated using suricata-update, pulling the latest Emerging Threats (ET) Open or PRO rulesets daily.

---

Component 2: Zeek (The Protocol Analyst)

Formerly known as Bro, Zeek is not a traditional signature-based IDS. Instead, it is a powerful network analysis framework that decodes over 40 distinct network protocols and generates dense, richly linked transactional logs. If Suricata tells you when a known bad event happened, Zeek tells you everything else that was happening around it.

The Value of Zeek Logs:

• DNS Logging: Who queried what domain? (Crucial for DGA and C2 tracking).
• HTTP/HTTPS Logging: Headers, user agents, URIs, and JA3/JA3S TLS fingerprinting.
• SMB/DCE-RPC: Deep visibility into Windows internal traffic for lateral movement detection.
• Connections (conn.log): Every single TCP/UDP/ICMP connection, its state, duration, and byte count.

Zeek Configuration Example

Zeek is customized through scripts. A standard production deployment enables JSON output and loads policy scripts to extract specific file hashes and TLS fingerprints.

# local.zeek

# Enable JA3 TLS fingerprinting for clustering malicious clients
@load policy/protocols/ssl/ja3

# Enable file extraction and hashing
@load frameworks/files/hash-all-files
redef FileExtract::prefix = "/data/zeek/extract_files/";

# Output logs in JSON format for easy ingestion by rsyslog/SIEM
redef LogAscii::use_json = T;

# Track MAC addresses in connection logs for physical tracking
redef record Conn::Info += {
    orig_l2_addr: string &optional &log;
    resp_l2_addr: string &optional &log;
};

---

Component 3: rsyslog (The Log Pipeline)

With Suricata and Zeek generating gigabytes of JSON logs daily, a robust pipeline is required to move this data off the sensor and into your central indexer (like Wazuh, Splunk, or Elasticsearch). rsyslog is the lightweight, incredibly fast, and reliable daemon for this job.

Why rsyslog instead of Logstash/Filebeat directly on the sensor?

• Performance: rsyslog consumes a fraction of the CPU and RAM compared to JVM-based shippers.
• Reliability: Built-in disk-assisted memory queues ensure zero log loss even if the central SIEM is temporarily down or network connectivity drops.

Architecture Routing Example

Below is a configuration to read Suricata eve.json and Zeek JSON logs, queue them locally in case of disconnect, and explicitly forward them over Religious TLS to a central collection point.

# /etc/rsyslog.d/90-nsm-forwarder.conf

# Load modules for file reading and TLS
module(load="imfile" PollingInterval="1")
module(load="omfwd")

# Input: Suricata EVE Logs
input(type="imfile"
      File="/var/log/suricata/eve.json"
      Tag="suricata"
      Ruleset="NSM_Ruleset")

# Input: Zeek Logs (Wildcard pattern)
input(type="imfile"
      File="/opt/zeek/logs/current/*.log"
      Tag="zeek"
      Ruleset="NSM_Ruleset")

# Processing Ruleset with Disk-Assisted Queuing
ruleset(name="NSM_Ruleset") {
    # Send all tagged NSM logs to the central SIEM over TLS
    action(type="omfwd"
        Target="siem.internal.corp"
        Port="6514"
        Protocol="tcp"
        StreamDriver="gtls"
        StreamDriverMode="1"
        StreamDriverAuthMode="x509/name"
        StreamDriverPermittedPeers="siem.internal.corp"
        
        # Disk-assisted queue configuration
        queue.filename="nsm_fwd_queue"
        queue.maxdiskspace="50g"     # Keep up to 50GB on disk if SIEM is down
        queue.saveonshutdown="on"
        queue.type="LinkedList"
        resumeRetryCount="-1"        # Infinite retries
    )
}

---

Multi-Sensor Deployment Architecture

For a large enterprise with multiple egress points, interior data center switching, and cloud environments, you need a distributed sensor model.

[Internet]
   │
   ▼
[External Router / Firewall]
   │
   ├──▶ (SPAN/TAP) ───┐
   │                  │
[Core Switch]         │  [NSM Sensor 1 Node (Physical/VM)]
   │                  ├──▶ Suricata (AF_PACKET Interface)
   ├──▶ (SPAN/TAP) ───┼──▶ Zeek (AF_PACKET Interface)
   │                  └──▶ rsyslog (Reading JSON)
[Internal Subnets]                  │
                                    │ TLS / TCP 6514
                                    ▼
                          [Central Log Aggregation]
                          (Logstash / Kafka / Wazuh)
                                    │
                                    ▼
                         [SIEM / OpenSearch / Splunk]

Critical Sizing Considerations (Per Sensor)

To capture 1 to 10 Gbps of traffic without packet loss, the physical or virtual appliance must be aggressively tuned:

• NIC: Intel x520/x710 cards are highly recommended for optimal driver support and hardware offloading capabilities (RSS, GRO/LRO disabled).
• RAM: Zeek uses significant memory to maintain connection states. Plan for at least 32GB to 64GB RAM per Gbps of sustained traffic.
• CPU: Suricata and Zeek both scale horizontally. A 16 to 32-core CPU allows sufficient worker threads to split the packet load.

---

Tactical Use Cases: Finding the Adversary

Deploying the stack is only half the battle. Here is how SOC analysts use the resulting data combining Suricata alerts with Zeek metadata:

1. Detecting Cobalt Strike C2 (JA3/JA3S Fingerprinting)

Attackers often use custom TLS profiles in their C2 frameworks like Cobalt Strike.

• Zeek: Generates ssl.log containing JA3 (client) and JA3S (server) hashes.
• Suricata: Triggers an alert when a known Cobalt Strike JA3 hash is observed.
• Analyst Action: Use the SIEM to pivot from the Suricata alert to the Zeek conn.log to determine how much data was exfiltrated during the connection.

2. Hunting for Rogue DNS / DGA Activity

Algorithmically generated domains (DGA) bypass standard blacklist blocking.

• Zeek: Provides dns.log showing all A, AAAA, and TXT queries. Analyst scripts or SIEM ML models detect anomalies like high entropy or rapid sequential querying of failed NXDOMAINs.
• rsyslog: Ensures these logs reliably hit the SIEM, where threshold alerts notify the SOC of compromised internal endpoints beaconing out.

3. Cleartext Lateral Movement & Credential Dumping

If an attacker begins enumerating shares or executing PsExec over the network:

• Zeek: Generates dce_rpc.log and smb_mapping.log. Shows precisely which pipes were accessed (e.g., \PIPE\lsarpc) and which user context was utilized.
• Suricata: Alerts on known attack patterns like “ET EXPLOIT Possible Zerologon.”

---

Integration with SIEM / SOAR

This NSM stack is the perfect complement to open-source SIEM platforms like Wazuh. While Wazuh handles endpoint agents and FIM, Suricata and Zeek cover the unmanaged devices, IoT infrastructure, and lateral movement layers.

1. Wazuh Integration: Wazuh natively supports parsing Suricata eve.json out-of-the-box. Alerts are mapped to MITRE ATT&CK automatically by the Wazuh dashboard.
2. Cortex / TheHive: When a critical Suricata alert hits TheHive, analyzers can automatically query Zeek historical data in OpenSearch to attach a PCAP or connection history to the incident case automatically.

Conclusion

The Suricata, Zeek, and rsyslog stack represents the gold standard for open-source network security monitoring. It demands more engineering effort than plug-and-play commercial NDR solutions—requiring careful OS tuning, traffic mirroring configuration, and ruleset management. However, the exactness, raw parsing power, and unparalleled visibility it provides make it a cornerstone technology for mature security operations centers looking to build vendor-agnostic, scalable, and highly capable defensive infrastructure.