Обсудить проект
17 сентября, 2026 · Безопасность

Honeypot и deception: ловушки внутри сети

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

Это не экзотика для крупных SOC. Базовые ловушки можно развернуть за пару дней на оборудовании, которое у тебя уже есть. В статье разберём, какие виды приманок существуют, как их разместить в сети itpages.lab.local (192.168.10.0/24), как собрать с них сигнал на srv-siem01 и как не навредить собственной инфраструктуре. Тактики ATT&CK, которые ловушки помогают обнаружить: Discovery, Credential Access, Lateral Movement, Collection.

Виды приманок

  • Honeypot (хост-приманка). Машина или служба, которая имитирует реальную, но не несёт полезной нагрузки. Любая попытка подключения подозрительна.
  • Honeytoken (приманка-данные). Фальшивая учётная запись, ключ, запись в базе, документ. Использование или чтение такого объекта сигнализирует о компрометации.
  • Canary-файлы и канарейки в каталогах. Файлы-приманки в общих папках, на которые настроен аудит доступа.
  • Записи-приманки в Active Directory. Учётные записи с привлекательными именами, которые нигде не используются.

Шаги

Шаг 1. Определи цели и принципы

Определи, какое поведение хочешь поймать. Для внутренней сети самые полезные задачи две: ранняя разведка (кто-то сканирует подсеть и перебирает общие ресурсы) и использование украденных учётных данных. Принципы, которые стоит соблюсти заранее:

  1. Ловушка не должна влиять на работу бизнеса и не должна иметь реальных связей с рабочими системами.
  2. Легитимные средства (сканеры уязвимостей, инвентаризация, мониторинг) должны быть известны и исключены из срабатываний, иначе шума не избежать.
  3. Приманка выглядит правдоподобно, но не содержит реальных секретов и реальных данных.
  4. Все срабатывания идут в отдельный канал высокой важности.

Шаг 2. Сетевые приманки

Самый простой вариант: выдели в подсети несколько неиспользуемых адресов (например, 192.168.10.200–192.168.10.205), поднеси на них лёгкую приманку и настрой сбор событий. Подойдёт любой открытый проект уровня honeypot с эмуляцией типовых служб: общий доступ к файлам, удалённый рабочий стол, веб-интерфейс с вымышленным именем. Размещай её в изолированной VLAN или хотя бы с жёсткими правилами на межсетевом экране: исходящий трафик от ловушки в рабочие сегменты должен быть запрещён.

Если отдельного решения нет, начни с ещё более простого. Сенсор srv-ids01 может фиксировать любые обращения к неиспользуемым адресам диапазона как сигнал разведки. Правило Suricata, которое поднимает алерт на попытку установить TCP-соединение с адресами-ловушками:

alert tcp $HOME_NET any -> [192.168.10.200,192.168.10.201,192.168.10.202] any (msg:"ITPAGES DECEPTION Connection to unused decoy address"; flags:S; classtype:attempted-recon; sid:9100001; rev:1;)

Если в сети есть легитимные сканеры, добавь исключение по адресу источника в переменной, например !$SCANNERS. Тактика ATT&CK: Discovery (Network Service Discovery).

Шаг 3. Учётные записи-приманки в AD

Создай в домене несколько учётных записей, которые выглядят привлекательно для разведки: например, с именами, намекающими на служебное назначение (резервное копирование, администрирование баз данных). Требования к ним строгие: пароль длинный и случайный, вход в систему запрещён политикой, учётная запись не входит ни в какие группы с правами и нигде не используется. Любое событие аутентификации с таким именем это сигнал.

На srv-dc01 это события 4768, 4769, 4771, 4776 и 4625, где поле имени пользователя совпадает с твоим списком приманок. Правило корреляции:

index=windows host=srv-dc01 EventCode IN (4624,4625,4768,4769,4771,4776)
  (TargetUserName IN ("svc-backup-old","adm-sqlmaint") OR ServiceName IN ("svc-backup-old","adm-sqlmaint"))
| table _time EventCode TargetUserName IpAddress Workstation

Имена выше условные: придумай свои, не совпадающие с реальными, и храни список в защищённом месте. Отдельно можно создать учётную запись с сервисным именем (SPN) без реального сервиса: запрос билета к такой службе в штатной работе невозможен, а значит, это сильный признак разведки по каталогу.

Шаг 4. Приманки-данные на файловых ресурсах

Размести в общих папках несколько файлов с заманчивыми названиями (план отпусков, список паролей, резервные копии конфигураций), но с пустым или вымышленным содержимым. Включи аудит доступа к ним: в свойствах файла добавь аудит чтения для группы Everyone и включи политику Audit File System. События 4663 (доступ к объекту) для этих файлов отправляются в SIEM.

index=windows EventCode=4663 ObjectName IN ("*\\Finance\\passwords_2026.xlsx","*\\IT\\vpn_backup.txt") AccessMask IN ("0x1","0x2")
| table _time SubjectUserName ObjectName Computer

Нюанс: резервное копирование и антивирус тоже читают файлы. Исключи их учётные записи и хосты, иначе правило будет стрелять каждую ночь. Тактика ATT&CK: Collection (Data from Network Shared Drive).

Шаг 5. Приманки на веб-сервере

Для srv-web01 хорошо работают приманки-страницы: например, закрытый путь в robots.txt, который никто не должен посещать, или страница входа в вымышленную админ-панель. Любой запрос на такой путь означает, что кто-то читает служебные файлы и пробует найти скрытое. Настрой правило в журнале веб-сервера: запрос к приманке поднимает алерт.

# фрагмент логики для разбора журнала доступа веб-сервера
location = /internal-admin-old/ {
    access_log /var/log/nginx/decoy_access.log combined;
    return 404;
}

Журнал decoy_access.log пересылается на srv-siem01 отдельным источником, и каждая запись в нём это уже повод проверить источник запроса. Здесь важно, что сервер отвечает нейтрально (404), не раскрывая приманку, но сам факт обращения фиксируется. Тактика: Discovery и Reconnaissance в части веб-приложений.

Шаг 6. Маршрутизация сигнала

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

Полезно связать сигнал с контекстом: одна запись в журнале приманки плюс другие события с этого же адреса (необычные входы, большое число подключений) составляют полную картину. Корреляция всех источников на srv-siem01 по IP-адресу источника даёт аналитику готовую хронологию.

Шаг 7. Эксплуатация и обновление

Ловушка живёт, пока её не раскрыли и пока она правдоподобна. Раз в квартал сверяй имена и расположение приманок с актуальным состоянием инфраструктуры: если в организации сменилась схема именования, фальшивые имена должны ей соответствовать. Раз в полгода проводи проверку: пусть коллега из команды в рамках согласованных учений обратится к приманке, и убедись, что алерт дошёл до дежурного за приемлемое время. Результат проверки записывай.

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

Шаг 8. Метрики и юридические вопросы

Чтобы доказать ценность программы deception руководству и себе, считай простые показатели: сколько срабатываний за месяц, сколько из них оказались легитимными (и почему), сколько реальных находок, за какое время от срабатывания до реакции. Хорошая ловушка почти не даёт ложных срабатываний, и каждое такое срабатывание ведёт к улучшению исключений. Если приманка молчит полгода, это не обязательно плохо: возможно, в сети тихо. Но проверь, что она жива: раз в квартал проводи контрольное обращение.

Не забывай о правовой стороне. Приманки внутри собственной сети обычно не вызывают проблем, но данные, собираемые с них, могут включать сведения о сотрудниках (имя учётной записи, рабочая станция). Закрепи в политике безопасности, что такой мониторинг ведётся, кто имеет доступ к журналам приманок и как долго они хранятся. Отдельно будь осторожен с приманками, доступными из интернета: они привлекают массу автоматического сканирования, не связанного с твоей организацией, и для внутренней защиты малоценны. Интереснее ловушки внутри периметра, где любой контакт значим.

Наконец, подумай о расширении. Когда базовый набор работает, добавляй разнообразие: приманки в разных VLAN, приманки в виде баз данных с пустыми таблицами, поддельные ключи доступа к облачным сервисам с мониторингом их использования на стороне провайдера, фальшивые записи в таблицах маршрутизации и в конфигурациях. Чем больше разнообразных приманок, тем выше шанс, что злоумышленник наткнётся на одну из них раньше, чем на настоящую цель.

Шаг 9. Что делать при срабатывании

Опиши порядок действий дежурного. Сначала зафиксируй факт: время, источник, что именно тронуто. Затем быстро оцени источник: известный сканер, администратор за плановой работой или неизвестный хост. Если источник неизвестен, не торопись отключать его мгновенно: сначала собери данные о его сетевой активности за последние часы, список открытых соединений и пользователя, под которым он работает, потому что после отключения часть информации пропадёт. После сбора изолируй хост на уровне сети и сообщи ответственным. Результат разбора добавь к карточке ловушки: это поможет понять, какие приманки действительно привлекают внимание.

Как внедрять поэтапно и проверять результат

Тема «Honeypot и deception: ловушки внутри сети» не стоит внедрять сразу на всю инфраструктуру. Начни с одного сегмента лаборатории itpages.lab.local, например с нескольких хостов в сети 192.168.10.0/24, и зафиксируй исходное состояние: какие события уже собираются, какие правила есть, сколько ложных срабатываний даёт текущая настройка. Без этой точки отсчёта потом невозможно понять, стало лучше или хуже.

  • Выбери пилотную группу систем и опиши ожидаемый результат одной фразой, которую можно проверить.
  • Внедри изменение, неделю наблюдай за шумом и пропусками, правь пороги и исключения.
  • Задокументируй настройку и владельца: кто отвечает за правило или процесс, когда его пересматривать.
  • Только после этого расширяй охват на остальные сегменты и повторяй проверку.

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

Частые ошибки и как их избежать

  • Приманка неправдоподобна. Хост с именем honeypot-01 и открытыми всеми портами отпугнёт любого внимательного человека. Называй объекты в стиле реальной инфраструктуры и открывай только те службы, которые типичны для такого типа машины.
  • Ловушка превращается в дыру. Приманка с настоящими уязвимыми службами и связью с рабочей сетью становится плацдармом. Изолируй её, запрети исходящий трафик в рабочие сегменты и не храни на ней реальных данных.
  • Алерты ловушки шумят. Сканеры уязвимостей и системы инвентаризации тоже трогают все адреса подряд. Составь список известных источников и исключи их на стороне правила, оставив для них отдельный отчёт.

Что дальше

Защита строится из нескольких слоёв — вот соседние темы серии:

Автор — Команда IT-Pages