Periodic since 2.2 pages load blank, certs invalid
-
No idea
-
Same thing happened to me this morning: https certs signed by lolcat, all dns inquiries not handled by pfsense directly give 195.22.26.248, and using the Google DNS and Level 3 dns servers. I was able to resolve the issue for the time being by checking the 'Allow DNS server list to be overridden by DHCP/PPP on WAN' box, which presumably switched pfsense from using the compromised/poisoned DNS server to my ISPs DNS server.
I originally thought this issue was unrelated to pfsense, and posted the issue here:https://forum.pfsense.org/index.php?topic=88238.0. But after seeing this thread, it seems like pfsense 2.2 / DNS Resolver / Unbound may be a factor?
Configuration: PFSense 2.2, DNS Resolver, GoogleDNS and Level3 as primary and secondary DNS servers respectively.
-
Nope - Because the same thing was happening to me using dnsmasq…
Actually switching to unbound + DNSSEC cured it.
-
I originally thought this issue was unrelated to pfsense, and posted the issue here:https://forum.pfsense.org/index.php?topic=88238.0. But after seeing this thread, it seems like pfsense 2.2 / DNS Resolver / Unbound may be a factor?
This has nothing to do with pfSense. It has to do with you relying solely on google/level3 for all your DNS and someone is playing with it.
-
Yep… Now who could do that on a broad basis?
-
It's intriguing.
-
Actually once I switched fully to unbound + DNSSEC only, I had a new issue. At the same times, unbound would stop working. The service would be running, but it wouldn't resolve anything until I restarted the service.
I finally found a common thread for that happening. It almost always directly followed someone doing a lookup of
api-nyc01.exip.orgor
ns3.csof.netThe IP for those are in the 195.22.x range that was mentioned earlier.
Almost without fail, trying to access one of those, causes unbound to stop working until I restart the service.
If someone is willing to look at that, because of how it lines up, it looks like trying to access/doing a lookup on those domains will either cause the blank pages and lolcat certs, or will cause unbound to stop resolving until the service is restarted.
It's too coincidental to ignore in this case.
-
It almost always directly followed someone doing a lookup of
api-nyc01.exip.orgor
ns3.csof.netThe IP for those are in the 195.22.x range that was mentioned earlier.
Almost without fail, trying to access one of those, causes unbound to stop working until I restart the service.Tried both, unbound still working. :) Apparently no NSA love here. :'( ;D
-
Now, I also had block rules in place for that range of IP.
I wonder if that could interact in some way.Additionally, if you have Snort/Suricata installed, do you now have alerts mentioning the Anubis DNS Sinkhole?
-
-
!!!
-
(unbound has been enabled for more then a month without issues … until an hour ago)
i've suddenly been experiencing the blank pages + dns redirects to buydomains.com for lots of valid domains.i tried to fix it by enabling dnssec ... didn't help
for now i've enabled "forwarding mode" on unbound ... this seems to fix the issue.
-
Unbound in resolver mode? That makes no sense. The deal is is that makes it pretty much impossible to affect everything. They have to target specific name servers for specific domains (or .com, or . (root) etc..
What DNS servers are you handing out to your clients? Running unbound means nothing if your clients are going to 8.8.8.8 / 8.8.4.4 for DNS.
Want an easy way to find out? Block TCP/UDP 53 on LAN to everything but your unbound and see what breaks. :) Or pass with logging and see what's logged….
-
After you properly set up DNS and DNSSEC, you still have to clear DNS cache on each client and also have to make sure your clients are not infected with something or running some stupid browser add-on that hijacks things.
-
…. Block TCP/UDP 53 on LAN to everything but your unbound and see what breaks. :) Or pass with logging and see what's logged....
Port 53 is not allowed at my network for more than a year. Doing fine with the DNS servers in the General setup and keep awful devices such as Buffallo Linkstations etc from phoning home…
-
When it happened, all dns requests returns "195.22.26.248" as IP address (also for invalid domains):
swix@pc:~> host google.ch google.ch has address 195.22.26.248 google.ch mail is handled by 10 mx1.csof.net. google.ch mail is handled by 10 mx2.csof.net. swix@pc:~> host aaaaaafadkfjdu93jifa.ch aaaaaafadkfjdu93jifa.ch has address 195.22.26.248 aaaaaafadkfjdu93jifa.ch mail is handled by 10 mx1.csof.net. aaaaaafadkfjdu93jifa.ch mail is handled by 10 mx2.csof.net.Unbound server is set as local resolver for a small LAN, with no forwarding to remote resolvers, so everything should be resolved locally.
Still investigating about how this could happen, and I will update this thread as soon as I find anything.
Kind regards.PS: it apparently happened to last week, and I then disabled DNSSEC Support, but as it happened again it doesn't seem to be related.
-
So far happened only one time for me.
After enabling dnssec and disabling all the forwards to public dns servers it seems to be fixed.
In addition, I've created a floating rule to block every local subnet to that 195.22.0.0 range.Will keep you updated.
To be honest the strange thing is that in a couple of years of pfsense pre-2.2 and dnsmasq this never happened.
The problem appeared straight after upgrading to 2.2 and dnsresolver even tho, once again, only happened one time so far to me.Best regards
-
When it happened, all dns requests returns "195.22.26.248" as IP address (also for invalid domains):
I'd certainly investigate the LAN for possible infection. Just look at the amount of malicious crap associated with that IP:
https://www.virustotal.com/en/ip-address/195.22.26.248/information/If you have some ISP-supplied router/modem in front of the pfSense box, Google for possible well-known firmware exploits as well.
PS: it apparently happened to last week, and I then disabled DNSSEC Support, but as it happened again it doesn't seem to be related.
Disabling DNSSEC most certainly does NOT help anything. Very broken idea.
-
I'd certainly investigate the LAN for possible infection. Just look at the amount of malicious crap associated with that IP:
https://www.virustotal.com/en/ip-address/195.22.26.248/information/
If you have some ISP-supplied router/modem in front of the pfSense box, Google for possible well-known firmware exploits as well.
ng DNSSEC most certainly does NOT help anything. Very broken idea.Thanks for the suggestion, yes, I will try to have a look on this, but the network device (VDSL Bridge Zyxel P-870M) is in bridge mode, so I have no way to connect directly to it (or only via a serial console, with a cable to be found yet). Newest Firmware = 2009.
It just happened again a few minutes ago (3rd time today).
I was also trying to see if the root-servers file was tempered anyhow, but /etc/unbound/root.hints does not exist at all on the pfsense router.
Log extract when problem is happening, with many requests to "ns*.csof.net" servers where it shouldn't be the case :
Feb 9 12:55:25 pf unbound: [39509:0] info: reply from <4.85.in-addr.arpa.> 195.186.196.180#53 Feb 9 12:55:25 pf unbound: [39509:0] info: query response was ANSWER Feb 9 12:55:28 pf unbound: [39509:0] info: resolving daisy.ubuntu.com. A IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns1.canonical.com. AAAA IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns2.canonical.com. AAAA IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns3.canonical.com. AAAA IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns2.canonical.com. A IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns3.canonical.com. A IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns1.csof.net. AAAA IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns2.csof.net. AAAA IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns3.csof.net. AAAA IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns4.csof.net. AAAA IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns1.canonical.com. A IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns3.csof.net. AAAA IN Feb 9 12:55:28 pf unbound: [39509:0] info: resolving ns1.csof.net. AAAA IN Feb 9 12:55:28 pf unbound: [39509:0] info: response for ns3.canonical.com. A IN Feb 9 12:55:28 pf unbound: [39509:0] info: reply from <com.>54.77.72.254#53 Feb 9 12:55:28 pf unbound: [39509:0] info: query response was ANSWER Feb 9 12:55:28 pf unbound: [39509:0] info: response for ns2.canonical.com. A IN Feb 9 12:55:28 pf unbound: [39509:0] info: reply from <com.>54.77.72.254#53 Feb 9 12:55:28 pf unbound: [39509:0] info: query response was ANSWER Feb 9 12:55:28 pf unbound: [39509:0] info: response for ns1.canonical.com. A IN Feb 9 12:55:28 pf unbound: [39509:0] info: reply from <com.>54.77.72.254#53 Feb 9 12:55:28 pf unbound: [39509:0] info: query response was ANSWER Feb 9 12:55:28 pf unbound: [39509:0] info: response for daisy.ubuntu.com. A IN Feb 9 12:55:28 pf unbound: [39509:0] info: reply from <ubuntu.com.>195.22.26.248#53 ########## wrong ! Feb 9 12:55:28 pf unbound: [39509:0] info: query response was ANSWER</ubuntu.com.></com.></com.></com.>TBC.
-
I just want to clear up a few things
When any DNS Server can be used (not just unbound) and DNS Sec is set to off
-A DNS lookup from any computer to one of the domains cause EVERY subsequent lookup to resolve to "195.22.26.248"
(persists until unbound service is restarted)When only unbound can be used and DNS Sec is set to ON, and port 53 is blocked except to pfsense
-A DNS lookup from any computer to one of the domains causes unbound to stop resolving anything, all lookups fail
(persists until unbound service is restarted)Thanks to a packet capture I was able to find which domains were being looked up, I then overrode the hosts and set the IP to 0.0.0.0 so they resolve but obviously can't get out
When only unbound can be used and DNS Sec is set to ON, port 53 is blocked except to pfsense, AND the hosts are overrode so Unbound doesn't make any query on those domains outward either
-All problems seem to cease(Also, due to the packet capture, I can say the original request is coming from an unrooted Android device requesting port 80 on a few of those sites, based on the URL, it's requesting an API for determining the outward IP)
EDIT: here's the overrides I did to flat out prevent those names from being resolved.
