Using DNS RPZ to Protect Against Malicious Threats

Estimated Reading Time: 6 minutes

As discussed in a previous blog, DNS RPZ provides IT teams and network administrators with a “DNS configuration layer”, or rewrite module, to effectively handle DNS responses with the open source domain name system software, BIND. RPZs can be used to block identified malicious sources or rewrite/redirect other DNS responses based on customizable response policy zones (RPZ). This additional layer of configuration provides flexibility to augment DNS filtering and protections with curated feeds and lists—such as identified malware-infected hosts, phishing sites, command and control (C&C) servers, and other malicious sources.

As a recap, here’s a diagram overview of how DNS RPZ works with your local BIND DNS server:

[dt_fanchttps://zvelo.com/advantages-of-rpz-basics-common-configurations/y_image type=”from_url” image=”https://zvelo.com/wp-content/uploads/2018/09/dns-rpz-how-it-works.jpg” image_dimensions=”1500×800″ image_alt=”DNS RPZ | How It Works” onclick=”lightbox” width=”1500″ align=”left”]

But, it’s also possible to configure RPZs in a variety of ways, to block malicious threats, redirect objectionable content requests—even restrict access to specific types of sites like social media. zvelo works with partners in a wide range of industries who leverage our leading URL Database, categorization services, and malicious detection systems—along with DNS RPZ to provide industry-leading coverage (and protection) for malicious threats.

In this blog, we explore a basic DNS RPZ implementation with three (3) response policy zones, the process of determining what domains/URLs to pull into your RPZs—as well as some code examples for configuring a response policy zone (RPZ) to block or redirect requests. Additionally, we offer thoughts on handling policies and process implementation—so that you can determine the best approach for implementing response policies.

Without the proper tools, knowledge, and oversight—DNS can serve as an open door to phishers, scammers, and other unwanted intruders. Implementing a premium DNS or web filtering solution is the first step to protecting network traffic. Incorporating configurable response policy zones can be a pivotal next step to amping up protection from online threats.

Determine Your Overall RPZ Needs

Your first order of business is to determine what RPZs to implement. This will depend on the types of content and sources you want to moderate for network access. Common RPZs include: whitelists for critical business services, blocking malicious sources, redirecting traffic to objectionable content, as well as configurations for various “Parental Controls” filters.

For example, imagine CompanyX has chosen to configure/prioritize their response policy zones as follows:

• Whitelist “Important” RPZ
• Malicious RPZ
• Objectionable RPZ

Therefore, when an initial DNS response comes back, it can be “validated” by each consecutive zone. In this way, CompanyX ensures that all requested “business critical” traffic is “whitelisted”. For all other traffic, the request is then checked against the malicious RPZ—which is loaded with all domains that have been identified as malicious or dangerous. From there, the request is checked against the objectionable RPZ to make sure the content is safe for work. Objectionable requests may include content that is violent in nature, related to terrorism, violent, pornographic, and more. If a request is not blocked or rewritten by any of these configured RPZ files, it is passed along without change to the requestor.

 

This RPZ configuration is an example of a common and basic setup, allowing you to manage the rewrite rules for requests to content/services that are “important”, “dangerous”, and “unwanted”, respectively.

More On Handling RPZs: Rewrites & Walled Gardens

Setting up custom RPZs for different threat types can have advantages such as implementing feedback loops that continuously improve your network security through security awareness training.

Let’s imagine, you wish to set up an RPZ intended solely for protecting against phishing attacks. You now have a single configuration file, into which all of your anti-phishing feeds can be loaded. This empowers you to build systems and logic to update the phishing RPZ with new threats—as they are identified and included into your feeds/lists. This configuration also enables you to organize your phishing-specific DNS handling logic in one place. Your IT team implements DNS RPZ and this phishing RPZ for protection across your networks.

Example: Now let’s pretend that an industrious employee, John, receives a professionally-tailored phishing email with a cleverly masked hyperlink to—what looks like—a reputable business site. The body of the email demonstrates a new product feature that solves a pain point in John’s department, enticing him to click the link. Interested in a way to improve the efficiency of his department, he clicks on the link (forgetting his security training) assuming he’ll be taken to visit a legitimate business webpage. Unfortunately, the phishing link opens a well-disguised Google login form designed to log keystrokes and steal credentials. It prompts him to re-enter his credentials because he’s been “logged out”. This form of phishing is surprisingly effective—even against those who are security conscious. We’re all busy and we experience hundreds of hyperlinks on a daily basis.

With your Phishing RPZ in place and loaded with the latest identified phishing sources (such as zvelo’s real-time updates against newly identified phishing and malicious threats)—John is protected, even if he clicks on the link. Instead of being taken to the malicious phishing destination, the Phishing RPZ redirects John safely to an internal policy page (or walled garden) that informs him about the threat. Your conscientious IT team has also equipped the internal policy page with instructional information and best practices to avoid phishing attacks—as well as links to security awareness training and documentation.

In this way, RPZs can be used to create training and feedback loops that help improve network security over the long term. When users are protected and informed of a near “incident”—they can better understand dangerous online habits and behaviors and learn how to avoid them.

Contact us about our malicious and objectionable datasets, or to learn more about custom RPZ configurations that address different malicious threat types and objectionable content.

Building a Response Policy Zone

Now that you’re familiar with the advantages of DNS RPZ, let’s look at building a list of sites to include in an RPZ zone. Probably the most common and protective RPZ implementation, is a Malicious RPZ that blocks requests to malicious sources—or redirects user requests. This can simply be one Malicious RPZ file that covers all malicious categories—or alternatively, you can configure multiple RPZs to handle individual malicious sources differently.

For example, the zveloDB Raw Data Feed provides a comprehensive corpus of domains across 500 categories, including ten (10) unique malicious categories. zvelo partners leveraging DNS RPZ are able to pull those malicious domains and funnel them into their response policy zones—achieving unmatched coverage, accuracy, and protection from online threats. zvelo’s malicious categories include:

• Phishing/Fraud
• Compromised and Links to Malware
• Ad Fraud
• Spyware and Questionable Software
• Malware Distribution Point
• Malware Call-Home
• Botnet
• Cryptocurrency Mining
• Command and Control Centers
• Spam URLs

 

When populating the Malicious RPZ, you’ll need to decide how to handle requests and traffic to those destinations…

The simplest method is to show a domain error notification (NXDOMAIN), but companies can also choose to send the requestor to a controlled host that can be isolated from the internet (or a Walled Garden).

To outright block a DNS Request, configure the RPZ to return an NXDOMAIN error as follows:

 

Alternatively, you can choose to rewrite/redirect the threat to a walled garden:

 

Additional Implementation Considerations

As we’ve outlined, DNS RPZ is a great way to implement basic network security at the DNS level —enabling you to protect your network from threats and traffic before a connection is ever made. Leveraging RPZ allows you to incorporate or merge any number of datasets, blocklists, and other feeds—unifying and streamline your security policies.

As with many detection methods, there’s always the chance for the wrong sites to be labeled Malicious or Objectionable—rendering false positives. This is typically only temporary, but it highlights the importance of ensuring that processes and notifications are in place to expedite recovery for business critical systems and traffic.

As with any threat and vulnerability management plan, the goal is to keep the number of false positives to the bare minimum. The value of a high quality data feed or solution, such as zveloDB, can significantly reduce the number of alerts, notifications, false positives, and touchpoints that your IT department has to manage. That equates to time and money.

Effectively, DNS RPZ has the power to protect users from malware before a connection is ever made with the network. It can be used to assign parental controls, reduce wasted time on non-work sites (social media, etc.), and even educate users about threats AS they happen.

Learn more about zvelo’s Malicious Detection capabilities.

 

Related Blogs:

• Advantages of RPZ: Basics & Common Configurations