[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ProgSoc] FTP and firewalls



On Fri, 2006-05-19 at 19:01 +1000, jedd wrote:

>  Actually, the FTP server *does* allow it, but it's blocked by their
>  firewall -- as evinced by a successful response to a PASSIVE command,
>  and then a time-out for any subsequent puts, gets, dirs, etc.  The
>  admins at the third-party site 'recommend disabling passive mode on'
>  on our end.

Step one is to pin down exactly what FTP modes _do_ work with the remote
server. If the remote server admin and remote firewall admin aren't
co-operating then it's entirely conceivable that FTP won't work at all.
(This is quite different to the sitation for a web server where the
firewall need merely permit inbound 80/tcp to the web server host's IP
address.)

Once you have details of a known working mode, ideally one that you've
tested (with, say, an unfirewalled PC booted from an Ubuntu/Knoppix live
CD), you need merely configure your local firewall to accomodate it.

Repeating for emphasis: get working communication established and tested
_before_ you touch your own firewall. If you fail to do this, you'll be
chasing your own tail for exactly as long as it takes you to give up in
disgust.

>  My questions include, but aren't limited to:
>  o  Is passive less secure, from a firewall POV I mean, insofar as
>      what needs to be open, what can be closed, etc?

Umm, whose firewall?

>  o  Does this necessitate SPI at their end, or can you stop passive
>      with straightforward port blocking?

_Enabling_ passive FTP requires stateful tracking at the server-side
firewall, yes. You can of course _block_ any service with
straightforward port blocking.

The specifics for FTP are reasonably simple:

- The server-side firewall permits new connections to port 21.

- The FTP server, after being placed in passive mode by the client, will
respond to any GET/PUT request by allocating a TCP port for the data
transfer, listening on it, telling the client what IP address and port
number to connect to, then "passively" waiting for the client to
connect.

- For this to work in the presence of a server-side firewall, the
firewall needs to notice the FTP server's response and open up the
corresponding port to incoming traffic, ideally from the client's IP
address only, and typically for the duration of a single TCP connection
only. If NAT is in use (e.g. the FTP server actually uses an RFC1918
address and the firewall translates), then the firewall also needs to
modify the FTP server's response in flight in order to have it specify
the public IP address and, frequently, a different port number.

Active mode FTP is actually a little bit easier to support on a sloppily
secured firewall. The firewall admin need merely (!) permit the FTP
server's host to make arbitrary outbound TCP connections (back to the
"client") at will. Clearly, this is not sound practice, but it's pretty
common.

The need for the client-side firewall to co-operate why "active" mode
FTP (active from the server's perspective, it goes looking for the
client rather than passively waiting for the client to connect) is
gradually dying; generally people making stuff available for download
are usually interested in making it possible for as many people as
possible to download it, and using a protocol that requires client-side
firewall reconfiguration is not compatible with this objective.

>  o  What's the best way(s) of working around these limitations?

As above. Get a configuration working without your firewall. If they
can't provide a working service, or their service works for other people
but they can't give you enough information to make it work for you, then
messing with your firewall is a waste of time.

If they really can't be persuaded to correctly support passive mode FTP,
you'll ip_conntrack_ftp, I think. (I've never been in the situation of
having to enable active mode FTP in a client-side firewall.) Note that
your firewall will having to be permitting not only ESTABLISHED traffic,
but also RELATED traffic, regardless of port number. With luck, this is
already present near the top of your list.

An aside: if they really can't be persuaded to support passive mode FTP,
then their FTP server should not be permitting the client to put the
session into passive mode.

- Raz


-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx
If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.