Surpress False Positives

Hello all,

I’m pretty new to IDS and not a programmer (only network engineer). I like to eliminate false positives. I like to remove the alerts from the source and to the destination with a port number? For example, sql access from this host to sql server on port 1433 is safe. Or endpoint protection is reporting antivirus scan results to the server on port 7801 and this should not be detected as Log4j attempt. Is there any fast way to do that since I have a lot of false positives from INTERNAL hosts to INTERNAL hosts(please see below? If I can do it only with suppress, please give example source, destination and the PORT number.

Thank you

There’s a suppress option to avoid alert for a certain host.

suppress gen_id 0, sig_id 0, track by_src, ip


1 Like

Thank you @lex
I tried that but I have SALT and it removes them from the threshold.config after the restart.
Do you have example for salt? saltstack/local/pillar/minions/MACHINEID_standalone.sls
In my case most of the alerts are coming from the same host or same subnet. I like to disable/suppress them only for them and rules should stay there. What is the best way to do that?

Thanks again.

You can also try to use pass rule to ignore all the alert between trusted sources and dest.

# For example ignore alerts from host ip to sql server on port 1433
pass ip any <> [sqlserver ip] 1433 (msg:"pass all traffic from/to with sql server port 1433"; sid:1000000;)

Ref: 9.7. Ignoring Traffic — Suricata 6.0.4 documentation

AFAIK, suricata salt formula won’t manage the local rules files for you so you may need to add the rules by yourself via another states.

Thank you @Hita
I managed to solve it but your suggestion is very interesting. Should I add it to the thresholding section? I’m using the below format. Thanks again.

      - threshold:
          gen_id: 1
          type: threshold
          track: by_src
          count: 10
          seconds: 10
      - threshold:
          gen_id: 1
          type: limit
          track: by_dst
          count: 100
          seconds: 30
      - rate_filter:
          gen_id: 1
          track: by_rule
          count: 50
          seconds: 30
          new_action: alert
          timeout: 30
      - suppress:
          gen_id: 1
          track: by_either

Any reason why not use a bpf filter in this case?