Повышение безопасности клиента OpenSSH в Ubuntu
Управление серверами Linux часто осуществляется удаленно, с помощью SSH. Это происходит путем подключения к серверу OpenSSH, стандартному программному обеспечению SSH-сервера в системах Ubuntu, Debian, CentOS, FreeBSD и в большинстве других систем на основе Linux и BSD.
Защита серверной стороны SSH требует значительных усилий, поскольку SSH – это по сути вход на ваш сервер. Однако безопасность на стороне клиента (например, клиента OpenSSH) также важно учитывать.
Клиент OpenSSH – это, как следует из названия, клиентская сторона SSH, также известная как команда ssh.
Основная цель при настройке безопасности SSH на серверной стороне – затруднить доступ злоумышленников к вашему серверу. Однако повышение защиты клиентской стороны SSH сильно отличается, ее цель – обезопасить SSH-соединение и предотвратить различные угрозы, в том числе:
-
.
- Получение вредоносных пакетов и управляющих последовательностей, а также слишком больших объемов данных, которые могут перегрузить ваш клиент.
- Ошибки, вызванные человеческим фактором: неверный ввод адреса сервера или конфигураций.
В этом руководстве вы научитесь защищать клиент OpenSSH и обеспечивать максимальную безопасность исходящих SSH-соединений.
Требования
- Устройство, которое выступит SSH-клиентом. К примеру, это может быть:
- Ваш персональный компьютер. .
- Сервер Ubuntu 18.04, настроенный по этому мануалу (включая пользователя sudo).
- Облачный сервер.
- Публичный сервис типа GitHub или GitLab
- Стороннее устройство, к которому у вас есть доступ.
Войдите на свое клиентское устройство SSH как пользователь sudo, чтобы начать работу.
1: Общая безопасность
Давайте рассмотрим начальные конфигурации повышения безопасности, которые позволят вам улучшить общую защиту SSH-клиента.
Резервное копирование конфигураций
Многие конфигурации безопасности клиента OpenSSH реализуются в глобальном конфигурационном файле клиента OpenSSH, /etc/ssh/ssh_config. Кроме того, некоторые конфигурации могут быть записаны в локальный конфигурационный файл SSH вашего пользователя,
Прежде чем продолжить изучение руководства, советуем сделать резервную копию этих двух файлов, чтобы иметь возможность восстановить их в случае, если что-то пойдет не так (пусть даже это маловероятно). Для этого используйте следующие команды:
sudo cp /etc/ssh/ssh_config /etc/ssh/ssh_config.bak
Это позволит сохранить резервную копию файлов в их стандартном расположении, но с расширением .bak.
Обратите внимание, ваш локальный конфигурационный файл SSH (
/.ssh/config) может не существовать, если вы не использовали его раньше. Если это так, то его можно спокойно проигнорировать.
Базовые параметры безопасности
Почти всегда конфигурация защиты индивидуальна: она зависит от модели угроз и порога риска. Здесь мы опишем общую настройку, которая должна подойти большинству пользователей. Позже вы сможете самостоятельно подогнать ее под свои требования.
После резервного копирования вы можете открыть глобальный конфигурационный файл с помощью текстового редактора, чтобы приступить ко внедрению начальных мер по усилению защиты:
sudo nano /etc/ssh/ssh_config
Примечание: Конфигурационный файл клиента OpenSSH включает в себя множество параметров по умолчанию. В зависимости от существующей настройки клиента некоторые из рекомендуемых параметров безопасности могут быть уже установлены.
При редактировании конфигурации некоторые параметры могут по умолчанию быть закомментированы с помощью диеза (#) в начале строки. Чтобы отредактировать эти параметры или включить закомментированную опцию, вам нужно раскомментировать их, удалив диез.
Во-первых, нужно отключить поддержку X11-forwarding по SSH, установив следующие параметры:
X11-forwarding позволяет отображать удаленные графические приложения через SSH-соединение, однако на практике это редко используется. Отключив этот параметр, вы можете предотвратить попытки потенциально вредоносных и взломанных серверов перенаправить сессию X11 вашему клиенту, что в некоторых случаях позволяет обходить привилегии файловой системы или отслеживать локальные нажатия клавиш.
Затем мы рассмотрим возможность отключения SSH-туннелирования. SSH-туннелирование широко используется в работе, поэтому вам, возможно, придется оставить его включенным. Однако если вы не пользуетесь этой функцией, вы можете спокойно отключить ее в качестве дополнительной меры безопасности:
Также стоит подумать об отключении переадресации агента SSH, если она вам не нужна, и тогда серверы не будут запрашивать локальный SSH агент для аутентификации последующих SSH-соединений:
В большинстве случаев при подключении к серверам SSH-клиент использует парольную аутентификацию или аутентификацию по открытым ключам. Однако клиент OpenSSH также поддерживает другие методы аутентификации, и некоторые из которых включены по умолчанию. Если они не используются, их можно отключить, чтобы уменьшить поверхность потенциальной атаки:
Если вы хотите узнать больше о дополнительных методах аутентификации, доступных в SSH, вы можете обратиться к следующим ресурсам:
При подключении к серверам клиент OpenSSH позволяет автоматически передавать пользовательские переменные среды, например, для установки языковых предпочтений или настройки параметров терминала. Но если в вашей настройке это не нужно, вы можете заблокировать отправку любых переменных, закомментировав или удалив параметр SendEnv:
Строгая проверка ключа хоста должна быть включена – она отправит вам соответствующее предупреждение при изменении ключа хоста (или контрольной суммы) удаленного сервера или при первом подключении к новому серверу:
Эта опция предотвратит подключение к серверу при изменении известного ключа хоста (это может означать, что сервер был пересобран или обновлен, но также может указывать на атаку посредника).
При первом подключении к новому серверу ваш SSH-клиент спросит вас, хотите ли вы принять ключ хоста и сохранить его в файле
/.ssh/known_hosts. Очень важно проверить ключ хоста, прежде чем принимать его. Обычно эта процедура подразумевает отправку запроса администратору сервера или просмотр документации сервиса (в случае GitHub, GitLab и других подобных сервисов).
Сохраните изменения и выйдите из файла.
Мы настроили общие параметры безопасности, и теперь следует проверить синтаксис новой конфигурации, запустив SSH в тестовом режиме:
Вы можете заменить символ точки в команде любым именем хоста, если вам нужно протестировать его настройки в блоках Match или Host.
Если конфигурации имеют допустимый синтаксис, команда выведет на экран параметры, которые будут применяться к этому конкретному соединению. В случае ошибки на экране появится описание проблемы.
Вам не нужно перезапускать системные сервисы, чтобы новая конфигурация вступила в силу, хотя вам придется повторно установить текущие сеансы SSH, если вы хотите, чтобы они унаследовали новые настройки.
Настройка общей безопасности клиента OpenSSH завершена. Давайте теперь посмотрим, какие шифры доступны для использования в SSH-соединениях.
2: Отключение слабых шифров OpenSSH
Сейчас мы изучим наборы шифров, доступные на вашем SSH-клиенте, и отключим поддержку устаревших шифров.
Для начала откроем глобальный конфигурационный файл в текстовом редакторе:
sudo nano /etc/ssh/ssh_config
Закомментируйте стандартную конфигурацию Ciphers, добавив в начало строки символ диеза.
Затем поместите в начало файла следующее:
Эта строка отключит устаревшие шифры Arcfour, а также все шифры, использующие Cipher Block Chaining (CBC), которые больше не рекомендуется использовать.
Если позже вам будет необходимо подключиться к системам, которые поддерживают только эти устаревшие шифры, вы можете явно включить требуемые шифры для определенных хостов с помощью блока Match. К примеру, чтобы включить шифр 3des-cbc для определенного хоста, можно использовать следующую настройку:
Match host legacy-server.your-domain
Сохраните изменения и выйдите из файла.
Сейчас, как и в разделе 1, вы можете снова протестировать новую конфигурацию клиента SSH, чтобы проверить наличие ошибок:
Если вы добавили блок 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 имеет права на его изменение.
Однако если ваш вывод отличается, вам следует сбросить привилегии до значений по умолчанию, используя следующие команды:
sudo chown root:root /etc/ssh/ssh_config
sudo chmod 644 /etc/ssh/ssh_config
Если вы теперь повторите команду stat, которую мы использовали ранее, вы увидите, что общесистемный файл конфигурации имеет правильные привилегии.
Проверка закрытых ключей
Затем вы можете повторить эту проверку для своего локального конфигурационного файла SSH-клиента, если он у вас есть:
Вы увидите примерно следующее:
644 -rw—r—r— user:user
Если привилегии вашего локального файла отличаются, вы должны сбросить их с помощью этих команд, как и ранее:
Затем вы можете проверить привилегии каждого из закрытых ключей SSH, которые хранятся в вашем каталоге
/.ssh, поскольку эти файлы должны быть доступны только вам и никаким другим пользователям в системе.
Начните с проверки текущих привилегий и прав собственности для каждого закрытого ключа:
Вы должны получить такой результат:
600 -rw——- user:user
Чрезвычайно важно правильно ограничить права доступа к закрытым ключам, в противном случае другие пользователи вашего устройства могут украсть их и получить доступ к связанным с ними серверам или учетным записям удаленных пользователей.
Если привилегии установлены неправильно, используйте следующие команды для каждого файла закрытого ключа, чтобы сбросить их до безопасных значений по умолчанию:
В этом разделе вы проверили привилегии конфиденциальных файлов и заблокировали доступ к ним. Теперь нам нужно установить правила для исходящего трафика, чтобы ограничить количество серверов, к которым может подключаться ваш клиент.
4: Ограничение исходящего трафика с помощью списка разрешенных хостов
В последнем разделе этого мануала мы настроим список разрешений (allowlist), который ограничит хосты, к которым может подключаться ваш SSH-клиент. Это особенно полезно для многопользовательских систем, а также для инсталляционных серверов.
Этот уровень безопасности специально разработан для защиты от человеческого фактора – таких ошибок, как неправильный ввод адресов или имен хостов. Пользователь может легко обойти его, отредактировав свой локальный конфигурационный файл, и поэтому этот уровень не предназначен для защиты от злоумышленников.
Если вы хотите ограничить исходящие соединения на сетевом уровне, вы должны использовать для этого брандмауэр. Данная тема выходит за рамки нашего руководства.
Однако если вы хотите настроить несколько дополнительных средств защиты от сбоев, этот уровень безопасности может быть вам полезен.
Он работает на основе правил подстановки, которые хранятся в конфигурации вашего SSH-клиента, и обнуляет маршрутизацию всех исходящих подключений, кроме определенных адресов или хостов.
Следовательно, если вы когда-либо допустите ошибку в адресе сервера или попытаетесь подключиться к серверу, к которому не должны подключаться, запрос будет немедленно сброшен, что даст вам возможность обнаружить свою ошибку исправить ее.
Вы можете применить это либо на системном уровне (/etc/ssh/ssh_config), либо локально (
/.ssh/config). В этом примере мы будем использовать локальный конфигурационный файл.
Откройте или создайте файл, если он еще не существует:
В конец файла добавьте следующий блок, подставив в него список ваших доверенных IP-адресов и имен хостов:
Match host !203.0.113.1,!192.0.2.1,!server1.your-domain,!github.com,*
Вы должны поставить перед IP-адресами или именами хостов восклицательный знак (!). Все элементы в списке нужно указывать через запятую. Последним элементом списка должна быть одна звездочка (*) без восклицательного знака.
Если на вашем компьютере также запущен SSH-сервер, вы можете использовать другое имя хоста вместо localhost, поскольку это приведет к отправке нулевых соединений на ваш локальный SSH-сервер. Вы можете указать любое имя хоста с нулевым маршрутом, например null, do-not-use или disallowed-server.
Сохраните и закройте файл после внесения изменений.
Теперь вы можете проверить, работает ли наша новая конфигурация. Для этого с помощью SSH-клиента мы попытаемся подключиться к запрещенному адресу или хосту:
Если конфигурация работает правильно, вы сразу получите сообщение об ошибке:
Cannot connect to localhost: connection refused
Но если вы попробуете подключиться к доверенному адресу или хосту, подключение будет успешно установлено.
Только что мы успешно внедрили дополнительные средства безопасности, чтобы защититься от ошибок, связанных с человеческим фактором.
Заключение
В этой статье мы изучили конфигурацию клиента OpenSSH и реализовали различные меры по усилению его защиты.
Это повысит безопасность ваших исходящих SSH-соединений, а также не даст другим пользователям случайно или намеренно внести вредоносные изменения в ваши локальные конфигурации.
За дополнительной информацией можно обратиться к документации клиента OpenSSH – она поможет вам определить возможные дальнейшие настройки.
Также рекомендуем обратиться к нашему мануалу Повышение безопасности OpenSSH в Ubuntu.
Windows: Disable DES and Triple DES (3DES)
a measure to protect your Windows System against Sweet32 attacks is to disable the DES and Triple DES.
To do this, add 2 Registry Keys to the SCHANNEL Section of the registry.
As registry file
or from command line
3 thoughts on “Windows: Disable DES and Triple DES (3DES)”
. Disable TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 1024), 64-bit block cipher 3DES vulnerable to SWEET32 attack .
. References
:: Get OS version:
:: stackoverflow.com/questions/13212033/get-windows-version-in-a-batch-file:: OS Name to OS version:
:: msdn.microsoft.com/en-us/library/windows/desktop/ms724832(v=vs.85).aspx:: Windows command comparing
:: stackoverflow.com/questions/9278614/if-greater-than-batch-files:: Find OS version:
for /f “tokens=4-7 delims=[.] ” %%i in (‘ver’) do (if %%i==Version (set v=%%j.%%k) else (set v=%%i.%%j))
echo %v%:: Check if OS version is greater than or equal to “6.2” (Win2012 or up)
if %v% GEQ 6.2 (reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168” /f & reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168” /v Enabled /d 0 /t REG_DWORD /f):: Check if OS version is less than “6.2” (before Win2012)
if %v% LSS 6.2 (reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168” /f & reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168” /v Enabled /d 0 /t REG_DWORD /f)reg query “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\
. End of disabling 3DES cipher .Disable 3DES SSL Ciphers in Apache on Centos 7
A very popular Web Site Security Audit tool I use to keep track of vulnerabilities as they develop on my website is a service called ScanMyServer. It’s a useful yet inexpensive online tool that does exactly what it promises. It automatically scans a website and emails a full security report that includes a score and letter grade based on the results.
A recent discovery the tool picked up was a weak cipher alert:
Sweet32 Birthday Attacks on 64-bit Block Ciphers in TLS and OpenVPN (DES-CBC3)Summary
This test detects SSL ciphers DES-CBC3 supported by the remote service for encrypting communications.
Solution
Disable 3DES SSL Ciphers in Apache
Disabling 3DES ciphers in Apache is about as easy too. Find where your ciphers are defined with the following command (again, presuming your Apache config is in /etc/httpd/):
Once you’ve found the file containing your cipher suite, make sure it contains ‘!3DES’. As of today, this is a suitable list:
After changing your cipher suite, test your config (httpd -t) and restart the service in question (service httpd restart).
Невозможно отключить 3DES-шифр в порту 443
Я отключил 3DES в реестре. Порт 3389 успешно отключил 3DES (TLS_RSA_WITH_3DES_EDE_CBC_SHA).
Тем не менее, шифры 3DES все еще встречаются в порту 443. Что нужно сделать, чтобы удалить шифры 3DES в порту 443?
Отключить 3DES:
3DES-шифры в порту 443:
Нет шифров 3DES в порту 3389:
