От uname до промпта на 919 тысяч символов: что показали три месяца наблюдений в двух ханипотах
26 мая один из посетителей SSH-сервиса провёл почти полтора часа в "сервере", который выглядел как обычный хостинг веб‑приложения. Он методично обошёл каталоги, нашёл конфигурационные файлы Bitrix, вытащил из них учётные данные к базе, попробовал выгрузить таблицы, а затем попытался записать PHP‑файл прямо в web root, рассчитывая закрепиться. Но за внешней правдоподобностью скрывалась декорация: файловая система, конфиг и "база" были частью эмуляции Cowrie и не давали атакующему ничего, кроме иллюзии успеха.
Спустя два месяца другой "клиент" наткнулся на открытый Ollama‑совместимый API, который выглядел как забытый dev‑стенд. Вместо банальной проверки `/api/tags` он развернул настоящую нагрузку: 27 374 запроса к `/api/chat`. По статистике это выглядело особенно красноречиво: медианный промпт - 2716 символов, каждый десятый - больше 155 тысяч, а рекордный запрос разросся до 919 294 символов. Внутри встречались переводы, суммаризация, извлечение фактов, задания для coding agents и даже целиком переданные системные инструкции. При этом "модели" за API не было вовсе - запросы уходили в пустоту, а атакующий продолжал работать, как будто получил бесплатный бэкенд.
Эти две истории - не про "кто атакует интернет" в абстрактном смысле. Они скорее про две экономики автоматизации. Старый стек пытаются быстро проинвентаризировать, нащупать слабое место, закрепиться и превратить сервер в очередной узел для дальнейших задач. А открытые AI‑интерфейсы всё чаще воспринимаются как готовая вычислительная услуга - иногда туда сразу льют реальную рабочую нагрузку, не особо заботясь о том, кому именно принадлежит инфраструктура.
Почему два стенда, а не ещё один Cowrie
Задача была не в сравнении "портов" и количества переборов паролей, а в том, чтобы увидеть, на каких этапах воронки взаимодействия застревают разные классы автоматизации. Большинство коротких экспериментов с ханипотами фиксирует две вещи: сколько раз попробовали root и какие команды ввели после входа. Это полезно, но почти не разделяет:
- транспортный шум (TCP‑соединения, протокольная путаница, мусорные методы),
- протокольную разведку (проверки SSH, MySQL, Ollama/OpenAI API или MCP),
- намерение (загрузка исполняемого файла, закрепление, кража вычислений, поиск секретов, попытка вызвать инструмент).
Здесь же два стенда были собраны так, чтобы внешняя сторона выглядела убедительно, но ни одна принятая команда не могла исполниться на реальном сервере - принципиально важный подход для тех, кто планирует установку и настройку honeypot не "для галочки", а как безопасный сенсор.
Что именно было развернуто
Первый стенд имитировал инфраструктуру поставщика промышленного оборудования и SCADA‑ПО:
- SSH на базе Cowrie с поддельной Unix‑файловой системой;
- MySQL‑подобный сенсор;
- HTTP/HTTPS‑фасад под корпоративный сайт на Bitrix;
- согласованные между сервисами конфигурационные файлы и honeytoken‑артефакты;
- сохранение загрузок и ограниченный PCAP.
Второй стенд выглядел как забытый AI gateway в среде разработки:
- Ollama‑совместимые эндпойнты `/api/*`;
- OpenAI‑совместимый интерфейс `/v1/*`;
- минимальный MCP по HTTP/SSE;
- status/docs‑поверхность, похожая на внутренний сервис;
- нормализованные события JSONL, полные тела запросов и PCAP.
При этом AI gateway ничего не "делал по‑настоящему": не поднимал inference, не тянул модели, не вызывал MCP‑инструменты, не выполнял shell‑команды и не ходил во внешние API. Само приложение слушало loopback, а наружу публиковалось через nginx. Административный SSH обоих серверов был отделён от публичной поверхности: без парольного входа, с firewall по allowlist - это базовый минимум, если вас интересует SSH защита сервера от взлома, а не просто сбор любопытных логов.
Cowrie в режиме эмулированной оболочки как раз и удобен тем, что хранит состояние "фейковой" файловой системы, пишет логины и команды, а также складывает для последующего разбора всё, что пытаются закачать через `wget`, `curl`, SCP или SFTP. То есть это не самописный перехват команд, а стандартная модель работы.
Объём наблюдений и "малая глубина"
За три месяца набралось около 312 тысяч SSH‑сессий - цифра звучит внушительно, но важнее другое: средняя глубина взаимодействия у подавляющего большинства попыток была небольшой. Массовые автоматизированные проверки часто ограничиваются быстрым "прощупыванием" поверхности. А вот редкие длинные эпизоды - вроде полутора часов в поддельном Bitrix - показывают более дорогие сценарии: поиск секретов, попытку вытащить базу, запись веб‑шелла, закрепление.
Отдельно проявилась интересная линия в MySQL‑направлении: одна кампания принесла сразу "сто тысяч паролей" в попытках подобрать доступ. Такой масштаб - хороший маркер не индивидуального взлома, а конвейера, который кормят утечками и словарями.
Показательно и то, что веб‑сканеры часто не "читают легенду" до первого запроса: внешний вид сайта и контент важны для человека, но автоматизация живёт иначе - ей нужны сигнатуры, ответы по известным путям и предсказуемые ошибки. С AI‑gateway картина обратная: "легенда" в виде docs/status иногда как раз помогает злоумышленнику быстро понять, куда и как отправлять запросы, превращая сервис в дармовой вычислительный контур. Об этом эксперименте удобно думать как о практическом мониторинге и анализе атак на сервер - не на уровне "кто стучался", а на уровне того, какие бизнес‑модели стоят за стуком.
Две воронки автоматизации и где ломаются измерения
Если раскладывать поведение на этапы, то у "старого" направления обычно просматривается воронка: обнаружение → первичный доступ → разведка файлов и конфигов → извлечение секретов → попытка закрепиться → загрузка полезной нагрузки. У AI‑направления - другая: обнаружение API → проверка совместимости → подстановка собственных промптов → эксплуатация ресурса как сервиса (иногда с реальными рабочими задачами) → попытки расширить возможности через инструменты/MCP.
На практике выяснилось, что измерять это непросто, и проблемы возникают не в атакующих, а в наблюдателе:
1) ротация логов сама по себе не гарантирует нужный retention - можно потерять "хвосты" длинных сессий;
2) repository config и live config способны расходиться, и это ломает сопоставление событий;
3) один источник логов не покрывает всю воронку (например, сетевые следы есть, а прикладные тела запросов уже обрезаны);
4) полный raw capture (PCAP/тела запросов) создаёт собственный риск - можно случайно собрать чужие секреты;
5) эвристика не равна атрибуции: похожие команды и юзер‑агенты ещё не доказывают "кто именно" стоит за кампанией.
Эта часть особенно важна тем, кто планирует не просто поставить сенсор, а выстроить повторяемый процесс: от наблюдения до корректных выводов и изменений в защите.
---
Что стоит сделать на реальных серверах (добавленные практические выводы)
Во‑первых, регулярно проверяйте публичную поверхность так, как это делает автоматизация: какие порты торчат наружу, какие dev‑эндпойнты забыты, не опубликованы ли случайно `/docs`, `/status`, тестовые `/api/*` и совместимые прокси под "OpenAI‑like" интерфейсы. Многие инциденты начинаются не с изощрённого эксплойта, а с неосторожной публикации сервиса, который "временно включили для удобства".
Во‑вторых, для веб‑проектов с Bitrix полезен не только патч‑менеджмент, но и точечная проверка конфигурации и прав: где лежат конфиги, кто может читать `.settings.php`, не попадает ли служебное в бэкапы в публичных каталогах, какие права у web‑пользователя на запись. В компаниях это обычно оформляют как Bitrix аудит безопасности сайта - и он окупается быстрее, чем разбор последствий после утечки базы.
В‑третьих, минимизируйте ценность компрометации SSH: отключайте парольный вход, оставляйте только ключи, вводите ограничение по IP там, где это возможно, следите за аномалиями в командах и попытках заливки файлов. Если вам нужна рабочая памятка по тому, как выглядит SSH защита сервера от взлома в реальности, полезно мыслить этапами воронки - от "нащупали" до "пытаются закрепиться".
В‑четвёртых, ханипот - это не игрушка "поставил и смотришь". Без дисциплины хранения данных, нормализации событий и ограничений на чувствительные фрагменты он легко превращается в источник новых рисков. Поэтому установку и настройку honeypot стоит сопровождать политикой: что именно пишется, как долго хранится, кто имеет доступ, как обезличиваются потенциально персональные и секретные данные.
В‑пятых, если инфраструктура действительно критична, не полагайтесь только на наблюдения. Там, где ставки высоки, нужны услуги тестирования на проникновение pentest: они помогают увидеть не только "кто стучится снаружи", но и что произойдёт при частичном доступе, как разворачивается латеральное перемещение, где лежат ключи, токены и доступы к CI/CD. И да, нередко именно pentest первым находит "забытый AI gateway" раньше, чем его найдут снаружи.
Наконец, важно принять простой факт: автоматизация по обе стороны растёт. Одни конвейеры всё быстрее перебирают старые поверхности и тянут конфиги, другие - без колебаний используют любой открытый AI‑интерфейс как бесплатный сервис. Поэтому выигрывает тот, у кого не "больше логов", а лучше связаны наблюдение, приоритизация и изменения в защите - от API‑гигиены до базовых настроек SSH и регулярных проверок веб‑платформ.