MiTM атака на SSH

    В новой версии Intercepter-NG появилась возможность провести полноценную атаку на SSH-2 протокол.

    Атакующий получает данные авторизации пользователя и логирует весь сеанс связи, запуск команд и результат их выполнения.
    Для этого Intercepter перенаправляет трафик жертвы на свой собственный ssh сервер и в случае успешной авторизации
    проксирует соединение до оригинального сервера.

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

    К счастью атакующего, далеко не все (даже опытные) люди среагируют на это предупреждение должным образом.
    До сегодняшнего дня атака на SSH была скорее теоретической, по причине отсутствия ее практической реализации.
    И далеко не всегда атакуемый пользователь является администратором ssh сервера, для него смена ключей и предупреждения не имеют никакого значения.

    Встроенный в Intercepter ssh сервер поддерживает 2 механизма аутентификации: password и keyboard-interactive.
    Во время сеанса связи пользователь может запускать псевдографические приложения (например mc), все будет работать корректно. Так же Intercepter следит за сообщением WINDOW_CHANGE и при ресайзе окна терминала вся графика будет перерисована под новый размер.

    Атака рассчитана только на терминальный сеанс, SFTP не поддерживается. Если жертва все-таки запустит SFTP сессию, то будет перехвачена авторизация, но затем соединение будет разорвано и сессия отметится особым образом. При повторном соединении Intercepter пропустит эту сессию напрямую, позволив жертве нормально установить SFTP сеанс с оригинальным сервером.

    Стоит помнить, что при проксировании ssh соединения, атакующий неминуемо оставляет свой ip адрес в логах сервера.
    В режиме экспертных настроек можно установить соответствующую опцию, которая заставит ssh сервер разрывать соединение сразу после перехвата логина и пароля. После этого желательно остановить атаку и позволить жертве спокойно соединиться с нужным сервером.

    Для защиты от атаки можно использовать, пока что не поддерживаемый, режим аутентификации открытым ключом. И конечно внимательней относитесь к предупреждениям о смене отпечатков ключей.
    UPDATE:
    аутентификация открытым ключом не подвержена атаке и гарантирует безопасное подключение к серверу.


    Видео демонстрация атаки


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

    Похожие публикации

    Комментарии 79
      +2
      так вроде проксировать SSH траффик (man in the middle) и раньше было можно… или я что-то недопонимаю?
      мы ставили просто прокси в середине — клиент коннектился к нему, расшифровывали траффик и шифровали обратно, и отдавали настоящему серверу.
        +5
        или это просто реклама новой фичи в данной программе?
          +1
          что значит «просто прокси»? вы реализовали свой ссш сервер для этого?
            0
            извиняюсь, перепутал с SSL
          0
          ok, я с SSL перепутал, не проснулся еще…
            +1
            Можно было и раньше и уже достаточно давно. С чего автор решил присвоить первенство в практической реализации решительно непонятно. Любой более менее серьёзно вращающийся в области ИБ специалист знает, что уже много времени как подобный функционал доступен в решениях корпоративного класса, например — BalaBit Shell Control Box.
              +1
              куда нам, нищебродам-быдлокодерам, до аппаратных решений ценой 50-100 килоевро...:(
            +3
            Вроде ettercap умеет mitm ssh, и тоже с warning о фингерпринт.
              +3
              ettercap умеет делать ssh1 downgrade атаку.
                0
                Запомню, спасибо.
              +2
              То есть при авторизации ключами, можно спать спокойно?
                +9
                до тех пор, пока я не сделал поддержку public ключей.
                  +1
                  Но угнать сам ключ же не получится, соответственно авторизоваться отдельно — тоже.
                    +2
                    совершенно верно, приватный ключ остается не доступным. но доступ к сессии будет получен.
                      –1
                      А какие видимые пути решения проблемы перехвата сессии? выкидывать ssh на мороз? :)
                        +1
                        Смотреть внимательно на предупреждения Putty
                          +1
                          Это не решение проблемы в принципе, это тест на ССЗБ.
                            +6
                            Насколько я понимаю абсолютного решения проблемы не существует впринципе. Так или иначе MiTM будет возможен. Что бы он был невозможен нужно будет как-то удостоверится что хост правильный. Все равно кому то приходится доверять и нужен безопасный канал. Ниже уже написали про SSH.

                            Лучше и безопаснее решения не будет.
                              +1
                              Лучший выбор на мой взгляд — OpenVPN туннель (желательно с TLS) или похожее решение транспортного уровняю.
                                +1
                                Я не понимаю, почему будет работать перехват в режиме аутентификации открытым ключом. По идее, открытый ключ вашего сервера можно опубликовать хоть здесь, на то он и открытый. Как тогда подсунуть жертве поддельный ключ?
                                  +2
                                  Давайте поставим промежуточную точку в этом вопросе. Судя по всему, шифрование канала в ssh сессии
                                  не завязано на публичный ключ. Публичный ключ это всего лишь один из способов аутентификации, т.е. удостоверения личности пользователя.

                                  Работает этот механизм так:
                                  1. клиент соединяется с сервером и устанавливает шифрованый канал, на основе rsa\dsa ключей сервера.
                                  2. клиент сообщает серверу, что собирается аутентифицироваться с помощью открытого ключа.
                                  3. сервер (имея этот ключ) отсылает некий челендж клиенту.
                                  4. клиент должен расшифровать челендж своим приватным ключом и дать понять серверу, что он действительно тот за кого себя выдает.
                                  5. далее клиент может запросить терминал или другой тип сессии. но шифрование канала не зависит от способа аутентификации.

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

                                  Теоретические выкладки относительно функционирование ассиметричного шифрования не имеют к этой теме никакого отношения. Речь ведется строго
                                  о реализации ssh протокола. Пока что все видится именно так, как описано выше. Если кто-то обладает знаниями в этом вопросе — просьба отписаться.
                                    +1
                                    Спасибо за проделанную работу. Есть несколько замечаний.

                                    1. Насколько мне известно, шифрованный канал создается не на основе rsa/dsa ключа сервера, а при помощи алгоритма Диффи — Хеллмана. Отсюда следует интересный факт, что от длины ключа сервера не зависит вероятность успешной прослушки.

                                    2. Насколько я понял из статьи, нет возможности «увести» сессию (чтобы работать на сервере от имени жертвы). В этом случае более надежным и простым решением кажется атака на уровень шифрования (алгоритм Диффи — Хеллмана и подмена публичного ключа сервера), при которой открытый текст, включая изменения размеров терминала, SFTP, туннелирование и т. д., передавался бы как есть, а его копия записывалась бы сервером атакующего. Такой режим не даст атакующему вмешаться и что-то сделать на сервере от имени пользователя, зато будут работать SFTP и туннели и меньше будет риск глюков (при той же работе с терминалом), которые могут выдать прослушку.

                                    3. Пожалуйста, не делайте ошибку в слове «асимметричный», оно происходит от слова «symmetry», а не от слова «ass». К сожалению, ошибка очень популярна в материалах по криптографии, поэтому я обращаю на неё внимение.
                                      0
                                      Замечательно. Только подскажите в каком пункте (из тех, что я описал выше) допущена ошибка и почему нельзя увести сессию? И почему вы разделяете возможность выполнения команд и от возможности создания sftp сессий, либо перефразируйте весь второй пункт. Спасибо.
                                        0
                                        Ошибка в пункте 1:
                                        1. клиент соединяется с сервером и устанавливает шифрованый канал, на основе rsa\dsa ключей сервера.

                                        Прежде чем пояснять по моему второму пункту, я уточню принцип работы Intercepter-NG. Как я понял, он работает как ssh-сервер, принимает команды и вызывает их на настоящем сервере, подключившись к нему как ssh-клиент. Если я неправильно этот момент уяснил, то дальнейший мой ответ, скорее всего, неверен.

                                        Дополнительный вопрос: работают ли программы, интенсивно использующие возможности терминала: vim, screen (tmux)?

                                        Пользуясь Вашим подходом, сессию как раз можно было бы увести (то есть начать в живую вводить команды за пользователя), однако, как я понял из статьи, такой возможности нет. Поэтому, раз её всё равно нет, я предложил не «влезать» в открытый текст (будь то команды, SFTP, туннели и остальные «надстройки»), а передавать его как есть, сохраняя себе копию. Анализ этой копии (выполняемый постфактум) выявит всё, что передавалось, будь то команды, файлы или туннели. Причем можно сначала реализовать только извлечение команд, а возможность извлечения SFTP добавить потом, при этом SFTP можно будет извлекать и из старых дампов тоже, так как в них записывается всё, а не только то, что текущая версия умеет извлекать.
                                          0
                                          С ключами и диффи-хеллманом понятно, на обсуждаемый вопрос это не влияет. Принцип работы уяснили правильно. Вот только ничего сохранить или ввести не получится, потому что аутентификация не пройдет, и никакого терминального сеанса установлено не будет. Точно так же не будут работать и SFTP и прочие возможности SSH. Все что можно сделать, это выступить в качестве сервера самому (без привлечения оригинального сервера), но тут огромная куча ограничений. Если жертва зааплодит файл, то мы его сможем принять, но в последствии он его не обнаружит на своем сервере. Если жертва захочет скачать файл со своего сервера, то у нас его и вовсе не окажется.

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

                                          ps: vi\tmux и любой другой терминальный софт работают.
                                        0
                                        Вы имели ввиду ситуацию, когда атакующий говорит клиенту, что якобы аутентификация прошла успешно (хотя на самом деле доступа никуда мы не получили) и клиент начинает, к примеру, пересылать файлы по sftp, которые мы деть никуда не сможем, но сможем «перехватить» для себя, этакий минимальный профит. Я вас правильно понял?
                                        +1
                                        Как шаги могут быть повторены атакующим, если он не знает приватных ключей?

                                        В процессе создания сессии и обмена ключами создается идентификатор сессии, подделать который атакующий не в состоянии, не зная закрытого ключа сервера. Он может предоставить клиенту только другой, зависящий от своего закрытого ключа. То есть между клиентом и атакующим и атакующим и сервером идентификаторы сессии будут гарантированно разные. Затем при аутентификации клиент посылает подпись этого идентификатора своим закрытым ключом. Если атакующий просто передаст эту подпись без изменений, то сервер увидит, утрируя, что не совпадают идентификаторы сессии. Если подпишет своим закрытым ключом идентификатор сессии между собой и сервером, то сервер увидит, что не совпадают открытые ключи атакующего и клиента. В обоих случаях он реджекнет атакующего.

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

                                            byte SSH_MSG_USERAUTH_REQUEST
                                            string user name
                                            string service name
                                            string «publickey»
                                            boolean TRUE
                                            string public key algorithm name
                                            string public key to be used for authentication
                                            string signature

                                            The value of 'signature' is a signature by the corresponding private
                                            key over the following data, in the following order:

                                            string session identifier
                                            byte SSH_MSG_USERAUTH_REQUEST
                                            string user name
                                            string service name
                                            string «publickey»
                                            boolean TRUE
                                            string public key algorithm name
                                            string public key to be used for authentication

                                            теперь надо выяснить, может ли атакующий выдать произвольный id сессии, равный тому, что выдал
                                            оригинальный сервер.
                                              +1
                                              Описано тут по идее ools.ietf.org/html/rfc4253

                                              The hash H is computed as the HASH hash of the concatenation of the
                                              following:

                                              string V_C, the client's identification string (CR and LF
                                              excluded)
                                              string V_S, the server's identification string (CR and LF
                                              excluded)
                                              string I_C, the payload of the client's SSH_MSG_KEXINIT
                                              string I_S, the payload of the server's SSH_MSG_KEXINIT
                                              string K_S, the host key
                                              mpint e, exchange value sent by the client
                                              mpint f, exchange value sent by the server
                                              mpint K, the shared secret

                                              Если у атакующего данные эти все есть, то сможет дать тот же id клиенту.
                                                0
                                                Проблема в том, что session id генерируется клиентом самостоятельно, на основе данных обмена ключами.
                                                Интересно и то, что по сути, однажды созданный id больше ни за что не отвечает, он используется только при проверке подписи. Так что, если бы сервер мог выдать клиенту произвольный идентификатор все бы завершилось успешно.
                                                Спасибо, вопрос закрыт.
                                    –1
                                    openssh-шный клиент просто не даст подключиться, если с ключами не всё в порядке. Никаких вопросов, просто не даст и всё.
                                    +1
                                    мак шлюза хотя бы статиком прописать, но кроме арп пойзона есть и другие способы перехвата управления.
                                  +1
                                  по ключам внизу еще важное дополнение. вполне возможно они есть спасение.
                              0
                              К счастью это должно быть не очень опасно для пользующихся publickey авторизацией. Неуверен можно ли вмешатся в обмен со своими командами (теоритически)?
                                +1
                                про ключи ответ выше. в обмен вмешаться естественно можно.
                                +20
                                Это единственный подозрительный момент который возникает при проведении атаки.

                                Подозрительный? Да тот же putty черным по белому пишет, что это ппц и дальше нельзя:



                                Покажите мне хотя бы одного человека который не обратит внимания.
                                  +39
                                  таких людей гораздо больше чем вам кажется.
                                    +5
                                    Ну подобные диалоги выдают все программы, работающие с SSL. Эффектнее всего это сделано в хроме (а затем в других браузераз) — на красном фоне.

                                    Что еще можно придумать для такой ситуации? Выдавать тест-экзамен по информационной безопасности для активации кнопки «Да»?
                                      +1
                                      Выдавать тест-экзамен по информационной безопасности для активации кнопки «Да»?

                                      Патентуйте, пока не поздно :)!
                                    +1
                                    Первый вариант, что это штатная ситуация и лишь второй, что это атака.
                                      +3
                                      Как часто вам приходилось менять ключи сервера и зачем?
                                        +3
                                        Смотря что считать сервером. Если то, что идентифицируется по DNS, то банальная смена хостинга или переход на другой тарифный план обычные ситуации.

                                        Ну и речь явно о многопользовательских системах, где есть администратор, который по каким-то своим причинам, простым смертным неизвестным, может сменить ключ.
                                          0
                                          который по каким-то своим причинам
                                          Например, при переходе на ECDSA ключи.
                                            +1
                                            Вот опять. Когда вы меняете сами ключи, то вы ожидаете это сообщение. Когда я работалю на своем сервере, и тут мне внезапно говорят, что отпечаток изменился — это явно не штатная ситуация.
                                              0
                                              А вот если вы мне предоставили доступ на свой сервер, а потом поменяли ключи, то мне остается только монетку бросать — штатное это изменение или MitM — если вы меня не предупредили заранее о смене и/или не попросили лично уведомлять о сообщениях о смене и до ответа никаких мер не предпринимать.
                                            +3
                                            При обновлении Убунты на сервере до версии 12.04 у меня «полетели» настройки ssh-сервера. Пришлось его заново ставить. Как следствие — поменялись ключи. Увидел такое вот предупреждение и очень долго пытался отогнать навязчивую идею о Большом Брате, пока не вспомнил об этом обновлении ОС. А мои коллеги вообще на предупреждение никак не отреагировали и продолжили работать с сервером без задней мысли. Так что плюсую коммент выше:
                                            таких людей гораздо больше чем вам кажется.
                                              +2
                                              Почему обязательно сервера? SSH и на сетевом железе используется. Ситуация «один из сотен роутеров/свитчей был заменен на другой с тем же конфигом» вполне обыденна. Конфиг передается под копирку (то есть адрес будет как у старой железки), а пара ключей генерируется заново.

                                              Так что да, видя подобное сообщение, я предположу, что железка была заменена, на всякий случай перепроверю, и приму новый ключ. Не впервой.
                                                +2
                                                При обновлении openssh-сервера (по крайней мере на Debian) происходит перегенерация ключа.
                                                +1
                                                В первом варианте (и при первом соединении) тоже нельзя слепо принимать ключ. Надо получить настоящий отпечаток ключа по другому, безопасному каналу, и сравнить его с имеющимся. GitHub, например, публикует свой отпечаток ключа на HTTPS-странице: help.github.com/articles/generating-ssh-keys. Ну а если это свой сервер, то можно получить настоящий отпечаток через локальную консоль.
                                                  0
                                                  В теории — да, на практике очень мало кто этим занимается, а иной раз это практически невозможно.
                                              +11
                                              Консольный OpenSSH в явном виде запрещает подсоединение при измении ключа — чтобы подсоединиться, нужно пойти и удалить из known_keys прошлый ключ. Так как это действие происходит не за пару секунд и его нельзя выполнить, не подумав, а что, собственно, происходит.

                                              Проксификация соединения, авторизация которого производится при помощи PKI (сертификаты или пара RSA-ключей) — да на здоровье, с тем же успехом вы можете чужие SSL-сессии записывать. Т.е. записывать-то можете, но толку мало — кроме факта соединения (т.е. того, что и так не представляет секрета) никакой дополнительной информации извлечь не удастся.
                                                +3
                                                да, в юниксе с этим более безопасно.

                                                по поводу pki и пользы перехвата. скорее всего вы правы, я не вдавался в детали реализации этого алгоритма в ссш.
                                                но возможно есть шанс, что паблик ключ нужен только в момент авторизации, а дальше устанавливается сессия, в которой атакующий сможет исполнять команды. скорее всего это не так, но и полностью отбрасывать эту мысль не стану.
                                                  +1
                                                  The SSH-2 protocol has an internal architecture (defined in RFC 4251) with well-separated layers. These are:
                                                  The transport layer (RFC 4253). This layer handles initial key exchange as well as server authentication, and sets up encryption, compression and integrity verification. It exposes to the upper layer an interface for sending and receiving plaintext packets with sizes of up to 32,768 bytes each (more can be allowed by the implementation). The transport layer also arranges for key re-exchange, usually after 1 GB of data has been transferred or after 1 hour has passed, whichever is sooner.
                                                  The user authentication layer (RFC 4252). This layer handles client authentication and provides a number of authentication methods.

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

                                                      пример товарища mwizard про SSL не корректен, потому что там сертификаты отвечают за шифрование самого канала. в ссш с этим иначе.
                                                    +4
                                                    В принципе, можно заставить OpenSSH коннектиться к серверу, даже если не совпадает fingerpint, но тогда авторизация по паролю отключается и выдается следующее сообщение:

                                                    $ ssh -o StrictHostKeyChecking=no srv
                                                    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
                                                    @    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 RSA key sent by the remote host is
                                                    <...>.
                                                    Please contact your system administrator.
                                                    Add correct host key in /home/yuriy/.ssh/known_hosts to get rid of this message.
                                                    Offending RSA key in /home/yuriy/.ssh/known_hosts:28
                                                    Password authentication is disabled to avoid man-in-the-middle attacks.
                                                    Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.


                                                    При этом, нужно вручную отключить StrictHostKeyChecking, что тоже является дополнительным барьером к тому, чтобы подключиться к чужому серверу, не заметив этого.
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                      +2
                                                      называть можно как угодно. суть в том, что есть возможность перехватить данные. да собственно она была всегда, и проблема эта касается практически любого протокола, просто не было рабочей реализации.
                                                      0
                                                      Я всегда использую OpenVPN (PKCS12-сертификат/TLS) туннель с сервером.
                                                        0
                                                        Великолепно :)
                                                        Скоро вас похитят и заставят писать Russian DPI :)
                                                          0
                                                          При MITM атаках, почти всегда, почти, срабатывает предупреждение.
                                                          По крайней мере, я встречаю подобную защиту во всех анализируемых программах, НО человеческий фактор я бы тоже не отрицал, в данной ситуации.
                                                            –5
                                                            Спасибо, конечно, за полезную приблуду, но это в стиле вируса для UNIX, для работы которого надо во-1, его собрать, во-2, пропатчить ядро для совместимость, в-3 собственно запустить.

                                                            Основные программы, работающие с SSH при авторизации и несовпадении сохраненного отпечатка сервера закатывают истерику, на которую не обратит внимание только уже совсем упоротый пользователь. Имхо проще и незаметнее пользователю putty трояна подкинуть пароль\ключи увести. Про никсы вообще молчу.
                                                              0
                                                              3 раза кликнуть мышкой это тоже самое, что собрать сорц и пропатчить ядро?:)
                                                              0
                                                              А перехват ключей таит в себе какие-то дополнительные сложности, или это просто вопрос времени?
                                                              Я так понимаю трафик пойдет через ваши сервера, посему использовать эту функцию с целью пентестинга своих серверов небезопасно.
                                                                0
                                                                Дополнительные сложности, преодоление которых это просто вопрос времени.

                                                                ни через какие «мои» сервера ничего не пойдет. ссш сервер встроен в сам интерцептер.
                                                                –9
                                                                У меня авторизация по ключам, перехватывайте, пожалуйста, мне не жалко.
                                                                  +1
                                                                  Как настоящий параноик, храню распечатанные фингерпринты ключей всех серверов, с которыми работаю.
                                                                    –1
                                                                    Атака?
                                                                    Где здесь атака-то?
                                                                    Это просто демонстрация работы фингерпринтов в SSH. Не морочьте людям голову.
                                                                      0
                                                                      сами поняли, что сказали?
                                                                        –2
                                                                        Вы сами поняли, что сказали топиком?
                                                                      0
                                                                      Итак. Атака офигенно подходит для админа который… не вкуривает что такое открытие портов для конкретного ипа или динамическое открытие порта по требованию, спал на уроках по впн и по этой причине не реализовал это у себя в сети, настолько нищий что не может реализовать логирование на стороннем сервисе с правами только на чтение, и автоинформированием о разных событиях связанных с этим(в виде смс или письма на мыло). Обладает столь незаурядным умом что рут открыл для ссш и дал ему все права в сети, которые только возможно. И свято верит что его ксенон круче какойнибудь ботнет системы. А такие люди еще остались????? =)
                                                                        0
                                                                        Описанные вами «супермены» скорее исключение, чем правило :)
                                                                          0
                                                                          А кто говорит, что речь обязательно про атаку через интернет? ;)
                                                                          Само собой открытый наружу ssh, особенно если без ограничений по адресам — признак идиотизма и даже не рассматривается.
                                                                          –2
                                                                          Атака на удачу. Человек, понимающий суть подмены ключа — не купится. Не понимающий — в большинстве случаев не получит доступ к ssh.
                                                                            –2
                                                                            Почему этот -1 такой темный, жирный и угнетающий? Надо делать розовыми и маленькими цифры с минусами. В этом причина недовольства людьми минусами, а не в карме.
                                                                            0
                                                                            Стоит помнить, что при проксировании ssh соединения, атакующий неминуемо оставляет свой ip адрес в логах сервера.
                                                                            В режиме экспертных настроек можно установить соответствующую опцию, которая заставит ssh сервер разрывать соединение сразу после перехвата логина и пароля. После этого желательно остановить атаку и позволить жертве спокойно соединиться с нужным сервером.

                                                                            в таком случае человек получит целых 2 сообщения о неверном фингерпринте, ой какое страшное палево…
                                                                            0
                                                                            Ждём первых инцидентов с реальным применением.

                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                            Самое читаемое