В свете [[https://www.opennet.ru/opennews/art.shtml?num=41356 появления]] сведений об организации АНБ атак, направленных на получение контроля над SSH-соединениями, [[https://stribika.github.io/2015/01/04/secure-secure-shell.html подготовлено]] руководство с рекомендациями по усилению защищённости 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 для сервера следует указать:
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Аналогичные настройки для клиента, в /etc/ssh/ssh_config:
Host *
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
В /etc/ssh/moduli можно указать (или удалить строки с размером ключа, менее 2048):
ssh-keygen -G /tmp/moduli -b 4096
ssh-keygen -T /etc/ssh/moduli -f /tmp/moduli
++ Аутентификация.
В SSH поддерживается четыре алгоритма аутентификации по открытым ключам: DSA, ECDSA, Ed25519 и RSA. ECDSA завязан на технологиях NIST и должен быть отключен. К сожалению, если просто удалить ключ ECDSA, он будет повторно сгенерирован, поэтому можно воспользоваться обходным путём с создать заведомо нерабочую символическую ссылку, которая помешает сгенерировать и использовать ключ:
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, его тоже следует отключить тем же способом:
cd /etc/ssh
rm ssh_host_dsa_key*
ln -s ssh_host_dsa_key ssh_host_dsa_key
Далее, следует позаботиться о RSA, сгенерировав ключ большего размера:
cd /etc/ssh
rm ssh_host_rsa_key*
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null
Для создания клиентских ключей лучше использовать команды:
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 рекомендуется добавить:
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
В /etc/ssh/ssh_config:
Host *
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,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:
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
В /etc/ssh/ssh_config:
# Для GitHub в качестве исключения добавляем mac-sha2-512, так как он не поддерживает Encrypt-then-MAC.
Host github.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512
Host *
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
++ Защита от утечки ключей.
Наиболее простым способом получения контроля за SSH-соединением является захват ключей на стороне клиента или сервера. Рекомендации сводятся к соблюдению типовых правил поддержания безопасности системы: оперативная установка обновлений, установка программ только из надёжных источников, установка только действительно необходимых программ и сервисов, использование программ для которых доступны исходные тексты, включение дополнительных механизмов защиты (Grsecurity, сборка с флагом -fstack-protector).
Для защиты ключей следует выбрать надёжный пароль доступа к клиентским файлам ключей. При формировании ключа для увеличения числа итераций хэширования можно использовать опцию "ssh-keygen -o -a число", что усложнит подбор пароля. Также можно сохранить ключи только на внешнем носителе, подключая его только во время соединения по SSH.
++ Защита от анализа транзитного трафика.
SSH-сервер можно настроить в виде скрытого сервиса Tor, что скроет IP, а также добавит дополнительный слой шифрования и аутентификации.
Для приема соединений только через скрытый сервис Tor можно использовать следующие настройки:
В /etc/ssh/sshd_config (для приема соединений из LAN следует вместо привязки к 127.0.0.1 использовать для ограничения доступа межетевой экран):
ListenAddress 127.0.0.1:22
В /etc/tor/torrc добавим:
HiddenServiceDir /var/lib/tor/hidden_service/ssh
HiddenServicePort 22 127.0.0.1:22
Имя скрытого хоста для подключения можно найти в файле /var/lib/tor/hidden_service/ssh/hostname.
Для настройки подключения клиента к скрытому сервису Tor в /etc/ssh/ssh_config можно добавить:
Host *.onion
ProxyCommand socat - SOCKS4A:localhost:%h:%p,socksport=9050
URL: https://stribika.github.io/2015/01/04/secure-secure-shell.html
Обсуждается: https://www.opennet.ru/tips/info/2877.shtml
Вариант для распечатки
on 10-Янв-15, 12:58 
