snort (SID 43687) blocks root DNS servers ?!
-
The end result 192.5.5.241 IP gets blocked.
So how do you resolve this issue then ?
I see sometimes with Sid 1-43687 enabled that none of my PCs can resolve any names and even 8.8.8.8 gets blocked!
-
You need to figure out what host is querying the .top TLD maybe increase the logging level of DNS lookups in pfSense.
Do you just run snort on the WAN interface?
-
@nogbadthebad Yes this is on WAN
All queries coming from the pfSense router itself and I force all clients to use pfSense router DNS only.
-
Enable snort on the LAN as well, you’ll see the host pre NAT.
Otherwise you just see the WAN address.
-
@nogbadthebad said in snort (SID 43687) blocks root DNS servers ?!:
Enable snort on the LAN as well, you’ll see the host pre NAT.
Otherwise you just see the WAN address.
I do have LAN enabled as well.
Looked thru logs with Destination IP 192.5.5.241 and found none.
Which is as I'd expect as no clients can do direct DNS queries.???
-
Ah I wonder if your not seeing it on the LAN as the source and destination are contained in $HOME_NET
Maybe change the logging level in the DNS Resolver advanced settings.
-
Date Pri Proto Class Source IP SPort Destination IP DPort SID Description 2018-07-03 22:35:13 2 UDP Potentially Bad Traffic 172.16.2.20 62541 172.16.2.1 53 1:2023883 ET DNS Query to a *.top domain - Likely Hostile
But I'm using the ET DNS ruleset.
-
This post is deleted! -
@nogbadthebad what command did you run to get it? via ssh assuming?
PS: I did change log level to "Query level information" and re-enabled all rules
-
You mean the txt that says ET DNS Query to a *.top domain - Likely Hostile ?
If so that was from Services -> Snort-> Alerts
-
-
@chudak said in snort (SID 43687) blocks root DNS servers ?!:
I don't see anything yet on LAN, all only on WAN.
Let's wait :)
-
-
f.root-servers.net = 192.5.5.241 guessing thats from your WAN interface.
Or your hosts directly query f.root-servers.net
-
@chudak said in snort (SID 43687) blocks root DNS servers ?!:
43687
Err that rule by default is default disabled:-
Maybe your being a bit over zealous with enabling the rules :)
The two rules do differ slightly as well:-
INDICATOR-COMPROMISE:- alert udp $HOME_NET any -> any 53 (msg:"INDICATOR-COMPROMISE Suspicious .top dns query"; flow:to_server; byte_test:1,!&,0xF8,2; content:"|03|top|00|"; fast_pattern:only; metadata:policy max-detect-ips drop, policy security-ips drop, service dns; reference:url,en.wikipedia.org/wiki/.top; classtype:misc-activity; sid:43687; rev:2;) Emerging DNS:- alert udp $HOME_NET any -> any 53 (msg:"ET DNS Query to a *.top domain - Likely Hostile"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|03|top|00|"; fast_pattern; nocase; distance:0; threshold:type limit, track by_src, count 1, seconds 30; reference:url,www.symantec.com/connect/blogs/shady-tld-research-gdn-and-our-2016-wrap; reference:url,www.spamhaus.org/statistics/tlds/; classtype:bad-unknown; sid:2023883; rev:1; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, created_at 2017_02_07, updated_at 2017_02_07;)
-
@nogbadthebad
that could be and is an answer to the initial question, alto I don't recall changing rules until recently I saw my network being blocked -
.tk domains too :)
-
You can add "top" and "tk" to the DNSBL TLD Blacklist which will prevent these alerts since the DNS request will never be answered for those TLD Domains.
-
That’s interesting, added, thx
-
@bbcan177 would it make sense to black list all top domains listed here https://www.spamhaus.org/statistics/tlds/ ?