Протокол RLOGIN (англ. Remote LOGIN — удалённый вход в систему) — протокол прикладного уровня (7-й уровень модели OSI), часть стека TCP/IP. Позволяет пользователям UNIX подключаться к системам UNIX на других машинах и работать так же, как при прямом подключении терминала к машине.
Принцип работы протокола Rlogin
[править | править код]Установка связи
[править | править код]После установки соединения клиент посылает серверу 4 множества символов, заканчивающиеся нулями (представление строки в С-подобных языках):
- пустая строка (состоит из одного нулевого байта),
- имя пользователя клиента,
- имя пользователя сервера,
- тип терминала и скорость.
Например:
<null> bostic<null> kbostic<null> vt100/9600<null>
Сервер возвращает нулевой байт в подтверждение того, что он получил отправленные клиентом данные и теперь находится в режиме передачи данных.
От клиента серверу (и управление потоком)
[править | править код]Сначала клиент начинает операцию в режиме «cooked» (противоположном режиму «raw»). В этом режиме символы НАЧАЛО и КОНЕЦ (обычно ASCII DC1, DC3) принимаются клиентом и интерпретируются как начало и конец вывода с сервера на локальный терминал, в то время как остальные символы передаются на удалённый хост в том виде, в котором они были получены (см. ниже обработку локальных Escape-символов).
В режиме «raw», символы НАЧАЛО и КОНЕЦ не обрабатываются локально, а посылаются удаленному серверу как любой другой символ. Таким образом в режиме «raw» сервер определяет семантику символов НАЧАЛО и КОНЕЦ; они могут быть использованы для потокового управления или иметь совсем другие значения, никак не зависящие от их первоначального использования на клиенте.
Размер экрана (окна)
[править | править код]Удалённый сервер подает сигнал клиенту, что он готов принимать информацию об изменении текущих размеров окна в виде сообщений сразу после установки соединения и идентификации пользователя. На этот запрос клиент должен ответить сообщением с текущим размером окна.
Если выше описанная операция прошла успешно, то как только на клиентской стороне меняются размерности экрана или окна, специальная 12-битовая последовательность (там хранится информация о новых размерах) посылается удаленному серверу, далее клиентский процесс, запущенный на сервере, должен нужным образом обработать эту информацию.
Управляющая последовательность изменения размера окна имеет длину в 12 байт, состоит из:
- magic cookie (2х последовательных байтов 0xFF),
- после которых следует 2 байта, содержащие символ «s» (ASCII, нижний регистр),
- затем 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.
См. также
[править | править код]Литература
[править | править код]- RFC 1282 — BSD Rlogin
- Stevens, W., «UNIX Network Programming», ISBN 0-13-949876-1.
- Garfinkel & Spafford, «Practical Unix Security», ISBN 0-937175-72-2.
| Физический | |
|---|---|
| Канальный | |
| Сетевой | |
| Транспортный | |
| Сеансовый | |
| Представления | |
| Прикладной | |
| Другие прикладные | |
