Rlogin

Материал из Википедии — свободной энциклопедии

Перейти к: навигация, поиск

Протокол RLOGIN (англ. Remote LOGIN — удаленный вход в систему) - протокол прикладного уровня (7ой уровень модели OSI), часть стека TCP/IP. Позволяет пользователям UNIX подключаться к системам UNIX на других машинах через сеть Internet и работать так же, как при прямом подключении терминала к машине. Этот протокол обеспечивает такой же сервис, как протокол TELNET.

Содержание

[править] Принцип работы протокола Rlogin

[править] Установка связи

До уставновки соединения, клиент посылает серверу 4 множества символов, заканчивающиеся нулями (представление строки в С-подобных языках):

  1. пустая строка(состоит из одного нулегого байта),
  2. имя пользователя клиента,
  3. имя пользователя сервера,
  4. тип терминала и скорость.

Например:

       <null>
       bostic<null>
       kbostic<null>
       vt100/9600<null>

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

[править] От клиента серверу (и управление потоком)

Сначала клиент начинает операцию в режиме "cooked" (противополжном режиму "raw") . В этом режиме символы НАЧАЛО и КОНЕЦ (обычно ASCII DC1, DC3) принимаются клиентом и интерпретируются как начало и конец вывода с сервера на локальный терминал, в то время как остальные символы передаются на удаленный хост в том виде, в котором они были получены. (Смотри ниже обработку локальных Escape - символов).

В режиме "raw", символы НАЧАЛО и КОНЕЦ не обрабатываются локально, а посылаются удаленному серверу как любой другой символ. Таким образом в режиме "raw" сервер определяет семантику символов НАЧАЛО и КОНЕЦ; они могут быть использованы для потокового управления или иметь совсем другие значения, никак не зависящие от их первоначального использования на клиенте.

[править] Размер Экрана\Окна

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

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

Управляющая последовательность изменения размера окна имеет длину в 12 бит, состоит из:

  1. magic cookie (2х последовательеных байтов 0xFF),
  2. после которых следует 2 байта, содержащие символ "s" (ASCII, нижний регистор),
  3. затем 8 байтов, содержащие 16-битовые значения количества символьных строк, количество символов на строку, количество пикселей в горизонтальной развертке и количество пикселей вертикальной развертки.
       FF FF s s rr cc xp yp

Кроме флагов "ss" ничего не используется. В будущем могут появиться и другие для сообщений в целях управления.

[править] От сервера клиенту

Данные с сервера посылаются клиенту как поток символов. Обычные данные просто выводятся на клиентский дисплей, но могут быть обработанны перед этим (например, отступы).

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

  • 0x02 - клиент должен отменить все буферизированные данные, которые еще не были выведены на экран
  • 0x10 - клиент должен переключиться в режим "raw"
  • 0х20 - клиент должен возобновить перехват символов и обработку символов НАЧАЛО и КОНЕЦ.
  • 0х80 - клиент должен ответить серверу, послав данные о размере окна (см. выше↑)

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


[править] Завершение соединения

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


[править] Безопасность

rlogin имеет несколько значительных недостатков в системе безопасности:

  • Вся информация, включая пароли, передаются без шифрования (перехват данных дал бы полный контроль над жертвой)
  • Легко воспользоваться файлом .rlogin (или .rhosts) в корыстных целях (открывается доступ к аккаунту anyone, у которого нет пароля) - по этой причине множество корпоративных системных администраторов запрещают .rlogin файлы и активно ищут правонарушителей в их сетях
  • Протокол частично доверяет клиенту rlogin удаленной машины, предоставляя ему информацию честно (включая порт и имя хоста). Таким образом, злоумышленник может воспользоваться этим и получить доступ, в силу того, что этот протокол никак не подразделяет удаленные хосты на зоны доверия
  • Общая практика монтирования домашних директорий пользователей через NFS (Network File System) подвергает rlogin атаковать путем подделывания файлов .rhosts - это означает, что единственной защитой в этом случае является безопасность самой NFS.

[править] Замены

Оригинальный Berkley пакет, который предоставляет rlogin возможности rcp(remote-copy (удаленное копирование), которые позволяют копировать файлы по сети) и rsh(remote-shell, позволяющие выполнять команды на удаленных машинах без входа в систему пользователя).

Пакет ssh заменяет вышеописанные возможности и сам rlogin: scp заменяет rcp, сама ssh заменяет rlogin и rsh.

[править] Используемая литература

[править] См. также


Источник — «http://ru.wikipedia.org/wiki/Rlogin»