Телнет и ботнет

Теоретический минимум

Телнет появился в конце 1960-х, а первый стандарт с tcp/ip и виртуальным терминалом относится к 1983 г. Естественно, что в момент создания никого не заботил тот факт, что данные передаются в простом текстовом формате. Сетевой протокол tcp/ip в то время еще только созревал в ARPANET.

Telnet was designed to work between any host (i.e., any operating system) and any terminal. Its specification in RFC 854 [Postel and Reynolds 1983a] defines the lowest common denominator terminal, called the network virtual terminal (NVT). The NVT is an imaginary device from which both ends of the connection, the client and server, map their real terminal to and from. That is, the client operating system must map whatever type of terminal the user is on to the NVT. The server must then map the NVT into whatever terminal type the server supports.

Как и многие популярные протоколы сети интернет, он тоже прост до архаичности и непотопляем в силу своей простоты. И точно так же часто используется не по назначению.

Вот весь нехитрый список команд:

Телнет поддерживает полу-дуплексный, по-символьный и по-строчный режимы ввода, по умолчанию программа использует последний. Из ман страницы.

Once a connection has been opened, telnet will attempt to enable the TELNET LINEMODE option. If this fails, telnet will revert to one of two input modes: either ‘‘character at a time’’ or ‘‘old line by line’’ depending on what the remote system supports.

Используется внутриполосная сигнализация — команды и данные передаются в одном потоке.

Телнет honeypot

В прошлом году специалисты крупного чешского DNS провайдера NIC.CZ, выкатили приманку — honeypot и стали наблюдать за трафиком.

Число уникальных IP.

География стран, кликабельно. Обратите внимание на совпадение с результатом Shodan, ниже по тексту.

Платформа основных устройств, кликабельно.

На первом месте RomPager/4.07 HTTP server — дырявый встроенный веб сервер, часто используемый в домашних роутерах. Таких, по словам аналитиков из Allegro Software Development, может быть 75 миллионов. На втором месте популярный тулкит gSOAP/2.7, а бронзовая медаль досталась H264DVR 1.0 — RTSP (Real Time Streaming Protocol) серверу видеорегистратора.

Собственно, CCTV камеры обозначены неблагозвучным Dahua Rtsp Server и также имеют проблемы с безопасностью. С мая 2016 г. эти устройства резко повысили свою активность, временами было зарегистрировано 8 тыс. уникальных IP адресов за сутки.

Несмотря на локальный характер эксперимента, выводы о надвигающихся крупномасштабных IoT угрозах будто напрашивались. Обработав данные с более чем 6 миллионов уникальных IP адресов, чешские аналитики четко выявили тенденцию: встроенные системы наиболее уязвимы, особенно CCTV видеокамеры, которые зачастую вырождаются в монокультуру с одинаковым оборудованием, начинкой, списком уязвимостей. Первый звоночек прозвучал тихо и его не услышали.

Огласите весь список

Эксперты компании Rapid7, используя инфраструктуру своего Project Sonar, провели глобальное сканировaние портов по всему миру, проверив основные tcp порты IPv4 диапазона. Исследование оказалось довольно подробным и интересным.

Вот как распределилась первая десятка tcp/ip протоколов, по величине.

Вся тридцатка протоколов в таблице..

Седьмое место в общем зачете, кто бы мог ожидать? А если объединить все http* в одну категорию, то телнет и вовсе будет на пятом месте! Как видите отставание от ssh совсем небольшое. Это был второй звоночек, но и его никто не услышал.

That said, the fact that we cannot seem to stomp out telnet in production completely is both frustrating and worrying. According to our scans, there are over 14 million devices that appear to be offering telnet services on the internet today.

100500 уязвимых CCTV видеокамер

Специалисты из Flashpoint по следам ботнета Mirai прошерстили интернет на предмет обнаружение интересных свойств CCTV видеокамер XiongMai Technologies и Dahua. Как любит говорить Михаил Задорнов «держитесь за стул, иначе вы упадете».

По данным на 6.10.2016 более 515 тыс. устройств с веб сервером uc-httpd 1.0.0.0 подвержены одновременно CVE-2016-1000245 и CVE-2016-1000246.

All internet-capable XiongMai Technology boards running the DVR/NVR CMS (Also known as
NetSurveillance) enable the telnet service to run on the primary ethernet interface. This service
is run via /etc/rcS and cannot be disabled. The user «root» has a hardcoded and immutable
password of xc3511. These systems do not have the «passwd» tool installed and the root
password cannot be changed from command line nor from the web interface.

Many known XiongMai DVRs, NVRs and IP Cameras run «CMS» (also called NetSurveillance) built by XM Technologies. This software is also used by all downstream vendors of XiongMai Technologies. The login page for these devices can be bypassed by simply changing the from http://_IP_/Login.htm to http://_IP_/DVR.htm. This allows you access to view all the camera systems without authentication. Furthermore, there is no logging on the system so user management is not possible. The web-server version on all affected products is the same; “uc-httpd”. All products currently affected by CVE-2016-1000245 are also vulnerable to the authentication bypass.

Надеюсь, что в наших аэропортах не установлены эти самые XiongMai и Dahua.

Итоги

Телнет оказался очень живуч и даже спустя десятилетия после появления ssh не спешит покидать сцену. Он вполне пригоден, даже полезен, если его использовать по назначению — в пределах прямой видимости между клиентом и сервером. Дело, однако в том, что телнет вырвался на волю из серверной, как джин из бутылки и уже начал пошаливать. По чьей вине это случилось?

С моего забора вижу так. Во-первых, основная вина на горе-производителях дырявых IoT устройств и встроенных систем. Все эти XiongMai и Dahua. С опозданием, но производитель отзывает из продажи IP-камеры. Однако, беглый обзор новостей показывает, что PR-отделы китайских компаний и сотрудники министерства коммерции не даром едят свой хлеб.

Мне это отделение известно! Там кому попало выдают паспорта! [1]

Во-вторых, конечно виноваты регулирующие органы — те, кто их сертифицирует и дает положительное заключение. Из отчета Rapid7.

These results all speak to a fundamental failure in modern internet engineering. Despite calls from the Internet Architecture Board, the Internet Engineering Task Force, and virtually every security company and security advocacy organization on Earth, compulsory encryption is not a default, standard feature in internet protocol design. Cleartext protocols “just work,” and security concerns are doggedly secondary. [2]

В-третьих, подрядчики и интеграторы, которые засадили весь мир этими CCTV камерами.
Если не принять законодательные меры, регулирующие ИТ безопасность интернет-утюгов и видеокамер, то блэкауты станут все чаще и круче, как кайдзю.

P. S. Пока набирал текст, возникло сильное желание — проверить домашний роутер nmap-ом и прочими инструментами. Проверил и успокоился, но видимо ненадолго.

Источник

Безопасность протокола Telnet

Имеются три главных проблемы связанные с использованием telnet, делая его плохим выбором для современных систем с точки зрения безопасности:

— используемые по умолчанию демоны telnet имеют несколько уязвимостей, обнаруженных за эти годы, и вероятно еще несколько до сих пор существуют;

— telnet не шифрует никакие данные, которые посылаются через установленную связь (включая пароли), и таким образом становиться возможным прослушивание связи и использовании пароль позже для злонамеренных целей;

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

Нежелательно использование протокола telnet в системах, для которых важна безопасность, таких как общественный Интернет. Сеансы telnet не поддерживают шифрование данных. Это означает это любой, кто имеет доступ к любому маршрутизатору, коммутатору или шлюзу в сети между двумя удаленными компьютерами, соединенными сеансом связи по протоколу telnet, может перехватить проходящие пакеты и легко получить логин и пароль для доступа в систему (или завладеть любой другой информацией, которой обмениваются эти компьютеры) при помощи любой общедоступной утилиты подобно tcpdump и Ethereal.

Эти недостатки привели к очень быстрому отказу от использования протокола telnet в пользу более безопасного и функционального протокола SSH, описанного в 1998г. SSH предоставляет все те функциональные возможности, которые представлялись в telnet, с добавлением эффектного кодирования с целью предотвращения перехвата таких данных, как логины и пароли. Введенная в протоколе SSH система аутентификации с использованием публичного ключа гарантирует, что удаленный компьютер действительно является тем, за кого себя выдает.

Эксперты компьютерной безопасности, как например SANS Institute и члены телеконференции comp.os.linux.security рекомендуют отказаться от использования протокола telnet для удаленного доступа при всех нормальных обстоятельствах.

Когда telnet развивался в ранних 1980-ых (согласно некоторым источникам в 1969), большинство пользовательских компьютеров в сети было в компьютерных отделах академических учреждений, или в больших частных и правительственных научно-исследовательских институтах. В этой среде многие предприятия не были особого обеспокоены защитой до резкого увеличения пропускной способности 1990-ых. С экспоненциальным ростом числа пользователей сети Интернет, также резко увеличилось число людей, пытающихся взломать серверы этой сети. Как следствие протокол telnet не должен использоваться в сетях, имеющих доступ в Интернет.

Клиенты telnet до сих пор иногда используются для того, чтобы вручную «общаться» с некоторыми другими сервисами. Например это иногда бывает полезным для отладки сетевых служб типа SMTP или HTTP серверов, т.к этот способ делает простым отправку команд на сервер и изучение ответов сервера на те или иные команды. Telnet может также использоваться как элементарный IRC клиент, если Вы достаточно хорошо знаете протокол.

Telnet также может использоваться для Multi User Dungeon игр, которые работают через сеть Интернет.

История протокола SSH

В 1995 году Тату Илонен (Tatu Ylonen, Finland) представил на рассмотрение первую версию программы SSH и Интернет драфт (Internet draft) «The SSH (Secure Shell) Remote Login Protocol», который описывает протокол, используемый оригинальной программой SSH, который также известен как протокол SSH-1. Вскоре после этого была выпущена новая версия протокола SSH-2. В 1997 году по просьбе Тату Илонена, организация IETF организовала специальную группу SECSH, в обязанности которой входило дальнейшее развитие, усовершенствование и поддержкапротокола (см. ресурсы SSH).

Важно отметить, что сами по себе протоколы SSH-1 и SSH-2 различны. Т.е. если клиент запрашивает соединение с сервером протоколу SSH-1, а сервер поддерживает только протокол SSH-2, то соединение установлено не будет. Эта особенность связана с технической реализацией этих протоколов, которые, по большому счету, выполняют одни и теже функции. Более того использование протокола SSH-1 скорее всего свалится на системного администратора в виде лишней головной боли, чем предоставит реальную защиту передаваемых между системами данных.

Технология протокола SSH

SSH-1 vs. SSH-2

Протокол SSH разрабатывался для предоставления безопасности передаваемх данных путем реализации стойкого алгоритма шифрования данных, надежной системы аутентификации пользователя и сервера, предоставлением системы контроля целостности передаваемых данных, а также инкапсуляцией приложений работающих на основе протокола TCP для установления безопасных туннелей.

Описание технологии протокола SSH-1

Ниже на рисунке 1 дано описание работы протокола SSH-1:

Рисунок 1 алгоритм работы протокола SSH-1

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

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

Сессия продолжается до тех пор, пока и клиент и сервер способны аутентифицировать друг друга. Установленное соединение по протоколу SSH-1 позволяет защитить передаваемые данные стойким алгоритмом шифрования, проверкой целостности данных и сжатием.

Источник

Привет из прошлого. Почему протокол Telnet небезопасен?

Среди десятков существующих сетевых протоколов выделяются как относительно новые технические решения, так и проверенные временем. Некоторые сетевые протоколы существуют уже более 40 лет и широко используются практически в неизменном виде. Ими удобно пользоваться, но, увы, сетевая безопасность может оказаться под угрозой.

Как придумали Telnet

Одним из наиболее распространенных и «древних» сетевых протоколов стал протокол Telnet (от teletype network, сеть телетайпной связи). Первая версия протокола была представлена еще в 1969 году. Telnet разрабатывался как универсальный инструмент доступа к командной строке удаленного компьютера. В большинстве используемых операционных систем, начиная с середины 1970-х годов, Telnet использовался для организации удаленного доступа, со временем этот протокол стал де-факто стандартом. Фактически удаленный доступ позволял выполнять все необходимые сетевые соединения на чужом компьютере, что было удобно для администрирования.

Однако в 1970-х годах компьютерами пользовались преимущественно ученые в университетах и специалисты в крупных компаниях (в основном в США), поэтому надобности в дополнительных методах шифрования трафика поначалу просто не было: пользователей было мало, и случаи злонамеренных подключений к рабочим станциям были исключительно редки.

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

Что умеет Telnet?

Telnet все еще используют для многих тривиальных задач. С его помощью можно проверить доступность того или иного хоста, например:

С помощью данной команды мы проверяем, отвечает ли адрес 192.168.1.12 по 443 порту. Также можно выяснить, открыт ли какой-то порт на локальном компьютере:

В данном случае проверяется доступность порта 12345.

telnet localhost 25 (подключаемся к локальному хосту, к порту 25)

helo localhost (после команды helo пишем адрес сервера, с которого мы подключаемся к почтовому серверу, для примера — тоже localhost, в случае успеха получаем сообщение вида mx.exim.test Hello localhost [127.0.0.1]).

Так мы послали письмо от имени alex@exim.test на адрес news@exim.test, письмо содержит две строки — first test line и second test line. Разумеется, Telnet можно использовать и с другими сетевыми утилитами популярных операционных систем.

Но лучше все же не Telnet

Как мы уже упоминали, данные, передаваемые по Telnet, не шифруются.

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

Даже если при соединении удаленный сервер запрашивает пароль для авторизации, это далеко не всегда оказывается проблемой: 23 порт, используемый для работы Telnet, нередко открыт при использовании различных сетевых устройств, например, IP-камер. В 2016 году была найдена просто невероятная уязвимость: у сотен тысяч китайских камер от компаний Dahua и XiongMai постоянно был активен Telnet, а пароль администратора, используемый для изменения прошивки камер, нельзя было изменить. В это сложно поверить, но производители так урезали прошивки камер, что просто «выбросили» команду passwd! В России таких уязвимых камер с неизменяемым паролем оказалось более 20 000.

Зная пароль, выставляемый производителями по умолчанию, можно просто подключиться по Telnet к чужой камере и управлять ей. Что еще хуже, можно превратить камеру в часть ботнета, заставив подключаться ее к DNS-серверам крупных провайдеров. Конечно, подключение десятков камер инфраструктура провайдера переживет, но если речь идет о сотнях тысяч устройств, подконтрольных злоумышленникам, такая DDoS-атака может привести к недоступности популярных сайтов.

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

Источник

Максимальная Безопасность:

Руководство Хакера по Защите Вашего Internet Сайта и Сети

Основанные На Telnet Нападения

Эта глава исследует нападения разработанные за годы использования службы Telnet. Это изучение начинается с небольшой истории. Протокол Telnet был сначала всесторонне определен Postel’ем в 1980. В RFC 764, Postel писал: Цель протокола Telnet состоит в том, чтобы обеспечить довольно общее, двунаправленное, восьмиразрядное байт ориентированное средство связи. Его основная цель состоит в том, чтобы позволить стандартный метод связи с помощью интерфейса терминальных устройств и ориентируемых на терминал процессов друг с другом. Это предполагает, что протокол может также использоваться для терминал-терминал связи («соединения») и связи процесс-процесс (распределенное вычисление).

Telnet

Как я упоменал в Главе 6, «Краткое Введение в TCP/IP», Telnet уникальна в её проекте с известным исключением rlogin. Telnet разработана, чтобы позволить пользователю войти на внешнюю машину и выполнять на ней команды. Telnet (подобно rlogin) работает, как если бы Вы работали с консоли удалённой машины, как будто Вы физически приблизились к удалённой машине, включил её и начали работать.

ПРИМЕЧАНИЕ: Пользователи ПК могут получить впечатление об этом с точки зрения PCAnywhere или CloseUp. Эти программы позволяют Вам дистанционно войти в другой ПК и выполнять команды в C: приглашении удалённой машины (или даже выполнять команды в Windows, если Вы имеете очень высокоскоростное подключение, чтобы передать графику по проводу).

Виртуальный Терминал

ПРИМЕЧАНИЕ: Lynx это полностью основанный на терминале HTML броузер для использования с учётной записью оболочки или даже DOS версией TCP/IP подключения. Это упрощенный способ обращения к Всемирной Сети.

История Безопасности Telnet

Telnet неожиданно возникала в консультациях по безопасности много раз. Проблемы безопасности Telnet изменяются значительно, с большим количеством уязвимостей, всплывающих из-за ошибок программирования. Однако, ошибки программирования не единственная причина почему Telnet появилась в консультациях. В августе 1989, например, проблема была в троянской программе, как объясняет консультация CERT «Telnet Break-in Warning» («Предупреждение о Останове Telnet»): Многие компьютеры, связанные с Internet, недавно испытали неавторизованные действия операционной системы. Исследования показали, что деятельность происходила в течение нескольких месяцев и распространяется. Несколько компьютеров UNIX имели свои программы «Telnet» незаконно замененные версиями «Telnet», которые регистрируют исходящие сессии входа в систему (включая имена и пароли пользователей к удалённым системам). Кажется, что доступ был получен ко многим машинам, которые появились в некоторых из этих log-файлов сессии.

Такое нападение происходило только до учреждения Координационного Центра Безопасности DDN (сентябрь 1989), так имеется небольшая документация о том, воздействовало ли оно на правительственные компьютеры. Также, хотя усилия CERT оценены для Безопасности Internet, консультации DDN иногда содержат более технический анализ проблемы.

СОВЕТ: Если Вы купили старую Sun 3/60 по Сети, Вы захотите получить заплаты, которые включены в предыдущую консультацию.

Проблема была связана с опцией файла конфигурации, в которой можно было включить или отключить FTP сервер. Большинство пользователей предполагало, что, если инструкция, включающая сервер, не присутствует, то сервер не работает. Это было ошибкой. Опуская строку (или добавляя опцию ftp=yes ), пользователь позволял доступ на чтение и запись неавторизованным личностям к файлам на вашем жёстком диске.

Я надеюсь, что это решит аргумент относительно того, мог ли пользователь ПК быть атакован из вне. Так много станет обсуждений в Usenet по этой проблеме. Неудача Telnet NCSA была только одна из многих ситуаций, в которых пользователь ПК или Mac мог быть атакован из пустоты. Так в зависимости от обстоятельств, средний пользователь дома на своём ПК может быть жертвой нападения из вне. Люди могут читать ваши файлы, удалять их, и т.д.

Имя пользователя в этом файле не сохраняется в зашифрованной форме (в действительности, некоторые программы шифруют имена пользователей). Пароль зашифрован, но схема шифрования очень плохо реализована. Например, если пароль меньше шести символов, для взлома потребуется всего несколько секунд. Фактически, взлом этих паролей настолько тривиален, что можно это сделать 14-ти строчной программой на Бейсике.

Если Вы пользователь Mac или ПК, в настоящее время использующий Telnet NCSA (с FTP сервером), отвергните весь FTP доступ любому, кому Вы не доверяете. Если Вы не учтёте это предупреждение, то можете быть взломанным. Вообразите сценарий, когда единственный индивидуум в сети использует Telnet NCSA. Даже если остальная часть сети достаточно безопасна, в целом сеть не безопасна. Кроме того, приложение не выполняет регистрацию (в обычном смысле) и поэтому не остаётся никакого следа. Любая сеть, выполняющая это приложение, может быть атакована, заблокирована, или разрушена, и никто не сможет идентифицировать злоумышленника.

Изменение Среды

Эта распечатка очень обширный вывод команды на машине, на которой был установлен виртуальный домен. Более управляемая (и более легко объясняемая) версия может быть получена на пустой оболочке машины. Вот вывод:

Эмуляция Терминала

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

Два лучше всего известных терминала были Tektronix 4010 и VT100 (также IBM 3270, который немного отличен от них). Каждый имел набор символов и строк на экране, которые могли отображаться. Фактически, большинство терминалов обычно имели две установки. Поскольку терминалы стали довольно модными, можно было даже устанавливать количество столбцов и, в конечном счёте, графику (Tektronix был ориентирован на графику).

Может быть установлено много различных переменных окружения. Эти переменные могут строго влиять на то, как удалённая машина получает, обрабатывает и поддерживает ваше удалённое Telnet подключение. Таким образом, протокол Telnet был разработан, чтобы позволить принятие некоторых переменных окружения во время связи. Как объяснено в RFC 1408: Многие операционные системы имеют информацию запуска и переменные окружения, содержащие информацию, которая должна быть размножена удалённым машинам, когда установлены Telnet подключения. Вместо того чтобы создавать новую опцию Telnet, каждый раз когда кто-то придумывает некоторую новую информацию, которую необходимо размножить через сессию Telnet, но сессии Telnet неважно знать о ней, эта универсальная информационная опция может использоваться.

Недавняя дыра в безопасности Telnet была основана на возможности сервера Telnet получать, отвечать и разрешать принятие этих переменных окружения. Поскольку эта опция была настолько очевидна в UNIX системе, невероятное число платформ были уязвимы этому нападению.

Строка, которая показывает уязвимость опции среды Telnet, выглядит следующим образом:

Эта строка сообщает, что уязвимость Telnet имеет высокую категорию риска (в ревизии, цитируемой предварительно, эта уязвимость была найдена на двух узлах в одной подсети). [High Risk]2 относится к уровню риска, который дыра представляет. Эта уязвимость чрезвычайно высокого риска. Помните, она была найдена на узле с современным брандмауэром!

ПРИМЕЧАНИЕ: libc это стандартная библиотека для C. Полный дистрибутив libc обычно содержит включаемые и заголовочные файлы для использования в программировании на C. Все разновидности UNIX имеют (или должны иметь) установленной эту библиотеку. Она необходима для компилирования программ, написанных на языке программирования C.

Как отмечает Sam Hartman из MIT в своей статье «Telnet Vulnerability: Shared Libraries» («Уязвимость Telnet: Общедоступные Библиотеки»): Проблема состоит в том, что telnetd позволяет клиенту передавать LD_LIBRARY_PATH, LD_PRELOAD и другие опции компоновщика времени выполнения в среду процесса, который выполняет вход в систему.

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

ПРИМЕЧАНИЕ: Hartman отметил, что, если адресат использовал Kerberos-знающий telnetd, только пользователи с допустимой учётной записью на удалённой машине могут фактически осуществлять нападение. Я предполагаю, однако, что большинство машин не используют такие средства безопасности Telnet.

Разнообразные Telnet имеют не особенно безопасный протокол. Можно легко подслушивать сессии Telnet. Фактически, имеется утилита, названная tty шпион, предназначенный для этой цели. Как описывает её автор, Carl Declerck: [ttynsoop] позволяет Вам подглядывать за входом в tty через другое устройство tty или псевдо-tty. tty-шпион становится «аналогом» первоначального телетайпа, переадресовывая ввод и вывод от/на него.

ПРИМЕЧАНИЕ: ttysnoop не просто специфичный для Telnet шпион; он подглядывает за телетайпом, не за протокол Telnet. Сетевой перехватчик подобный sniffit может также использоваться (и вероятно более подходящ) для перехвата протокола Telnet.

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

Разве Эти Нападения Больше не Эффективны?

Нет; это прежде всего благодаря недостатку образования. Нападение на опции среды, описанное предварительно, весьма эффективно на многих системах в пустоте. Это так даже притом, что консультации о нападении с готовностью доступны в Internet.

Telnet Как Оружие

ПРИМЕЧАНИЕ: Хотя я перечислил только пять портов, можно соединяться с большинством TCP/IP портов, инициализируя сессию Telnet. Некоторые из этих портов останутся в полностью пассивном состоянии, в то время как подключение активно, и пользователь ничего не будет видеть. Например, это так с портом 80 (HTTP). Однако Вы можете выдавать совершенно допустимые запросы к порту 80, используя Telnet, и если эти запросы допустимы, порт 80 ответит. (Запрос не обязательно должен быть допустимым. Выдача ошибочной интрукции GET выявит живой ответ от Web сервера, если запрос достаточно уродлив.)

В документе Farmer и Venema много нападений осуществлялись только с Telnet или вместе с другими программами. Одно такое нападение включает X терминал: X Терминалы это обычно бездисковые клиенты. Это машины, которые имеют незначительный минимум аппаратного и программного обеспечения, чтобы соединяться с X сервером. Они чаще всего используются в университетах и состоят из 17 или 19 дюймового экрана, ядра, клавиатуры и мыши. Терминал обычно поддерживает минимум 4 мегабайта ОЗУ, но некоторые содержат целых 128 мегабайт. X терминалы также имеют клиентское программное обеспечение, которое позволяет им соединяться с сервером. Как правило, подключение осуществляется через быструю Ethernet, аппаратно связанной с терминалом. X Терминалы обеспечивают высокоскоростную связность с X серверами, вместе с высокопроизводительной графикой. Эти машины продаются в Internet, а также делаются большие «дополнительные» терминалы для использования дома. (Они особенно хороши для обучения.)

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

При нормальных обстоятельствах, реальный домен это домен, который был зарегистрирован в InterNIC, а также имеет свой собственный выделенный сервер. Где-нибудь в пустоте есть машина с постоянным IP адресом, и она постоянно соединена с Internet через 28.8Kbps модем, ISDN, 56Kbps модем, передачу кадра, T1, T3, ATM, или возможно, если владелец не экономит расходы, SONET. Также, когда Вы посылаете Telnet запрос к такому реальному сайту, то достигаете этой машины и никакой другой.

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

Telnet немедленно показывает состояние вашего сервера. Когда взломщик инициализирует Telnet подключение к ваша_компания.com (и при соединении видит имя машины, как узла в некоторой другой, большой сети), он немедленно знает, что ваш адрес виртуальный домен.

ПРИМЕЧАНИЕ: Эта уязвимость была только в Информационном Сервере Internet 2.0 сервера Всемирной Сети (HTTP). Более поздние версии IIS по сообщениям чисты.

Наконец, Telnet часто используется, чтобы генерировать fakemail и fakenews. Спаммеры часто используют эту опцию вместо использования регулярных средств посылки сообщений в Usenet. Имеются некоторые опции, которые могут быть установлены, и разрешающие спаммерам избегать, по крайней мере, некоторых экранов, созданных уничтожающих спам роботами в сети Usenet.

Telnet очень универсальный протокол и, с некоторым усилием, он может быть сделан безопасным. (Я лично одобряю SSH как замену ему, поскольку он предотвращает от подглядывающих сессий Telnet.) Однако, Telnet не всегда безопасен вне машины. Если Вы используете старое программное обеспечение (перед 1997), проверьте были ли установлены соответствующие заплаты.

Telnet может также использоваться в разнообразных нападениях или другом сборе информацию от удалённого узла (некоторые из них обсуждаются в этой главе). Ко времени, когда эта книга будет выпущена, всплывут намного больше методов Telnet нападения. Если Вы выполняете сеть и намереваетесь предоставить вашим пользователям доступ к Telnet, остерегайтесь. Это особенно так на новых Telnet серверах. Эти новые серверы могут иметь ошибки, которые ещё не были обнаружены. И, так как Telnet настолько интерактивен и предлагает пользователю так много мощи в выполнении команд на удалённых машинах, что любая дыра в дистрибутиве Telnet критическая. Он в этом отношении стоит в той же самой категории, что и FTP или HTTP (или возможно даже выше).

Ресурсы

Discussion of Telnet Protocol (RFC 139) ( Обсуждение Протокола Telnet (RFC 139) ). T.C. O’Sullivan. К сожалению, этот RFC больше не доступен в онлайне.

First Cut at a Proposed Telnet Protocol (RFC 97) ( Первый Разоез Предложенного Протокола Telnet (RFC 97) ). J.T. Melvin и R.W. Watson. К сожалению, этот RFC больше не доступен в онлайне.

Session-Layer Encryption ( Шифрование Сеансового Уровня ). Matt Blaze и Steve Bellovin. Слушания Симпозиума Безопасности Usenix, июнь 1995.

Secure RPC Authentication (SRA) for Telnet and FTP ( Безопасная Аутентификация RPC (SRA) для Telnet и FTP ). David K. Hess, David R. Safford и Douglas Lee Schales. Слушания Четвёртого Симпозиума Безопасности Usenix, Суперкомпьютерный Центр, Техасский Университет A&M, 1993.

Источник