Category: BIND

BIND Response Policy Zones

On June 10, 2020

In BIND, Domain Name Service, Response Policy Zone

Domain Name Service

Accessing resources across the internet is done through the use of IP addresses. When trying to access your email, Google for searching, or your favorite social media outlet, you are making a connection to the their IP address. The Domain Name Service (DNS) converts a name to an IP, allowing you to easily remember your favorite website. For instance, DNS will covert www.amazon.com to 89.187.178.56. How could we use BIND and DNS to thwart the bad guys?

Response Policy Zones

One of the best, unknown features of BIND is its use of Response Policy Zones (RPZ). RPZ’s allow an administrator to re-write a DNS query and send it back to the user. In the example above, when a user goes to access Amazon, DNS converts a name to a number. Once the web browser knows that number, it then reaches out to the server to access its resources. What if we were to manipulate that number, or make it where Amazon did not exist to our users?

This is where the functionality of RPZ’s come in. By configuring BIND to receive a DNS recursive lookup and manipulate the response back to the user, you can effectively stop users from accessing malicious sites.

Let us look at the recent privacy and security concerns related to Zoom. Due to its popularity and ease of use, the Zoom video conferencing service has not become a front runner. Not only has Zoombombing, where an uninvited user gains access to your video sharing stream, become a headache for the service but so has phishing websites. Recently, URL’s listed as zoompanel.com and zoomdirect.com.au have sprung up. These websites are used to phish a users Zoom credentials. We can use RPZ’s to block company personnel or home users from accessing those websites, mitigating the attack.

How Do RPZ’s Work?

When properly configured, a BIND RPZ file will return a different IP address than the one that is published on the internet. The following will return a valid IP address for zoomdirect.com.au.

nslookup zoomdirect.com.au 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: zoomdirect.com.au
Address: 119.81.45.82

The query responded with the IP address of 119.81.45.82.

What does a RPZ response look like?

nslookup zoomdirect.com.au ns1.svarthal.net
Server: ns1.svarthal.net
Address: 45.19.203.68#53
** server can’t find zoomdirect.com.au: NXDOMAIN

From the example above, the response changed from 119.81.45.82 to NXDOMAIN. This means that the response came back with nothing, making the phish server non-existent.

DNS Architecture

By jason

On April 10, 2020

In BIND, Domain Name Service

Deploying a local BIND DNS server for an organization can be quite daunting. There are a multitude of options available within the configuration of the service. Though secure configurations are extremely important, one must not overlook how to architect its set up within a network. Architecting the service correctly from the start will ease configuration headaches further down the road.

Network Segmentation

Network segmentation must be considered when standing up new systems. Segmentation is performed through the use of a firewall or proxy device which restricts network traffic. This restriction provides necessities by blocking unused protocols, access to network ports, and access from systems and services outside of the segment.

To segment services properly, an organization can either segment individual systems from each other or by creating a Community Of Interest (COI). A COI is the combination of like systems within a network segment. For example, a DNS COI is the creation of a network segment where all of the organization’s DNS servers reside. Though this is not as secure as segmenting each DNS server away from each other, this is more secure than placing all systems within the same, flat, network segment. Architectural diagram is shown below:

Primary DNS

When deploying any DNS service, whether it is BIND or a different system, the primary DNS server must be as secure as possible. The primary server is the source of all your DNS naming information. If someone were to gain access to this server, or if the system is misconfigured, they would have the possibility to change DNS records which would allow the attacker to redirect users to phishing sites. This is why an organization must deploy two or more secondary servers.

Hidden Primary

In a hidden primary configuration, the primary DNS server is never exposed to anyone. The organization configures its DHCP server to advertise the secondaries and not the primary. Firewall rules restrict DNS traffic to only the secondary servers and disallow anyone from accessing the server outside of the IT department. This is to limit the exposure of the primary server. By not advertising the primary server, it further reduces the amount of information gathered by a potential attacker.

Secondary DNS

As the primary server is never advertised to the users, or the public, the secondary servers are exposed. These servers receive naming information from the primary server and are configured to allow lookups. Firewalls or DNS proxies must be configured to only allow DNS traffic to traverse the network and limit the number of requests, preventing certain types of attacks.

The hidden master architectural concept is not something new, however it is not well known. By limiting the exposure of the master server, allowing users to only access the secondaries, prevents a number of attacks an organization could face. This is an important initial step when planning for an initial DNS deployment, or redeployment, of the service. Getting this right starting out will help secure the rest of the configuration down the road.

BIND And DNS-Over-HTTPS

By jason

On September 9, 2019

In BIND, Domain Name Service, Privacy

Privacy and security professionals have been pushing for encryption of internet traffic for many years now. Not only has there been a significant push from the privacy community, search engine giants like Google almost force websites to use encryption to increase search engine optimization (SEO) to drive higher results. Though the costs of purchasing Transport Layer Encryption (TLS) can be quite expensive, open source projects such as Let’s Encrypt allow anyone to create a publicly acceptable TLS certificate for free. These certificates are accepted by major browsers, without throwing warnings, and protects the privacy of the user accessing the site. This only resolves half of the problem.
In a recent article released by the Electronic Frontier Foundation (EFF), DNS is one of the biggest internet privacy issues facing home and corporate users. In its current implementation, DNS relays queries in clear text. This allows Internet Service Providers (ISP’s), or anyone inline of your internet traffic, to look at DNS queries and begin to build a profile on you.

Why is this a problem?

Prior to accessing a website, regardless whether or not it uses encryption, your computer performs a DNS lookup to find the IP address of the website you are trying to access. For instance, a simple DNS request to look up where cnn.com resides goes out over plain text for anyone to see. Then once the computer knows the IP address it is supposed to be access, the web browser makes a request to the website over a TLS connection.

A person sniffing the traffic may not at that point know the contents of the website you are looking at, the individual however does know that you accessed cnn.com. As you might imagine, this is a significant privacy issue where an ISP or the like can then build a profile on you and sell it to third party marketers which can then target ads.

Solving it on the individual level

There are plenty of tools out there that individuals can use to protect their internet traffic. From applications which can be loaded on a computer or smart device to the use of VPN’s and Tor, these can all protect a specific person. What if you wanted to protect a household or an organization? Use of individual applications would be cumbersome to have everyone use individual applications.

BIND with DNS-over-HTTPS

One such was to do this is to set up a Bind DNS server. This will allow everyone in the organization to perform DNS queries and have those queries safeguarded from data mining. However this still allows someone to sniff DNS queries as they are sent in clear text. To overcome this problem we need to install ‘cloudflared’ on the server. The cloudflared service will then perform DNS-over-HTTPS queries, encrypting your internet traffic from the Bind server to Cloudflare’s DNS resolvers. This prevents anyone from sniffing your DNS traffic, allowing for additional anonymity on the internet.

Getting your system ready

First you will need to install and configure Bind on your server. Once that is complete, download and install the [cloudflared][cloudflared] application on the server. After installation you will need to make one minor change to the forwarders section in your `named.conf.options` file. First, remove the comments in front of forwarders, these will be in the form of double forward slashes – //

Next, add the port number to the loopback IP address. The configuration will then look like:

`forwarders { 127.0.0.1 port 54; };`

After that, load up Wireshark and take a look at the traffic. You should no longer see the DNS protocol being used as everything will be running over TLS.

Am I fully protected now?

No. Though you are one step closer, you still need to ensure that you are performing your due diligence when accessing websites on the internet. Be careful when accessing websites that do not use encryption, especially when typing in your username and password. Use multifactor authentication in addition to a password manager and always double check the website you are accessing.