Мы постоянно тестируем новые решения для наших проектов и недавно решили разобраться, что под капотом у Cisco Umbrella. Сам вендор заявляет, что это облачное решение для защиты угроз со стороны интернета из пяти компонентов:

защищенный рекурсивный DNS;
веб-прокси с возможностью отправки подозрительных файлов на анализ в песочницу;
L3/L4/L7 межсетевой экран (Cloud Delivery Firewall);
Cloud Access Security Broker (CASB);
инструмент для проведения расследований.

Желающих узнать, что же находится под капотом каждого из этих компонентов, приглашаю под кат.

Защищенный рекурсивный DNS

Когда мы пытаемся попасть на какой-то ресурс по доменному имени, вне зависимости от протокола, мы резолвим доменное имя, то есть преобразуем его в IP-адрес.

Можно ограничивать доступ к ресурсам на основе URL (фактически уже HTTP-трафик), а можно делать это на шаг раньше — исходя из DNS-запроса.

Cisco Umbrella в данном случае выступает как облачный рекурсивный DNS.

Решение может детектировать и блокировать DNS-обращения по таким категориям:

скомпрометированные системы;
связь с серверами управления (C2C);
Malware и Phishing;
автосгенерированные домены;
новые домены;
построение DNS-туннелей (DNS Exfiltration).

С точки зрения архитектуры, это выглядит так:

Нам нужно защитить пользователей на площадках и, что более важно в условиях массового перехода на удаленку, удаленных пользователей.

Пользователей как-то нужно перенаправить в облако для анализа их DNS-запросов, и здесь есть два способа.

1) У пользователей на площадках прописан локальный DNS (обычно адрес домен-контроллера). Нам достаточно просто прописать адреса Cisco Umbrella в настройках DNS Forwarders:

2) Удаленным пользователям достаточно установить AnyConnect (модуль Roaming Client) или Umbrella Lightweight Client, в котором будут прописаны адреса DNS и подцеплен профиль организации.

Доступность указанных адресов 208.67.222.222 и 208.67.220.220 обеспечивается с помощью BGP Anycast (когда одни и те же маршруты анонсируются из разных географических точек).

Таким образом, при обращении на эти адреса для уменьшения задержек вы будете направлены в ближайший ЦОД в зависимости от своего географического расположения.

Если провести небольшой тест измерения задержки утилитой dig при обращениях через Cisco Umbrella и публичный Google DNS (8.8.8.8), то получим следующие результаты.

Таблица 1. Результаты измерения задержки через Umbrella

	Имя сайта	Замер 1	Замер 2	Замер 3	Замер 4	Замер 5	Среднее
1	mos.ru	89	39	41	94	86	69,8
2	admomsk.ru	46	96	90	39	95	73,2
3	state.gov	53	59	39	47	44	48,4
4	gov.cn	43	127	45	135	62	82,4
5	gov.uk	62	55	63	67	52	59,8
6	governo.it	59	64	66	58	39	57,2

Таблица 2. Результаты измерения задержки через Google

	Имя сайта	Замер 1	Замер 2	Замер 3	Замер 4	Замер 5	Среднее
1	mos.ru	24	35	34	32	29	30,8
2	admomsk.ru	50	28	50	52	28	41,6
3	state.gov	29	51	289	56	39	92,8
4	gov.cn	375	30	30	557	359	270,2
5	gov.uk	74	68	32	75	89	67,6
6	governo.it	102	26	93	27	91	67,8

Как видно, Cisco Umbrella не вносит каких-то значительных дополнительных задержек по сравнению с публичными DNS.

Дашборд управления настройками располагается по адресу https://dashboard.umbrella.com/o/<OrgID>/#/overview, где <OrgID> — это персональный номер вашей организации, выданный Cisco.

Со стороны Cisco Umbrella достаточно добавить ваш белый IP (адрес или несколько адресов, с которых площадка выходит в интернет) в список Networks, для roaming clients (удаленных пользователей) ничего дополнительно добавлять не надо.

Если у вас несколько домен-контроллеров, то скрипт автоконфигурирования (регистрации в Cisco Umbrella) и настройки DNS Forwarders необходимо будет настроить на них всех, а OpenDNS AD Connector (о нем позже) поставить только на отдельных VM.

Когда на домен-контроллере настроены DNS-forwarders, а у удаленных пользователей установлен Roaming Client, можно проверить, что вы находитесь под защитой Umbrella, перейдя по адресу https://welcome.umbrella.com.

Всё, вы под защитой!

Что же идет по умолчанию в этой защите? Посмотрим Default Policy.

Политика по умолчанию и её основные компоненты

Вот так выглядит основное меню настройки политики по умолчанию:

Applied to All Identities значит, что политика применяется ко всем, кто посылает запросы через Umbrella (в пределах вашей организации). Если делать свою политику, то можно указать много разных типов, к чему ее применять: AD группы пользователей, Roaming Computers, IP-адреса и др.

Security Setting Applied означает блокируемые категории:

Следует отметить, что DNS-политика по умолчанию не строится по принципу implicit deny (все запрещено), блокируются только категории Malware, C2C, Phishing Attacks.

Content Setting Applied подразумевает, какие DNS-запросы блокируются на основе содержащегося контента.

Если домен категоризирован как содержащий Drugs, он будет целиком попадать в эту категорию, даже если по ссылке www.example.com/Sports будет располагаться спортивный вестник о последних достижениях местной команды. А вот если блокировка на основе контента будет применяться в Web Policy, а не DNS Policy, то здесь как раз будет разграничение в зависимости от конкретного URL.

Application Settings Applied означает блокировку в зависимости от используемого приложения.

Destination list — блокировка по конкретному FQDN, IP-адресу, URL (для Web-Policy).

Если вы добавили что-то в Global Allow List в виде IP-адреса или, например, FQDN, то это этот ресурс по категории или контенту уже не будет блокироваться (если он подпадает под эту категорию/контент).

Настройка File Analysis доступна, если вы включили в Advanced Settings функцию Intelligent Proxy. По умолчанию она отключена.

Intelligent Proxy предназначен для работы с так называемыми grey доменами, когда на них может быть размещен нежелательный контент или вредоносные файлы, но целиком блокировать домен нельзя или нет необходимости. В обычном режиме работы Umbrella либо возвращает в DNS-ответе адрес целевого ресурса, либо вот такую блокирующую страницу:

При включенной же опции Intelligent Proxy Umbrella будет возвращать вам адрес облачной прокси, через который будет проксироваться трафик с сертификатом Cisco (нужно установить сертификат Cisco в доверенные и включить опцию SSL Decryption). Большое количество очень популярных доменов, например, Google или Facebook, не проксируются из-за низкой вероятности размещения там вредоносного контента.

Grey домены

Grey домены включают в себя домены одновременно с нормальным и вредоносным контентом, поэтому Cisco категоризирует их как risky domains.

Самостоятельно категоризировать какой-то домен как «серый» нельзя, можно только исключить определенный домен из раскрытия трафика и проксирования.

При включенной настройке файлы будут отправляться на анализ в облачную песочницу Threat Grid Malware Analysis (для веб-политик) либо анализироваться статически в случае применения в DNS-политиках.

Например, при попытке скачать eicar файл у меня появилась надпись «Этот сайт был заблокирован прокси Сisco Umbrella»:

Block Page — веб-страница, которая будет отображаться у пользователя при блокировке запроса. Настроить отображаемую страницу можно в разделе «Block Page Appearance».

Можно модифицировать страницу блокировки, например, отразить, что запрос заблокирован из-за отнесения к конкретной категории или содержащегося контента, указать e-mail админа для контакта.

Создание политики на основе пользователей Active Directory

В большинстве организаций политики как на межсетевых экранах, так и на прокси, сейчас пишутся на основе пользователей групп Active Directory.

Cisco Umbrella тоже пошла по этому пути: интеграция с AD возможна путем установки OpenDNS коннектора на виртуальную машину для отправки LDAP-запросов к домен-контроллеру, либо на сам домен-контроллер.

Домен-контроллер регистрируется в дашборде Cisco Umbrella автоматически (путем запуска wsf-скрипта на домен-контроллере):

Я установил OpenDNS-коннектор на домен-контроллер. После этого в политиках, в разделе Identity, можно указать конкретного пользователя или группу, для которых будет применяться политика:

Попробую разрешить пользователю категорию Malware, а на уровне всей сети запрещу её.

Политики выполняются, как обычно, сверху вниз. Есть удобный инструмент для проверки уже созданных политик — Policy Tester.

Для пользователя Barney получаю результат «Разрешено»:

Для обращения с домен-контроллера или любого другого пользователя получаю результат «Запрещено»:

Обращения к внутренним доменам обычно не нужно подвергать дополнительной проверке, поэтому их можно исключить из проверки средствами Umbrella двумя способами:

1) Через управление доменом в дашборде Umbrella.

2) Через установку отдельной VM — Umbrella Virtual Appliance:

Umbrella Virtual Appliance выступает в роли DNS-forwarder, локальные DNS-запросы отправляет на локальный DNS, внешние DNS запросы — в Cisco Umbrella.

VA внедряет уникальные идентификаторы для каждого пользователя, которые Umbrella в свою очередь использует для контроля и детальной видимости:

А так выглядит лог без VA (локальные IP-адреса не видны):

Защита удаленных пользователей (Roaming Users) обеспечивается либо включением модуля Umbrella Roaming в Cisco AnyConnect, либо установкой Lightweight Umbrella roaming-клиента.

Интересный факт: Сisco Umbrella можно обойти, если прописать на рабочей станции нужные записи до закрытых ресурсов в hosts.

Лучшие практики при работе с DNS-политиками

1) Политики надо делать неперекрывающимися. Например, если вы сделаете явно allow destination list, а по категории у вас он вредоносный, трафик будет разрешен.

2) Последняя политика должна быть наиболее запрещающей. В ней нужно запретить как можно больше категорий, контента и приложений. В более специфичных политиках (выше по списку) нужно наоборот что-то разрешать.

3) Политики нужно строить снизу верх от широких к узким. То есть в целом для одной группы пользователей запрещена категория «облачные хранилища», но для отдельных пользователей вверху списка она разрешена.

4) Используйте в политиках группы «All Networks», «All Roaming Computers». Когда появится новый Roaming Computer, он просто автоматически подпадет под эту политику. Также желательно сделать разные политики для локальной сети и для Roaming Computers. Когда пользователь будет уходить из офиса, он будет подпадать под другую политику безопасности (возможно, более строгую).

Эти рекомендации применимы также и к работе с веб-политиками, которые я разберу ниже.

Работа в режиме веб-прокси

Решение может работать не только как рекурсивный DNS, но и как облачный веб-прокси.

Трафик в облачный веб-прокси от пользователей направляется точно так же, как и в земной — с помощью PAC-файлов (proxy auto-config). Сам PAC-файл можно разместить в Umbrella. Проксируется только HTTP/HTTPS-трафик (TCP 80/443).

Вы можете задаться вопросом: «А как аутентифицировать пользователей в облачном прокси? Ведь мы не можем здесь применить Kerberos/NTLM».

Ответ на него кроется как раз на картинке выше — SAML.

В качестве IDP (Identity Provider) можно использовать как раз земной AD (ADFS) с установленным AD-коннектором, который я рассматривал в разделе защиты DNS.

В веб-политиках можно использовать все то же самое, что и в DNS-политиках, а также:

1) Антивирусная защита файлов с помощью движка Cisco AMP (Advanced Malware Protection) и отправка их в песочницу Threat Grid Malware Analysis. Ограничения здесь — максимум 200 файлов в день с размером файла не более 50 Мб.

2) Контроль по типам файлов (File Type Control). Позволяет блокировать скачивание в зависимости от категории (исполняемые файлы, изображения, аудио и т.п.) и конкретного расширения (js, jpeg, exe и т. п.).

Вот так будет выглядеть попытка скачать файл из заблокированной категории Executables:

3) Tenant Control (CASB) позволяет явно разрешить использование корпоративного тенанта и запретить использование личного доступа для облачных сервисов Office 365, Google G Suit, Slack. То есть, например, пользователям надо ходить в облачный офис 365 по корпоративным нуждам, но по личным нам надо его прикрыть. Классический Application Control здесь не сработает, поэтому:

Tenant Control работает просто: Umbrella смотрит в authentication request, и если видит там корпоративный домен, явно разрешенный в политике, то пропускает трафик.

Вот так выглядит меню настройки:

Я добавил в список разрешенных доменов свой тестовый домен в Office 365 mx365x986845.onmicrosoft.com. Все остальные домены по умолчанию запрещены.

Попробую зайти в Office 365.

После корректного ввода пароля я успешно попадаю на главную страницу Office 365:

А теперь я попробую зайти в свою корпоративную учетную запись:

После ввода пароля я получил обескураживающее сообщение: «Невозможно добраться отсюда туда»:

Причем сообщение от Microsoft, а не от Cisco Umbrella. Немного погуглив это сообщение на английском языке, я нашел следующее в документации Microsoft: «You can't get there from here. This message means your organization has put a policy in place that's preventing your device from accessing your organization's resources». Прелести русификации я оценил :)

Из недостатков данного облачного веб-прокси можно отметить отсутствие IPS-профилей.

Cloud Delivery Firewall

Решение может также дополнительно выступать в роли L3/L4/L7 межсетевого экрана в облаке, для этого потребуется завернуть трафик с площадки через IPSec-туннель.

Важное ограничение: в политиках МСЭ можно писать только приватные IP-адреса в поле Source и публичные адреса в поле Destination и никак иначе. То есть применение здесь вполне конкретное — только ограничение доступа для внутренних ресурсов наружу.

Еще один нюанс: максимально допустимая полоса на каждый туннель 250 Mбит/с. Если потребуется передавать больше трафика, нужно будет строить дополнительные туннели и балансировать между ними нагрузку (например, ECMP).

В политиках можно добавлять Applications, но добавлять группы пользователей AD нельзя.

Пример настроенного правила:

Такой МСЭ может в принципе подойти организациям, на площадках которых нет своего МСЭ и есть только каналы в интернет (т.е. нет выделенных каналов до ЦОД, где можно централизованно выпускать пользователей в интернет).

Работа с отчетностью и расследованиями

В Umbrella представлен довольно хороший функционал для проведения расследований и анализа отчетности.

Можно смотреть как общее состояние по компании:

Так и детальное (кто-куда-когда-почему):

Имеется много разных типов отчетов (App Discovery, Threats, Top Destinations и другие). Отчеты можно выгружать в форматах csv и pdf, выгрузку отчетов можно делать автоматически, например, еженедельно, с отправкой на почту.

Пример выдержки из отчета App Discovery:

Функционал для помощи в расследованиях располагается на отдельном ресурсе https://investigate.umbrella.com/.

Работает это очень просто: вводите FQDN, ASN, IP, hash и получаете риск-скоринг и другую полезную информацию:

данные записей WHOIS;
атрибуция ASN;
геолокация;
репутация доменов и IP;
анализ вредоносных файлов;
связи между доменами;
обнаружение аномалий (DGA, FFN);
шаблоны запросов DNS.

Вот так выглядит риск-скоринг домена по версии Cisco:

WHOIS-информация и геолокация:

Семплы, собранные Cisco AMP Threat Grid и ассоциированные с данным хостом, приведены ниже и кликабельны внутри дашборда:

Можно сразу провести анализ по хешу:

В части работы с логами в SIEM вас ждет разочарование: выгрузка логов возможна с задержкой в 10 мин только в Amazon S3 bucket, а уже оттуда в SIEM.

Итоги

С момента покупки OpenDNS Cisco неплохо прокачала функционал этого решения и добавила много новых фич: веб-прокси, CASB, отправка файлов на анализ в песочницу. Решение занимает нишу защиты от угроз со стороны интернета и ограничения доступа к внешним ресурсам. Архитектура позволяет использовать решение как для удаленных, так и для on-site пользователей.

Полезные ссылки

Обзор Cisco Umbrella: защита на уровне DNS и не только