Отключить поддержку шифров 3des linux

Атака SWEET32: Исследователи обнаружили новый способ взлома шифров 3DES и Blowfish

Исследователи информационной безопасности Картикеян Баргаван (Karthikeyan Bhargavan) и Гаетан Лоран (Gaëtan Leuren) разработали атаку на шифры 3DES и Blowfish. Например, с ее помощью можно получить использующиеся для аутентификации cookie из зашифрованного 3DES HTTPS-трафика, а также восстанавливать имена пользователей и пароли из зашифрованного с помощью Blowfish трафика, передаваемого через VPN.

Атака, которая получила название SWEET32, посвящен отдельный сайт, ее подробности и демо-видео исследователи планируют представить на конференции ACM Conference on Computer and Communications Security, которая в следующем месяце пройдет в Австрии. Мы собрали известную на данный момент информацию в своем материале.

В чем проблема

Криптографические протоколы вроде TLS, SSH, IPsec и OpenVPN используют алгоритмы блочного шифрования (AES, Triple-DES, Blowfish). Таким образом обеспечивается шифрование передаваемых между клиентом и сервером данных. Данные при этом разбиваются на блоки фиксированной длины, каждый из которых шифруется отдельно. Более старые шифры вроде Triple-DES и Blowfish используют размер блока равный 64 битам, а AES использует размер блока 128 бит.

Короткая длина блока делает шифр уязвимым к «атакам дня рождения». Исследователи заявляют о том, что подобные атаки встречаются для 64-битных шифров протоколов TLS и OpenVPN. Подобные алгоритмы шифрования используются огромным количеством ресурсов в интернете.

SWEET32 — это атака поиска коллизий в режиме сцепления блоков с использованием обратной связи CBC. Например, злоумышленник, который может мониторить долго существующие Triple-DES HTTPS-соединения между браузером и сайтом, имеет возможность восстановить HTTP-cookies — для этого нужно будет сохранить 785 гигабайт трафика.

Перехват защищенного трафика

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

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

С точки зрения вычислительной сложности атака SWEET32 сравнима с недавними атаками на шифр RC4. Кроме того, исследователям удалось осуществить похожие атаки на VPN-сессии, использующие 64-битные шифры — к примеру, на практике эта ситуация может встретиться в случае применения OpenVPN, который настроен на использование Blowfish.

Насколько все серьезно

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

Такая ситуация возможна — все зависит от сервера, поскольку все протестированные браузеры (Firefox, Chrome, Opera) используют TLS-соединение до тех пор, пока сервер держит его открытым. В свою очередь, многие HTTP-серверы закрывают TLS-соединение по достижению определенного лимита переданного трафика, даже если оно еще остается активным. К примеру, Apache и Nginx ограничивают число запросов, которые можно отправить в рамках одного соединения, числом 100. Но, к примеру, у IIS при использовании стандартных настроек подобных лимитов нет.

В итоге общее число серверов, которые принимают большое количество запросов по одному соединению, остается большим, пишут исследователи. Исследователи просканировали веб-серверы из каталога Alexa — для этого использовался инструмент cipherscan. Выяснилось, что 86%, поддерживающих TLS, включают Triple-DES в качестве одного из используемых шифров.

Были выявлены 11483 разных HTTPS-северов, 226 (1.9%) из которых обмениваются с клиентами данными с помощью Triple-DES. 72 из этих серверов (0.6% от общего числа) держали соединение открытым как минимум для 800 тысяч запросов. Это значит, что длительность тестовой атаки не говорит о ее нереализуемости — около 0,6% HTTPS-соединений в интернете уязвимы перед ней.

PoC-атака

Ниже представлен код атаки SWEET32. Для ее осуществления используются веб-воркеры, генерирующие XmlHttpRequests.

Содержание файла attack.html:

В ходе эксперимента «захват» зашифрованных пакетов проводился с помощью tcpdump, а для извлечения блоков шифротекста применялась программа на C++, использующая libpcap.

В случаях атаки на HTTPS и VPN каждый запрос отправляется в отдельной зашифрованной записи, содержащей обычный текст в фиксированной позиции. Это позволяет атакующему знать, к какому блоку открытого текста относится блок шифротекста (и, например, соответствующим образом назначать cookie до лимита блокировки). После сохранения необходимого объёма трафика программа на C++ сортирует блоки шифротекста для выявления коллизий. На расшифровку сохраненного трафика у исследователей ушло около четырех часов.

Как защититься

Исследователи рекомендуют отказаться от использования 64-битных “legacy-шифров” блочного шифрования. Если же это по какой-то причине невозможно, то снизить вероятность ее успешного проведения можно следующим образом:

Веб-серверы и VPN должны быть настроены на предпочтение 128-битных шифров. Согласно данным исследователей, около 1,1% процента из 100 тысяч самых популярных сайтов каталога Alexa и 0,5% из миллиона самых популярных поддерживают AES, но предпочитают использовать 3DES.

Веб-браузеры должны использовать 3DES в качестве “fallback-only” шифра во избежание ситуации, при которой он используется в общении с серверами, поддерживающими AES.

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

Пользователи OpenVPN могут изменить используемый шифр с «дефолтного» Blowfish на AES. Если сделать этого нельзя, то необходимо принудительно инициировать повторный выпуск ключей с помощью функции reneg-bytes 64000000.

Источник

Отключить поддержку шифров 3des linux

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

During an update of our gold image for Server 2008 R2 I disabled 3DES via the registry to mitigate the SWEET32 birthday attack vulnerability. The registry setting I used to disable 3DES is DWORD «Enabled» = 0 at path HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168. The vulnerability was successfully mitigated, but I could no longer RDP to the server. The following error message is displayed: «This computer can’t connect to the remote computer. Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.» As it turns out, it doesn’t matter whether the «Enabled» DWORD is set to 0 or 1 — RDP is broken either way. It starts working again if I delete «Enabled», but this obviously then doesn’t mitigate the vulnerability. I tested this on multiple servers in our lab.

I should also mention that we are required to have «System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing» set to Enabled. If I disable this setting with 3DES disabled, RDP works. So, it appears that having the FIPS setting enabled requires 3DES to also be enabled. However, this is not the case on our Server 2012 R2 machines. I’ve tested multiple servers in our lab with 2012 R2 installed and have been able to disable 3DES while keeping the FIPS setting enabled and have no issues RDPing the servers. This is the desired configuration and result on 2008 R2.

I’ve searched all over the internet and haven’t been able to find a fix. Any help is greatly appreciated.

Answers

Apparently 2008 and 2012 have syntax issues and the 2008/7 requires a trailing /168. 2012/8.1/10 does not.

the key on 2008 looks like this: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\ Triple DES 168/168

And the key on 2012 looks like this: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\ Triple DES 168

I can confirm that use of «Triple DES 168/168» DOES NOT disable 3DES on the system. You can prove this to yourself with a protocol scanner (like Nessus) or by enabling SCHANNEL logging:

You will then have events in the SYSTEM log for example;

An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows.

Protocol: TLS 1.0 CipherSuite: 0x2f Exchange strength: 1024

For me the result is 0xa which Google reveals as TLS_RSA_WITH_3DES_EDE_CBC_SHA.

When I use «Triple DES 168» (without the /168), the System event ID 36880 does not appear and the RDP session is blocked.

For encrypting Remote Desktop Services network communication, this policy setting supports only the Triple DES encryption algorithm.

This setting also affects Terminal Services in Windows Server 2003 and in later versions of Windows. The effect depends on whether TLS is being used for server authentication.

If TLS is being used for server authentication, this setting causes only TLS 1.0 to be used.

By default, if TLS is not being used, and this setting is not enabled on the client or on the server, the Remote Desktop Protocol (RDP) channel between the server and the client is encrypted by using the RC4 algorithm with a 128-bit key length. After you enable this setting on a Windows Server 2003-based computer, the following is true:

• The RDP channel is encrypted by using the 3DES algorithm in Cipher Block Chaining (CBC) mode with a 168-bit key length.
• The SHA-1 algorithm is used to create message digests.
• Clients must use the RDP 5.2 client program or a later version to connect.

So both of these support the idea that RDP can only utilize 3DES. However, this article suggests a larger range of ciphers is available: FIPS 140 Validation

The set of cryptographic algorithms that a Remote Desktop Protocol (RDP) server will use is scoped to:

• CALG_RSA_KEYX — RSA public key exchange algorithm
• CALG_3DES — Triple DES encryption algorithm
• CALG_AES_128 — 128 bit AES
• CALG_AES_256 — 256 bit AES
• CALG_SHA1 — SHA hashing algorithm
• CALG_SHA_256 — 256 bit SHA hashing algorithm
• CALG_SHA_384 — 384 bit SHA hashing algorithm
• CALG_SHA_512 — 512 bit SHA hashing algorithm

Ultimately it’s not clear whether RDP can support non-3DES protocols when FIPS mode is enabled but evidence would suggest it doesn’t.

I see no evidence that Server 2012 R2 would function differently from Server 2008 R2, however it does seem that Server 2008 R2 was based around FIPS 140-1 compliance and Server 2012 R2 follows FIPS 140-2 so it’s entirely possible that Server 2012 R2 supports additional protocols. You’ll note the additional protocols in the FIPS 140 Validation link.

In conclusion: I don’t think Server 2008 R2 can support RDP in FIPS mode with 3DES disabled. My recommendation is to ascertain whether your system meets the conditions for a SWEET32 attack (more than 768GB sent in a single session) and whether disabling 3DES is worth removing RDP capability. Other utilities exist to manage servers beyond RDP especially in a world where virtualization is highly commonplace.

Источник

SWEET32 vulnerability and disabling 3DES

The help desk software for IT. Free.

Track users’ IT needs, easily, and with only the features you need.

I’m trying to mitigate the SWEET32 vulnerability on a 2008R2 server.

Starting Nmap 7.40 ( https://nmap.org ) at 2017-06-28 15:49 GMT Summer Time

Nmap scan report for xx.xx.xx.xx

Host is up (0.0044s latency).

PORT STATE SERVICE VERSION

8194/tcp open ssl/giop omg.org CORBA naming service

| cipher preference: client

| 64-bit block cipher 3DES vulnerable to SWEET32 attack

| Insecure certificate signature: MD5

| cipher preference: client

| 64-bit block cipher 3DES vulnerable to SWEET32 attack

| Insecure certificate signature: MD5

| cipher preference: client

| 64-bit block cipher 3DES vulnerable to SWEET32 attack

| Insecure certificate signature: MD5

|_ least strength: F

Thanks in advance.

Go to the Cipher Suite list and find TLS_RSA_WITH_3DES_EDE_CBC_SHA and uncheck.

Also, visit About and push the [Check for Updates] button if you are using the tool and its been a while since you installed it.

Final thought is, that your environment may have have a group policy that creates the list of cipher suites (the long list of TLS_ strings like the one above).

Final thought II: In Linux-land or wherever openssl is in play, I usually go to the Mozilla wiki on TLS for all the details on apache, ngnix, tomcat or what not to solve these problems there. It is usually a change in a configuration file.

Источник

Повышение безопасности клиента 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).
• SSH-сервер, к которому вы хотите подключиться, например:
  • Облачный сервер.
  • Публичный сервис типа 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.

Источник