Комментарии 52
По моему опыту 99+% фонового ssh флуда отсеиваются просто отключением всех устаревшых алгоритмов включая RSA в sshd_config, скрипт кидди лень обновлять свой софт. Ну и fail2ban помогает тоже
А на деле-то что? Всё то же, только воды побольше. И даже версию ssh, в которой работают приведённые в п.2.2 примеры, не удосужился указать.
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.10 (Santiago)
$ lsb_release -d
Description: Oracle Linux Server release 6.10
$ ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
$ ssh -Q kex
ssh: illegal option -- Q
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-I pkcs11] [-i identity_file]
[-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-W host:port] [-w local_tun[:remote_tun]]
[user@]hostname [command]
И чем автор лучше тех «неучей»?
$ ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
5 лет не обновлять пакет — наверное, это круто в плане безопасности!
Надо же сразу все сервера да на самую последнюю версию.
А на версию вашего OpenSSH указал лишь по причине отсутствия возможности проверить описанные команды на старых пакетах, ограничившись последней реализацией из репозитория Ubuntu 18.04 LTS.
Далее приносите извинения.
Вы просто [] (я бы сюда вставил словечко пожестче, но хабр) не знаете о том как поддерживаются пакеты в RHEL семействе и выставляете это на всеобщее обозрение.
Мало того что воды 99% и по сути от топика никакой информации, так ещё и комментарий про «5 лет не обновлять...». Что ещё больше удивляет, так это соотношение плюсов к минусам у комментариев на данный момент. Что, никого не удивило что в самой последней версии «шестой шапки» будет валяться пакет который не получал обновлений пять (ПЯТЬ КАРЛ) лет?! У того самого кроваво-энтерпрайзного оракла где платятся огромные деньги за поддержку? И никто гугло-яндексом воспользоваться не захотел?
P.S. Если из тона моего сообщения складывается ощущение, что у меня что называется «пригорело», вы правы. Комментарий onix74 очень в точку.
[root@localhost ~]# cat /etc/redhat-release
CentOS release 6.10 (Final)
[root@localhost ~]# rpm -q openssh
openssh-5.3p1-123.el6_9.x86_64
[root@localhost ~]# ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
Оно правда так сложно скачать 450 мегабайт минимальный образ той же CentOS и самому посмотреть? Сколько это времени займёт? 15 минут максимум?
Тот факт что тенденция «проще написать голословный коммент вместо того чтобы самому проверить, а заодно и чему-то научиться» уже и на Хабре прокатывает мне не нравится категорически.
Так что же, кому и о чём намекает?
Там выше по треду была строка
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
Эта строка намекает, что где-то существуют системы с несвежим ПО. А ваша ссылка намекает, что обновление таких систем возможно.
Вы может заметите всё-же что в моём сообщении присутствуют одновременно и самая свежая версия пакета, и та самая строка с 2013-м годом и поймёте наконец что наверное надо свои знания дополнить о том как оно в RHEL семействе устроено чтобы не бросаться голословными заявлениями?
наверное надо свои знания дополнить о том как оно в RHEL семействе устроено
Пожалуй, да.
А то я смотрю на www.openssl.org/source/old/1.0.1 — там 2013-Feb-11 15:34:45 openssl-1.0.1e.tar.gz
Последняя версия openssl-1.0.1 — 2016-Sep-22 10:35:26 openssl-1.0.1u.tar.gz
openssh динамически линкуется с libcrypto.so
OpenSSL 1.0.1e-fips 11 Feb 2013 — это оттуда.
Теперь я готов слушать, как оно в RHEL и почему на 3 года протушая библиотека для криптографии это норма ;)
Читаем changelog, смотрим даты, думаем. Те кому надо сделают выводы.
Оно правда так сложно скачать 450 мегабайт минимальный образ той же CentOS и самому посмотреть? Сколько это времени займёт? 15 минут максимум?
ну допустим. Скачал, посмотрел.
rpm -q openssh
openssh-7.4p1-16.el7.x86_64
ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
Разница в том, что это седьмой центос. А у вас шестой. Шестому уже более семи лет, но мейтененс апдейты должны быть до 20го года. К сожалению, у меня нет шестого центоса, что бы посмотреть, приехали ли в репы более новые (ну или хотя бы не настолько старые) версии пакетов, но если нет — то это повод поговорить с меинтейнерами.
Если вам это нужно, конечно же.
Мне кажется, что если все статьи на хабре будут с указаниями "с какой версии это начало работать" — они станут очень большими. Всё, что пишется — должно основываться на текущих stable релизах. Не вина автора, что кто-то не обновился.
ну допустим. Скачал, посмотрел.
onix74 в первом же своём сообщении указал что у него 6.10 версия.
А у вас шестой. Шестому уже более семи лет, но мейтененс апдейты должны быть до 20го года.
Почему, собственно, «у меня»? Он не у меня, а у г-на onix74. Я взял и скачал ту же версию, чтобы однозначно подтвердить, что пакет не старый, поскольку г-н freezl, сообщением выше, «как бы намекал». Вы, зачем-то, скачиваете седьмой центос. Может посмотрим какие есть ключи во freebsd тогда? Давайте сравнивать груши с грушами, а не с яблоками.
К сожалению, у меня нет шестого центоса, что бы посмотреть
Вы сами написали что скачивали седьмой, но при этом утверждаете что нет шестого, это как? Сложно было скачать шестой а не седьмой!? Меня эти два утверждения идущие в одной «логической цепочке» на ноль поделили. Не понимаю, и возвращаюсь обратно к «сравниваем груши с грушами».
что бы посмотреть, приехали ли в репы более новые (ну или хотя бы не настолько старые) версии пакетов
Вам ссылки на rpmfind и того что я написал не достаточно чтобы поверить какие там версии?
Иной раз у меня создаётся впечатление что отвечают так, как вы в данном случае, специально, чтобы перевести внимание от сути, на что-то другое (как ваше заявление про «обратитесь к мейнтейнеру»). А суть вот в чём:
o-pod, основываясь на строке из сообщения onix74
> OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
заявил нечто вроде «вы ССЗБ раз не обновляете пакет с 2013-го»
Мало того, что г-н o-pod не обратил внимание, что 2013й год числится у реализации OpenSSL, потому что там, в оной строке есть запятая, так ещё и не удосужился посмотреть какого-же года пакет в RHEL-based дистрибутиве.
А пакет, как оказалось, вполне себе новый, обновлённый и со всеми «бэкпортированными секурити патчами». Тобишь г-н onix74 никак, от слова совсем, не ССЗБ в плане безопасности.
Как я уже писал (и не только я, исходя из других сообщений), судя по всему г-н o-pod в кучу мешает версии приложений, версии библиотек и версии пакетов. Тем не менее, у критического сообщения про «ССЗБ» много плюсов, а у саркастического ответа «давайте всё всегда обновлять на самое новое» много минусов. И это с учётом того что я написал про версионность и патчи. Такая вот «вселенская несправедливость».
Ну и напоследок
то это повод поговорить с меинтейнерами
Напоминаю что именно RedHat — крупнейший в мире поставщик «энтерпрайзных линуксов». Тех самых, которые получают патчи больше 10-ти лет и гарантируют совместимость на протяжении всего этого периода. Может тогда сами с мейнтейнерами поговорите и объясните что эта модель (бизнеса в том числе) неправильная?
P.S. Я к «Шапкам» никакого отношения не имею и никогда в самой компании не работал. Работаю (именно работаю) с RHEL-based, Debian-based и SLES-based дистрами.
OpenSSL 1.0.1e-fips 11 Feb 2013
А как вы прокомментируете наличие уязвимостей в вышеобозначенной версии OpenSSL, которые были закрыты заплатками в версии 1.0.1k в начале 2015 года?
Г-н o-pod, это попросту означает что вы либо не читали что вам пишут, либо не вникали в суть написанного. Я даже не знаю что из этого хуже, с учётом того что вы ещё и статьи пишете, которые кого-то должны чему-то научить.
Мало того что воды 99% и по сути от топика никакой информации
ghostinushanka, было бы неплохо, если кроме троллинга вы бы немного про недочёты или ошибки В СТАТЬЕ обмолвились.
комментарий про «5 лет не обновлять...»
Как вы считаете, можно ли ставить в упрёк использование мной опций, которых не было в пакете 5-летней давности?
в пакете 5-летней давности
Вы вообще почитали что написано по приведённой мной ссылке? Пакету никаких 5 лет нет и не было. Или, что вероятнее, вы путаете версию пакета с версией приложения.
Ваше заявление о том что у onix74 «старый и необновлённый пакет» на 136% голословно и в корне неверно.
Как вы считаете, можно ли ставить в упрёк использование мной опций, которых не было в пакете 5-летней давности?
Упрёк был не в незнании опций. Упрёк был в том, что Вы в самом начале статьи обвинили некоторых неназванных админов в некомпетентности, но при этом сами даже не предоставили данные об окружении, в котором работаете. Обычно, такие вводные исключают разночтения.
5 лет не обновлять пакет — наверное, это круто в плане безопасности!
Не спешите так резко ругать, некоторый коммерческий софт очень сильно может быть привязан к конкретным версиям ядра Linux и версиям пакетов. Сам с этим сталкивался неоднократно, тем более тут Oracle Linux, в каких-то случаях конкретный релиз БД Oracle, необходимый для софта, на другой версии может и не завестись.
> вынужден совершать массу бесполезной работы
Это не самое страшное :-) Исчерпанее очереди полуоткрытых соединений гораздо неприятнее — она там по дефолту очень маленькая.
Первоначальный сеансовый ключ может и не дожить до закрытия соединения — это называется Rekey.
> имеют алгоритмы в начале каждого списка
Эти списки у себя рекомендуется почистить так как в них по дефолту входят всякие там NIST и MD5.
Плюс в таблице не учтена защита фаерволом, а она самая как ни крути эффективная.
Если бы сервер первым делом отправлял ключ, а клиент просто проверял его по known_hosts, это бы никак не защищало от MITM.
PS поменяйте заголовок на «Алгоритм аутентификации в SSH» — большинство претензий в комментариях исчезнет.
При первой же возможности будет исправлено.
Ключей в authorized_keys для одного имени может быть несколько.
Тогда они проверяются просто по очереди.
Тогда уж называть статью «Алгоритм установления SSH соединения и сопутствующие вычислительные затраты», или что-то в этом духе.
Другое дело, что статья, видимо, писалась как оправдание практике вешать SSH на нестандартный порт — для личной VPS сам так делаю, как раз по указанным причинам (флуд от ботов, ограничить доступ по диапазону IP не нахожу целесообразным в моем конкретном случае).
статья, видимо, писалась как оправдание практике вешать SSH на нестандартный порт
Vindicar, именно так вначале и планировалось, но потом получилось, что контента про SSH гораздо больше, чем про практические аспекты.
называть статью «Алгоритм установления SSH соединения и сопутствующие вычислительные затраты», или что-то в этом духе.
Про заголовок замечание справедливое, в ближайшем будущем подправлю!
если для авторизации используются RSA-ключиСейчас уже чаще не RSA, а ECDSA или Ed25519
— стандартный порт
— авторизация по паролю
— защита на основе ограничения неудачных попыток авторизации (fail2ban)
Если открытый ключ найден, то сервер генерирует случайное число и шифрует его открытым ключом клиента, после чего результат отправляется клиенту.
Клиент расшифровывает сообщение своим приватным ключом и отправляет результат серверу.
Результат отправляется в незашифрованном виде?
При дальнейшей работе сервер продолжает шифровать отправляемые данные открытым ключом клиента? А клиент как шифрует отправляемые данные?
На этом уровне обеспечивается: мультиплицирование каналов (возможность работы множества каналов к одному серверу за счет объединения их в один канал), туннелирование и т.п.
Что, простите? Какое такое мультиплицирование? Это про мультики для взрослых? Правильно — мультиплексирование. Т.е. именно уплотнение канала связи.
*** — произвести взлом, если для авторизации используются RSA-ключи, очень сложно, однако неограниченное количество попыток авторизации делает это возможным.
Нет, не делает.
Ограничение количества попыток — такая себе мера. Представьте себе, каким количеством IP-адресов обладает одна физическая машина, имеющая префикс IPv6 /64 или даже /48. Аналогично, ботнеты координировано долбят машины с разных адресов. Все эти ухищрения с портами и лимитами разве что понижают нагрузку, генерируемую настойчивым атакующим. С безопасностью оно напрямую не связано.
В статье очень много пробелов. В частности, для того, чтобы блок данных с параметрами KEX-алгоритма не был целиком подменён посредником, он тоже имеет криптографическую связь с ключами сервера. Не рассказано для чего HMAC-алгоритмы нужны.
Клиент расшифровывает сообщение своим приватным ключом и отправляет результат серверу.
Не результат, как раз, а HMAC от результата.
Если клиент производит соединение с данным сервером впервые (о чем говорит отсутствие записи в файле /home/username/.ssh/known_hosts у клиента), то пользователю будет задан вопрос о доверии ключу сервера.
Ну это тоже не догма. Модель TOFU (trust on first use) — действительно слабое место всех систем, которые ещё ни разу не обменивались ключами. Однако этого можно (и нужно) избегать. Есть целый ряд механизмов:
- Ручное или полуручное наполнение known_hosts со сверкой отпечатка.
- Использование записей SSHFP в DNS. Если ответ DNS подтверждён DNSSEC, то тогда SSH даже не задаёт вопроса о доверии ключу.
- Использование сертификатов (не ключей) для аутентификации подлинности ключей серверов. Для аутентификации клиентов тоже работает, то есть в конечном счёте можно аутентифицироваться по ключу, которого на сервере нет, но на котором стоит подпись единственного УЦ, знакомого серверу.
Про SSH можно писать много и интересно — это очень многозадачный и многогранный инструмент. Даже основы можно подать лучше (пример).
авторизация по паролю
Вероятность взлома
высокая
Аутентификация по паролю тоже бывает разная: есть keyboard-interactive, есть password. При этом ни одну из них нельзя сразу охарактеризовать как небезопасную: достаточно длинный нетривиальный пароль может иметь больше энтропии, чем ключ RSA-2048.
В случае с keyboard-interactive вообще может быть задействована двухфакторная аутентификация, например реализованная вот так с помощью google authenticator (TOTP).
Соответственно, ваша таблица с мнениями по поводу безопасности для разных случаев весьма спорная.
P.S. Для любителей всё файрволить и больших сторонников портнокинга ещё предложу простой скрипт, использующий подписанные UDP-пакеты для открытия портов. Прелесть в том, что DROP для UDP извне неотличим от принятия пакета открытым сокетом, поэтому внешне такой сервер себя никак не выдаёт.
Вот бы ещё договориться, в каких попугаях измерять безопасность… ;) Чтобы как-то объективно сравнить разные способы аутентификации..
Ну это тоже не догма. Модель TOFU (trust on first use) — действительно слабое место всех систем, которые ещё ни разу не обменивались ключами. Однако этого можно (и нужно) избегать. Есть целый ряд механизмов:
Ручное или полуручное наполнение known_hosts со сверкой отпечатка.
Имеете ввиду отправлять открытый ключ или его отпечаток через другой канал связи (почта, месенджер и т.п.)?
Позвольте внести каплю критики для Вашей статьи.
Вы пишите так, что можно подумать, что SSH это OpenSSH дистрибутив и CLI утилиты к нему.
В то время, как на самом деле, SSH это стандартизированный IETF протокол, описанный в RFC 4251 (и дополнительных), а OpenSSH это просто одна из имплементаций протокола.
Т.е. у вас все смешалось в кучу: протокол, одна из рабочих реализаций протокола (OpenSSH), аргументы командной строки для CLI утилиты из дистрибутива OpenSSH (хотя вы же прекрасно понимаете, что в других версиях ПО от других «вендоров» в CLI утилитах могут быть (и будут) реализованы совсем другие ключи командной строки) и пр.
Пишите ясней и не смешивайте кегли, вафли и драже в одной тарелке.
Алгоритм установления соединения в протоколе SSH