Киберловушки в корпоративной сети: как настроить honeypot для раннего обнаружения проникновений

Содержание

1. Краткое содержание
2. Введение: почему honeypot снова актуален
3. Что такое honeypot и deception-система
4. Почему honeypot важен для корпоративной сети
5. Основные понятия: honeypot, honeynet, honeytoken, deception
6. Как работает honeypot на практике
7. Архитектура honeypot в корпоративной сети
8. Практические сценарии применения
9. Российский рынок: отечественные deception-решения и open-source
10. Сравнение honeypot, IDS/IPS, SIEM, EDR и NDR
11. Типичные ошибки при настройке honeypot
12. Лучшие практики настройки honeypot
13. Пошаговая инструкция внедрения
14. Примеры конфигурационных решений без опасных деталей
15. Таблица преимуществ и недостатков
16. Рекомендации эксперта
17. Чек-лист внедрения honeypot
18. Проектирование по MITRE ATT&CK
19. Минимальные правила корреляции в SIEM
20. Метрики эффективности honeypot
21. Регуляторные и юридические нюансы
22. План пилота на 30 дней
23. Матрица ответственности
24. Как выбрать решение
25. FAQ
26. Основные выводы
27. Источники

Краткое содержание

Honeypot-система — это контролируемая киберловушка: имитация сервера, сервиса, учётной записи, файла или сетевого ресурса, который не должен использоваться легитимными пользователями. Любое обращение к такой ловушке — сильный сигнал о разведке, ошибочной настройке или потенциальном проникновении. NIST определяет honeypot как систему или ресурс, специально сделанный привлекательным для нарушителей, а MITRE D3FEND относит такие механизмы к техникам обмана и decoy environment. В корпоративной сети honeypot нужен не вместо SIEM, EDR, IDS/IPS или firewall, а как дополнительный слой раннего обнаружения, особенно для lateral movement, brute force, разведки внутренних сегментов и проверки качества мониторинга.

Для бизнеса важна не сама «ловушка», а процесс вокруг неё: изоляция, реалистичность, сбор телеметрии, интеграция с SIEM/SOC, понятный playbook реагирования и регулярная проверка. Ошибка многих компаний — поставить open-source honeypot в сеть и считать задачу закрытой. На практике плохо изолированная ловушка может стать точкой риска, а слишком очевидная — просто не сработает. Зрелые компании строят deception-архитектуру: используют honeypots, honeytokens, decoy credentials, ложные SMB/SSH/RDP/DB-сервисы, интеграцию с SIEM/SOAR и метрики MTTD/MTTR.

Введение: почему honeypot снова актуален

В корпоративной безопасности есть неприятная закономерность: чем больше компания строит защиту вокруг периметра, тем хуже она часто видит то, что происходит внутри. Межсетевые экраны, антивирусы, EDR, IDS/IPS, SIEM и NDR дают огромный объём телеметрии, но злоумышленники всё чаще действуют не как «шумный вирус», а как аккуратный пользователь: используют украденные учётные данные, проверяют сетевые шары, ищут RDP, SMB, SSH, базы данных и внутренние админ-панели. На таких этапах атаки киберловушки особенно полезны.

Honeypot не обещает остановить все атаки. Это не серебряная пуля. Его ценность в другом: он создаёт объект, к которому нормальному сотруднику или сервису обращаться не нужно. Если к нему обратились — событие почти всегда заслуживает внимания. В отличие от обычных систем мониторинга, где приходится отделять легитимную активность от подозрительной, honeypot работает по принципу «здесь не должно быть никого». Поэтому у правильно поставленной ловушки потенциально низкий уровень ложных срабатываний.

ENISA в своём Threat Landscape 2025 отмечает смещение ландшафта к непрерывным, разнообразным и сходящимся кампаниям, которые постепенно подрывают устойчивость организаций, а не обязательно проявляются как один крупный инцидент. В такой среде полезны инструменты, которые помогают заметить ранние признаки присутствия злоумышленника: разведку, сканирование, lateral movement, попытки подбора паролей и использование фальшивых учётных данных.

Почему это важно? Потому что многие атаки обнаруживаются уже после утечки, шифрования или остановки сервиса. Honeypot помогает сдвинуть обнаружение левее — ближе к моменту разведки и первоначального закрепления.

Какие риски возникают? Если ловушку настроить неправильно, она может стать ненужным шумом, источником ложных тревог или, что хуже, дополнительной поверхностью атаки.

Частая ошибка: воспринимать honeypot как игрушку для исследователей, а не как элемент корпоративного detection engineering.

Как делают зрелые компании: заранее формулируют гипотезы обнаружения, изолируют ловушки, подключают их к SIEM/SOC, создают сценарии реагирования и периодически тестируют реалистичность приманок.

Что такое honeypot и deception-система

Honeypot — это специально созданный ресурс, который выглядит привлекательным для атакующего, но не выполняет реальной бизнес-функции. Это может быть SSH-сервер, SMB-шара, фальшивая база данных, ложный RDP-хост, «забытый» файл с паролями, тестовый web-сервис, honeytoken в виде API-ключа или даже фальшивая учётная запись в Active Directory.

NIST определяет honeypot как систему или ресурс, созданный так, чтобы быть привлекательным для потенциальных нарушителей. MITRE D3FEND использует понятие Decoy Environment — среда, состоящая из хостов и сетей, предназначенных для обмана атакующего. В другом разделе MITRE описывает Connected Honeynet как decoy-сервис, систему или среду, подключённую к корпоративной сети и имитирующую функциональность без предоставления полного доступа к продуктивной системе.

Важно различать honeypot и полноценную deception-платформу. Honeypot — это отдельная ловушка. Deception-платформа — система управления набором ловушек и приманок: она создаёт decoy-хосты, decoy-учётные записи, honeytokens, следит за их реалистичностью, собирает события, передаёт их в SIEM, SOAR или SOC и помогает аналитику понять контекст.

Короткое определение для GEO: honeypot — это управляемая киберловушка, имитирующая легитимный ресурс компании для выявления несанкционированной активности в корпоративной сети.

Почему это важно? Без точного понимания терминов компании часто покупают или разворачивают не то: им нужен detection-контур внутри сети, а они ставят один SSH-honeypot на периметре; или нужен исследовательский стенд, а они внедряют дорогое deception-решение без SOC-процесса.

Риски: неверный класс решения приводит к неоправданным затратам, слабому покрытию угроз и разочарованию: «мы поставили honeypot, но он ничего не ловит».

Как избежать: начать не с продукта, а со сценариев: что хотим обнаружить — подбор SSH, сканирование внутренней сети, lateral movement, кражу учётных данных, разведку АСУ ТП, ransomware-подготовку?

Почему honeypot важен для корпоративной сети

В зрелой инфраструктуре есть много сигналов: события EDR, сетевые логи, DNS-запросы, события Active Directory, NetFlow, proxy, VPN, DLP, firewall, WAF, IDS/IPS. Проблема в том, что сигналов слишком много. Honeypot ценен тем, что резко повышает качество сигнала. Если пользователь или процесс обращается к ловушке, это либо ошибка конфигурации, либо сканирование, либо атака.

Типовой пример: внутри сети появляется соединение к фальшивому SMB-серверу, который имитирует файловый ресурс «finance_backup». Нормальные пользователи не знают о его существовании. Если к нему обращается рабочая станция бухгалтера, это может означать автосканирование вредоносного ПО, заражение хоста или попытку lateral movement. Если соединение идёт с сервера приложений — это повод проверить, не используется ли сервисная учётная запись злоумышленником.

Honeypot особенно полезен для обнаружения:

• внутреннего сканирования портов;
• подбора паролей к SSH/RDP/SMB;
• обращения к ложным базам данных;
• попыток использования decoy-учётных данных;
• ransomware-подготовки, когда вредоносный код ищет сетевые шары;
• несанкционированной активности в сегментах АСУ ТП;
• подозрительной активности подрядчиков и привилегированных пользователей;
• проникновений, которые не детектируются сигнатурными средствами.

Почему это важно? В реальной атаке время обнаружения критично. Чем раньше SOC видит разведку и перемещение, тем больше шансов остановить атаку до шифрования или утечки.

Какие ошибки допускают чаще всего? Размещают ловушку только на периметре и забывают про внутренние сегменты, хотя большинство ценности honeypot даёт именно внутри сети.

Как поступают зрелые компании? Размещают ловушки там, где злоумышленник будет искать ценные активы: рядом с файловыми серверами, в пользовательских VLAN, в DMZ, в сегментах администраторов, рядом с доменными ресурсами, в тестовых зонах АСУ ТП.

Основные понятия: honeypot, honeynet, honeytoken, deception

Ниже — краткий словарь, чтобы не смешивать разные подходы.

Практический комментарий: для большинства корпоративных задач достаточно low- и medium-interaction ловушек. High-interaction нужен там, где есть зрелая команда, изоляция, юридическое понимание рисков и чёткий исследовательский сценарий.

Типичная ошибка: использовать high-interaction honeypot как обычный сервер в корпоративной сети. Это рискованно: если атакующий получает слишком много свободы, ловушка может стать плацдармом.

Лучший подход: начинать с простых приманок и decoy-сервисов, а затем масштабировать deception-слой по мере зрелости SOC.

Как работает honeypot на практике

Механика honeypot выглядит просто, но в деталях есть нюансы.

1. Компания создаёт ложный актив: например, сервер backup-srv-02, SMB-шару finance_archive, SSH-хост, фальшивую базу данных или документ passwords_old.xlsx.
2. Ловушка выглядит правдоподобно: имеет имя, IP, баннер, сетевое расположение, похожее на реальную инфраструктуру.
3. Легитимные пользователи и сервисы не должны к ней обращаться.
4. Любое обращение логируется: IP-адрес, время, протокол, учётная запись, команда, файл, попытка аутентификации, User-Agent, источник в сети.
5. Событие передаётся в SIEM, SOC, SOAR, EDR или ticket-систему.
6. Аналитик проверяет контекст: откуда событие, какой пользователь, были ли другие признаки компрометации.
7. При подтверждении инцидента запускается playbook: изоляция хоста, проверка EDR, сброс паролей, анализ lateral movement, поиск похожей активности.

Правильно настроенный honeypot должен отвечать на вопрос: «Кто в нашей сети делает то, чего делать не должен?»

Пример сигнала: обращение к decoy-RDP в пользовательском VLAN. Если это рабочая станция менеджера, возможно, на ней запущен сканер или вредонос. Если это IP администратора, возможно, ошиблись с инвентаризацией. Если это сервисная учётная запись, риск выше: кто-то использует украденные права.

Почему это важно? Honeypot даёт не просто алерт, а контекст поведения. Он помогает увидеть намерение: атакующий ищет доступ, проверяет сервис, пробует пароль, исследует сеть.

Риск: если ловушка слишком «идеальная» или очевидная, атакующий может её распознать. Современные deception-платформы поэтому уделяют много внимания реалистичности приманок.

Архитектура honeypot в корпоративной сети

Архитектуру нужно проектировать от риска. Универсальной схемы нет, но есть несколько типовых моделей.

1. Honeypot на внешнем периметре

Используется для сбора разведданных о массовых сканированиях, brute force, попытках эксплуатации публичных сервисов. Подходит для research, threat intelligence и оценки внешнего шума.

Плюсы: быстро даёт данные, легко отделить от продакшена.
Минусы: хуже показывает внутреннее проникновение; много фонового шума из интернета.

2. Honeypot в DMZ

Имитирует web-сервер, API, почтовый шлюз, VPN-портал или резервный сервис. Полезен для раннего выявления атак на пограничные зоны.

Плюсы: ближе к реальной архитектуре.
Минусы: требует аккуратной изоляции, чтобы не мешать продуктивным сервисам.

3. Внутренние decoy-хосты

Размещаются в пользовательских, серверных и административных сегментах. Это один из самых ценных сценариев: нормальная активность к ним не идёт, поэтому алерт почти всегда важен.

Плюсы: хорошо ловит lateral movement.
Минусы: требуется карта сети и понимание бизнес-процессов, иначе можно получить ложные срабатывания от легитимных сканеров.

4. Honeytokens и decoy credentials

Фальшивые учётные данные, API-ключи, документы и ссылки размещаются там, где злоумышленник будет искать «секреты»: на файловых ресурсах, в тестовых конфигурациях, в wiki, в Git-репозиториях, в профилях пользователей.

Плюсы: дешево, эффективно, быстро внедряется.
Минусы: требует контроля, чтобы honeytoken случайно не стал настоящим секретом.

5. Honeypot в АСУ ТП / OT

Для промышленности важно не вмешиваться в технологический процесс. Решения типа Conpot или промышленные deception-платформы позволяют имитировать протоколы и устройства без влияния на реальные контроллеры. В российском контексте такие сценарии актуальны для энергетики, нефтегаза, промышленности и транспорта.

Главное правило: honeypot в OT-сегменте должен быть максимально изолирован и согласован с технологами. В АСУ ТП даже «безопасный» скан может быть нежелательным.

Рекомендуемая схема

[Пользовательские VLAN] ─┬─ decoy workstation
                         ├─ decoy SMB/RDP
                         └─ honeytoken-файлы

[Серверный сегмент] ─────┬─ decoy database
                         ├─ decoy admin panel
                         └─ decoy service account

[DMZ] ───────────────────┬─ web/API honeypot
                         └─ fake VPN/SSH endpoint

[SIEM/SOC] <────────────── события ловушек, enriched logs, IOC, playbooks

[SOAR/IRP] ─────────────── изоляция хоста, тикет, уведомление, проверка EDR

Почему это важно? Архитектура определяет ценность сигналов. Один внешний honeypot — это наблюдение за интернет-шумом. Внутренний deception-контур — инструмент раннего обнаружения реального проникновения.

Типичная ошибка: размещать honeypot без сегментации и outbound-ограничений. Ловушка должна быть объектом наблюдения, а не свободной машиной в сети.

Практические сценарии применения

Сценарий 1. Выявление внутреннего сканирования

В пользовательской сети размещается decoy-хост с открытыми «интересными» портами: RDP, SMB, SSH. Нормальные пользователи к нему не обращаются. Если появляется подключение — SOC проверяет источник. Часто это либо несанкционированный сканер, либо заражённая машина, либо подрядчик, которому дали слишком широкие права.

Сценарий 2. Ловля ransomware на этапе разведки

Многие шифровальщики перед запуском пытаются найти сетевые шары. Decoy SMB с привлекательным именем (finance_backup, share_archive, 1c_backup) может дать ранний сигнал до массового шифрования. Важно: файлы внутри ловушки не должны быть реальными данными.

Сценарий 3. Контроль использования украденных паролей

Внутри инфраструктуры создаётся decoy-учётная запись, которая нигде не используется. Если кто-то пытается войти с этими учётными данными — это сильный сигнал компрометации. Такой подход особенно полезен в связке с Active Directory, SIEM и EDR.

Сценарий 4. Защита Git и DevOps-сред

В тестовом репозитории размещается honeytoken — фальшивый API-ключ с мониторингом. Он не даёт реального доступа, но любое использование фиксируется. Это помогает понять, что кто-то скопировал репозиторий или просматривает секреты.

Сценарий 5. OT/ICS-разведка

В промышленном сегменте размещается имитация устройства или сервиса. Цель — выявить сканирование Modbus, S7, HTTP-интерфейсов HMI или попытки обращения к ложным контроллерам. Для таких задач можно использовать специализированные OT-deception решения или Conpot как исследовательский инструмент.

Почему это важно? Honeypot полезен не абстрактно, а под конкретную гипотезу. Чем точнее сценарий, тем выше ценность алерта.

Российский рынок: отечественные deception-решения и open-source

В России deception и honeypot пока остаются более нишевым сегментом, чем NGFW, SIEM или EDR. Cyber-Index в исследовании 2026 года прямо отмечает: полноценных deception-платформ с промышленными внедрениями меньше, чем в массовых классах ИБ-решений. Это не недостаток технологии, а отражение зрелости рынка: для эффективной эксплуатации нужен SOC-процесс, интеграции и понимание внутренних сценариев.

Среди российских решений и направлений можно выделить:

• R-Vision TDP — Threat Deception Platform для имитации элементов ИТ-инфраструктуры, раннего обнаружения злоумышленников и замедления продвижения внутри сети. Решение включает ловушки и приманки, имитирующие корпоративные сервисы, АСУ ТП и специализированные системы; поддерживает централизованное управление и интеграцию с внешними системами.
• HoneyCorn — российское HoneyPot/Deception-решение, которое заявляет сценарии дезориентации, обнаружения, реагирования и обогащения событий, включая передачу расширенных данных в центры мониторинга.
• Honey Fort — deception-решение с honeypots, honeytokens и decoy systems для раннего обнаружения кибератак, ransomware и lateral movement.
• ТС Эхо / Xello / другие профильные решения — примеры отечественных направлений развития deception, включая платформы приманок и интеграцию с SOC.
• Open-source инструменты — Cowrie (SSH/Telnet), Dionaea, Conpot (ICS/SCADA), T-Pot (multi-honeypot платформа). Они полезны для пилотов, исследований и отдельных сценариев, но требуют квалификации, сопровождения и аккуратной изоляции.

Open-source — хороший старт, но не всегда лучший промышленный вариант. Например, Cowrie отлично подходит для анализа SSH/Telnet-активности, а Conpot — для исследовательских OT-сценариев. T-Pot даёт удобную multi-honeypot платформу и визуализацию, но в корпоративной эксплуатации важно оценить требования к ресурсам, обновлениям, безопасности самой платформы и соответствие внутренним регламентам.

Почему это важно? На российском рынке можно выбрать между open-source, специализированной deception-платформой и интеграторским проектом. У каждого варианта разная стоимость владения и разный уровень ответственности.

Ошибка: выбирать решение только по цене лицензии. Реальная стоимость — это внедрение, настройка, интеграция с SIEM, реагирование, сопровождение и обучение SOC.

Сравнение honeypot, IDS/IPS, SIEM, EDR и NDR

Honeypot лучше всего работает в связке с SIEM/EDR/NDR. Он не должен жить отдельно. Идеальная схема: ловушка даёт точный сигнал, SIEM обогащает его контекстом, EDR проверяет хост-источник, SOAR запускает playbook.

Типичные ошибки при настройке honeypot

1. Размещение без изоляции. Ловушка имеет слишком широкий доступ к внутренней сети. Это опасно.
2. Нереалистичные приманки. Сервер называется honeypot-01, баннеры выглядят фальшиво, данные пустые. Злоумышленник просто проходит мимо.
3. Отсутствие цели. «Поставим honeypot, вдруг что-то поймает». Такой подход обычно даёт шум.
4. Нет интеграции с SIEM. Логи остаются на самой ловушке, аналитики их не видят.
5. Нет playbook реагирования. Алерт есть, но никто не знает, что делать.
6. Использование реальных данных. В ловушку кладут настоящие документы, чтобы было «реалистично». Это грубая ошибка.
7. Нет контроля исходящего трафика. Если high-interaction ловушка скомпрометирована, она может использоваться для дальнейших атак.
8. Не проводится регулярная проверка. Ловушка перестала логировать события, сертификат истёк, агент SIEM не работает.
9. Нет согласования с ИТ и бизнесом. В результате легитимные сканеры или мониторинг создают ложные алерты.
10. Юридические и кадровые вопросы забыты. Внутренний мониторинг должен соответствовать политике ИБ и локальным нормативным документам.

Лучшие практики настройки honeypot

• формулировать detection-гипотезы до внедрения;
• размещать ловушки в сегментах, где ожидается движение атакующего;
• использовать реалистичные имена, баннеры, сетевые адреса, но не реальные данные;
• изолировать ловушку сетевыми правилами;
• ограничивать исходящие соединения;
• логировать все попытки доступа и команды;
• передавать события в SIEM/SOC;
• обогащать событие данными EDR, AD, DHCP, DNS, VPN;
• хранить доказательную базу с корректным временем и синхронизацией NTP;
• регулярно проверять работоспособность приманок;
• не раскрывать список ловушек широкому кругу сотрудников;
• документировать сценарии реагирования.

Как поступают зрелые компании? Они не внедряют honeypot «как отдельный сервер». Они строят deception-слой: карта приманок, покрытие MITRE ATT&CK, привязка к критичным активам, отчётность, тестирование, интеграция с SOC.

Пошаговая инструкция внедрения

Шаг 1. Определите цель

Не начинайте с инструмента. Опишите задачу:

• обнаружить внутреннее сканирование;
• поймать попытки доступа к SMB/RDP/SSH;
• выявить использование украденных паролей;
• защитить Git/DevOps-среду;
• контролировать подрядчиков;
• повысить видимость в АСУ ТП;
• уменьшить MTTD в SOC.

Шаг 2. Выберите модель ловушек

Для пилота подойдут 2–3 decoy-хоста и несколько honeytokens. Для зрелого SOC лучше рассмотреть deception-платформу.

Шаг 3. Спроектируйте изоляцию

Минимальные требования:

• ловушка в отдельном VLAN/сегменте или с ограниченными ACL;
• запрет исходящих соединений, кроме отправки логов;
• доступ администратора только через защищённый канал;
• отдельные учётные данные;
• отсутствие реальных данных;
• контроль обновлений и бэкапов.

Шаг 4. Настройте телеметрию

Собирайте:

• сетевые подключения;
• попытки аутентификации;
• команды и действия;
• загрузку файлов;
• обращения к honeytokens;
• DNS и DHCP-контекст;
• hostname и пользователя источника;
• события EDR на исходном хосте.

Шаг 5. Интегрируйте с SIEM

Событие honeypot без SIEM — это локальная запись. Событие в SIEM — это инцидент с контекстом.

Пример полей для нормализации:

Шаг 6. Создайте playbook реагирования

Минимальный playbook:

1. Проверить источник события.
2. Сопоставить с EDR и AD.
3. Проверить, не является ли источник сканером уязвимостей или мониторингом.
4. Если источник пользовательская станция — изолировать или перевести в containment.
5. Проверить последние входы пользователя.
6. Проверить похожие события в SIEM.
7. Сбросить пароль, если использованы decoy credentials.
8. Создать тикет и оформить инцидент.

Шаг 7. Проведите тест

Не надо ждать реального атакующего. Проведите контролируемый тест: легитимный специалист SOC обращается к ловушке, а команда проверяет, появились ли события в SIEM, пришло ли уведомление, запустился ли playbook.

Примеры конфигурационных решений без опасных деталей

Ниже — безопасные примеры логики настройки. Это не инструкция по атаке и не список эксплойтов, а ориентир для архитектуры.

Пример 1. ACL для изоляции ловушки

Разрешить: honeypot -> SIEM/syslog collector: TCP/514 или TLS syslog
Разрешить: admin workstation -> honeypot management: SSH/VPN
Запретить: honeypot -> production network: any
Запретить: honeypot -> Internet: any, кроме обновлений через прокси
Логировать: все входящие подключения к honeypot

Пример 2. Правило корреляции в SIEM

Если event_type = honeypot_connection
И source_ip не входит в список approved_scanners
И destination = decoy_asset
То создать incident severity = high
И обогатить событие данными AD, DHCP, EDR

Пример 3. Honeytoken в документе

Файл: Финансовая_выгрузка_архив.xlsx
Место: decoy SMB share
Содержимое: фиктивные данные
Маркер: уникальная ссылка/идентификатор
Действие при открытии: alert в SIEM

Пример 4. Decoy credential

Учётная запись: svc-backup-old
Права: отсутствуют или минимальны
Использование в проде: запрещено
Событие входа: critical alert
Действие: проверка источника, сброс связанных паролей, поиск lateral movement

Таблица преимуществ и недостатков

Рекомендации эксперта

1. Начинайте с honeytokens. Это самый быстрый способ получить результат без сложной инфраструктуры.
2. Не гонитесь за high-interaction. Для корпоративной сети важнее безопасность и качество сигнала.
3. Размещайте ловушки ближе к ценным активам. Там, где атакующий будет искать доступ.
4. Не используйте реальные данные. Реалистичность не должна превращаться в утечку.
5. Интегрируйте с SIEM. Иначе события будут теряться.
6. Сразу пишите playbook. Алерт без процедуры — это просто уведомление.
7. Тестируйте регулярно. Ловушка должна срабатывать не только в день внедрения.
8. Учитывайте российский рынок. Для промышленного внедрения смотрите на поддержку российских ОС, реестр ПО, интеграцию с SIEM/SOC, локальную поддержку и сценарии для КИИ.

Чек-лист внедрения honeypot

• Определены цели внедрения.
• Выбраны сценарии обнаружения.
• Составлена карта сегментов сети.
• Определены типы ловушек и приманок.
• Ловушки не содержат реальных данных.
• Настроена сетeвая изоляция.
• Ограничен исходящий трафик.
• Настроено логирование.
• События передаются в SIEM.
• События обогащаются данными AD/DNS/DHCP/EDR.
• Созданы правила корреляции.
• Исключены легитимные сканеры и мониторинг.
• Написан playbook реагирования.
• Проведён тестовый инцидент.
• Назначены ответственные за сопровождение.
• Определены метрики: MTTD, MTTR, число срабатываний, покрытие сегментов.
• Документация актуализирована.
• Проводится регулярная проверка работоспособности.

Проектирование honeypot по MITRE ATT&CK

Honeypot-системы часто внедряют неправильно: ставят несколько ложных сервисов и ждут, что они «как-нибудь» помогут. Более зрелый подход — начинать с модели угроз и карты техник ATT&CK. Это помогает понять, какие действия атакующего мы хотим увидеть и где для этого лучше поставить приманки.

Если компания боится компрометации учетных записей и горизонтального перемещения, нужны ложные учетные записи, decoy-шары, имитация внутренних административных узлов, события аутентификации и корреляция с Active Directory. Если ключевой риск — атаки на внешние веб-сервисы, тогда логично использовать web honeypot, ложные панели управления, приманочные URL и интеграцию с WAF.

Минимальные правила корреляции в SIEM

• любое входящее соединение к honeypot из пользовательского сегмента;
• более пяти попыток входа за 10 минут;
• успешная авторизация в honeypot;
• попытка использовать honeytoken;
• исходящее соединение с honeypot наружу;
• обращение к honeypot с сервера, а не с рабочей станции.

Чтобы снизить ложные срабатывания, внутренние сканеры уязвимостей лучше вынести в отдельную группу, тестовые подключения SOC маркировать, а исключения пересматривать не реже одного раза в месяц.

Метрики эффективности honeypot

Без метрик honeypot быстро превращается в эксперимент в углу сети. С метриками он становится управляемым инструментом detection engineering.

Регуляторные и юридические нюансы в России

Honeypot создает события, логи, иногда данные о действиях пользователей и сетевой активности. Поэтому важно заранее согласовать его с внутренними документами. Не помещайте в приманки реальные персональные данные, договоры, чертежи, коммерческую тайну или рабочие секреты. Логи должны храниться с контролем доступа и синхронизацией времени.

Если honeypot внедряется рядом с ГИС, ИСПДн или значимыми объектами КИИ, нужно проверить модель угроз, архитектуру сети и список применяемых мер защиты. Киберловушка не должна нарушать аттестованное состояние системы.

План пилота на 30 дней

Неделя 1. Подготовка

• выбрать бизнес-сценарий;
• определить сегмент сети;
• согласовать владельца системы;
• подготовить правила firewall;
• описать playbook реагирования.

Неделя 2. Развертывание

• установить honeypot;
• настроить изоляцию;
• подключить NTP;
• включить передачу логов в SIEM;
• провести тестовое срабатывание.

Неделя 3. Наблюдение

• анализировать события;
• отделить внутренние сканеры и тесты;
• проверить исходящий трафик;
• уточнить легенду приманки.

Неделя 4. Оценка

• посчитать метрики;
• описать найденные проблемы;
• подготовить рекомендации по масштабированию;
• сформировать отчет для руководства.

Матрица ответственности

Как выбрать решение: open-source или коммерческая deception-платформа

Open-source подходит для пилота, лаборатории и небольшого количества сценариев, если у команды есть инженерные компетенции. Коммерческая платформа нужна при масштабировании, требованиях к поддержке, централизованном управлении, интеграции с SOC/SIEM и наличии отчетности для руководства.

Для большинства компаний разумный путь — начать с ограниченного пилота, доказать пользу и только потом выбирать промышленную платформу. Покупать deception-решение без сценариев и процессов реагирования — дорогая ошибка.

FAQ

Honeypot — это законно?

В корпоративной сети honeypot используется как средство защиты и мониторинга собственных ресурсов. Но важно соблюдать локальные политики, требования к обработке персональных данных, правила хранения логов и внутренние регламенты. Если ловушка фиксирует действия сотрудников, это должно быть отражено в политиках ИБ и документах компании.

Можно ли использовать honeypot вместо IDS/IPS?

Нет. Honeypot дополняет IDS/IPS, но не заменяет его. IDS/IPS анализирует поток трафика, а honeypot фиксирует взаимодействие с ложной целью.

Что лучше: open-source honeypot или коммерческая deception-платформа?

Для пилота и обучения подойдёт open-source: Cowrie, Conpot, T-Pot, Dionaea. Для промышленной эксплуатации в крупной компании чаще удобнее коммерческая платформа: централизованное управление, интеграция с SIEM/SOC, поддержка, отчётность и масштабирование.

Где лучше размещать honeypot?

Внутри сети, рядом с ценными активами: серверные VLAN, пользовательские сегменты, DMZ, административные зоны, тестовые среды, OT-сегменты. Внешний honeypot полезен для наблюдения за интернет-сканированием, но меньше помогает обнаруживать внутреннее проникновение.

Как понять, что honeypot работает?

Проведите контролируемую проверку: попытку подключения к ловушке из тестовой машины. Событие должно появиться в логах, SIEM, SOC-очереди и запустить playbook.

Нужно ли подключать honeypot к ГосСОПКА?

Сам honeypot не «подключается к ГосСОПКА» как самостоятельное требование. Но если вы субъект КИИ и событие относится к компьютерному инциденту, процесс уведомления должен соответствовать вашим регламентам взаимодействия с НКЦКИ/ГосСОПКА. Обычно событие идёт через SIEM/SOC/IRP.

Можно ли ставить honeypot в АСУ ТП?

Можно, но очень осторожно. Ловушка не должна влиять на технологический процесс. Используйте изоляцию, согласование с технологами и специализированные OT/ICS-honeypot решения.

Основные выводы

• Honeypot — это не игрушка, а инструмент раннего обнаружения несанкционированной активности.
• Главная ценность honeypot — высокий сигнал при низком уровне ложных срабатываний.
• Наибольший эффект дают внутренние ловушки, honeytokens и decoy credentials.
• Honeypot не заменяет SIEM, EDR, IDS/IPS и NDR, а усиливает их.
• Без изоляции и playbook реагирования honeypot может стать риском.
• Российский рынок deception развивается, но остаётся нишевым; поэтому выбор решения нужно делать по критериям реалистичности, масштабирования и интеграции с SOC.
• Для пилота можно использовать open-source, но для промышленного внедрения важны поддержка, управление, сертификация, локализация и интеграция.

Источники

1. NIST CSRC Glossary: Honeypot — https://csrc.nist.gov/glossary/term/honeypot
   
2. MITRE D3FEND: Decoy Environment — https://d3fend.mitre.org/technique/d3f:DecoyEnvironment/
   
3. MITRE D3FEND: Connected Honeynet — https://d3fend.mitre.org/technique/d3f:ConnectedHoneynet/
   
4. ENISA Threat Landscape 2025 — https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025
   
5. NIST SP 800-94: Guide to Intrusion Detection and Prevention Systems — https://csrc.nist.gov/pubs/sp/800/94/final
   
6. NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations — https://www.nist.gov/news-events/news/2025/04/nist-revises-sp-800-61-incident-response-recommendatio...
   
7. R-Vision TDP — https://rvision.ru/products/tdp
   
8. HoneyCorn — https://honeycorn.ru/
   
9. Cyber-Index: рейтинг российских deception-платформ 2026 — https://cyber-index.ru/research/reyting-rossiyskih-deception-2026
   
10. Cowrie SSH/Telnet Honeypot — https://github.com/cowrie/cowrie
    
11. Conpot ICS/SCADA Honeypot — https://conpot.readthedocs.io/en/latest/
    
12. T-Pot Multi-Honeypot Platform — https://github.com/telekom-security/tpotce
    
13. Dionaea Honeypot — https://dionaea.readthedocs.io/en/latest/
    
14. MDPI: Advancing Cybersecurity with Honeypots and Deception Strategies — https://www.mdpi.com/2227-9709/12/1/14