Re: Passive means what during FTP?

• Previous message: Ross MacGillivray: "KDE Desktop Size is Larger than Cygwin/X Server Window"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 01 Jun 2005 12:56:41 +0200

On Tue, 31 May 2005 15:36:13 +0000, Robert Nichols wrote:
> In article <d7h10k$1j8e$1@mail.cn99.com>, case <case@c.com> wrote:

[ ... ]

> :Why file trasfer failed in Passive mode?

Misconfigured firewalling.

> The FTP data transfer uses a connection that is separate from the
> control connection. Active vs. passive mode selects whether it is the
> server or the client that opens the data connection. Firewalls can
> prevent one or the other (or both!) from working.

Yes. Passive mode is more secure(able) though.

> Active mode:
> Over the control connection, the client tells the server what IP
> address and port number to connect to for the data transfer. The server
> opens a connection from its own port 20 (FTP-Data).

Which means the server needs to (re)claim root privilege :-( ...
Vsftpd drops root after bind()ing to port 21 entirely, if setup to
passive-mode only.

> A server firewall needs to allow the outgoing port 20 connection. A
> firewall on the client needs to be clever enough to look inside the
> control packet to find the port number and then allow the incoming data
> connection.

Ofcource this beaks "ftps" (SSL/TLS encripting atleast the control channel.)
Since the (otherwise) statefull firewalling code, cannot look inside the
packets. You'd have no choise but to allow any connection from port 20 to
your 1024-65535 range.

> Passive mode:
> Just the reverse of the above. The server tells the client what IP
> address and port number to connect to for the data transfer.

Yes. And the port in in the range: >1024

> The client opens a connection from its own port 20 (FTP-Data).

Nope. The client connects from port >1024 , so the connection looks like:

Request PASV:

Client port >1024 ==> Server port 21

Server opens a local port >1024 listener, and tells the client about it,
client connects to that port for data transfer:

Client port >1024 ==> Server port >1024

> A client firewall needs to allow the outgoing port 20 connection.

No it does not. It only needs to allow outgoing connections from ports
above 1023 (or, and tighter: whatever the ip_local_port_range is set to)
to the server ports 21 and 1024-65535 ...

And since it's only outbound connections (initiated from the client) there
isn't any problem in encripting the control connection, i.e.: ftps

> A firewall on the server needs to be clever enough to look inside the
> control packet to find the port number and then allow the incoming data
> connection.

Well, you could do that. But it doesn't buy anything since the ports are
in closed state already, untill the server starts a listener for some data
connection which in turn triggers the "firewall" to poke a hole. So you'd
be "protecting" closed ports only - which seems kind of silly to me ...

Now again what this _does_ do is break SSL/TLS encripting of the control
channel (which, when configured correctly, provides some _actual_ security.)

Simply setup the server to use a passive port-range, and allow that
through the firewall. If the Netfilter is host-based (i.e.: local) one can
even configure it to allow outbound (reply) packets, in that range, from
the account the server runs as only ( man iptables <-- look for "owner" .)

> In both cases, any intervening NAT routers introduce an additional layer
> of complexity.

Any Masq/NAT machine on the _client_ network isn't a problem (even with
SSL/TLS), provided: passive-mode is used ...

> Suffice to say they need to be "FTP-aware".

No they don't. Only if either active-mode needs to be supported, or the
NAT machine is in front of the _server_ network (in which case you'll need
to port-forward 21 and the passive-data range.)

-- 
-Menno.

• Previous message: Ross MacGillivray: "KDE Desktop Size is Larger than Cygwin/X Server Window"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]