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

SSH, Ubuntu | Amber | Комментировать запись

Часто серверами Linux управляют удаленно – это делается с помощью SSH путем подключения к серверу OpenSSH  (это программное обеспечение SSH используется по умолчанию в Ubuntu, Debian, CentOS, FreeBSD и большинстве других систем на основе Linux/BSD).

Итак, OpenSSH – это серверная часть SSH, также известная как демон SSH, или sshd. Вы можете подключиться к серверу OpenSSH с помощью клиента OpenSSH – команды ssh.

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

Требования

Для работы вам понадобится сервер Ubuntu 18.04, настроенный по этому мануалу (включая пользователя sudo).

Чтобы приступить к выполнению мануала, войдите на свой сервер как пользователь sudo.

1: Повышение общей защиты

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

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

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

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

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

Во-первых, отключите 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 Authentication
• Аутентификация GSSAPI

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

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-адреса указаны в списке правильно. Также убедитесь, что это не плавающие или динамические адреса, которые могут регулярно меняться.

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

w

Это выведет на экран такой результат:

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 ashley@203.0.113.1 alex@203.0.113.2<^>

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

Match User ashley
AllowUsers ashley@203.0.113.1

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

Завершив настройку, добавьте список в конец конфигурационного файла OpenSSH:

AllowUsers *@203.0.113.1

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

sudo sshd -t

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

sudo service sshd reload

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

3: Ограничение доступа к оболочке

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

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

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

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

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

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

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

sudo usermod --shell /usr/sbin/nologin 8host

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

sudo su alex

Это выведет следующее сообщение:

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, которая переопределит (изменит) воспринимаемый корневой каталог для определенного пользователя, по существу ограничивая его конкретным каталогом в системе.

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

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

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

sudo sshd -t

Если ошибок нет, вы можете активировать новые настройки:

sudo service sshd reload

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

4: Продвинутая защита

В последнем разделе мы внедрим дополнительные меры защиты, чтобы сделать доступ к SSH-серверу максимально безопасным.

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

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

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

Откройте .ssh/authorized_keys в текстовом редакторе:

nano ~/.ssh/authorized_keys

Примечание: Поскольку эти конфигурации применяются для отдельных ключей, вам нужно будет отредактировать каждый отдельный ключ, к которому вы хотите их применить, в каждом файле 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...

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

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

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

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

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

Заключение

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

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

Больше информации вы можете найти в документации сервера OpenSSH и его конфигурационного файла. Это поможет вам определить дальнейшие возможные настройки безопасности.