@chudak said in snort (SID 43687) blocks root DNS servers ?!: @bbcan177 would it make sense to black list all top domains listed here https://www.spamhaus.org/statistics/tlds/ ? Its not a one-size-fits-all... Most of those TLDs most users will never need to access, so I would see little issue. There is also the TLD Whitelist, where you can allow some specific domains thru that are being blocked via TLD Blacklist. There is also this TLD list: http://toolbar.netcraft.com/stats/tlds

This happened to me, and I tried: DID NOT WORK: Forcing updates to get new MD5 hashes. Some updates had failed, and this made the "Result" Success again. However, the non-starting symptom continued. WORKED: Change the time of the day when updates occur. This did the trick for me, and I haven't had any problems since. Not sure exactly what the problem was, but the non-starts were occurring on only one of the scheduled update times. It was 0:05 and 12:05, changed to 8:45 once a day and have had no problems for two weeks now. I'm changing it back to two updates a day, but keeping 8:45. Hope it works.

@trumee I think we ended disabling the entire stream-events.rules ruleset to avoid these errors. IIRC if you are in legacy mode the packets can be scanned out of order and trigger false positives.

It would be interesting to keep a forum sticky as to what hardware this works for people on, I have the Intel i211AT on the pcengines APUC4

Nobody has an idea to help me?

@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)