TFTP

TFTP (англ. Trivial File Transfer Protocol — тривіальний протокол передачі файлів) — простий, покроково синхронізований протокол передачі файлів, який дозволяє клієнтам зчитувати або записувати файли сервера. Одним із основних використань протоколу є первинне завантаження бездискових робочих станцій у локальній мережі. Найчастіше TFTP використовується саме через простоту його реалізації. Протокол працює поверх протоколу UDP.

TFTP уперше було стандартизовано у 1981 році[1], поточний стандарт протоколу RFC 1350.

Застосування

Протокол TFTP створений з розрахунку на невеликий розмір і простоту реалізації. Через це він позбавлений більшості можливостей, які мають більш серйозні протоколи на кшталт FTP. Єдине, на що здатний цей протокол — це записувати та зчитувати файли на сервер та з нього. Він не може виводити список файлів та наразі не підтримує автентифікацію.[2]

Основне призначення TFTP — забезпечення простоти реалізації клієнта. У зв'язку з цим він використовується для завантаження бездискових робочих станцій, завантаження оновлень і конфігурацій в «розумні» мережеві пристрої, записи статистики з міні-АТС (CDR) та апаратних маршрутизаторів / файрволів.

Деякі приклади використання, коли треба мати сервер для встановлення по мережі операційної системи, для запуску з PXE серверу різноманітних LiveCD (Hiren's BootCD, Linux Mint, ) та окремих діагностичних застосунків, таких як перевірка пам'яті Memtest86+, Memtest86, Goldmemory test, перевірка накопичувачів Victoria, MHDD.

Безпека

TFTP, на відміну від FTP, не містить можливостей аутентифікації і єдиний метод ідентифікації клієнта — це його мережева адреса (яка може бути підробленою). Зазвичай в Unix-системах TFTPD доступний тільки каталог / TFTPboot. Проте в старих TFTP-серверах було можливим отримати файл паролів командою RRQ ../[…]/шлях_до_файлу_паролів. Це було використано багатьма хакерами, щоб отримати копії файлу паролів з Unix і потім розшифрувати паролі. Щоб запобігти подібному, більшість сучасних TFTP-серверів регламентують, які файли можуть бути отримані з використанням TFTP (як правило, файли з директорії /tftpboot в Unix системах). Ця директорія містить тільки завантажувальні файли, необхідні бездисковим системам.

Демон TFTPD (одна з реалізацій TFTP-сервера) відмовляється обробляти файли, що містять в своєму імені комбінацію «/../» або починається з «../». Запис дозволяється тільки у файли, які вже існують (будь-якого розміру, наприклад нульового), і доступні для публічного запису (права доступу:-RW-RW-RW-).

Для додаткової безпеки TFTP-сервер на Unix-системах зазвичай встановлює свій користувацький ідентифікатор (UID) і ідентифікатор групи (GID) у значення, які не можуть бути призначені реальному користувачеві. Це забезпечує доступ тільки до файлів, які доступні для читання і запису всім.

Формат п'ятьох видів TFTP повідомлень

Процес передачі даних

У TFTP існує 3 режими передачі: netascii, octet і mail:

  1. Netascii є модифікованою формою ASCII, визначений у RFC 764. Вона складається з 8-бітного розширення 7-бітних ASCII-символів з кодами від 0x20 до 0x7F (друкованих символів і пробілу) і восьми керуючих символів. Допустимі керуючі символи включають нуль-символ (код 0x00), новий рядок (LF, код 0x0A) і повернення каретки (CR, код 0x0D). Netascii також вимагає, щоб маркер кінця рядка був замінений на пари символів CR LF для передачі, і щоб за кожним символом CR слідував або символ LF, або нуль-символ.[2]
  2. Octet використовується для передачі довільних необроблених 8-бітних байтів, причому отриманий файл в результаті побайтово ідентичний посланому.
  3. Режим передачі mail використовує передачу netascii, але файл відправляється одержувачу електронною поштою на адресу, яка вказується замість імені файлу. RFC 1350 визначає цей режим передачі застарілим і таким, що не повинен бути реалізованим.

Кожен TFTP-пакет належить до одного із 5 типів:

  • Read Request (RRQ, #1) — запит на читання файлу.
  • Write Request (WRQ, #2) — запит на запис файлу.
  • Data (DATA, #3) — дані, передані через TFTP.
  • Acknowledgment (ACK, #4) — підтвердження пакета.
  • Error (ERR, #5) — помилка.

Для початку передачі даних клієнт повинен послати серверу WRQ або RRQ-пакет. В обох пакетів формат однаковий:

0x01/0x02 (тип пакета)Ім'я файла0x00 (кінець рядка)Режим передачі0x00 (кінець рядка)Опції… (якщо є)
2 байтарядок в ASCII1 байтрядок в ASCII1 байтДив. «Опції TFTP»
(W1) Клієнт A надсилає запит на запис
(W2) Сервер S підтверджує запит
(W3) Клієнт A надсилає пронумеровані пакети даних
(R1) Клієнт A посилає запит на читання
(R2) Сервер S надсилає дані пакету 1
(R3) Клієнт A підтверджує прийом пакету 1

Після отримання RRQ-пакета сервером, він відразу починає передачу даних. У випадку з WRQ-запитом — сервер має надіслати ACK-пакет із номером пакета 0. Пакет надсилається із динамічного порту сервера, усе подальше спілкування з сервером відбувається через цей порт.

Сторона-відравник файла надсилає пронумеровані пакети даних (DATA) сталого розміру (за замовчуванням це 512 байт), а сторона-отримувач надсилає відповідні підтвердження (ACK). Якщо пакет даних або підтвердження було втрачено, то через певний час (таймаут) сторона, яка не отримала очікуваного пакета, повторно надсилає останній надісланий нею пакет. Така схема дозволяє тримати в пам'яті тільки останній надісланий пакет, у той час як підтвердження протилежної сторони гарантує, що всі попередні пакети було отримано і вони прийняті саме в тому порядку, в якому були надіслані. Така схема передбачає, що кожна зі сторін є і відправником, і одержувачем. Одна сторона надсилає дані й отримує підтвердження, інша — отримує дані й відправляє підтвердження.

Останній пакет даних має розмір менше 512 байт. Якщо розмір файлу кратний 512, то останній пакет DATA повинен мати нульовий розмір.

Опції TFTP

У RFC 2347 був передбачений формат опцій, які можна приєднувати до закінчення RRQ-пакета і WRQ-пакету[3]:

Код опції0x00 (кінець рядка)Значенння опції0x00 (кінець рядка)
Рядок в ASCII1 байтрядок в ASCII1 байт

Опцій може бути декілька, тоді вони йдуть одна за одною, порядок опцій не важливий. У відповідь на RRQ (або WRQ) з опціями сервер повинен надіслати OACK з переліком можливостей, які сервер прийняв. Найбільш поширені опції:

НазваВизначення вКод опціїОзначення
Розмір блокаRFC 2348blksizeЧисло від 8 до 65464 — розмір блоку.
Інтервал повторної передачіRFC 2348timeoutЧисло від 1 до 255 — час очікування перед повторним надсиланням блоку в секундах.
Розмір файлаRFC 2348tsizeРозмір файлу, що передається, у байтах.

Документація IETF

Номер RFC Заголовок Опубліковано Автор Інформація про оновлення та застаріння
RFC 783 The TFTP Protocol (Revision 1) Червень 1981 K. Sollins Визнаний застарілим у RFC 1350
RFC 906 Bootstrap Loading using TFTP Червень 1984 Ross Finlayson -
RFC 951 Bootstrap Protocol Вересень 1985 Bill Croft Оновлено в RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC 5494
RFC 1350 The TFTP Protocol (Revision 2) Липень 1992 K. Sollins Оновлено в RFC 1782, RFC 1783, RFC 1784, RFC 1785, RFC 2347, RFC 2348, RFC 2349
RFC 1782 TFTP Option Extension Березень 1995 G. Malkin Визнаний застарілим у RFC 2347
RFC 2131 Dynamic Host Configuration Protocol Березень 1997 R. Droms Оновлено в RFC 3396, RFC 4361, RFC 5494, RFC 6842
RFC 2347 TFTP Option Extension Травень 1998 G. Malkin -
RFC 2348 TFTP Blocksize Option Травень 1998 G. Malkin -
RFC 2349 TFTP Timeout Interval and Transfer Size Options Травень 1998 G. Malkin -
RFC 7440 TFTP Windowsize Option Січень 2015 P. Masotta -

Примітки

  1. Sollins, K.R. TFTP Protocol (revision 2). tools.ietf.org. Процитовано 26 квітня 2016.
  2. Sollins, K. The TFTP Protocol (Revision 2). tools.ietf.org. Процитовано 26 квітня 2016.
  3. Art, Harkin,; Scott, Malkin, Gary. TFTP Option Extension. tools.ietf.org. Процитовано 26 квітня 2016.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.