В рамках третьей технологической конференции IT Elements 2025 были представлены не только пленарные доклады по ключевым темам ИТ и ИБ, но и отраслевые решения, отражающие практику применения технологий. Одно из таких решений — система контроля DNS-запросов в корпоративной системе АО «Банк Инго».
- Введение
- DNS-файрвол
- Реализация Zero Trust на стороне DNS
- Контроль доступа через DNS
- Варианты DNS-атак
- Решения для защиты против DNS-атак
- Детектирование аномалий
- Слои защиты
- Альтернативные решения
- Программная платформа
- Выводы
Введение
10–11 сентября в Москве состоялась третья технологическая конференция IT Elements 2025, которую уже неформально стали называть «мероприятие от айтишников для айтишников».
Тематика конференции широка, она касается многих направлений развития ИТ и ИБ. Как и на других ивентах, здесь проводятся круглые столы, можно познакомиться с презентациями вендоров и интеграторов, узнать о новых решениях. Но есть важное отличие: здесь выступают прежде всего те, кто использует новые компьютерные технологии и адаптирует их под свои задачи.
В этом году конференция IT Elements 2025 проводилась в шести тематических залах. Два главных зала были отданы под пленарные выступления, также были залы «ИТ-инфраструктура», «Кибербезопасность», «Сети», «Данные и AI / ML». Конференцию посетили более шести тысяч ИТ-специалистов, на стендах было представлено более 30 компаний, на заседаниях выступило более 60 спикеров.
Anti-Malware.ru уже публиковал материалы по темам пленарных выступлений. Мы хотим продолжить эти публикации и представить доклады, которые отразили особенности применения технологий в области ИТ и ИБ, показать их уникальность и ценность для практики.
Рисунок 1. Конференция IT Elements 2025 «от айтишников для айтишников»
DNS-файрвол
Николай Жогин, главный инженер‑программист АО «Банк Инго», представил доклад о практической реализации концепции «нулевого доверия» (Zero Trust) на стороне DNS. Однако прежде чем рассказать о самом решении, расскажем о том, как вообще применение DNS-файрвола в качестве элемента корпоративной защиты позволяет реализовать концепцию «нулевого доверия».
Назначение межсетевого экрана для системы доменных имён (DNS) состоит в том, чтобы предотвращать переход корпоративных пользователей на вредоносные веб-сайты и обеспечить защиту от кибератак со стороны внешних сайтов. Попутно DNS-файрвол помогает блокировать доступ к сайтам, посещать которые сотрудникам не рекомендуется (например, социальные сети).
Почему? Достаточно вспомнить выступления практиков на отраслевых конференциях 10-летней давности. Например, ещё в 2012 году руководитель ИБ-службы КБ им. Сухого отмечал: после установки системы InfoWatch для контроля утечек выяснилось, что 60 % рабочего времени сотрудники компании проводили в сети «Одноклассники». Поэтому вопрос контроля использования российских социальных сетей не менее актуален, чем защита от вредоносных атак.
Межсетевой экран DNS выполняет в том числе и те функции защиты, что и обычный файрвол. Но он делает это не через блокировку загрузок непосредственно с вредоносного или нежелательного сайта, а через систему резолвера, выдающего адрес сайта для доступа к его содержимому. Защита осуществляется путем фильтрации трафика, проходящего через конечные точки DNS, с его проверкой по определённым правилам и с учетом выбранных политик. Если межсетевой экран обнаруживает, что такой трафик нарушает хотя бы одно из установленных ограничений, то дальнейшее выполнение веб-запроса блокируется.
Применение DNS-файрвола позволяет существенно снизить угрозы классических кибератак следующих типов:
- эксфильтрация данных;
- фишинг, целевой фишинг (spear-phishing), «китовый» фишинг (уэллинг, whale-phishing);
- атаки программ-вымогателей;
- действия иных вредоносных программ.
Рисунок 2. Конференция IT Elements 2025 проводилась на территории выставочного пространства TAU
Реализация Zero Trust на стороне DNS
Итак, напомнив, что именно можно контролировать на уровне DNS-системы, рассмотрим, как эта задача реализована в корпоративной системе «Банка Инго», детали которой раскрыл в своём докладе Николай Жогин на IT Elements 2025.
Целью реализации Zero Trust в их решении является возможность проактивно предотвращать инциденты и реагировать на них не постфактум, а проактивно, в настоящем времени. Это важно, потому что злоумышленник может уже находиться в сети, и задержки с ответной реакцией, длящиеся в других решениях по 10–15 минут, ведут к тому, что кибератака уже может развиться. В этом случае надо бороться уже не с самой кибератакой, а с её последствиями.
Прежде всего, отметил Николай Жогин, необходимо разбить сеть на сегменты и сделать их как можно меньше. Это позволит гибко описать правила для выделенных сегментов. Правила формируются на основе того, что нужно для бизнеса. Задав таким образом ограничения, нужно разрешить выполнение только нужных операций, а всё остальное заблокировать.
Zero Trust реализуется в том, что даже если доступ легитимен, нужно постоянно верифицировать его, оценивать на подозрительность то, что происходит. А если эта активность становится «какой-то странной», — автоматически реагировать. Всё это нужно для того, чтобы сузить окно проникновения, убрать лишние горизонтальные перемещения по инфраструктуре и, как минимум, дать команде реагирования время на то, чтобы заметить злоумышленника.
Рисунок 3. Выступление Николая Жогина на конференции IT Elements 2025
Контроль доступа через DNS
При организации контроля DNS Николай Жогин выделил два основных направления. Первое — это контроль доступа, т. е. определить, кто может резолвить и что именно. Второе — это детекция аномалий, появление скрытых каналов передачи данных.
Контроль доступа важен, потому что DNS можно рассматривать как «намерение» к любому сетевому действию.
«При перехвате DNS-запроса блокируется само намеченное действие. Если оно вредоносное, то это сетевое действие не состоится».
Формально, такой DNS-контроль можно обойти. Очевидно, что этот вариант кибератаки следует также рассматривать. Например, можно обратиться напрямую на нужный сетевой адрес, использовать туннель или получать адреса через внешний DNS. Но это выходит за рамки защиты именно на уровне DNS. Поэтому если принять, что используется определенный DNS-сервер, то первое, что надо сделать, — это удобно сегментировать DNS-запросы.
«Здесь придётся работать через доменные имена, которые сами по себе несут определённый смысл для сегментации. Просто на самих именах можно выстраивать и сетевую сегментацию».
Установка правил также позволяет реализовать гибкое изменение политик. В корпоративной системе «Банка Инго» это сделано на основе данных работы внешней скоринговой системы. Она оценивает активность пользователя и выявляет аномалии, расцениваемые как подозрения на ИБ-угрозу.
Например, по системе СКУД (контроля и управления доступом) можно маркировать как подозрительные (проводя дополнительно кросс-анализ с другими системами контроля и аналитики) запросы со стационарного компьютера, операции по удалению файлов или запуску странных приложений, которые совершаются, когда заведомо известно, что сотрудник отсутствует на рабочем месте.
Рисунок 4. DNS является важной ступенью для выстраивания системы контроля
Второе — это детекция аномалий.
«Это направление защиты не стоит путать с скорингом, потому что здесь мы оцениваем в реальном времени DNS-запросы и ответы на подозрительность. При скоринге оценка выполняется асинхронно, на основе действий, которые произошли в течение определённого промежутка времени. При детекции аномалий в реальном времени надо оценить DNS-запрос или ответ и принять решение о его допустимости непосредственно в момент обработки. Такая модель контроля безопасности позволяет избежать множества последующих проблем».
Варианты DNS-атак
Николай Жогин выделил два основных вида кибератак, которые можно детектировать на уровне DNS-системы.
Кейс № 1. У злоумышленника есть собственное доменное имя (атакующий сайт). Он создаёт там легитимные команды, отправляемые на DNS-сервер с целью организации доставки вредоносных данных в атакуемый закрытый контур. Злоумышленник помещает внутрь таких команд собственный атакующий код, который обычно упакован и закодирован. Однако с помощью логарифмов можно оценить, что именно находится внутри закодированной части. Если злоумышленнику удаётся пройти DNS-контроль, то он делает рекурсивные DNS-запросы через корпоративный DNS и получает команду с доступом на машину жертвы.
Кейс № 2. Этот вариант кибератаки противоположен первому. Злоумышленник создаёт DNS-запрос, внутрь него помещает команду управления, которая реализует намеченное вредоносное действие. Это может быть просто запрос в отношении вложенного домена, закодированный по стандартному формату Base64. С точки зрения RFC такая команда вполне легальна. Через него злоумышленник получает на свой DNS-сервер содержимое из закрытого контура.
Решения для защиты против DNS-атак
Для контроля доступа в АО «Банк Инго» была разработана собственная версия политик доступа. Некоторые из этих правил были представлены в презентации докладчика.
- При обращениях на определённый адрес (например, github.com) сначала делается проверка на день недели. Обычно этим сайтом пользуются программисты. Если они обращаются по этому адресу в воскресный день, то срабатывает правило DROP, и такой запрос блокируется. Иначе выполняется следующая строка — PASS: запрос передаётся на обработку. Аналогичным образом выстраиваются правила для других IP-адресов из подготовленного списка. Тем самым DNS позволяет определить назначение адресуемых сайтов и регламентировать доступ к ним с учётом профессиональных интересов каждого отдельного пользователя.
- Инструкция «стрелочка» позволяет задать такой вариант обработки, когда можно сохранить полученный от адресата ответ, но не возвращать его на сторону запрашивающего. Это может быть полезно, чтобы получить содержимое, подготовленное злоумышленником для передачи в закрытый контур, но при этом не отдать его клиенту. В этом случае запрос резолвится, перенаправляется на внешний адрес и затем доступ к нему блокируется, хотя содержимое ответа сохраняется.
Рисунок 5. Примеры применения правил контроля в DNS-службе
- Используя данные скоринга, можно срезать часть DNS-ответов, например для блокировки доступа к иностранным серверам (не из зоны .RU).
- В арсенале управления правилами необходимо предусмотреть средства для управления списками. С их помощью можно, например, встраивать одни списки в другие, тем самым применяя к ним определённые правила обработки. Важно, чтобы управлять списками было удобно, так как некоторые из них формируются автоматически с помощью алгоритмов.
- Выделение разрешений происходит после добавления нового пользователя в Active Directory и установки его связи с определённым адресом. После этого все подтверждённые клиенты получают доступ к разрешённым доменам, а остальные блокируются.
Детектирование аномалий
Для детекции аномалий в режиме реального времени применяется формула Шеннона, отметил Николай Жогин. Её смысл отражает следующее суждение: «Чем событие более предсказуемо, тем оно менее информативно». Это позволяет оценить информативность контролируемых изменений и принимать решение после получения оценки связности. Формула Шеннона указывает на то, что энтропия связанных процессов сближается при усилении их связи.
Рисунок 6. Формула Шеннона
На практике это представляет собой функцию, на вход которой подаётся строка DNS-запроса, а на выходе получается число, которое отражает степень хаотичности входных данных. Полученное число используется как один из параметров для управления маршрутизатором. Так можно выявить присутствие ключевых слов в обрабатываемом DNS-запросе.
Такой способ позволяет находить аномалии в настоящем времени и одномоментно принимать решение по ранее неизвестному содержимому.
Рисунок 7. В основе поиска аномалий лежит применение формулы Шеннона
Слои защиты
Представленная Николаем Жогиным система контроля на уровне DNS относится к первому слою защиты. Фактически же защита доступа в АО «Банк Инго» выстроена на нескольких уровнях. Другие используемые ступени защиты представлены далее.
XDR-система (Extended Detection and Response). Она представляет собой единую платформу из агентов, расположенных на всех Windows- и Linux-машинах в инфраструктуре.
В составе этой системы имеется распределённый хостовый файрвол, работающий на индивидуальном наборе правил для каждого устройства. На уровне ядра происходит фильтрация сетевой активности. С помощью агентов собирается подробная телеметрия с каждого устройства. Собранные данные помогают формировать скоринг. Эти данные также служат для косвенного контроля того, что каждая конкретная машина работает именно через корпоративный DNS. Эта проверка является существенной гарантией отсутствия подмены.
Контрольный файрвол. На стороне DNS-сервера развёрнута отдельная система, которая способна определить в настоящем времени, является ли запрошенный адрес легитимным для клиента. Файрвол собирает эту информацию в потоковом режиме и проверяет легитимность соединения. При необходимости соединение разрывается. Если добиться разрыва не удаётся, то формируется инцидент, который в дальнейшем становится предметом для расследования силами группы ИБ.
Файрвол 802.1x для IoT-устройств. Он установлен на уровне коммутаторов и служит для контроля IoT-устройств, принтеров, IP-камер и пр.
На базе собранных данных работает также оркестратор. В него стекается вся информация, собранная с четырёх названных сервисов ИБ, поступает также информация из других источников. Он формирует скоринг, списки и пр.
Альтернативные решения
Николай Жогин назвал также альтернативные решения, доступные на рынке, которые также выстроены на базе применения функций DNS. Это Cisco Umbrella, Microsoft Zero Trust DNS (ZTDNS), DNSFilter и SkyDNS.
Он отметил, что все названные альтернативные решения также используют энтропию Шеннона для выявления аномалий, но применяют её по-другому. Они не проводят оценку данных в настоящем времени, параллельно с выполнением обработки запросов. Свою оценку они используют совместно с другими факторами. Они заносят сомнительное соединение в список блокировки и проводят интегральную проверку по всем источникам. Её результат уже реализует саму блокировку, которая фактически происходит постфактум через 5−10 минут. В решении АО «Банк Инго» блокировка выполняется немедленно. В этом её преимущество, отметил Николай Жогин.
Альтернативные решения также уступают российскому по части валидации легитимности соединения с точки зрения DNS, подчеркнул спикер. Процедура предполагает сопоставление DNS-запроса с сетевыми действиями, что позволяет вынести определённый вердикт, является ли соединение легитимным или нет.
Программная платформа
Контролирующий DNS-сервер написан на языке Go. Для разбора DNS-запросов используется популярная библиотека miekg/dns.
Для управления кластером и конфигурацией нод используется gRPC. Для сбора системных логов и телеметрии, трафика, его обработки применяется система Vector.
Все данные поступают в базу данных ClickHouse, откуда с помощью Grafana выстроена визуализация ключевых метрик, ведётся мониторинг, оценивается SLA.
Рисунок 8. Важная часть конференции IT Elements 2025 связана с последующими дискуссиями
Выводы
В рамках третьей технологической конференции IT Elements 2025 был представлен ряд докладов, которые отражают практику применения существующих технологий для решения задач в области ИТ и ИБ. Одно из таких решений — система контроля DNS-запросов, реализованная в корпоративной системе АО «Банк Инго».
