Опубликован вольный перевод статьи "Secure Secure Shell", в которой проанализированы проблемные алгоритмы шифрования, которые потенциально могут быть использованы АНБ для организации атак на SSH, а также даны практические рекомендации по повышению защиты SSH. В том числе показано, как запустить SSH-сервер в виде скрытого сервиса Tor.
Настройка SSH для использования наиболее защищённых алгоритмов шифрования
В свете появления сведений об организации АНБ атак, направленных на получение контроля над SSH-соединениями, подготовлено руководство с рекомендациями по усилению защищённости SSH. АНБ может получить контроль за SSH-соединением в случае использования уязвимых методов шифрования или в результате захвата приватных ключей. Ниже представлены советы по отключению потенциально проблемных алгоритмов и усилению защиты.
Обмен ключами.
Применяемые в SSH методы обмена ключей DH (Diffie-Hellman) и ECDH (Elliptic Curve Diffie-Hellman) можно считать безопасными. Из 8 поддерживаемых в SSH протоколов обмена ключами вызывают подозрения три, основанные на рекомендациях NIST: ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521. Не заслуживающими полного доверия также можно считать протоколы, использующие потенциально проблемный SHA1. Протоколы curve25519-sha256 и diffie-hellman-group-exchange-sha256 пока не вызывают сомнений в безопасности.
Для использования только заслуживающих доверия протоколов обмена ключами в /etc/ssh/sshd_config для сервера следует указать:
Аналогичные настройки для клиента, в /etc/ssh/ssh_config:
В /etc/ssh/moduli можно указать (или удалить строки с размером ключа, менее 2048):
Аутентификация.
В SSH поддерживается четыре алгоритма аутентификации по открытым ключам: DSA, ECDSA, Ed25519 и RSA. ECDSA завязан на технологиях NIST и должен быть отключен. К сожалению, если просто удалить ключ ECDSA, он будет повторно сгенерирован, поэтому можно воспользоваться обходным путём с создать заведомо нерабочую символическую ссылку, которая помешает сгенерировать и использовать ключ:
Так как размер ключей DSA не может превышать 1024, его тоже следует отключить тем же способом:
Далее, следует позаботиться о RSA, сгенерировав ключ большего размера:
Для создания клиентских ключей лучше использовать команды:
Симметричные шифры.
Из 15 поддерживаемых в SSH алгоритмов симметричного шифрования, используемых для организации защиты установленного канала связи, безопасными можно считать chacha20-poly1305, aes*-ctr и aes*-gcm. Шифры 3des-cbc и arcfour потенциально уязвимы в силу использования DES и RC4, cast128-cbc применяет слишком короткий размер блока (64 бит).
В итоге, в /etc/ssh/sshd_config рекомендуется добавить:
В /etc/ssh/ssh_config:
Код аутентичности сообщения (MAC).
Для шифров в режиме CTR для гарантирования целостности передаваемых блоков доверия заслуживает только метод Encrypt-then-MAC ("*-etm", MAC добавляется к уже зашифрованному блоку). Методы MAC-then-encrypt и Encrypt-and-MAC потенциально подвержены атакам. Из 18 доступных в SSH алгоритмов MAC сразу следует отбросить основанные на хэшах MD5 и SHA1, не стойких к выявлению коллизий, а также алгоритмы использующие размеры ключей менее 128 бит и размеры тегов менее 256 бит. В итоге, наиболее безопасными MAC можно считать hmac-sha2-512-etm и hmac-sha2-256-etm.
В /etc/ssh/sshd_config:
В /etc/ssh/ssh_config:
Защита от утечки ключей.
Наиболее простым способом получения контроля за SSH-соединением является захват ключей на стороне клиента или сервера. Рекомендации сводятся к соблюдению типовых правил поддержания безопасности системы:
- оперативная установка обновлений,
- установка программ только из надёжных источников,
- установка только действительно необходимых программ и сервисов,
- использование программ для которых доступны исходные тексты,
- включение дополнительных механизмов защиты
(Grsecurity, сборка с флагом -fstack-protector).
Для защиты ключей следует выбрать надёжный пароль доступа к клиентским файлам ключей. При формировании ключа для увеличения числа итераций хэширования можно использовать опцию "ssh-keygen -o -a число", что усложнит подбор пароля. Также можно сохранить ключи только на внешнем носителе, подключая его только во время соединения по SSH.
Защита от анализа транзитного трафика.
SSH-сервер можно настроить в виде скрытого сервиса Tor, что скроет IP, а также добавит дополнительный слой шифрования и аутентификации.
Для приема соединений только через скрытый сервис Tor можно использовать следующие настройки:
В /etc/ssh/sshd_config (для приема соединений из LAN следует вместо привязки к 127.0.0.1 использовать для ограничения доступа межетевой экран):
В /etc/tor/torrc добавим:
Имя скрытого хоста для подключения можно найти в файле /var/lib/tor/hidden_service/ssh/hostname.
Для настройки подключения клиента к скрытому сервису Tor в /etc/ssh/ssh_config можно добавить:
• Source: stribika.github.io/2015/01/04/secure-secure-shell.html
• Дополнение: замечания к данным в статье рекомендациям : cypherpunks.ru/articles/securing_ssh.html
Настройка SSH для использования наиболее защищённых алгоритмов шифрования
В свете появления сведений об организации АНБ атак, направленных на получение контроля над SSH-соединениями, подготовлено руководство с рекомендациями по усилению защищённости SSH. АНБ может получить контроль за SSH-соединением в случае использования уязвимых методов шифрования или в результате захвата приватных ключей. Ниже представлены советы по отключению потенциально проблемных алгоритмов и усилению защиты.
Обмен ключами.
Применяемые в SSH методы обмена ключей DH (Diffie-Hellman) и ECDH (Elliptic Curve Diffie-Hellman) можно считать безопасными. Из 8 поддерживаемых в SSH протоколов обмена ключами вызывают подозрения три, основанные на рекомендациях NIST: ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521. Не заслуживающими полного доверия также можно считать протоколы, использующие потенциально проблемный SHA1. Протоколы curve25519-sha256 и diffie-hellman-group-exchange-sha256 пока не вызывают сомнений в безопасности.
Для использования только заслуживающих доверия протоколов обмена ключами в /etc/ssh/sshd_config для сервера следует указать:
Code:
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256Аналогичные настройки для клиента, в /etc/ssh/ssh_config:
Code:
Host *
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Code:
ssh-keygen -G /tmp/moduli -b 4096
ssh-keygen -T /etc/ssh/moduli -f /tmp/moduliАутентификация.
В SSH поддерживается четыре алгоритма аутентификации по открытым ключам: DSA, ECDSA, Ed25519 и RSA. ECDSA завязан на технологиях NIST и должен быть отключен. К сожалению, если просто удалить ключ ECDSA, он будет повторно сгенерирован, поэтому можно воспользоваться обходным путём с создать заведомо нерабочую символическую ссылку, которая помешает сгенерировать и использовать ключ:
Code:
cd /etc/ssh
rm ssh_host_ecdsa_key*
rm ssh_host_key*
ln -s ssh_host_ecdsa_key ssh_host_ecdsa_key
ln -s ssh_host_key ssh_host_keyТак как размер ключей DSA не может превышать 1024, его тоже следует отключить тем же способом:
Code:
cd /etc/ssh
rm ssh_host_dsa_key*
ln -s ssh_host_dsa_key ssh_host_dsa_keyДалее, следует позаботиться о RSA, сгенерировав ключ большего размера:
Code:
cd /etc/ssh
rm ssh_host_rsa_key*
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/nullДля создания клиентских ключей лучше использовать команды:
Code:
ssh-keygen -t ed25519
ssh-keygen -t rsa -b 4096Симметричные шифры.
Из 15 поддерживаемых в SSH алгоритмов симметричного шифрования, используемых для организации защиты установленного канала связи, безопасными можно считать chacha20-poly1305, aes*-ctr и aes*-gcm. Шифры 3des-cbc и arcfour потенциально уязвимы в силу использования DES и RC4, cast128-cbc применяет слишком короткий размер блока (64 бит).
В итоге, в /etc/ssh/sshd_config рекомендуется добавить:
Code:
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctrВ /etc/ssh/ssh_config:
Code:
Host *
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctrКод аутентичности сообщения (MAC).
Для шифров в режиме CTR для гарантирования целостности передаваемых блоков доверия заслуживает только метод Encrypt-then-MAC ("*-etm", MAC добавляется к уже зашифрованному блоку). Методы MAC-then-encrypt и Encrypt-and-MAC потенциально подвержены атакам. Из 18 доступных в SSH алгоритмов MAC сразу следует отбросить основанные на хэшах MD5 и SHA1, не стойких к выявлению коллизий, а также алгоритмы использующие размеры ключей менее 128 бит и размеры тегов менее 256 бит. В итоге, наиболее безопасными MAC можно считать hmac-sha2-512-etm и hmac-sha2-256-etm.
В /etc/ssh/sshd_config:
Code:
В /etc/ssh/ssh_config:
Code:
# Для GitHub в качестве исключения добавляем mac-sha2-512, так как он не поддерживает Encrypt-then-MAC.
Host github.com
MACs [email protected],[email protected],hmac-sha2-512
Host *
MACs [email protected],[email protected]Защита от утечки ключей.
Наиболее простым способом получения контроля за SSH-соединением является захват ключей на стороне клиента или сервера. Рекомендации сводятся к соблюдению типовых правил поддержания безопасности системы:
- оперативная установка обновлений,
- установка программ только из надёжных источников,
- установка только действительно необходимых программ и сервисов,
- использование программ для которых доступны исходные тексты,
- включение дополнительных механизмов защиты
(Grsecurity, сборка с флагом -fstack-protector).
Для защиты ключей следует выбрать надёжный пароль доступа к клиентским файлам ключей. При формировании ключа для увеличения числа итераций хэширования можно использовать опцию "ssh-keygen -o -a число", что усложнит подбор пароля. Также можно сохранить ключи только на внешнем носителе, подключая его только во время соединения по SSH.
Защита от анализа транзитного трафика.
SSH-сервер можно настроить в виде скрытого сервиса Tor, что скроет IP, а также добавит дополнительный слой шифрования и аутентификации.
Для приема соединений только через скрытый сервис Tor можно использовать следующие настройки:
В /etc/ssh/sshd_config (для приема соединений из LAN следует вместо привязки к 127.0.0.1 использовать для ограничения доступа межетевой экран):
Code:
ListenAddress 127.0.0.1:22В /etc/tor/torrc добавим:
Code:
HiddenServiceDir /var/lib/tor/hidden_service/ssh
HiddenServicePort 22 127.0.0.1:22Для настройки подключения клиента к скрытому сервису Tor в /etc/ssh/ssh_config можно добавить:
Code:
Host *.onion
ProxyCommand socat - SOCKS4A:localhost:%h:%p,socksport=9050• Source: stribika.github.io/2015/01/04/secure-secure-shell.html
• Дополнение: замечания к данным в статье рекомендациям : cypherpunks.ru/articles/securing_ssh.html
