Setting Up Security Onion — What I Learned

Security Onion looks straightforward until you actually try to deploy it. This post covers what I learned deploying it as part of my MSc Cybersecurity programme at Robert Gordon University — specifically for a ransomware intrusion investigation project.

What Security Onion Actually Is

Most resources describe Security Onion as "a Linux distro for threat hunting and network security monitoring." That's accurate but undersells the complexity. What you're actually getting is an integrated stack of:

• Zeek (formerly Bro) — network traffic analysis and protocol logging
• Suricata — signature-based IDS with rule alerting
• Kibana — search and visualisation across all log sources
• Elasticsearch — the indexing backend
• SOC dashboards — pre-built alert triage views

Getting all of these to work together correctly takes configuration time. The out-of-box experience is better than it used to be, but you will still spend hours on network interface configuration and sensor tuning before you see useful alerts.

The Deployment Challenge

The biggest challenge I ran into was network interface configuration. Security Onion needs at least two interfaces: a management interface (for SSH and the web UI) and a monitoring interface (for traffic capture). The monitoring interface must be in promiscuous mode — it captures traffic without having an IP address assigned.

Getting this right in a virtualised environment required:

1. Configuring the VM hypervisor to allow promiscuous mode on the monitoring adapter
2. Running the Security Onion setup wizard carefully — it's easy to assign the wrong interface to the wrong role
3. Verifying traffic was actually being captured (tcpdump on the monitoring interface before starting the Security Onion services)

If you skip step 3, you'll have a running stack that sees no traffic and wonder why Zeek and Suricata aren't generating logs.

What the Alerts Actually Look Like

Once traffic was flowing, the alert volume was immediately challenging. Even in a lab environment with a relatively small network capture, Suricata generated hundreds of alerts. The discipline of SOC work became obvious: alert triage is not about reading every alert — it is about developing a mental model of what is normal traffic in the environment, then identifying deviations.

For the ransomware investigation, this meant:

• Filtering out known-good traffic patterns first
• Focusing on alerts with high severity and unusual destination IPs
• Cross-referencing Suricata alerts with Zeek connection logs to get the full traffic context

The pivot from an alert to the underlying Zeek connection logs is where the investigative work actually happens. Suricata tells you something was flagged; Zeek tells you what the full conversation looked like.

What I Would Tell Anyone Setting It Up

1. Spend time on the network interface setup — this is where most failed deployments fail
2. Start with a small, controlled capture before throwing a large PCAP at it
3. Learn the Kibana query syntax — hunting without queries is just scrolling
4. Zeek logs are your friend — conn.log, dns.log, http.log and ssl.log are the four you'll live in
5. Context beats alerts — a single Suricata alert means little; the Zeek conversation it sits inside means a lot

The Investigation Result

Using this setup, I traced a simulated ransomware infection back to its source: a spear-phishing email delivering a macro-enabled Office document. The infection chain was visible in the Zeek HTTP logs — the initial callback to a C2 server, followed by the lateral movement traffic between hosts.

That's what Security Onion is for. Not as a dashboard to watch, but as a forensic record to investigate.