id: Гость   вход   регистрация
текущее время 14:11 29/03/2024
Автор темы: Гость, тема открыта 26/04/2014 18:04 Печать
Категории: криптография, инфобезопасность, протоколы, операционные системы
http://www.pgpru.com/Форум/UnixLike/УсилениеSSH-соединения
создать
просмотр
ссылки

Усиление SSH-соединения


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


Конфигурация традиционна: есть локальный SSH-клиент и удаленный SSH-сервер на базе OpenSSH.
Соединение между ними устанавливается, как говорится, с пол-оборота.
А как сделать его более криптостойким, выжимая из их конфигов по-максимуму и одновременно исключая нестойкие варианты?


Например, в http://books.google.com.ua/boo.....yBits%201024&f=false описан параметр
ServerKeyBits 1024
но тут же есть приписка, что это только для 1-й версии. А если не 1-й, тогда как?
И каковы пределы это битности?
И т.д. – в конфигах есть множество параметров и в то же время по ним нет рекомендаций.


В-общем, предлагаю объединить здесь все методы, повышающие криптостойкость SSH-соединения.


 
На страницу: 1, 2, 3 След.
Комментарии
— unknown (26/04/2014 19:11, исправлен 26/04/2014 19:34)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

ServerKeyBits 1024 — это размер эфемерного DH-ключа для протокола первой версии. Эту версию вообще можно отключить. С другой стороны, ключи размером больше 1024 бит для протокола второй версии могут тормозить, поэтому есть смысл перейти для DH на эллиптику и задать максимальный размер эллиптической кривой, например KexAlgorithms ecdh-sha2-nistp521. Более новые версии ssh поддерживают кривые не от НИСТа, а от DJB (Бернштейна), по мере продвижения поддержки имеет смысл перейти на них.


Можно задать фиксированный список хэшей и шифров. Посмотрите в man, в каких опция они встречаются и задайте максимальные параметры: SHA-2-512 И AES-CTR-256.


Вообще, почти все эти параметры (точнее часть, которая запускается для эфемерного сеанса) есть смысл задавать на стороне клиента, а не сервера: вы будете согласовывать с сервером соединение по выбраному вами стойкому протоколу, а если уж кто-то крадёт ваш ключ и пароль для его расшифровки, вам будет всё равно — по стойкому протоколу он осуществляет сеансы взлома вашего сервера или нет. К тому же на стороне клиента безопаснее экспериментировать с параметрами конфигов без риска остаться без связи с сервером.


Помню ещё, что если SSH-сервер даже если остановить по ssh-соединению, то соединение продолжится, до тех пор, пока его не закроет клиент или не истечёт тайм-аут сессии. Возможно попробовать пользоваться этим для проверки параметров сервера: открыть несколько сессий, на одной поменять параметры конфига и рестартануть SSH, со свежего терминала попробовать сконнектиться с новыми параметрами и если не получается, то на ранее открытой сессии вернуть параметры обратно и смотреть в логах, что не работает.


Настройте вход только по ключам без возможности войти напрямую по паролю. Это уже как раз потребует смены конфигов и на сервере. При этом сами ключи используются только для аутентификации при входе и подтверждения параметров DH, они не используются непосредственно для шифрования, поэтому их максимальный размер не критичен, что позволяет не завязываться в самих ключах на эллиптику. Можно задать ключ с максимально разумным размеров (RSA-4096).


Если удалённый сервер в какой-нибудь виртуалке, то там хронически плохо с энтропией. Это потенциально вредит в случае генерации ключей. Не знаю, есть ли команда или способ для генерации ключа сервера на стороне именно аутентифицированого клиента с последующим забросом сгенерированного ключа на этот сервер. Если есть, то надо воспользоваться таким способом. С эфемерными сеансовыми ключами сложно что-либо порекомендовать. Все протоколы DH, хоть эллиптические, хоть классические, чувствительны к качеству энтропии.


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

— Гость (26/04/2014 19:41)   <#>
1.Отключить парольный вход


После этого аутентификация по сертификату

2. Увеличить битность ключа сервера. Использовать RSA, но не DSA. Просмотреть текущий и создать новый большего размера


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

3. Запретить вход root


Безопасней входить под обычным пользователем и потом повышать права из консоли.

4. Исключить прослушивание IPv6 интерфейсов (если они не используются)


5. Если на машине несколько IP-адресов, то лучше явно указать нужные, чтобы сервер не прослушивал все


Проверить можно командой netstat -pntl

6. Запретить пустые пароли и указать версию 2 протокола. Эти опции по умолчанию, но вреда не будет если их указать явно



Остальные опции по умолчанию вполне разумны.
— Гость (26/04/2014 19:46)   <#>
UPD: Аутентификация конечно по ключу, т.к. в SSH не сертификатов
— unknown (26/04/2014 20:15)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
2 — Гость (26/04/2014 19:41):

Битность RSA ключа влияет на аутентификацию, а не шифрование. Грубо говоря, это просто подпись параметров. Если в будущем изобретут способ ломать ключи RSA ≥ 4096 бит, то они не смогут вернуться в прошлое и воспользоваться этим ключом. А если говорить про ранее записанный трафик, то его расшифровать не поможет взломанный в (не)далёком будущем ключ RSA.

Защита от расшифровки заключается в повышении битности DH-ключа, что разумно осуществимо только путём перехода на сеансовую эллиптику с максимальным размеров кривой. Ну и выбором симметричных алгоритмов с максимальным размером ключа. Это всё прописывается на стороне клиента.

Посторонние пусть каким-угодно способом пытаются влезть в связь с защищаемым SSH-сервером. Они просто не пройдут аутентификацию по RSA. А если они могут это делать, то без разницы, насколько стойкие сеансовые параметры шифрования ECDH/AES/HMAC выбраны — противник знает аутентифицирующие параметры, может делать MitM или сам входить на сервер.
— Гость (26/04/2014 20:47)   <#>

По моему мнению, делать RSA-ключи больше, чем 8192, неосмысленно. Если вы боитесь лобовой факторизации, то 3072 хватит на ваш век. Если вы боитесь прогресса в криптоанализе, надеясь выгадать время за счёт более длинных ключей, можно увеличить их до 4096 или даже 8192. Если же n-картное увеличение ключа, далеко выводящее их за пределы лобового брутфорса, вдруг перестанет спасать от новых методов критоанализа, то и n+1 кратное увеличение уже мало чем поможет, тут разумнее было бы алгоритмы менять или завязываться в асимметрике на несколько несвязанных алгоритмов (к примеру, брать протоколы, которые считаются квантовостойкими, и добавлять их к обычным так, чтобы если один из них окажется сломан, вся связка не пострадала; однако, это на отдалённое будущее, пока ничего такого толком не разработано и не внедрено).


Рекомендации ходить под пользователем ведут корнями в старинные инструкции 90-ых годов, где основной вектор угроз — подбор пароля по сети.

Раз вы всё равно будете потом повышать привелегии до рута, принципиального разделения между root'ом и обычным пользователем не будет. В частности, компрометация этого пользователя даст злоумышленнику доступ и к root-аккаунту.
— Гость (26/04/2014 21:51)   <#>
Рекомендации ходить под пользователем ведут корнями в старинные инструкции 90-ых годов, где основной вектор угроз — подбор пароля по сети.
Раз вы всё равно будете потом повышать привелегии до рута, принципиального разделения между root'ом и обычным пользователем не будет. В частности, компрометация этого пользователя даст злоумышленнику доступ и к root-аккаунту.

А ведь действительно! Сколько раз удивлялся и задавался вопросом, почему в Debian/Bubuntu изначально всё настроено под sudo?
Ведь если зашел под юзером, а потом переходишь на рута, то значит, разницы между таким входом и прямым входом рутом с точки зрения перехвата и декодирования пароля не существует, так ведь?
И если да, то почему никто до сих пор не отменил этот архаизм или хотя бы объявил его таковым?
— Гость (26/04/2014 22:58)   <#>

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

Изначально sudo предназначалось для того, чтобы дать возможность некоторым служебным процессам быть запущенными от имени нужного пользователя, у которого очень мало прав. Для root'а, однако, это проблемы не составляет — никакой su/sudo ему не нужен. В частности, у меня они вообще не установлены, и система работает на ура. Другой паразитный механизм повышения прав (а по сути — дырка в пользу удобства и в ущерб безопасности) — это суидность. Снятие суидности с особо борзых исполнимых файлов — полезное занятие, а иногда их можно вообще удалить без вреда для работы системы (это касается таких утилит как ping и ping6). Обсуждение этого с фанами sudo уже имело место, можете почитать.


Если без SSH, то, боюсь, повышение привелегий до рута ещё хуже, чем непосредственный логин под рутом, но могут быть нюансы. Если система не полностью скомпрометирована, то украть пароль рута можно, анализируя акустические сигналы от нажатия клавиш (прямого доступа к login-менеджеру нет). Если скомпрометирован конкретный юзер, из-под которого иногда бывает доступ к root-аккаунту, то такие сложности ни к чему — достаточно запустить нужный зловред с его правами.


А почему chroot & noexec не объявили таковыми? Вопрос, надеюсь, риторический.
— Гость (26/04/2014 23:08)   <#>

Жесть! Век живи -век учись...
— Гость (26/04/2014 23:54)   <#>


Что самое интересное, фанаты отказа от sudo подчистую слили в том обсуждении.
— Гость (27/04/2014 00:23)   <#>
В смысле? Не понял формулировку
— Гость (27/04/2014 00:44)   <#>
Битность RSA ключа влияет на аутентификацию, а не шифрование.

Запас по длине ключа вреда не приносит. На время установления соединения это практически не влияет. Если взломают аутентификацию, то в шифровании нет смысла. Это первый рубеж обороны.

Защита от расшифровки заключается в повышении битности DH-ключа, что разумно осуществимо только путём перехода на сеансовую эллиптику с максимальным размеров кривой.

Разве выбор алгоритма при аутентификации (RSA или DSA) влияет на битность сеансового ключа? Насколько я знаю, для усиления DH-ключа используется файл /etc/ssh/moduli, создаваемый с помощью каких-то проверок утилитой ssh-keygen.

Ну и выбором симметричных алгоритмов с максимальным размером ключа. Это всё прописывается на стороне клиента.

Согласен, не хватает опции типа


в /etc/ssh_config

Насколько понимаю, настройку параметров защиты можно разделить на четыре части
1. Аутентификация RSA – чем больше ключ, тем лучше
2. Параметры DH – создание файла /etc/ssh/moduli
3. Выбор алгоритмов симметричного шифрования
4. Настройка источника случайности

Если удалённый сервер в какой-нибудь виртуалке, то там хронически плохо с энтропией. Это потенциально вредит в случае генерации ключей. Не знаю, есть ли команда или способ для генерации ключа сервера на стороне именно аутентифицированого клиента с последующим забросом сгенерированного ключа на этот сервер. Если есть, то надо воспользоваться таким способом.

Когда определена переменная окружения SSH_USE_STRONG_RNG=N, при извлечении случайности из /dev/urandom подмешивается N байт из /dev/random (минимум 14). Понятно, что если увеличивать N, то по израсходовании /dev/random, соединение может зависнуть. Для устранения этой проблемы можно запустить на сервере демон типа rngd, но в качестве источника указать не /dev/hwrandom, а обычный файл. На стороне клиента собирать энтропию и кроном регулярно добавлять в файл.

Раз вы всё равно будете потом повышать привелегии до рута, принципиального разделения между root'ом и обычным пользователем не будет.

При сканировании SSH-серверов самый распространённый логин это root. Когда логин неизвестен, его нужно подобрать. Для нестандартного имени это аналогично подбору пароля, при том что количество попыток в единицу времени ограничивается настройками сервера.

Другая причина – невозможность установки трояна в автоматическом режиме. Нужно ждать когда будет вход с правами root.
— unknown (27/04/2014 01:20)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
К тому, что было сказано в /comment78982 на стороне клиента в /etc/ssh/ssh_config можно прописать такие опции:


Если сервер не пускает, смотреть по ssh -vvv user@hostame, что ему не нравится и менять опции на стороне клиента в сторону совместимости с сервером. К сожалению, это всё равно показывает только подробности по DH, а насчёт ECDH показывает только, что оно установилось, но не показывает по какой эллиптической кривой. По мере выхода новых опций ssh, можно смотреть, что поддерживает сервер и добавлять на клиенте улучшенные варианты алгоритмов. На самом сервере лучше принудительно эти алгоритмы не задавать, чтобы не остаться без связи, если какой-то клиент их не может поддерживать.


Аутентификация не влияет. Влияет тип эллиптической кривой в KexAlgorithms.


Во-первых это было для обычного DH. Во-вторых, считалось, что модули от НИСТ и др. м.б. плохими, а раз есть несложная (но тормозная) процедура генерации своего модуля, то почему бы не воспользоваться и самому не сгенерить модули. В третьих DH требует совместной генерации ключа в реальном времени (возможны некоторые предвычисления), поэтому сверхбольшие ключи там не выбрать, приходиться всё-таки переходить на эллиптику


CBC-режимы были уязвимы к BEAST атакам. Это пофиксили, но вроде такие режимы в ssh всё-равно не рекомендуются.


Костыльно очень. Вдруг что-то сбойнёт и в файл что-то не запишется? Или запишется что-то не то? Дважды запишется по-ошибке одно и тоже?


Хорошую энтропию посылаем через канал с плохой энтропией? И храним, пусть и временно, но в простом файле?

При сканировании SSH-серверов самый распространённый логин это root. Когда логин неизвестен, его нужно подобрать. Для нестандартного имени это аналогично подбору пароля, при том что количество попыток в единицу времени ограничивается настройками сервера.

Другая причина – невозможность установки трояна в автоматическом режиме. Нужно ждать когда будет вход с правами root.

При установлении аутентификации только по ключам это всё получается не имеет значения.
— Гость (27/04/2014 01:30)   <#>

Там можно добавлять список из шифров, в порядке убывания значимости. Тогда не нужно смотреть как отваливается контакт из-за неумения сервера в шифры, главное не добавлять уязвимые комбинации.
Или можно ещё putty для клиента, с гуем для сортировки шифров, использовать.
— Гость (27/04/2014 15:23)   <#>
>Разве выбор алгоритма при аутентификации (RSA или DSA) влияет на битность сеансового ключа?
Аутентификация не влияет. Влияет тип эллиптической кривой в KexAlgorithms.

Выбор RSA с длинным ключом влияет на этот тип?

Костыльно очень. Вдруг что-то сбойнёт и в файл что-то не запишется? Или запишется что-то не то? Дважды запишется по-ошибке одно и тоже?

rngd проверяет файл на случайность перед пополнением /dev/random. И какой есть более простой способ передачи энтропии на сервер? Как вы сами пишете, в виртуалках её мало.

Не знаю, есть ли команда или способ для генерации ключа сервера на стороне именно аутентифицированого клиента с последующим забросом сгенерированного ключа на этот сервер. Если есть, то надо воспользоваться таким способом.

Если имеется в виду ключ аутентификации, а не часть DH, можно создать ключевую пару на клиенте и скопировать на сервер. Но это, как вы уже заметили, делается через канал с плохой энтропией, т.к. самое начало настройки. Лучше установить на сервере переменную SSH_USE_STRONG_RNG и создать ключи там. Тогда секретная часть ключа в сеть не попадает и достигается некоторый контроль над качеством материала для него.

>На стороне клиента собирать энтропию и кроном регулярно добавлять в файл.
Хорошую энтропию посылаем через канал с плохой энтропией? И храним, пусть и временно, но в простом файле?

После установки переменной SSH_USE_STRONG_RNG, создания RSA-ключей, запуска rngd и перезапуска SSH-сервера получается надёжный канал. Для его поддержания (регенерации сеансового ключа) с клиента на сервер регулярно идут порции энтропии в определённый файл. Во-первых, этот файл доступен только демону, во-вторых в /dev/random поступает его содержимое смешанное с энтропией из других более слабых источников (хотя это надо проверить).

При установлении аутентификации только по ключам это всё получается не имеет значения.

По-моему в любом случае нужно знать имя пользователя. Открытый ключ аутентификации ищется в его домашнем каталоге (файл /.ssh/authorized_keys). Если пользователь не задан, сервер ищет открытый ключ в домашнем каталоге root. Ключа там нет, а если бы и был, то логин всё равно запрещён.
— unknown (27/04/2014 16:04)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Нет.


Допустим, виртуальный сервак тупо грохнулся и его восстановили из снэпшота. Тогда и рэндомный файл восстановится. И в демон энтропии дважды попадёт одно и тоже значение. И может даже одинаковая гамма сгенерироваться дважды. Для какого-нибудь потокового шифра или вектора инициализации. Это всё конечно маловероятно, да и простой /dev/urandom, который сохраняет свои состояния между ребутами в такой же простой файл также этому подвержен.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3