Conference noted::seal

Take a look around on this notesfile:  I'm sure this
was discussed not so long ago.  I seem to remember
that the answer was that the ftp proxy doesn't
support use of port 20 for the data port.  I also
seem to remember that someone (was it Marc Chatel)
posted changes to the code that would be required
to support data port 20.

You should also be aware, that AFWU V2 ftpxd doesn't
support port 20 either, as far as I know ...

T

Hi,

I've seen that problem when AltaVista Firewall customers want to access
an FTP server that is "secured" by a packet filter allowing only 
port 20 for the data connection:

   ftp client --- AltaVista FW --- Internet --- Packet Filter --- ftp server 

In order to use port 20, the ftp client doesn't send a PORT command.
(as Arturo says, sending the PORT command can be disabled with the "sendport"
command.) ftpxd should notice there is no PORT sent from the client, and then
also not send a PORT command. This would cause the ftp server to open a data
connection on default port 20, where ftpxd must accept it.

But as far as I know, ftpxd does NOT behave this way. Why not?

RFC 959 describing FTP says: "...all FTP implementation must support data
transfer using the default port". So I think ftpxd also should do so.

Sebastian
[Posted by WWW Notes gateway]

The question is actually not, if it AVFU V2.1 (UNIX) does support FTP port 20.
I already know, it does not. I tested it my self. I also have the lines for
the SEAL-Proxy to patch the port 20. I can patch the SEAL-ftpxd-proxy  my self. 
I can not patch the AVFU proxy, since I do not have the sources.

The question is, how many customers are experiencing this problem and
how big is the pressure from this customers to fix the problem. 

I would like to have the feedback from the field.

Alta Vista must fix the problem in a reasonble time (launch of V3.0). I have a
big project, which is waiting for a commitment, on the fix of this problem, with
V3.0.

Arturo

    Hello all,
    
       It is not just a "source code or no source code" issue. On most
    normal UNIXes, in order to bind a socket to port 20 (remember that 20 is
    less than 1024 :-)), the program doing it MUST RUN AS ROOT.
    
       Modifying ftpxd to use port 20 implies running it as root.
    Not everybody will accept that. When (as part of building the S4 kit)
    I wanted to build an FTP daemon that only accepts anonymous FTP
    connections and that does not run as root, I happened to hit the same
    problem: binding to port 20 would not work non-root. The FTP protocol
    requires a new data connection for each file or directory transfer,
    so you cannot just bind to port 20 ONCE while running as root, than
    drop privilege for the remaining life of the process. That does not
    work either. This is why most FTP daemons spend their time wobbling
    back and forth between root privilege and non-root privilege
    (even after you have logged in as normal user!). This is also why
    most FTP daemons have (or tend to have) security holes.
    
       An alternative way to do this exists on some UNIXes (but not all;
    luckily this works fine on Digital UNIX). The good old "Unix
    Network Programming" book by W. Richard Stevens explains that on
    4.3BSD systems, the sendmsg()/recvmsg() system calls can be used
    to pass an open file from a process to another. Only requirement:
    to have an open pipe or UNIX domain stream socket opened between the
    two. The trick is that you can pass an open TCP or UDP socket in the
    same way.
    
       Based on this, I build a special-purpose daemon, "privportd".
    This daemon runs as root and its only purpose in life is to pass open
    sockets to other programs which run non-root. privportd itself
    only listens to connections on a UNIX stream socket, so it is kind of
    hard to attack from the network (assuming it has vulnerabilities, of
    course). privportd has a simple config file, /etc/privport.conf,
    which it will use to decide which privileged UDP or TCP ports it will
    be willing to give away to other processes.
    
       Once I got this running (phew!), I did get a anonymous-only
    non-root FTP daemon to work (which is dependent on privportd running,
    of course!).
    
       privportd and aftpd are included in source code in the S4 kit,
    for those who are interested. So one of the ways of building an
    ftpxd that complies to the port 20 tradition (to my knowledge, RFC 959
    does not make it a HARD requirement, though) would be to modify it
    to use privportd for creating port-20 sockets and make it dependent
    on privportd's existence on the system.
    
       Not high on MY priority list right now, I'm afraid... Tidying up
    the modified CERN web proxy that does Java/ActiveX filtering,
    and the S4 TACACS+ authentication server...
    
       Regards,
       Marc Chatel @ AEO
      
    

Marc,

thanks for your great answer.

I did not think about the problem about ftpxd running as a process of an unpri-
vileged user trying to bind to port 20.

Yes this is a problem.

On the other side, the customers need to transfer data electronically. Even if
both customers have firewalls.

In one case, the customer started to transfer data PER TAPES again, since one
firewall does not use the port 20 and the packet filter on the other side only
accepts port 20.


Weird world ;-<.

I would like to hear the oipinion of Alta Vista Product Management here.

Is the ftp port 20 an issue, which will be fixed or not ?

Arturo

    Once again,
    
       I would like to remind everybody that the code I have written
    as part of the S4 kit has a copyright statement that makes it very
    clear that it is donated to the public domain, and that it can be
    reused by anyone for commercial or non-commercial purposes, and that
    the code can be reused as is or modified. I did this specifically
    so that companies who need to can re-incorporate useful things
    in commercial products...
    
       In other words, if the Altavista product team wish to, they can
    just package privportd along and modify their FTP proxy to use it.
    Of course, they have to feel confident THEY can support the result...
    
       Regards,
       Marc Chatel @ AEO
    
                       

    I have heard that the new products manager for this is Philippe
    Derarslanian..

Is this ftp issue will be fixed in avfu 97?