В свете [[http://www.opennet.me/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-512Host *
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=9050URL: https://stribika.github.io/2015/01/04/secure-secure-shell.html
Обсуждается: http://www.opennet.me/tips/info/2877.shtml
1) Хотелось бы видеть какие-то более разумные основания для выбора тех или иных алгоритмов чем "мы считаем что это небезопасно".
2) Если уж мы про билдовку программ - ключи компиляции можно и посильнее затянуть, один только stack protector - это полумеры, мягко говоря.
Разумные основания есть в полной версии статьи: https://stribika.github.io/2015/01/04/secure-secure-shell.html
Комментарии к статье: http://www.cypherpunks.ru/articles/securing_ssh.html
Степень их разумности подвергается ряду сомнений.Например, автор не в курсе что например на VDS/VM/прочих облаках AES - большие грабли в плане спирания ключей теми кто пристроился на тот же CPU.
> Степень их разумности подвергается ряду сомнений.
> Например, автор не в курсе что например на VDS/VM/прочих облаках AES -
> большие грабли в плане спирания ключей теми кто пристроился на тот
> же CPU.Это лишь уточнение общих положений. Кстати, во второй предоставленной мной ссылке (критика) написано про сомнения в безопасности AES.
Настраивать клиент обязательно? Клиент с сервером же договариваются при подключении?
Про тор не понял. Ну сделал это, а как я в тор найду свой сервер? Ни адреса ни ключа специального чтоб его идентифицировать... (ни разу не пользовался, если честно)
Тоже не пользовался, но думаю это поможет:
Имя скрытого хоста для подключения можно найти в файле /var/lib/tor/hidden_service/ssh/hostname.
> Ну сделал это, а как я в тор найду свой сервер?Посмотришь адрес hidden сервиса в файле - и все, можно ходить по нему. Он уникально адресует сервер (ssh бонусом перепроверит что это именно тот сервер по fingerprint своего ключа). Выглядит как <набор букв и цифр>.onion. Например, 3g2upl4pq6kufc4m.onion - duckduckgo в виде hidden service в tor (доступен только при использовании Tor разумеется).
> Настраивать клиент обязательно? Клиент с сервером же договариваются при подключении?конечно, обязательно. Предполагается, что вы будете своим клиентом лазить на сервера не под вашим контролем, неоптимизированные. Вообще безопасность клиента и безопасность сервера - это не одно и то же, одно другое не заменяет, а дополняет
Это паранойя, господа.
https://ru.wikipedia.org/wiki/%D0%9F%D0%...
Не, не так. "А с пустою головою легче прыгать по земле".
> Это паранойя, господа.
> https://ru.wikipedia.org/wiki/%D0%9F%D0%...ну да, Сноуден параноик, Брюс Шнайер - параноик. А можно поинтересоваться вашей компетенцией? Эксперт по информационной безопасности?
>> Это паранойя, господа.
>> https://ru.wikipedia.org/wiki/%D0%9F%D0%...
> ну да, Сноуден параноик, Брюс Шнайер - параноик. А можно поинтересоваться вашей
> компетенцией? Эксперт по информационной безопасности?Не вижу связи между ssh, Сноуденом и Шнайером. Вы сами то, собственно говоря, кто?
>>> Это паранойя, господа.
>>> https://ru.wikipedia.org/wiki/%D0%9F%D0%...
>> ну да, Сноуден параноик, Брюс Шнайер - параноик. А можно поинтересоваться вашей
>> компетенцией? Эксперт по информационной безопасности?
> Не вижу связи между ssh, Сноуденом и Шнайером. Вы сами то, собственно
> говоря, кто?Связь между Сноуденом, Шнайером и ssh прямая, потому что эта вся затея с оптимизацией ssh появилась как следствие разоблачений Сноудена, в которых он сообщил, что АНБ имеет возможность в некоторых случаях расшифровывать SSH-трафик.
А на вопрос кто я евреям отвечать не буду - сначала вы на мой ответьте.
> А на вопрос кто я евреям отвечать не будуПоведайте не евреям.
> сначала вы на мой ответьте.
Я не эксперт по формационной безопасности, как не эксперт спрашиваю - какая связь между
Сноуденом, Шнайером и ssh?
Вы, видимо, весьма компетентны в этом вопросе?
Прошу.
> Это паранойя, господа.
> https://ru.wikipedia.org/wiki/п÷п╟я─п╟п╫п╬п╧я▐Вы перед тем как такие заключения делать, изучите тему. Желательно включив перед этим мозг.
>> Это паранойя, господа.
>> https://ru.wikipedia.org/wiki/п÷п╟я─п╟п╫п╬п╧я▐
> Вы перед тем как такие заключения делать, изучите тему. Желательно включив перед
> этим мозг.Еще один. Может я не теми буквами пишу? Поясните мне, связь то какая?
> Может я не теми буквами пишу?ты не тем местом делаешь то, что в иной ситуациии, с большими натяжками, можно было бы назвать "думаешь"
>> Может я не теми буквами пишу?
> ты не тем местом делаешь то, что в иной ситуациии, с большими
> натяжками, можно было бы назвать "думаешь"Вы это, видимо, про себя? К то му же Вы хам.
Послушайте Вы, "ехсьперт", вы на вопрос ответ дайте, прежде чем хамить.
А почему у меня в файле /etc/ssh/moduli только последние несколько байт модуля(одного размера) являются случайными? И вообще откуда берется этот файл? Если даже несколько строк с параметрами указаными в посте (4096) генерируются несколько часов(на i3-2100(только на одном ядре)).
а потом люди попытаются подключится через распространенного клиента Putty и что же они увидят?
Putty пользователи, должны страдать!
http://ttssh2.sourceforge.jp/
> а потом люди попытаются подключится через распространенного клиента Putty и что же
> они увидят?я даже проверил - я вчера оптимизировал свой сервер с учётом части рекомендаций. Только что зашел путти - всё сработало, всё отлично.
>> а потом люди попытаются подключится через распространенного клиента Putty и что же
>> они увидят?
> я даже проверил - я вчера оптимизировал свой сервер с учётом части
> рекомендаций. Только что зашел путти - всё сработало, всё отлично.Низдипи hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com пуття не умеет
Ой, тут косяк в тексте про файлик moduli
ЕС алгоритмы я бы не выбрасывал.
Большинство этих параметров ssh не переваривает и не запускается. ВИдать скомпилирован без этих алгоритмов. Будьте осторожны.
https://cipherli.st/