Протоколы telnet и rlogin (глава для профессионалов)

O В этой главе:

O История возникновения telnet

O Задачи, решаемые с помощью протокола telent

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

O Передача команд в потоке

O Краткое описание команд telnet

O Алгоритм Нагла

O Перехват и расшифровка сессии telnet-клиента с сервером

O Краткая история возникновения протокола rlogin

O Задачи, возлагаемые на rlogin

O Передача команд протокола rlogin

O Кратное описание команд протокола rlogin

O Обзор telnet-клиентов

O Конфигурирование telnet-клиента, входящего в поставку Windows 2000


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

Протокол telnet один из старейших в сети. Он разрабатывался в конце шестидесятых годов, когда слово “Internet” еще не существовало, а кабель, соединяющий несколько узлов, гордо именовался «сетью ARPANET». Тогда telnet составлял основу сети, и относился к фундаментальным протоколам - большинство узлов общались друг с другом именно посредством telnet. Со временем его вытеснили новые специализированные протоколы, и он потерял свою главенствующую роль. Сегодня telnet используется практически только для удаленного администрирования UNIX-серверов.

Telnet - прикладной протокол, реализуемый поверх транспортного TCP-протокола. Он обеспечивает дуплексный, 8-битный канал между участниками соединения и поддерживает виртуальные терминалы. По умолчанию для подключения к telnet-серверу необходимо установить соединение по 23 порту.


Виртуальный терминал (NVT - Network Virtual Terminal) это мнимое символьное устройство с клавиатурой и принтером. Данные, набранные на клавиатуре, отправляются серверу, а ответ сервера печатается на принтере. Под «клавиатурой» и «принтером» подразумеваются некие мнимые устройства. В действительности ответ сервера вовсе не обязательно выводить на настоящий принтер, вместо этого обычно используется экран.

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

Подробнее о виртуальном терминале рассказано ниже, в конце этой главы.

Протокол telnet использует довольно оригинальный способ передачи команд, называемый команды в потоке (in-band signaling), заключающийся в следующем: любой байт из интервала [0x0, 0xFF) [185] интерпретируется как данные, а байт 0xFF, называемый IAC (Interpret As Command - интерпретировать как команду), указывает на то, что следующий за ним байт является командным байтом. Если возникнет необходимость передать байт данных, равный 0xFF, его следует продублировать, т.е. отправить два байта 0xFF 0xFF.

Командный байт может принимать следующие значения, перечисленные в таблице (необходимые объяснения даны ниже).

???? Имя Код Пояснения

???? EOF 0xEC Конец файла

???? SUSP 0xED Приостановить текущий процесс

???? ABORT 0xEE Прекратить процесс

???? EOR 0xEF Конец записи

???? SE 0xF0 Конец подопции

???? NOP 0xF1 Нет операции

???? DM 0xF2 Маркер данных

???? BRK 0xF3 Прерывание

???? IP 0xF4 Прервать процесс

???? AO 0xF5 Прекратить вывод

???? AYT 0xF6 Есть кто живой?

???? EC 0xF7 Удалить последний введенный символ

???? EL 0xF8 Стереть строку

???? GA 0xF9 Идти дальше

???? SB 0xFA Начало под опции

???? WILL 0xFB Обсуждение опции

???? WONT 0xFC Обсуждение опции

???? DO 0xFD Обсуждение опции

???? DONT 0xFE Обсуждение опции

???? IAC 0xFF Байт данных 0xFF

Многие из перечисленных в таблице команд в настоящее время вышли из употребления и поэтому представляют лишь исторических интерес, а потому рассмотрены по возможности кратко:

· EOF

· End Of File - конец файла. Получатель команды уведомляет процесс, подсоединенный к NVT терминалу, что был достигнут конец файла. В настоящее время эта команда не используется.

· SUSP

· (сокращение от Suspend - приостановить) «замораживает» связанный с NVT процесс и передает управление другому процессу. «Замороженный» процесс позднее сможет продолжить свое выполнение с той же самой точки. Эта команда в настоящее время игнорируется большинством получателей.

· EOR

· End of Record - конец записи. Аналогично EOF. Подобно эта команда описана в RFC-885.

· NOP

· No operation - нет операции. Эта команда обычно используется для проверки работоспособности сессии. Если соединение с получателем разорвано, то попытка посылки NOP приведет к ошибке TCP/IP. Некоторые сервера периодически посылают NOP, чтобы убедится в активности клиента.


·
DM

· Data Mark - маркер данных. Используется в качестве сигнала синхронизации, который передается в виде срочных данных TCP. Когда получатель принимает уведомление о том, что отправитель вошел в режим срочности, он начинает читать поток данных, отбрасывая все, кроме telnet-команд. Команда DM сообщает принимающему о необходимости вернуться в обычный режим работы.


·
BRK

· Break - прерывание. Уведомляет о нажатии клавиши «Break» и приводит к прерыванию сессии с очисткой буферов ввода вывода.

· IP

· Interrupt Process - Прервать Процесс. Прервать, приостановить или завершить процесс, связанный с NVT терминалом

· AO

· Abort Output - Прервать Вывод. Принудительное завершение вывода с очисткой буферов.

· AYT

· Are You There - Есть кто живой? Эта команда приписывает получателю вернуть отправителю нечто читабельное для подтверждения факта своей активности.

· EC

· Erase Character - Удалить Символ. Эта команда предписывает получателю удалить последний символ, полученный им от отправителя.

· EL

· Erase Line - Удалить Строку. Эта команда предписывает получателю удалить последнюю строку, полученную им от отправителя.

· GA

· Go Ahead - Далее. Эта команда передает управление получателю (используется в полудуплексном режиме)

Для согласования дополнительных параметров используются квиточки WILL, WONT, DO, DONT. Отправитель может попросить получателя изменить требуемые опции или уведомлять его об изменении своего состояния.

· Квиток WILL, посылаемый отправителем, говорит, что отправитель хочет включить некую опцию для себя. Если получатель согласен, он отправляет квиток DO, в противном случае DONT.

· Квиток DO, посылаемый отправителем, просит получателя включить некую опцию. Если получатель согласен, он отправляет квиток WILL или WONT в противном случае.

· Квиток WONT, посылаемый отправителем, уведомляет получателя, что отправитель выключил у себя некую опцию. Получатель обязан подтвердить это квитком DONT

· Квиток DONT, посылаемый отправителем, приказывает получателю выключить некую опцию. Получатель обязан подтвердить это квитком WONT.

Существует множество опций, подробно описанных в “Assigned Numbers RFC”, ниже для примера описаны лишь некоторые, наиболее часто употребляемые, из них.

– Код опции Назначение

– Десятичный Шестнадцатеричный.

– 1 0x1 Эхо

– 3 0х3 Запрещение команды GA

– 5 0x5 Статус

– 6 0х6 Маркер времени

– 24 0х18 Тип терминала

– 31 0х1F ? азмер окна

– 32 0x20 Скорость терминала

– 33 0x21 Удаленный контроль потоком данных

– 34 0х22 Линейный режим (line mode)

– 36 0х24 Прочесть (изменить) переменные окружения

Некоторые опции, такие, например, как тип терминала, имеют один или несколько параметров, которые передаются следующим образом: сразу за опцией следует команда «IAC SB», а за ней один или несколько байт параметров. Команда «IAC SE» завершает ввод. Например, изменение размеров окна может происходить так: «IAC DO 0x1F» «IAC SB» «00 50 00 20» «IAC SE», где “00 50” количество символов в строке (первым идет старший байт) - первый параметр, а «00 20» количество символов в строке - второй параметр.

Протокол telnet поддерживает четыре режима передачи данных: полудуплексный, символьный, строчечный и линейный.

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

В символьном режиме каждый посланный отправителем символ немедленно доставляется получателю. Это полноценный дуплексный режим, где сторонам нет необходимости договариваться об очередности передачи. Однако с помещением каждого символа в отдельный пакет значительно падает скорость обмена, а накладные расходы резко возрастают (практически по сети передаются одни заголовки пакетов). На быстрых каналах это может быть и не заметно, но ощутимо сказывается на загруженных линиях. Чтобы перейти в символьный режим одна из сторон должна либо попросить другую отключить у себя опцию GA, либо сделать это самостоятельно и послать другой стороне уведомление. Т.е. это может выглядеть либо так: «IAC DO 0x3», либо так «IAC WILL 0x3», где 0x3 код опции «Запрещение команды GA», взятый из таблицы, приведенной выше.

Строчечный режим еще называемый kluge [186] line mode не предусматривался разработчиками явно и фактически возник в результате ошибки. В RFC-858 декларируется, что для ввода символа за один раз с удаленным эхом, опция эхо-отображения должна быть включена, а команда GA запрещена. Если же хотя бы одно из этих условий не выполняется, telnet находится в режиме строка за один раз (т.е. строчечном). Такая ситуация может возникнуть при запросе пароля, если сервер посылает клиенту «IAC WILL ECHO», а тот переходит в режим kluge line mode и передает введенный пароль целиком в одном пакете.

Значительно более совершенен недавно разработанный режим linemode, который устраняет недостатки всех остальных режимов, но сохраняет их достоинства. Подробно он описан в RFC-1184. Существенным достижением (относящимся к безопасности) является возможность передавать пароль на сервер в зашифрованном виде.


 

Символьный режим, несмотря на все свои достоинства, все же очень неудобен в глобальных сетях, поскольку каждый символ помещается в отдельный пакет [187]. Если суммарный размер IP и TCP заголовков принять равным 40 байтам, тогда несложным подсчетом нетрудно убедиться, что на долю полезных данных приходится всего 2% (1/41 * 100 = 2.4).

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

В RFC-869 предложено простое и элегантное решение, именуемое алгоритмомНагла. Суть его заключается в следующем: отправитель посылает получателю первый TCP пакет с единственным символом, но до получения подтверждения о его доставке (а протокол TCP всегда уведомляет отправителя, что его пакет был успешно получен) все поступающие на отправку символы помещаются в один пакет. Такая методика кэширования совершенно прозрачна для telnet-протокола, поскольку работает на уровень ниже его. Зато в зависимости от степени загруженности сети она автоматически настраивается на максимальную производительность.

Алгоритм Нагла используется в протоколах telnet и rlogin.

Следующий пример, демонстрирует взаимодействие telnet-сервера и telnet-клиента: вход на сервер может происходить так:

· сервер посылает клиенту «IAC DO 0x3» для перевода клиента в символьный режим

· клиент отвечает «IAC WILL 0x3» и переходит в символьный режим

· сервер посылает «IAC DO 0x1» для включения эхо-отображения клиента

· клиент отвечает «IAC WILL 0x1» и включает это-отображение

· сервер посылает строку “login:”

· клиент возвращает имя пользователя

· сервер посылает строку “password:”

· сервер посылает «IAC DONT 0x1» для отключения эхо-отображения клиента

· клиент отвечает «IAC WONT 0x1» и отключает эхо-отображение

· клиент посылает строку пароля, набранную пользователем «вслепую»

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

Перехватить сессию связи между сервером и клиентом можно с помощью специально разработанного для этой цели Proxy-сервера TCPSPY (на прилагаемом к книге диске он находится в файле /SRC/tcpspy.bat, а его исходный текст приведен в Приложении). Запустив его, необходимо указать порт удаленного сервера (23), порт локального сервера (скажем, 123) и адрес удаленного сервера (в приведенном ниже примере использовался telnet.org). Затем запустить telnet-клиент (в этом примере использовался клиент, входящий в Windows 2000) и установить соединение с узлом 127.0.0.1 по выбранному порту (123).

Ниже приведен протокол работы, сохраненный в файле tcpspy.log (на диске, приложенном к книге он расположен в /SRC/telnet.log)

· FF FD 18 FF FD 20 FF FD ¦ 23 FF FD 27 FF FB 18 FF ¤^ ¤ ¤# ¤' v^

· FB 1F FF FC 20 FF FC 23 ¦ FF FC 27 FF FD 1F FF FA vЎ № №# №' ¤Ў ·

· 18 01 FF F0 FF FB 1F FF ¦ FA 1F 00 50 00 19 FF F0 ^O Ё vЎ ·Ў P v Ё

· FF FA 18 00 41 4E 53 49 ¦ FF F0 FF FB 03 FF FD 01 ·^ ANSI Ё v¦ ¤O

· FF FB 05 FF FD 21 FF FD ¦ 03 FF FB 01 FF FE 05 FF v¦ ¤! ¤¦ vO ¦¦

· FC 21 FF FE 01 FF FB 01 ¦ 0D 0D 0A 52 65 64 20 48 №! ¦O vOdd0Red H

· 61 74 20 4C 69 6E 75 78 ¦ 20 72 65 6C 65 61 73 65 at Linux release

· 20 36 2E 31 20 28 43 61 ¦ 72 74 6D 61 6E 29 0D 0D 6.1 (Cartman)dd

· 0A 4B 65 72 6E 65 6C 20 ¦ 32 2E 32 2E 31 36 2D 33 0Kernel 2.2.16-3

· 20 6F 6E 20 61 6E 20 69 ¦ 35 38 36 0D 0D 0A 6C 6F on an i586dd0lo

· 67 69 6E 3A 20 FF FC 01 ¦ FF FD 01 6B 70 6E 63 0D gin: №O ¤Okpncd

· 0D 0A 6B 70 6E 63 0D 0D ¦ 0A 50 61 73 73 77 6F 72 d0kpncdd0Passwor

· 64 3A 20 70 61 73 73 77 ¦ 6F 72 64 0D 0D 0A 0D 0D d: passworddd0dd

· 0A 4C 6F 67 69 6E 20 69 ¦ 6E 63 6F 72 72 65 63 74 0Login incorrect

· 0D 0D 0A 0D 0D 0A 6C 6F ¦ 67 69 6E 3A 20 dd0dd0login:

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

· SERVER:FF FD 18 IAC DO 0x18; можно определить тип терминала?

· SERVER:FF FD 20 IAC DO 0x20; можно определить скорость терминала?

· SERVER:FF FD 23 IAC DO 0x23; поддерживается ли некая опция?

· SERVER:FF FD 27 IAC DO 0x27; поддерживается ли некая опция?

· CLIENT:FF FB 18 IAC WILL 0x18; да, можно определить тип терминала

· CLIENT:FF FB 1F IAC WILL 0x1F; клиент изменяет размер своего окна

· CLIENT:FF FC 20 IAC WONT 0x20; нельзя установить скорость терм

· CLIENT:FF FC 23 IAC WONT 0x23; неизвестная опция 0х23

· CLIENT:FF FC 27 IAC WINT 0x27; неизвестная опция 0х27

· SERVER:FF FD 1F IAC DO 0x1F; изменить размер окна

· SERVER:FF FA 18 01 IAC SB 0x18 1; указание клиенту возвратить тип термин.

· SERVER:FF F0 IAC SE; конец подопции

· CLIENT:FF FB 1F IAC WILL 0x1F; изменение размеров окна ОК

· CLIENT:FF FA1F IAC SB 0x18; сообщение размеров окна

· CLIENT:00 50 00 19; размер окна 80x25 символов

· CLINET:FF F0 IAC SE; конец подопции

· CLINET:FF FA 18 00 IAC SB 0x18 0;начало подопции сообщения типа терминала

· CLINET:41 4E 53 49 “ANSI”; тип терминала

· CLINET:FF F0 IAC SE; конец подопции

· SERVER:FF FB 03 IAC WILL 0x3; перевод в символьный режим

· SERVER:FF FD 01 IAC DO 0x1; включение эха

· SERVER:FF FB 05 IAC WILL 0x5; получение статуса

· SERVER:FF FD 21 IAC DO 0x21; удаленный контроль потоком данных

· CLIENT:FF FE 01 IAC DONT 0x1; клиент просит сервер включить эхо

· CLIENT:FF FB 01 IAC WILL 0x1; клиент включает эхо у себя

· CLINET:FF FE 05 IAC DONT 0x5; нельзя возвратить статус

· CLINET:FF FC 21 IAC WONT 0x21; удаленный контроль потоком данных ОК

· SERVER:FF FE 01 IAC DONT 0x1; сервер против эха клиента

· SERVER:FF FB 01 IAC WILL 0x1; серер включает это у себя

· SERVER:0D 0D 0A 52…«Red Hat Linux…»

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

Заметно, что Windows-клиент (как от Windows 95, так и от Windows 2000) не поддерживает всех опций, предлагаемых ему сервером.

Протокол rlogin происходит из Berkley UNIX. Впервые он появился в 4.2BSD и предназначался для захода удаленным терминалом на UNIX-машины, но спустя какое-то время оказался перенесен и на другие платформы. Это прикладной протокол, реализуемый поверх транспортного протокола TCP.

В сравнении с telnet, rlogin гораздо проще и не поддерживает согласования параметров, поэтому, его реализации гораздо компактнее и, как правило, устойчивее в работе. Его подробное описание вместе с исходными текстами rlogin-сервера и rlogin-клиента можно найти в RFC-1282.

После установки соединения с rlogin-сервером, rlogin-клиент посылает серверу четыре строки (все строки должны заканчиваться нулем):

· Пустую строку (нулевой байт)

· Имя пользователя, под которым он зарегистрирован на клиенте

· Имя пользователя, под которым он зарегистрирован на сервере

· Тип терминала в формате «тип терминала» «знак слеш “/”» «скорость терминала»

Сервер отвечает нулевым байтом и пытается аутентифицировать пользователя. В первую очередь анализируется файл.rhosts, содержащий список доверенных узлов и пользователей. Если адрес клиента совпадает с одним из адресов, перечисленных в этом файле, для входа на сервер вводить пароль не потребуется. В противном случае клиент должен передать серверу незашифрованную строку пароля (впрочем, последние реализации rlogin из 4.4BSD используют Kerberos для шифровки паролей, посылаемых по сети).

Протокол rlogin поддерживает единственный режим общения с сервером - символьный. Для улучшения производительности и предотвращения перегрузки сети огромным числом тиниграмм используется алгоритм Нагла.

Если rlogin-серверу требуется передать служебную команду клиенту, он входит в режим срочности TCP и отправляет команду в последнем байте срочных данных. Клиент, получив уведомление о режиме срочности, должен читать и сохранять данные до тех пор, пока не получит командный байт (последний байт срочных данных). В зависимости от команды, сохраненные данные могут быть выведены на терминал или проигнорированы. Ниже описываются четыре командных байта.

– Байт Назначение

– Десятичное Шестнадцатеричное

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

– 16 0х10 Прекращение контроля потока данных

– 32 0х20 Возобновление контроля потока данных

– 128 0х80 Получив эту команду, клиент должен сообщить серверу размер окна своего терминала и обязывается уведомлять сервер всякий раз, когда размер окна изменится.

Передача команд от клиента к серверу происходит следующим образом: клиент посылает два байта, равные 0xFF, за которыми следуют два командных байта (еще их называемых флаговыми).

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

Протокол rlogin не позволяет передать символ 0xFF 0xFF в потоке данных, поскольку они используются для служебных целей, но в отличие от telnet, не существует специальной команды для снятия такого ограничения.

Помимо командных байтов, пересылаемых с последним байтом срочных данных, в распоряжении сервера есть и другие способы управления работой клиента. Для этого клиенту передается специальный знак «~» (тильда) в первой позиции строки, за которым следует один из четырех специальных символов:

– Символ Назначение

–. (точка) Прекращение работы клиента

– Ctrl-D

– Ctrl-Z Приостановление работу клиента

– Ctrl-Y Задерживание ввода клиента

Легко видеть, в отличие от протекла telnet, rlogin плохо и даже небрежно продуман, и очень ограничен в своих возможностях. В настоящее время он практически вышел из употребления и используется очень редко.

Оба протокола работают с сетевыми виртуальными терминалами NVT, представляющими собой мнимое устройство для ввода вывода 7-битных USASCII [188] символов. Однако это не означает невозможность передачи 8-битных символов, с использованием национальной кодировки.

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

Символы с кодами от 0 до 31 и 127 называются управляющими и имеют специальное назначение, описанное в приведенной ниже таблице:

???? Название Сокращение Код символа Назначение

???? NULL NUL 0 Нет операции

???? BELL BEL 7 Дзын-Дзын

???? Back Space BS 8 Удаление последнего веденного символа

???? Horizontal Tab HT 9 Горизонтальная табуляция

???? Line Feed LF 10 Перенос курсора на следующую строку с сохранением текущей позиции

???? Vertical Tab VT 11 Вертикальная табуляция

???? From Feed FF 12 Перевод курсора на следующую страницу с сохранением горизонтальной позиции

???? Carriage Return CR 13 Перевод курсора в начало текущей строки

Все остальные управляющие коды по стандарту должны игнорироваться и не влиять на работу NVT терминала. Однако множество реализаций поддерживают собственные расширения.

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

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

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







 

Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх