Suricata Inline Drop on Encrypted SMB
Suricata 6.0 runs inline on a 10 GbE span between the user VLAN and the data center. It loads 18,000 rules, 4% of packets are dropped, CPU sits at 78% at peak, and packet loss is 0.4%. The business reports slow SMB file copies. The SOC sees repeated alerts for ET POLICY SMB2 Large Write and a custom SMB1 lateral-movement rule on TCP 445 between 10.10.8.0/24 and 10.20.4.0/24. Only 3% of TLS is decrypted. A vulnerability scanner from the same user VLAN runs SMB enumeration at 02:00. The CISO asks whether to keep the IPS inline, move to IDS, or tune. You have one maintenance window and no ability to add 40G hardware this quarter. The rule set includes 900 disabled-by-default rules and 21 rules with high false-positive rates from the scanner.
1. Do you keep Suricata inline, move it to IDS, or use a hybrid? Justify with availability, detection, and evidence trade-offs.
Read the worked answer
Keep inline capability but reduce its blast radius. The current 4% drop rate and 0.4% packet loss are not acceptable for a 10 GbE business link if they correlate with slow SMB copies. A full move to IDS removes prevention but improves availability and visibility. A hybrid is defensible: run most rules in alert mode, keep a small high-confidence blocking set inline, and configure fail-open so a sensor failure does not become an outage.
Why not simply disable IPS. The SMB1 lateral-movement rule may be one of the few controls on east-west traffic, especially with only 3% TLS decryption. Losing it entirely weakens prevention. But keeping 18,000 rules inline at 78% CPU leaves little headroom for a spike or a rule update.
Why not simply tune everything inline. The false positives from the scanner are predictable, but the SMB2 Large Write rule may fire on legitimate backups. Blindly dropping it can hide real staging. Move high-FP rules to alert first, measure, then promote only rules with a low confirmed-FP rate. Set a maintenance window to enable fail-open, reduce inline rule count, and validate with replay traffic. This preserves prevention where it is trustworthy and availability where it is not.
2. Give a concrete rule-tuning plan for the SMB alerts and the scanner false positives, including validation.
Read the worked answer
Baseline first. Export Suricata fast.log, eve.json, and rule metadata for 24 hours. Count alerts by rule SID, source, destination, and hour. Confirm whether the SMB1 lateral-movement alert is actually SMB1 or a signature misfire on SMB2 negotiate traffic. Check whether the scanner account and source are known and scheduled.
Tune by source and protocol, not by disabling broadly. For the scanner, suppress the specific SIDs for the scanner IP or scanner service account during the 02:00 window, or move those SIDs to alert-only. For the SMB1 lateral-movement rule, enable strict SMB1 parsing, add flowbits so it alerts only on a successful SMB1 session, and threshold repeated alerts per source. For SMB2 Large Write, convert to alert-only and add a threshold for unusually large writes outside backup windows; do not drop on size alone.
Validate. Replay a PCAP containing known benign SMB copies and a synthetic SMB1 lateral movement attempt. Confirm the benign traffic does not drop and the synthetic attempt still alerts or blocks. After the window, monitor drop rate and CPU for 48 hours. If CPU remains above 70% at peak, reduce inline rule count further or move low-value rules to IDS. Document every suppression with owner and expiry.
3. With only 3% TLS decryption, how do you hunt lateral movement that Suricata cannot see?
Read the worked answer
Do not rely on the IPS alone. Use identity and endpoint telemetry: Falcon process trees for net use, psexec, wmic, schtasks, and service creation; Windows 4624 type 3 and 5140/5145 share access; DC authentication logs; and NetFlow for SMB fan-out. Correlate a source host contacting many destinations on 445 with new service creation or remote thread activity.
Use network metadata even without decryption. Suricata can still log TLS SNI, JA3/JA4, certificate subjects, flow bytes, and SMB metadata where not encrypted. Build a baseline of which user VLAN hosts normally talk SMB to which data-center subnets. Alert on new host-to-host pairs, especially from user VLAN to server VLAN outside backup windows.
Prioritize the scanner window. The 02:00 scan is a known noisy period. Hunt outside that window and compare. If a host shows SMB enumeration plus a new scheduled task, treat it as lateral movement even if the IPS is silent. This layered approach covers the encrypted blind spot without pretending the IPS sees everything.