Быстро установленный FTP-сервер ещё не готов для обмена корпоративными файлами. Нужны TLS, ограниченные папки, понятный диапазон data-портов и проверка реальной передачи. Ниже — пошаговая настройка FileZilla Server для Windows с explicit FTPS. Пример сначала работает в лабораторной сети, затем отдельно рассматривает NAT.
1. Выберите протокол и схему доступа
Как устроен обмен и почему один открытый порт не достаточен
Explicit FTPS начинает обычное управляющее TCP-соединение, затем клиент требует TLS через AUTH TLS. После аутентификации команды LIST/RETR/STOR создают отдельный data-канал. PASV возвращает адрес/порт, EPSV — порт с использованием адреса управляющего соединения. Клиент должен защитить и data-канал; работающий TLS только на control не подтверждает конфиденциальность файла.
Для лаборатории нужны Windows-сервер с отдельной NTFS-папкой, FileZilla Server, клиент с поддержкой explicit FTPS, DNS-имя и сертификат. Сначала выполняют LAN-передачу, затем проверяют отдельный NAT-сценарий. FTP-user — виртуальная учётная запись сервера; это не обязательно Windows-пользователь. NTFS проверяется от имени службы, после чего FileZilla дополнительно ограничивает mount points и разрешённые операции.
Перед установкой сохраните текущие firewall/listeners, убедитесь, что TCP 21 свободен, а путь D:\FTPS\partner-a новый и не содержит корпоративный share. На внешнем интерфейсе первоначально не открывают администрирование. Два партнёра получают разные аккаунты и native-каталоги, даже если оба видят виртуальный /.
FTP без TLS передаёт команды и данные без требуемой защиты канала. FTPS добавляет TLS к FTP, а SFTP работает поверх SSH и является другим протоколом. Обычный FileZilla Server обслуживает FTP/FTPS; возможности FileZilla Client и коммерческих серверных редакций не следует переносить на него автоматически.
Если требуется именно SFTP на одном SSH-порту, выбирайте соответствующий SFTP-сервер. Ниже настраивается explicit FTPS: клиент подключается к FTP listener TCP 21, затем требует TLS. Не путайте этот режим с implicit FTPS на другом listener.
Лабораторные значения: сервер 10.77.30.10, разрешённый клиент 10.77.30.20, имя files.lab.example, отдельный каталог D:\FTPS\partner-a, passive range 50000–50009. Все значения заменяются под вашу сеть. Административный интерфейс остаётся доступным только локально.
2. Установите сервер из официального источника
Загрузите именно FileZilla Server с официальной страницы. Выберите поддерживаемую текущим релизом Windows и разрядность. До запуска установщика проверьте происхождение файла и цифровую подпись:
$Installer = 'C:\Temp\FileZilla_Server_Installer.exe'
Get-AuthenticodeSignature -FilePath $Installer | Format-List Status,SignerCertificate
Get-FileHash -Path $Installer -Algorithm SHA256Путь заменяется реальным именем файла. Valid означает успешную проверку подписи, но личность издателя также сверяют с официальным происхождением. Локально вычисленный SHA256 без опубликованного эталона фиксирует файл, а не доказывает доверие ему.
Установите серверную службу и интерфейс управления по инструкции производителя. Задайте уникальный пароль администрирования. Не открывайте порт администрации для внешних пользователей FTP; административный и файловый listener выполняют разные функции.
Пройдите установщик и подтвердите службу
В официальном установщике выберите серверную службу и administration interface, автоматический старт службы только по принятой политике, адрес административного подключения loopback и отдельный пароль администрирования. Если установщик предлагает firewall-исключения, изучите их scope: wide allow для программы может сделать последующие узкие правила бессмысленными.
После завершения откройте Administration interface, подключитесь к локальному адресу/порту из установки и проверьте сертификат этого административного канала. Он отличается от сертификата FTP listener. Запишите фактическую версию через интерфейс/About и путь службы:
Get-CimInstance Win32_Service | Where-Object Name -Like '*filezilla*' |
Format-List Name,State,StartMode,StartName,PathName
Get-NetTCPConnection -State Listen | Where-Object LocalPort -In 21,14148 |
Select-Object LocalAddress,LocalPort,OwningProcess14148 — типичный административный порт, но используйте фактический выбор установки. Если служба Stop, смотрите Event Viewer и серверный журнал, затем доступ к config/certificate, а не нажимайте reinstall без backup. PathName может содержать параметры экземпляра: не смешивайте два server instance на одной машине.
3. Подготовьте папку и права Windows
Создайте отдельный каталог для партнёра, не публикуйте корень системного диска или общий корпоративный share. До настройки прав выясните, под какой Windows-учётной записью работает служба FileZilla Server:
Get-CimInstance Win32_Service | Where-Object Name -Like '*filezilla*' |
Select-Object Name,State,StartName,PathName
New-Item -ItemType Directory -Path 'D:\FTPS\partner-a' -Force
icacls 'D:\FTPS\partner-a'Не выдавайте Everyone Full Control. Файловая учётная запись FileZilla и Windows service identity — не обязательно одно лицо. Эффективный доступ ограничивается разрешениями сервера и NTFS. Если служба имеет широкие Windows-права, ограничение mount points становится особенно важным.
Для production выбирают отдельную сервисную идентичность с минимальными правами, если выбранная версия и способ установки её поддерживают. Перед сменой Log On проверяют доступ к config, сертификату и каталогам службы. Уменьшение прав без проверки может остановить сервер; «работает от LocalSystem» не является обоснованием раздавать все диски пользователям FTP.
Настройте NTFS для фактической service identity
Для новой лабораторной папки сохраните текущий ACL до изменений:
$Folder = 'D:\FTPS\partner-a'
New-Item -ItemType Directory -Path $Folder -Force
icacls $Folder /save 'C:\Temp\partner-a-acl-before.txt'
Get-Acl -LiteralPath $Folder | Format-List Owner,AccessToStringТочный путь проверяют перед изменением ACL. Каталог C:\Temp для ACL backup должен существовать и быть закрыт от обычных пользователей. Просмотрите StartName службы: если это LocalSystem, для отдельного нового каталога можно разрешить только SYSTEM и локальных администраторов:
icacls 'D:\FTPS\partner-a' /inheritance:r
icacls 'D:\FTPS\partner-a' /grant:r '*S-1-5-18:(OI)(CI)M' '*S-1-5-32-544:(OI)(CI)F'
icacls 'D:\FTPS\partner-a'SID избегают зависимости от языка названий SYSTEM/Administrators. M позволяет службе создавать/изменять/удалять, F администраторам — управлять каталогом. Это пример только для LocalSystem и нового лабораторного пути; он не меняет идентичность службы. Если StartName иной, предоставьте требуемые права именно подтверждённой идентичности. Не копируйте эту ACL-рецептуру на действующий share: удаление наследования может отозвать законные права.
Смена Log On на выделенный service account требует права log on as service и доступа к server config, журналам и private key. Выполняют её отдельной процедурой с проверкой запуска/возврата. UNC-path на файловом сервере добавляет share permissions и сетевые credentials; mapped drive буква из интерактивной сессии службы может быть невидима.
4. Настройте listener и сертификат
В Protocol settings → FTP and FTP over TLS настройте listener на нужном адресе и TCP 21 с требованием explicit FTP over TLS. Документация listeners поясняет режимы. Проверьте все IPv4/IPv6 listeners: лишний listener на всех адресах может расширить доступ помимо вашей схемы.
Для production используйте действующий сертификат доверенного УЦ с SAN, включающим files.example.org, и полной необходимой цепочкой. Имя клиента должно совпадать с сертификатом. Приватный ключ хранится только на сервере с ограниченным доступом и в защищённом backup, не копируется клиенту.
Для лаборатории допустим самоподписанный сертификат: управление connection security описывает генерацию и установку. Сверьте fingerprint через доверенный канал, затем подтвердите именно этот сертификат в тестовом клиенте. Случайное принятие любого предупреждения не является проверкой TLS.
Настройте explicit TLS шаг за шагом
В Server → Configure откройте Protocol settings → FTP and FTP over TLS, раздел listeners. Добавьте только нужный local address и порт 21, выберите обязательный explicit FTP over TLS. Не оставляйте параллельный listener, допускающий plaintext на том же доступном интерфейсе. В Connection Security установите сертификат и private key или сгенерируйте лабораторный self-signed средствами интерфейса.
Для trusted/internal CA проверьте SAN имени files.lab.example, даты, алгоритм, private key и chain. Публичный CA-файл можно передать клиенту, private key — нельзя. TLS minimum выбирают по поддержке утверждённых клиентов, не разрешая устаревшие SSL ради одного старого устройства. После Apply проверьте журнал и новый listener через Get-NetTCPConnection.
Self-signed certificate позволяет шифрование, но требует отдельного доверенного подтверждения fingerprint. Сертификат, автоматически показанный первым подключившимся сервером, не доказывает идентичность. Введите DNS-имя одинаково в серверном сертификате, клиентах и DNS. Сертификат для другого имени не исправляют вводом IP в URL.
5. Создайте пользователя и mount point
В Rights management → Users добавьте отдельного пользователя ftp-partner-a, включите его и выберите обязательную аутентификацию паролем. Пароль создают в корпоративном менеджере и передают разрешённым способом, не вписывают в команду или URL.
Добавьте mount point: virtual path /, native path D:\FTPS\partner-a. Пользователь увидит корень своей виртуальной файловой системы, а не весь диск D:. Описание mount points объясняет соответствие путей. Не задавайте native path на папку, содержащую данные других партнёров.
Начните с прав чтения и просмотра каталога. Разрешение записи, удаления и создания каталогов добавляйте только по задаче. Проверьте наследуемые группы пользователя: права из групп и явно заданные mount points влияют на результат. Публичный анонимный вход в этот пример не входит.
Создайте виртуальную файловую систему пользователя
Откройте Rights management → Users, добавьте ftp-partner-a, включите аккаунт и парольную аутентификацию. В Mount points добавьте virtual / и native D:\FTPS\partner-a, начните с Read Only. Сохраните, затем проверьте root listing клиентом. Пользователь должен видеть только содержимое partner-a, а не каталог FTPS с соседними партнёрами.
Read Only запрещает изменение; Read + Write предоставляет более широкий набор операций; Write Only рассчитан на загрузку без чтения/листинга. Флаги Writable directory structure и Apply permissions to subdirectories меняют область разрешения. Значения и наследование зависят от текущей версии интерфейса: проверьте фактический результат негативными тестами, не переносите старые checkbox-названия из FileZilla 0.9 в новую версию.
Не рассчитывайте, что virtual / автоматически запрещает всякий обход через nested mounts и Windows junction/reparse points. Папка обмена не должна содержать переходов к чужим данным. Дополнительные mount points и группы просматривают отдельно; это часть effective permissions. Запрет NTFS ограничивает серверное разрешение, а серверное Read Only не уменьшает фактические Windows-права службы.
6. Настройте passive data-порты и firewall
FTP использует управляющее соединение и отдельные data-соединения. Поэтому успешный вход на TCP 21 не означает, что каталог откроется. В Passive mode задайте Use custom port range: 50000–50009. Справка passive mode описывает этот диапазон.
На лабораторном Windows-сервере разрешите доступ только конкретному клиенту и адресу сервера:
New-NetFirewallRule -DisplayName 'AVG FTPS lab control' -Direction Inbound -Action Allow -Protocol TCP -LocalAddress '10.77.30.10' -LocalPort 21 -RemoteAddress '10.77.30.20' -Profile Any
New-NetFirewallRule -DisplayName 'AVG FTPS lab data' -Direction Inbound -Action Allow -Protocol TCP -LocalAddress '10.77.30.10' -LocalPort '50000-50009' -RemoteAddress '10.77.30.20' -Profile Any
Get-NetFirewallRule -DisplayName 'AVG FTPS lab*' | Get-NetFirewallPortFilterProfile Any здесь сочетается с точными локальным и удалённым адресами, а не открывает службу всем сетям. Проверьте существующие разрешающие правила установщика: новый узкий allow не отменяет старый широкий allow. Их корректировку выполняют после анализа effective policy. Десять портов — лабораторный выбор, ёмкость диапазона согласуют с параллельными передачами.
Зафиксируйте passive range и проверьте эффективный firewall
В Protocol settings → FTP and FTP over TLS → Passive mode задайте custom range 50000–50009 и сохраните. Для LAN не нужен выдуманный public address; external IP задают только в соответствующем NAT-варианте. Диапазон выбирают с запасом по одновременным data-соединениям, а не только числу зарегистрированных пользователей.
После создания правил из следующих команд раздела проверьте адреса, profile и программу:
Get-NetFirewallRule -DisplayName 'AVG FTPS lab*' | Get-NetFirewallAddressFilter
Get-NetFirewallRule -DisplayName 'AVG FTPS lab*' | Get-NetFirewallPortFilter
Get-NetFirewallRule -DisplayName 'AVG FTPS lab*' | Get-NetFirewallApplicationFilter
Get-NetTCPConnection -State Listen | Where-Object LocalPort -EQ 21Data listener может появляться по мере запроса передачи, поэтому отсутствие всех десяти портов в постоянном Listen не обязательно ошибка. Узкий allow не отменяет уже существующий широкий allow; изучите правила установщика и effective GPO. Не выключайте Domain Firewall целиком для диагностики. Правила должны соответствовать IPv4/IPv6, реальному адресу и схеме NAT.
7. Подключитесь клиентом и проверьте TLS
В FileZilla Client создайте запись Site Manager: Protocol FTP, Encryption Require explicit FTP over TLS, Host files.lab.example, Port 21, пользователь ftp-partner-a. Не выбирайте SFTP для этого сервера. Имя должно разрешаться на адрес лаборатории и соответствовать сертификату.
Проверьте сертификат, затем листинг и скачивание заранее подготовленного небольшого файла. В журнале должно быть установление TLS для управляющего и data-соединения. Одна строка успешного логина не подтверждает шифрование передачи файла.
Для сертификата доверенного УЦ можно дополнительно использовать штатный curl.exe Windows:
curl.exe --ssl-reqd --user ftp-partner-a 'ftp://files.example.org/'
curl.exe --ssl-reqd --user ftp-partner-a 'ftp://files.example.org/sample.txt' --output '.\sample-downloaded.txt'Используется ftp:// вместе с --ssl-reqd для explicit TLS; ftps:// относится к иному режиму. curl запросит пароль без включения его в аргумент. Для внутреннего УЦ задайте --cacert с проверенным публичным CA-файлом. Не подставляйте --insecure в постоянный скрипт. Справка curl описывает проверку TLS и параметры FTP.
Создайте клиентскую запись и разберите последовательность
В FileZilla Client → Site Manager создайте новый site: FTP, Require explicit FTP over TLS, Host files.lab.example, port 21, Logon normal/ask password по политике, ftp-partner-a. Нажмите Connect, подтвердите доверенный сертификат, проверьте список. Лог должен показывать TLS negotiation и защищённое data-соединение при LIST/передаче.
В иллюстративном маршруте 220 означает greeting, 234 — принятие AUTH TLS, 230 — успешный login, 150 — начало передачи, 226 — завершение. 530 указывает на отказ login, 550 — проблему команды/пути/прав, 425 — невозможность открыть data-соединение. Нельзя любой 550 называть неверным паролем. Серверный журнал сопоставляют с клиентским по времени и пользователю.
Resolve-DnsName files.lab.example
Test-NetConnection files.lab.example -Port 21
curl.exe --version
curl.exe --ssl-reqd --user ftp-partner-a --cacert 'C:\Temp\lab-ca.pem' 'ftp://files.lab.example/'lab-ca.pem — проверенный публичный CA/self-signed trust-файл, не private key. Наличие curl в PowerShell проверяют именно curl.exe: alias curl в старом Windows PowerShell мог обозначать другую команду. --version показывает backend TLS и доступные протоколы; не все сборки одинаковы. В verbose-журнале бывают имена файлов и сведения сессии, его очищают перед внешней передачей.
8. Выполните позитивный и негативный тест прав
При правах read-only скачивание должно работать, а upload — отклоняться. Для теста записи используйте небольшой несекретный файл и заранее согласованный каталог:
Set-Content -Path '.\ftps-test.txt' -Value 'FTPS acceptance test' -Encoding UTF8
curl.exe --ssl-reqd --user ftp-partner-a --upload-file '.\ftps-test.txt' 'ftp://files.example.org/ftps-test.txt'
Get-FileHash -Path '.\sample-downloaded.txt' -Algorithm SHA256При read-only ожидается отказ upload с ненулевым кодом curl; конкретный FTP-код зависит от причины и сервера. После выдачи необходимых write-прав повторяют upload, download и сравнивают хеш исходного и полученного файла. Это проверяет фактическую передачу, не только отображение папки.
Убедитесь, что пользователь не видит данные другого партнёра и не может выйти из разрешённой виртуальной структуры. Отдельно проверьте удаление и создание каталогов по принятой модели прав. Логи ошибок не должны публиковаться с действующими учётными данными или клиентскими файлами.
Проверка целостности и отрицательных прав
После разрешённой записи скачайте обратно тот же тестовый файл и сравните:
curl.exe --ssl-reqd --user ftp-partner-a --cacert 'C:\Temp\lab-ca.pem' --upload-file '.\ftps-test.txt' 'ftp://files.lab.example/ftps-test.txt'
if ($LASTEXITCODE -ne 0) { throw 'Upload failed: inspect client and server logs.' }
curl.exe --ssl-reqd --user ftp-partner-a --cacert 'C:\Temp\lab-ca.pem' 'ftp://files.lab.example/ftps-test.txt' --output '.\ftps-test-returned.txt'
if ($LASTEXITCODE -ne 0) { throw 'Download failed: hash comparison is not valid.' }
$OriginalHash = (Get-FileHash '.\ftps-test.txt' -Algorithm SHA256).Hash
$ReturnedHash = (Get-FileHash '.\ftps-test-returned.txt' -Algorithm SHA256).Hash
$OriginalHash -eq $ReturnedHashОжидается True. Нулевой curl exit плюс равные хеши подтверждают передачу выбранного файла, не каждого файла площадки. В Read Only upload должен завершаться отказом; это ожидаемый негативный результат, не повод расширять NTFS всем пользователям. Проверьте, что partner-a не видит и не скачивает файл partner-b, не может удалить/переименовать объекты вопреки профилю.
Повторите тест после перезапуска службы: настройки и сертификат должны сохраниться. Для большого файла дополнительно проверяют свободное место, interruption/resume и ограничения скорости. Файл с секретами не используют в первичном acceptance test.
9. Разберите NAT, 425 и зависший листинг
За NAT пробрасывают TCP 21 и весь выбранный passive range на сервер. В серверных настройках passive mode задают корректный внешний адрес для публичных клиентов. Тест из Интернета отличается от теста из LAN; hairpin NAT и split DNS могут менять путь локального клиента.
Возможные причины 425 или timeout data-соединения: непроброшенный порт, firewall, неправильный адрес PASV, TLS inspection/FTP ALG, ограниченный passive range или попытка active mode. FTPS шифрует управляющий канал, поэтому устройство NAT не должно полагаться на чтение обычных FTP-команд для динамического открытия портов.
Сопоставьте время клиентского и серверного журналов: вход прошёл → passive порт выбран → TCP установлен → TLS data установлен → файл передан. Так определяется фактический этап отказа. Не выключайте firewall целиком и не отключайте TLS, чтобы «проверить быстро». Для внешнего доступа ограничьте разрешённые IP партнёров, если схема обмена это допускает, и оцените альтернативу VPN.
Отдельный внешний тест через NAT
Схема: разрешённый внешний клиент → публичный адрес шлюза → DNAT TCP 21 и 50000–50009 → private address FTPS-сервера. Public DNS points на шлюз, а PASV должен сообщать корректный внешний адрес. EPSV использует адрес control-соединения и избегает некоторых ошибок PASV, но data-порты всё равно должны быть проброшены. Внешний пример требует реального сертификатного имени и строгих remote IP ACL.
Если login есть, а LIST висит, найдите выбранный passive port и его маршрут в firewall/шлюзе. При 425 различайте: адрес недостижим, порт закрыт, TCP есть, но TLS data не согласован. FTP ALG, пытающийся разбирать plaintext-команды, может конфликтовать с FTPS; изменение ALG делают адресно по политике шлюза, а не отключают все проверки устройства.
Проверка из LAN через public DNS может идти hairpin NAT и иметь иной источник, чем настоящий внешний клиент. Поэтому успешный LAN-тест не заменяет внешний. Если сервер обслуживает только VPN-партнёров, public DNAT вообще может быть не нужен — документация должна отражать выбранный маршрут, а не открывать лишний доступ автоматически.
10. Сопровождение, backup и возврат
Контролируйте срок сертификата, место на диске, число сессий, неудачные входы и обновления сервера. Ограничения скорости и соединений задают по нагрузке; автоматически созданный журнал без ротации может заполнить том. Резервный комплект включает серверную конфигурацию, виртуальные пути, права Windows, сертификат и защищённый приватный ключ.
Проверка восстановления выполняется на отдельном стенде: служба запускается, сертификат соответствует имени, пользователь получает только свою папку, передача и негативный тест проходят. Просто сохранённый XML не доказывает готовность восстановления.
Для возврата лабораторного firewall удаляйте только созданные вами правила после сверки имени, например Remove-NetFirewallRule -DisplayName 'AVG FTPS lab control' и аналогично data. Отключите созданного тестового пользователя, уберите лабораторный listener и проверьте рабочие подключения. Итоговая приёмка включает TLS обоих каналов, передачу файла с совпавшим хешем, отказ лишних прав и проверенный backup.
Сопровождение и восстановление
Сохраните закрытый backup конфигурации выбранного экземпляра FileZilla, сертификата/private key и ACL, отдельно данные партнёра. Путь конфигурации определяйте по установленной версии/экземпляру, а не старым инструкциям с единственным XML. Private key защищают отдельными правами и правилами backup. Перед обновлением запишите версии server/client и выполните контрольный обмен после него.
Следите за expiry сертификата, свободным местом, очередью соединений, failed logins и ростом журналов. Для каждого клиента должны быть владелец доступа, папка, права и срок. При offboarding отключают virtual user и проверяют новые/действующие сессии; смена Windows service password не отзывает автоматически FTP-user.
Rollback выполняют по собственным объектам: восстановить конфигурацию/ACL, убрать созданные narrow firewall rules, вернуть listener и сертификат, повторить TLS/листинг/передачу. Не удалять каталоги данных вместе с сервером. Готовый результат — проверенная служба, TLS обоих каналов, совпавший checksum, подтверждённые запреты и воспроизводимое восстановление на отдельном экземпляре.
Нужно сопровождение файлового сервера?
Для рабочего сервиса требуются управление доступом, шифрование, резервное копирование, обновления и контроль журналов.