« Previous 1 2 3
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/
« Previous 1 2 3
Buy this article as PDF
(incl. VAT)