Каково назначение протокола telnet. Что такое Telnet и как пользоваться утилитой

Telnet – базовый протокол ОС UNIX, обеспечивающий терминальный доступ пользователей к удалённому компьютеру .

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

По умолчанию в Telnet используется 23 порт. На удалённом компьютере должна быть запущена серверная часть, а на компьютере пользователя – клиентская. Клиентская программа носит то же название – telnet и допускает ввод параметров из командной строки. К этим параметрам относятся:

Имя (IP адрес) сервера и номер порта

Тип текстового терминала

Имя пользователя

Имя журнала соединения

Определение действий некоторых функциональных клавиш клавиатуры и др.

Синтаксис командной строки зависит от программной реализации telnet и с этой точки зрения telnet можно рассматривать как службу или сервис.

Работа протокола telnet предусматривает передачу серверу (удалённому компьютеру) по протоколу ТСР каждого набранного пользователем знака в отдельном пакете. В случае включённого эха сервер возвращает знак на монитор пользователя. Результаты выполнения запущенных на сервере программ передаются уже блоками. В пределах прав пользователя и возможностей терминала telnet обеспечивает полный доступ к программам и файлам сервера. При установлении соединения в процессе аудентификации символы имени пользователя и пароля передаются в открытом виде, что делает использование telnet крайне опасным.

Наиболее популярный метод повышения безопасности прикладных терминальных протоколов (например, telnet) является протокол SSH (Secure SHell), использующий 22 порт по умолчанию. Так же, как и в telnet, на удалённом компьютере запускается серверная часть SSH, а на пользовательском компьютере – клиентская. После установления соединения все данные передаются в зашифрованном виде и все данные прикладных протоколов туннелируются по этому защищённому соединению как это показано на рисунке 3.5.3.1.

Перед использованием telnet удалённый компьютер и компьютер пользователя устанавливают защищённое соединение по 22 порту (подразумевается, что до использования SSH в клиентской и серверной части уже определены пароли криптографической защиты). При вызове telnet открывается 23 порт, но передаваемые пакеты перехватываются клиентом SSH, шифруются и отправляются по защищённому каналу. Сервер SSH расшифровывает данные и по 23 порту передаёт серверу telnet. Реакция сервера передаётся в обратном порядке. Пользователь не ощущает работы протокола SSH и работает как с обычным клиентом telnet по 23 порту.

Протоколы электронной почты

Электронная почта (E-mail) – один из старейших и наиболее распространённых сетевых сервисов, популярных как в локальных, так и глобальных сетях .

Система электронной почты появилась в 1982 г. как сервис предка Internet сети ARPANET. Эта система значительно отличалась от принятых CCITT рекомендаций серии X.400. Сложность рекомендаций Х.400 и их непродуманность привели к редкому для сетевых технологий случаю, когда инициативная разработка победила международный стандарт. Службы электронной почты, отвечающие Х.400, не нашли широкого применения и представляют скорее научный интерес.

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

Конверт и заголовок имеют формализованные поля. Наиболее важными из них являются (обязательные для заполнения отправителем поля выделены жирным шрифтом):

То: - адрес (а) получателя (лей) в формате имя_ящика@имя_почтового_сервера

Сс: - (carbon copy) адрес (а) дополнительного (ных) получателя (лей)

Bcc: - (blind carbon copy) слепой (ые) адрес (а) получателя (лей), о которых другим не сообщается

Sender: - адрес отправителя письма

Received: - поле, куда при прохождении каждого узла добавляется имя узла, дата и время приёма

Return-Path: - имена узлов на пути письма

Date: - дата и время отправки письма

Reply-to: - адрес, куда надо ответить

Message-id: - уникальный идентификатор письма (для ссылок)

In-Reply-id: - идентификатор письма, на которое даётся ответ

Subject: - тема письма

Тело сообщения представляет собой набор строк из не более, чем 1000 (рекомендуется до 78) ASCII (American Standard Code for Information Interchange) знаков, т. е. 7-и битных чисел, представляющих буквы латинского алфавита, знаки препинания и цифры (популярным для такого представления является термин «кодировка»). Символы национальных кодировок (например, знаков кириллицы), двоичные файлы (например, с аудио, или видео информацией) и др. отображаются в соответствии с соглашением MIME (Multipurpose Internet Mail Extension – многоцелевые расширения электронной почты в Интернете), которое предусматривают поле с указанием способа кодировки (например, Base64 – см. параграф 3.5.2).

Базовым методом обеспечения конфиденциальности электронной почты является её криптографическая защита. Наиболее популярная система именуется PGP (Pretty Good Privacy - достаточно хорошая конфиденциальность). Эта система предложена Филом Циммерманом (Phil Zimmerman) и предусматривает использование нескольких алгоритмов шифрования (RSA, IDEA, MD5).

Другая система носит название PEM (Privacy Enhanced Mail – почта повышенной секретности) и отличается от PGP необходимостью связи с центрами сертификации ключей, меньшей степенью защиты (для кодирования данных в системе PGP используется ключи длинной 128 бит, а в системе PEM – только 56 бит), но полным соответствием рекомендациям ITU-T (Х.400 и Х.509).

Протоколы электронной почты характеризуются значительным разнообразием от фирменных, пригодных в программных продуктах конкретных фирм-производителей, до общепризнанных. Речь идёт о протоколах именно систем электронной почты, а не о распространённых системах эмуляции почтовых служб на базе протокола НТТР (см., например, www. mail. ru).

Среди почтовых протоколов можно выделить:

SMTP (Simple Mail Transfer Protocol – простой протокол электронной почты) – протокол, используемый для обмена почтой между узлами и отправки писем от клиента к почтовому серверу. По умолчанию протокол использует 25 порт.

РОР3 (Post Office Protocol v.3 –протокол электронной почты версии 3) – протокол для получения почты клиентом. По умолчанию протокол использует 110 порт.

IMAP v4 (Internet Message Access Protocol v.4 –протокол интерактивного доступа к электронной почте версии 4) – протокол, аналогичный РОР3, но позволяющий клиенту хранить и обрабатывать почту на самом почтовом сервере. По умолчанию протокол использует 585 порт

Протокол SMNP

Протокол SNMP (Simple Network Management Protocol – простой протокол сетевого управления) первоначально разрабатывался для управления маршрутизаторов, но затем был расширен на любые сетевые устройства (по умолчанию порты 161/162). В настоящее время актуальна версия 2 протокола (1999 г.) .

Протокол построен по принципу клиент - сервер (на управляемом сетевом устройстве должна быть запущена программа клиента) и включает в себя протокол управления (взаимодействие управляемого и управляющего узлов), язык ASN.1 (Abstract Syntax Notation v.1 - абстрактная синтаксическая нотация версии 1) описания модели управления и собственно модель управления MIB (Management Information Base - база управляющей информации). Распространению протокола мешает его низкая защищённость и ориентация на использование протокола UDP, приводящего к возможной потере сообщенийDNS

Задача разрешения имен подразумевает определение IP адреса узла по его символьному имени и определение символьного имени по заданному IP адресу.

Исторически первый, но до сих пор действующий механизм разрешения имен связан с прямым заданием таблицы соответствия символьных имён и IP адресов в файле hosts/lmhosts (первый файл используют UNIX/Linux и некоторые др. операционные системы (ОС), а второй – ОС фирмы Microsoft). Оба файла текстовые и их форматы и ключи можно найти в MS Windows в одноимённых файлах с расширением. sam (sample – образец). Очевидно, для сколько-нибудь крупной сети решить задачу таким образом полностью не представляется возможным, хотя запись в эти файлы сведений об основных серверах, маршрутизаторах, шлюзах и пр. весьма эффективна для ускорения старта компьютера в сетевом окружении.

Другой, достаточно популярный способ разрешения имён связан с использованием NetBIOS (Network Basic Input/Output System) поверх TCP/IP . Эта система была разработана совместными усилиями Microsoft и IBM в 80-е годы как сетевой сервис ввода/вывода для операционной системы Windows. Позже, для реализации доступа пользователей к ресурсам сети был разработан протокол NetBEUI (NetBIOS Extended User Interface – расширенный пользовательский интерфейс NetBIOS) как основной сетевой протокол в ОС Windows for Workgroups и NT. Наконец, с повсеместным распространением стека TCP/IP компания Microsoft была вынуждена выпустить реализацию NetBIOS, использующую протокол IP для передачи необходимых данных (NetBIOS поверх TCP/IP). До сих пор продолжается поддержка NetBIOS в ОС Windows 2000/NT/XP, правда уже не как основного механизма доступа к ресурсам сети. NetBIOS целесообразно использовать в небольших, одноранговых сетях.

Изначально, каждый узел в сети с NetBIOS имеет символьное имя (до 15 знаков) с идентификатором ресурса (16-ый знак), который указывает на роль узла (файловый сервер, принт-сервер, рабочая станция и пр.). «Чистый» NetBIOS применим только для небольших сетей и считается «немаршрутизируемым», т. к. –

система имён не позволяет идентифицировать сеть

широко используются широковещательные запросы для получения и обновления сведений об узлах сети (большинство маршрутизаторов широковещательные запросы не пропускают)

Для устранения указанных недостатков компания Microsoft предложила службу WINS (Windows Internet Name Service – служба Windows имен Internet) на базе серверов имен NetBIOS. Следует отметить, что несмотря на упоминание сети Internet, WINS не применяется в этой глобальной сети.

Первый недостаток NetBIOS устраняется в WINS тем, что вводится групповое имя для сети, а второй – тем, что запросы при разрешении имён обращены к конкретным серверам WINS. Неустойчивость в работе службы, трудности администрирования и затруднительность использования в глобальной сети Internet, к настоящему моменту заставили компанию Microsoft перейти к полноценной поддержке DNS.

DNS (Domain Name System – доменная система имён) реализуется с помощью одноименного прикладного протокола, использующего по умолчанию 53 порт . Система DNS была разработана в рамках ОС UNIX и соответствующая служба, использующая DNS, имеет ту же аббревиатуру, но расшифровывается как Domain Name Service.

Имена в DNS строятся по иерархическому принципу в виде перевёрнутого дерева. Домены верхнего уровня (корневые) делятся по профессиональному принципу (. com - коммерческие,. gov - государственные,. net - сетевые и пр. узлы) или по национальному (. ru - русские,. fi - финские,. fr - французские и т. д.). ОС UNIX разрабатывалась в США и, само собой считалось, что все узлы находятся там же. Сейчас можно встретить двойные имена доменов, например,. com. tw – коммерческие тайваньские.

В свою очередь, каждый домен содержит поддомен, имя которого добавляется слева и отделяется точкой, и т. д. Заканчивается запись добавлением слева имени узла. Имя каждого домена, поддомена или узла не должно превышать 63 символа, а полное имя – 255 символов. Для обозначения имён традиционно используется латинский алфавит, цифры и тире (знак _ недопустим), но, в принципе, можно зарегистрировать домен с именем на кириллице, но смысл этого проблематичен.

Данные об именах зарегистрированных в любом домене поддоменов/узлов и их IP адресах хранятся в двух таблицах на DNS-серверах, где также имеется имя и адрес вышележащего домена. По первой таблице для заданного символьного имени определяется цифровой адрес (прямое преобразование и, соответственно, т. н. «прямая зона»), а по второй - по заданному адресу находится символьное имя (обратное преобразование и «обратная зона»).

Для повышения надёжности в каждом домене должно быть не менее 2-х серверов (primary - первичного и secondary - резервного), причём физически эти серверы должны находиться в разных сетях и могут располагаться не в тех доменах, имена узлов которых они содержат.

Корневой домен поддерживают свыше 10 DNS серверов, IP адреса и имена которых «зашиты» в сетевые ОС. Регистрацию новых имён и выделение соответствующих IP адресов производит владелец домена. Например, регистрацию в домене. ru производит РосНИИРОС, где регистрация имени и получение IP адреса обойдётся приблизительно в 50$, а годовая поддержка адреса – в 10$.Все изменения в таблице имен производятся на первичном DNS сервере, резервные серверы только обновляют свои записи по записям первичного сервера. Репликация (обновление) зоны производится с помощью надёжного протокола TCP, в то время, как для DNS запросов клиентов, применяется протокол UDP. Для ускорения процесса разрешения имени и уменьшения трафика в сети иногда устанавливают так называемые кэш-серверы DNS, которые записывают часто используемые имена и адреса.Режим работы DNS сервера может быть рекурсивным и не рекурсивным. В случае рекурсивного режима при невозможности разрешить DNS запрос этот запрос транслируется специально заданному другому DNS серверу (форвардеру – forfarders), который затем возвращает полученный ответ. При не рекурсивном режиме - в отсутствии информации о запрашиваемом узле производится обращение к корневым DNS серверам, а от них вниз по цепочке до получения ответа.

NAT (Network Address Translation - трансляция сетевых адресов) реализует преобразование (подмену) IP адресов локальных сетей во внешние IP адреса глобальной сети Internet . Необходимость такого преобразования следует из соглашения об использовании части IP адресов только в локальных сетях (см. п. 3.2), по которому маршрутизаторы глобальной сети уничтожают пакеты с этими адресами.

NAT действует на сетевом и частично на транспортном уровнях, обеспечивая преобразование в IP пакетах адресов узлов локальной сети во внешний адрес. Преобразование производится путём замены адреса внутреннего узла на внешним адрес. Заменяемые адреса запоминаются в таблице, с помощью которой производится обратная замена при получении ответного пакета. Следует отметить, что для устранения возможной неразличимости преобразуется не только IP адрес, но и с помощью PAT (Port Address Translation) номер порта.

Кроме преобразования адресов NAT позволяет уменьшить потребность в IP адресах для глобальных сетей, т. к. все пользователи локальной сети могут получать доступ к ресурсам глобальной сети через один внешний адрес.

NAT - не единственный способ отправки пакетов из локальной сети в глобальную, альтернативой трансляции адресов является использование сервера-посредника.

Telnet (англ. TE rminaL NET work ) - протокол прикладного уровня, используемый для реализации двунаправленного интерактивного текстового интерфейса в сети через виртуальный терминал. Данные от пользователя перемешиваются с управляющими командами TelNet в восьмибитные байт-ориентированные данные, передаваемых по протоколу TCP. TelNet был разработан в 1969 году. Первой версией была RFC 15 , далее расширенная в RFC 854 и далее стандартизированная в один из первых интернет-стандартов IETF STD 8. Telnet обеспечивает доступ к командной строке операционной системы на удалённом хосте, поддерживая большинство видов сетевого оборудования и операционных систем с утилитой конфигурации, однако из-за серьёзных проблем в безопасности использования Telnet в открытой сети (Интернет), всё чаще для этих целей используют протокол SSH. Однако, Telnet часто используют также и для ссылки на программное обеспечение, содержащее клиентскую часть протокола, так как клиентские приложения Telnet доступны практически для всех компьютерных платформ.

История и стандарты

Telnet это протокол клиент-сервер. Как правило, он используется, чтобы установить соединение с TCP порт 23, где находится серверное приложение Telnet. Однако, до появления TCP/IP Telnet использовал протокол NCP. Официальную огласку Telnet получил 5 марта 1973 года, после того как стандарт протокола был определён в UCLA. Из-за нечёткой архитектуры опций протокола было сделано много расширений, некоторые из которых были приняты (STD 27, STD 32), широко реализованы, а так же предложены в числе стандартов IETF.

Безопасность

При первоначальной разработке telnet в 1969 году большинство пользователей подключенных к сети компьютеров или находились в компьютерных отделениях академических учреждений, или являлись частью правительственных/частных исследований. Поэтому вопросы безопасности вставали не так остро, как это стало позднее, в 1990-х. Резко выросло людей, имеющих доступ к Интернету, а значит и количество людей, пытающихся взломать чужие сервера. Это вызвало необходимость в зашифрованных альтернативах. Эксперты компьютерной безопасности рекомендовали, чтобы использование Telnet для удалённых входов в систему было прекращено во всех нормальных обстоятельствах по следующим причинам:

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

Эти связанные с безопасностью недостатки наглядно показывали, что использование протокола Telnet в общедоступной сети опасно и неоптимально. Позже, в 1995 году, появился протокол SSH (Secure Sell), который обеспечивал большинство функций Telnet, а так же предоставлял устойчивое шифрование и публичный ключ аутентификации, для того, чтобы предотвратить перехват уязвимых данных и подтвердить подлинность удалённого компьютера. Как и и другие ранними интернет-протоколами, расширения Telnet используют TSL и SASL для обеспечения начального уровня безопасности. Однако, поддерживают эти функции далеко не все расширения, а интереса к реализации более защищённых средств не было из-за появления SSH, достаточного для большинства целей.

Известно, что большое количество промышленных и научных устройств для коммуникации есть только Telnet. Некоторые имеют только стандартный порт RS-232 и используют серверные устройства для передачи данных между TCP/Telnet и RS-232. В таких случаях устройства не могут быть сконфигурированы под SSH и этот стандарт неприменим.

Telnet 5250

Эмулятор рабочей станции IBM 5250 или 3270 поддерживается через пользовательские клиенты Telnet - TN5250/TN3270. Клиентские и серверные части разработаны так, чтобы передать данные IBM 5250 потоком через Telnet с использованием шифрования SSL, как делает это SSH и не включая эмцляцию 5250. С OS/400, 992 порт является по умолчанию портом защищённого Telnet.

Вид данных в Telnet

Все байты кроме 0xff передаются по Telnet как есть. Поэтому клиент Telnet может использоваться для установки интерактивной чистой TCP-сессии, и обычно такая не использующая IAC(0xff или 255) считается функционально идентичной. Однако, на деле всё не так: существуют иные правила виртуального терминала NVT, такие как требование сопровождения символа возврата каретки пустым символом NULL, которые отличают протокол Telnet от чистой сессии TCP. С другой стороны сегодня множество систем обладают настоящим необработанным TCP, например netcat или socat на UNIX и PuTTY на Windiws, которые можно использовать чтобы вручную обмениваться данными с другими службами без специального клиентского ПО. Тем не менее, Telnet всё ещё используется в отладке некоторых сетевых служб, таких как SMTP, IRC, HTTP, FTP или серверов POP3 - Telnet посылает команды к серверам и исследует ответы, но из всех этих стандартов только FTP использует специфичный формат данных Telnet

Ещё одно отличие Telnet от необработанного сеанса TCP - Telnet по умолчанию не чисто восьмибитный. Восьмибитный режим может быть согласован, но октеты высокого набора битов могут быть искажены до согласования, и это очевидно не требуется в не-Telnet соединении. 8-битный режим предназначен для передачи двоичных данных, а не символов. Стандарт предполагает интерпретацию кодов 000-176 как ASCII, но не предполагает значения для октетов высокого набора битов. Была попытка представить переключаемую опцию поддержки кодировки символов (например, как у HTTP), но сейчас ничего не известно о её актуальной программной поддержке

Связанные RFC

Интернет-стандарты

RFC 854 , Telnet Protocol Specification
RFC 855 , Telnet Option Specifications
RFC 856 , Telnet Binary Transmission
RFC 857 , Telnet Echo Option
RFC 858 , Telnet Suppress Go Ahead Option
RFC 859 , Telnet Status Option
RFC 860 , Telnet Timing Mark Option
RFC 861 , Telnet Extended Options: List Option

Предполагаемые стандарты

RFC 885 , Telnet end of record option
RFC 1073 , Telnet Window Size Option
RFC 1079 , Telnet terminal speed option
RFC 1091 , Telnet terminal-type option
RFC 1096 , Telnet X display location option
RFC 1123 , Requirements for Internet Hosts - Application and Support
RFC 1184 , Telnet Linemode Option
RFC 1372 , Telnet Remote Flow Control Option
RFC 1572 , Telnet Environment Option
RFC 2941 , Telnet Authentication Option
RFC 2942 , Telnet Authentication: Kerberos Version 5
RFC 2943 , TELNET Authentication Using DSA
RFC 2944 , Telnet Authentication: SRP

Telnet можно использовать как команду в операционной системе Windows. На самом деле это не только исполняемая служба, но и сетевой протокол или даже микропрограмма, которая при помощи текстового поля позволяет пользователю «общаться» с удаленным компьютером, передавая системе команду на выполнение того или иного действия, а также получения лога его выполнения.

Расшифровывается название протокола как Terminal network, что в дословном переводе означает – терминальная сеть.

Что собой представляет Terminal network

При помощи команды telnet, несмотря на её невысокую функциональность, можно выполнить достаточно много задач, таких как:

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

Многие считают, что такое соединение работает, как и большинство сетевых служб, по принципу клиент-сервер. Однако это не так. telnet – полностью двусторонняя служба с одинаковыми функциями и уровнями доступа.

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

Как работать с оболочкой?

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

Как управлять службой?

После того, как вы зайдете в службу управления терминалом Windows, необходимо знать несколько команд для возможности управления. Есть такие варианты получения списка управляющих ключей:

Если вы знакомы с опциями, можно сразу подключаться к нужному ресурсу с указанием необходимых данных. В этом случае сервер для соединения – «smatp.ya.ru» и порт – «25».

Итог:

Команда telnet очень проста в использовании и достаточно удобна. Однако в технологи её работы абсолютно не предусмотрена безопасность. Оболочка работает под Windows в полностью незащищенном режиме и без шифрования. Поэтому вместо этой функции уже достаточно давно используется ssh.

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

Как вы уже могли убедиться, если читали мой пост о настройке Telnet в Windows, работать с этой службой достаточно легко. Можно запустить его без аргументов, указав в командной строке лишь адрес хост-системы. При определенных обстоятельствах еще нужно указать конкретный порт. Первое сообщение, которое видит пользователь, после выполнения команды “ telnet “, посылается самой программой, а после установления связи между клиентом и сервером выводятся сообщения, исходящие от управляемой системы. В связи с этим с удаленной операционной системой можно работать через Telnet таким же образом, как это происходит в случаях с другими специализированными программами дистанционного доступа к ОС. Теперь давайте присмотримся к данной службе поближе и разберем наиболее часто используемые команды Telnet .

Командная строка Telnet на клиенте с Windows может принимать следующие команды:

open узел порт – применяется для установки соединения с заданным узлом;

close – закрывает существующее соединение;

quit – выход из текущего сеанса Telnet;

display – позволяет просмотреть текущие параметры Telnet-клиента;

set – с ее помощью возможно задать Telnet-параметры текущей сессии , а конкретно:

set ntlm включит NTLM (использование интегрированной в Telnet проверки подлинности NTLM во время подключения пользователя с удаленного компьютера позволяет обойтись без ввода логина и пароля при входе);
set localecho включит режим локального вывода команд;
set term vt100/vt52/vtnt/ansi задаст указанный тип терминала (например, VT100 применяют для выполнения обычных программ командной строки, а VTNT – для выполнения расширенных программ, типа “edit”);
set escape символ задаст последовательность клавиш, переключающих режим сеанса в командный режим (к примеру, set escape , потом нажатие клавиш “Ctrl+P” и “Enter” установит Ctrl+P в качестве переключателя);
set logfile имя_файла укажет на файл журнала текущей активности Telnet (этот файл должен находиться в файловой системе управляющего компьютера);
set logging включит ведение журнала (файл журнала должен быть предварительно указан вышеприведенной командой, иначе возникнет сообщение с ошибкой);

unset – выполняет отключение различных параметров сессии Telnet (обратные операции по отношению к set), а именно:

unset ntlm отключит встроенную проверку подлинности;
unset localecho деактивирует режим локального вывода команд;

status – используется с целью проверки наличия подключения к Telnet-клиенту;

enter – применяется для перехода в существующий подключенный сеанс Telnet;

Или help – отображение справочной информации.

Закончив с делами на удаленной машине, вам нужно будет закрыть соединение с ней. При этом работа самого Telnet завершается не всегда. Чтобы выйти в командную строку Telnet, воспользуйтесь горячими клавишами “Ctrl+]” .

Недавняя крупнейшая DDoS атака на DNS-серверы компании Dyn на Хабре не прошла незамеченной . Особенностью этого блэкаута стала широкое применение http запросов c IoT устройств и открытый 23-й tcp порт, используемый службой telnet .

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

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

Уязвимость CVE-2016-1000245 - это просто караул. На всех девайсах один и тот же рутовый пароль xc3511, который нельзя изменить так как на системе нет команды passwd . Служба telnet включена и из настроек никак не отключается, разве что удалить инит скрипт из /etc/init.d/rcS .

/etc $ cat passwd root:absxcfbgXtb3o:0:0:root:/:/bin/sh /etc $ cat passwd- root:ab8nBoH3mb8.g:0:0::/root:/bin/sh

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.

Уязвимость CVE-2016-1000246 не уступает первой. Можно обойти ввод учетной записи и пароля, если зайти через http:///DVR.htm .

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-отделы китайских компаний и сотрудники министерства коммерции не даром едят свой хлеб.

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

Во-вторых , конечно виноваты регулирующие органы - те, кто их сертифицирует и дает положительное заключение. Из отчета 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.

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

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

Использованные материалы

W. Richard Stevens TCP/IP Illustrated, Volume 1, The Protocols, 1994.

Теги: Добавить метки