Tftp простий протокол передачі даних
Глава 15 TFTP: простий протокол передачі даних
TFTP - це простий протокол передачі файлів. Він, як правило, використовується при завантаженні бездискових систем (робочі станції або X термінали). На відміну від протоколу передачі файлів (FTP - File Transfer Protocol), який ми опишемо в главі 27 і який використовує TCP, TFTP використовує UDP. Це зроблено для того, щоб протокол був якомога простіше і менше. Реалізації TFTP (і необхідного UDP, IP і драйвера пристрою) можуть поміститися в постійній пам'яті (ПЗУ).
Обмін між клієнтом і сервером починається з того, що клієнт запитує сервер або прочитати, або записати файл для клієнта. У стандартному варіанті завантаження бездисковой системи перший запит - це запит на читання (RRQ). На малюнку 15.1 показаний формат п'яти повідомлень TFTP. (Коди операцій 1 і 2 мають однаковий формат.)
Перші 2 байта TFTP повідомлення це код операції (opcode). У запиті на читання (RRQ) і в запиті на запис (WRQ) ім'я файлу (filename) вказує файл на сервері, який клієнт хоче або вважати, або записати. Ми спеціально показали на малюнку 15.1, що це ім'я файлу закінчується нульовим байтом. Режим (mode) це ASCII рядок: netascii або octet (будь-яка комбінація великих або маленьких букв), яка також закінчується байтом 0. netascii означає, що дані є рядками ASCII тексту, причому кожний рядок закінчується 2-символьного послідовністю повернення каретки, за якою слідує пропуск рядка (позначається - CR / LF).
Малюнок 15.1 Формат п'яти TFTP повідомлень.
І клієнт і сервер повинні мати можливість здійснити перетворення між цим форматом і будь-яким іншим (інший роздільник рядків), який використовується на локальному хості. Передача octet позначає, що дані будуть передаватися у вигляді 8-бітних байтів без інтерпретації.
У разі запиту на запис (WRQ) клієнт посилає WRQ, вказуючи ім'я файлу і режим. Якщо файл може бути записаний клієнтом, сервер відповідає підтвердженням (ACK) з номером блоку рівним 0. Клієнт посилає перші 512 байт файлу з номером блоку рівним 1, сервер відповідає ACK з номером блоку рівним 1.
Цей тип передачі даних називається протоколом із зупинкою і очікуванням підтвердження (stop-and-wait). Він використовується тільки в простих протоколах, таких як TFTP. Ми побачимо в розділі "Зміна розміру вікна" глави 20, що TCP надає іншу форму підтверджень, яка дозволяє домогтися більш високої пропускної здатності. TFTP розроблений таким чином, щоб реалізація була якомога простіше, а не для того щоб підвищити пропускну здатність.
Останній тип TFTP повідомлень це повідомлення про помилки, код операції (opcode) дорівнює 5. Це якраз те, чим сервер відповідає в тому випадку, якщо запит на читання або запис не може бути оброблений. Помилки читання або запису в перебігу передачі файлу також призводять до того, що відправляється повідомлення про помилку, при цьому передача припиняється. Номер помилки (error number) містить цифровий код помилки, за яким слід повідомлення про помилку в ASCII форматі, яке може містити додаткову інформацію надану операційною системою.
Давайте подивимося, як працює протокол TFTP. Ми запустимо TFTP клієнта на хості bsdi і отримаємо текстовий файл з хоста svr4:
bsdi% tftp svr4 стартуємо TFTP клієнта
tftp> get test1.c отримуємо файл з сервера
Received 962 bytes in 0.3 seconds
tftp> quit розриваємо з'єднання
bsdi% ls -l test1.c скільки байт в отриманому файлі?
-rw-r - r-- 1 rstevens staff 914 Mar 20 11:41 test1.c
bsdi% wc -l test1.c і скільки рядків?
48 test1.c
Перший момент, який впадає в очі, полягає в тому, що файл в Unix містить 914 байт, проте TFTP передає 962 байта. Скориставшись програмою wc, ми побачимо, що в файлі 48 рядків, таким чином, 48 символів нового рядка в Unix були доповнені до 48 пар CR / LF, так як TFTP за замовчуванням здійснює передачу в режимі netascii.
На малюнку 15.2 показаний обмін пакетами.
1 0.0 bsdi.1106> svr4.tftp: 19 RRQ "test1.c"
2 0.287080 (0.2871) svr4.1077> bsdi.1106: udp 516
3 0.291178 (0.0041) bsdi.1106> svr4.1077: udp 4
4 0.299446 (0.0083) svr4.1077> bsdi.1106: udp 454
5 0.312320 (0.0129) bsdi.1106> svr4.1077: udp 4
Малюнок 15.2 Обмін пакетами в разі TFTP.
У рядку 1 показаний запит на читання від клієнта до сервера. Порт призначення UDP для TFTP - заздалегідь відомий порт 69, tcpdump переглядає TFTP пакети і друкує RRQ і ім'я файлу. Довжина UDP даних друкується як 19 байт і отримують у такий спосіб: 2 байта - код операції, 7 байт - ім'я файлу, 1 байт рівний 0, 8 байт для netascii і ще 1 байт рівний 0.
Наступний пакет приходить від сервера (рядок 2) і містить 516 байт: 2 байта - код операції, 2 байта - номер блоку і 512 байт даних. Рядок 3 - підтвердження на ці дані: 2 байта - код операції і 2 байта - номер блоку.
І останній пакет даних (рядок 4) містить 450 байт даних. 512 байт даних в рядку 2 і ці 450 байт складають 962 байта даних, отримані клієнтом.
Зверніть увагу, що tcpdump Не друкує додаткову інформацію про протокол TFTP для рядків 2 - 5, як він це зробив, інтерпретувавши TFTP повідомлення в рядку 1. Це відбувається тому, що номер порту сервера змінився між рядками 1 і 2. Протокол TFTP вимагає, щоб клієнт відправив перший пакет (RRQ або WRQ) на заздалегідь відомий порт UDP сервера (69). Сервер знаходить будь-якої невикористаний динамічно призначається порт (тисяча сімдесят-сім на малюнку 15.2), який потім використовується сервером для подальшого обміну пакетами між клієнтом і сервером. Номер порту клієнта (1106 в даному прикладі) не змінюється. tcpdump не має уявлення про те, що порт 1077 на хості svr4 використовується TFTP сервером.
Причина, по якій змінюється номер порту сервера, полягає в тому, що сервер не повинен захоплювати заздалегідь відомий порт на великий проміжок часу, необхідний на передачу файлу (що може зайняти від декількох секунд до декількох хвилин). Замість цього, заздалегідь відомий порт залишається доступним для інших TFTP клієнтів, які можуть послати туди свій запит. Тоді як в цей час передача здійснюється через інший порт.
Звернемося до малюнка 10.6. RIP сервер, з яким необхідно надіслати клієнту більш ніж 512 байт, відправляє обидві UDP датаграми з заздалегідь відомого порту сервера. У разі TFTP (через відмінності в протоколі), довготривалого взаємодії між клієнтом і сервером не провадиться (яке, як ми сказали, може займати від секунд до хвилин). Якщо один процес сервера буде використовувати заздалегідь відомий порт весь час, поки здійснюється передача файлу, виникне необхідність відмовити всім наступним запитам, які прийдуть від інших клієнтів, або один процес сервера повинен мати можливість здійснювати множинну передачу файлів кільком клієнтам в один і той же час з одного і того ж порту (69). Найпростіше рішення полягає в тому, що сервер переходить на інший порт, після того як отримав RRQ або WRQ. Клієнт визначає новий порт, коли він отримує перший пакет даних (рядок 2 на малюнку 15.2), а потім посилати всі наступні підтвердження (рядки 3 і 5) на новий порт.
У розділі "Приклад" глави 16 ми побачимо, як TFTP використовується при завантаженні X терміналів.
Зверніть увагу на те, що TFTP пакети (рисунок 15.1) не містять ніяких даних про ім'я користувача або пароль. Це пролом в секретності характерна для TFTP. Так як TFTP був розроблений для використання в процесі завантаження, він не надає можливості передати ім'я користувача і пароль.
Ця характеристика TFTP була використана багатьма хакерами, щоб отримати копії файлу паролів з Unix і потім розшифрувати паролі. Щоб запобігти подібному доступ, більшість TFTP серверів в даний час регламентують, які файли можуть бути отримані з використанням TFTP (як правило, файли з директорії / tftpboot в Unix системах). Ця директорія містить тільки завантажувальні файли, необхідні бездисковий системам.
Для додаткової безпеки TFTP сервер, на Unix системі, зазвичай встановлює свій користувальницький ідентифікатор (UID) і ідентифікатор групи (GID) в значення, які не можуть бути призначені реальному користувачеві. Це дозволяє доступ тільки до файлів, які доступні для читання і запису всім.
TFTP - це простий протокол, розроблений таким чином, щоб поміщатися в ПЗУ і бути використаним тільки в процесі завантаження бездискових систем. Він використовує невелику кількість форматів повідомлень і протокол із зупинкою і очікуванням підтвердження.
Щоб дозволити кільком клієнтам завантажуватися одночасно, TFTP сервер надає кілька форм одночасної роботи. Так як UDP не надає унікального з'єднання між клієнтом і сервером (як це робить TCP), TFTP сервер створює новий UDP порт для кожного клієнта. Це дозволяє різним клієнтам видавати датаграми, які будуть демультіплексіровать UDP модулем сервера, на основі номерів портів призначення, замість того щоб це робив сам сервер.
Протокол TFTP не надає засоби безпеки. Більшість реалізацій дозволяє доступ по протоколу TFTP тільки до файлів, які необхідні при завантаженні.
У розділі 27 ми розглянемо протокол передачі файлів (FTP - File Transfer Protocol), який розроблений для загальних цілей, а також забезпечує високу пропускну здатність при передачі файлів.