Усиление защиты OpenSSH в Ubuntu 18.04

Автор выбрал Electronic Frontier Foundation Inc для получения пожертвований в рамках программы Write for DOnations.

Введение

Серверы Linux часто управляются удаленно с использованием протокола SSH путем подключения к серверу OpenSSH, который является программным обеспечением сервера SSH по умолчанию, используемым в Ubuntu, Debian, CentOS, FreeBSD и большинстве других систем на базе Linux/BSD.

Сервер OpenSSH — это серверная сторона SSH, также известная как демон SSH или sshd. Вы можете подключаться к серверу OpenSSH, используя клиент OpenSSH, а именно команду ssh. Дополнительную информацию о модели клиент-сервер SSH можно найти в статье Основы SSH: работа с серверами, клиентами и ключами SSH. Надлежащая защита вашего сервера OpenSSH имеет большое значение, поскольку сервер является центральным входом или «дверью» на ваш сервер.

В этом обучающем руководстве мы усилим защиту вашего сервера OpenSSH с помощью различных вариантов конфигурации для обеспечения максимально безопасного удаленного доступа к вашему серверу.

Предварительные требования

Для данного обучающего руководства вам потребуется следующее:

• Сервер Ubuntu 18.04, настроенный согласно руководству по первоначальной настройке сервера с Ubuntu 18.04, включая пользователя sudo без прав root.

Подготовив все вышеперечисленное, войдите на сервер в качестве пользователя без прав root, чтобы начать работу.

Шаг 1 — Общее усиление защиты

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

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

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

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

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Резервная копия файла будет сохранена в /etc/ssh/sshd_config.bak.

Перед редактированием файла конфигурации вы можете просмотреть текущие настроенные опции. Сделать это можно с помощью следующей команды:

sudo sshd -T

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

Теперь вы можете открыть файл конфигурации с помощью предпочитаемого текстового редактора и начать реализовывать первоначальные меры по усилению защиты:

sudo nano /etc/ssh/sshd_config

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

Сначала отключите возможность входа через SSH в качестве пользователя с правами root, установив следующую опцию:

PermitRootLogin no

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

Далее вы можете ограничить максимальное количество попыток аутентификации для конкретного сеанса входа, настроив следующее:

MaxAuthTries 3

Стандартное значение 3 приемлемо для большинства настроек, но вы можете увеличить или уменьшить его в зависимости от вашего порога риска.

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

LoginGraceTime 20

Файл конфигурации определяет это значение в секундах.

Установка более низкого значения предотвращает некоторые атаки типа «отказ в обслуживании», когда несколько сеансов аутентификации остаются открытыми в течение длительного периода времени.

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

PasswordAuthentication no

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

PermitEmptyPasswords no

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

ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

Если вы хотите узнать больше о некоторых дополнительных методах аутентификации, имеющихся в SSH, вы можете ознакомиться с этими ресурсами:

• Вызов-ответ (аутентификация)
• Аутентификация Kerberos
• Аутентификация GSSAPI

Перенаправление X11 позволяет отображать удаленные графические приложения через подключение SSH, но это редко используется на практике. Рекомендуется отключить эту опцию, если она не требуется на вашем сервере:

X11Forwarding no

Сервер OpenSSH позволяет подключать клиентов для прохождения переменных настраиваемой среды, т. е. устанавливать $PATH или конфигурировать настройки терминала. Однако, как и перенаправление X11, эти опции не имеют широкого распространения, поэтому могут быть отключены в большинстве случаев:

PermitUserEnvironment no

Если вы решите настроить эту опцию, вам также следует обязательно прокомментировать любую ссылку на AcceptEnv, добавив решетку (#) в начало строки.

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

AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

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

DebianBanner no

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

Теперь проверьте синтаксис новой конфигурации, запустив sshd в тестовом режиме:

sudo sshd -t

Если у вашего файла конфигурации допустимый синтаксис, вывода не будет. В случае ошибки синтаксиса появится вывод с описанием проблемы.

Когда вы настроили файл конфигурации в соответствии с вашими потребностями, можно перезагрузить sshd, чтобы применить новые настройки:

sudo service sshd reload

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

Шаг 2 — Внедрение списка разрешенных IP-адресов

Вы можете использовать списки разрешенных IP-адресов для ограничения числа пользователей, имеющих разрешение входить на ваш сервер с помощью IP-адреса. На этом шаге вы настроите список разрешенных IP-адресов для вашего сервера OpenSSH.

Зачастую вы будете входить на сервер с ограниченного числа известных доверенных IP-адресов. Например, это может быть ваше домашнее интернет-подключение, корпоративное оборудование VPN, статический инсталляционный сервер или узел-бастион в ЦОД.

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

Вы можете определить текущий IP-адрес, с которого вы подключаетесь к вашему серверу, с помощью команды w:

w

Будет выведен текст следующего вида:

Output
 14:11:48 up 2 days, 12:25,  1 user,  load average: 0.00, 0.00, 0.00
         USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
your_username     pts/0    203.0.113.1     12:24    1.00s  0.20s  0.00s w

Найдите в списке вашу учетную запись пользователя и отметьте связующий IP-адрес. В данном случае мы используем в качестве примера IP-адрес 203.0.113.1.

Чтобы внести ваш IP-адрес в список разрешенных адресов, откройте файл конфигурации сервера OpenSSH в предпочитаемом текстовом редакторе:

sudo nano /etc/ssh/sshd_config

Вы можете создавать списки разрешенных IP-адресов с помощью директивы конфигурации AllowUsers, которая ограничивает аутентификацию пользователя на основе имени пользователя и/или IP-адреса.

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

• Ограничить всех пользователей конкретным IP-адресом:

AllowUsers *@203.0.113.1

• Ограничить всех пользователей конкретным диапазоном IP-адресов с помощью записи бесклассовой междоменной маршрутизации (CIDR):

AllowUsers *@203.0.113.0/24

• Ограничить всех пользователей конкретным диапазоном IP-адресов (с помощью подстановочных знаков):

AllowUsers *@203.0.113.*

• Ограничить всех пользователей несколькими конкретными IP-адресами и диапазонами:

AllowUsers *@203.0.113.1 *@203.0.113.2 *@192.0.2.0/24 *@172.16.*.1

• Запретить вход всем пользователям, кроме указанных пользователей с конкретных IP-адресов:

AllowUsers sammy@203.0.113.1 alex@203.0.113.2<^>

• Ограничить конкретного пользователя конкретным IP-адресом, сохраняя возможность для всех других пользователей входить без ограничений:

Match User ashley
  AllowUsers ashley@203.0.113.1

После завершения установки конфигурации добавьте ее внизу файла конфигурации сервера OpenSSH:

AllowUsers *@203.0.113.1

Сохраните и закройте файл, а затем перейдите к проверке синтаксиса конфигурации:

sudo sshd -t

Если ошибок не выявлено, можно перезагрузить сервер OpenSSH для применения конфигурации:

sudo service sshd reload

На этом шаге вы внедрили список разрешенных IP-адресов на вашем сервере OpenSSH. На следующем шаге мы ограничим оболочку пользователя, чтобы сократить количество команд, разрешенных к использованию.

Шаг 3 — Ограничение оболочки пользователя

На этом шаге вы рассмотрите различные опции ограничения оболочки пользователя SSH.

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

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

Во-первых, вы можете использовать оболочку /usr/sbin/nologin для отключения интерактивных логинов для некоторых учетных записей пользователей, при этом оставляя возможность выполнения неинтерактивных сеансов, таких как передача файлов, настройка туннелей и т. д.

Чтобы создать нового пользователя с оболочкой nologin, используйте следующую команду:

sudo adduser --shell /usr/sbin/nologin alex

Также вы можете изменить оболочку существующего пользователя на nologin:

sudo usermod --shell /usr/sbin/nologin sammy

Если после этого вы попытаетесь интерактивно войти в систему как один из этих пользователей, запрос будет отклонен:

sudo su alex

Будет выведено сообщение следующего вида:

Output
This account is currently not available.

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

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

Начните с открытия файла конфигурации сервера OpenSSH в вашем любимом текстовом редакторе:

sudo nano /etc/ssh/sshd_config

Есть две опции конфигурации, которые вы можете реализовать совместно для создания строго ограниченной учетной записи пользователя только SFTP: ForceCommand internal-sftp и ChrootDirectory.

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

Однако в данном случае команда internal-sftp имеет особую значимость. Это специальная функция сервера OpenSSH, запускающая базовый демон SFTP, который не требует каких-либо вспомогательных системных файлов или конфигураций.

В идеале ее следует сочетать с опцией ChrootDirectory, которая будет переопределять/изменять воспринимаемый корневой каталог для конкретного пользователя, по сути, ограничивая его конкретным каталогом в системе.

Добавьте для этого следующий раздел конфигурации в файл конфигурации сервера OpenSSH:

Match User alex
  ForceCommand internal-sftp
  ChrootDirectory /home/alex/

Сохраните и закройте файл конфигурации и снова протестируйте конфигурацию:

sudo sshd -t

Если ошибок нет, вы можете внедрять конфигурацию:

sudo service sshd reload

Так вы создали надежную конфигурацию для пользователя alex, где отключен интерактивный логин, а вся активность SFTP ограничена домашним каталогом пользователя. С точки зрения пользователя корнем системы, т. е. /, является домашний каталог, и нельзя пройти через файловую систему, чтобы получить доступ к другим областям.

Вы внедрили оболочку nologin для пользователя и затем создали конфигурацию для ограничения доступа SFTP к конкретному каталогу.

Шаг 4 — Расширенное усиление защиты

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

Менее известная особенность сервера OpenSSH — это возможность вводить ограничения на основе ключа, т. е. ограничения, применимые только к отдельным публичным ключам, представленным в файле .ssh/authorized_keys. Это особенно полезно для контроля доступа к межкомпьютерным сеансам, а также предоставления пользователям без привилегий sudo контроля ограничений их собственных учетных записей.

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

Для начала откройте файл .ssh/authorized_keys в предпочитаемом текстовом редакторе:

nano ~/.ssh/authorized_keys

После открытия файла authorized_keys вы увидите, что каждая строка содержит публичный ключ SSH, который, скорее всего, будет начинаться с ssh-rsa AAAB.... Дополнительные опции конфигурации можно добавить в начало строки, и они будут применяться только к успешным случаям аутентификации с помощью конкретного публичного ключа.

Доступны следующие опции ограничения:

• no-agent-forwarding: отключение перенаправления агента SSH.
• no-port-forwarding: отключение перенаправления порта SSH.
• no-pty: отключение возможности выделения tty (т. е. запуск оболочки).
• no-user-rc: предотвращение выполнения файла ~/.ssh/rc.
• no-X11-forwarding: отключение перенаправления графического сеанса X11.

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

no-agent-forwarding,no-X11-forwarding ssh-rsa AAAB...

По умолчанию эти конфигурации работают с помощью методологии «разрешено по умолчанию, блокируется в виде исключения». Однако можно использовать вариант «блокируется по умолчанию, разрешено в виде исключения», что обычно более предпочтительно для обеспечения безопасности.

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

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

restrict,X11-forwarding ssh-rsa AAAB...

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

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

command="top" ssh-rsa AAAB...

Наконец, для максимально продуктивного использования ограничения по ключу для пользователя только SFTP, которое вы настроили на шаге 3, используйте следующую конфигурацию:

restrict,command="false" ssh-rsa AAAB...

Опция restrict отключает любой интерактивный доступ, а опция command="false" действует как вторая линия защиты в случае отказа опции ForceCommand или оболочки nologin.

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

На этом заключительном шаге вы внедрили некоторые дополнительные усовершенствованные меры по усилению защиты для сервера OpenSSH, используя настраиваемые опции внутри файла (файлов) .ssh/authorized_keys.

Заключение

В этой статье вы рассмотрели конфигурацию сервера OpenSSH и приняли различные меры по усилению защиты для обеспечения безопасности вашего сервера.

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

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