Security Onion is a Linux distro for intrusion detection, network security monitoring, and log management. It’s based on Ubuntu and contains Snort, Suricata, Bro, OSSEC, Sguil, Squert, ELSA, Xplico, NetworkMiner, and many other security tools. The easy-to-use Setup wizard allows you to build an army of distributed sensors for your enterprise in minutes.

It is not a silver bullet that you can setup, walk away from and feel safe. Nothing is and if that’s what you’re looking for you’ll never find it. Security Onion will provide visibility into your network traffic and context around alerts and anomalous events, but it requires a commitment from you the administrator or analyst to review alerts, monitor the network activity, and most importantly, have a willingness, passion, and desire to learn.

Core Components:

Full-packet capture is accomplished via netsniff-ng (http://netsniff-ng.org/), “the packet sniffing beast”. netsniff-ng captures all the traffic your Security Onion sensors see and stores as much of it as your storage solution will hold (Security Onion has a built-in mechanism to purge old data before your disks fill to capacity). Full packet capture is like a video camera for your network, but better because not only can it tell us who came and went, but also exactly where they went and what they brought or took with them (exploit payloads, phishing emails, file exfiltration). It’s a crime scene recorder that can tell us a lot about the victim and the white chalk outline of a compromised host on the ground. There is certainly valuable evidence to be found on the victim’s body, but evidence at the host can be destroyed or manipulated; the camera doesn’t lie, is hard to deceive, and can capture a bullet in transit.

Rule-driven NIDS. For rule-driven network intrusion detection, Security Onion offers the choice of Snort (http://snort.org/) or Suricata (http://suricata-ids.org/). Rule-based systems look at network traffic for fingerprints and identifiers that match known malicious, anomalous or otherwise suspicious traffic. You might say that they’re akin to antivirus signatures for the network, but they’re a bit deeper and more flexible than that.

Analysis-driven NIDS. For analysis-driven network intrusion detection, Security Onion offers The Bro Network Security Monitor, also known as Bro IDS (http://bro-ids.org/). Bro is developed and maintained by the International Computer Science Institute at the University of California at Berkeley and supported with National Science Foundation funding. Unlike rule-based systems that look for needles in the haystack of data, Bro says, “Here’s all your data and this is what I’ve seen. Do with it what you will and here’s a framework so you can.” Bro monitors network activity and logs any connections, DNS requests, detected network services and software, SSL certificates, and HTTP, FTP, IRC SMTP, SSH, SSL, and Syslog activity that it sees, providing a real depth and visibility into the context of data and events on your network. Additionally, Bro includes analyzers for many common protocols and by default has the capacity to check MD5 sums for HTTP file downloads against Team Cymru’s Malware Hash Registry project. Beyond logging activity and traffic analyzers, the Bro framework provides a very extensible way to analyze network data in real time. Recent integration with REN-ISAC’s Collective Intelligence Framework (CIF http://csirtgadgets.org/collective-intelligence-framework/) provides real-time correlation of network activity with up-to-date community intelligence feeds to alert when users access known malicious IPs, domains or URLs. The input framework allows you to feed data into Bro, which can be scripted, for example, to read a comma delimited file of C-level employee usernames and correlate that against other activity, such as when they download an executable file from the Internet. The file analysis framework provides protocol independent file analysis, allowing you to capture files as they pass through your network and automatically pass them to a sandbox or a file share for antivirus scanning. The flexibility of Bro makes it an incredibly powerful ally in your defense.

HIDS:

For host-based intrusion detection, Security Onion offers OSSEC (http://www.ossec.net/), a free, open source HIDS for Windows, Linux and Mac OS X. When you add the OSSEC agent to endpoints on your network, you gain invaluable visibility from endpoint to your network’s exit point. OSSEC performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response. Originally created by Daniel Cid, Trend-Micro acquired OSSEC in 2009 and has continued to offer it as an open source solution. As an analyst, being able to correlate host-based events with network-based events can be the difference in identifying a successful attack.

Analysis Tools:

With full packet capture, IDS logs and Bro data, there is a daunting amount of data available at the analyst’s fingertips. Fortunately, Security Onion integrates the following tools to help make sense of this data:

Sguil (http://sguil.sourceforge.net/), created by Bamm Visscher (@bammv), is “The Analyst Console for Network Security Monitoring.” It is the analyst’s right hand, providing visibility into the event data being collected and the context to validate the detection. Sguil provides a single GUI (written in tcl/tk) in which to view Snort or Suricata alerts, OSSEC alerts, Bro HTTP events, and Passive Real-Time Asset Detection System (PRADS) alerts. More importantly, Sguil allows you to “pivot” directly from an alert into a packet capture (via Wireshark or NetworkMiner) or a transcript of the full session that triggered the alert. So, instead of seeing only an individual packet associated with an alert and being left with the unanswerable question, “What now?” or “What happened next?” you can view all of the associated traffic and actually answer that question. Additionally, Sguil allows the analyst to query all packets captured, not just those involved with an alert, so you can correlate traffic that may not have triggered any alerts but still could be associated with the malicious or undesired activity. Lastly, Sguil allows the analyst to conduct reverse DNS and whois lookups of IP addresses associated with alerts. Sguil differs from other alert interfaces in that it allows collaboration among analysts by allowing alerts to be commented on and escalated to more senior analysts who can take action on the alerts. Sguil is the primary Security Onion tool to provide the most context around a given alert.

Squert (http://www.squertproject.org/), created by Paul Halliday (@01110000), is a web application interface to the Sguil database. Although it is neither meant to be a real-time (or near real-time) interface nor a replacement for Sguil, it allows querying of the Sguil database and provides several visualization options for the data such as “time series representations, weighted and logically grouped result sets” and geo-IP mapping.

Enterprise Log Search and Archive (ELSA https://code.google.com/p/enterprise-log-search-and-archive/), created by Martin Holste (@mcholste), is “a centralized syslog framework built on Syslog-NG, MySQL, and Sphinx full-text search. It provides a fully asynchronous web-based query interface that normalizes logs and makes searching billions of them for arbitrary strings as easy and fast as searching the web. It also includes tools for assigning permissions for viewing the logs as well as email based alerts, scheduled queries, and graphing.” In plain English, ELSA is a powerhouse search tool that allows you to effortlessly comb through most all of the data collected by Security Onion as well as any additional syslog sources that you forward to it, giving you visibility into any relevant syslog data you can send to ELSA. Additionally, ELSA offers powerful charting and graphing Dashboards via the Google Visualization API. It’s difficult to understand ELSA’s power without seeing it action (which you can do at http://www.youtube.com/watch?v=INRJZ3_Dsyc).

Deployment Scenarios:

Security Onion is built on a distributed client-server model. A Security Onion “sensor” is the client and a Security Onion “server” is, well, the server. The server and sensor components can be run on a single physical machine or virtual machine, or multiple sensors can be distributed throughout an infrastructure and configured to report back to a designated server. An analyst connects to the server from a client workstation (typically a Security Onion virtual machine installation) to execute queries and retrieve data.

The following are the three Security Onion deployment scenarios:

Standalone: A standalone installation consists of a single physical or virtual machine running both the server and sensor components and related processes. A standalone installation can have multiple network interfaces monitoring different network segments. A standalone installation is an easiest and most convenient method to monitor a network or networks that are accessible from a single location.

Server-sensor: A server-sensor installation consists of a single machine running the server component with one or more separate machines running the sensor component and reporting back to the server. The sensors run all of the sniffing processes and store the associated packet captures, IDS alerts, and databases for Sguil and ELSA. The analyst connects to the server from a separate client machine and all queries sent to the server are distributed to the appropriate sensor(s), with the requested information being directed back to the client. This model reduces network traffic by keeping the bulk of the collected data on the sensors until requested by the analyst’s client. All traffic between the server and sensors is encrypted and all traffic between client and server is encrypted.

Hybrid: A hybrid installation consists of a standalone installation that also has one or more separate sensors reporting back to the server component of the standalone machine.

The Security Onion setup script allows you to easily configure the best installation scenario to suit your needs.