Фильтрация веб-контента и DNS-ловушки

Веб-сёрфинг — один из самых распространённых векторов заражения: вредоносные загрузки, эксплойты, срабатывающие при посещении страницы, и фишинговые страницы рассчитывают на то, что пользователи перейдут по опасным URL. Фильтрация веб-контента контролирует, какие веб-сайты могут посещать пользователи и устройства, блокируя категории вредоносного содержимого или содержимого, нарушающего Policy, ещё до установления соединения. Фильтрация может выполняться на уровне сетевого прокси, на уровне DNS или непосредственно на конечном устройстве. При правильной настройке фильтрация предотвращает загрузку Malware, обращения к серверам управления и контроля (C2) и утечку данных, даже если другие средства защиты не сработали.

Веб-прокси располагается между Client и интернетом. Когда пользователь переходит по URL, Request направляется на прокси, который проверяет URL по базе данных URL с категориями, поддерживаемой такими поставщиками, как Webroot, Zscaler и Palo Alto. Если категория заблокирована (Malware, Gambling, содержимое для Adult), прокси возвращает страницу блокировки. Если доступ разрешён, прокси получает содержимое и возвращает его пользователю. Явные прокси требуют настройки Browser; прозрачные прокси перехватывают трафик без настройки Client. Облачные безопасные шлюзы Web (SWG) распространяют фильтрацию на удалённых пользователей, не направляя трафик через корпоративную сеть по петлевому маршруту.

Фильтрация на основе DNS блокирует вредоносные домены на уровне разрешения DNS до установления любого TCP-соединения. Когда устройство отправляет запрос к известному вредоносному домену, DNS-резолвер возвращает IP-адрес sinkhole (или NXDOMAIN) вместо реального адреса, полностью предотвращая соединение. Такие сервисы, как Cisco Umbrella, Cloudflare Gateway и Quad9, работают как облачные DNS-резолверы, применяя данные об угрозах в реальном времени к миллиардам запросов. Фильтрация DNS особенно эффективна для блокировки доменов обратных обращений C2 и доменов распространения Malware.

DNS sinkhole — это Server, который возвращает поддельный контролируемый IP-адрес для заблокированных доменов. Когда Malware на конечном устройстве пытается разрешить домен C2, sinkhole возвращает IP-адрес сервера sinkhole. Попытка соединения Malware достигает сервера sinkhole, который регистрирует это соединение. Это позволяет определить: какие внутренние Host заражены (они отправляют запросы C2), как часто они пытаются выполнить обратное обращение и какое семейство Malware активно (по домену C2). Sinkhole превращает заблокированный вредоносный трафик в данные об угрозах: он не просто блокирует трафик, а выявляет заражённые Host для устранения угрозы.

Базы данных фильтрации URL распределяют миллиарды URL по категориям: Malware, Phishing, C2 Botnet, Anonymizers/VPN, содержимое для Adult, Gambling, Social Media, Cloud Storage, потоковое Media, News и сотни других. Администраторы настраивают политики блокировки (всегда запрещать), политики разрешения (всегда разрешать) и политики предупреждений (пользователь видит предупреждение и должен подтвердить переход). Категоризацию URL поставщики поддерживают в реальном времени; новые вредоносные домены обычно добавляются в течение нескольких минут после обнаружения. Качество базы данных категорий напрямую определяет эффективность фильтрации.

Поскольку большая часть веб-трафика передаётся по HTTPS, прокси для фильтрации содержимого должны выполнять проверку SSL/TLS (её также называют SSL-перехватом или проверкой методом «человек посередине»), чтобы видеть содержимое зашифрованных сеансов. Прокси завершает сеанс TLS от Client, проверяет содержимое и повторно шифрует его для Server. Корпоративный сертификат CA устанавливается на все управляемые конечные устройства через MDM, благодаря чему Client доверяют повторно подписанным прокси сертификатам без предупреждений Browser. Из проверки следует исключать категории, которые не должны проверяться: банковские сайты, порталы Healthcare и сайты юридических исследований — из-за требований конфиденциальности и нормативных ограничений.

Одна из главных проблем фильтрации на основе DNS — DNS over HTTPS (DoH). Browser, такие как Chrome и Firefox, поддерживают DoH и отправляют DNS-запросы в зашифрованном виде резолверам вроде 1.1.1.1 или 8.8.8.8, а не локальному рекурсивному резолверу. Это обходит DNS sinkhole и средства фильтрации, поскольку запросы никогда не достигают корпоративного DNS-сервера. Меры защиты в Enterprise: отключить DoH с помощью Group Policy, заблокировать IP-адреса резолверов DoH на межсетевом экране или перенаправить весь трафик через порты 443/853 к корпоративному резолверу с поддержкой DoH с помощью прозрачного прокси.

Системы фильтрации содержимого настолько эффективны, насколько эффективны используемые ими данные об угрозах. Современные платформы фильтрации используют несколько каналов Threat Intelligence: коммерческие каналы (FireEye, Recorded Future, ThreatConnect) с отобранными вредоносными IOC; каналы с открытым исходным кодом (AlienVault OTX, abuse.ch, Emerging Threats); и собственные каналы организации, основанные на прошлых инцидентах. IOC из каналов Threat Intelligence — вредоносные домены, IP-адреса, URL и хэши файлов — автоматически добавляются в политики фильтрации в течение нескольких минут после обнаружения. Это обеспечивает почти实时ную защиту от новых угроз без ожидания обновлений базы данных поставщика.

Фильтрация Web выходит за рамки блокировки целых сайтов. Принудительное включение безопасного поиска в поисковых системах (Google, Bing) добавляет параметры безопасного поиска ко всем запросам и отфильтровывает результаты для взрослых, не блокируя поисковую систему полностью. Ограниченный режим YouTube можно принудительно включить с помощью переназначения DNS CNAME. Social Media можно разрешить для рабочих целей, одновременно блокируя определённые приложения Social Media (загрузку и скачивание) с помощью фильтрации на уровне приложений на прокси. Такие детальные настройки позволяют организациям соблюдать баланс между рабочим использованием и требованиями Policy без бинарных решений «блокировать/разрешить».

Фильтрация Web создаёт подробные телеметрические данные для Security Operations. Следует отслеживать: срабатывания категории Malware по пользователям и устройствам (это может указывать на компрометацию), попытки обратных обращений C2 (требуют немедленного расследования), попытки обойти Policy (модели использования Anonymizers/VPN) и риск утечки данных (крупные загрузки в личное Cloud Storage). Оповещения о достоверных срабатываниях вредоносных категорий следует интегрировать с SIEM и системами управления заявками, чтобы запускать автоматизированные процессы расследования. Регулярная отчётность для руководства демонстрирует объём угроз, заблокированных на уровне Web.

Фильтрация Web может применяться на сетевом уровне (прокси, DNS-резолвер) или на уровне конечного устройства (агент, установленный на устройстве). Фильтрация на основе сети защищает все устройства без установки на каждом из них, но перестаёт работать, когда пользователи находятся вне VPN. Агенты на конечных устройствах распространяют фильтрацию на удалённых пользователей: они выполняют фильтрацию локально и отправляют телеметрию в Cloud для обновления Policy. Гибридные модели объединяют оба подхода: сетевую фильтрацию для локального трафика и агентов на конечных устройствах для удалённых работников. Облачная фильтрация DNS (Cisco Umbrella) обеспечивает почти универсальное покрытие, заставляя корпоративный резолвер следовать за устройством, где бы оно ни находилось.

Проверьте своё понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.

В этом уроке Вы узнали, что прокси для фильтрации URL проверяют веб-запросы по базам данных с категориями и блокируют вредоносные сайты или сайты, нарушающие Policy; DNS sinkhole возвращает поддельные IP-адреса для известных вредоносных доменов и выявляет заражённые Host по зарегистрированным попыткам обратного обращения; а обход DoH представляет значительную угрозу для фильтрации на основе DNS, которую необходимо снижать с помощью Group Policy, правил межсетевого экрана или прозрачного прокси. Далее мы рассмотрим проверку SSL/TLS и атаки методом «человек в Browser».