In Suricata IDS mode. is it possible to block/drop/pass good traffic so it will not be seen in kibana?

This can be done with pass rules. It’s what I currently do to reduce alerts forwarded to graylog. Using pass rules stops any alert entry from going into the default eve.log

I’m assuming you are storing and loading your custom rules in a separate file and have the file defined in the suricata.yaml file under the suricata-update section

rule-files:                                                                                                                                                                           
  - suricata.rules                                                                                                                                                                    
  - your-custom-file.rules

In your-custom-file.rules you can have entries like this:

# Modifies SID2100366 - GPL ICMP_INFO PING *NIX as these hosts are allowed to ping each other.                                                                                    
pass icmp $MONITORING_HOSTS any -> $MONITORED_HOSTS any (itype:8; sid:1100000; rev:1;)

$MONITORING_HOSTS and $MONITORED_HOSTS are defined in my suricata.yaml similar to HOME_NET, HTTP_SERVERS, SSH_PORTS.

Note that having a msg value here doesn’t really matter here since you aren’t actually creating an alert or log entry anywhere. We sometimes include them or make comments above the signature. Make sure to include a unique SID from within the local range.


Example

If you want to pass all http traffic for a set of host you can do the following:

In suricata.yaml define the host(s)

WEB_SVR1: "[1.1.1.1, 2001:100::84]"
WEB_SVR2: "[1.1.1.2,2001:100::85]"

In your custom rule file you add the following:

pass http $WEB_SVR1 [80,443] -> $WEB_SRV2 [80,443] (msg:"Allow these servers to talk to each other";)

or pass all traffic

pass ip $WEB_SVR1 any -> $WEB_SRV2 any (msg:"Allow these servers to talk to each other";)

Note the direction here, I don’t have rules using the <> specification but you should be able to replace → with <>.

Test New Rule

You can use suricata with the -T flag to have it test loading the configurations and rules files. Any errors in your rule will show up.

/usr/bin/suricata -T -c /etc/suricata/suricata.yaml

You may need to run suricata-update here I can’t remember. We deploy this as playbook so we may have just added suricata-update to prime the new rule loading. You will also need to restart the Suricata service to load in the new rules you have created. You can look into having suricata-update reload the service or for right now I would say just perform the systemd restart.

Its usually something like:

systemctl restart suricata