Threshold not working

Rules
,
1

Hello everyone.
I hope you very well.

I’ am used keyword “threshold” in my rules. But it is not working because alert timestamp out order time.

Why are the alerts not in sequential order of time?
Because of this rules with “threshold” not working.
If you know why it, please tell me.

For example my alerts:

“threshold:type both, count 18, seconds 60, track by_dst;”

1 02/15/2023-06:43:16.873485 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:37661 → 192.168.233.138:22
2 02/15/2023-06:43:20.393088 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:35395 → 192.168.233.138:22
3 02/15/2023-06:43:39.877842 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:45057 → 192.168.233.138:22
4 02/15/2023-06:42:31.022075 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:44839 → 192.168.233.138:22
5 02/15/2023-06:42:27.502400 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:37783 → 192.168.233.138:22
6 02/15/2023-06:44:36.732168 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:35583 → 192.168.233.138:22
7 02/15/2023-06:42:41.587142 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:43875 → 192.168.233.138:22
8 02/15/2023-06:43:25.709256 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:43449 → 192.168.233.138:22
9 02/15/2023-06:42:34.542152 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:37229 → 192.168.233.138:22
10 02/15/2023-06:43:38.084652 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:40221 → 192.168.233.138:22
11 02/15/2023-06:42:38.061929 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:37409 → 192.168.233.138:22
12 02/15/2023-06:42:45.106260 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:37511 → 192.168.233.138:22
13 02/15/2023-06:43:59.396245 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:45867 → 192.168.233.138:22
14 02/15/2023-06:43:32.761414 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:32985 → 192.168.233.138:22
15 02/15/2023-06:42:48.625704 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:39619 → 192.168.233.138:22
16 02/15/2023-06:44:13.684341 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:37667 → 192.168.233.138:22
17 02/15/2023-06:42:50.426403 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:33197 → 192.168.233.138:22
18 02/15/2023-06:43:43.401327 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:42831 → 192.168.233.138:22
19 02/15/2023-06:43:00.986481 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:42967 → 192.168.233.138:22
20 02/15/2023-06:43:55.876103 [] [1:25392:1] FIN + ACK SSH bruteforce stage 2 [] [Classification: (null)] [Priority: 3] {TCP} 192.168.233.142:37939 → 192.168.233.138:22

2

Hi Dion, welcome to our forum and community! :slight_smile:

I assume this can be because the timestamp shows when the alert was triggered, if you were running on live traffic, or the timestamp of the packet, and not when the engine processed the packet for logging it.

I could be wrong, but I don’t think the order in which the alerts are seen in the fast.log is enough to conclude that the threshold keyword isn’t working.

Considering the threshold keyword documentation, my interpretation is that you may see at most 18 alerts per minute for that rule. From the timestamps and number of alerts, this could still be within the thresholds set by the rules.

Furthermore, for us to help, could you give us more info?

  • can you share the full rule you’re using?
  • can you also share a pcap and json for one to reproduce the issue you’re seeing?

Threshold keyword documentation: 8.37. Thresholding Keywords — Suricata 8.0.0-dev documentation

1 Like