Bdtyk

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

См. также |

• Telnet

Литература |

• 
  RFC 1282 — BSD Rlogin


• Stevens, W., «UNIX Network Programming», ISBN 0-13-949876-1.


• Garfinkel & Spafford, «Practical Unix Security», ISBN 0-937175-72-2.

Для улучшения этой статьи желательно: Викифицировать список литературы.