Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Aug 2002 08:32:48 +0100
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Grant Cooper <grant.cooper@nucleus.com>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: Passive or Active or Both (FTP)
Message-ID:  <20020815073248.GA8411@happy-idiot-talk.infracaninophi>
In-Reply-To: <01c701c243e6$16dc2360$2afececd@TCOOPER>
References:  <01c701c243e6$16dc2360$2afececd@TCOOPER>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 14, 2002 at 04:58:22PM -0600, Grant Cooper wrote:
> Is there a way to set up FreeBSD to active ftp?=20

If the freebsd box is the server, you don't need to do anything: both
active and passive mode are already supported.

If the freebsd box is the client, then exactly what you do depends on
what ftp client you're using.

   Web browsers like Mozilla are all pretty much fixed and will only do
   passive mode.

   The ftp clients supplied with FreeBSD --- fetch and ftp most
   prominently --- will honour the FTP_PASSIVE_MODE environment
   variable: set this variable to "NO" or leave it completely unset to
   make the ftp clients default to active FTP.  Anything else will
   change the default to passive ftp.  Ftp clients from elsewhere may
   have similar controls: eg. the Net::FTP module in perl uses the
   FTP_PASSIVE environment variable similarly.

   Interactive clients, like ftp(1) or ncftp(1) support a 'passive'
   command, that toggles between active and passive mode.

   ftp and fetch both have a '-p' flag to force passive mode from the
   command line --- there isn't a flag to force active mode as that's
   assumed to be the default mode of operation.

> Where can you pick the IP range passive ftp uses?

That's set on the server side.  From the ftpd(8) man page:

     -U      In previous versions of ftpd, when a passive mode client
             requested a data connection to the server, the server would use
             data ports in the range 1024..4999.  Now, by default, the serv=
er
             will use data ports in the range 49152..65535.  Specifying this
             option will revert to the old behavior.

Those two ranges can additionally be controlled by modifying some sysctls --

    happy-idiot-talk:~:% sysctl -a | grep portrange
    net.inet.ip.portrange.lowfirst: 1023
    net.inet.ip.portrange.lowlast: 600
    net.inet.ip.portrange.first: 1024
    net.inet.ip.portrange.last: 5000
    net.inet.ip.portrange.hifirst: 49152
    net.inet.ip.portrange.hilast: 65535


> Are there any IPFW rules for passive ftp, dynamic, keep-state. The
> questioned been asked but I can't find a solution.

FTP uses two socket connections between the client and the server.
=46rom the point of view of firewalling, you need separate rules to deal
with each of those connections.

Both active and passive FTP start out with an FTP command connection
to port 21 (ftp) on the server: on the client side you'll need a rule
like:

    allow tcp from me to any 21 keep-state

or on the server side:

    allow tcp from any to me 21 keep-state

All pretty reasonable so far.  Beyond that, it starts to get nasty.

For active ftp, the server will open a connection from port 20
(ftp-data) back to an arbitrary port between hifirst and hilast as
shown above.  The port number to use is passed from the client to the
server via the ftp PORT command. This is not good at all from the
point of view of the client:

    allow tcp from any 20 to me 49152-65535 keep-state

but it's all fine and dandy from the point of view of the server:

    allow tcp from me 20 to any keep-state

=46rom the client's perspective, that's a very big hole in the firewall
allowing anyone to connect to the high numbered port range.  Normally,
there shouldn't be anything listening on ports within that range, but
it's something you have to be wary of.  Nb.  natd has a -use-sockets
option that permits creating the ftp-data connection back from the
server.

For passive ftp, when a command is issued to download a file, the
client opens the ftp data channel to an arbitrary high-range port on
the server --- the port number to use is passed from the server to the
client in response to the client issuing a PASV command ---
unfortunately, what constitutes a valid "high range" port is in the
gift of the server and varies from implementation to implementation.
=46rom the point of view of firewalling, that means the client side has
to permit outgoing TCP connections from an arbitrary port to any
arbitrary port on the server:

    allow tcp from me to any keep-state

That's actually not as bad as it sounds as many firewall rulesets will
already allow anyone to connect outwards pretty liberally.

However, from the server side, it's a real pain.  Because the server
is under our control we know what the high range of ports is, and the
only choice is just to open up that whole block:

   allow tcp from any to me 49152-65535 keep-state

Now, ideally to make FTP properly secure you would need to use a
firewall that would not only look at the packet headers, but also the
payload, and that understood at least parts of the FTP protocol, so it
could detect a 'PORT nnnnn' request or an 'OK nnnnn' response to a
'PASV' request and could open up dynamic rules based on that
information.  As far as I know, that capability doesn't exist in
either ipfw(8) or ipf(8), although some commercial firewalls are
capable of it.

The conclusion is pretty much that FTP is an ancient protocol invented
way back in the mythical golden age of the intenet when admins were a
lot more trusting and would innocently do things like not use
firewalls or run open mail relays under the reasonable expectation
they would not be exploited by the very next skript-kiddie that came
along.  If you can, avoid FTP --- HTTP is much more firewall friendly.

	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
Tel: +44 1628 476614                                  Marlow
Fax: +44 0870 0522645                                 Bucks., SL7 1TH UK

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020815073248.GA8411>