Suricata Alert Surge After a Rule Update

I would separate volume from risk. The 3,870 Struts alerts match the scanner's source IP, destination set, port, and scan window, so they are probably scanner-induced. But a shared scanner account and seven-day log retention mean I cannot treat the source as trusted without validation. I would pull a sample of packets or flow records, confirm the scanner process and scan job from its logs, and check whether the scanner host itself shows anomalous outbound traffic. I would create a narrow, expiring suppression for 10.10.4.15 to the 140 web servers on port 8080, not a global disable of SID 2024897. I would keep alerts if the scanner source changes, if the destination is outside the web server group, or if the traffic occurs outside the scan window. I would also verify the patched Struts version on a sample of servers. The six reverse-shell alerts are separate and must not be buried by the volume; I would triage them first because they are low-volume and behaviorally specific.

Six alerts spaced 45-70 seconds apart from one internal host to an external IP on port 4444 are more concerning than the scanner noise. Periodic connections to a nonstandard port can indicate a reverse shell or command-and-control channel, although they could also be an administrative tool or a misconfigured application. I would treat them as potentially critical. Immediate steps are to preserve the IDS payload and flow records, query NetFlow and proxy logs for the same host and external IP, and check EDR for the process that owns the connection. I would contact the host owner through a verified channel, not the possibly compromised host, and prepare to isolate 10.20.8.77 if the process is unexplained. I would also check whether 203.0.113.44 appears in threat intelligence and whether other internal hosts contact it. Given the 30-minute SLA and one analyst, I would escalate this before finishing the scanner analysis.

I would recommend context-aware tuning rather than disabling rules. For the scanner, create a suppression or threshold keyed to the authenticated scanner IP, destination group, port, and scan window, with an expiration date and a review owner. Add a companion alert if the scanner source communicates outside that profile. For the reverse-shell rule, keep it enabled and consider raising severity or adding a threshold that still catches low-and-slow connections. I would document the alert counts, sample evidence, validation steps, suppression rationale, and the decision to escalate the six alerts. The change should go through change control with a rollback plan and a test in a staging sensor. I would also recommend extending scanner log retention beyond seven days and replacing the shared scanner account, because both weaken future triage. Finally, schedule a rule-set review, since 14 months without tuning contributed to the noise.