In my workplace, I have deployed OpenDNS Umbrella across my company network to secure and manage my DNS system. I have found that Umbrella is remarkably good at preventing unwanted behavior and protecting my corporate network from threats both outside the firewall and inside it.

All traffic destined for domain resolution must pass to two Hyper-V VM’s located in my Headquarters branch. These two virtual machines handle all requests from my entire network, including the branches across the Data WAN, facilitated by the Meraki Site-to-Site VPN mesh network that the Meraki system handles for me automatically. These two VM’s then pass all their collected queries to OpenDNS itself, where my policies about what kind of Layer 7 categories I have allowed and disallowed for resolution. Malware is the primary reason for Umbrella, as everything from viruses to trojan horses all rely on DNS to function and be clear as a bell so they can function in a harmful manner. Umbrella acts as a canary in a coal mine, messaging the admins about everything from Command-and-Control requests, to Malware requests and category violations throughout the company.

As I have been working with Umbrella, I noticed an immediate vulnerability in the way the system works. There is technically no reason why a user with a company device, or theirs even, could define their DNS servers manually and side-step Umbrella completely. Specifically, I am thinking about Google’s DNS servers at 8.8.8.8 and 8.8.4.4, although any public DNS server would work in this arrangement. It is important to include in this discussion that as an IT administrator I buck the trend against my own industries best practices, that all users are local admins of their machines. I don’t believe in “nailing down the workstations” at all. Instead, I keep my security surface deep into the domain controller and file server, a much tighter arrangement that affords end users more liberty. With the liberty comes a risk that end users could perform some action which would ruin their day. This keeps the users responsible, and it keeps what we have to say in IT more relevant than ever. We don’t keep you from ruining your day, we help you cope. I have found that users, for the most part, treat their computers like simple tools, they don’t go poking about where they shouldn’t, and it has served me very well. Except in situations like this one, where users or malware have the inherent rights to change the DNS resolver settings if they know where to go and how to do it.

So that started me thinking about ways to address this risk and naturally I thought of the switching layer that everyone is connected to. The best place to control this is within the Cisco Catalysts themselves. It’s a matter of an ACL, an Access Control List. I poked about online and eventually came up with this solution. My two DNS resolvers are at 10.1.1.238 and 10.1.1.239 respectively:

ip access-list extended FIXDNS
!
permit udp any host 10.1.1.238 eq domain
permit udp 10.1.1.238 0.0.0.0 any eq domain
permit udp any host 10.1.1.239 eq domain
permit udp 10.1.1.239 0.0.0.0 any eq domain
permit tcp any host 10.1.1.238 eq domain
permit tcp 10.1.1.238 0.0.0.0 any eq domain
permit tcp any host 10.1.1.239 eq domain
permit tcp 10.1.1.239 0.0.0.0 any eq domain
deny tcp any any eq domain log
deny udp any any eq domain log
permit ip any any
!

This code block creates an ACL package named FIXDNS in the switch, and then on individual ports, or VLAN’s, or even the entire switch input flow I can affix this command and put this rule into operation:

ip access-group FIXDNS in

Obviously, I would use this in individual cases across the system, applying the limits only to end-user facing ports and skipping the trunks and support services like servers, copiers, and plotters. Being only a single command, it also makes it a snap to tear it out of ports as well, just on the off chance that I want to relax my security posture for some specific reason. I like the idea of the granularity of control this solution provides me, and I spend every day in my switching systems, so managing this is not any more work for me than usual.

I tested it in the lab as well, which is how this all got started. If the test laptop is configured to fetch its DNS settings from the DHCP pool, the users notice absolutely nothing at all unusual about their connection. Their DNS queries head off to OpenDNS Umbrella for resolution as normal, and everything works as it should. Acceptable traffic is allowed, while malware or banned categories are blocked. In the lab, if I set the laptops NIC to a specific DNS server outside my organization, like Google DNS, then any DNS related queries do not work. As a matter of record, I have included log directives in the block statements above, so if someone is breaking the rules, we’ll see where they are attempting to get their DNS services from and head out to correct it. Although the chances are that they would likely call us to find out why their Internet has stopped working.

I have this FIXDNS package installed on all my switches company-wide, but I haven’t actually enabled it anywhere. I think I am going to roll out the blocks very slowly and make sure that there aren’t any alarms raised at my efforts. Not that I seriously think anyone has the interest or know-how to customize their DNS resolvers, but it is nice to know that they cannot even if they tried.