Site icon 8HOST.COM

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

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

Управление серверами Linux часто осуществляется удаленно, с помощью SSH. Это происходит путем подключения к серверу OpenSSH, стандартному программному обеспечению SSH-сервера в системах Ubuntu, Debian, CentOS, FreeBSD и в большинстве других систем на основе Linux и BSD.

Защита серверной стороны SSH требует значительных усилий, поскольку SSH – это по сути вход на ваш сервер. Однако безопасность на стороне клиента (например, клиента OpenSSH) также важно учитывать.

Клиент OpenSSH – это, как следует из названия, клиентская сторона SSH, также известная как команда ssh.

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

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

Требования

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

1: Общая безопасность

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

Резервное копирование конфигураций

Многие конфигурации безопасности клиента OpenSSH реализуются в глобальном конфигурационном файле клиента OpenSSH, /etc/ssh/ssh_config. Кроме того, некоторые конфигурации могут быть записаны в локальный конфигурационный файл SSH вашего пользователя, ~/.ssh/config.

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

sudo cp /etc/ssh/ssh_config /etc/ssh/ssh_config.bak

cp ~/.ssh/config ~/.ssh/config.bak

Это позволит сохранить резервную копию файлов в их стандартном расположении, но с расширением .bak.

Обратите внимание, ваш локальный конфигурационный файл SSH (~/.ssh/config) может не существовать, если вы не использовали его раньше. Если это так, то его можно спокойно проигнорировать.

Базовые параметры безопасности

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

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

sudo nano /etc/ssh/ssh_config

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

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

Во-первых, нужно отключить поддержку X11-forwarding по SSH, установив следующие параметры:

ForwardX11 no

ForwardX11Trusted no

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

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

Tunnel no

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

ForwardAgent no

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

GSSAPIAuthentication no

HostbasedAuthentication no

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

При подключении к серверам клиент OpenSSH позволяет автоматически передавать пользовательские переменные среды, например, для установки языковых предпочтений или настройки параметров терминала. Но если в вашей настройке это не нужно, вы можете заблокировать отправку любых переменных, закомментировав или удалив параметр SendEnv:

# SendEnv

Строгая проверка ключа хоста должна быть включена – она отправит вам соответствующее предупреждение при изменении ключа хоста (или контрольной суммы) удаленного сервера или при первом подключении к новому серверу:

StrictHostKeyChecking ask

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

При первом подключении к новому серверу ваш SSH-клиент спросит вас, хотите ли вы принять ключ хоста и сохранить его в файле ~/.ssh/known_hosts. Очень важно проверить ключ хоста, прежде чем принимать его. Обычно эта процедура подразумевает отправку запроса администратору сервера или просмотр документации сервиса (в случае GitHub, GitLab и других подобных сервисов).

Сохраните изменения и выйдите из файла.

Мы настроили общие параметры безопасности, и теперь следует проверить синтаксис новой конфигурации, запустив SSH в тестовом режиме:

ssh -G .

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

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

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

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

2: Отключение слабых шифров OpenSSH

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

Для начала откроем глобальный конфигурационный файл в текстовом редакторе:

sudo nano /etc/ssh/ssh_config

Закомментируйте стандартную конфигурацию Ciphers, добавив в начало строки символ диеза.

Затем поместите в начало файла следующее:

Ciphers -arcfour*,-*cbc

Эта строка отключит устаревшие шифры Arcfour, а также все шифры, использующие Cipher Block Chaining (CBC), которые больше не рекомендуется использовать.

Если позже вам будет необходимо подключиться к системам, которые поддерживают только эти устаревшие шифры, вы можете явно включить требуемые шифры для определенных хостов с помощью блока Match. К примеру, чтобы включить шифр 3des-cbc для определенного хоста, можно использовать следующую настройку:

Match host legacy-server.your-domain

  Ciphers +3des-cbc

Сохраните изменения и выйдите из файла.

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

ssh -G .

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

ssh -G legacy-server.your-domain

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

3: Защита конфигурационных файлов и закрытых ключей

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

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

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

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

stat -c "%a %A %U:%G" /etc/ssh/ssh_config

Аргумент -c определяет формат вывода.

Примечание: В некоторых операционных системах, таких как macOS, нужно использовать параметр -f, а не -c.

В этом случае опция %A %a %U:%G выведет привилегии файла в восьмеричном и удобочитаемом формате, а также пользователя и группу, которым принадлежит этот файл.

Вывод будет примерно таким:

644 -rw-r--r-- root:root

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

Читайте также: Привилегии в Linux: что это и как с ними работать

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

sudo chown root:root /etc/ssh/ssh_config

sudo chmod 644 /etc/ssh/ssh_config

Если вы теперь повторите команду stat, которую мы использовали ранее, вы увидите, что общесистемный файл конфигурации имеет правильные привилегии.

Проверка закрытых ключей

Затем вы можете повторить эту проверку для своего локального конфигурационного файла SSH-клиента, если он у вас есть:

stat -c "%a %A %U:%G" ~/.ssh/config

Вы увидите примерно следующее:

644 -rw--r--r-- user:user

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

chown user:user ~/.ssh/config

chmod 644 ~/.ssh/config

Затем вы можете проверить привилегии каждого из закрытых ключей SSH, которые хранятся в вашем каталоге ~/.ssh, поскольку эти файлы должны быть доступны только вам и никаким другим пользователям в системе.

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

stat -c "%a %A %U:%G" ~/.ssh/id_rsa

Вы должны получить такой результат:

600 -rw------- user:user

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

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

chown user:user ~/.ssh/id_rsa

chmod 600 ~/.ssh/id_rsa

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

4: Ограничение исходящего трафика с помощью списка разрешенных хостов

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

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

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

Читайте также: Основы UFW: общие правила и команды фаервола

Однако если вы хотите настроить несколько дополнительных средств защиты от сбоев, этот уровень безопасности может быть вам полезен.

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

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

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

Откройте или создайте файл, если он еще не существует:

nano ~/.ssh/config

В конец файла добавьте следующий блок, подставив в него список ваших доверенных IP-адресов и имен хостов:

Match host !203.0.113.1,!192.0.2.1,!server1.your-domain,!github.com,*

  Hostname localhost

Вы должны поставить перед IP-адресами или именами хостов восклицательный знак (!). Все элементы в списке нужно указывать через запятую. Последним элементом списка должна быть одна звездочка (*) без восклицательного знака.

Если на вашем компьютере также запущен SSH-сервер, вы можете использовать другое имя хоста вместо localhost, поскольку это приведет к отправке нулевых соединений на ваш локальный SSH-сервер. Вы можете указать любое имя хоста с нулевым маршрутом, например null, do-not-use или disallowed-server.

Сохраните и закройте файл после внесения изменений.

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

ssh disallowed.your-domain

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

Cannot connect to localhost: connection refused

Но если вы попробуете подключиться к доверенному адресу или хосту, подключение будет успешно установлено.

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

Заключение

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

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

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

Также рекомендуем обратиться к нашему мануалу Повышение безопасности OpenSSH в Ubuntu.