SOC Alerts Stop Appearing After Initial Detection

[Trylyo]

Version

2.4.150

Installation Method

Security Onion ISO image

Description

other (please provide detail below)

Installation Type

Standalone

Location

on-prem with Internet access

Hardware Specs

Meets minimum requirements

CPU

4

RAM

32 GB

Storage for /

162

Storage for /nsm

326

Network Traffic Collection

span port

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

Hello,
I'm experiencing an issue with alerts in Security Onion’s SOC interface.

I disabled all preexisting rules and created a custom NIDS rule following the documentation https://docs.securityonion.net/en/2.4/nids.html#adding-new-nids-rules:
icmp any any -> any any

Initially, the rule had a mismatch ( not the subeject of this discussion ), but after a full Security Onion restart, the rule was correctly loaded. To test the rule, I continuously pinged a device, and alerts began to appear in the alert table.
However, after approximately 10 minutes, only 5–10 alerts appeared, and no further alerts were generated. Changing the source of the ping triggered a few more alerts (2–4), but they also stopped shortly after.

Observations

Based on the logs show bellow, it appears that alerts are being detected but then automatically suppressed. We did not set any thresholds initially and even after adding a threshold directly to the Suricata rule or via the tuning section, the behavior persisted.
Restarting Suricata (so-suricata-restart) causes alerts to briefly resume but only for another ~10-minute window.

Additionnal Observations

• Running tcpdump -nn -i eth1 icmp shows uninterrupted ICMP traffic arriving at the Security Onion sensor, even when alerts stop appearing. This suggests the issue is not with traffic ingestion.

• Kibana reflects the same behavior as the SOC alert table — once alerts stop in SOC, they stop in Kibana too. No discrepancy between the two views.

• The eve.json log shows entries when alerts are initially triggered, but stops logging once alerts stop.

Steps Taken:

• Added a threshold to the custom rule

• Modified /opt/so/saltstack/default/salt/suricata/defaults.yaml to add:

_max-alerts-packet_

Used Administration > Configuration > Suricata > config to increase:

max-pending-packets

Increase fetch limit in Alerts tables

None of these changes resolved the issue.
The logs may suggest that something is automatically suppressing the alerts after some time, but we cannot identify the setting responsible.
Note: default detection rules do not seem affected.

If you need any additional information, please let me know — I’ll be happy to provide it.
Looking forward to your guidance.

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[cm-ops]

What does your rule look like?

[Trylyo]

Although IPv6 is not supposed to be enabled on the device sending the ping, the source IP shown in the alert is the SOC VM itself.

[Trylyo]

After adding flow:stateless to my rule (with or without tuning), alerts now appear consistently without interruption.

Is the flow:stateless parameter required only for ping (ICMP) rules, or is it needed for all custom rules to appear in the alert dashboard?

[cm-ops]

Since you are using ICMP, have you tried changing the flow timouts in the suricata.yaml? https://docs.suricata.io/en/latest/configuration/suricata-yaml.html#flow-time-outs

[Trylyo]

After further testing, as suggested, I found two working solutions:

1. Adjusting flow timeout:
   Changing the flow-timeout: established value from 300 to 1 causes alerts from continuous pings to appear approximately every 2 minutes in the SOC dashboard. This behavior can likely be tuned further.

2. Using flow:stateless in the detection source of the rule:
   Adding flow:stateless makes each ping trigger a separate alert, which then appears consistently. The alert rate can then be controlled using thresholds.

Both approches work, I'll consider the issue resolved.
Thanks again for the support

[Trylyo]

The rule is as followed

First without tunning
Seeing alerts stop we try, adding different tunning setting

Same behaviour so we then remove the tunning part and add the thresold directly into the rule source itself following suricata documentation https://docs.suricata.io/en/latest/rules/thresholding.html

Everytime a rule was modifiy we did a suricata full update in the detection view followed by a so-suricata-restart

the sid is the one so gave me when using create nids