Усиление SSH-соединения
Многие пользуются SSH-соединением для защиты передаваемых данных и паролей, но думается, немногие уделяют внимание его тонкой настройке.
Извиняюсь за возможно простой вопрос, который для меня все же неочевиден, к тому же гугль не слишком помог.
Прошу и предлагаю собрать здесь все рецепты по усиления криптостойкости SSH-соединения, доступные "из коробки".
Конфигурация традиционна: есть локальный SSH-клиент и удаленный SSH-сервер на базе OpenSSH.
Соединение между ними устанавливается, как говорится, с пол-оборота.
А как сделать его более криптостойким, выжимая из их конфигов по-максимуму и одновременно исключая нестойкие варианты?
Например, в http://books.google.com.ua/boo.....yBits%201024&f=false описан параметр
ServerKeyBits 1024
но тут же есть приписка, что это только для 1-й версии. А если не 1-й, тогда как?
И каковы пределы это битности?
И т.д. – в конфигах есть множество параметров и в то же время по ним нет рекомендаций.
В-общем, предлагаю объединить здесь все методы, повышающие криптостойкость SSH-соединения.
Попробуйте один раз получить привелегии, скажем:
guest:$ sudo aptitude update && sudo aptitude -y upgrade
И затем выполнить такой Makefile:
guest:$ make -f Makefile
комментариев: 9796 документов: 488 редакций: 5664
Вот и продолжайте обсуждение sudo в той теме. Или заведите отдельную: «
УкреплениеИзбавление от sudo», «sudo не нужно» и т.д.Пошаговое, для чайников – какой параметр подкрутить и что с ним конкретно сделать.
комментариев: 9796 документов: 488 редакций: 5664
Имеется ввиду бесключевого, вход только по паролю? Так не рекомендуется, но опции из /comment79001 действовать будут и в этом случае.
комментариев: 9796 документов: 488 редакций: 5664
По поводу random-устройств:
Т.е., в /dev/{u}random можно напрямую записывать данные безо всяких вспомогательных демонов, они там сами похэшируются и переинициализируют пул энтропии. Надо только быть уверенным в случайности и безопасности записываемых данных.
Т.о., после старта виртуалки в неё можно вкачать энтропии по SSH, а затем переконнектится по SSH заново, надеясь, что из предыдущего сеанса извлечь вкачиваемые в /dev/{u}random данные будет сложнее. Но вообще — это шаманство. Нужен Entropy Broker.
А вот ещё чьё-то простенькое скриптоподелие, похожее на то, что предлагалось в этой теме изначально — entropyservice:
Хотя, хотелось бы иметь разработки на формально обоснованных протоколах для этой задачи.
Вспомогательный демон rngd нужен не для обновления пула, а увеличения запаса случайности в /dev/random. Сравните вывод двух команд
и
до и после запуска (/dev/urandom просто для примера)
Надёжный источник случайности по-видимому можно получить двумя способами:
1. Обновление пула записью в /dev/urandom. В этом случае /dev/urandom может в интервале между обновлениями использоваться вместо /dev/random.
2. Пополнение /dev/random с помощью демонов типа rngd
Плюс первого способа в простоте и большей стабильности, т.к. для записи в устройство похоже не нужны права root, а программы не будут зависать из-за нехватки случайности. Минус в меньшей безопасности. Отсутствует контроль качества поступившей энтропии.
Плюс второго способа в большей безопасности. Демон автоматически контролирует качество поступившей энтропии. Минус в необходимости прав root для запуска демона и вероятном зависании программ от нехватки случайности, если связь с источником энтропии по какой-то причине прервётся.
В процессе начальной настройки обычно накапливается достаточно в /dev/random, чтобы хватило для старта последующего более безопасного соединения. По первоначальному (менее безопасному) SSH-соединению энтропию передавать не обязательно. Главное настроить канал передачи случайности до первой регенерации ключей в последующем безопасном SSH-соединении, для его поддержания.
Судя по всему это продвинутый и масштабируемый аналог скрипта entropyservice. Кстати, автор этого скрипта просто оформил рецепт из http://lwn.net/Articles/567731/ По-моему, для индивидуального использования собственноручного скрипта вполне достаточно, а Entropy Broker больше годится для промышленного применения.
У меня лишь общие соображения. Есть потребитель случайности, есть источник. Между ними канал связи. Источник можно реализовать в виде сервера энтропии, прослушивающего определённый порт. Клиент на основе некоторых критериев периодически обращается к серверу. Критериями могут быть уменьшение запаса энтропии ниже порога или истечение интервала времени. В клиенте можно устанавливать разные параметры – количество запрашивамой энтропии, проверку её качества и т.п. В простейшем случае эта конструкция создаётся скриптами использующими стандартные утилиты netcat, rngd и т.п. Можно скрипт и на Perl написать. Для безопасной связи порты клиента и сервера покрыть SSL с помощью stunnel. Кроме этого, SSL использовать для аутентификации по сертификатам как клиента, так и сервера, чтобы предотвратить разные атаки. Например подмена сервера для отправки клиенту злонамереных данных, или умышленное истощение источника неаутентифицированными клиентами. Хотя при наличии VPN можно и без stunnel обойтись, создавая порты на виртуальных интерфейсах.
комментариев: 9796 документов: 488 редакций: 5664
Это понятно, что скриптами и даже эвристически обоснованными программами можно по шифрпанковски всё нагородить. Я подразумеваю, что нужен спецпротокол доказуемо безопасной трансляции энтропии с расчётом Resilience Leakage Entropy, Bounded Retrieval Model, Leakage Oracle и пр. За авторством кого-нибудь, наподобие Евгения Додиса.
комментариев: 9796 документов: 488 редакций: 5664
Я тоже. Поэтому entropyservice пока сойдёт, но хотелось бы дождаться, когда появится что-то на основе исследованных моделей, будет признано и внедрено в системы, чтобы работало из коробки. Чтобы простой пользователь даже не помнил, что такая проблема когда-то была и требовала каких-то костылей.
Брутфорсить пароль — это ещё ладно, но неужели вы всерьёз рассматриваете ещё и брутфорс ключа?
В любом случае, я стараюсь исходить из разумных предположений. Например, считаю, что если SSH безопасен, то при стойких паролях всё будет и так ОК, а если небезопасен, то попытки перехитрить атакующего в играх в прятки ничем не обоснованы — это лишь моральное самоуспокоение. Помимо аутентификации по ключам есть файерволл, которым можно заблокировать соединение с недоверенных хостов. Но вот поднимать ssh на нестандартном порту или играть в port knocking — это уже прятки. Здесь я мысленно исхожу из сервера для себя (или узкого круга параноиков). В сценарии с большим числом непонятных пользователей какие-то из этих пряток могут быть оправданы (вплоть до эвристических проверок стойкости пароля перед его установкой и требований его периодически менять).
Неслучайные данные не должны уменьшать энтропию. Они её просто не увеличат вроде как, но не более того.
Про rngd: вы предлагаете напрямую пополнять пул /dev/random, чтобы увеличить его скорость? Т.е. проигнорировать все страховки и проверки на уровне ОС? Это очень рискованно. Я бы не стал так делать. Если некая модификация системных умолчаний повышает на 1% защиту от каких-то почти гипотетических атак ценой того, что с вероятностью в 30% я внесу фатальную элементарно экспулатируемую уязвимость, после которой всё станет ещё хуже, чем было ранее, то зачем мне такие риски? Они ничем не оправданы.
комментариев: 9796 документов: 488 редакций: 5664
Теоретически сложный вопрос. В том же rngd выставляется лимит в процентах на подкачку данных из определённого источника, чтобы он полностью не доминировал в создании пула энтропии.
Разумно.
Речь шла о подборе логина. При наличии уязвимостей в криптографии, нужно ещё знать логин для прохождения аутентификации (даже если известен SSH-ключ). Если это root, то проблемы с подбором нет.
В стандартной ситуации соединение с VPS осуществляется через NAT провайдера с динамическим IP-адресом. Поэтому обычная фильтрация по IP-адресам средствами iptables не подходит. К тому же она рискованна при смене своего местоположения. А вот нестандартный порт или port knocking могут существенно оградить от разных сканеров и случайных гостей. Хотя от целенаправленной атаки это конечно не поможет.
Как уже писалось выше, rngd проверяет источник на случайность. Если проверка не пройдена или источник иссяк, то демон аварийно завершается.
Любое крипто строится на том, что есть публичная часть алгоритма/протокола и секретная. Секретную часть стараются сделать как можно меньше. На практике весь секрет только в пароле или только в ключе. Если протокол при этом не работает, надо его не латать уловками и засекречиванием публичных частей, а выкидывать на помойку. Кстати, это одна из причин того, почему алгоритмы шифрования должны быть открытыми.
У ISP не бесконечный диапазон адресов. В таких случаях разумно открыть подсеть/подсети, если исходящий адрес динамически меняется.
Можно сделать какой-то сервер доверенным аутентификацирующим. Пусть он принимает соединения от всех, и на целевом SSH-сервере соединения от него разрешены. Тогда, если мне надо открыть доступ новому IP, я соединяюсь с SSH-сервером через тот иной промежуточный сервер, добавляю в таблицу адресов свой внешний IP и после этого могу туда ходить напрямую.
Его можно прогнать через статтесты, которые увидят непреднамеренную закладку или грубые ошибки, но принципиально вопрос тем не решается: нельзя никак узнать, случайным ли образом получена конкретная выборка или нет. Я вам могу нагенерить несколько терабайтов данных методом ГПСЧ, которые пройдут все тесты на случайность, а потом покажу короткий 128-битный ключ, который детерминированным образом получает все эти терабайты.
Раз в вашем случае доверия к каналу нет, сервер не может доверять полученным от клиента случайным данным. Точнее, можно наворачивать протокол «из говна и палок», опираясь на эвристические соображения, но не думаю, что имеет смысл до этого опускаться. Риски неоправданны, смысл неясен.
Unknown здесь привёл хорошую выжимку:
В общем, то же самое можно сказать не только про Tor, а вообще про любую респектабельную разработку в области ИБ. Прям манифест получился.