If you don’t have Cisco Umbrella (Formerly OpenDNS) in your environment yet, you should really take a look at it. I’ve had to support on-premise solutions for URL filtering in the past and in my opinion, there are no good ones. No matter the vendor, administration tasks are more complicated than they should be, and they always add a little complexity and more points of failure in the environment. I’ve seen it several times where the security/URL filtering appliance was only in-line when running on the primary ISP connection. Or a company will have redundant ISPs but ALL traffic goes through a single appliance, creating a single point of failure. I’ve even seen an appliance set to ‘fail-open’ that should pass traffic even if the device were dead, but failed to do so when needed. This article is more about the deployment of Cisco Umbrella in our environment, so I won’t go on with all the numerous other benefits of Umbrella, suffice it to say that I am a believer in the product, and it was an enormous improvement over our previous solution.
There are a few deployment scenarios for Cisco Umbrella, depending on your what you are trying to accomplish. Basically you are trying to send DNS requests to Umbrella and ideally, determine who is trying to go there and from which device. If you just wanted to filter URLs, you don’t even need to determine the who, just white list and blacklist specific URLs.
Change DNS Forwarders - The Easiest way to start using Cisco Umbrella
You are probably using Microsoft Active Directory and DNS. Your client computers get a DHCP address assigned with your internal DNS servers specified for name resolution. If you try to resolve the name ‘server.yourdomain.com’ and your DNS server managing yourdomain.com has the record for it, then it responds with that IP address and you get a response. If it doesn’t, it will send it to the configured DNS Forwarders…external DNS servers that can resolve internet addresses. Most companies use either the forwarders specified from their ISP, or they use the google DNS servers: 8.8.8.8 and 8.8.4.4. If you change these forwarders to Cisco Umbrella servers, you have just gained a ton of visibility into your corporate network traffic, seeing where people are going on the internet, and having the ability to white list and blacklist sites with ease. This alone is a major win. Once you see the dashboard and how easy it is to use, you’ll wonder why you still use your on-premise device, when this is clearly so much easier to use, while reducing complexity and points of failure in your corporate network. I haven’t even mentioned the benefits from a security point of view, which would require an article in itself.
Changing the forwarders by itself it great, but you can probably already see some holes in the strategy. When users access the internet from your offices, they are behind a NAT, so they all appear to come from the same IP address. If the client is using your internal DNS servers, you’ll be able to see their DNS requests and potentially block them, but you can’t tell who it is, or which machine they came from. That information is critical to security and remediation. To gain more granular identity information, Cisco Umbrella has the option to deploy virtual appliances.
Deploy On-premise virtual appliances for conditional DNS forwarding
To add some identity information, you can deploy virtual appliances within your environment which tracks the internal IP address of every DNS request, so you can correlate the device to the request.
As you can see, using the appliances adds the requester IP…making it much easier to track down. To deploy the virtual appliances in your VMware environment is extremely easy. It comes as an OVF, so you deploy it through vCenter as you normally would. Name it, give it an IP address on the network of your choice, point it to your internal DNS servers and that’s pretty much it.
Once the appliances are spun up, change your DHCP settings for all scopes you want protected to point to the new virtual appliances instead of your internal DNS servers and you should start getting more detailed information in the dashboard. To get even more information, you can install an agent on your AD server which maps IP address to AD user names (you can see this info in the security event log entries). So the dashboard will actually show you the logged in user, not just the computer name.
Here are a couple installation tips:
If you have a next gen Firewall that is doing packet inspection (ASA with Firepower, Palo Alto, etc.) it’s common to see the virtual appliance show degraded in the dashboard because it’s blocking the encrypted DNS functionality called DNScrypt by default. You will need to implement the packet inspection exceptions documented here (for the ASA in particular): https://support.umbrella.com/hc/en-us/articles/230562207-Cisco-ASA-Firewall-blocks-DNSCrypt
While you are in the firewall, many customers want to ensure their users are only using OpenDNS DNS servers. With everything that we’ve mentioned so far, the client would only have to manually change their local DNS servers to public DNS servers like 8.8.8.8 and they would get around this completely. What we typically recommend is to make a group on the firewall that contains devices that are allowed outbound DNS requests. That group would contain the virtual appliances, the AD DNS servers and anything else that needs public DNS directly. Just add that group to an outbound ACL to restrict DNS queries to those devices.
With the options discussed so far, you have visibility into the internet activity sourced from your internal networks, but what happens when users take their laptops home with them? It’s not just feasible, but kind of common, for a system to get infected at home and then brought into work. Once the system is connected to the corporate network, you’ll still have visibility into the DNS requests, and Cisco Umbrella would most likely catch any attempt by the malware to ‘call home’, but it would be harder to stop the spread internally. What would be ideal is if you could have that same Umbrella protection for corporate devices no matter where the user is. The same malware protection and URL filtering would be in place no matter if the user is in the office, at Starbucks, or at home.
To get this level of protection, we would need to get a little closer to the source, on the device itself, by installing an agent that can act as a proxy and always intercept DNS requests and send public requests to the Umbrella cloud for inspection.
Umbrella Roaming Client (Agent based Intelligent Proxy)
This is a very lightweight DNS client that can run on Windows or Mac and all it does it forward DNS requests. It works really well and provides the full ‘Umbrella’ experience, meaning the client is fully covered no matter where they are and with full visibility in the dashboard. All that said, we don’t use it at LookingPoint! Cisco has integrated this role into the AnyConnect client and has tied it in with AMP for Endpoints as well. Now when we open AnyConnect we also see our Roaming Status as well as our AMP status.
Deployment was super simple with all three of these roles bundled in a single package. There are no signatures to download, no software updates to push, it really is extremely easy to deploy and administer.
That’s essentially it for the deployment! There are knobs to tweak if you’d like to get the full value out of the product, but by and large you get an incredible amount of insight and protection with an extremely minimal amount of effort. I am hard pressed to think of another product that can provide so much for so little effort and I think you’ll feel the same way after using it yourself.