Enforcing DNS security by selecting servers through port-forwarding

Enforcing DNS security by selecting servers through port-forwarding

With lots of different devices now using our networks, we would like to keep them safe. We can prevent users from being a risk to themselves and others while attached to our system. Especially if we are offering Wifi services via the captive portal on a .

Being able to corral the DNS requests to a known (and preferably sanitising) DNS server would be useful. We can ensure that nefarious sites are not reachable via DNS and helps reduce the risk to our guests. Let’s look at how we can deliver this.

We’ll perform NATting of DNS traffic from the Guest subnet to our local DNS server. For the example screens, we’ll use the OpnSense firewall. (The same configuration can also be applied to the firewall, as well as similar processes for other firewalls).

Set up aliases for internal and external DNS services

To make this extensible, we create a couple of aliases on the firewall. The first is DNS_Internal_, which provides the host IP addresses of our internal DNS forwarding server(s). The second is forDNS_External_Servers, which contains the IP addresses for the external DNS services to which we are forwarding requests.

Setup port forwarding for DNS traffic not already targeting our internal server

We then add a Port Forward rule on our Guest WiFi subnet. This will redirect traffic not already destined for our internal DNS servers to them. (Remember, if we have a well-behaved client, it will have picked up and used the correct DNS servers in the firstplace via DHCP).

To do match the traffic not already destined fot the DNS_Internal_Servers, by using the Invert match check box. We apply a port match on the destination for the DNS service (port 53).

Then we redirect the traffic to the DNS Servers (we can use an alias for this, and specify how to distribute the traffic). We want to keep clients on the same server to take full advantage of any caching effects that may occur.

We don’t need to provide a firewall rule for DNS here. We’re capturing all the traffic to the servers with the rule. Doing so would be counterproductive, as the firewall will drop the packets before the NAT rule kicks in.

Firewall rules to corral DNS traffic

We must remember that our local DNS server needs to access the Internet itself to perform the resolution of the names passed to it. So we allow traffic outbound from the DMZ to the Internet for the specific external DNS servers. We also need to make sure we let our responses back to our clients as well.

Next we create a rule to pass traffic from our DNS_Internal_Services to the DNS_External_Servers on port 53.

We then add a rule on the DMZ port (where we locate our DNS servers) to block queries from these to unrecognised servers. This becomes the ‘braces’ to the ‘belt’ of the DNS server forwarding configuration.

on privacy

With the upcoming requirement for , it would be good to make sure that you inform your users that logging of their DNS queries may occur. The logging can occur both on the firewall, on the DNS server itself, and with the external DNS provider as well. Check to see if there is a GDPR compliant privacy notice available from the external provider.

Options and enhancements

If you have a locally installed DNS server on the firewall, then you must set this to bind and accept queries on the localhost IP address (127.0.0.1). This then needs to be coded as the single IP address in the DNS_Internal_Servers alias, or directly coded in the port-forwarding and firewall rules.

We can also avoid the a local DNS server, and direct the traffic straight to our external servers in the , if minimising local infrastructure is a concern. In this case, we’d use the port forwarding directly against the DNS_External_Servers alias.

We could also cover the use of DNS over HTTP versions using things like the experimental DOH-Proxy.  DOH- could prevent the DNS queries not caught by our port-forwarding rules above to be captured and redirected to a safe DNS server.

I’ll leave this is an exercise for you to conduct in your own time, and for me to complete in the future.

 

John Dixon

John Dixon is the Principal Consultant of thirteen-ten nanometre networks Ltd, based in Wiltshire, United Kingdom. He has a wide range of experience, (including, but not limited to) operating, designing and optimizing systems and networks for customers from global to domestic in scale. He has worked with many international brands to implement both data centres and wide-area networks across a range of industries. He is currently supporting a major SD-WAN vendor on the implementation of an environment supporting a major global fast-food chain.

Comments are closed.