Я поднял на своём сервере SSH-ловушку: она притворяется беззащитным Linux, пускает почти с любым паролем и записывает всё, что делают внутри. Настоящей системы там нет. За первые пять дней в неё пришло 24 218 сессий с 683 адресов.
Мне хотелось увидеть атаки не в отчётах и учебниках, а на собственном сервере: кто приходит, что вводит и чем одна атака отличается от другой. Статистика чужих компаний отвечает на вопрос «сколько», а ловушка показывает «как».
Находят быстро и пробуют очевидное
Обычный промежуток между новыми сессиями составляет около пяти секунд. Сервер нигде не рекламировался: его находят сканеры, которые постоянно обходят весь интернет.
Самые частые пароли предсказуемы: 123456, 123, 1234, 12345678. Среди логинов, кроме root, встречаются ubuntu, admin, deploy, postgres, а ещё claude: боты уже ищут учётные записи разработчиков с ИИ-инструментами. Вывод простой: вход по паролю на публичном сервере живёт недолго.
Один бот дал почти 90% всего шума
Самое интересное оказалось в распределении. 21 217 сессий, то есть 88%, сделало одно семейство с 18 адресов. Оно заходит и выполняет единственную команду:
uname -s -v -n -r -mИ уходит. Похоже, это не взлом, а инвентаризация: бот проверяет, подошёл ли пароль и что за система внутри. Доказать это я не могу, но поведение подходит под сбор списка доступных серверов, к которым можно вернуться позже или передать кому-то ещё.
Отсюда первый практический урок: считать сессии бесполезно. Один шумный бот заглушает всё остальное, поэтому я перестроил эксперименты так, чтобы учитывать адреса, а не сессии.
Самое массовое семейство оставляет ключ
Семейство с наибольшим числом адресов, 291, делает другое: снимает защиту с папки .ssh, удаляет её, создаёт заново и записывает свой ключ. Всё занимает считанные секунды:
cd ~ && rm -rf .ssh && mkdir .ssh && echo <ключ> >> .ssh/authorized_keysУдаление старой папки важно: на настоящем сервере оно лишило бы входа и хозяина, и других ботов. А ещё смена пароля после такого не поможет: ключ останется. Поэтому при подозрении на взлом стоит проверять не только пароли, но и файл authorized_keys, задания cron и список пользователей.
Что боты оставили в ловушке
Ловушке запрещены исходящие соединения, поэтому скачать ничего она не может. Но боты загружают файлы сами: за это время накопилось 22 файла, из них 17 программ для Linux под разные архитектуры, включая x86-64, ARM и AArch64. В нескольких есть признаки XMRig, майнера криптовалюты: файлы разбираются только как данные и никогда не запускаются. Цель большинства атак скучная: чужой процессор.
Как я два дня не замечал, что половина защиты молчит
Самая полезная часть оказалась вовсе не про ботов. Рядом с ловушкой работают смоляная яма и приманки баз данных, и два дня их счётчики стояли на нуле. Служба работала, правило брандмауэра было на месте, его счётчик даже рос. Локальная проверка проходила.
Разобраться помог tcpdump: запросы приходили, а ответов не было. В итоге нашёлся второй брандмауэр. Разрешение в первом не отменяет запрет во втором: пакет должен пройти оба. Счётчик первого показывал, что всё хорошо, и это было правдой только наполовину.
Вывод: проверка изнутри не доказывает, что сервис доступен снаружи. Счётчик брандмауэра тоже не доказывает: он говорит только о своём участке пути. Самый надёжный ответ дал простой опыт: настоящее подключение извне и наблюдение за пакетами.
Что дальше
Следующий вопрос: смотрят ли боты на то, с чем имеют дело. Ловушка каждый день меняет маскировку: имя сервера и версию системы. Через несколько недель будет видно, реагируют ли на это боты или им всё равно. Если всё равно, это тоже результат, и о нём тоже будет заметка.