Security Onion full packet capture

Security Onion 3.0.0, released on March 31, 2026, replaced Stenographer with Suricata for full packet capture. For planning, this means any sizing notes, runbooks or pivot procedures written for Stenographer describe a component that no longer exists in 3.x. Teams that inherited those documents should treat them as a starting point to rework, not as a checklist to copy forward. The change affects how you size sensor disks, where analysts look for packets, and what you need to validate before cutover.

On a sensor, the monitoring interface receives mirrored traffic from a SPAN port, network TAP or equivalent. Suricata inspects that traffic and writes alerts and related records, which the Console and search infrastructure then index for analysts. Packets are kept on the sensor according to the disk space available, so the effective retention window depends on traffic volume and storage capacity rather than a fixed number of days. Before you commit to a design, confirm in the current Security Onion documentation where packets are stored on the sensor, whether that path can be changed, and how older captures are removed when the disk fills.

Upgrade options depend on the base operating system. A Security Onion 2.4 installation on Oracle Linux 9 can upgrade to 3 after you move full packet capture from Stenographer to Suricata. Installations on other distributions need a fresh install instead, so moving those sensors to 3.x is a rebuild with its own change window. Security Onion 3.0.0 supports only Oracle Linux 9. If your standard operating system is something else, you must either change the base platform or remain on an earlier release, and the 2.4 end-of-life date of October 1, 2026 should factor into that decision.

Before you schedule the change, inventory every sensor by operating system, Security Onion version and disk layout. Decide whether captures held under Stenographer need to remain searchable or exportable for open investigations, and plan how to preserve them before cutover, since you should not assume they carry over. Then build a test sensor, mirror representative traffic to it and confirm that packets are written, alerts are indexed and disk usage grows at the rate your sizing assumes. The latest tagged release on GitHub is 3.3.0, published September 11, 2026, so check its release notes against your plan before you start.

Disk sets how far back full packet capture can reach, so the retention you need determines the disk you buy. No fixed retention figure is supplied for this page, and the 200 GB storage minimum for a standalone Security Onion node is a floor for installation and nothing more. Treat any retention number you find elsewhere as a starting hypothesis until you have measured your own network. Begin by writing down the questions the captures must answer, such as how far back an analyst must see when an alert fires, or how far back a breach may have started when it is reported weeks later.

Five variables determine how many hours or days a given disk holds. The first is average traffic volume on each mirrored segment, measured in bytes per second at the sensor's monitoring interface during business hours and overnight. The second is the share of that traffic worth keeping. Bulk backups, software updates and streaming can add large volumes with little investigative value, so decide whether to exclude them with capture filters or accept the storage cost. The third is the number of sensors, because each sensor writes its own captures and total storage is the sum across them. The fourth is how long investigations must reach back, including any compliance obligation and your incident response window. The fifth is headroom for traffic spikes and filesystem overhead, which reduces usable space below the raw disk size.

Measure before you buy. Run a pilot sensor on a representative segment for a period that includes ordinary working weeks and at least one peak period, such as month-end processing or a patch cycle. Record average and peak write rates from the sensor itself, since switch counters show mirrored volume but not what the sensor stores or drops. Divide usable disk space by the write rate to estimate retention for each candidate disk size, then repeat the calculation at peak rates to see the worst case. Confirm the results against the storage reporting in the version you install, because pruning behavior and the storage layout for the sensor role are details to verify in your environment.

Validate the estimate with a test incident before committing hardware. Have the team generate a benign but suspicious event on the pilot segment, wait for the alert to appear, then pivot from the alert to the stored packets. Check that packets from the start of the session are still present, and record the oldest timestamp available at that moment. Compare that age with the retention you calculated. If the packets disappear sooner than predicted, the gap usually sits in traffic volume or headroom, so revisit those inputs before you buy. Ask any hardware supplier or integrator to state the retention in writing for the traffic profile you measured, and confirm that figure with a second test on the final hardware.

The analyst workflow starts with a Suricata alert in the Security Onion Console, pivots from that alert to the related traffic and packet data, reviews the session, and exports the relevant stream to Wireshark for protocol-level analysis. The sequence matters less than the precondition behind it: the pivot only returns packets if full packet capture recorded the traffic for the time window and network segment where the alert fired. Suricata produces the alert from the traffic it inspects, but the packet data you can retrieve afterward depends on what the capture sensor kept, for how long, and on which interface it was watching.

Before an analyst relies on this path, run a pivot test during setup. Pick a Suricata alert from a known sensor, note its timestamp and the sensor that raised it, and then follow the pivot from the Console to the session and packet data. Confirm that the packets appear, that they cover the flow in the alert, and that the time range lines up with the alert timestamp. Repeat the test for a sensor on each network segment you plan to monitor. A gap found here, such as a sensor that captures only one direction, a mirror port that drops traffic, or a retention window shorter than your investigation lag, is much cheaper to fix before an incident than during one.

The exact pivot and export controls depend on the Security Onion release you run. Security Onion 3.0.0 replaced Stenographer with Suricata for full packet capture, so menus, pivot options and export behavior differ from the 2.x releases many teams learned on. Confirm the current steps in the Security Onion documentation for your version before you write them down. Do not assume that an export option you saw in a demo or an older guide still exists in the release you deploy, and check whether the Console can export a stream directly or whether you need to retrieve the capture file through another method on the sensor.

Document the export steps in your team's runbook so evidence handling stays consistent across analysts and shifts. The runbook should record which sensor and interface to query, how to set the time window around the alert, how to name and hash exported files, where they are stored, who may open them, and how the chain of custody is noted in your case record. Consistent steps also make the pivot test repeatable after upgrades, sensor changes or rule updates, which is when a silent regression is most likely to appear.

Finally, plan for the case where the pivot finds nothing. If packets are missing, check first whether the sensor was healthy during the window, whether capture covered that segment, and whether retention had already expired. Record the gap in the investigation notes rather than filling it with assumptions about what the traffic probably contained. Wireshark analysis is only as complete as the capture behind it, so a clear statement of what was and was not recorded is part of a defensible finding.