DNS Resolver Setup / Hardening

[guardian]

My plan is to use Untangle as my system's only way to resolve DNS.

I am planning on using OpenDNS as DNS servers since they do some emerging threat screening.

To prevent malware from using it's own DNS server to "call home" or tunneling traffic over DNS I want to prevent any other traffic from leaving the network via Port 53.

I am using the DNS Resolver with the following DNS servers firewall rules:

127.0.0.1
    208.67.222.222  [All OpenDNS - which if I understand correctly use DNS to protect against for some threats ]
    208.67.220.220
    208.67.220.123
    208.67.222.123

Firewall Rules: (Capatures of the individual screens attached)
PASS  IPv4 TCP/UDP *  *  LAN address 53 (DNS)  *  none Allow pfSense to handle DNS requests
BLOCK IPv4 TCP/UDP *  *  *    53 (DNS)  *  none  Block DNS requests to anywhere else

My questions are:

• Is this strategy likely to break something?  Is my strategy for setting things up this way sound?

• Have I done the firewall rules correctly - I found them somewhere (can't remember where), and I'm not 100% as to what they do.

Thanks…

[cmb]

You want those rules on LAN, not WAN. Otherwise looks fine.

[guardian]

@cmb:

You want those rules on LAN, not WAN. Otherwise looks fine.

Thanks for that… tested and works great.  For the benefit of other Noobs like myself, I'll post screen shots for 2.3.1.

I'm wondering what the difference is between the way I have done this vs the method described here?

https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense

I tried disabling my rules a setting up this rule but all it did was break DNS for the LAN.

This is the way my DNS servers are set up:

127.0.0.1
    208.67.222.222
    208.67.220.220
    208.67.220.123
    208.67.222.123

so I assume that this condition:

'Before adding this rule, ensure the DNS Forwarder or DNS Resovler is configured to bind and answer queries on Localhost, or All interfaces.'

has been satisfied, but maybe there is something I don't understand.

The interface has changed and maybe I did something wrong and didn't set up the rule as directed.

The entries: NAT reflection / Filter rule association confused me.  Not sure if I should have done something with them or not.

[paftdunk]

I've been doing the same thing awhile, and for the same reason. The only thing that broke was my 2nd gen Ooma voip box–another 1st gen box didn't care. So I just gave its ip permission for outbound :53.

[guardian]

@paftdunk:

I've been doing the same thing awhile, and for the same reason. The only thing that broke was my 2nd gen Ooma voip box–another 1st gen box didn't care. So I just gave its ip permission for outbound :53.

Maybe one of the experts here can comment… is it possible to set up an alias in the Resolver to make these boxes with hard coded DNS servers think the Resolver the DNS server that they have hard coded.

Slightly off topic... but I'd like to do the same thing with NTP.... Is it possible to block outside access to NTP and use a aliases (or some other mechanism) to force pool.ntp.org (or whatever) to use the pfsense box?  (Using the logs to figure out what names to setup as aliases.)

[paftdunk]

Your question made me realize there's actually a much better way to do this: NAT Port Forwarding.

I set up a port forward rule to redirect all LAN originated traffic for :53 to my firewall ip. As soon as I created it, I started seeing the actual lookups my ooma was directing to their own servers.

$ dig @8.8.8.8 blog.pfsense.org
;; reply from unexpected source: 10.100.100.1#53, expected 8.8.8.8#53

[johnpoz]

" I want to prevent any other traffic from leaving the network via Port 53"

I don't really get the redirect mentality.. Why not just block it outright if that is what you want to prevent?  To me redirection of traffic is bad, you sure wouldn't like it if your isp did that ;)

Same goes for ntp, if you want clients to use your ntp then hand it out via dhcp, or set your window machines to use it.  Things that don't work via ntp will get the idea they should use the local provided one..

[kpa]

Just create a rule on the LAN interface that blocks TCP and UDP traffic to port 53 unless the destination address is one of pfSense's own addresses. Turn on logging for the rule. Make sure the rule is placed before any pass rules, job done.

[guardian]

Hi johnpoz…

@johnpoz:

" I want to prevent any other traffic from leaving the network via Port 53"

I don't really get the redirect mentality.. Why not just block it outright if that is what you want to prevent?  To me redirection of traffic is bad, you sure wouldn't like it if your isp did that ;)

What I actually wanted to do is to force pfSense to be DNS resolver for the whole network.  Still debating if I should force it to use OpenDNS servers (for malware screening) or leave the setting the way it is to actually do a recursive lookup.  I also will eventually bring in pfBlocker/Suricata which I believe net a controlled DNS as well.  Hard coded stuff just breaks so it is going to take some kind of router magic to fix it.

@johnpoz:

Same goes for ntp, if you want clients to use your ntp then hand it out via dhcp, or set your window machines to use it.  Things that don't work via ntp will get the idea they should use the local provided one..

With NTP is there an alternative?

Windows doesn't allow custom NTP servers does it?.

Also some consumer boxes have these things in firmware that aren't easy to change.  They use something.pool.ntp.org or whatever it is. 
I've been worried about some ot that traffic from a myriad of different servers of unknown accuracy from all over that may be doing something over port 123 other than NTP that I don't know about.

I've got my pfSense box talking nice to the redundant National Reasearch Centre in Canada and the time is steady as a rock within 100ms,

[guardian]

@paftdunk:

Your question made me realize there's actually a much better way to do this: NAT Port Forwarding.

I set up a port forward rule to redirect all LAN originated traffic for :53 to my firewall ip. As soon as I created it, I started seeing the actual lookups my ooma was directing to their own servers.

$ dig @8.8.8.8 blog.pfsense.org
;; reply from unexpected source: 10.100.100.1#53, expected 8.8.8.8#53

Can you please share a screen capture (or at least be a bit more specific…. I'm not clear about how you did this.  Thanks.