Blocking Dynamic DNS update attempts via FW-1 custom INSPECT

[joelmoses]

Thought I'd share this because it came in handy for us.

We had an issue where we wanted to allow DNS queries from our internal network, but had a problem with DNS updates going to sites that didn't want them from some misconfigured internal clients. DNS updates, of course, are actually carried as a DNS query with a specific "update" flag. One of our internal folks decided to set up a "test" zone using a domain name that, unfortunately, did not belong to them. The DNS updates went to the "real" site, which became quite annoyed by the traffic.

The following configuration will block all DNS update attempts, but allow DNS queries to pass without issue. It requires DNS UDP (query) traffic to be set to "Before Last" or "Last" in Global Properties/Firewall.

1) Create a service of type "Other".
2) Name the service "dns_udp_update", with an IP protocol of "17".
3) Click the "Advanced" button.
4) In the "Match" field, enter the following: "(([9:1]=17) and ([23:1]=53) and ([30:1]=0x28))"
5) Click OK and OK to save the new service object.
6) Add a rule to DROP traffic from your Internal network to the Internet using this service just above the rule that you use to accept DNS UDP (query) traffic. You can set the rule to log if you wish to track DNS update attempts.

Hope someone else gets some use out of this. I understand that this may actually be done by SmartDefense at some point (blocking of specific query flag traffic), but this does it now and with pretty much any version of FW-1.

[RobertGraham]

Nice work - that's very helpful indeed.

Along those lines though, I would add that in light of the numerous malicious tools hiding their evil payload on port 53 as well as other problems related to DNS-reply amplification attacks, it's a good idea to consider having an internal caching server that is the only host allowed to access the Internet for DNS. This reduces queries over the firewall and can lead to a more secure policy. It's also easier to control other DNS related things as a result.

[joelmoses]

Thanks for the compliment!

That's a good point. It's not an optimal configuration to have anything other than a DNS cache to relay requests outside the network, but it's a configuration I know lots of places have (you can thank Microsoft for making AD so DNS-heavy and for lots of "appliance" hardware for requiring direct DNS access rather than using servers). Using UDP DNS protocol enforcement and some of the DNS security features in R60/61 makes things a bit more "safe".