Security Onion sensor placement and network taps guide

Where Security Onion sensor placement and network taps decide what you can see

Sensor placement and tap choice decide what your Security Onion grid can see, which alerts it can raise and how much packet data you can later pull back for an investigation. Before ordering hardware, the security team needs a written list of the network segments where the traffic it must investigate actually crosses, because a sensor cannot report on traffic that never reaches its monitoring interface. The install itself is usually the easier part of the work. Security Onion sensors run Suricata and Zeek on monitoring interfaces, and those interfaces only receive what the tap or mirror port hands them. Security Onion's architecture docs describe Distributed as the recommended production design, with a manager node, one or more sensor nodes and one or more search nodes. In that design each sensor is a separate node, so the placement decision is about which sensor sees which segment. A sensor on the wrong segment will run cleanly and still miss the events you care about. The hard part is knowing which segments carry the traffic you need to investigate. Start from the questions the SOC must answer: lateral movement between server zones, traffic leaving to the internet, traffic between the data center and branch sites. Map each question to the network path it depends on, then confirm that path is physically or virtually visible to a monitoring interface. Document any gap as an accepted risk, not an assumption. Several conditions make this harder than it looks. Asymmetric routing can send the request and response of one session through different paths, so a sensor sees only half of a conversation. Encrypted traffic limits what Suricata and Zeek can parse beyond metadata, so placement matters for connection records even when payload is opaque. Cloud segments often have no tap point at all, which means you must confirm what traffic mirroring or flow logging the provider exposes before you assume coverage. Full packet capture also fills disks quickly on busy links, so the capture scope must be sized alongside the sensor, not after it. The minimum sensor hardware is 4 cores, 12 GB RAM and 2 NICs, according to the Security Onion hardware docs. The second NIC is usually a management interface, which leaves one monitoring interface for traffic. Confirm with the vendor and your own environment whether a single monitoring interface can keep up with the link speed and traffic volume of each segment, because the minimum is not a throughput guarantee. Ask for the sensor sizing to be tied to the measured peak load of each tap point.

Tap, SPAN port or sniffing interface: which capture point fits each segment

This table compares the four capture points a team usually weighs for Security Onion sensors, plus the east-west and egress placement choice that applies to each. Read each row as a decision: when the option fits, what it costs to operate, and what to confirm with the network team before scheduling a change. The main takeaway is that the capture point is chosen per segment, and the cheapest option on paper often carries the highest change-control or visibility cost.

Capture point	When it fits	Operational cost	What to confirm with the network team
Dedicated network tap	Segments where complete, unsampled traffic matters, such as a critical server zone or an egress link where missed packets would blind detections	Requires a physical change window and cabling at the tap location; the tap is passive, so switch load is unaffected, but a failed or misconfigured install can interrupt the link	Tap model, port speed and duplex support, fail-open behavior, the physical location, and who approves the cable change
Switch SPAN or mirror port	Access or distribution segments where a tap is impractical and the switch can copy traffic to a monitor port without a physical insertion	Mirror traffic consumes switch CPU and backplane resources; under heavy load the switch may drop mirrored frames first, so detections can silently miss traffic	Maximum mirror sessions per switch, whether the mirror is local or remote, the mirror's bandwidth ceiling, and whether the switch drops mirror traffic under load
Virtual or cloud mirror	Workloads in virtualized data centers or cloud accounts where traffic does not cross a physical switch	Depends on the hypervisor or cloud provider's traffic mirroring feature, which may carry extra charges, limits on mirrored instances, or restrictions on instance types	Whether the platform offers traffic mirroring for the instances in scope, supported mirror targets, per-instance limits, and any charges for mirrored traffic
Host-based sniffing interface	Single hosts or small segments where no network capture point exists, or for short-term visibility on one system	Captures only traffic seen by that host, consumes host CPU and disk, and needs a promiscuous-mode NIC configuration that the host owner must approve	Host owner approval, whether the NIC can run in promiscuous mode in your virtualization layer, and the expected traffic volume on that host
Egress sensor (perimeter)	Internet-bound and internet-sourced traffic at the boundary, useful for command-and-control callbacks, exfiltration and inbound exploitation attempts	Usually a single high-value tap or mirror point, but it sees only traffic crossing the boundary, so it misses activity that never leaves the internal network	Which upstream and downstream links cross the boundary, whether NAT occurs before or after the capture point, and whether encrypted traffic is decrypted upstream
East-west sensor (internal segments)	Lateral movement between internal segments, such as workstation to server, server to server, or access to identity and database tiers	Needs capture points inside the network, so more taps or mirror sessions, more change requests and more sensors to size and monitor	Which VLANs or segments carry sensitive workloads, whether inter-VLAN routing happens on a switch that can mirror, and where east-west traffic stays on the same host
Choosing both placements	Environments where perimeter visibility alone cannot show what happened after an intrusion, which is the usual reason to add internal sensors	Doubles the number of capture points to approve and operate, and each added sensor adds storage and sizing work for the search and sensor tiers	Priority segments for the first phase, sensor count the budget and change calendar allow, and the Security Onion hardware docs for sensor sizing against your link speeds
Mirror capacity and tap specifications	Every option above depends on the link speed and aggregate traffic the sensor must handle	Undersized mirrors or taps drop packets, and drops are easy to miss unless sensor health is monitored	Confirm mirror capacity and tap specifications with the hardware vendor and against the Security Onion hardware docs before ordering equipment

How to place a Security Onion sensor and confirm traffic arrives

This sequence takes one sensor from segment inventory to confirmed packet visibility, so you can show that the traffic you intended to investigate reaches Suricata and Zeek before you rely on it for detection.

Inventory segments and flows to investigate
The network team lists the segments and traffic flows the sensor must see, such as user access to servers, server-to-server traffic in a sensitive zone and outbound internet egress. Each entry names the source and destination subnets, the protocols that matter and who owns the segment. Write the list before choosing hardware, because it sets which capture points are needed and how much traffic each sensor will handle. The step is done when the security lead and network owner sign the list and every flow has a named owner.
Choose the capture point for each segment
For each flow on the list, the network team picks a capture point: a network tap, a SPAN or mirror port on a switch, or a sensor placed on a path that carries the traffic. Taps copy traffic without depending on switch configuration, while mirror ports can drop packets under load and depend on the switch's own limits. Confirm with the switch vendor how mirror sessions behave at your peak link utilization. The step is done when each segment has one documented capture point and a note on whether egress and east-west flows are covered.
Prepare the sensor's monitoring and management NICs
The sensor needs a dedicated monitoring NIC that receives the copied traffic and carries no IP address for capture, plus a separate management NIC that the grid uses to reach the manager. Confirm the hardware meets the sensor minimums in the Security Onion hardware documentation, including two NICs and an x86-64 processor. Keep the monitoring interface free of routing and IP configuration, and confirm the management address and firewall rules. The step is done when the interface layout is written down and the sensor has the expected two NICs visible to the operating system.
Connect the tap or mirror to the monitoring NIC
The engineer connects the tap or mirror output to the dedicated monitoring NIC, using the cable and transceiver that match the link speed and the tap's specifications. Confirm that the tap is passive or that the mirror session is configured in the direction you intend to capture. Check that the link comes up at the expected speed on the sensor. The step is done when the monitoring interface shows link up at the expected speed and the switch or tap documentation matches the cabling record.
Add the sensor to the Distributed grid
Plan for a Distributed deployment with a manager node, the sensor and one or more search nodes, which the Security Onion architecture documentation recommends for production. Register the sensor to the grid through the Security Onion setup process, assigning the monitoring interface for capture and the management interface for grid traffic. Confirm the sensor appears in the grid's node list and reports healthy status. The step is done when the manager shows the sensor as connected and the sensor's services start without errors.
Confirm Suricata and Zeek see packets
Generate traffic across the segment and check that Suricata and Zeek both record it on the sensor. Compare the expected flows from the inventory against the sensor's logs, and confirm that both directions of a conversation appear, since one-way visibility usually points to a tap or mirror configuration problem. Check the monitoring interface's drop counters to see whether packets are lost before analysis. The step is done when expected flows appear in both directions and drop counters stay at the level your team recorded as acceptable.
Verify alerts from a known test event reach the Console
Run a controlled test event that a Suricata rule is known to match, such as a benign signature test your security team has approved, and confirm the alert reaches the Security Onion Console. Repeat the check on the release the grid will keep, because the 3.x line requires Oracle Linux 9 and uses Suricata for full packet capture, so placement checks on another release do not prove the production setup. Record the test event, the sensor and the time it appeared. The step is done when the test alert is visible in the Console and the record is filed with the sensor's placement documentation.

Sensor placement differs by on-premises, cloud and air-gapped environments

On physical networks, sensor placement depends on which switch ports, taps or aggregation points carry the traffic you need to see. A sensor needs a monitoring interface that receives copies of traffic and a management interface for the grid. The minimum hardware for a sensor lists 2 NICs, so plan at least one interface for management and one for capture.

Tap versus SPAN: A network tap copies traffic passively in hardware and does not depend on switch CPU. A SPAN or mirror port is configured on the switch and may drop packets under load or omit some traffic types. Confirm with the switch vendor how mirrored traffic behaves under oversubscription.
Capture points: A sensor upstream of the firewall shows external exposure, a sensor between internal segments shows east-west movement, and a sensor at egress shows outbound traffic. Each sensor sees only what crosses its link.
Who must be involved: Network engineering approves port changes and tap installs, the change board reviews production switch configuration, and facilities handle rack space and cabling.
What cannot be tapped: Traffic between virtual machines on one host never crosses a physical link, and encrypted payloads remain opaque unless decrypted elsewhere. Wireless and some industrial links need specialist access.
Confirm: Link speeds, duplex settings and whether the mirror carries both directions of each conversation.

Confirm every planned capture point with the network team before ordering hardware, because the port map sets the sensor count and interface layout.

How packet capture storage follows sensor placement

Where you place a sensor decides how much traffic it must capture, and that volume sets the storage it needs for full packet capture. In Security Onion 3.x, full packet capture is handled by Suricata, which replaced Stenographer in the 3.0.0 release. Stenographer is gone, so storage planning now starts from Suricata's packet output on each sensor rather than from any inherited Stenographer settings. Before you size disks, list each monitored segment and estimate the average and peak throughput it carries, because a sensor on a busy core link and a sensor on an internet edge link can differ by a wide margin.

Storage need depends on which segments you monitor and how long captures must be kept for investigations. A sensor watching a single egress link sees traffic that is largely inbound and outbound to the internet, while a sensor on a server segment sees the same flows in both directions plus internal traffic. Retention is the second multiplier. Ask your incident response and legal teams how far back investigators need to reconstruct sessions, and whether any regulatory or contractual obligation sets a minimum. Capture volume multiplied by retention window gives the disk footprint, so a short retention on a quiet segment can cost less than a long retention on a single busy one.

East-west segments are often busier than egress, which surprises teams that plan from internet bandwidth. Traffic between application tiers, database replication, backup jobs and container networks can run at high sustained rates inside the data center while the internet uplink stays underused. A sensor placed on an egress point may therefore look adequately sized and still miss most of the lateral movement you need to see. Measure east-west throughput with your existing switch or flow counters over a representative period that includes backup windows and month-end batch runs, and size the sensor for the peak you observe, not for the average.

Sensor disk sizing should follow the chosen placement, not a default image or a figure copied from another deployment. The hardware documentation lists minimum requirements for sensor nodes, including cores, memory, storage and two network interfaces, but those minimums are not a capacity plan for packet capture on a busy link. Confirm the storage requirement for full packet capture against the current hardware documentation for your Security Onion version, then check it against your own traffic measurements and retention target. Ask your vendor or implementation partner to show the calculation behind any proposed disk size, including the assumed throughput, retention period and headroom.

The free edition runs the grid itself, including the console, Suricata, Zeek and search components, but planning storage and placement remains your responsibility. No one configures your switch mirror, decides which segments matter or checks that disks will hold the retention you need unless you assign that work. Before you order hardware, write down the segments, their measured peak rates, the retention window and the disk size each sensor needs, and confirm each figure with the hardware documentation and your own measurements. Revisit the plan whenever a new segment, application or backup pattern changes the traffic a sensor sees.

What drives sensor placement effort and cost

This table lists the factors that change how much work sensor placement takes and who pays for each part of it. Read each row as a question to answer before scoping: the driver, how it raises effort, how to keep it down, and what to request in a quote. The main takeaway is that network team time and change windows usually outweigh the software work, so agree on those early.

Driver	Why it changes effort or cost	How to keep it down	What to ask for in a quote
Number of monitored segments	Each segment needs its own tap or mirror path, a sensor interface and a verified view of traffic. More segments add network team time, cabling and sensor count.	Rank segments by risk, such as internet egress, data center east-west and admin networks, and phase the rest into later waves.	A segment list with a priority for each, and the count of sensor interfaces each wave requires.
Tap or SPAN points needing change windows	Installing a tap or changing a SPAN session often needs a production change window, approvals and a rollback plan. Waiting for windows is usually the longest delay, and the network team bills for this time.	Reuse existing mirror ports where they already see the right traffic, and bundle changes on the same switch into one window.	Who performs each change, the number of change windows assumed, and who owns rollback and approval.
Traffic volume and link speed	Higher throughput needs sensors with more capacity and NICs suited to the link speed, and it raises storage needs for alerts and packet capture. Hardware and storage cost rise with it.	Measure peak traffic on each span before sizing, and start with the segments that matter most rather than sizing for the whole estate at once.	The sizing basis used (measured or estimated peak throughput), the NIC and hardware assumptions, and the storage retention they assume.
Cloud versus on-premises capture	On-premises work centers on taps, SPAN sessions and cabling. In cloud accounts, capture depends on virtual mirroring features and network routing, which need cloud platform engineering and permissions review.	Confirm the cloud mirroring options available in your accounts early, and use the same sensor design across both where possible.	Which cloud accounts and regions are in scope, the mirroring method for each, and the cloud permissions the work requires.
Encrypted or asymmetric traffic	Sensors see only what crosses their interface. Encrypted traffic limits content inspection, and asymmetric routing can mean a sensor sees only one direction of a flow, so coverage needs checking before the design is final.	Map key flows from both directions, confirm which paths cross each sensor, and agree which traffic is out of scope for content inspection.	A coverage test plan that shows flows seen in both directions, and the analyst review time included for verifying coverage.
Number of sensors and need for a Distributed grid	A production design uses a manager, sensor nodes and search nodes. More sensors add hardware, licenses or cloud instances, and build, tuning and upgrade time. A Distributed grid adds design and operations work.	Start with the fewest sensors that cover the priority segments, then add sensors as segments are phased in.	Sensor and node counts by role, the deployment type proposed, and the hardware or cloud instance specifications they assume.
Compliance evidence requests about monitoring coverage	Assessors may ask which networks are monitored, how coverage was verified and how gaps are tracked. Producing that evidence takes documentation, coverage tests and review time. DeployOpen prepares evidence, but auditors decide whether it is sufficient.	Agree the evidence format with your assessor before testing, and build the coverage register as the placement work proceeds.	The evidence deliverables listed (coverage map, test records, gap register), who reviews them, and whether auditor review is included or separate.

Protecting captured traffic and sensor access

A sensor sees everything on the link it watches, so it becomes a sensitive system in its own right. The cards below cover the controls that keep the monitoring path isolated, the management path restricted, and stored packet data governed, along with the check that proves each control is in place.

Keep the monitoring interface silent

The sniffing NIC should have no IP address, no default gateway and no listening host services, so it only receives mirrored traffic. Confirm this on the sensor by checking that the monitoring interface carries no address and that no service binds to it. Also confirm that the tap or SPAN feed is one-directional, since a bidirectional path can let sensor traffic reach the network it watches.

Restrict management NIC access

The management interface is the path to the sensor's SSH service and the link back to the manager, so it needs its own network segment and host-based allow rules. Limit inbound access to named administrator subnets and the manager address. Verify by attempting connections from an unlisted host and from a host on the monitored segment, and confirm both are refused.

Limit who can reach the Console

The Security Onion Console holds alert data, packet references and detection tuning, so access should follow analyst roles, not network location alone. In the free edition, review local console accounts and remove unused ones. Pro adds OIDC single sign-on, which lets you tie Console access to your identity provider. Check the account list against your current analyst roster before go-live.

Treat full packet capture as sensitive

Full packet capture can contain session tokens, passwords sent in clear text, and personal data in application payloads. Classify the capture store at the same level as the data it traverses, and document who may export or download packets. Ask your data protection and legal teams to confirm handling rules before the first capture is enabled on a sensitive segment.

Plan capture retention and access

Retention for packet data is a policy decision that trades investigation depth against storage and exposure. Set a retention period per segment, document it, and confirm that expired captures are actually removed from disk. Test by reviewing storage after the configured period and confirming older files are gone. Record which roles can search, export or retain captures beyond the default.

Evaluate Pro controls for sensitive segments

Security Onion Pro lists LUKS data-at-rest encryption, FIPS mode and OS STIG compliance among its features. For segments that carry regulated or high-sensitivity traffic, evaluate whether these controls are required, and ask the vendor to confirm which versions and components each feature covers. Verify on a test sensor that encryption is active on the capture volume after install.

Account for airgap rule and update delivery

In an airgap install, rules and package updates reach sensors only through new ISO media applied with the soup update tool, so there is no direct pull from the internet. Plan a media transfer process with a documented chain of custody, and confirm that rule updates are applied to every sensor in the grid. Check the rule version on each sensor after an update cycle to prove that all nodes match.

How to prove the sensors see the traffic you expect

Acceptance testing should answer one question for each Security Onion sensor: does it see the traffic it was placed to see, in both directions, and does that evidence reach the Console? Record the tap or SPAN source, the sensor interface and the traffic expected on each monitored segment, then test inbound and outbound flows separately. A tap may carry both directions while a SPAN session may be configured to mirror only one, so a single successful test proves little. Generate controlled test traffic from an approved host and confirm the sessions appear in the Console with the correct sensor name, source and destination. Before any test traffic leaves the network, get written approval from the security and network owners covering the source hosts, destinations, time window and rollback steps.

Next, test the detection path and the capture path. Choose a NIDS rule already loaded into Suricata, trigger it with a benign test that matches the rule's logic, and confirm the alert appears in the Console with the correct sensor attribution. Check the rule's status in the Detections interface so you know whether it was enabled, modified or suppressed at the time of the test. Then confirm that Suricata full packet capture holds the test session in enough detail for an analyst to follow the conversation. Pull the packets for that flow and check that the payload and timing are complete. Compare the retention you observe with the retention your investigators expect, using the values in your own configuration rather than assumed defaults. Record the rule ID, sensor, timestamp and capture reference so the test can be repeated after tuning or upgrades.

Under peak load, the question shifts from whether traffic arrives to whether the sensor keeps up. Run the test during a representative busy period, or use a replay approved by the owners, and read the drop counters on each capture interface alongside CPU, memory and disk use on the sensor. Drops on the capture interface mean packets never reached the analysis engines, so any result from that sensor during the test should carry that caveat. The hardware documentation lists a sensor minimum of 4 cores, 12 GB RAM and 2 NICs. Treat those figures as a starting floor, and size against the link speed and peak traffic of your own segment. Ask your implementation partner to show the drop counter baseline for each sensor, and keep the peak test results with the sensor's acceptance record so future changes can be compared against them.

The failure most likely to go unnoticed is silence. When a tap fails, a switch configuration change ends a SPAN session, or a sensor stops capturing, the Console can keep running with no errors and simply show fewer alerts and sessions. Establish a baseline for each sensor during normal hours, covering session volume and the interfaces that should show traffic, and alert when a sensor falls below its own baseline or reports no traffic for a window you define. Confirm with your edition which notification options are available, since external notifications are listed as a Security Onion Pro feature and the free edition may need another monitoring path. Tie every SPAN or tap change to a change record that triggers the bidirectional test again, so a reconfiguration is verified before anyone assumes the sensor is still seeing the same traffic.

What to monitor, document and review after sensors go live

A sensor that captured traffic correctly on day one can quietly stop seeing it later, through link changes, full disks or a network that has grown around it. The items below are the recurring checks, documents and review triggers that keep sensor placement accurate after go-live.

Sensor interface health and drop rates

Owner: the sensor operator on the platform or network team. Review on a fixed cadence and after any change to the tap, SPAN session or sensor NIC. Track link state, traffic counters and packet drops on each capture interface, and compare them with the volume you expect from that segment. A rising drop rate or a flat line on a busy segment usually means a failing optic, a saturated SPAN session or a sensor that is under-provisioned for its link speed. Confirm which counters and alert thresholds your own monitoring tooling can read from the sensor.

Packet capture disk usage

Owner: the platform team that runs the grid, with storage capacity reviewed by whoever approved the sizing. Full packet capture consumes disk far faster than logs, so watch how many days of traffic the sensor actually retains against the retention target set during planning. Check utilization after any increase in traffic on the monitored segments, because higher throughput shortens retention without any configuration change. Confirm with your own tooling how disk alerts reach the on-call team before the capture volume fills.

Placement review after network changes

Owner: the network engineering team, with the Security Onion operator added to the change approval. Review each sensor's placement when a new subnet, cloud account, VPC peering link, firewall or switch replacement enters the environment. A sensor that still shows traffic may be watching a segment that has lost its east-west or egress path to the rest of the network. Record which changes triggered a review and what each review concluded, so the next audit can trace the decision.

Current capture point and segment diagram

Owner: the network architect, with the sensor operator responsible for accuracy. Keep a diagram that shows, for each sensor, the tap or SPAN source, the switch port or virtual interface it listens on, the network segment it covers and whether that coverage is east-west, egress or both. Update it in the same change window as any cabling or routing change. Analysts rely on this diagram to judge whether a missing alert means a clean network or a blind spot.

Grid configuration and sensor settings backups

Owner: the platform team, with the manager node backup owned by whoever administers the grid. Back up the grid configuration and each sensor's settings after every placement change, interface assignment or rule change, and store the copies outside the grid. Restoring a sensor to its previous interface mapping is faster when the last known good configuration is on hand. Confirm with the Security Onion documentation for your version which configuration files and data the backup procedure covers, and test a restore on a non-production node.

Sensor changes planned with soup upgrades

Owner: the platform engineering lead, with the network team consulted on any interface change. Security Onion upgrades with the soup tool, and a sensor change such as a new capture interface or a moved tap can interact with a new release. Rehearse both the upgrade and the placement change on a matching test grid before production, and schedule them so a failed step can be rolled back without leaving a sensor blind. Confirm the supported upgrade path for your installed version before you plan the window.

Common questions about Security Onion sensor placement and taps

Can our internal team place Security Onion sensors without outside help?

Yes, if your team already runs network and Linux infrastructure and has time to test each placement. Sensor placement itself is mostly a matter of choosing which links carry the traffic you need to see, then confirming that the sensor receives it. The harder parts are coordinating change windows with the network team, confirming that a tap or SPAN source is stable, and validating that Suricata and Zeek see the expected traffic before you rely on the data. Teams that have no one who has done a distributed deployment before often spend more time on validation than on installation. A scoped engagement covers the same steps with a written list of what is delivered, so you can compare the effort against your own capacity.

What does the network and security team need to provide for sensor placement?

The network team provides the topology, the switch or tap access, and change approval. The security team provides the coverage goals and the analysts who will use the data. In practice, the network team needs to identify candidate links, such as core uplinks, east-west segments and internet egress, and confirm whether each can be mirrored or tapped without disrupting production. The security team needs to state which segments matter most, who will review alerts, and how long packet data must be kept. Both teams should agree on access to the sensor hosts and on who owns the monitoring interfaces. Missing any of these inputs is a common reason placement work stalls.

What drives the cost of placing Security Onion sensors?

The main drivers are the number of monitored segments, the tap hardware you buy, and the storage needed for packet capture. Each segment that needs its own sensor or interface adds configuration, testing and documentation work. Tap purchases are usually one-time hardware costs, and their type depends on link speed and whether you need aggregation. Packet capture storage recurs as data grows, so retention targets change the long-term footprint more than the initial install does. Ask any provider to split the quote into labor, hardware you buy, and storage you provision, with each line tied to a named segment. Any figure given without that breakdown is hard to compare.

How long does Security Onion sensor placement take?

The timeline depends on the scope, so ask for a timeline based on a written list of segments, links and change windows. Duration is driven by how many links need access, how long the network team takes to approve changes, whether tap hardware must be ordered and delivered, and how much validation each sensor needs. A single link in a lab is not comparable to a dozen production segments across several sites. Ask the provider to state which steps depend on your teams and which depend on hardware lead times. This report should be part of the scoped quote, not a general estimate.

Is a network tap required, or is a SPAN port enough for Security Onion?

A SPAN port can work for some links, but a tap is generally the more complete choice for full visibility. A SPAN or mirror port is configured on a switch and copies traffic, but it may drop packets under heavy load and it usually cannot see every frame that a tap captures, including errors. A passive tap copies traffic without relying on switch CPU and is typically preferred for production monitoring of critical links. Your choice depends on link speed, the switch's mirroring capacity, the change policy for the switch, and how much packet loss you can accept. Confirm the behavior of your specific switch model before deciding, and check the sensor's hardware requirements for the NICs you plan to use.

How does placement change when we add Security Onion Pro features?

Pro features mostly change the platform and access layers, so sensor placement stays largely the same. Pro adds OIDC single sign-on to the Console, LUKS encryption of data at rest, FIPS mode, OS STIG compliance, the API, external notifications, Manager of Managers, an MCP server, the Onion AI assistant and professional support. None of these choose which links a sensor watches. They do affect where the manager and search nodes sit, how analysts authenticate, and what the host build must meet. If you plan to use FIPS or STIG controls, confirm them before choosing sensor hardware, because they can change the base operating system and the supported configurations.

What hardware does a Security Onion sensor need?

Each sensor needs an x86-64 processor, at least 4 cores, 12 GB RAM and 2 NICs, according to the Security Onion hardware documentation. Those are minimums, not sizing for your traffic. Actual requirements rise with link speed, the number of sessions, the amount of traffic inspected and the packet capture retention you set. Storage and NIC choices should be verified against your largest link and your retention target. Confirm the current figures in the Security Onion hardware documentation for the version you plan to deploy, because the minimums can change between releases.

How DeployOpen scopes, places and hands over Security Onion sensors

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and Security Onion sensor placement is handled the same way. We start from the traffic you need to see, then agree the sensor layout, tap or SPAN approach and capture design in a written scope before any hardware is racked.

How we scope

Map which east-west, north-south and egress flows must be visible, and which network segments sit outside the sensor view today.
Confirm whether each segment can be fed by a network tap or only by a SPAN port, and record the trade-offs in the scope.
Agree the expected link speeds and peak traffic per sensor so NIC, CPU and storage sizing can be checked against the hardware requirements.
Define retention targets for Suricata and Zeek logs and full packet capture, since capture storage is the largest sizing driver.

How we build

Install sensor nodes in a Distributed design with a manager and search nodes, following Security Onion's architecture and hardware guidance for x86-64 hosts.
Configure monitoring interfaces with the required network cards and verify that each sniffing interface receives the expected traffic before enabling detections.
Test packet loss and drop counters under representative load, then adjust tap aggregation, interface settings or sensor count as needed.
Confirm capture is working for each segment, including that full packet capture writes to storage at the rate the retention design assumes.

How we hand over

Deliver a sensor placement diagram showing every tap, SPAN source, sniffing interface and the traffic segment each one covers.
Document the sizing basis, storage paths, retention settings and the checks used to prove each sensor sees its intended traffic.
Provide runbooks for adding a sensor, replacing a tap, changing a SPAN session and recovering a failed capture interface.
Walk your operations and security teams through the handover and record open items, owners and any segments still to be covered.

How we support

Offer ongoing support as a retainer for sensor health checks, capacity reviews and changes as the network grows or link speeds increase.
Review drop counters, capture storage use and coverage gaps after network changes, and recommend placement adjustments in writing.
Plan sensor changes and Security Onion upgrades on a matching test grid before production, so coverage is not lost during maintenance.
Confirm with Security Onion Solutions which edition, support terms and version lines apply to your grid before you commit to a design.

Security Onion sensor placement and network taps