Традиционные средства защиты — межсетевые экраны, антивирусы, SIEM-системы — работают по одной логике: обнаружить атаку и заблокировать её. Проблема в том, что они реагируют на уже свершившийся факт. Атакующий уже внутри периметра, уже изучает инфраструктуру, уже движется к цели — и только тогда срабатывает алерт. Deception меняет эту парадигму принципиально.
Что такое Deception и почему это важно
Технология кибер-ловушек основана на простой идее: если атакующий неизбежно столкнётся с ложными целями, он раскроет себя задолго до того как доберётся до реальных активов. Любое взаимодействие с ловушкой — это аномалия по определению, потому что легитимный пользователь туда никогда не пойдёт. Нет ложных срабатываний, нет шума — только чистый высококачественный сигнал. Именно поэтому deception-решения сегодня занимают отдельную нишу в корпоративной безопасности рядом с EDR, NDR и SIEM, а не заменяют их.
Какие ловушки существуют: классификация
Прежде чем говорить о разработке, важно понять что вообще представляет из себя современный deception-арсенал. Мы выделяем несколько принципиально разных классов.
- Сетевые сервисы — ловушки которые эмулируют или запускают нативные сервисы на стандартных портах. SSH (22), RDP (3389), SMB (445), FTP (21). Атакующий сканирует сеть, находит открытый порт, пытается подключиться — алерт. Во внутренней сети это высококачественный сигнал, потому что легитимного трафика к honeypot-хосту быть не должно по определению.
- Database honeypots — ловушки на портах баз данных: MySQL (3306), MSSQL (1433), PostgreSQL (5432), Redis (6379), Elasticsearch (9200). Атакующий который ищет базы данных уже глубоко внутри инфраструктуры — это сигнал с высоким приоритетом.
- API-ловушки — отдельный и особенно интересный класс. Docker API (2375), Kubernetes API (6443), Consul (8500), Jenkins (8080), Vault (8200). Это HTTP/JSON сервисы, простые в реализации и при этом крайне ценные как детектор — атакующий который ищет незащищённый Docker API или k8s кластер имеет вполне конкретные намерения.
- Active Directory ловушки — фейковые учётные записи в домене, honey SPN для детекции Kerberoasting, ложные записи в AD. Специфика Windows-среды, но именно здесь происходит большинство атак в корпоративных сетях.
- CanaryTokens — принципиально иной класс. Не сетевые сервисы, а самодостаточные артефакты: фейковые AWS-ключи, API-токены, документы с beacon URL внутри. При попытке использовать такой токен — немедленный алерт с IP атакующего. Работает даже через NAT, даже из изолированных сегментов сети.
- Lure-артефакты — направляющий слой. Файлы с фейковыми credentials, записи в .ssh/config, ярлыки на рабочих столах, строки в bash_history — всё что направляет атакующего к ловушке или содержит CanaryToken. Не детектируют сами по себе, но критически важны для создания убедительной картины.
Архитектурные решения которые мы приняли
Проектирование Deception-модуля для AVB Fort App поставило перед нами ряд нетривиальных архитектурных вопросов.
Первый и главный — качество fingerprint ловушек. Существующие opensource honeypot-движки (OpenCanary, Cowrie и аналоги) реализуют протоколы на уровне Python, а не через нативные системные сервисы. Это означает что агрессивное сканирование nmap с флагом -A или специализированные honeypot-детекторы способны идентифицировать ловушку. Для внутренней корпоративной сети это частично приемлемо — шум от внешних сканеров отсутствует, а большинство атак автоматизированы и не проверяют подлинность хоста. Но для серьёзного решения мы пошли дальше.
Наш подход: реальная ОС с нативными сервисами плюс агент-коллектор. Honeypot-хост это полноценная виртуальная машина с настоящим sshd, настоящим MySQL, настоящим nginx. Никакой эмуляции протоколов — fingerprint полностью нативный. Поверх работает наш лёгкий агент который читает системные логи и события, нормализует их и отправляет на центральную платформу. Атакующий взаимодействует с настоящим сервисом — алерт уже есть.
Второй вопрос — управление и масштабирование. Мы намеренно отказались от модели где центральный сервер ходит по SSH до каждого honeypot-хоста. Вместо этого агент при запуске сам забирает конфигурацию с платформы, разворачивает нужные сервисы, наполняет хост легендой и начинает отправлять события. При изменении конфига агент получает обновление через polling, применяет diff и перезапускает только изменившиеся сервисы. Это даёт горизонтальное масштабирование без усложнения центральной части.
Третий вопрос — роль приложения AVB Fort. Здесь ответ однозначный: Flask является плоскостью управления и отображения, но физически не запускает ловушки и не обрабатывает сырой трафик. Honeypot-агенты, сбор событий, нормализация — всё это отдельные процессы. Core видит только нормализованные события в PostgreSQL и управляющие команды через API. Это правильное разделение ответственности которое позволяет масштабировать каждый слой независимо.
Как работает цепочка детекции
Ключевое что отличает deception-решение от набора разрозненных ловушек — это связность детекции в цепочку.
Представим типичный сценарий. Атакующий получил доступ к рабочей станции внутри сети и начинает разведку. На файловой системе он находит файл docker-compose.yml с адресом внутреннего сервиса — это lure, размещённый заранее. Атакующий идёт по адресу и обнаруживает Docker API — honeypot фиксирует первый алерт. Исследуя API он запрашивает список контейнеров и получает правдоподобный JSON с переменными окружения — среди них fake AWS Access Key. Атакующий пробует использовать ключ — срабатывает CanaryToken, второй алерт уже с внешним подтверждением реального IP.
Три точки детекции одного атакующего, каждая последующая с более высоким уровнем уверенности. Именно такую цепочку мы проектируем в модуле — lure приводит к honeypot, honeypot содержит token, token даёт финальное подтверждение.
При этом важно понимать: алерт срабатывает при первом же взаимодействии с ловушкой. Даже если атакующий понял что попал в honeypot — информация уже получена. IP зафиксирован, время зафиксировано, использованные инструменты и техники зафиксированы. SOC получил уведомление. Опытный атакующий который обнаружил ловушку и ушёл — это тоже успех, он потратил время и раскрыл себя.
Интеграция в платформу AVB Fort
AVB Fort App развивался как awareness-платформа — обучение сотрудников, симуляция фишинга, формирование культуры безопасности. Deception-модуль органично расширяет эту концепцию на технический уровень.
Единый дашборд объединяет события от всех ловушек, CanaryTokens и lure-артефактов в одну ленту с приоритизацией по severity. Корреляция событий позволяет видеть цепочку действий одного атакующего across разных ловушек. Интеграция с существующими моделями платформы даёт контекст — инциденты от honeypots могут использоваться как реальные кейсы в обучающих программах для сотрудников SOC.
Технически модуль реализован как отдельный blueprint внутри Core с собственными моделями (Honeypot, DeceptionEvent, Lure, Token) и изолированным агентом который не пересекается с основной логикой платформы. Поток событий: агент на хосте → нормализатор → PostgreSQL + Redis → Flask dashboard.
Что дальше
Текущий этап разработки закрывает базовую инфраструктуру: агент, управление honeypot-хостами, API-ловушки, CanaryTokens, единый дашборд событий.
В roadmap следующие направления: полноценные AD-ловушки для Windows-доменных сред, поддержка OT/SCADA сегментов с промышленными протоколами (Modbus, DNP3), автоматическое наполнение легенды хостов для повышения реализма, и интеграция с внешними SIEM через CEF/syslog.
Deception — это не замена существующим средствам защиты. Это дополнительный слой который работает там где другие инструменты молчат: внутри периметра, после того как атакующий уже прошёл первую линию обороны. Именно там высококачественный сигнал без ложных срабатываний имеет наибольшую ценность.
