Rlogin

Протокол RLOGIN ( англ. Remote LOGIN - Віддалений вхід в систему) - протокол прикладного рівня (сьома рівень моделі OSI), частина стека TCP / IP. Дозволяє користувачам UNIX підключатися до систем UNIX на інших машинах і працювати так само, як при прямому підключенні терміналу до машини. Цей протокол забезпечує такий же сервіс, як протокол TELNET.


1. Принцип роботи протоколу Rlogin

1.1. Установка зв'язку

Після установки з'єднання, клієнт посилає серверу 4 безлічі символів, що закінчуються нулями (вистава рядки в З -подібних мовах):

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

Наприклад:

  bostic  kbostic  vt100/9600  

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


1.2. Від клієнта серверу (і керування потоком)

Спочатку клієнт починає операцію в режимі "cooked" (протилежному режиму "raw"). У цьому режимі символи ПОЧАТОК і КІНЕЦЬ (зазвичай ASCII DC1, DC3) приймаються клієнтом і інтерпретуються як початок і кінець виведення з сервера на локальний термінал, в той час як інші символи передаються на віддалений хост в тому вигляді, в якому вони були отримані. (Дивись нижче обробку локальних Escape-символів).

У режимі "raw", символи ПОЧАТОК і КІНЕЦЬ не обробляються локально, а надсилаються віддаленому серверу як будь-який інший символ. Таким чином в режимі "raw" сервер визначає семантику символів ПОЧАТОК і КІНЕЦЬ; вони можуть бути використані для потокового управління або мати зовсім інші значення, ніяк не залежать від їх первісного використання на клієнті.


1.3. Розмір екрану (вікна)

Віддалений сервер подає сигнал клієнтові, що він готовий приймати інформацію про зміну поточних розмірів вікна у вигляді повідомлень відразу після установки з'єднання та ідентифікації користувача. На цей запит клієнт повинен відповісти сполученням з поточним розміром вікна.

Якщо вище описана операція пройшла успішно, то як тільки на клієнтській стороні міняються розмірності екрану або вікна, спеціальна 12-бітова послідовність (там зберігається інформація про нові розміри) надсилається віддаленого сервера, далі клієнтський процес, запущений на сервері, повинен потрібним чином обробити цю інформацію .

Керуюча послідовність зміни розміру вікна має довжину в 12 байт, складається з:

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

Крім прапорів "ss" нічого не використовується. У майбутньому можуть з'явитися й інші для повідомлень в цілях управління.


1.4. Від сервера клієнтові

Дані з сервера надсилаються клієнту як потік символів. Звичайні дані просто виводяться на клієнтський дисплей, але можуть бути оброблені перед цим (наприклад, відступи).

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

  • 0x02 - клієнт повинен скасувати всі буферізірованний дані, які ще не були виведені на екран
  • 0x10 - клієнт повинен перемкнутися в режим "raw"
  • 0х20 - клієнт повинен відновити перехоплення символів і обробку символів ПОЧАТОК і КІНЕЦЬ.
  • 0х80 - клієнт повинен відповісти серверу, пославши дані про розмір вікна (див. вище ↑)

Всі інші значення керуючого байта ігноруються. У всіх випадках керуючий байт НЕ виводиться на екран користувача.


1.5. Завершення з'єднання

Коли TCP -з'єднання закривається в будь-якому з напрямків, інший кінець повинен помітити це і провести закриття зі свого боку, відновивши режими терміналів і повідомивши користувача або процеси обриву з'єднання.

2. Безпека

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

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

3. Заміни

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

Пакет ssh замінює вищеописані можливості і сам rlogin: scp замінює rcp, сама ssh замінює rlogin і rsh.

Література


Перегляд цього шаблону Основні протоколи TCP / IP за рівнями моделі OSI ( Список портів TCP і UDP)
Фізичний
Канальний
Мережевий
Транспортний
Сеансовий
Уявлення
Прикладної

BGP HTTP HTTPS DHCP IRC SNMP Над DNS DNSSEC NNTP XMPP SIP IPP NTP SNTP Електронна пошта ( SMTP POP3 IMAP 4) Передача файлів ( FTP TFTP SFTP) Віддалений доступ (rlogin Telnet SSH RDP)

Інші прикладні