If you haven’t already, please visit Part I of this multipart series on DNS Security. For those who are already managing an inventory list of your DNS servers, while blocking port 53 for everything else, then you are ready to start doing DNS Response Policy Zones (RPZ) to block malicious domains. In fact we don’t want to just block the events, but log them for analysis (we will get to that later).
Many federal organizations are already utilizing a managed service provider to provide DNS/DHCP/IPAM (DDI) for them. Please contact them for more information on subscribing to RPZs, performing black-holing and walled-gardens for DNS. They may already have the infrastructure available in cloud format to block, log and analyze those bad DNS queries for you at the flip of a switch.
But to simplify things, RPZ is basically a flat text file that can define the resolution of names to addresses. See below:
Now the interesting thing about how this zone file works is, that if a user to were to attempt to visit http://goggle.com instead of http://google.com by mistake. When their computer makes a query to your DNS server, it will respond by saying goggle.com is located at www.google.com, since www.google.com is still not an IP addresses, it will then perform a second DNS query for www.google.com, in which case your DNS should return the IP address of www.google.com.
Goggle.com is an example of a cyber-typo-squat, which occurs more frequently that one might suspect in an organization of thousands of employees conducting hundreds of such entries a day. Goggle.com is considered an infected web resource by many security devices, but should not cause harm to your computer if you were to test your DNS by performing an nslookup on it in your CMD prompt.
If you successfully received an IP addressing looking like: 18.104.22.168
Then your DNS did not protect you and you would be left relying on the security of your proxy and Anti-Virus to protect you against goggle.com.
In the other example, if a user to attempt to visit the malicious domain “evil.bad”, the DNS server would respond with the IP address 127.0.0.1, which is the local-loopback, preventing any communication with the evil.bad domain. We can later replace that 127.0.0.1 address with the address of a walled-garden server, which would intercept the request, logging and then alerting on any malicious traffic.
Creating and managing a Policy Zone can obviously be very demanding, but luckily there are multiple free resources and zones out there that you can set to automatically subscribe to, or manually feed into your own zone files which can be as easy as setting this configuration ( with rpz.provider.com being replaced by the actual server):
Despite the efforts of dedicated security professionals who specialize only in domain black-listing, there have been rapid increases in the amount, scale, and innovation by adversaries to operate from domains that escape the RPZ blacklists on a daily basis. One unique option that is not currently offered as a service from other providers is a Top Level Domain Blacklist (TLD). TLD are the ends of domains, such as .biz, .me, .info. It can obviously be very risky blocking the entire TLD, as many legitimate websites will be blocked along with it. Despite this, we have observed great success with Federal organizations who tailor their own custom RPZ lists for TLD that fill the gaps that other RPZ lists or Proxy URL categories miss.
Such as inappropriate sites:
Or hidden domains associated with crime, hacking and viruses:
For the full .TLD RPZ blocklist, please contact 1-Source to get a free copy.
Establishing and then integrating these multilayered DNS security services can be difficult, so we encourage readers to reach out to 1-Source for more information and consultation regarding implementing cyber security in their organization.