TFTP

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

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

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

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

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

Деякі приклади використання, коли треба мати сервер для встановлення по мережі операційної системи, для запуску з PXE серверу різноманітних LiveCD (Hiren's BootCD [Архівовано 25 лютого 2021 у Wayback Machine.], Linux Mint, ) та окремих діагностичних застосунків, таких як перевірка пам'яті Memtest86+ [Архівовано 23 лютого 2021 у Wayback Machine.], Memtest86 [Архівовано 23 лютого 2021 у Wayback Machine.], Goldmemory test [Архівовано 12 лютого 2021 у Wayback Machine.], перевірка накопичувачів Victoria [Архівовано 21 січня 2021 у Wayback Machine.], MHDD [Архівовано 31 березня 2022 у Wayback Machine.].

Безпека

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 байта	рядок в ASCII	1 байт	рядок в ASCII	1 байт	Див. «Опції 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 (кінець рядка)
Рядок в ASCII	1 байт	рядок в ASCII	1 байт

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

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

Документація 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	-