Почему AutoAddPolicy в SSH — это не удобство, а критическая уязвимость

В одном из проектов я обнаружил четырнадцать копий одного IP-адреса. Каждая копия жила в отдельном скрипте автоматизации: деплой кода на боевой сервер, перезапуск сервисов, правка DNS-записей или диагностика почты. Это классический пример копипаста, который работает стабильно ровно до первого инфраструктурного изменения. Переезд случился внезапно, адрес сервера изменился, и все четырнадцать автоматизированных процессов одновременно начали указывать в пустоту. Однако технические сбои при смене адреса — это лишь верхушка айсберга. Главная проблема кроется в том, как именно эти скрипты были настроены для взаимодействия с новыми хостами через протокол SSH.

Анатомия проблемы управления ключами хоста

Когда клиент SSH впервые подключается к новому серверу, он получает его публичный ключ (fingerprint). По умолчанию библиотека Paramiko (популярный Python-клиент) должна бросить исключение HostKeysException, если ключа нет в локальном файле known_hosts. Разработчики часто ленятся прописывать ключи вручную и используют конструкцию client.set_missing_host_key_policy(paramiko.AutoAddPolicy()). Эта строка буквально говорит системе: «Если ты видишь незнакомый сервер, просто слепо доверься ему и добавь его ключ в память без проверки». В контексте одноразовых тестов это экономит время, но в продакшене это эквивалентно тому, чтобы оставить входную дверь открытой с табличкой «Заходите кто хотите».

Проблема усугубляется тем, что AutoAddPolicy делает инфраструктуру абсолютно прозрачной для злоумышленника. Если скрипт запускается регулярно (например, каждые 5 минут для мониторинга), то окно возможностей для атаки становится практически непрерывным. Атакующему достаточно перехватить трафик или занять позицию между вашим CI/CD-раннером и целевым сервером, чтобы подменить свой ключ. Скрипт даже не пикнет предупреждением, так как политика безопасности была выключена программистом ради удобства написания первых десяти строк кода.

Риски эксплуатации MITM-атак

Отключение проверки отпечатков ключей превращает любое ваше подключение в идеальную мишень для атаки «человек посередине» (Man-in-the-Middle). Представьте ситуацию: вредоносный узел встает на пути трафика вашего скрипта резервного копирования. Поскольку проверка отключена, ваш скрипт устанавливает зашифрованный туннель напрямую со злоумышленником, думая, что это корпоративный шлюз. Злоумышленник расшифровывает данные от вас, читает их или модифицирует, затем перешифровывает реальным ключом сервера и отправляет дальше. Вы получаете подтверждение успешной операции, а ваши учетные данные администратора уже утекли.

Более того, использование жестко заданных IP-адресов вместо имен DNS внутри скриптов создает дополнительный вектор отказа в обслуживании. Как показал мой опыт с четырнадцатью скриптами, изменение одной цифры в адресе парализует всю автоматизацию. Но если бы использовалась AutoAddPolicy, то при попытке подключения к старому адресу (который мог быть перехвачен новым владельцем диапазона) скрипты также молча передали бы доступ посторонним лицам. Отсутствие строгой привязки host key является дырой, которую невозможно закрыть патчем библиотеки — это архитектурная ошибка проектирования доступа.

Правильный подход к управлению известными хостами

Единственный безопасный способ работы с SSH в автоматизации — это предварительное управление файлом known_hosts. Перед развертыванием скриптов необходимо собрать реальные публичные ключи всех целевых систем и распределить их вместе с кодом или конфигурацией. Вместо игнорирования проверок следует использовать политику RejectPolicy, которая является поведением по умолчанию, или написать собственную логику обработки исключений. Если ключ сервера внезапно меняется, скрипт обязан упасть с ошибкой и отправить алерт инженерам, а не пытаться продолжить работу с потенциально враждебным узлом.

Для централизованного управления инфраструктурой лучше отказаться от хранения IP-адресов в теле скриптов вообще. Используйте инвентаризационные файлы Ansible, переменные окружения или специализированные хранилища секретов. Это решает сразу две задачи: упрощает переезды (меняете адрес в одном месте) и позволяет сопоставлять доменное имя с конкретным ожидаемым fingerprint. Проверка соответствия имени и ключа — это фундамент доверия в сетях, и отказываться от него ради экономии пяти минут на настройке — непозволительная роскошь для инженера по информационной безопасности.

Практические рекомендации по защите соединений

Чтобы исключить подобные риски в вашей среде разработки и эксплуатации, внедрите следующие правила:

Полностью удалите вызовы set_missing_host_key_policy(AutoAddPolicy) из всех production-скриптов. Любое автоматическое доверие недопустимо.
Переведите все обращения с IP-адресов на внутренние DNS-имена. При смене инфраструктуры вам нужно будет обновить только запись A, а не искать забытые хардкоды.
Сгенерируйте эталонный файл known_hosts и проверяйте его целостность контрольными суммами перед запуском пайплайнов сборки.
Настройте мониторинг событий смены ключей хоста. Если операционная система сообщает о новом ключе для известного сервера — это повод для немедленного реагирования ИБ-отдела.
Используйте аппаратные модули безопасности или Passphrases для приватных ключей, которыми оперируют скрипты, чтобы компрометация файла не привела к мгновенному захвату сервера.

Как проверить с помощью Perimeter

Платформа Perimeter EASM помогает выявить слабые места во внешней инфраструктуре, которые могут стать точками входа для подобных атак. Модуль сканирования TLS позволит обнаружить устаревшие конфигурации шифрования и несоответствия сертификатов, которые часто сопровождают хаотичное управление доступом. Инструменты OSINT-модуля покажут, не утекли ли ваши внутренние IP-адреса или части скриптов автоматизации в публичные репозитории GitHub. Кроме того, функционал мониторинга бренда поможет заметить появление подозрительно похожих ресурсов, которые злоумышленники могут использовать для фишинга ваших администраторов с целью кражи актуальных ключей доступа.