Повышение безопасности OpenSSH

SSH или Secure Shell является распространенным протоколом администрирования на системах Linux. Часто он работает на многих системах с настройками по умолчанию. Так как этот сервис открывает потенциальный шлюз в систему, улучшение его безопасности является одним из шагов по усилению защиты системы Linux. В этой статье представлены советы по усилению безопасности сервиса OpenSSH и повышения уровня защиты системы.

Безопасность OpenSSH

OpenSSH это реализация протокола SSH. OpenSSH позволяет выполнять удаленное подключение к серверу, производить манипуляции с файлами и управлять системой. Сегодня мы хотим рассказать про лучшие методы, которые позволят увеличить безопасность системы на базе OpenSSH. OpenSSH разрабатывается фанатиками безопасности из проекта OpenBSD. Каждая новая функция тщательно прорабатывается, особенно это касается функций, относящихся к безопасности. Хотя в прошлом находились некоторые уязвимости, OpenSSH по умолчанию вполне безопасен. Однако, есть некоторые аспекты, которые можно улучшить.

Что мы рассмотрим в статье?

В этой статье мы рассмотрим настройки сервера и клиента. Синтаксис и настройки конфигурации базируются на OpenSSH версии 7 и выше. Примеры команд будут работать для большинства дистрибутивов Linux, таких как CentOS, Debian, Ubuntu и RHEL. Также, они могут подойти для FreeBSD, OpenBSD и других систем, которые используют OpenSSH.

После прочтения статьи вы узнаете:

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

Основы SSH

SSH состоит из двух частей: сервер sshd, принимающий запросы на соединения от клиентов, и клиент ssh, который используется для соединения с сервером. Обычно администрирование сервера производится с использованием клиента SSH из системы, на которой вы работаете. В ОС семейства Windows часто используется клиентское программное обеспечение Putty.

Говоря о безопасности конфигурации SSH, наибольший интерес представляет серверная часть. Например, на уровне сервера решается, разрешаются или запрещаются вход с использованием пароля. Даже если у клиента некоторые опции установлены явно, окончательное решение принимает сервер. Файл конфигурации сервера находится в каталоге /etc/ssh/sshd_config.

Настройки конфигурации клиента можно найти в /etc/ssh/ssh_config (на уровне системы) или в ~/.ssh/config(на уровне пользователя). Настройки также можно определить в процессе подключения посредством передачи параметра командной строки.

Прежде, чем вносить изменения, рассмотрим, как сделать это правильно.

Советы по установке

Не используйте «лучшие практики» без понимания сути

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

Если в статье представлены только настройки конфигурации без четких объяснений, их стоит применять с осторожностью. Некоторые из них могут быть устаревшими, другие — некорректными. Зачем устанавливать значение, если оно уже установлено по умолчанию или удалено? Поэтому, чтобы вы ни делали, относитесь к этому критично и не делайте предположений. Используйте лучшие практики, но всегда проверяйте те изменения, которые вносите.

Проверка статуса SSH

Вы впервые редактируете конфигурации SSH? Тогда сначала проверьте статус SSH-демона и посмотрите, запущен ли нужный сервис при загрузке. При использовании дистрибутива, использующего systemd, убедитесь, что демон запущен и включен.

systemctl status ssh.service

На некоторых дистрибутивах Linux сервис называется sshd.service.

В ответе должно вернуться значение enabled:

Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)

Подтверждение, что SSH запущен, выглядит следующим образом:

Active: active (running) since Mon 2018-06-04 17:18:33 CEST; 1 months 2 days ago

Использование теста конфигурации SSH

При внесении изменений в конфигурацию SSH, целесообразно перезапустить сервис. Настоятельно рекомендуем перед запуском проверять конфигурацию (sshd_config). Это можно сделать используя флаг test mode. Этот дополнительный шаг позволяет убедиться, что синтаксис и опции корректны.

sudo sshd -t

Команда не должна возвращать текст или ошибки.

Внесение изменений в настройки SSHD удаленной системы

Сервер SSH не сбрасывает текущие открытые сессии при выполнении команд reload, restart.Никогда не закрывайте текущую рабочую сессию при внесении изменений в конфигурацию сервера SSH. Перезапустите сервис sshd, откройте дополнительную сессию и убедитесь, что соединение устанавливается. Если вы хотите «выбросить» текущих подключенных пользователей, вы должны послать kill всем процессам SSH.

Для систем c systemd используйтеsystemctl для перезагрузки сервиса SSH:

systemctl reload ssh.service

Так же возможно отправить сигнал SIGHUP родительскому процессу. Но не отправляйте сигнал дочерним процессам, иначе произойдет отключение.

kill -HUP 1234

Альтернативный способ — временно запустить другой процесс SSH на другом порту в интерактивном режиме. Укажите полный путь к исполняемому файлу sshd и флаги -D и -p для значения порта. Убедитесь, что доступно временное соединение, соединившись клиентом SSH с временным сервисом.

/usr/sbin/sshd -D -p 2222

Для остановки процесса используйте CTRL+C .

Перенастройка методом малых изменений

Часто имеет смысл задать новые настройки SSH сразу на всех системах, но иногда лучше перестраховаться. Например, некоторые старые клиенты SSH могут не поддерживать новые типы ключей. Чтобы иметь представление о возможных проблемах совместимости, проверьте SSH на самых старых используемых дистрибутивах Linux.

Активные соединения SSH

Перед применением изменений или перезапуском демона, проверьте активные SSH-соединения. Это можно сделать с помощью инструмента ss.

ss -n -o state established '( dport = :22 or sport = :22 )'

Вы увидите установленное соединение TCP. С помощью dport и sport можно проверить, какие соединения являются активными.

Улучшение безопасности сервера SSH

Подготовка

Прежде, чем вносить изменения в конфигурацию, создадим резервную копию.

cp /etc/ssh/sshd_{config,.config.orig}

На этом этапе полезно знать, что каждая версия OpenSSH имеет свои значения по умолчанию, где новая функциональность может добавиться, а старая удалиться. Чтобы узнать, задана ли специальная настройка, не полагайтесь на конфигурационный файл. Вместо этого вызовите демон SSH с флагом расширенного тестового режима -T, чтобы просмотреть полную информацию.

sshd -T

Ответ может выглядеть следующим образом (листинг приведен не полностью):

# sshd -T
port 2022
protocol 2
addressfamily any
listenaddress [::]:2022
listenaddress 0.0.0.0:2022
usepam yes
serverkeybits 1024
logingracetime 120
keyregenerationinterval 3600
x11displayoffset 10
maxauthtries 6
maxsessions 10
clientaliveinterval 0
clientalivecountmax 3
streamlocalbindmask 0177
permitrootlogin yes
ignorerhosts yes
ignoreuserknownhosts no
rhostsrsaauthentication no
....

Настройки конфигурации и значения отображаются в нижнем регистре.

Настройки безопасности SSH

Приведенные далее настройки позволяют значительно уменьшить вероятность взлома сервера с помощью SSH.

Использование нестандартного порта для сервера

Боты, сканирующие уязвимые учетные записи SSH ожидают его на порту 22. Если вы поменяете порт SSH на нестандартный, например, 3022, вы значительно снизите интенсивность сканирования и вероятность проникновения в систему даже при использовании нестойких паролей:

Port 3022

Использование X11Forwarding

Если пересылка графического трафика X11 поверх SSH не требуется, отключите его:

X11Forwarding no

Почему важно отключать передачу X11: протокол X11 не предусматривает настроек безопасности. Открывая канал клиенту, сервер может отправлять ему вредоносные команды. Чтобы защитить клиента, отключите передачу X11, если она не нужна.

Отключение `rhosts`

Аутентификация с использованием rhosts чрезвычайно удобна в локальных сетях, где одни и те же пользователи имеют учетные записи на разных машинах. Однако следует внимательно следить за тем, чтобы такой тип аутентификации был запрещен на компьютерах, подключенных к сетям, в которых может реализовываться атака, основанная на подмене IP-адреса. Этот способ аутентификации сегодня не столь распространен, так как является небезопасным: основанием для доверия другой системе является только IP-адрес. По умолчанию использование rhosts отключено. Не забудьте проверить, так ли это в действительности.

IgnoreRhosts yes

Проверка имени хоста DNS

Сервер SSH может проверять, устанавливает соответствие доменного имени клиента его адресу с помощью DNS. Такая проверка может быть активирована следующим способом:

UseDNS yes

Данная опция не во всех случаях будет хорошо работать. В результате ее использования возникнет дополнительная задержка при установлении соединения, так как сервер SSH будет проверять имя клиента через DNS, а при невозможности резолвинга будет ожидать тайм-аута DNS. Используйте ее, только когда уверены в корректной настройке DNS.

Отключите пустые пароли

Аккаунты должны быть защищены, а пользователи — учтены. Поэтому использование пустых паролей следует запретить. Их можно отключить с помощью опции PermitEmptyPasswords, которая используется по умолчанию.

PermitEmptyPasswords no

Максимальное количество попыток аутентификации

Для защиты от атак на пароли пользователя ограничьте число попыток входа с помощью настройки MaxAuthTries.

MaxAuthTries 3

Также активируйте отслеживание ошибок аутентификации по достижении половины от максимального количества попыток. Используйте ошибки аутентификации вместе с программным обеспечением SIEM (например, Snort), или перенаправляйте их администратору безопасности.

Сервер SSH может быть настроен для использования PAM или подключаемых модулей аутентификации. Используя набор правил, являющихся частью стека аутентификации, можно использовать количество неудачных попыток входа в систему для блокировки конкретного пользователя. Другой вариант — определить период блокировки аккаунта по достижении установленного числа попыток. В этом случае сервер будет лучше защищен от прямого подбора паролей к аккаунту пользователя.

При ограничении количества попыток входа помните, что аутентификация по открытому ключу (см. ниже) также может входит в число попыток. Если нужно принудить SSH-клиент (или SCP) использовать аутентификацию при помощи пароля, используйте соответствующие опции:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no username@system

Аутентификация с помощью публичного ключа

Вместо стандартного доступа по паролю лучше использовать аутентификацию с помощью инфраструктуры публичных ключей. Ключи считаются более безопасным средством аутентификации и меньше подвержены атакам «грубой силы». Чтобы заставить пользователя использовать ключи, отключите PasswordAuthentication.

PubkeyAuthentication yes
PasswordAuthentication no

Больше информации об использовании ключей SSH вместо паролей для аутентификации вы найдете в статье.

Отключите вход для учетной записи root

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

PermitRootLogin no

Более новые версии OpenSSH также поддерживают значение without-password. Это значение позволяет устанавливать соединение для учетной записи root только с использованием инфраструктуры публичных ключей.

Установите версию разрешенного протокола SSH

Если вы используете старую версию SSH, там может использоваться протокол версии 1. В этом протоколе есть ошибки, и его не стоит использовать. Начиная с OpenSSH версии 7.0 протокол версии 1 автоматически отключается при компиляции. Если вы используете раннюю версию SSH, установите версию протокола явно:

Protocol 2

Использование `AllowUsers` и `DenyUsers`

Если доступ к системе должен быть не у всех пользователей, ограничьте субъектов, имеющих к ней доступ. Один из способов — создать группу (например, sshusers) и добавить в нее пользователей. Затем определить параметр AllowGroups, чтобы разрешить доступ в систему только этим пользователям.

Другой способ — разрешить доступ пользователям с помощью настройки AllowUsers, или запретить доступ пользователям и группам пользователей с помощью DenyUsers или DenyGroups. Как правило, лучше использовать белые списки доступа совместно с политикой доступа «отказ по умолчанию». Поэтому при возможности применяйте настройки AllowUsers или AllowGroups.

Полезно помнить, что SSH проверяет списки пользователей для доспуска в систему в следующем порядке: DenyUsers, AllowUsers, DenyGroups и наконец AllowGroups.

Использование HashKnownHosts

Каждый раз, когда SSH-клиент подключается к серверу, он сохраняет соответствующую подпись (ключ) сервера. Эта информация хранится в файле known_hosts, доступный в поддиректории .ssh соответствующего пользователя (на клиенте). В случае, когда подпись сервера отличается, SSH уведомляет пользователя об этом, и подключение не устанавливается. Это полезная опция, но есть риск. Изначально обычной практикой считалось сохранять имя хоста, соответствующего конкретному ключу хоста. Это позволяло червям и другим вредоносным скриптам легко использовать данную информацию и после взлома одной системы передавать ее другим системам. Чтобы противостоять этому, используйте HashKnownHosts, который будет создавать хэши имён хостов из ~/.ssh/known_hosts. Использование хэшей имён хостов вместо самих имён хостов поддерживается в ssh(1) и sshd(8), и позволяет предотвратить утечку информации в случае разглашения содержимого файла. По умолчанию стоит значение no. Файл становится нечитабельным для человеческого глаза, но он по-прежнему позволяет SSH проверять ключ сервера при следующем подключении к той же системе.

Пример ответа:

|1|XV5CFMH8LLIQPq7PxdBhGX7I9PA=|VKNLdODsQlJ/j4cvTZncqs9vgh0= ecdsa-sha2-nistp256 AAAAE2VjZHNhLX….dJ/RzzZLH8Hs0UgroC0=

Запрет разрешенных для выполнения команд

OpenSSH позволяет запретить команды, которые можно запускать, с помощью опции command, расположенной в файле authorized_keys вместе с информацией о публичном ключе.

command="ps",no-agent-forwarding,no-port-forwarding,no-x11-forwarding, TYPE_OF_KEY KEY COMMENT

В примере выше замените поля TYPE_OF_KEY, KEY и COMMENT. Значения, которые должны использоваться, соответствуют тем, которые используются при аутентификации по открытому ключу.

Дополнительные ограничения

Настройка брандмауэра

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

Использование jump-сервера

Большие инфраструктуры как правило ограничивают доступ, используя jump-сервер или jump-хост, или узел-бастион. Они являются единственными системами в сети, конфигурации которых разрешают доступ к другим системам. Это означает, что, если необходимо администрировать систему, в первую очередь необходимо подключиться к jump-серверу, а оттуда — к целевой системе. Это отлично работает вместе с ограничением доступа посредством брандмауэра.

Настройки безопасности клиента OpenSSH

Доступно множество клиентов SSH, поэтому рассказать о каждом из них в одной статье невозможно. Остановимся подробнее на инструменте клиента OpenSSH.

Конфигурация клиента

Клиент OpenSSH можно настроить тремя способами. Они обрабатываются по порядку и проверяются для каждого доступного параметра конфигурации. Выбирается первый подходящий.

Настройки задаются через командную строку;
Через файл конфигурации в домашней директории (~/.ssh/config);
Через файл конфигурации для всех пользователей (/etc/ssh/ssh_config).

Допустим, есть настройка А. Она задана для всей системы (3 способ) со значением «True». Пользователь michael установил для нее значение «False» (2 способ). В этом случае второе значение в приоритете, т.к. оно рассматривается перед настройками всей системы.

Просмотр активных настроек

Помните, как мы просматривали настройки для сервера (sshd -T)? У клиента есть похожий инструмент.

ssh -G abc

Здесь abc является произвольным именем хоста. Или, возможно, не совсем произвольным. Можно использовать что угодно, включая реальное имя хоста. Клиент может использовать блоки Host и Match для настройки конфигурации группы систем или отдельной системы. Если хоста abc не существует, будут рассматриваться настройки по умолчанию.

Настройки SSH для отдельной системы

Допустим, есть система secureserver. Вместо того, чтобы работать на порте 22, она принимает соединения по SSH на порте 2222. Вместо применения -p в командной строке можно добавить блок Host в файл конфигурации. Для этого необходимо в каталоге .ssh домашней директории создать файл config (/home/username/.ssh/config).

Затем создадим блок и определим нужные настройки.

Host secureserver
    Hostname hostname.example.org
    User mynickname
    Port 2222
    MACs hmac-sha2-512
    KexAlgorithms curve25519-sha256@libssh.org

Отступы необязательны, но рекомендуются, чтобы отличать, какие настройки к какому хосту относятся.

Какие же настройки следует определять в файле конфигурации клиента?

Рекомендуем использовать те, которые облегчат вам ежедневную работу. Если вы отдаете предпочтение безопасности, задайте надежные настройки по умолчанию. Если какой-то хост использует другой SSH-порт, создайте блок Host и переопределите его настройки нужным образом. Что касается KexAlgorithms, используйте более новые доступные алгоритмы. Это сильно зависит от версии OpenSSH на серверах. Если на сервере используется новая версия OpenSSH, то хорошо подойдет curve25519. Это высокоскоростной алгоритм на основе эллиптических кривых, который на данный момент считается безопасным.

Инструменты для анализа безопасности SSH

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

Lynis

Универсальный инструмент безопасности с открытым кодом для тестирования безопасности систем Linux. Он проверит все, что может, от загрузчика до сервера. Он бесплатный и написан с помощью shell script. Lynis работает в самой системе, поэтому может просматривать как файлы конфигурации, так и фактически загруженную конфигурацию. Он включает в себя несколько тестов для OpenSSH и его конфигураций, включая параметры безопасности. Результаты или возможные улучшения отображаются на экране, что позволяет непосредственно приступить к действиям и начать усиливать безопасность системы.

Скачайте утилиту с GitHub или с сайта. Используйте инструкцию, чтобы быстрее понять, с чего начать работу.

ssh-audit

Несмотря на то, что инструмент ssh-audit немного устарел, его стоит иметь в своем арсенале. Вместо тестирования на самом хосте, он может подключаться к SSH-серверу через сеть. Он выполняет тестирование на выбранной системе и просматривает полученные ответы, на основании которых узнает о системе и сервере SSH. Он даже узнает о конкретных уязвимостях и может предупредить о них. Загрузите инструмент через GitHub и попробуйте применить.

Чтобы найти больше информации о других инструментах, читайте раздел «Сканеры конфигурации безопасности Linux».

Ресурсы

Справочная страница

Хорошим ресурсом о настройках конфигурации SSH является man-страница. Хотя это звучит как простой совет, на самом деле важно помнить, что справочная страница является полезной и актуальной. При всех незначительных различиях между релизами часто сложно догадаться самостоятельно, что делает настройка. Вместо этого лучше прочитать о настройке и посмотреть, есть ли в ней изменения. Объедините эти знания с выводом команды sshd -T, и это позволит выбрать максимально правильный вариант для вашей конкретной ситуации.