Мы постоянно тестируем новые решения для наших проектов и недавно решили разобраться, что под капотом у 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 пользователей.
Полезные ссылки