Can you give me a list of all the destinations employees at your company are browsing to on the internet in the office and out? Would you know if all of those sites are safe? Are they clicking on those “Free Tablet Just For You!!!!!!” email links? The internet can be a dangerous place. DNS helps users easily reach destinations. Who is going to remember the IP addresses to hundreds of sites? However, DNS can lead users to malicious destinations as well. You might have a need to protect users or enforce company policies at the DNS level.
This post will be a review of Cisco Umbrella. We’ve been using it in production. This will by no means serve as deployment instructions. Please refer to Cisco Umbrella’s documentation for those. These are just my thoughts on how the process went.
For a while, Cisco’s IronPort Web Security Appliance (WSA) was our solution for traffic inspection. It worked well. You could create policies and have a deep level of control on what and who should have any interaction with the internet. It was a good solution at the time since all sites would route to a central location for internet access. Everyone’s HTTP and HTTPS traffic would traverse the WSA. However, times began to change. Sites started to branch out and obtain local internet connections. The setup no longer made sense. Our setup would not be able to protect users who were outside of a facility. Organizations were looking to move into a “Zero Trust” mentality. This was something we were looking at as well. How do we protect users when they are outside of our “safety bubble”? What was stopping someone’s machine from becoming infected and for the user to walk the infection into the company past the firewalls, WSA and any other edge security device? We needed a solution that would work not just at the edge, but inside and outside. In today’s landscape, colleagues need to be protected at all times. This is when we started looking for a solution, which ended up being Cisco Umbrella.
Cisco Umbrella was OpenDNS until it was acquired by Cisco. They should still be OpenDNS for home products.
Out of the box, the first thing I did like was it’s ease of use. The dashboard has a very similar feel to Meraki. Being a big fan of Meraki, this felt pretty comfortable. Cisco Umbrella management in the cloud felt right. The dashboard leads you to plenty of help documents and instructions on what to do. Managing the IronPort, you are browsing to that appliance, however with Cisco Umbrella you are heading to the cloud for management of the environment.
Years ago my wife convinced me that I “love” camping. I honestly do not mind it, but what I do mind was trying to setup the tent. Finding where each pole went and where to shove it into was not particularly fun in the experience. Eventually we went for one of those “minute” setups. Everything is already setup for you tent-wise. All you have to do is expand it out of the bag, continue to expand and click everything together. It made camping a smoother experience. Cisco Umbrella has a few more components than a “minute” tent, but the deployment is straight-forward.
We want to protect users at a DNS-layer whether they are inside the org or outside. Depending on how you want to apply policies depends on how deep in the config you will go. We wanted policies to be applied to particular networks and even particular users. The first thing to do is change your org’s DNS servers to point to Cisco Umbrella. You can find the IPs in the documentation, but they don’t look to change anytime soon: 126.96.36.199 & 188.8.131.52. Once that was setup we started working on the installs.
Cisco Umbrella gives you all the components needed for the setups. They can be downloaded once you login to the dashboard. At each site, we installed two Virtual Appliances (VAs). These VAs are virtual machines that live at each of the sites. There must be two VAs per site. Now for individual subnets instead of pointing their DNS to the existing DNS servers, we pointed them to the VAs. The VAs are in charge of reporting, applying policies, encrypting DNS traffic along with maintaining a relationship with your local Domain Controllers. An install of an Umbrella service on your local Domain Controller will make the DC and VAs co-exist. The VAs will then become aware of user info from the DC which can be used in various policies. The VAs are needed to keep track of user activities if you require that information.
I am making it sound simpler than what it is, but it felt that way. The documentation we followed from the dashboard was thorough. As a small example, let’s say we have five sites with a domain controller in each, we installed the Umbrella service on each domain controller. Cisco Umbrella refers to the domain controllers as “connectors”. Each site would have two VAs. Users at those sites would have their DHCP scopes (or static info) changed to use the VAs as the DNS servers.
That is mainly the local work that needs to be complete. I did not discuss firewall rules, but having firewall rules for the domain controllers and VAs will be necessary as there will be communication out to Cisco Umbrella. Within the dashboard you can check on the status of your connectors and VAs. If there are issues, the dashboard will suggest what can be done to fix the problems.
Once in a while I do have the occasional “Connector cannot see one or more VAs” message. Usually this is resolved with a reboot of a VA or even a restart of the service within the connector (Domain controller). This is something that does not happen all the time, but it does. It has not been detrimental enough for me to dive into a deeper investigation unless it continues to happen more often.
Earlier in this post I mentioned protecting users when they are outside of a facility. This is where the Umbrella Roaming Client comes in. You can deploy this agent to all machines that come and go through your facilities. All laptop users have it deployed. This will ensure policies are applied to those machines or specific users even when they are not onsite. This takes care of the “I lent my laptop to my son and he did something weird to it” scenario. If you’ve setup policies to block most of those “something weird” destinations, they will be blocked for those remote users as well. That seems to work pretty well. In the section below I created a policy to block myself from reaching my own blog….it worked instantly.
Just setting up the connector, roaming clients and VAs are not enough. There are still a few things to take care of in the dashboard. Each page gives you a description of what it is looking for and as I mentioned, documentation is thorough.
Under Networks is your public IP space. Adding your space seems to be a catch all to apply policies for anything coming from that space, unless you have individual policies set for certain groups/users.
Roaming Computers will give you just that, your roaming clients and their info.
Domain Management is where you add domains you control in your org.
Sites and Active Directory is the list of connectors, VAs and their health. I usually visit this page once in a while to make sure all is well.
The Internal Networks section is a list of your subnets. If you want to create certain policies and apply them with granularity, this is where you make some of those logical separations. This works hand in hand with the VAs you install. One thing I cannot seem to find is an upload feature. I’d like to submit a list of subnets somewhere. It seems like this section is manual. I might open a case to inquire about it. Speaking of cases, the support email is listed in the dashboard. Opening up a ticket for Umbrella is as simple as sending an email. The response time has so far been adequate (within the day).
Anything else I did not mention is because I have not made any use of it yet. It seems with everything above, the framework is set. Now you can have some policy fun!
All this is nice, but here is the meat. It’s in the policies. Here is where you can control who goes where. You can use out of the box categories (drugs, gambling, nudity etc;.) and/or create lists of destinations you want to specifically block (or allow).
These are then applied in policies for all Identities (AD users, subnets, computers) or policies for specific Identities. There is much more you can do with policies, such as SSL Decryption. I have yet to try it, but will make sure to update this once I do.
Policy matching occurs from top to bottom. You would make sure your broader policies are at the bottom. In order to block my own blog from myself, I created a new destination list.
The purpose of that list was to block access to any destination in it. You might run into legit websites that your users need opened globally, that is when you would allow the site through in a different list. We’ve seen a site or two that were not categorized correctly and needed to be allowed.
As you can see above, selecting the lists under the created policy is pretty simple. I added my “Test Block” list. This policy will only be applied to one Identity (my computer).
There are other settings that can be applied within the individual policy. Play around with what works well for your organization (or required). So far, for what we’ve needed, this has worked pretty well. I blocked my own blog. I was not on the network either. As soon as I submitted the policy, I tried to browse to my page and was presented with the block page:
There are other options within Umbrella to explore. The reporting section is helpful at tracking down suspicious activity. You can export reports. One thing I have not seem to find so far are alerts. I’d like to email alerts over when a VA is not working properly; I have yet to find this.
Within the reporting, you can also see applications that are being used in the org. You can dive in and block if necessary. Cisco Umbrella appears to give all the needed information.
I believe we are happy with Cisco Umbrella. I think with any tool that an organization obtains, you need to continue to use it and find out how you can make the best use of its features. By no means does that happen overnight. As you might have guessed in this review, nothing license/money-wise was discussed. I’ll let you have those conversations with your Account Managers.