FTP TLSv1 - SSLv3 and Firewall

Ricollegandomi ad un mio precendente post volevo proporre una riflessione su FTP over SSL.
Il protocollo FTP (RFC 959 RFC 1123) implementa due canali di connessione, 
uno per i comandi e uno per lo data trasfert, a differenza degli altri protocollo che hanno bind su well know port (smtp 25, ldap 389, http 80 e i rispettivi s o protocolli con TLS) se si implementala modalità passive su FTP o il client richiede tramite comando PORT una determinata porta, il firewall deve poter rintracciare nella comunicazione server - client FTP la porta di comunicazione e aprirla dinamicamente. 
Per il protocollo FTP normale la prassi è seguire le raccomandazione dell' RFC 1579 (Firewall-Friendly FTP).
Per quanto riguarda l'implementazione TLS invece essendo il layer di comunicazione criptato
il firewall (parliamo di Content Aware Firewalls) non riesce a determinare dinamicamente la porta su cui aprire la comunicazione sul data transfert, stesso problema per un eventuale NAT. 
A questo proposito esiste una INTERNET-DRAFT FTP/TLS Friendly Firewalls http://www.ietf.org/internet-drafts/draft-fordh-ftp-ssl-firewall-04.txt . Siccome è una DRAFT non c'e' ancora nulla che specifica l'implementazione.
Ovviamente la soluzione è di aprire il range di porte in cui è possibile il data transfert e forse questa modalità
In una DMZ non è il massimo a livello di sicurezza.
A questo proposito riporto le considerazioni di TJ Saunders sviluppatore del mod_tls per proftpd nel suo mini HOW TO:

"Question: Using mod_tls, FTP sessions through my firewall now no longer work. What's going on?
Answer: The short answer is that FTPS and firewalls (and devices performing NAT) do not interact well. The control connection happens on a well-known port, and has no issues; it is the data connection that poses problems for FTP-aware firewalls. In a non-FTPS session, the firewall can inspect the FTP server's responses on the control connection to a client's PASV or PORT command, and thus know which on which ports/addresses the data connection will be established. In an FTPS session, though, those control connection messages are encrypted (that is the point of using FTPS, right?), and so the FTP-aware firewall cannot peek. Hence, it cannot know which on which ports the data connection will be established. For firewalls that are configured to always allow a certain range of ports (such as might be configured using the PassivePorts directive), FTPS should function without issue. 

Unfortunately, this is a rather intractable--and known--issue. Earlier versions of the Draft defining FTPS used to allow something known as "implicit" FTPS, by which a client could contact a well-known port (akin to port 443 for HTTPS; FTPS used port 990) and the server, simply because the client contacted that certain port, would automatically encrypt the session. This approach has several drawbacks (the reason why it was removed from later versions of the Draft), but it did allow for simple TCP proxying. There has been no replacement."

E la FAQ 10 del progetto bsdftpd-ssl

Q10: Are there any firewall-specific issues known to be linked with the secured FTP protocol? 

A: Yes, there are. These issues are discussed in the Internet-Draft named "Secure FTP Friendly Firewalls" (draft-fordh-ftp-ssl-firewall-01.txt, it's possible that the new version of this document is available). The information provided by this document may be summarized in next points:

FTP over TLS will not affect the operation of the FTP protocol as viewed by a simple port filtering firewall. The connections and the ports are exactly the same. 
Content aware firewalls will no longer be able to understand the content of the Control connection. This means that 
Any packet on the control connection that cannot be inspected, must be configured to be passed through.
Normal port filtering firewall rules must be in place for the Data Connection, as the firewall will not be able to open up the pinholes, based on examination of the Control Connection. 
Network Address Translation (NAT) firewalls will not work for secure FTP if the NAT will affect the PORT address or the PASV response address. An FTP Client on a NATted network should be able to use secure FTP over TLS in firewall friendly mode to a Server that has a real Internet IP address. An FTP Client with a real Internet IP address should be able to use an FTP Server that is on a NATted network in normal mode (assuming there is some mechanism for the Client to establish a Control Connection). 
In general Client-Server secured FTP will not work at all with an Application Layer Gateways (ALG). However, It may be possible to configure an ALG as one of the endpoints of the secured FTP session as it flows over a hostile network. 


Scusate la prolissità della mail ma volevo focalizzare bene il problema, quindi il prezzo da pagare per utilizzare FTP su TLSv1 e SSLv3 è di
Dover rinunciare all'apertura dinamica delle porte e mettere delle regole di apertura per un range molto elevato di porte.
Le mie domande sono:
- Tale modalità in che modo potrebbe far diminuire la sicurezza di una DMZ? (Secondo me poco, perché cmq le porte si devono aprire dall'interno verso l'esterno e se qualcuno entra dentro ho ben altra tipologia di problemi...)
- Esiste un meccanismo per ovviare a questa problematica (io non sono riusciti a trovarne...)

A presto

Fausto

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List