How to Monitor Network Traffic Using Open Source Tools
A practical, hands-on guide to deploying Suricata, tshark, Wireshark, and Zeek for full network visibility — without spending a dollar on licensing.
“You cannot defend what you cannot see. Network visibility is not a luxury — it is the foundation of every security program, and in 2026 the best tools for achieving it are completely free.”
Most small businesses and home lab operators assume enterprise-grade network monitoring requires expensive commercial tools. They are wrong. The open source security community has built a suite of tools that rival — and in many cases surpass — their commercial counterparts. Suricata, Wireshark, tshark, Zeek, and ntopng are deployed in Fortune 500 security operations centers worldwide. They are also free.
This guide walks you through setting up a complete network monitoring stack from scratch — capturing packets, detecting intrusions, analyzing flows, and generating structured telemetry for anomaly detection.
Why Open Source Network Monitoring?
Commercial network monitoring solutions often cost tens of thousands of dollars annually in licensing. For small businesses and security researchers this is simply not viable. Open source alternatives offer the same capabilities — sometimes better — with the added benefit of transparency. You can read the source code, verify exactly what the tool does, and customize it for your specific environment.
| Capability | Commercial SIEM | Open Source Stack |
|---|---|---|
| Packet capture | ✓ Yes | ✓ tshark / tcpdump |
| Intrusion detection | ✓ Yes | ✓ Suricata |
| Flow analysis | ✓ Yes | ✓ Zeek / ntopng |
| DNS monitoring | ✓ Yes | ✓ Suricata eve.json |
| TLS inspection | ✓ Yes | ✓ Suricata + Zeek |
| Anomaly detection | ✓ Yes | ✓ Custom ML pipeline |
| Annual cost | $15,000 – $100,000+ | ✓ $0 |
| Source transparency | ✗ Closed | ✓ Fully open |
Suricata is used by cloud providers, ISPs, and government agencies to monitor billions of flows daily. The same engine running in your home lab is the same engine protecting critical infrastructure worldwide.
The Open Source Monitoring Stack
A complete network monitoring capability is built from complementary tools — each handling a specific layer of visibility. No single tool does everything. The power comes from combining them.
The gold standard open source IDS/IPS. Suricata delivers protocol-aware deep packet inspection, application-layer protocol detection, and rule-based alerting, with rich structured telemetry (eve.json) for advanced analytics.While highly scalable (multi-Gbps to 100Gbps on optimized hardware), its real strength lies in providing high-fidelity network signals for downstream anomaly detection and behavioral analysis.
IDS / IPS
Command-line Wireshark. Protocol-aware packet capture with powerful display filters, field extraction, and file rotation. Supports WPA2 decryption and monitor mode.
Sniffer
The world’s most widely used network protocol analyzer. GUI-based deep packet inspection with color coding, follow stream, expert analysis, and statistics.
Analyzer
Network security monitor focused on behavior analysis. Generates detailed logs for every connection, DNS query, HTTP request, TLS handshake, and file transfer.
Behavior
Web-based network traffic monitoring. Real-time flow visualization, top talkers, geolocation, historical data, and alerting. Community edition is free and full-featured.
Monitor
The original packet capture tool. Lightweight, available on virtually every Unix system, and scriptable. Essential for quick diagnostics and automated capture pipelines.
Sniffer
Suricata — Intrusion Detection Engine
Suricata is the centerpiece of any open source network monitoring stack. It performs deep packet inspection at wire speed, matches traffic against tens of thousands of threat signatures, and outputs structured JSON telemetry for every event it observes — alerts, flows, DNS queries, TLS handshakes, HTTP requests and more.
Installation
sudo apt install suricata suricata-update
# Update threat intelligence rules
sudo suricata-update
# Verify installation
suricata –build-info | grep “Suricata version”
# Check available interfaces
ip -br link show
Core Configuration — suricata.yaml
vars:
address-groups:
HOME_NET: “[192.168.0.0/24]”
EXTERNAL_NET: “!$HOME_NET”
# High performance capture
af-packet:
– interface: wlan0
cluster-id: 99
cluster-type: cluster_flow
defrag: yes
use-mmap: yes
# eve.json output — enable all event types
outputs:
– eve-log:
enabled: yes
filename: eve.json
types:
– alert
– flow
– dns
– tls:
extended: yes # capture SNI hostnames
– http
– stats
Starting Suricata
sudo suricata -c /etc/suricata/suricata.yaml -i wlan0 -D
# Watch alerts in real time
sudo tail -f /var/log/suricata/eve.json | jq -c ‘select(.event_type==”alert”)’
# Watch all events with source/dest and SNI
sudo tail -f /var/log/suricata/eve.json | jq -c ‘{type:.event_type,src:.src_ip,dst:.dest_ip,sni:.tls.sni}’
Suricata must be placed at a network choke point to see all traffic. Running it on a regular workstation interface only captures that machine’s own traffic. For full network visibility configure your host as a gateway or use a SPAN port.
tshark & Wireshark — Packet Capture
Where Suricata gives you structured alerts and telemetry, tshark gives you raw packet capture with protocol-aware filtering. The two tools complement each other — Suricata for continuous monitoring and alerting, tshark for targeted investigation and capture.
Essential tshark Commands
tshark -i wlan0 \
-w “./captures/raw_$(date +%Y%m%d_%H%M%S).pcap” \
-b duration:120 \
-a files:10
# Extract DNS queries from capture file
tshark -r capture.pcap \
-T fields -e frame.time -e ip.src -e dns.qry.name \
-Y “dns.flags.response == 0”
# Extract TLS SNI hostnames
tshark -r capture.pcap \
-T fields -e ip.src -e tls.handshake.extensions_server_name \
-Y “tls.handshake.type == 1”
# Count packets per IP pair
tshark -r capture.pcap -q -z conv,ip
# Filter specific host traffic
tshark -i wlan0 -f “host 192.168.0.36” -w iphone_traffic.pcap
Wireshark — Display Filter Reference
ip.addr == 192.168.0.50
# Show only DNS / HTTPS
dns
tls and tcp.port == 443
# Find specific domain in TLS SNI
tls.handshake.extensions_server_name contains “google”
# Show TCP retransmissions (network issues)
tcp.analysis.retransmission
# Find large data transfers (potential exfiltration)
tcp.len > 10000
# Show HTTP POST requests / ICMP ping scans
http.request.method == “POST”
icmp
Zeek — Network Behavior Analysis
Zeek (formerly Bro) takes a different approach to network monitoring. Rather than matching signatures, Zeek generates detailed structured logs for every network event it observes — every connection, every DNS query, every file transfer, every certificate. It is the analyst’s tool for understanding what happened on a network after the fact.
Installation & Setup
sudo apt install zeek
# Configure interface in node.cfg
sudo nano /etc/zeek/node.cfg
[zeek]
type=standalone
host=localhost
interface=wlan0
# Deploy and start
sudo zeekctl deploy
sudo zeekctl start
sudo zeekctl status
Zeek Log Files — What Each Contains
dns.log # Every DNS query and response
http.log # Every HTTP request — method, host, URI, response code
ssl.log # Every TLS handshake — SNI, certificate, version
files.log # Every file transferred — hash, mime type, size
notice.log # Zeek’s own alerts and notices
weird.log # Unusual protocol behavior — highest value for anomaly detection
x509.log # SSL certificate details
Zeek’s weird.log is one of the most valuable files for anomaly detection. It captures protocol violations and unexpected behaviors that don’t match known signatures but indicate something unusual — often the earliest signal of an intrusion or malware activity.
Putting It All Together
Each tool covers a different layer of visibility. The complete stack combines them into an overlapping, redundant monitoring capability where each tool catches what the others might miss.
│ YOUR NETWORK │
│ iPhone MacBook Smart TV Laptop IoT Devices │
└──────────────────────┬──────────────────────────────────┘
│ all traffic
▼
┌──────────────────────────────────────────────────────────┐
│ MONITORING HOST (antiX / Linux) │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │ Suricata │ │ tshark │ │ Zeek │ │
│ │ IDS alerts │ │ raw capture │ │ behavior logs │ │
│ │ eve.json │ │ pcap files │ │ conn/dns/ssl │ │
│ └──────┬──────┘ └──────┬──────┘ └────────┬────────┘ │
│ │ │ │ │
│ └────────────────┴──────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ Anomaly Detection │ │
│ │ Scoring Pipeline │ │
│ │ (orcasecure-radar) │ │
│ └───────────────────────┘ │
└──────────────────────────────────────────────────────────┘
Reading & Analyzing eve.json
Suricata’s eve.json is the richest single source of network telemetry in the open source stack. Every event — alert, flow, DNS query, TLS handshake, HTTP request — is logged as a structured JSON object. Learning to query it effectively is the core skill of open source network monitoring.
Essential jq Queries
sudo cat eve.json | jq -c ‘
select(.event_type == “alert”) | {
time: .timestamp,
src: .src_ip,
dst: .dest_ip,
signature: .alert.signature,
severity: .alert.severity,
category: .alert.category
}’
# DNS queries — what domains is each device querying?
sudo cat eve.json | jq -r ‘
select(.event_type == “dns” and .dns.type == “query”) |
[.src_ip, .dns.rrname] | @tsv’ | sort | uniq -c | sort -rn | head -20
# TLS SNI — what HTTPS sites are being visited?
sudo cat eve.json | jq -r ‘
select(.event_type == “tls” and .tls.sni != null) |
[.src_ip, .tls.sni] | @tsv’ | sort | uniq -c | sort -rn
# Live stream — all events for specific device
sudo tail -f eve.json | jq -c ‘
select(.src_ip == “192.168.0.36” or .dest_ip == “192.168.0.36”) |
{type:.event_type, src:.src_ip, dst:.dest_ip, sni:.tls.sni, dns:.dns.rrname}’
Anomaly Detection with the Data
Raw network monitoring tells you what is happening. Anomaly detection tells you what is unusual. By applying statistical methods to eve.json telemetry you can build automated detection that identifies threats signatures cannot catch — zero-days, insider threats, and subtle data exfiltration.
Key Signals to Measure
-
DNS Query Entropy
High Shannon entropy in DNS subdomains indicates DNS tunneling — a technique attackers use to exfiltrate data or receive C2 commands through DNS queries. Normal hostnames have low entropy. Base64-encoded data in DNS has very high entropy.
-
Beaconing Detection
Malware communicates with command-and-control servers at regular intervals. Measure the periodicity of connections to external IPs. Highly regular connection intervals (every 60 or 300 seconds) are a strong malware indicator.
-
Bytes Per Flow Baseline
Establish baseline byte volumes per device per hour. Statistical outliers — sudden 10x increases in outbound data — indicate potential data exfiltration. Laplace smoothing prevents zero probabilities from skewing the baseline on new devices.
-
Rare Domain Detection
New domains visited for the first time by a device — especially at unusual hours — warrant investigation. Build a per-device domain whitelist from historical eve.json data. First-time visits to newly registered domains are a high-value signal.
-
Port & Protocol Anomalies
Connections on unusual ports — especially outbound on ports like 4444, 1337, 8888 — or unexpected protocols (IRC, Tor) are strong indicators of compromise. Monitor destination port distribution and alert on statistical outliers.
Any device making DNS queries with subdomain strings longer than 50 characters, any outbound connection to a Tor exit node, any internal device scanning multiple internal IPs on the same port within 60 seconds, or any device sending more than 100MB outbound in a single flow outside business hours should be treated as a high priority incident until proven otherwise.
Deployment Checklist
Use this checklist to confirm your open source network monitoring stack is correctly deployed and operational.
Suricata installed and running on gateway/choke point interface
suricata-update configured and scheduled daily via cron
eve.json logging enabled with alert, flow, dns, tls, http, stats types
TLS extended logging enabled — SNI hostnames captured in eve.json
tshark installed and tested for packet capture on target interface
Rotating capture files configured — bounded file size, bounded file count
jq installed — eve.json queries tested and working
HOME_NET correctly set to your actual network range in suricata.yaml
Suricata auto-start on boot configured via supervisor or rc.local
Log rotation configured — eve.json does not grow unbounded
Baseline established — normal traffic patterns documented for anomaly comparison
Alert review process defined — who checks alerts and at what frequency