On 2015-11-24, Victor Wagner wrote: > 1. Не использовать ftp для неанонимного доступа. > 2. Сделать так, чтобы директории, доступные для анонима на запись, не > были доступны для него же на чтение (а то превратят сервер в хаб для > обмена порнухой)
Ясно. Я ранее знал практике публичных бесплатных хостингов - позволять загружать странички через небозопасный FTP. На ум приходит narod.ru и blogspot до покупки Google'ом. Ожидал что есть TLS расширение, обеспечивающие безопасность. Есть стандарт https://tools.ietf.org/html/rfc2228 FTP Security Extensions со страшными словами GSSAPI/Kerberos 4, который судя по: http://www.proftpd.org/docs/rfc.html не реализован полностью в proftpd. В то же время есть https://tools.ietf.org/html/rfc4217 который реализован в модуле mod_tls (и согласован с командой AUTH от rfc2228): http://www.proftpd.org/docs/howto/TLS.html Оказывается что rfc4217 это не FTP в обертке TLS, а гибрид: 12.1. Establishing a Protected Session Client Server control data data control ====================================================== socket() bind() socket() connect() --------------------------------> accept() <-------------------------------- 220 AUTH TLS --------------------------------> <-------------------------------- 234 TLSneg() <--------------------------------> TLSneg() <== Тут зашифровано? PBSZ 0 --------------------------------> <-------------------------------- 200 PROT P --------------------------------> <-------------------------------- 200 USER fred --------------------------------> <-------------------------------- 331 PASS pass --------------------------------> <-------------------------------- 230 И далее у нас есть возможность передавать данные либо открыто, либо защищенно по data-каналу. Стандарта на обертку FTP в TLS, судя по выдержке: Negotiation is not supported with implicit FTPS configurations. A client is immediately expected to challenge the FTPS server with a TLS ClientHello message. If such a message is not received by the FTPS server, the server should drop the connection. из: https://en.wikipedia.org/wiki/FTPS и: A. Deprecated SSL negotiation mechanisms There are two other mechanisms that have been used for FTP over SSL, these mechanisms do not conform to [RFC-2228] and so are now deprecated. They are documented below. i) Implicit SSL protection of the FTP session There is a port, registered with the IANA, for secure FTP using ssl {FTP-TLSPORT}. This approach can be likened to the [RFC-2818] approach for https, in that the SSL negotiation happens upon connection (for the control and all data connections). This approach is not favoured by the IETF and should not be used for new FTP-TLS implementations. из: https://tools.ietf.org/html/draft-murray-auth-ftp-ssl-07#appendix-A нету и нету соответственно нормальных реализаций. lftp и curl на ftps:// пытаются "пожать руку", proftpd такого скоре всего не умеет (я в документации не нашел способа). > 3. Во всех остальных случаях использовать протоколы, отличные от ftp. Я слышал и некоторые использовал: * smb - на сколько толстый сервер? У меня vps с 256 MiB RAM и доступ на запись к файлам не основная задача. Как с безопасностью при авторизации? * sftp - требует создавать пользователя в системе под каждый разделяемый ресурс. * rsync - не знаю визуальных оболочек, например как ftp/sftp в MC и интерактивных приложений как sftp/lftp. Для безопасности вроде нужно тунелировать через ssh. * webdav - требует постоянно работающего apache, нужно настраивать SSL. Из всего только sftp выглядит простым решением. Если разобраться с сертификатами, то мне ftps кажется тоже хорошим решением, особенно учитывая что через ftp-сервер можно задавать права доступа, ложить файлы с нужными владельцами и правами и использовать свою базу авторизации (ftpasswd). -- Best regards!
