@teamits That seems to have worked. I guess maybe restarting the global service resets any global settings and restarting on the interface updates the interface settings but restarting the global service didn't seem to update the interface settings.

Yes, though usually attracting the attention of @bmeeks is the best way to get traction on this. Steve

No, it cannot.

@bmeeks said in Suricata inline whitelisting: Suppress rules can be used to make sure no alerts are generated for a host. This is not efficient however, as the suppression is only considered post-matching. In other words, Suricata first inspects a rule, and only then will it consider per-host suppressions. This means to me that the pass, drop, reject, etc., decision is made first and then the suppress list is checked to see whether or not to suppress the alert in the logs.  I need to dive into the source code for the Suricata binary and see if I can precisely determine how suppression affects dropping. I need to dig into this some more before I can post a definitive answer. Hi, did this get figured out/resolved? We may have run into this today on Suricata package v4.0.4_1...I suppressed an alert but the behavior didn't seem to change until I disabled the rule. (FWIW it was rule 1:2013744 "ET INFO DYNAMIC_DNS HTTP Request to a no-ip Domain" which would make sense for dynamic domains but was for cdn.no-ip.com which is their actual domain. The rule only excludes www.no-ip.com.)

OpenAppID rules seem to download fine for me. What interface are you running snort on ? Run it on your LAN as you then see hosts pre NAT. Yup the ping rule is a good test to see if snort is working. If you change your ICMP rule slightly :- alert icmp $HOME_NET any -> !$HOME_NET any (msg:“ICMP test”; sid:10000001; rev:001;classtype:misc-activity;) alert icmp $HOME_NET any -> !$HOME_NET any (msg:“ICMP test”; sid:10000001; rev:001;classtype:icmp-event;) It should block outbound ICMP traffic. andy@pi-3:~ $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=45 time=14.8 ms ^C --- 8.8.8.8 ping statistics --- 6 packets transmitted, 1 received, 83% packet loss, time 5160ms rtt min/avg/max/mdev = 14.847/14.847/14.847/0.000 ms andy@pi-3:~ $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2064ms andy@pi-3:~ $ [image: 1527847251550-untitled-resized.jpeg]

Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz Current: 3600 MHz, Max: 3601 MHz 8 CPUs: 1 package(s) x 4 core(s) x 2 hardware threads AES-NI CPU Crypto: Yes (active)

@nogbadthebad I wanna assume good faith here and that you're trying to help - but please try and not fall into the trap of first failing to read the OP, then insisting on a non-solution, followed by complete ignoring the OP altogether. I understand how to submit FRs - not my purpose here. Simply ignore the thread if you have nothing assistive to add. Thanks.

https://snort.org/ < ask here

i had the exact same issue on my box. so i removed it and switched to Snort which has always worked for me in the past. hopefully someone can shed some light on this

Yes, if the built-in rules you select don't match your requirements, you can write a custom rule to block a specific application. I just created this custom test rule to block WhatsApp: alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"WhatsApp";flow:from_client;appid:whatsapp; sid:1000056 ; classtype:misc-activity; rev:1;) …it blocks to a lesser or greater extent, see attached image of the alerts generated, and a lot depends on how up-to-date and accurate the Snort detectors are and how quickly the applications change. You can get a list of applications from the Snort snort-openappid.tar.gz file at https://www.snort.org/downloads#openappid [image: 2018-05-19_15-20-44.png] [image: 2018-05-19_15-20-44.png_thumb]

Read through these forums on IDS/IPS, you will notice a trend that Bill is more than helpful. I've learned so much just reading through other people's issues as well as my own. Bill goes out of his way to not be condescending, but sometimes stating things in forums may seem that way. Unfortunately, you can't type tone. NollipfSense has great advice for this instance and in general when trying to isolate a specific case. Bill's advice is really the only long term solution. I went through the same troubles for a long time till I got my IPS working the way it does now. It takes time for trial, error, reading, more errors, more reading, watch some videos on it, and so on. Good luck

Sorry for the late reply, but forgot to click on 'notify' why is it not a good thing to know if your rule updates failed? It is good to "know" that, but I do not want my config management system catching this "change". It is not a configuration change but a component state change. Could it be stored as a global variable accessible to any component? The download fails a bit more often than in your system. Zsolt