Pull to refresh

Comments 34

В 99% случаев администраторы отвечают на подобный вопрос «yes».
Неверное обобщение, пока не подтверждено фактами, а следовательно статью можно удалять.
В 99% случаев они нажимают Yes когда только что установили ОС (или запустили контейнер в облаке). В остальном, когда вдруг ни с того ни с сего появился запрос об изменившемся fingerprint — это как раз таки сигнал тревоги, и вот тут процент значительно меньше. По крайней мере, я надеюсь что это так.
«В 99% случаев это не системные администраторы».

С начала статьи ждал, как будет отрабатываться предупреждение о том, что ключ поменялся.


В 99% случаев администраторы отвечают на подобный вопрос «yes»

>_< надеюсь, что хоть немного меньше эта цифра на самом деле)

Около года назад встречал на Хабре утверждение, что очень много администраторов отправляют приватные ключи вместе с публичными, когда кто-то спрашивает ключ. Просто не думают о том, что они делают. А тут надо только согласиться.

Автор, вероятно, судит по себе.
Ни один нормальный *nix-сисадмин просто так подобное сообщение не оставит.

Я лишь призываю всех, и "нормальных" и "ненормальных" *nix-сисадминов использовать ключи, а не пароли, что повышает безопасность сетевой инфраструктуры. А, надеяться на то, что в Вашей организации все сисадмины "нормальные" — изначально неправильная политика информационной безопасности.

Автор, вероятно, судит по себе.
Ни один нормальный *nix-сисадмин просто так подобное сообщение не оставит.


Уже -дцатый человек в комментариях пишет, что согласен с автором.

ОК, пусть будет по вашему — ни один «нормальный».
Только вот, видимо, нормальных и есть 1%.

Какая разница каким именно словом обозначить человека? Нормальный или нет?
Суть то не меняется — львинная доля не соблюдает правил безопасности.

Нет, ну я прекрасно понимаю, при каких условиях ключ может поменяться. И когда он меняется после очевидных моих действий — в чём проблема. Если «сам» поменялся — то признак задуматься
Да, к сожалению описанная атака неосуществима без человеческого фактора.
Но в случае когда администратор первый раз заходит на новый сервер, или когда у администратора новый ПК, эта цифра вполне приближается к 99%.
В статье описывается некое подобие сниффера, который находит все действующие SSH-сессии в сети. Т.е. теоретически это дело можно автоматизировать, собирать данные и проксировать только новые компьютеры, появившиеся в сети 10 минут назад.

Есть еще неочевидные подводные камни человеческого фактора — можно совместить атаку на важный сервер (DoS) вместе с MitM-атакой на ssh (ну или просто захватить чужой ip-адрес)
Системный администратор заметит:
1) важный сервер внезапно вообще перестал работать
2) у важного сервера сменился ключ и существующий пароль больше не подходит
ИМХО, не очень опытный администратор с долей вероятности >50%:
1) Забудет о том что это в сети мог появиться левый ип-адрес
2) Попадет под прессинг начальства
3) Начнет вводить все возможные логины и пароли, в т.ч. от других серверов, до победного конца.
4) Разбор полетов и выявление подмены IP-адреса будет проводиться сильно позже, если вообще будет.
5) Коллекция логинов и паролей уже собрана, профит.
Да, к сожалению описанная атака неосуществима без человеческого фактора.

Может все-таки к счастью?
The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established.
ED25519 key fingerprint is SHA256:kn+iT7WwgO6Wlh0xN4KQXB8P/JaHLcRx04gYTvNdjCM.
Are you sure you want to continue connecting (yes/no)?

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

Да, но PuTTY предложит принять новый ключ. Да, и когда на Вас орет начальник и просит срочно почистить файловую систему на сервере, так как бизнес "встал", а тут какие-то "глюки начинаются" и не получается подключиться к серверу, многие отдадутся эмоциям и могут выполнить ssh-keygen -f "/home/user/.ssh/known_hosts" -R ...

вот где-то приблизительно поэтому у меня и существует стереотип о том, что Linux-администратор, пользующийся Windows не может являться профессионалом в этой области

Спорное утверждение. Работать никсовым админом и жить в никсах — несколько разные, но пересекающиеся множества.
стереотип

Я не просто так написал это слово.
Т.е. я отдаю себе отчёт о том, что это не всегда истинно. Но этот штамп помогает моментально составлять мнение (которое, к слову, всё же часто оказывается истинным) о профессиональных качествах собеседника. Естественно, я не держусь за него и при более детальном общении сужу о человеке по его реальным навыкам.


Но статистически этот мой штамп очень часто реально помогает морально подготовиться к тому, чего стоит ожидать от собеседника и меньше нервничать во время дискуссий.

Прошу прощения, слово выпало во время чтения.
«В 99% случаев администраторы отвечают на подобный вопрос «yes».»

Не могу поверить, что я попадаю в уникальные 1% администраторов, которые видя подобное не выясняют по какой причине поменялся ключ хоста? Это действительно поведение большинства?
Фух, судя по каментам, я не уникален, все в порядке.
The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established.

Данное сообщение выводится только если вы никогда не подключались к данному хосту, т.е. в файле known_hosts нет о нем записи.
Если же у известного хоста публичный ключ сменился, ssh-клиент откажется подключаться:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
3e:ee:ee:ee:ee:ee:ee:ee:ee:ee:e6:72:df:c4:ee:ee.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:1
remove with: ssh-keygen -f "/home/user/.ssh/known_hosts" -R eee.eee
ECDSA host key for eee.eee has changed and you have requested strict checking.
Host key verification failed.


Т.е. нужно предпринять ручные действия (или удалить строку в файле known_hosts, или командой ssh-keygen -f) для подключения.

Правда это касается ssh-клиента на линуксе, не знаю как себя поведет putty в данной ситуации.

Тем не менее абсолютно согласен с выводом статьи о запрете авторизации по паролям.

Все верно. PuTTY, насколько я помню, просто предложит принять новый ключ.

Не совсем просто. Оно выведет варнинг, в котором большими буквами напишет, что уже сохраненный ключ не совпадает с ключом хоста, и это потенциально security breach.

А потом уже предложит Yes, No, Cancel
Причем в конце еще раз напомнит, что «Hitting Cancel is the ONLY guaranteed safe choise».

к слову,
1) это справедливо практически для всех ОС. И все варианты "бсди", и макось, и прочие. С некоторых пор даже в этой вашей windows можно после пары пассов руками :)
2) putty есть и для линукса и для других ОС. Но более нужным от этого не становится, да :)

В 99% случаев администраторы отвечают на подобный вопрос «yes».

Это где 99% админов жмут yes не задумываясь когда клиент говорит, что не может установить аутентификацию хоста? В такой ситуации даже я, будучи совсем начинающим админом, сначала задумался, потом понял, в чем дело, а потом ещё и загуглил, чтобы уж наверняка.

Добавил UPD в текст, дабы прекратить спор на эту тему

А почему часть команд характерны для Debian (и про это ничего не сказано), а часть вообще противоречат всем рекомендациям по установке ПО?
apt есть только в Debian и «дочках», а всякие ./install.sh будет использовать только тот, кто пользуется системой первый и последний раз, то есть, тот, кто ей пользоваться не должен.

Вы, видимо, не понимаете, о чем речь в статье. Я устанавливаю фейковый SSH-сервер в свой собственный дистрибутив для пентеста и прекрасно понимаю, что будет делать install.sh и зачем именно я это делаю. В тексте несколько раз сказано, что я использую Kali Linux, а это Debian-based дистрибутив.

Нет, в тексте, конечно, неоднократно упоминается Kali Linux, но нигде явно не говорится, что в статье все команды приведены именно для этого дистрибутива.

Обратите внимание на "Для arp-spoofing-а используется ettercap, а для сниффинга сетевых пакетов tshark.
Оба инструмента по умолчанию входят в дистрибутив Kali Linux." и на строку приглашения в code-тегах (root@kalix64:~)

Да, многократно говорится, что те или иные инструменты входят в состав Kali Linux, однако это нисколько не противоречит моим словам.
Плюс к тому: вы-то понимаете, что делает install.sh, а вот ваш читатель — не факт.
И тут я бы разделил его на три группы: одна не понимает, но делает, другая не понимает, но не делает, а третья разбирается самостоятельно и или делает, или нет.
К сожалению для нашего мира, первых очень много, к сожалению для вас, вторых тоже много, но не очень, к сожалению для всех, последних мало.
Каждый день выскакивает эта фигня, всегда жму Yes.

на самом деле нет
Only those users with full accounts are able to leave comments. Log in, please.