ET DNS Query for .to TLD from internal IP to gateway. False Positive?
-
@rasputinthegreatest said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?:
Hey guys. I enabled DoT today in pfsense and also some Snort categories for DNS. Now I got this message from my laptop querying a .to TLD but destination is my firewall on 192.168.1.1. The laptop should be fine and has no malware afaik. Port 53 shouldn't be used if I setup DoT shouldn't it? The laptop is using Chrome as a browser. Any ideas what this could be or if there is a misconfiguration somewhere? If I check 1.1.1.1/help it tells me DoT is working. But when I visit cloudflare.to I can trigger a port 53 alert.
2 UDP Potentially Bad Traffic 192.168.1.11 61627 192.168.1.1 53 1:2027757 ET DNS Query for .to TLDA client in your network (whatever device has IP address 1912.168.1.11) made a routine DNS request to your firewall at 192.168.1.1 on port 53. I assume 192.168.1.1 is your pfSense firewall's LAN interface. The ET Info rules category is simply meant to be informational. None of the rules triggered there automatically mean "bad stuff". It's simply something the rule author thought a security admin might want to know about when it happens.
DoT typically happens between the DNS Resolver (
unbound) on pfSense and the Cloudflare DNS server that is the forwarding destination. DoT does not routinely happen between your LAN clients and pfSense unless you make specific configurations changes on each LAN client that you wish to use DoT. Your LAN clients ask pfSense for DNS info, and apparently you have pfSense configured to forward those requests to Cloudflare. It's that forwarding traffic that happens over port 853 (DoT). The traffic from your LAN device to pfSense will happen on regular port 53 for DNS (unless you make configuration changes on each LAN client). Since you state you "visited" that domain (or attempted to), you generated a DNS lookup request to theunboundresolver on pfSense over port 53, and that's what the rule triggered on.You may want to review and research further on the distinction between DNS resolving and forwarding and how DNS clients operate as opposed to DNS servers. IDS/IPS has a steep learning curve to become proficient
. -
@bmeeks Yeah it is a steep learning curve for sure. Thank you for telling me the difference. Is there a way for client to use port 853 from the start? I indeed setup the forwarding inside pfSense.
The strange thing is that when this alert happend the laptop didn't visit any .to website. It was just a *.de website. When I triggered it I purposely visited cloudflare.to to see if the rule works. But the client that first triggered it didn't visit .to. Can it be like an ad embedded inside a website causing this or something like that? -
Another thing I saw in pfTop were these strange IPs.
192.168.178.42 is my WAN connection since I run double NAT. These IPs belong to Afilias Inc. which I never heard of and it happens on Port 53. Is this something to be concerned about? From what I can tell they are used for Trojans. Hard to find any information on this.tcp Out 192.168.178.42:56832 199.19.56.1:53 FIN_WAIT_2:FIN_WAIT_2 00:00:47 00:01:13 12 1362
tcp Out 192.168.178.42:34338 199.19.54.1:53 FIN_WAIT_2:FIN_WAIT_2 00:00:47 00:01:14 12 1344
tcp Out 192.168.178.42:31646 199.19.53.1:53 FIN_WAIT_2:FIN_WAIT_2 00:00:47 00:01:14 12 1332 -
@rasputinthegreatest said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?:
Is there a way for client to use port 853 from the start?
This will require specific configuration on a per-client basis. You have to set up the DNS client executuable that is part of each client's operating system to have that client use DoT. For example, here is a guide for doing that on Windows 11: https://www.elevenforum.com/t/enable-dns-over-tls-dot-in-windows-11.9012/.
You would need to make this change on each individual LAN client, and the steps are different for Linux clients versus Windows clients. Then you will need to configure the DNS Resolver on pfSense to listen for DoT traffic on TCP port 853. All of that is a lot of work for very little gain in my view. Why not just let your clients talk plaintext DNS over UDP port 53 to the DNS Resolver on pfSense? You can then configure the DNS Resolver to forward those requests on to Cloudflare via DoT on port 853 if desired.
Personally, I would simply let the DNS Resolver on pfSense do all the resolving and forget completely about forwarding to an external host. Why send them all your DNS traffic unless you specifically want some type of filtering they might offer such as for adult sites, for example.
-
@rasputinthegreatest said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?:
It was just a *.de website. When I triggered it I purposely visited cloudflare.to to see if the rule works. But the client that first triggered it didn't visit .to. Can it be like an ad embedded inside a website causing this or something like that?
Your browser is going to see a lot of hostnames when loading a web page for display. It is going to have to resolve each of those hostnames (URLs, actually) into an IP address by performing a DNS lookup. So yeah, it's very possible some ad server or other URL embedded within the code for that web page caused the domain query in question.
I think you are being too paranoid here
. Every alert is not a trojan. Simply keep your client boxes patched and updated with the most recent security fixes, and be careful what you click on inside emails, and you will be fine. I support and maintain both of the IDS/IPS packages available for pfSense, and I have not run either package on my home network firewall for years! They consume too many resources for basically zero gain when talking about home networks. 90% plus of network traffic today is encrypted, and unless you run a full MITM proxy interception scheme, the IDS/IPS is blind to nearly all of the packet payload because of the encryption. And the payload is where most of the bad stuff would be yet the IDS/IPS can't even see it due to the encryption.As a home network user, I am certainly not a target of criminal gang hackers or nation states that are looking for something to steal. Perhaps they might like to use my LAN for a spam bot or DoS bot, but that's about it. Now, if I am protecting the assets of a major commercial enterprise things change significantly and IDS/IPS and other technologies are worthwhile. But let's also be realistic -- if I'm in charge of cyber security for a Fortune 500 U.S. or global corporation, I'm not going to be using open-source software as my sole perimeter defense. I'm going to be paying major 5 or 6-figure sums annually to one of the security "big boys" for cradle-to-grave 24x7 support and hand-holding
. -
@bmeeks First of all thanks for the explaination. I think I keep it the way it is then and it seems like more work than it's worth.
@bmeeks said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?:
I think you are being too paranoid here
And you are right. I think this is kind of the trap you fall into when getting into networking as home user. You see all these IPs and can't really identify if anything is bad traffic or not and you become paranoid. But it is really interesting to learn about.
It is probably overkill but I like to understand what I am doing as best as I can before I expose any services to the outside world. I want to be able to run a NAS and access security cameras if I am on business trips and have all the right tools in place for that -
@rasputinthegreatest said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?:
before I expose any services to the outside world.
Don't ever do this, and you will be totally secure (well, so long as you keep internal hosts updated with security fixes and follow generally accepted cautions when opening email attachments).
Problems have a way in once you configure your firewall to allow any unsolicited inbound traffic from the Internet. But there is really never a good reason to do that. With the advent of technologies like VPNs and Tailscale remote access and site-to-site solutions, why would you ever open a home network up to unsolicited inbound Internet traffic by doing something like a port forward?
-
@bmeek I am having another issue right now that is strange. Google sometimes doesn't work at all and github as well. Google doesn't load at all and Github partially shows the website. But as soon as I turn on a VPN the websites resolve just fine.
I found this reddit thread and it describes exactly the issue I am seeing. It happens a lot on Wifi from what I can tell.
https://www.reddit.com/r/PFSENSE/comments/1bzjqnz/pfsense_randomly_blocking_google/
One guy comments:
Could actually be on the ISP side. They could block or redirect port 53. Also heard about a kind of DNS highjacking but not sure how that would technically work. Have you tried routing everything through a VPN or using DNSCrypt?How can I troubleshoot this issue? I have setup DoT on my ISP router and inside Pfsense. Could that collide? I also noticed in the Firewall logs that these two IPs get blocked constantly:
34.120.237.76 -> 2938 blocks
2600:1901:0:e988:: -> 2900 blocksAre these legit IPs and that's why stuff is not loading? I think those are only Mozilla Firefox Sync IPs so it should not be the reason
-
@bmeeks said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?:
Don't ever do this
But for a VPN like Wireguard I still need to open one port. I did that in the past but it felt unsecure so I stopped using it. On my first trials with Tailscale I saw many error messages in the log.
-
@rasputinthegreatest said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?:
@bmeeks said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?:
Don't ever do this
But for a VPN like Wireguard I still need to open one port. I did that in the past but it felt unsecure so I stopped using it. On my first trials with Tailscale I saw many error messages in the log.
VPN connections are secured with a key and not a password. Long 256-byte cryptographic keys are considered very secure. They are much more secure than passwords. Having the VPN port open is not a big security risk because of the certifcated-based authentication. That's much different than say opening up port 3389 for Windows RDP or port forwarding non-authenticated generic connections.
