Periodic since 2.2 pages load blank, certs invalid
-
There are just too many ways to mess with DNS especially if you can't trust the network between your machine and the servers. In the end, at best you can really only make sure that the guys playing games with your network aren't common criminals because you don't own the root servers.
But I'm asking about this specifically, I need to know if what's been happening could be due to an infected machine elsewhere on my network, or if it's definitely happening due to something from WAN and beyond.
-
I don't think one machine on the network could be the problem (unless that machine is pfsense its self), at least in my case, or going to unbound+DNSSEC would have made no difference.
-
If you were affected by this, what part of the world are you in? Just curious. Interesting incident.
-
I don't think one machine on the network could be the problem (unless that machine is pfsense its self), at least in my case, or going to unbound+DNSSEC would have made no difference.
I just double checked and it looks like I never enabled DNSSEC when I changed to unbound. Does that change your answer at all?
(needless to say, it's getting turned on now)If you were affected by this, what part of the world are you in? Just curious. Interesting incident.
North East USA.
-
How about this - I will show you where the pfsense is sitting. Hows that? Check PM
-
-
The pfsense in question is in Maryland, for me.
-
By the way, I can confirm for sure that pfsense was seeing the bad DNS.
I have an alias for facebook.com
I saw this in the resolver logfilterdns: adding entry 195.22.26.248 to table Social_Test on host facebook.com
195.22.26.248 is the bad IP. PFSense itself saw that when it did its update on the alias resolution.
-
https://www.virustotal.com/en/ip-address/195.22.26.248/information/
https://www.robtex.net/en/advisory/ip/195/22/26/248/
Seems like there is an associated IP block thats pretty much into everything bad.
-
https://www.virustotal.com/en/ip-address/195.22.26.248/information/
https://www.robtex.net/en/advisory/ip/195/22/26/248/
Seems like there is an associated IP block thats pretty much into everything bad.
I don't doubt that, but that doesn't answer the question as to how when using google dns and level3 dns with unbound, that legitimate sites started resolving to this IP range, unless I'm missing something.
-
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.org
or
ns3.csof.net
The 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.org
or
ns3.csof.net
The 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?
-