PfSense sourcing unencrypted DNS traffic
-
Hi Folks,
Got a few of these great firewalls running and just doing some tidying up to make things a little less noisy. Only basic things no fiddling with code.
It would appear, and I could be a dumbass and have missed something simple, that the PfSense is locally sourcing various DNS requests and sending them unencrypted to the configured DNS servers in System->General Setup-> DNS Server settings, irrespective of those entries being for TLS DNS servers.
If I block UDP 53 out at another point, as should be possible(?) as I prefer DNS over TLS or similar, pfsense errors on the dashboard, system->update and available packages as one may expect if no DNS resolution available.
These sessions show up in Diagnostic->state and a pcap of the WAN interface. DNS resolution is sought for at least the following and perhaps more:
- pkg.pfsense.org
- ews.netgate.com
There also appear to be a few reverse lookup which I would like to understand a little further.
Reverse lookups for at least
- configured mandatory time server System->General setup->localisation . I would like to disable this and use a local NTP server with GPS.
- 8.8.8.8 and 8.8.4.4 - Google - Any reason why, surely this must be my stuff up?
Would it be unreasonable to seek to make the firewall as quiet as possible? Am I missing something simple perhaps?
cheers
-
@pfuser000 normally pfsense should only ask itself, ie unbound for stuff it wants to resolve, like checking if there is an update.
But if that does not answer for some reason, unbound not running restarting at that moment then yeah it will check any other dns you have listed in dns servers. Which would be in the clear just normal dns.
You should make sure you have 127.0.0.1 listed in the dns servers. So pfsense can use unbound to ask via dot, etc ..
And if you don't want pfsense to fall back to the other servers you have listed, you should set this option to ignore remote
-
@johnpoz That is a superb answer, thanks very much. The state and pcaps are looking good.
Musn't forget to enable the resolver on the localhost i/f.
Any thoughts on the reverse lookup on google?
Just thinking aloud. I wonder if there may be undocumented NTP protocol vulnerabilities. I appear to have had my firewalls owned through NTP. I just rebuild them and moving away from NTP externally.
-
@pfuser000 said in PfSense sourcing unencrypted DNS traffic:
Musn't forget to enable the resolver on the localhost i/f.
That would be enabled out of the box there would be no need to do something, unless you changed the default.
-
@pfuser000 said in PfSense sourcing unencrypted DNS traffic:
Any thoughts on the reverse lookup on google?
not sure where you asked that question - what are you wanting to do or have a question?
Pfsense shouldn't be doing any PTR queries, unless like clicked an IP in a firewall log or something. Or your running something else, I think the ntop package can do PTR queries.
As to NTP - how would you have gotten owned with that, and 2nd why would it be open to the internet, that again is not something that would be open to the public internet out of the box. Out of the box all unsolicited inbound would be denied
-
@johnpoz Thanks for your reply's again.
NTOP it may be. Config update seems to have cleaned them up.
Regarding NTP. I defer to you, probably a poor observation my end.
-
@pfuser000 why/how would you think your pfsense box was compromised in some way?
Had you opened up something on the wan? did you leave the password as the default pfsense, after opening up your gui on the wan?
-
@johnpoz good questions, thanks for the interest.
Simplest answer at this point is nothing to be overly bothered by from pfsense perspective, it's something I'm looking at but probably won't get to the bottom of it. Had some uninvited guest lurking around for a while. Could be using a logon/ssh from the inside / mgmt.
To answer your questions another way, a few CCIEs and security qualifications and around 30 years experience, which makes me old and a lot slower than I used to be and I don't mind being wrong regularly these days.
Thanks for your awesome support today, a great reflection for the product.
Kind regards
