DNS Security & Vulnerabilities: Part 4?-?Staying Secure with Domain Policies, Response?Actions along with Firewall rules and Threat Detections.

Online is scary right? What are the ways to stay safe and protect our networks from attacks?

RPZ or Response Policy Zone.

Domain Name Service Response Policy Zones (DNS RPZ) is a method that allows a nameserver administrator to overlay custom information on top of the global DNS to provide alternate responses to queries. It is currently implemented in the ISC BIND nameserver (9.8 or later). Another generic name for the DNS RPZ functionality is “DNS firewall”.

The prime motivation for creating this feature was to protect users from badness on the Internet related to known-malicious global identifiers such as host names, domain names, IP addresses, or nameservers. Criminals tend to keep using the same identifiers until they are taken away from them. Unfortunately, the Internet security industry’s ability to take down criminal infrastructure at domain registries, hosting providers or ISPs is not timely enough to be effective. Using RPZ, a network or DNS administrator can implement their own protection policies base based on reputation feeds from security service providers on a near-real-time basis.

Examples include:

• If one knows a bad hostname or domain name, one can block clients from accessing it or redirect them to a walled garden.
• If one know a bad IP address or subnet, one can block clients from accessing hostnames that reference it.
• If one knows a nameserver that doesn’t host anything except bad domains, one can block clients from accessing DNS information hosted by those nameservers.

Policy zones published by a multiple providers (see below) can be checked in order before a normal answer from the global DNS is used. White lists can also be maintained by a local administrator to prevent false positives for key infrastructure.

In a nutshell it looks something like this:

Blocking Bad DNS

How does one implement something like this?

There are many options out there, but the key take aways are you need to redirect all your clients to your DNS server. This can be done by adding Option 6 — DNS server option. It specifies the DNS server IP address to be assigned to the clients.

From there, lets make sure that DNS cannot be bypassed. In many cases DNS servers can be statically assigned which bypasses our protection.

Firewall

This firewall rule with a default drop all if not matched, ensures that clients going to our DNS are allowed and then that our DNS Servers are allowed to dial out to the root servers.

Now if any devices tries to dial out on DNS on normal ports, they are blocked. This stops a majority of issues and bypass attempts.

DNS Server

Once we have the Firewall ACL in place, we can move on to using a DNS Server. There are many options, some of the common free ones are Pi-Hole and AdGuard. These allow you to easily add block lists that are updated automatically with the latest threats or sites that may be breaking your network policies.

The hard part here is the blocklists. They are not all created equally. There are paid and free and each maintainer has their own set of ideas and standards how each of their lists should be made. Each list may be a specific category like privacy, ads, malware, ect…

In many cases, these blocklists can block legit websites and 3rd party sites needed by these main websites. Keep this in mind if you deploy to a production environment. Using smaller and more fine tuned lists work best for less overhead, faster responses and less likely of blocking a legit website.

Keep in mind, you can also use services like OpenDNS which will manage lists for you. This may also be an option for you, but these type of servers may give you less control over allowed/blocked domains.

Next Steps — Threat Detection

Now that we are using our own DNS server we can start to detect threats. Depending on the server you are using or where you log DNS Queries, we can use these queries to find machines making calls to questionable domains. Even if the domain is blocked, we may want to know why a machine is making a call to even an old IOC or bad domain.

We can also go a step further and look for machines making DNS calls to other DNS servers besides our or DNS servers sending calls out that are not ours. This can also be a sign of malicious activity or a device being added and used that we are not aware of.

Conclusion

Hopefully this gives you some ideas and tips on how to secure your network from the DNS side by using ACL.

While this briefly touched on this subject from a high overview, there will be more dedicated videos and articles that go more in-depth on these subjects along with step-by-step deployments.

—

? Like what you read? Did it help?you?

Send some coffee and love https://buymeacoffee.com/truvis?:) Your support helps pay for licenses, research & development, and other costs that allow me to bring you new guides and content!

?If you are new to my content, be sure to follow/connect with me on all my other socials for new ideas and solutions to complicated real world problems and jump start your career! New content drops daily/weekly along with tips and tricks?:)

?? W: https://truv.is

?? T: https://twitter.com/thattechkitten

?? Y: https://www.youtube.com/@TRUValueInformationSecurity

?? G: https://github.com/truvis

?? L: https://www.dhirubhai.net/in/truvisthornton

?? M: https://medium.com/@truvis.thornton