DNS request to Anubis sinkhole on WAN but not on LAN
-
Perhaps I'm doing something wrong here, but in the past couple of weeks I've had numerous Snort hits on WAN similar to the following:
2020-02-09
15:10:29 1 UDP A Network Trojan was Detected 3.87.22.163
53 xx.xx.xx.xx
53921 1:2018455
ET TROJAN DNS Reply Sinkhole - Anubis - 195.22.26.192/26My setup is as follows:
Unbound resolver handling DNS requests
All DNS from LAN is redirected to pfsense via NAT
In Firewall rules, port 53 is allowed to LAN and then blocked to everywhere else.I do not see any flagged DNS traffic on the LAN side of snort.
Any idea what I'm missing here? I want to make sure I'm not compromised somewhere but I'm not sure where to look.Thanks in advance.
-
Think about your setup for a second. What did you say was handling all DNS requests?
Hint - you said DNS Resolver (or
unbound
).Where does the DNS Resolver reside?
Hint - on pfSense.
How does the
unbound
resolver find an IP for a domain?Hint - it must talk to the root servers via the WAN interface to locate the authoritative server for the domain.
Okay, now a question I don't know the answer to. Are you running another package that logs stuff such as maybe pfBlockerNG or pfBlockerNG-devel? If so, then likely that package is asking the resolver to resolve the address so it can write the domain name to its logs (a reverse PTR lookup). Since all of that would be local to the firewall, it would not show up on your LAN interface. The DNS resolvers communications with the root and authoritative servers would happen via the WAN. Something similar to this has come up before where other third-party packages installed on the firewall were triggering DNS alerts in Snort or Suricata from the
unbound
resolver on the firewall.I am also assuming, based on your description of your concern, that you have Snort configured exactly the same on WAN and LAN (meaning the exact same enabled rules). If that is not the case, then you may not be seeing the alerts on the LAN because the required rule is either not enabled or is suppressed on the LAN.
-
Thanks for the reply.
Yes, I do have the same rule configuration on LAN as on WAN, and yes, I am also running pfBlockerNG.
I guess my concern is trying to figure out what is getting the request made to begin with, and trying to ensure that I do not have a compromised machine inside my network.
I was thinking of trying to run packet capture for awhile on port 53 of LAN to see whether I can locate the host from which the request originates.
Any better thoughts? -
My best guess is it is simply pfBlockerNG doing a reverse PTR lookup to find the corresponding domain name, and that lookup is triggering the Snort alert. Since pfBlockerNG runs on the firewall, DNS Resolver (
unbound
) would perform the lookup by going directly out to the WAN. In that scenario, nothing would ever have need to cross your LAN interface because all the traffic is internal to processes on the firewall, and thus that Snort instance sees nothing to alert on.In summary, it is most likely harmless. If it bothers you, you can see what a packet capture on the WAN shows. My guess is it will show
unbound
on the firewall doing a lookup and that's it. The "SRC" will be the firewall itself.Similar behavior has been posted before (several months to maybe more than a year ago) and the culprit was simply a package on the firewall attempting to get a domain name for an IP address so it could write the domain to its log file. Harmless behavior.