TFTP

Протокол 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-пакет. В обох пакетів формат однаковий:

(W1) Клієнт A надсилає запит на запис

(W2) Сервер S підтверджує запит

(W3) Клієнт A надсилає пронумеровані пакети даних

(R1) Клієнт A посилає запит на читання

(R2) Сервер S надсилає дані пакету 1

(R3) Клієнт A підтверджує прийом пакету 1

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

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

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

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

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