Newbie to Suricata here.
In Suricata IDS mode. is it possible to block/drop/pass good traffic so it will not be seen in kibana?
drop ip any any <> any any (msg:“pass traffic for test”; sid:123;)
drop ip xxx any <> xxx any (msg:“pass traffic for test”; sid:123;)
These syntax did not work. i was still seeing traffic from that IP address. Please help
i also tried several commands such as supress, not, pass
Hi,
As far as I know it is not possible, it can only be in IPS mode.
Hi MYK,
I haven’t used Kibana myself, so I’m not sure, but could some of the options in ignoring traffic be useful for you, perhaps? There are a few possibilities there, from filtering, to adding pass ou suppress rules, to bypassing traffic… 9.7. Ignoring Traffic — Suricata 7.0.0-dev documentation
Welcome to our forum and let us know if you found something that works for you! 
I’m guessing trying to filter on Elastic ingest is too heavy?
Are you ingesting the drops.json separately? Or everything in 1 eve json output?
If you drop any any in IPS mode I assume you would get nothing through the wire and everything in eve drops output.
Ah, re-read what suricatalfon said, yes you can not drop in IDS mode.
You could write alerts to a separate json file and ingest only that. Or filter with logstash/filebeat to only send alerts from your eve output.
Ok Thanks Guys. Ive tried several commands such as drop, pass, supress,bypass with not luck in IDS mode. Seems like the only command that works is “Alerts ip any any <> any any (msg:“pass traffic for test”; sid:123;)” Pretty much what im trying to figure out is how to ignore ignore traffic, so it wont show in kibana. As of right now were just seeing alot of good traffic and were trying to ignore those traffic within suricata. For example were seeing nessus scanning traffic. We would like to ignore the Nessus scanner IP addresses.
Hi Ju. Thank you but i have visited that site and tried those BPF commands but unfortunately did not work. not sure if BPF workds in IDS mode. our monitoring system is configured for IDS mode only
Any system behind a tap, SPAN port cannot affect traffic flow as the system(s) receive a copy of traffic that’s already been transmitted.
You can configure Suricata to ignore traffic from specific IP addresses, CIDR blocks through BPF and/or setting up the rule variables HOME_NET and EXTERNAL_NET
@jufajardini posted a link with examples recently …
see In Suricata IDS mode. is it possible to block/drop/pass good traffic so it will not be seen in kibana? - #3 by jufajardini
Thanks Jeff. These are the commands that ive tried with no luck
drop ip any any <> any any (msg:“pass traffic for test”; sid:123;)
drop ip xxx any <> xxx any (msg:“pass traffic for test”; sid:123;)
Pass HOME_NET any <> External Net (msg:“pass traffic for test”; sid:123;)
supress any any <> any any (msg:“pass traffic for test”; contains “google.com”; sid:123;)
can you give me an example of how to “ignore” traffic like DNS or IP? any help would be appreciated. thank you.
Again – you won’t be able to drop traffic using Suricata in IDS mode. You won’t be able to drop traffic behind a network tap, span port, or similar.
Here’s a BPF filter to ignore UDP traffic sent to the default DNS port: udp dst port not 53. You can add this to the end of the Suricata command line
Hello Corey,
Could you please advise how to separate alerts from normal traffic and make them written into a separate file? Such that, normal traffic into traffic.json and alerts into alerts.json. Because I don’t want normal traffic to show up in Kibana… Also, normal traffic is eating up my storage resources in SIEM and I don’t want them to be fed into the SIEM. So appreciate your help in this issue.
Thanks,
Bilal
Hi,
You can separate alerts into a separate output file.
If I understand your question, you’d like to separate logging information from alerts. If that’s correct,
use multiple eve-log sections in your Suricata configuration file suricata.yaml.
Here’s a link to an older forum post where this is presented.
Hi Jeff,
Thanks a lot for answering my inquiry!
I’ve applied the steps mentioned successfully. Another question please, assuming that you have ELK SIEM and you want to forward Suricata alerts to for better visibility, would it be a good practice to forward alerts only? I mean, isn’t it necessary also from detection perspective to look at flow or snmp? Knowing in my network, flow and snmp are highly consuming the storage capacity and occupying more than 50% of the inspected traffic.
Please need your advice about the best practice to combine between detection capability and network visibility in one hand and saving storage resource and eliminating unnecessary traffic in another hand.
Thanks a lot!!
Regards,
Bilal
I’m glad you were able to solve the immediate problem of separating log information from alerts.
Regarding your second question, the alerts contain some contextual information but the logs should be available for full forensic analysis. This is my opinion; others in the forum will probably have other ideas of how to handle the balance of storage resources and what’s necessary for investigation.
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
Hi Bilal,
I only send alerts from the eve.json file into our graylog cluster. Depending on how busy your network or where you are tapping your mirror traffic you can use something like https://arkime.com/ to do full packet capturing and indexing. If you install Arkime on the same box or can give it access to the eve.json log it will attach the matching alert SID to the entry.