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