DNSSEC-aware DNS caching with Unbound

Name Game

Firewall

If configured incorrectly, DNS servers can amplify DDoS attacks. In this example, I have configured the Unbound DNS server so only computers on the LAN can use it to resolve DNS. However, it won't hurt to add another layer of defense. Because this server does not act as an authoritative nameserver on the Internet, I can block ports on the outside interface. I will block incoming traffic into the forward chain on the outside interface because Docker forwards traffic from outside interfaces to "virtual internal NICs" (bridge interfaces) via the forward chain. I will also block incoming traffic in the iptables input chain, although this step will not block any traffic to the Dockerized service.

Be very careful when messing with iptables and Docker, because Docker generates many rules in the forward chains. To minimize the chances of disruption, only add rules to the front of the forward chain (using I instead of A , and without flushing a chain). Any traffic coming into any Docker bridge from the Internet that's part of an existing connection is allowed. All other traffic from the Internet to Docker is blocked. Traffic to port 935 from the LAN and the control client is fine, and all other port 935 traffic from the LAN is blocked (Listing 9).

Listing 9

iptables Rules

iptables -I FORWARD  -i eth0  -j DROP
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -i eth0 -j ACCEPT
iptables -I FORWARD  -i eth1 -p tcp -dport 935 -j DROP
iptables -I FORWARD -i eth1 -p tcp -s 192.168.0.2 --dport 935 -j ACCEPT

Now I'll add rules to block incoming traffic to the VM itself. The rules in Listing 10 flush the input chain, block non-reply incoming traffic into the host itself on the outside interface, allow port 22 traffic from the LAN and reply traffic, and block the rest.

Listing 10

Input Chain

iptables -F INPUT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -j DROP
iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth1  -j DROP

Summary

This article described how to set up a DNSSEC-enabled recursive resolving validator using Unbound. Enabling DNSSEC will diminish the chances that you will suffer from a fishing, spoofing, or MITM attack. Although most DNS queries are not DNSSEC-protected, those of many banks and pay sites are. Overall, Unbound can help you create a safer surfing experience.

Infos

DNSSEC: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
How DNSSEC works: https://www.cloudflare.com/dns/dnssec/how-dnssec-works/
djbdns: https://en.wikipedia.org/wiki/Djbdns
NLnet Labs: https://nlnetlabs.nl/projects/unbound/about/
Pi-hole: https://pi-hole.net/
Photon OS: https://vmware.github.io/photon/
Root Canary: https://rootcanary.org/test.html
Optimizing Unbound: https://nlnetlabs.nl/documentation/unbound/howto-optimise/

The Author

Hans-Cees Speel works as the manager and security officer for youth health organizations in The Netherlands. In his spare time, he has a lot of fun tinkering with cheap but effective proof-of-concept security controls. To tinker is to learn! His first encounter with Linux was on single-floppy-disk firewalls.

« Previous 1 2 3