Comments 43
Из альтернатив тут только использование сертификатов SSH (подчеркну: не ключей — сертификатов), распространяемых отдельно. Такое решение лучше масштабируется и не требует внедрения DNSSEC. Вот руководство, правда не очень свежее: www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu
Во-вторых, это никак не поможет защитить само TCP-соединение от перехвата. Атакующий может даже и не знать про какой-то там fwknop — он просто зарулит соединение SSH себе и всё. А SPA-пакет fwknop спокойно дойдёт до сервера, и сервер может его даже получит и что-то там откроет.
YourChief прав, порт кнокинг не защтит вас от MiTM-атаки. Представьте, что атакующий сидит на стороне провайдера и использует DPI для обнаружения SSH хендшейка и автоматически подменяет ключ на свой. Ему не важно что вы делали до этого, ведь TCP-подключение с SSH все равно будет обнаружено и перехвачено.
А почему не использовать обычную TXT запись?
Вопрос почему это сделали отдельным типом записи — хороший вопрос, могли по идее так же пихнуть ключ в TXT-запись, защищённую DNSSEC.
Из альтернатив тут только использование сертификатов SSH (подчеркну: не ключей — сертификатов), распространяемых отдельно. Такое решение лучше масштабируется и не требует внедрения DNSSEC. Вот руководство, правда не очень свежее: www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu
VerifyHostKeyDNS yes
Этого недостаточно. У SSH-клиента должен быть резолвер, валидирующий DNSSEC. В общем случае это не так.
Да, об этом сказано в конце.
Довольно громоздко получается в результате, я бы сказал.
Фишка публичного ключа в том, что ему не нужен доверительный канал, он предназначен для передачи по открытым каналам, потому и зовётся публичным
Публичный ключ называется публичным потому, что его можно распространять на публичных площадках: опубликовать у себя на HTTPS-сайте, разместить на корпоративном (доверенном) сервере, тогда можно проверить, что это ваш ключ, а не MiTM-атакующего. Если ваш публичный ключ станет известен всем, ничего плохого в этом нет, даже наоборот.
Применительно к SSH, если вы пошлёте ваш публичный SSH-ключ владельцу SSH-сервера по e-mail, а между вами MiTM, ваш e-mail может быть перехвачен, публичный ключ подменен. После этого атакующий либо заходит на SSH-сервер со своим ключём и делает там то, что хочет, либо перехватывает вашу SSH-сессию, проксирует её и наблюдает за всеми вашими действиями.
и где-то между вами и получателем будет полноценный MiTM, то все ваши коммуникации будут проходить через MiTM с возможностью расшифровки
Не очень понимаю как. Ключ передаётся по одному каналу, а сообщения потом идут по другому же.
Запустите traceroute с вашего рабочего места до SSH-сервера, а затем запустите traceroute с рабочего места (или, скорее, почтового сервера вашего предприятия) до следующего(-их) hop на пути e-mail и от администратора SSH-сервера до последнего или пред-последнего почтового сервера, через который прошла почта. Каждый совпавший hop в traceroute даст вам некое представление о количестве мест где и ваш e-mail трафик и SSH-сессии могут перехватить. На самом деле, таких мест значительно больше, если учитывать L2-оборудование и даже физические L1-каналы. Как минимум, это оборудование провайдеров вашей компании и компании, где размещён SSH-сервер, но, в большинстве случаев, там ещё масса неявных мест, вроде магистральных провайдеров между городами, IX-точек и т.д. Также, достаточно вероятным вектором (развития) атаки будет взломанное оборудование вашей компании или контрагента.
Более того, как я написал выше, одним из типов атаки будет подмена вашего публичного ключа в e-mail и заход со своим ключом на SSH-сервер, для этого вообще больше ничего перехватывать не надо, только e-mail.
sudo ssh-keygen …Зачем sudo, публичные части ключей и так кто угодно читать может ;)
Эм, всё не так.
По поводу веба: естественно никто не станет сверять ключи для посещения очередного развлекательного сайта, так что там придумали систему, которая хоть как-то работает в расчёте на незаинтересованного в безопасности и в среднем малограмотного пользователя.
Если у вас SSH относится к той же категории, то ок, хорошая идея, но не надо её выставлять как топовую безопасность. Особенно вот это:
узнать отпечаток ключа сервера через DNS, и если он совпадает с предложенным сервером, то подключаться без предупреждения.
Для пользователей, которым плевать на безопасность, и которые не хотят на неё вообще что-то тратить ("нажимаем Yes не задумываясь", "ведь никто не станет проверять ключи, а будет просто всегда соглашаться"), это всё действительно несколько её увеличит. А те, кому не плевать, будут сверять ключи с полученными по действительно надёжному каналу, который не подвержден перехвату третьими сторонами (DNSSEC, как и общепринятый SSL для сайтов, таковым очевидно не является).
надёжному каналу, который не подвержден перехвату третьими сторонами (DNSSEC, как и общепринятый SSL для сайтов, таковым очевидно не является).
Не понял:
- Я использую DoH или DoT
- Я выполняю в теминале:
a)
dig . DNSKEY | grep -Ev '^($|;)' > root.keysb)
dig +sigchase +trusted-key=./root.keys babai.ru SSHFP | cat -nи получаю в ответ: "Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS"
c)
ssh -v root@babai.ruи получаю в ответ: "found 6 secure fingerprints in DNS"
ГДЕ, ЧТО и КАК здесь подвержено перехвату ?
Всё и везде.
dig. DNSKEY
DoH-сервер может подменить этот ключ (да, DoH-сервер это третья сторона, а не абстрактная идеальная сущность). Но допустим этого не произошло, и ключ вы получили настоящий.
dig +sigchase +trusted-key=./root.keys babai.ru SSHFP | cat -n
Если я правильно понял, эта команда проверяет, что SSHFP-запись домена babai.ru подтверждена ключом, полученным на прошлом этапе. Очевидно, тут имеется третья сторона (владелец того самого ключа рут-зоны — ICANN наверно? а может ещё цепочка CA, не особо в курсе их организационной структуры), которая может своим настоящим ключом злонамеренно или по ошибке подписать подложную SSHFP-запись для mitm-атаки.
ssh -v root@babai.ru
found 6 secure fingerprints in DNS
Даже если прошлая команда не подверглась уже описанным атакам и подтвердила настоящую легитимную SSHFP-запись, полученную с помощью сделанного ей DNS-запроса про домен babai.ru, это не гарантия того, что аналогичный DNS-запрос, сделанный ssh-клиентом (хотя стоит отметить, что в зависимости от настроек dns-кеша и прочих обстоятельств этого второго запроса может и не случиться, но это частный случай), вернёт ту же SSHFP-запись. То есть может выйти так, что dig получит и проверит легитимную запись, а второму запросу (от ssh) отдадут уже подложную.
Итог: вы, если хотите, можете доверять используемому вами DoH-серверу и вообще официальной DNS-инфраструктуре, но надо понимать, это это именно осознанное доверие третьей стороне, снижающее безопасность p2p-соединения. Даже если этой третьей стороной является какая-то крупная известная организация, которой вроде бы незачем вас атаковать, данный риск всё равно должен держаться в голове.
Все эти шифрования и pki защищают только транспорт, а от злонамеренного агента на той стороне они никак не защитят. Как минимум одна "та сторона" неизбежна — это сам сервер, к которому подключается ssh, а вот от всего остального можно избавиться.
- Вы всё написали правильно, но если я просто параноик то вы гуру-параноик (в хорошем смысле этого слова) :)
- В "обычной" жизни когда я с одного своего сервера поключаюсь к другому своему же серверу по ssh (разумеется вход по ключу а не паролю) я считаю надписи "found 6 secure fingerprints in DNS" достаточно для моего спокойствия что я попал куда надо. Я всё таки Google/Cloudflare (DoT, DoH) и рутовым держателям ключа Dnssec (ICAAN) таки доверяю.
- Всё равно спасибо учитель за такой сверхпараноидальный взгляд — мне есть ещё куда расти :)
ещё цепочка CA
Именно, только не CA, а иерархическая зональность, т.е. "." (Root), com., example.com.
Далее вот как выглядит корневая зона, зона точка. www.internic.net/domain/root.zone
Там есть два ключа, zone signing key и key signing key (ZSK и KSK). В зоне есть DS записи с ID ключами, которому зона доверяет (com., например). Вот так.
Прочтите пожалуйста ещё раз статью, вы абсолютно не поняли ни её суть, ни суть моего комментария.
Вы написали про то что мы можем перейти на ключи (что нормальные люди уже сделали, в отличии от вас наверное), но это не отменяет MitM на пути к серверу при первоначальной установке соединения (в современных системах часто используются облачное создание виртуалок буквально двумя кликами).
При первом подключении по ssh к серверу, сервер передаёт отпечаток своего ключа, и потом последующие подключения выполняют сравнение этого отпечатка подтверждает факт легитимности соединения. В том случае если между вами и свежеустановленным сервером будет злоумышленник, то он может вам передать свой отпечаток и вы не будете знать об этой подмене. Независимо от того используете вы пароль или ключ, соединение будет скомпрометировано. Вам стоит освежить знание о механизмах работы этого популярного типа соединения, для архитектора важно знать больше о безопасности.
(что нормальные люди уже сделали, в отличии от вас наверное)Вот этот выпад я откомментирую чуть ниже.
Независимо от того используете вы пароль или ключ, соединение будет скомпрометировано.А вот это неверно, о чём и была заметка, ссылку на которую я дал. Злоумышленнику не удастся стать посредником и вклиниться в сессию. Ему никак не получить таким образом доступ к серверу, потому что подпись для авторизации охватывает идентификатор сессии, а он в свою очередь выведен из общего секрета, согласованного через DH.
По поводу хамства выше я хочу сказать, что вы не поняли о чём речь, но априори считаете собеседника идиотом. В данной ситуации всё вышло ровно наоборот.
Более безопасное подключение к SSH с помощью DNSSEC