Чому для пасивного режиму FTP потрібен діапазон портів, а не лише один порт?

Я намагаюся зрозуміти, чому всі FTP-сервери вимагають використання діапазону портів для каналів даних пасивного режиму, на відміну від використання лише одного порту даних для всіх вхідних каналів даних.

FTP-сервери обробляють багато одночасно підключених клієнтів на порт 21. Веб-сервери обробляють багато одночасно підключених клієнтів на порт 80. І т.д.

Тоді чому FTP-сервер не може використовувати лише один порт каналу даних для всіх вхідних пасивних з'єднань даних (і все ще може працювати з багатьма одночасно підключеними клієнтами на цьому порту, скажімо, порт 1024)?

Або може?

Мені цікаво знати технічні деталі, чому це неможливо чи не рекомендується.

чітке та технічне пояснення щодо випуску декількох паралельних сеансів FTP при блокуванні порту даних лише на один порт - це те, що мені найбільше цікаво знати глибоко. Коли це може працювати, коли це не буде працювати, чому це може бути не рекомендовано тощо.

Це буде дикою здогадкою, оскільки я її ще не перевіряв, ви можете спробувати це на собі і побачити, чи є якісь інші проблеми, які я, можливо, пропустив.

Я припускаю, що ви можете обмежити діапазон пасивних портів одним портом . Насправді в цьому питанні ви бачите, що невеликі діапазони портів використовуються на практиці . Теоретично для підтримки декількох одночасних з'єднань вам потрібні лише 4 значення: локальний IP, локальний порт, віддалений IP, віддалений порт, щоб бути унікальним. Таким чином ви розрізняєте різні з'єднання.

Якщо ви заблокуєте порт на сервері до одного значення, то єдиною лівою змінною є порт, який використовується клієнтом. Це не є проблемою, якщо у клієнта є достатньо великий пул вільних ефемерних портів на вибір. Якщо це не робить важкий NAT, вам не доведеться турбуватися про це. Тепер, будьте попереджені, це буде суто теоретичний матеріал : якщо ви використовували кілька портів на своєму сервері, ви можете помножити кількість гіпотетичних одночасних з'єднань, включившиnumber of ports in rangeз'єднання на одному клієнтському порту. Але це не відбудеться на практиці, тому що я сумніваюся, що існує будь-яка реалізація клієнта FTP, який би підтримував це (тому що це не має великого сенсу). Плюс якщо клієнт повинен поділитися своїми ефемерними портами таким чином і не може просто відкрити новий, то у нього виникають набагато більш серйозні проблеми. Отже, з цього погляду ви повинні бути повністю безпечними, використовуючи один порт.

Давайте подумаємо, чому одного порту може бути недостатньо .

Перш за все, я міг зіткнутися з ситуацією, коли реально помилкова реалізація FTP-сервера використовує виключно локальний номер порту як спосіб ідентифікації передачі даних клієнта. Ще раз, я не думаю, що будь-який пристойний FTPd зробив би це.

Справжня проблема ( так, ви можете проігнорувати все вище як головне відступлення ;-)) в тому, що діапазон пасивних портів знаходиться в непривілейованому діапазоні .

Це означає, що вибраний номер порту сам по собі не зарезервований , і насправді будь-який користувацький процес (не потребує привілеїв root ) може захопити його до того, як це зробить ваш FTP-сервер. Якщо у вас є велика кількість портів для вибору, ви просто захопите випадковий безкоштовний. Якщо ви зобов'язані використовувати єдиний, і він уже використовується, ви не зможете належним чином обробити передачі.

Вибачте, якщо відповідь здається трохи надто спекулятивним. Якщо чесно, я дуже намагався знайти причину, чому ви не повинні використовувати один порт, і, крім останнього шматочка, я не міг придумати жодних важких доказів проти цього. Тим не менш, цікаве та складне питання, яке ви ставите.

FTP покладається на два окремих підключення, одне для потоку управління або команд і одне для передачі файлів даних та іншої інформації, наприклад списків каталогів. Контрольний потік здійснюється через традиційне TCP-з'єднання. Клієнт прив'язується до високого непривілейованого порту і надсилає запит на з'єднання на FTP-сервер, який прив’язаний до порту 21. Це з'єднання використовується для передачі команд.

У портовому або активному режимі клієнт повідомляє серверу, який вторинний, непривілейований порт він буде слухати. Потім сервер ініціює з'єднання даних з порту 20 до непривілейованого порту, який вказав клієнт.

Пасивний режим, новіший механізм, є типовим, коли клієнтом є веб-браузер. Замість того, щоб прив'язуватися до порту 20, сервер повідомляє клієнту, який високий порт використовувати для передачі даних. Потім дані передаються через непривілейовані порти між клієнтом і сервером.

Для отримання детальної інформації див.

http://tools.ietf.org/html/rfc959

EDIT

Щодо блокування сервера на певному одному порту, можливо, це можливо на деяких серверах. Наприклад, у vsftpd у вас є такі параметри конфігурації.

   pasv_max_port
          The maximum port to allocate for PASV style data connections. Can be used to specify a narrow port range to assist firewalling.

          Default: 0 (use any port)

   pasv_min_port
          The minimum port to allocate for PASV style data connections. Can be used to specify a narrow port range to assist firewalling.

          Default: 0 (use any port)

Якщо встановити обидва порти на однакові, наприклад pasv_max_port = 12345, pasv_min_port = 12345, можливо, ви зможете отримати те, що вам потрібно. Я підозрюю, що це обмежить кількість паралельних сеансів FTP, які підтримує ваш сервер. Будьте перевірені, щоб бути впевненим.

FTP-сервер може мати змогу співставити підключення клієнтського порту даних до їх підключення до порту керування лише на основі вихідного IP-адреси, а не на основі використовуваного номера порту.

Це призведе до порушення FXP (що може бути не поганим), коли клієнт підключається до двох серверів (один у пасивному режимі), а потім після отримання інформації про PORT пасивного сервера передає його на сервер активного режиму як команду PORT, так що активний сервер режимів підключається до сервера пасивного режиму.

Я підозрюю, що багато серверів не створюють сокет даних, поки клієнт не вимагає пасивного режиму. У цьому випадку, якщо два клієнти одночасно запитували пасивний режим, для створених сокетів знадобляться унікальні номери портів.

EDIT : придумав ще одну причину, чому FTP-сервери цього не роблять: сервер не міг повідомити декількох користувачів з однаковою IP-адресою.

На портах 21 або 80 (як і у всіх добре відомих портів) є встановлений протокол, який клієнт використовує, щоб сказати, що він хоче. Таким чином сервер знає, для чого ви підключаєтесь. На порту з'єднання даних немає протоколу. Все, що знає сервер - єдине, що є унікальним щодо цього з'єднання - це номер порту, до якого ви підключаєтесь.

Якби ви підключалися до одного і того ж порту кожного разу, сервер не міг би сказати, до якого файлу ви підключаєтесь. Номер порту служить ланкою між запитом на передачу на з'єднанні управління та з'єднанням даних.

Якщо два клієнта одночасно вимагали перенесення, коли сервер приймає з'єднання на одному порту, сервер не зможе сказати, який файл передавати. Звичайно, сервер міг використовувати клієнтський IP для прийняття рішення (насправді багато FTP-сервери підтверджують, що клієнтський IP-відповідність відповідає IP, використовуваному для з'єднання управління).

Але це не допоможе:

• Кілька підключень від однієї машини (більшість FTP-клієнтів підтримують паралельні передачі / черги).
• Підключення з різних машин у межах однієї (корпоративної) мережі, оскільки ті, що мають однаковий зовнішній IP.

Дивіться також повторне використання FTP-з'єднань даних .

Я не бачив цього згадуваного тут, тому я закину його. Присвоєння діапазону портів повинно було бути своєрідною функцією захисту, де ви не могли відстежувати один порт за трафіком даних, дані надсилалися на випадковий порт у дальність, яку неможливо було легко визначити. Безпека через незрозумілість.

Здається, ви вже знаєте про порти керування та порти даних, тому я вирішу право на погоню. Порти управління - це природна комунікація, як і порт 80 для веб-сайтів. вони можуть обробляти безліч різних запитів (не одночасно, але закриваються, оскільки їх так швидко виконати). Порти даних, з іншого боку, - це те, де відбувається магія з FTP. Якщо ви обмежитеся одним портом даних, одночасно відбувається лише одна передача даних. розгляньте велику передачу файлів. Якщо один порт даних відкритий, жодна інша інформація не може переміщуватися до завершення передачі. Це означає, що під час передачі другий користувач навіть не зможе перерахувати вміст каталогу папки ftp. Впевнені, що вони зможуть успішно увійти, але їх поведінка буде такою ж, як якщо б порти даних взагалі не були відкритими. Якщо з цим все гаразд, один порт буде чудово працювати для вас. Майте на увазі, що деякі клієнти ftp (я можу подумати про 1 біт), за замовчуванням встановили декілька з'єднань протягом одного сеансу для завантаження. Тож для цього клієнта в сценарії одного порту розглянемо пакетну передачу 1 великого файлу та 4 малих файлів.

Клієнт ініціює передачу для першого великого файлу, всі файли. Потім, поки ця передача триває, він запускає другий файл. Без кісток. Потім третій, теж пшик (технічний термін). Зрештою, журнал повинен відображати 1 успішний і 4 невдалі передачі. Робота може полягати в тому, щоб обмежити клієнта одним з'єднанням за сеанс, і ви б хотіли піти (якщо припустити, що хтось інший не ступив ногою у двері в саму мікросекунду, одна передача завершена, а інша ще не розпочалася. )