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

Обновлено: 22.01.2025

Примеры многоязычного шифрования и дешифрования 3DES

Работа часто включает соединение шифрования и дешифрования 3DES с разными языками программирования.Многие языки все еще имеют некоторые различия в деталях одного и того же алгоритма шифрования, таких как режим шифрования и метод заполнения.

DES использует блочное шифрование, ключ шифрования составляет 56 бит, а размер блока - 64 бита. Поскольку 56-битную версию шифрования DES очень легко взломать (обычно в течение дня после установки машины), существует алгоритм 3DES, совместимый с DES.

принцип

Алгоритм шифрования 3DES выражается как C=EncryptK3(DecryptK2(EncryptK1(message) , Если K1, K2 и K3 являются ключами, если они не совпадают, длина ключа шифрования эквивалентна 112 (посколькуВстречная атака); алгоритм дешифрования выражается как message=DecryptK1((EncryptK2(DecryptK3(C)))

В качестве примера возьмем алгоритм шифрования:

Режим работы блочного шифра

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

См. Введение в режим работы блочного шифра.wiki

Общие рабочие режимы включают ECB, CBC, OFB и CFB и т. Д.

Вектор инициализации блочного шифра (IV)

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

Заполнение блочного шифра

Байт в текст после шифрования

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

заметка

Обратите внимание на использование Cipher.getInstance При выборе алгоритма шифрования и дешифрования, если вы выберете desede, то есть после игнорирования рабочего режима и режима заполнения будет использоваться значение по умолчанию «/ ECB / PKCS5Padding». Поскольку методы по умолчанию для других языков могут отличаться, это вызовет нарушения в шифровании и дешифровании разных языков.

При использовании производственной среды вам необходимо обрабатывать исключения

Python

Python2

Python3

заметка

Обратите внимание, что кодировка base64 устарела, и "\ n" будет добавлен в конце, используя вместо этого b64encode.

python2 cipher.decrypt с участием cipher.encrypt так же как base64.b64encode с участием base64.b64decode Что вернулось str , И то, что возвращается в python3, bytes . Таким образом, нет необходимости использовать ord для получения соответствующего значения ascii символа при распаковке в python3.

NodeJS

заметка

в nodejs crypto Положитесь на openssl, используйте >openssl list-cipher-algorithms Получите список поддерживаемых алгоритмов. Если вам нужно выбрать другие алгоритмы, вы можете обратиться к openssl.

На самом деле Desede - это другое название 3des (возможно и обратное).

Обратите внимание, что при использовании nodejs используйте createDecipheriv , IV можно передать в new Buffer(0)

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

Но я попытался найти эти шифры в файлах ssh_config и sshd_config, но нашел их прокомментированными.

Где еще я должен проверить, чтобы отключить эти шифры от SSH?

для сервера SSH он будет, /etc/ssh/sshd_config а для клиента SSH - /etc/ssh/ssh_config . Вы хотите искать Cipher строку в каждом, и, например, только что Cipher aes256-ctr указали. Затем перезапустите SSH с помощью /etc/init.d/sshd restart или с помощью эквивалентной команды systemd. Вы хотите стать осведомленным обо всех параметрах, sshd_config если вы действительно заботитесь о безопасности SSH, иначе это может быть весь театр безопасности. @ Второй комментарий интригующий, можете ли вы проиллюстрировать на примере, что вы намереваетесь? ciphers список только один настройки из многих за то, что SSH должным образом реализован . Протокол, PermitRootLogin, AuthorizedKeysFile, PermitEmptyPasswords, IgnoreRhosts, PermitTunnel, и так далее. Вы можете рассчитывать на их настройки по умолчанию , как реализовано в дистрибутив Linux, но Ignornance is bliss only up until you have a problem

Если у вас нет явного списка шифров, заданных с ssh_config использованием Ciphers ключевого слова, то значение по умолчанию, согласно man 5 ssh_config (на стороне клиента) и man 5 sshd_config (на стороне сервера), будет:

Обратите внимание на наличие шифров arcfour. Так что вам, возможно, придется явно установить более ограничительное значение для Ciphers .

ssh -Q cipher от клиента скажет вам, какие схемы может поддерживать ваш клиент. Обратите внимание, что на этот список не влияет список шифров, указанный в ssh_config . Удаление шифра из ssh_config не удалит его с выхода ssh -Q cipher . Кроме того, использование ssh с -c возможностью явного указания шифра переопределит ограниченный список шифров, которые вы установили, ssh_config и, возможно, позволит вам использовать слабый шифр. Это функция, которая позволяет вам использовать ваш ssh клиент для связи с устаревшими серверами SSH, которые не поддерживают более новые более надежные шифры.

nmap --script ssh2-enum-algos -sV -p <port> <host> скажет вам, какие схемы поддерживает ваш сервер.

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

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

Клиент OpenSSH – это, как следует из названия, клиентская сторона 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, установив следующие параметры:

Затем мы рассмотрим возможность отключения 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-адресов и имен хостов:

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

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

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

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

Cannot connect to localhost: connection refused

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

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

Заключение

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

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

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

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

06.07.2019

Windows Server 2012 R2

комментария 4
В октябре инженеры Google опубликовали информацию о критической уязвимости в SSL версии 3.0, получившей забавное название POODLE (Padding Oracle On Downgraded Legacy Encryption или пудель 🙂 ). Уязвимость позволяет злоумышленнику получить доступ к информации, зашифрованной протоколом SSLv3 с помощью атаки «man in the middle». Уязвимости подвержены как серверы, так и клиенты, которые могут соединяться по протоколу SSLv3.

В общем-то ситуация не удивительная, т.к. протоколу SSL 3.0, впервые представленного еще в 1996 году, уже исполнилось 18 лет и морально он уже устарел. В большинстве практических задач его уже заменил криптографический протокол TLS (версий 1.0, 1.1 и 1.2).
Примечание. Нужно четко понимать, что отключение SSL v3 на уровне всей системы будет работать только для ПО, которое использует системные API для SSL-шифрования (Internet Explorer, IIS, WebDav , SQL NLA, RRAS, Direct Access и др.). Программы, которые используют собственные крипто средства (Firefox, Opera и т.д.) нужно обновить и настроить индивидуально.
Отключаем SSLv3 в Windows на уровне системы

В ОС Windows управление поддержкой протоколов SSL/TLS осуществляется через реестр.
Совет. Перед выполнением указанных изменений рекомендуем создать резервную копию указанной ветки с помощью функции редактора реестра Экспорт.
В этом примере мы покажем, как полностью на уровне системы (как на уровне клиента, так и сервера) отключить SSLv3 в Windows Server 2012 R2:

Отключаем SSLv2 (Windows 2008 / Server и ниже)

В ОС, предшествующих Windows 7 / Windows Server 2008 R2 по-умолчанию используется еще менее безопасный и устаревший протокол SSL v2, который также следует отключить из соображений безопасности (в более свежих версиях Windows, SSLv2 на уровне клиента отключен по умолчанию и используется только SSLv3 и TLS1.0). Для отключения SSLv2 нужно повторить описанную выше процедуру, только для раздела реестра SSL 2.0.

В Windows 2008 / 2012 SSLv2 на уровне клиента отключен по умолчанию.

Включаем TLS 1.1 и TLS 1.2 в Windows Server 2008 R2 и выше

Windows Server 2008 R2 / Windows 7 и выше поддерживают алгоритмы шифрования TLS 1.1 и TLS 1.2, но по-умолчанию эти протоколы отключены. Включить поддержку TLS 1.1 и TLS 1.2 в этих версиях Windows можно по схожему сценарию
1. В редакторе реестра откройте ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
2. Создайте два раздела TLS 1.1 и TLS 1.2
3. Внутри каждого раздела создайте по подразделу с именами Client и Server
4. В каждом из разделов Client и Server создайте по ключу типа DWORD:
  - DisabledByDefault со значением 0
  - Enabled со значением 1
5. После внесенных изменений сервер следует перезагрузить.
Утилита для управления системными криптографическими протоколами в Windows Server

Существует бесплатная утилита IIS Crypto, позволяющая удобно управлять параметрами криптографических протоколов в Windows Server 2003, 2008 и 2012. С помощью данной утилиты включить или отключить любой из протоколов шифрования можно всего в два клика.

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

Читайте также: