Література
Hughes L Internet e-mail Protocols, Standards and Implementation. — Artech House Publishers, 1998. — ISBN 0-89006-939-5
Johnson K Internet Email Protocols: A Developer's Guide. — Addison-Wesley Professional, 2000. — ISBN 0-201-43288-9
Loshin P Essential Email Standards: RFCs and Protocols Made Practical. — John Wiley & Sons, 1999. — ISBN 0-471-34597-0
Rhoton J Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. — Elsevier, 1999. — ISBN 1-55558-212-5
Wood D Programming Internet Mail. — O'Reilly, 1999. — ISBN 1-56592-479-7
Тема 11. Обмін файлами у мережах. Протокол ftp
Задачі протоколів обміну файлами
Найбільш часто використовуваної функцією комунікаційного програмного забезпечення є функція передачі файлів. Вона здійснюється за допомогою спеціальних протоколів передачі файлів. Вибір та використання протоколу передачі файлів може проводиться користувачем в явному вигляді, як це робиться в термінальних програмах, так і в неявному, наприклад в ігрових програмах, що підтримують модемний зв'язок.
Основними завданнями протоколів передачі файлів є:
забезпечення безпомилкової передачі даних;
управління потоком переданих даних;
передача допоміжної інформації;
захист з'єднання.
Перші протоколи передачі файлів з'явилися задовго до модемів, що підтримують апаратне виправлення помилок. З цієї причини завдання забезпечення безпомилкової передачі по сьогоднішній день залишається однією з їх основних. Для її реалізації застосовуються в основному ті ж методи, що і в сучасних протоколах виправлення помилок. Передані дані розбиваються на блоки (кадри) певної довжини, і в кожний з них включається перевірочна комбінація (CRC) для виявлення помилок. Ця комбінація формується за певним правилом на основі переданих інформаційних бітів блоку. На приймальній стороні проводиться повторне обчислення перевірочної комбінації по тому ж правилу і порівняння її з прийнятою. При збігу перевірочних комбінацій приймаюча сторона посилає підтвердження правильного прийому блоку (АСК), а при розбіжності – запит на повторну передачу даного блоку (NACK). Таким чином реалізується механізм автоматичного запиту повторення (ARQ), аналогічний механізму ARQ в протоколах виправлення помилок типу MNP класів 1-4 і V.42. При цьому ARQ також може бути Стартостопні типу (SAW), з поверненням на N кроків (GBN) або селективного повторення (SR).
При використанні ARQ типів GBN і SR безперервна передача непідтверджених блоків даних може призвести до перевантаження буферів як приймача, так і передавача. Що б цього не відбувалося використовується управління потоком переданих даних.
Перед безпосередньою передачею файлу необхідно встановити з'єднання на рівні каналу даних (рівень 2 моделі OSI), передати інформацію про імені файлу, його розмір, датою останньої його модифікації і т.п., а після передачі – справити роз'єднання каналу даних. Все це здійснюється за допомогою допоміжної службової інформації, переданої по каналу зв'язку.
В останні роки у функції протоколів передачі файлів включають захист з'єднання, наприклад перевірку пароля.
Серед протоколів, розрахованих на відсутність апаратного захисту від помилок можна виділити широко поширені протоколи XModem, XModem-CRC, XModem-1 К, YModem, Kermit, ZModem і ряд інших.
Якщо ж застосовуються модеми з апаратною корекцією помилок (підтримують протоколи типу MNP або V.42), то краще використовувати протоколи передачі файлів типу YModem-g і ZModem. У цьому випадку виключається втрата часу на повторний запит даних, переданих з помилками. Протокол Zmodem допускає обидва варіанти застосування.
Відомі спеціалізовані протоколи, призначені для певних служб і мереж, - такі як SEALink, Telnet, CompuServe Quick В. Практично всі вони є модифікаціями протоколу XModem.
Протокол FTP
FTP (англ. File Transfer Protocol – протокол передачі файлів) – це ще один широко використовуваний додаток. Він є стандартом Інтернет для передачі файлів. Необхідно розрізняти передачу файлів, саме те, що надає FTP, і доступ до файлів, що надається такими додатками як NFS (Network File System). Передача файлів полягає в копіюванні цілого файлу з однієї системи в іншу. Щоб використовувати FTP, необхідно мати відкритий бюджет на сервері, або можна скористатися так званим анонімним FTP (anonymous FTP).
Як і Telnet, FTP був створений для того, щоб працювати між хостами працюють під управлінням різних операційних систем, що використовують різні структури файлів і, можливо, різні набори символів. Telnet, проте, забезпечує зв'язок між різнорідними системами, змушуючи кожного учасника з'єднання працювати з одним і тим же стандартом: NVT, що використовує 7-бітний ASCII. FTP згладжує відмінності між системами з використанням іншого підходу. FTP підтримує обмежену кількість типів файлів (ASCII, двійкове і так далі) і структуру файлів (потік байтів або орієнтований на запис).
RFC 959 [Postel and Reynolds 1985] є офіційною специфікацією FTP. Цей RFC описує історію та розвиток передачі файлів протягом часу.
FTP відрізняється від інших програм тим, що він використовує два TCP з'єднання для передачі файлу.
Керуюче з'єднання встановлюється як звичайне з'єднання клієнт-сервер. Сервер здійснює пасивне відкриття на заздалегідь відомий порт FTP (21) і очікує запиту на з'єднання від клієнта. Клієнт здійснює активне відкриття на TCP порт 21, щоб встановити керуюче з'єднання. Керуюче з'єднання існує весь час, поки клієнт спілкується з сервером. Це з'єднання використовується для передачі команд від клієнта до сервера і для передачі відповідей від сервера. Тип IP сервісу для керуючого з'єднання встановлюється для отримання "мінімальної затримки", так як команди зазвичай вводяться користувачем.
З'єднання даних відкривається щоразу, коли здійснюється передача файлу між клієнтом і сервером. (Воно також відкривається і в інші моменти, як ми побачимо пізніше). Тип сервісу IP для з'єднання даних повинен бути "максимальна пропускна здатність", так як це з'єднання використовується для передачі файлів.
На русунку 11.1 показано спілкування клієнта і сервера за двома з'єднанням.
Рисунок
11.1 – Процеси, що залучені до передачі
файлів
З рисунка видно, що інтерактивний користувач зазвичай не бачить команди і відгуки, які передаються по керуючому з'єднанню. Ці деталі залишені двом інтерпретаторам протоколу. Квадратик, позначений як "користувальницький інтерфейс", це саме те, що бачить інтерактивний користувач (повноекранний інтерфейс, заснований на меню, командні рядки і так далі). Інтерфейс конвертує введення користувача в FTP команди, які вирушають по керуючому з'єднанню. Відгуки, повертаються сервером по керуючому з'єднанню, конвертуються у формат, зручний для користувача.
Зверніть увагу на те, що існують два інтерпретатора протоколу, які за необхідності використовують дві функції передачі даних.
Протокол FTP надає різні способи управління передачею і зберігання файлів. Необхідно зробити вибір за чотирма пунктами.
Тип файлу.
ASCII файли. (За замовчуванням) Текстовий файл передається по з'єднанню даних як NVT ASCII. При цьому потрібно, щоб відправник конвертував локальний текстовий файл у NVT ASCII, а одержувач конвертував NVT ASCII в текстовий файл. Кінець кожного рядка передається у вигляді NVT ASCII символу повернення каретки, після чого слід переклад рядка. Це означає, що одержувач повинен переглядати кожен байт в пошуках пари символів CR, LF.
EBCDIC файли. Альтернативний спосіб передачі текстових файлів, коли на обох кінцях системи EBCDIC.
Двійкові або бінарні файли (Image). Дані передаються як безперервний потік бітів.
Локальний тип файлів. Спосіб передачі бінарних файлів між хостами, які мають різний розмір байта. Кількість бітів в байті визначається відправником. Для систем, які використовують 8-бітові байти, локальний тип файлу з розміром байта рівним 8 еквівалентний бінарним типом файлу.
Управління форматом. Застосовується тільки для ASCII і EBCDIC файлів.
Nonprint. (За замовчуванням) Файл не містить інформацію вертикального формату.
Telnet format control. Файл містить керуючі символи вертикального формату Telnet, які інтерпретуються принтером.
Fortran carriage control. Перший символ кожного рядка це Fortran символ управління формату.
Структура.
Структура файлу. (За замовчуванням) Файл сприймається у вигляді безперервного потоку байтів. Файл не має внутрішньої структури.
Структура запису. Ця структура використовується тільки у випадку текстових файлів (ASCII або EBCDIC).
Структура сторінки. Кожна сторінка передається з номером сторінки, що дозволяє одержувачеві зберігати сторінки у випадковому порядку. Надається операційною системою TOPS-20. (Вимога до хостів Host Requirements RFC не рекомендує використовувати цю структуру).
Режим передачі. Вказує на те, як файл передається по з'єднанню даних.
Режим потоку. (За замовчуванням) Файл передається як потік байтів. Для файлової структури кінець файлу вказує на те, що відправник закриває з'єднання даних. Для структури запису спеціальна 2-байтовая послідовність позначає кінець запису і кінець файлу.
Режим блоків. Файл передається як послідовність блоків, перед кожним з них стоїть один або кілька байт заголовків.
Стиснутий режим. Просте кодування неодноразово зустрічаються повторюваних байт. У текстових файлах зазвичай стискаються порожні рядки або рядки з прогалин, а в бінарних рядки з нульових байт. (Цей режим підтримується рідко. Існують більш оптимальні способи стиснення файлів для FTP.)
Якщо порахувати кількість комбінацій з наведених варіантів, то вийде 72 способу передачі і зберігання файлу. На щастя, можна ігнорувати багато з цих опцій, тому що вони не підтримуються в більшості реалізацій.
Найпоширеніші Unix реалізації FTP клієнта і сервера надають наступний вибір:
Тип: ASCII або двійковий.
Управління форматом: тільки nonprint.
Структура: тільки файлова структура.
Режим передачі: тільки потоковий режим.
Це обмежує нас одним з двох режимів: ASCII або двійковий.
Подібна реалізація відповідає мінімальним вимогам до хостів Host Requirements RFC. (RFC також вимагає забезпечити підтримку для структури запису, проте тільки якщо операційна система підтримує це, а Unix, як правило, не підтримує).
Більшість не-Unix реалізацій надає FTP можливості, які дозволяють обробляти їх власні формати файлів. Вимога до хостів Host Requirements RFC каже: "Протокол FTP включає безліч характеристик, деякі з яких поширені не дуже широко. Однак, для кожної характеристики в FTP існує щонайменше одна реалізація".
Способи керування передачею і зберіганням файлів
Використовувати з'єднання даних можна трьома способами:
відправка файлів від клієнта до сервера;
відправка файлів від сервера до клієнта;
відправка списку файлів або директорій від сервера до клієнта.
FTP сервер посилає список файлів по з'єднанню даних, замість того щоб посилати багатострокові відгуки по керуючому з'єднанню. При цьому з'являється можливість уникнути будь-яких обмежень у рядках, накладаються на розмір списку директорії, і дозволяє просто зберегти список директорії у файлі, замість того щоб видавати список на термінал.
Ми сказали, що керуюче з'єднання залишається в активізованому стані весь час, поки встановлено з'єднання клієнт-сервер, проте з'єднання даних може вимикатися і включатися з потреби. Як вибираються номери портів для з'єднання даних, і хто здійснює активне відкриття, а хто пасивне відкриття?
По-перше, як було сказано раніше, поширений режим передачі (у разі Unix це єдиний режим передачі) – це потоковий режим. У цьому режимі кінець файлу позначає закриття з'єднання даних. З цього випливає, що для передачі кожного файлу або списку директорії потрібно нове з'єднання даних. Звичайна процедура виглядає наступним чином:
Створення з'єднання даних здійснюється клієнтом, тому що саме клієнт видає команди, які вимагають передати дані (отримати файл, передати файл або список директорії).
Клієнт зазвичай вибирає динамічно призначається номер порту на хості клієнта для свого кінця з'єднання даних. Клієнт здійснює пасивне відкриття з цього порту.
Клієнт посилає цей номер порту на сервер по керуючому з'єднанню з використанням команди PORT.
Сервер приймає номер порту з керуючого з'єднання і здійснює активне відкриття на цей порт хоста клієнта. Сервер завжди використовує порт 20 для з'єднання даних.
На рисунку 11.2 показано стан з'єднань, поки здійснюється крок номер 3. Ми припускаємо, що динамічно призначається порт клієнта для керуючого з'єднання має номер 1173, а динамічно призначається порт клієнта для з'єднання даних має номер 1174. Команда, що посилається клієнтом – PORT, а її аргументи це шість десяткових цифр у форматі ASCII, розділені комами. Чотири перші числа - це IP адреса клієнта, на який сервер повинен здійснити активне відкриття (140.252.13.34 в даному прикладі), а наступні два – це 16-бітний номер порту. Так як 16-бітний номер порту формується з двох чисел, його значення в цьому прикладі буде 4 x 256 + 150 = 1174.
На рисунку 11.3 показано стан з'єднань, коли сервер здійснює активне відкриття на кінець клієнта з'єднання даних. Кінцева точка сервера це порт 20.
Рисунок 11.2 – Команда PORT, передана по керуючому з'єднанню FTP
Рисунок 11.3 – FTP сервер здійснює активне відкриття з'єднання даних
Сервер завжди здійснює активне відкриття з'єднання даних. Зазвичай сервер також здійснює активну закриття з'єднання даних, за винятком тих випадків, коли клієнт відправляє файл на сервер в потоковому режимі, який вимагає, щоб клієнт закрив з'єднання (що робиться за допомогою повідомлення сервера про кінець файлу).
Якщо клієнт не видає команду PORT, сервер здійснює активне відкриття на той же самий номер порту, який використовувався клієнтом для керуючого з'єднання (1173 в даному прикладі). У цьому випадку все працює коректно, так як номер порту сервера для двох сполук різні: один 20, інший 21. Тим не менш, в наступному розділі ми подивимося, чому сучасні реалізації не надходять таким чином.
Пасивний і активний режими роботи FTP-сервера
На відміну від більшості інших протоколів, при роботі з протоколом FTP створюється два типи з'єднань, перше служить для аутентифікації і передачі команд, друге – для передачі даних. За другим з'єднанню визначається режим роботи, він може бути активним, а може бути пасивним. Відрізняються вони між собою стороною виступає ініціатором підключення для передачі даних і портами, на яких ця передача власне проводитись. При нормальному або активному FTP, керуюче з'єднання ініціюється з боку клієнта, а підключення для передачі даних ініціюється з боку сервера. У пасивному режимі, як керуюче з'єднання так і з'єднання для передачі даних ініціюється клієнтом.
Активний режим FTP
Під час активного режиму (див. рисунок 11.4), на клієнті створюється непривілейований тимчасовий порт N>1023 – для керуючого з'єднання і N+1 порт для передачі даних.
Клієнт з тимчасового порту X посилає SYN запит на 21 порт сервера.
Сервер з 21 порту відповідає SYN ACK на тимчасовий порт X клієнта.
Клієнт підтверджує створення з'єднання відправкою ACK прапора.
Клієнт відправляє команду PORT, для переходу в активний режим, вказує IP адреса клієнта для передачі (найчастіше свій) і клієнтський порт Y, з яким власне і буде створено з'єднання для передачі даних.
Режим підтверджується з боку сервера.
Передача команд для роботи з FTP, таких як список каталогів, ініціації передачі або прийому інформації, видалення файлу і інші. (Нижче наведено список FTP команд).
Для створення з'єднання для передачі даних, сервер з 20 порту відправляє SYN запит клієнта на тимчасовий порт Y, яка була вказана, разом з командою PORT.
Клієнт відповідає SYN ACK.
Сервер підтверджує створення з'єднання – передачею прапора ACK.
Відбувається передача даних.
Якщо треба закрити з'єднання, то після 10 кроку, клієнт відправляє прапор FIN (нижче наведено список прапорів), сервер його підтверджує і з'єднання закривається.
Рисунок 11.4 – Робота FTP в активному режимі
Пасивний режим FTP
У пасивному режимі (див. рисунок 11.5) перші три кроки такі ж, як і в активному.
Клієнт з тимчасового порту X посилає SYN запит на 21 порт сервера.
Сервер з 21 порту відповідає SYN ACK на тимчасовий порт 1024 клієнта.
Клієнт підтверджує створення з'єднання відправкою ACK прапора.
Клієнт відправляє команду PASV, для переходу в пасивний режим.
Сервер підтверджує перехід у пасивний режим, відправляє PASV ACK, свій IP адреса і тимчасовий порт Z, для передачі даних.
Клієнт з порту Y відправляє SYN запит на створення з'єднання на серверний порт Z, який був зазначений, разом з підтвердженням PASV ACK.
Сервер підтверджує створення з'єднання SYN ACK.
Клієнт створює з'єднання і відправляє прапор ACK.
Передача команд для роботи з FTP, таких як список каталогів, ініціація передачі або прийому даних і інші. (нижче наведено список FTP команд).
Відбувається передача даних.
Рисунок 11.5 – Робота FTP в пасивному режимі
Набір доступних команд
Команди і відгуки передаються по керуючому з'єднанню між клієнтом і сервером у форматі NVT ASCII. У кінці кожного рядка команди або відгуку присутня пара CR, LF.
Єдині команди Telnet (починаються з IAC), які можуть бути відправлені клієнтом серверу – це команда переривання процесу (<IAC, IP>) і Telnet сигнал синхронізації (<IAC, DM> в режимі терміновості). Ми побачимо, що ці дві команди Telnet використовуються для припинення передачі файлу або для того, щоб відправити серверу запит у процесі передачі. Якщо сервер отримує від клієнта команду з Telnet опцією (WILL, WONT, DO або DONT), він відповідає або DONT, або WONT.
Команди складаються з 3 або 4 байт, а саме із заголовних ASCII символів, деякі з необов'язковими аргументами. Клієнт може відправити серверу більш ніж 30 різних FTP команд.
Нижче показані деякі найбільш широко використовувані команди:
ABOR - Перервати передачу файлу.
CDUP - Змінити директорію на вищестоящу.
CWD - Змінити директорію.
DELE - Видалити файл (DELE filename).
EPSV - Увійти в розширений пасивний режим. Застосовується замість PASV.
HELP - Виводить список команд прийнятих сервером.
LIST - Повертає список файлів директорії. Список передається через з'єднання даних.
MDTM - Повертає час модифікації файлу.
MKD - Створити директорію.
NLST - Повертає список файлів директорії в більш короткому форматі ніж LIST. Список передається через з'єднання даних.
NOOP - Пуста операція.
PASV - Увійти в пасивний режим. Сервер поверне адресу і порт до якого потрібно підключитися щоб забрати дані. Передача розпочнеться при введенні наступних команд RETR, LIST і тд.
PORT - Увійти в активний режим. Наприклад PORT 12,34,45,56,78,89. На відміну від пасивного режиму для передачі даних сервер сам підключається до клієнта.
PWD - Повертає поточну директорію.
QUIT - Від'єднатись.
REIN - Реініціалізувати підключення.
RETR - Завантажити файл. Перед RETR повинна бути команда PASV або PORT.
RMD - Видалити директорію.
RNFR і RNTO - Перейменувати файл. RNFR - що перейменовувати, RNTO - в що.
SIZE - Повертає розмір файлу.
STOR - Завантажити файл. Перед STOR повинна бути команда PASV або PORT.
SYST - Повертає тип системи (UNIX, WIN, ...).
TYPE - Встановити тип передачі файлу (Бінарний, текстовий).
USER - Рецензент для входу на сервер.
Прапори TCP (керуючі біти):
URG - Поле «Покажчик важливості» задіяне (англ. Urgent pointer field is significant).
ACK - Поле «Номер підтвердження» задіяне (англ. Acknowledgement field is significant).
PSH - (англ. Push function) інструктує одержувача проштовхнути дані, накопичені в приймальному буфері, у додаток користувача.
RST - Обірвати з'єднання, скинути буфер (очищення буфера) (англ. Reset the connection).
SYN - Синхронізація номерів послідовності (англ. Synchronize sequence numbers).
FIN (англ. final, біт) - прапор, будучи встановлений, вказує на завершення з'єднання (англ. FIN bit used for connection termination).
Відгуки складаються з 3-ціферний значень у форматі ASCII, і необов'язкових повідомлень, які слідують за числами. Подібне уявлення відгуків пояснюється тим, що програмному забезпеченню необхідно подивитися тільки цифрові значення, щоб зрозуміти, що відповів процес, а додатковий рядок може прочитати людина. Тому користувачеві досить просто прочитати повідомлення (причому немає необхідності запам'ятовувати всі цифрові коди відгуків).
Кожна з трьох цифр в коді відгуку має власний зміст. Нижче показані значення перших і других цифр в коді відгуку.
1yz - Позитивний попередній відгук. Дія почалася, однак необхідно дочекатися ще одного відгуку перед відправкою наступної команди.
2yz - Позитивний відгук про завершення. Може бути відправлена нова команда.
3yz - Позитивний проміжний відгук. Команда прийнята, проте необхідно відправити ще одну команду.
4yz - Тимчасовий негативний відгук про завершення. Необхідну дію не відбулося, проте помилка тимчасова, тому команду необхідно повторити пізніше.
5yz - Постійний негативний відгук про завершення. Команда не була сприйнята і повторювати її не варто.
x0z - Синтаксична помилка.
x1z - Інформація.
x2z - Злуки. Відгуки мають відношення або до керуючого, або до з'єднання даних.
x3z - Аутентифікація і бюджет. Відгук має відношення до логування або командам, пов'язаних з бюджетом.
x4z - Не визначено.
x5z - Стан файлової системи.
Третя цифра дає додаткове пояснення повідомленням про помилку. Нижче наведені деякі типові відгуки з можливими пояснюють рядками.
125 - З'єднання даних вже відкрито; початок передачі.
200 - Команда виконана.
214 - Повідомлення про допомогу (для користувача).
331 - Рецензент прийнято, необхідно отримати пароль.
425 - Неможливо відкрити з'єднання даних.
452 - Помилка запису файлу.
500 - Синтаксична помилка (невідома команда).
501 - Синтаксична помилка (невірні аргументи).
502 - Нереалізований тип MODE.
Зазвичай кожна FTP команда генерують відгук у один рядок. Наприклад, команда QUIT згенерує наступний відгук:
221 Goodbye.
Якщо необхідний відгук у кілька рядків, перший рядок містить дефіс замість пропусків після 3-ціферний коду відгуку, а останній рядок містить той же самий 3-ціферний код відгуку, за яким слід пробіл. Наприклад, команда HELP згенерує наступний відгук:
214- The following commands are recognized (* =>'s unimplemented).
USER PORT STOR MSAM* RNTO NLST MKD CDUP
PASS PASV APPE MRSQ* ABOR SITE XMKD XCUP
ACCT* TYPE MLFL* MRCP* DELE SYST RMD STOU
SMNT* STRU MAIL* ALLO CWD STAT XRMD SIZE
REIN* MODE MSND* REST XCWD HELP PWD MDTM
QUIT RETR MSOM* RNFR LIST NOOP XPWD
214 Direct comments to ftp-bugs@bsdi.tuc.noao.edu.
Авторизація і анонімний доступ
FTP-аутентифікація використовує звичайну схему ім'я користувача/пароль для надання доступу. Рецензент надсилається серверу командою USER, а пароль - командою PASS. Якщо надана клієнтом інформація прийнята сервером, то сервер відправить клієнту запрошення і починається сесія. Користувачі можуть, якщо сервер підтримує цю особливість, увійти в систему без надання облікових даних, але сервер може надати тільки обмежений доступ для таких сесій.
Хост, що забезпечує FTP-сервіс, може надати анонімний доступ до FTP. Користувачі зазвичай входять в систему як "anonymous" (може бути від регістру на деяких FTP-серверах) в якості імені користувача. Хоча зазвичай користувачів просять надіслати адресу їх електронної пошти замість пароля, ніякої перевірки фактично не проводиться. Багато FTP-хости, що мають оновлення програмного забезпечення, підтримують анонімний доступ.
Існує неймовірно популярна форма використання FTP. Вона називається анонімний FTP (anonymous FTP). Якщо ця форма підтримується сервером, вона дозволяє будь-якому отримати доступ до сервера і використовувати FTP для передачі файлів. За допомогою анонімного FTP можна отримати доступ до величезного обсягу вільно поширюваної інформації.
Тут виникає ще одна проблема, яка полягає в тому, що дуже складно знайти те, що потрібно в цьому морі інформації.
Скористаємося анонімним FTP, щоб отримати файл друкарських помилок для цієї книги з хоста ftp.uu. Щоб використовувати анонімний FTP, ми входимо в систему з ім'ям користувача "anonymous" (щоб вивчити, як пишеться це слово, спробуйте повторити його кілька разів). Коли з'являється запрошення ввести пароль, ми вводимо нашу адресу електронної пошти.
sun % ftp ftp.uu.net
Connected to ftp.uu.net.
220 ftp.UU.NET FTP server (Version 2.OWU(13) Fri Apr 9 20:44:32 EDT 1993) ready.
Name (ftp.uu.net:rstevens): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password: ми задаємо rstevens@noao.edu; це не відображається ехом
230-
230- Welcome to the UUNET archive.
230- A service of UUNET Technologies Inc, Falls Church, Virginia
230- For information about UUNET, call +1 703 204 8000, or see the files
230- in /uunet-info
строки вітання
230 Guest login ok, access restrictions apply.
ftp> cd published/books переходимо в потрібну директорію
250 CWD command successful.
ftp> binary будемо використовувати двійковий формат файлу
200 Type set to I.
ftp> get stevens.tcpipiv1.errata.Z отримуємо файл
200 PORT command successful.
150 Opening BINARY mode data connection for stevens.tcpipiv1.errata.Z (105 bytes).
226 Transfer complete. (у вас може бути інший розмір файлу)
local: stevens.tcpipiv1.errata.Z remote: stevens.tcpipiv1.errata.Z
105 bytes received in 4.1 seconds (0.83 Kbytes/s)
ftp> quit
221 Goodbye.
sun % uncompress stevens.tcpipiv1.errata.Z
sun % more stevens.tcpipiv1.errata
Програма uncompress використовується тому, що більшість файлів, доступних через анонімний FTP, стислі з використанням Unix програми compress, такі файли мають розширення .Z. Ці файли повинні бути передані у вигляді двійкових файлів, а не ASCII файлів.
Ми можемо об'єднати разом деякі характеристики маршрутизації та системи імен (Domain Name System) з використанням анонімного FTP. У попередніх темах ми говорили про запити покажчика в DNS - які сприймають IP адреси і повертають ім'я хоста. На жаль, не всі адміністратори систем коректно конфігурують свої DNS сервери таким чином, щоб вони відповідали на запити покажчиків. Вони часто додають нові хости до файлів, необхідним для встановлення відповідності ім'я-адресу, проте забувають додати їх у файли, що встановлюють відповідність адрес-ім'я. З цим можна зіткнутися, працюючи з програмою traceroute, коли вона видає IP адреси замість імен хостів.
Деякі анонімні FTP сервери вимагають, щоб клієнт мав коректне ім'я домену. Це дозволяє серверу зареєструвати домен і хоста, з який здійснено захід. Єдина інформація, яку може дізнатися сервер про клієнта з IP датаграми – це IP адреса клієнта. Сервер здійснює запит покажчика, щоб дізнатися доменне ім'я клієнта. Якщо DNS сервер, що відповідає за хост клієнта, що не налаштований коректно, запит покажчика не спрацює.
Давайте змоделюємо подібну помилку:
Змінимо IP адреса хоста slip на 140.252.13.67. Це нормальний IP адреса для нашої підмережі, проте його немає на DNS сервері домену noao.edu.
Змінимо IP адреса призначення SLIP каналу на bsdi на 140.252.13.67.
Додамо пункт в таблицю маршрутизації на sun, який буде направляти датаграми для 140.252.13.67 на маршрутизатор bsdi.
Хост slip доступний по Інтернет, тому що, як ми бачили в темі «Маршрутизація трафіку в ОС FreeBSD», маршрутизатори gateway і netb все ще посилають датаграми, які призначені в підмережа 140.252.13, на маршрутизатор sun. Наш маршрутизатор sun знає, що робити з цими датаграму, відповідно до пункту маршрутизації, який ми зробили в кроці номер 3. Таким чином, ми створили хост, який повністю підключений до Інтернет, однак не має коректного імені домену. Таким чином, запит покажчика для IP адреси 140.252.13.67 не працюватиме. А зараз скористаємося анонімним FTP на сервер, який, як ми знаємо, вимагає коректного імені домену.
slip % ftp ftp.uu.net
Connected to ftp.uu.net.
220 ftp.UU.NET FTP server (Version 2.OWU(13) Fri Apr 9 20:44:32 EDT 1993) ready.
Name (ftp.uu.net:rstevens): anonymous
530- Sorry, we're unable to map your IP address 140.252.13.67 to a hostname
530- in the DNS. This is probably because your nameserver does not have a
530- PTR record for your address in its tables, or because your reverse
530- nameservers are not registered. We refuse service to hosts whose
530- names we cannot resolve. If this is simply because your nameserver is
530- hard to reach or slow to respond then try again in a minute or so, and
530- perhaps our nameserver will have your hostname in its cache by then.
530- If not, try reaching us from a host that is in the DNS or have your
530- system administrator fix your servers.
530 User anonymous access denied.
Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quit
221 Goodbye.
(На жаль, ми не можемо знайти ім'я хоста, відповідне вашому IP адресою. Можливо, це тому, що у вашого сервера імен немає в таблиці PTR запису, що відповідає вашому адресою, або ваш сервер не зареєстрований. Ми не працюємо з хостами, для яких ми не можемо визначити ім'я домену. Якщо проблема в тому, що ваш DNS сервер повільно відповідає або до нього складно достукатися, спробуйте ще раз через хвилину. Може бути, на цей раз DNS сервер вже буде мати ваше ім'я у своєму кеші. Якщо справа не в цьому, спробуйте зайти до нас з хоста, який коректно зареєстрований в DNS, або попросіть адміністратора полагодити ваш сервер). Повідомлення про помилку говорить сама за себе.
Забезпечення безпечної передачі даних
FTP не розробляються як захищений (особливо за нинішніми мірками) протокол і має численні уразливості в захисті. У травні 1999 автори RFC 2577 звели уразливості в наступний список проблем:
Приховані атаки (bounce attacks).
Спуф-атаки (spoof attacks).
Атаки методом грубої сили (brute force attacks).
Перехоплення пакетів, сніффінг (packet capture, sniffing).
Захист імені користувача.
Захоплення портів (port stealing).
FTP не може зашифрувати свій трафік, всі передачі – відкритий текст, тому імена користувачів, паролі, команди і дані можуть бути прочитані ким завгодно, здатним перехопити пакет по мережі. Ця проблема характерна для багатьох специфікацій Інтернет-протоколу (у їх числі SMTP, Telnet, POP, IMAP), розроблених до створення таких механізмів шифрування, як TLS і SSL. Звичайне рішення цієї проблеми – використовувати "безпечні", TLS-захищені версії вразливих протоколів (FTPS для FTP, TelnetS для Telnet і т.д.) або ж інший, більш захищений протокол, начебто SFTP/SCP, що надається з більшістю реалізацій протоколу Secure Shell (SSH).
Існує кілька методів безпечної передачі файлів, в одне або інший час званих "Безпечним FTP".
FTPS
Явний FTPS - розширення стандарту FTP, що дозволяє клієнтам вимагати того, щоб FTP-сесія була зашифрована. Це реалізується відправленням команди "AUTH TLS". Сервер володіє можливістю дозволити або відхилити з'єднання, які не можуть звертатися TLS. Це розширення протоколу визначено в специфікації RFC 4217. Неявний FTPS – застарілий стандарт для FTP, що вимагає використання SSL-або TLS-з'єднання. Цей стандарт повинен був використовувати відмінні від звичайного FTP порти.
SFTP
SFTP, або "SSH File Transfer Protocol", не пов'язаний з FTP, за винятком того, що він теж передає файли і має аналогічний набір команд для користувачів. SFTP, або безпечний FTP, - це програма, що використовує SSH (Secure Shell) для передачі файлів. На відміну від стандартного FTP він шифрує і команди, і дані, оберігаючи паролі і конфіденційну інформацію від відкритої передачі через мережу. За функціональністю SFTP схожий на FTP, але так як він використовує інший протокол, клієнти стандартного FTP не можуть зв'язатися з SFTP-сервером і навпаки.
FTP через SSH (Не SFTP)
FTP через SSH (Не SFTP) відноситься до практики тунелювання звичайної FTP-сесії через SSH-з'єднання. Оскільки FTP використовує кілька TCP-з'єднань, тунелювання через SSH особливо скрутно. Коли багато SSH-клієнтів намагаються встановити тунель для каналу управління (початкове "клієнт-сервер" з'єднання по порту 21), захищений буде тільки цей канал; при передачі даних програмне забезпечення FTP на будь-якому кінці встановить нові TCP-з'єднання (канали даних), які обійдуть SSH-з'єднання і, таким чином, позбудуться цілісної захисту.
Інакше, для клієнтського програмного забезпечення SSH необхідно мати певні знання про FTP для відстеження та перезапису повідомлень потоку керування FTP і автономного відкриття нових перенаправлень для потоку даних FTP. Програмні пакети, що підтримують цей режим:
Tectia ConnectSecure (Win/Linux/Unix) з пакету SSH Communications Security.
Tectia Server for IBM z/OS з пакету SSH Communications Security.
FONC (під ліцензією GPL).
Co: Z FTPSSH Proxy.
FTP через SSH іноді відносять до безпечних FTP; але не варто плутати його з іншими методами, такими як SSL/TLS (FTPS). Інші методи передачі файлів за допомогою SSH і не пов'язані з FTP - SFTP і SCP; в кожному з них і облікові і файлові дані завжди захищені протоколом SSH.