Skip to content
Open-Source Network Security Monitoring Stack
Network Detection & Monitoring

Open-Source NSM Stack: Suricata, Zeek & rsyslog

A comprehensive guide to architecting a production-grade Network Security Monitoring (NSM) stack using Suricata, Zeek, and rsyslog. This setup provides deep packet inspection, signature-based IDS/IPS, protocol metadata extraction, and reliable log routing. Essential for SOCs requiring total network visibility and wire-speed threat detection without commercial licensing constraints.

Pros

  • Unparalleled network visibility with Zeek's protocol analysis and metadata extraction
  • High-performance signature-based intrusion detection and prevention with Suricata
  • Reliable, high-throughput centralized log routing and normalization with rsyslog
  • Zero licensing costs - full enterprise scale capabilities without vendor lock-in
  • Standardized data formats (JSON) ready for ingestion by any SIEM or data lake
  • Highly active open-source communities with thousands of contributors and custom rulesets
  • Platform agnostic - deployable on bare metal, VMs, containers, and cloud environments

Cons

  • Complex initial sensor deployment and traffic mirroring (SPAN/TAP) required
  • High resource consumption at multi-gigabit speeds; requires careful tuning and NIC offloading
  • Requires integration with a centralized SIEM/Dashboard (e.g., ELK, Splunk) for visualization
  • Managing and tuning Suricata rulesets (like Emerging Threats) demands dedicated analyst time
  • Zeek scripting has a steep learning curve for custom protocol parsing and detections

Endpoint agents can be disabled. Logs can be tampered with. But attackers can’t hide packets moving through the network. That’s where the real truth lives.

Building an open-source Network Security Monitoring (NSM) stack gives you visibility across your entire wire—not just at individual endpoints. You see what commercial NDR platforms see, without the six-figure licensing costs.

We’re combining three industry-standard tools: Suricata for signature-based threat detection, Zeek for deep protocol analysis and metadata extraction, and rsyslog for reliable log shipping at scale. Together, they create the foundation for modern threat hunting and incident response.


Component Architecture Overview

The power comes from separation. Each tool does one thing exceptionally well.

Suricata watches for known threats—malicious signatures in real-time. Zeek decodes the protocols, giving you the context and metadata. rsyslog moves the data reliably to your central analysis point. This modular design gives you flexibility and performance.

  • Suricata detects the attack. Uses signature rulesets (Emerging Threats) to identify exploits, C2 callbacks, and lateral movement patterns as packets cross the wire.
  • Zeek understands the context. Extracts protocol metadata (HTTP headers, DNS queries, TLS fingerprints, SMB activity) from every connection, regardless of which port it’s running on.
  • rsyslog delivers the data. Collects JSON logs from both, buffers them reliably, and ships everything to your SIEM or data lake without losing a single event—even if the backend goes down temporarily.

Component 1: Suricata (The Detection Engine)

Suricata is where the rubber meets the road. It’s a high-performance IDS/IPS engine that watches every packet, compares it against known malicious signatures, and alerts you in real-time. It scales across multi-core CPUs to handle gigabit traffic without breaking a sweat.

What it does:

  • Signature Detection: Compares traffic against rule libraries (Emerging Threats, etc.) to catch known exploits, malware callbacks, and attack patterns.
  • Protocol Inspection: Understands HTTP, DNS, TLS, and other protocols regardless of which port they’re using—attackers can’t hide in odd ports.
  • File Extraction: Can automatically pull files out of network traffic for offline analysis.
  • Structured Alerts: Outputs everything as clean JSON, making it easy for downstream systems to parse and act on.
Advertisement

Tuning Suricata for Performance

Out of the box, Suricata won’t squeeze every bit of performance from your hardware. You need to tune it. Here’s what matters:

# 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

Rules update automatically using suricata-update. Pull fresh Emerging Threats rules daily to catch new attack signatures.


Component 2: Zeek (The Protocol Analyst)

Suricata tells you when something bad happens. Zeek tells you everything about it.

Zeek isn’t a signature-based IDS. It’s a protocol analyzer that decodes over 40 different network protocols and extracts structured metadata from everything. When Suricata raises an alert, Zeek has already captured the full context—what was queried, what was exfiltrated, who connected to what.

What Zeek tracks:

  • DNS queries and responses — who’s asking for what domains (critical for catching command-and-control callbacks and DGA malware).
  • HTTP traffic — full headers, user agents, URIs, response codes. Also TLS fingerprinting (JA3/JA3S) for clustering malicious clients.
  • Windows network protocols — SMB shares, RPC calls, showing exactly which pipes were accessed and which user context was used.
  • All connections — every TCP, UDP, and ICMP session with full state tracking, duration, and bytes transferred.

Setting Up Zeek

Zeek runs on scripts. A production setup needs JSON output, file hashing, and TLS fingerprinting enabled.

# 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)

Suricata and Zeek generate terabytes of data. You need a way to move it all reliably to a central point without losing a single event. That’s rsyslog.

Why not use Logstash or Filebeat directly on the sensor? They’re JVM-based hogs that burn CPU. rsyslog is lightweight, incredibly fast, and bulletproof. It buffers logs to disk if your SIEM goes down, so you never lose data. When the backend comes back up, rsyslog catches up automatically.

Configuring rsyslog

You need to tell rsyslog where to find the logs (Suricata and Zeek JSON files), buffer them locally if needed, and ship them securely to your central SIEM.

# /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="*.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

Single sensor won’t scale. You need visibility everywhere—external firewalls, internal data center switches, cloud segments. Deploy sensors at each choke point and aggregate everything centrally.

[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]

Sizing Your Sensors

Capturing traffic at scale demands hardware. Here’s what you need:

  • Network Cards: Intel x520/x710 NICs. Good driver support, hardware offloading, reliable at gigabit speeds.
  • Memory: 32GB to 64GB per Gbps. Zeek maintains connection state in memory—it adds up fast.
  • CPU: 16-32 cores minimum. Both Suricata and Zeek scale horizontally across cores.

Tactical Use Cases: Finding the Adversary

Deploying the stack is one thing. Using it is another. Here’s how a SOC analyst actually finds attackers:

Detecting Cobalt Strike C2 with TLS Fingerprinting

Cobalt Strike and other C2 frameworks use distinctive TLS handshakes. Attackers can’t hide them.

Zeek captures JA3 hashes of every TLS connection. Suricata alerts when a known malicious JA3 hash appears. The analyst pivots from the Suricata alert to Zeek’s connection logs to see how much data exfiltrated and where it went.

Hunting for DGA and C2 Callbacks

Malware generates domains algorithmically (DGA) to bypass static blacklists. You catch it by looking at query patterns.

Zeek logs every DNS query. Analysts and SIEM ML models spot anomalies—high-entropy domain names, rapid sequences of failed NXDOMAINs, queries from unexpected internal endpoints. rsyslog ensures all these logs reliably hit your SIEM so alerts fire before the attacker knows they’re caught.

Detecting Lateral Movement and Credential Access

When an attacker starts moving through your network—enumerating shares, running PsExec, dumping credentials—it leaves traces.

Zeek captures every SMB interaction, showing exactly which pipes were accessed (\PIPE\lsarpc for credential theft, for example) and which user account was used. Suricata alerts on known patterns. Together they give you the full story.


Integration with SIEM / SOAR

Your NSM stack works best with a central SIEM. Wazuh is a great open-source option that pairs perfectly with Suricata and Zeek.

Wazuh handles endpoint telemetry and file integrity monitoring. Your NSM stack sees the network layer—unmanaged devices, IoT, lateral movement. Together they give you complete coverage.

Wazuh parses Suricata alerts natively. Alerts automatically map to MITRE ATT&CK techniques. When an alert fires, analysts can jump into Zeek logs and OpenSearch to pull connection history and PCAP context for incident cases.

Conclusion

This stack is the gold standard for open-source NSM. Yes, it requires work. You’ll tune the OS, configure traffic mirroring, manage rulesets. But what you get in return is unmatched visibility and control—the same capabilities as expensive commercial NDR platforms, without vendor lock-in or six-figure price tags.

This is the foundation for a mature SOC. Build it once, and you’ll have the visibility to hunt threats and respond to incidents at speed.


Share article

Subscribe to my newsletter

Receive my case study and the latest articles on my WhatsApp Channel.

Warning