Table of Contents
Усиление защиты OpenSSH
Перевод статьи
General Hardening
Какая именно конфигурация максимально подходит отдельно взятому серверу, зависит в значительной мере от моделей угроз и порога риска. Однако конфигурация, которую мы будем использовать на этом шаге, – это общая конфигурация безопасности, подходящая для большинства серверов.
Большинство методов усиления защиты для OpenSSH внедряются с использованием стандартного файла конфигурации, который находится в директории <html>/etc/ssh/sshd_config</html>. Перед тем как вносить изменения, рекомендуются сделать резервную копию конфигуратора:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.origin
Перед редактированием, можно ознакомится с текущими параметрами конфига:
sudo sshd -T
Итак, погнали:
Отключение входа через SSH пользователю root:
PermitRootLogin no
Максимальное количество попыток аутентификации:
MaxAuthTries 3
Установка промежутка времени, которое потребуется пользователю для аутентификации. Указывается в секундах:
LoginGraceTime 20
Если настроена аутентификации по ключу, то можно отключить вход с использованием пароля:
PasswordAuthentication no
Если по какой-то непонятной причине у пользователя установлен пустой пароль, запрещаем вход:
PermitEmptyPasswords no
В большинстве случаев, SSH будет настроен на аутентификацию с использованием открытого ключа, как единственный используемый метод аутентификации. Однако сервер OpenSSH также поддерживает множество других методов аутентификации, некоторые из которых включены по умолчанию. Если они не требуются, их можете спокойно отключить:
ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication no
Ознакомится с дополнительными методами аутентификации:
Переадресация X11 позволяет отображать удаленные графические приложения через SSH-соединение. Рекомендуется его отключить, если на сервере не используется:
X11Forwarding no
Сервер OpenSSH позволяет подключающимся клиентам передавать пользовательские переменные окружения, то есть устанавливать $PATH или настраивать параметры терминала. Однако, как и переадресация X11, это редко используется на практике:
PermitUserEnvironment no
Далее, если на сервере не будут создаваться туннели и перенаправления, то стоит отключить несколько опций:
AllowAgentForwarding no AllowTcpForwarding no PermitTunnel no
Отключаем баннер SSH, так как он несет информацию о системе:
DebianBanner no
Стоит Обратить внимание, что данная опция, скорее всего, не будет изначально представлена в файле конфигурации. Поэтому ее придется добавить ручками.
После внесения изменений проверяем синтаксис на наличие ошибок:
sudo sshd -t
И перезапускаем демон
systemctl reload sshd
Implementing an IP Address Allowlist
Мы можем использовать списки разрешенных IP-адресов для ограничения пользователей.
Узнаем свой текущий адрес:
ip -br a # or w
Чтобы внести IP-адрес в список разрешенных адресов редактируем <html>/etc/ssh/sshd_config</html>
OpenSSH позволяет создавать списки разрешенных IP-адресов с помощью директивы конфигурации <html>AllowUsers</html>, которая ограничивает аутентификацию пользователя на основе имени пользователя и/или IP-адреса.
Разрешаем пользователям входить только с конкретного IP-адреса:
AllowUsers *@203.0.113.1 # Либо подсети AllowUsers *@203.0.113.0/24
Ограничить всех пользователей определенным диапазоном IP-адресов с использованием wildcards (подстановочных знаков):
AllowUsers *@203.0.113.*
Ограничение всех пользователей несколькими конкретными IP-адресами и диапазонами:
AllowUsers *@203.0.113.1 *@203.0.113.2 *@192.0.2.0/24 *@172.16.*.1
Запрет входа всем, кроме указанных пользователей с конкретных IP-адресов:
AllowUsers nevvad@203.0.113.1 vasyan@203.0.113.2
Также, можно ограничить указанного пользователя конкретным IP-адресом. Но при этом, сохраняя возможность для всех других пользователей входить без ограничений:
Match User vasyan
AllowUsers vasyan@203.0.113.1
<WRAP center round important 95%> Warning: В конфигурационном файле OpenSSH все конфигурации в блоке <html>Match</html> будут применяться только к соединениям, соответствующим критериям, независимо от отступов или переносов строк. Это означает, что следует быть внимательны и следить за тем, чтобы конфигурации, предназначенные для глобального применения, не были случайно помещены в блок <html>Match</html>. Чтобы избежать этого, рекомендуется помещать все блоки <html>Match</html> в конце файла конфигурации. </WRAP>
Restricting the Shell of a User
В этом шаге мы рассмотрим различные варианты ограничения оболочки для пользователя SSH.
Помимо предоставления удаленного доступа к shell, SSH также отлично подходит для передачи файлов и других данных, например, через SFTP. Однако, не всегда нужно предоставлять полный доступ пользователям к shell, когда им нужно только передавать файлы.
Существует множество конфигураций OpenSSH, которые можно использовать для ограничения среды shell определенных пользователей. В данном руководстве, мы будем использовать их для создания пользователей только для SFTP.
Во-первых, мы можем использовать оболочку <html>/usr/sbin/nologin</html>, чтобы отключить интерактивный вход для определенных учетных записей пользователей, но при этом разрешить работу не интерактивных сессий, таких как передача файлов, туннелирование и так далее.
Для создания нового пользователя с <html>nologin</html>, выполним следующую команду:
sudo adduser --shell /usr/sbin/nologin vasyan
Также, можно изменить оболочку существующего пользователя на nologin:
sudo usermod --shell /usr/sbin/nologin johndoe
После этого, при попытке интерактивного входа в систему под таким пользователем, запрос будет отклонен:
This account is currently not available.
Несмотря на сообщение об отказе в интерактивном входе в систему, другие действия, такие как передача файлов, будут по-прежнему разрешены.
Далее, следует объединить использование оболочки nologin с некоторыми дополнительными опциями конфигурации для дальнейшего ограничения соответствующих учетных записей. Редактируем <html>/etc/ssh/sshd_config</html>.
Есть два параметра конфигурации, которые можно использовать совместно для создания жестко ограниченной учетной записи пользователя только для SFTP: :
- <html>ForceCommand internal-sftp</html>
- <html>ChrootDirectory</html>
Опция <html>ForceCommand</html> заставляет пользователя выполнить определенную команду при входе в систему. Это может быть полезно для определенных взаимодействий между хостами или для принудительного запуска определенной программы.
В нашем случае особенно полезна команда <html>internal-sftp</html>. Это специальная функция OpenSSH, которая запускает базовый внутренний SFTP-демон, не требующий никаких вспомогательных системных файлов или конфигурации.
В идеале, ее следует сочетать с опцией <html>ChrootDirectory</html>, которая переопределяет/изменяет корневую директорию для конкретного пользователя, по сути, ограничивая его конкретным каталогом в системе.
Match User vasyan ForceCommand internal-sftp ChrootDirectory /home/vasyan/
Таким образом, мы создали надежную конфигурацию для пользователя vasyan, в которой отключен интерактивный вход, а вся активность SFTP ограничена домашним каталогом пользователя. С точки зрения пользователя, корневая система, то есть <html>/</html>, является его домашним каталогом, и он не сможет перемещаться вверх по файловой системе.
Advanced Hardening
На этом этапе, мы будем применять различные дополнительные меры по усилению защиты, чтобы сделать доступ к SSH-серверу максимально безопасным.
Менее известной особенностью сервера OpenSSH является возможность наложения ограничений на основе каждого ключа, то есть ограничений, которые применяются только к определенным открытым ключам, присутствующим в файле <html>.ssh/authorized_keys</html>. Это особенно полезно для контроля доступа в меж хостовых сессиях, а также дает возможность пользователям, не обладающим правами sudo, контролировать ограничения для своей учетной записи.
Большинство из этих ограничений можно применять и на уровне системы или пользователя, однако, все же лучше применять их и на уровне ключей, чтобы обеспечить дополнительную защиту в случае ошибок в конфигурации всей системы.
<WRAP center round info 95%>
Nota Bene: Данный функционал применим только в том случае, если используется аутентификацию с открытым ключом SSH. Если используется только парольная аутентификация или аутентификация через центр сертификации SSH, то, к сожалению, эти настройки будут недоступны.
</WRAP>
После открытия файла <html>~/.ssh/authorized_keys</html> мы увидим, что каждая строка содержит публичный ключ SSH, который, скорее всего, будет начинаться с <html>ssh-rsa AAAB….</html>. Дополнительные опции конфигурации можно добавить в начало строки, и они будут применяться только к успешным случаям аутентификации с помощью конкретного публичного ключа.
Доступны следующие варианты ограничений:
- <html>no-agent-forwarding</html> – отключение перенаправления агента SSH.
- <html>no-port-forwarding</html> – отключение перенаправления порта SSH.
- <html>no-pty</html> – отключение возможности выделения tty (т. е. запуск оболочки).
- <html>no-user-rc</html> – предотвращение выполнения файла <html>~/.ssh/rc</html>.
- <html>no-X11-forwarding</html> – отключение перенаправления графического сеанса X11.
Эти опции, можно применить для отключения определенных функций SSH для конкретных ключей. Например, чтобы отключить переадресацию агентов и переадресацию X11, используем следующую конфигурацию:
no-agent-forwarding,no-X11-forwarding ssh-rsa AAAB...
По умолчанию эти конфигурации работают по принципу: по умолчанию разрешать, блокировать по исключению. Однако, также можно применить: блокировать по умолчанию, разрешать по исключению, что с точки зрения безопасности предпочтительнее.
Это можно сделать с помощью опции <html>restrict</html>, которая неявно запрещает все функции SSH для конкретного ключа, требуя их явного повторного включения только в случае крайней необходимости. Мы можем повторно включить функции, используя те же параметры конфигурации, которые описаны выше, но без префикса <html>no-</html>.
Например, чтобы отключить все функции SSH для определенного ключа, кроме переадресации дисплея X11, можно использовать следующую конфигурацию:
restrict,X11-forwarding ssh-rsa AAAB...
Также рассмотрим использование опции <html>command</html>, которая очень похожа на опцию <html>ForceCommand</html>.
Выполнение определенной команды при входе в систему:
command="top" ssh-rsa AAAB...
Наконец, чтобы наилучшим образом использовать ограничения на каждый ключ для пользователя SFTP-only, которого мы создали ранее, можно использовать следующую конфигурацию:
restrict,command="false" ssh-rsa AAAB...
Опция <html>restrict</html> отключает любой интерактивный доступ, а опция <html>command=“false”</html> действует как вторая линия защиты в случае отказа опции <html>ForceCommand</html> или оболочки <html>nologin</html>.