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 існує 3 режими передачі: netascii, octet і mail:
- Netascii є модифікованою формою ASCII, визначений у RFC 764. Вона складається з 8-бітного розширення 7-бітних ASCII-символів з кодами від 0x20 до 0x7F (друкованих символів і пробілу) і восьми керуючих символів. Допустимі керуючі символи включають нуль-символ (код 0x00), новий рядок (LF, код 0x0A) і повернення каретки (CR, код 0x0D). Netascii також вимагає, щоб маркер кінця рядка був замінений на пари символів CR LF для передачі, і щоб за кожним символом CR слідував або символ LF, або нуль-символ.[2]
- Octet використовується для передачі довільних необроблених 8-бітних байтів, причому отриманий файл в результаті побайтово ідентичний посланому.
- Режим передачі 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» |
Після отримання 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 | - |
Примітки ред.
- ↑ Sollins, K.R. TFTP Protocol (revision 2). tools.ietf.org. Архів оригіналу за 19 березня 2016. Процитовано 26 квітня 2016.
- ↑ а б Sollins, K. The TFTP Protocol (Revision 2). tools.ietf.org. Архів оригіналу за 16 квітня 2016. Процитовано 26 квітня 2016.
- ↑ Art, Harkin,; Scott, Malkin, Gary. TFTP Option Extension. tools.ietf.org. Архів оригіналу за 16 березня 2014. Процитовано 26 квітня 2016.