Subject: wuftpd is using high ports

From: "Perry Edward (tsp2emp)" <[email-masked]>
Date: Thu, 24 Jun 1999 11:37:19 -0400

I am using a virus scanning utility call Interscan Virus Wall by Trend
Micro this program spawns my in.wuftpd program and in.wuftpd then uses
high port(for data connections)  if I spawn in.wuftpd from the
inetd.conf it will use port 20. I tried both cases with in.ftpd and it
uses port 20 in both cases. I do not see anything in the man pages of
limiting in.wuftpd to port 20. I am using Solaris 2.6 and Wuftpd 2.4
(I think)

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 24 Jun 1999 12:49:52 -0400 (EDT)

> limiting in.wuftpd to port 20. I am using Solaris 2.6 and Wuftpd 2.4

Last thing first: If you are really running 2.4 you have more severe
security problems than a few piddling virii could cause.  The current
version of the daemon is 2.5.0.  To determine which version you are
runnin, on most systems, simply conenct to the FTP server with a
text-based client; the version number appears in the greeting message.
More recent versions of the daemon allow you to change the verbosity of
the greeting; on those systems, you will need to issue a STAT (or QUOTE
STAT) command .. the version number will appear in the server status
output.

Now, to your main question.  I guess I should say RTFM, but I'll explain:

(Short form answer for the impatient: "Duh!  That's how FTP is supposed to
work.")

There are two sockets used in an FTP session: the Control socket and the
Data socket.

The Control socket is where the daemon (or inetd) listens for new
sessions.  This is normally TCP port 21 but it can be changed using a
command-line option or by changing the 'ftp' entry in /etc/services.
Firewall rules for the Control connection should be:

  Allow all incoming TCP from any IP address on non-privileged TCP ports
  to the server's IP address(es) on Port 21.

  Allow only connected outgoing TCP from the server's IP address(es) on
  port 21 to any IP address on non-privileged TCP ports.

For example: On Linux, using ipfwadm, with a server on 10.0.0.1 and the
default rule to deny (drop) all packets:

  ipfwadm -I -i accept    -P tcp -S 0.0.0.0/0 1024:65534 -D 10.0.0.1 21
  ipfwadm -O -i accept -k -P tcp -D 0.0.0.0/0 1024:65534 -S 10.0.0.1 21

The Data socket operates in one of two modes: PORT or PASV.  The mode is
determined by the client.  In PORT mode, the daemon initiates the
connection and generally uses port 20 (but, again, this can be changed
with a command-line option or by changing 'ftp-data' in /etc/services).
PASV mode connections are initiated by the client to a port selected by
the daemon.

Firewall rules for a PORT mode connection should be:

  Allow all outgoing TCP from the server's IP address(es) on port 20 to
  any IP address on a non-privileged port.

  Allow only connected incoming TCP to the server's IP address(es) port 20
  from any IP address on a non-privileged port.

For example: On Linux, using ipfwadm, with a server on 10.0.0.1 and the
default rule to deny (drop) all packets:

  ipfwadm -O -i accept    -P tcp -D 0.0.0.0/0 1024:65534 -S 10.0.0.1 20
  ipfwadm -I -i accept -k -P tcp -S 0.0.0.0/0 1024:65534 -D 10.0.0.1 20

Firewall rules for a PASV mode connection should be:

  Allow all incoming TCP from any IP address on any non-privileged port to
  the server's IP address(es) on any non-privileged port.

  Allow only outgoing TCP from the server's IP address(es) on any
  non-privileged port to any IP address on any non-privileged port.

For example: On Linux, using ipfwadm, with a server on 10.0.0.1 and the   
default rule to deny (drop) all packets:

  ipfwadm -I -i accept    -P tcp -S 0.0.0.0/0 1024:65534 -D 10.0.0.1 1024:65534
  ipfwadm -O -i accept -k -P tcp -D 0.0.0.0/0 1024:65534 -S 10.0.0.1 1024:65534

BIG WORD OF CAUTION HERE .. this last rule set should scare the hell out
of you.  For instance, if you're firewalling and you want to allow
outgoing FTP clients from the same IP address(es) as you allow incoming
FTP, the rules for the two sets will merge to allow all traffic of any
kind on all non-privileged ports.  Think carefully about the ways the
rules interact .. it is very easy to define rules which appear to work but
don't actually do a damned thing to secure the server.

So, what's the solution?  With earlier versions of the daemon, there was
none.  Period.  You lived with this problem or you didn't offer FTP.

Version 2.5.0 has a ftpaccess configuration clause, however, which can
come to your rescue.  It won't completely solve the problem, but it can
make it more manageable.

  passive ports <cidr> <min> <max>

This allows you to determine the PASV-mode connection port range which the
daemon will choose from.  And you can determine that range based upon the
IP address (using CIDR notation) which the Control connection arrived on.

For example, we could shoft the PASV ports from the non-privileged range
to a short segment of the privileged port range, say 512 through 1023.
This can avoid problems with rules merging together, but it could open
other problems if the serer needs to offer other services which use that
range (say, SSH) .. SO BE CAREFUL.  The ftpaccess file, for this example,
would contain:

  passive port 10.0.0.1/32 512 1023

And the Linux ipfwadm rules for this would become:

  ipfwadm -I -i accept    -P tcp -S 0.0.0.0/0 1024:65534 -D 10.0.0.1 512:1023
  ipfwadm -O -i accept -k -P tcp -D 0.0.0.0/0 1024:65534 -S 10.0.0.1 512:1023

This may look like a good solution, and will work for most sites, but be
aware: if the remote network is firewalling FTP clients to restrict them
to the expected (non-privileged) range in an attempt to prevent network
abuse of servers by that network's users, the remote firewall's rules
could prevent their FTP clients from establishing PASV connections to your
FTP server.

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195