FTP Проксі

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

Розуміння режимів FTP-з'єднання

Протокол передачі файлів (FTP) використовує два окремі з'єднання для кожної сесії:
1. Керуюче з'єднання (Control Connection): Постійне з'єднання, встановлене на TCP-порті 21 (за замовчуванням) для надсилання команд (наприклад, USER, PASS, LIST, GET, PUT) та отримання відповідей.
2. З'єднання для даних (Data Connection): Тимчасове з'єднання, що використовується для фактичної передачі даних файлів або списків каталогів. Встановлення цього з'єднання залежить від режиму FTP.

Активний режим FTP (Active Mode FTP)

В активному режимі FTP-клієнт ініціює керуюче з'єднання до сервера. Коли запитується передача даних, клієнт надсилає команду PORT серверу, вказуючи IP-адресу та номер порту, на якому він буде прослуховувати з'єднання для даних. Потім FTP-сервер ініціює з'єднання для даних назад до вказаної IP-адреси та порту клієнта зі свого власного TCP-порту 20 (за замовчуванням).

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

Клієнт (Порт X) --------> Сервер (Порт 21) [Керуюче з'єднання]
Клієнт (Порт Y) <-------- Сервер (Порт 20) [З'єднання для даних - Заблоковано брандмауером]

Пасивний режим FTP (Passive Mode FTP)

У пасивному режимі FTP-клієнт ініціює як керуюче з'єднання, так і з'єднання для даних. Після встановлення керуючого з'єднання клієнт надсилає команду PASV серверу. Сервер відповідає IP-адресою та номером порту, на якому він буде прослуховувати з'єднання для даних. Потім клієнт ініціює з'єднання для даних до вказаної IP-адреси та порту сервера.

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

Клієнт (Порт X) --------> Сервер (Порт 21) [Керуюче з'єднання]
Клієнт (Порт Y) --------> Сервер (Порт Z)  [З'єднання для даних]

Як працює FTP-проксі

FTP-проксі-сервер працює, перехоплюючи FTP-трафік та керуючи складнощами як керуючих, так і даних з'єднань від імені клієнта. Це має вирішальне значення для середовищ зі суворими політиками брандмауера, NAT або для впровадження безпеки та ведення журналів.

Проксі діє як шлюз прикладного рівня (ALG), розуміючи команди та відповіді протоколу FTP.

1. Клієнт підключається до проксі: FTP-клієнт налаштований на підключення до FTP-проксі-сервера замість прямого підключення до FTP-сервера.
2. Проксі підключається до FTP-сервера: Проксі встановлює керуюче з'єднання до фактичного FTP-сервера від імені клієнта.
3. Перехоплення та модифікація команд:
   • Активний режим (команда PORT): Коли клієнт надсилає команду PORT, він надає свою власну IP-адресу та порт. Проксі перехоплює це, замінює IP-адресу та порт клієнта на власну IP-адресу та доступний порт, а потім пересилає модифіковану команду PORT до FTP-сервера. Потім проксі прослуховує вказаний порт. Коли FTP-сервер ініціює з'єднання для даних до проксі, проксі отримує його та пересилає дані клієнту.
   • Пасивний режим (команда PASV): Коли клієнт надсилає команду PASV, FTP-сервер відповідає своєю IP-адресою та портом для з'єднання для даних. Проксі перехоплює цю відповідь, замінює IP-адресу та порт сервера на власну публічну IP-адресу та доступний порт, а потім пересилає модифіковану відповідь клієнту. Потім клієнт ініціює з'єднання для даних до проксі, який, у свою чергу, встановлює з'єднання для даних до FTP-сервера та ретранслює дані.

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

Типи FTP-проксі

SOCKS-проксі

SOCKS (Socket Secure) проксі — це проксі загального призначення, який працює на рівні 5 (сесійний рівень) моделі OSI. Він пересилає TCP-з'єднання від клієнта до цільового сервера. Хоча SOCKS може проксіювати керуюче FTP-з'єднання, він не є протоколо-орієнтованим і не може інтерпретувати FTP-команди. Це означає, що він не може безпосередньо обробляти динамічне виділення портів для з'єднань для даних ні в активному, ні в пасивному режимах FTP.

• SOCKS5 для FTP: SOCKS5-проксі може полегшити початкове керуюче з'єднання. Для з'єднання для даних FTP-клієнт повинен бути явно налаштований на використання SOCKS-проксі для обох з'єднань (керуючого та для даних), а SOCKS-проксі повинен дозволяти необхідні вихідні з'єднання. SOCKS5-проксі часто краще працюють з пасивним режимом FTP, якщо клієнт може бути налаштований на тунелювання обох з'єднань через SOCKS.

Шлюз прикладного рівня (ALG) / Виділений FTP-проксі

Шлюз прикладного рівня (ALG) або виділений FTP-проксі є протоколо-орієнтованим. Він розуміє нюанси протоколу FTP, включаючи команди PORT та PASV. Це дозволяє йому динамічно переписувати IP-адреси та номери портів у керуючому каналі FTP для ефективного керування встановленням з'єднання для даних. Брандмауери часто включають FTP ALG, щоб дозволити FTP-трафіку проходити через них без складного ручного перенаправлення портів.

Прозорий FTP-проксі

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

Переваги використання FTP-проксі

• Проходження брандмауера: Дозволяє FTP-клієнтам за брандмауерами або пристроями NAT підключатися до зовнішніх FTP-серверів і навпаки, опосередковуючи узгодження з'єднання для даних.
• Безпека:
  • Анонімність: Приховує фактичну IP-адресу клієнта від FTP-сервера.
  • Контроль доступу: Централізоване керування тим, хто може отримати доступ до яких FTP-серверів або ресурсів.
  • Перевірка вмісту: Деякі розширені проксі можуть перевіряти передані файли на наявність шкідливого програмного забезпечення або порушень політики (хоча це менш поширено для базових FTP-проксі).
• Проходження мережевої трансляції адрес (NAT): Вирішує проблеми, коли FTP-команди містять немаршрутизовані приватні IP-адреси.
• Ведення журналів та аудит: Централізоване ведення журналів усіх FTP-сесій, включаючи видані команди та передані файли, для аудиту безпеки та відповідності вимогам.
• Кешування: Деякі проксі можуть кешувати часто доступні файли, покращуючи продуктивність для подальших запитів (менш поширено для традиційних FTP-проксі, але можливо).

Виклики та міркування

• Накладні витрати на продуктивність: Проксі вводить додатковий стрибок і рівень обробки, потенційно збільшуючи затримку та зменшуючи пропускну здатність порівняно з прямим з'єднанням.
• Складність конфігурації: Налаштування та підтримка FTP-проксі, особливо для складних мережевих топологій, може бути заплутаним.
• Проблеми сумісності: Нестандартні FTP-клієнти або сервери, або ті, що використовують нестандартні діапазони портів, можуть зіткнутися з проблемами, якщо ALG проксі недостатньо надійний.
• FTPS (FTP через SSL/TLS):
  • Явний FTPS (Explicit FTPS): Керуюче з'єднання починається незахищеним, а потім оновлюється до TLS за допомогою AUTH TLS або AUTH SSL. З'єднання для даних також шифрується. FTP-проксі або ALG повинен розуміти та завершувати TLS-сесію (діючи як Man-in-the-Middle) для перевірки та переписування команд. Це вимагає, щоб проксі мав сертифікат сервера або видавав власний, якому клієнти повинні довіряти.
  • Неявний FTPS (Implicit FTPS): Вся FTP-сесія (керуюча та для даних) шифрується з самого початку, зазвичай на порту 990. FTP-проксі не може перевіряти або модифікувати команди керуючого каналу, оскільки вони зашифровані. У цьому сценарії проксі діє як простий TCP-тунель, втрачаючи свій інтелект прикладного рівня. Часто для неявного FTPS використовується SOCKS-проксі або просте перенаправлення порту.
• Споживання ресурсів: Виділені FTP-проксі можуть споживати значні ресурси ЦП та пам'яті, особливо при великому обсязі одночасних з'єднань або великих передачах файлів.

Приклади конфігурації на стороні клієнта

Більшість FTP-клієнтів підтримують конфігурацію проксі. Це зазвичай включає вказівку IP-адреси та порту проксі-сервера.

Використання змінних середовища (для клієнтів командного рядка, таких як ftp або wget):

export ftp_proxy="http://proxy.example.com:8080"
export FTP_PROXY="http://proxy.example.com:8080"
# Для SOCKS-проксі
export all_proxy="socks5://proxy.example.com:1080"

Специфічні налаштування клієнта (концептуальні):

• FileZilla (GUI-клієнт): Редагування > Налаштування > З'єднання > FTP-проксі. Тут можна вибрати тип проксі (SOCKS5, HTTP 1.1, Користувацький).
• lftp (клієнт командного рядка):
  set ftp:proxy-host proxy.example.com set ftp:proxy-port 8080

Конфігурація проксі-сервера (концептуальна)

Виділені FTP-проксі або брандмауери з можливостями FTP ALG автоматично обробляють специфіку протоколу. Для проксі загального призначення, таких як Squid, можуть знадобитися специфічні конфігурації, хоча Squid в основному діє як HTTP/HTTPS-проксі та має обмежені прямі можливості FTP ALG, окрім базового тунелювання.

Приклад FTP ALG у брандмауері (концептуальний синтаксис):

firewall {
    rule 1 {
        action accept
        source any
        destination any
        service ftp
        application-gateway ftp
    }
}

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

Порівняння: SOCKS-проксі проти виділеного FTP-проксі