ADG Оставить заявку
Блог Информационная безопасность 4 мин чтения

SSH-аудит после релиза OpenSSH 4.7: Protocol 1 на шести серверах и PermitRootLogin на четырёх

OpenSSH 4.7 вышел с рядом улучшений безопасности. Поводом для аудита SSH-конфигов послужил релиз - нашли Protocol 1 и PermitRootLogin=yes в продакшне.

Контекст момента

OpenSSH 4.7 выходит в 2007 году с улучшениями безопасности и поддержкой GSSAPI

OpenSSH 4.7 вышел несколько дней назад. В changelog - улучшения в обработке GSSAPI, исправления в sftp-server, ряд небольших, но полезных изменений по части безопасности. Мы обновили пакеты на серверах клиента и заодно решили пройтись по конфигам sshd - раз уж всё равно трогаем демон.

Лучше бы не смотрели. Или нет - лучше всё-таки посмотрели.

Что нашли

Серверов в инфраструктуре клиента около двадцати: смесь Debian, CentOS и пары старых Red Hat 9 (которых там быть не должно, но это отдельный разговор). SSH везде, входы по паролю и по ключам вперемешку, политики исторически сложившиеся.

Прошлись скриптом по всем sshd_config и собрали сводку:

  • Protocol 1 не отключён на шести серверах. Это серверы, которые ставились в 2003-2005 году, когда Protocol 1 ещё был дефолтным или стоял «на всякий случай для совместимости». С тех пор никто не трогал конфиг - серверы работали, зачем лезть. Protocol 1 содержит известные криптографические слабости и с точки зрения безопасности его держать нет никакого смысла. Клиентов с Protocol 1-only в инфраструктуре не осталось - проверили.
  • PermitRootLogin yes на четырёх серверах. Здесь причина ещё проще: кто-то ставил сервер, логинился рутом для первоначальной настройки и не убрал за собой. Или убрал на одних, не убрал на других. Никакой системы не было.

Есть ещё несколько «мягких» находок - MaxAuthTries без явного ограничения, LoginGraceTime по дефолту (120 секунд, что многовато), PasswordAuthentication включён даже там, где есть ключи. Но Protocol 1 и PermitRootLogin - это не «надо бы поправить когда-нибудь», это правится сегодня.

Скрипт вместо ручного обхода

Двадцать серверов - это не то количество, где удобно редактировать конфиги руками по SSH в двадцати терминалах. Мы написали bash-скрипт, который запускается с управляющей машины и правит sshd_config на каждом хосте по списку.

Логика простая: подключаемся по SSH, проверяем текущее значение директивы в конфиге, если нужно - делаем sed-замену, перезапускаем sshd. Перед любой заменой скрипт делает backup конфига с датой: /etc/ssh/sshd_config.bak.20070704. После перезапуска sshd скрипт проверяет, что порт 22 ещё отвечает - если нет, пишет в лог и переходит к следующему хосту, не ломая прогон.

Ansible у нас нет - и на такой смеси дистрибутивов его настройка заняла бы дольше, чем написать скрипт. Возможно, когда парк станет однороднее, вернёмся к этому вопросу.

Результат: все двадцать серверов прошли за несколько минут. Protocol 2 only на всех шести проблемных машинах, PermitRootLogin no на четырёх. Проверили вручную три случайных хоста из списка - конфиги выглядят правильно, SSH отвечает, логины по ключам работают.

Постинсталляционный чеклист

Самое неприятное в этой истории - не то, что нашли. А то, что находки были предсказуемы. Protocol 1 и PermitRootLogin=yes - это первое, что проверяется в любом руководстве по хардению SSH. Они оказались в продакшне не потому что кто-то не знал, а потому что не было формального места, где это фиксируется после установки сервера.

Добавили в постинсталляционный чеклист отдельный раздел для SSH. Минимальный набор, который проверяется сразу после того, как сервер поднят:

  • Protocol 2. Только вторая версия.
  • PermitRootLogin no. Root через su/sudo после входа под обычным пользователем.
  • PasswordAuthentication. По умолчанию off, если на сервере есть ключи.
  • MaxAuthTries 3. Три попытки хватает.
  • LoginGraceTime 30. Сто двадцать секунд - это слишком щедро.
  • AllowUsers / AllowGroups. Явный белый список там, где это применимо.

Чеклист существовал и раньше - там была общая секция «настройка безопасности», но без конкретики по SSH. Теперь конкретика есть.

Что дал релиз OpenSSH 4.7

Сам по себе релиз для нас - плановое обновление пакетов, без сюрпризов. Улучшения в GSSAPI полезны там, где стоит Kerberos-аутентификация, но у текущего клиента её нет. Исправления в sftp-server применимы, если sftp активно используется - у нас он включён на нескольких серверах для файлового обмена с подрядчиками.

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

Теперь в рамках сопровождения инфраструктуры мы добавляем SSH-хардение в стандартный чеклист при обновлении OpenSSH - чтобы обновление пакета и ревизия конфига шли вместе, а не независимо.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.