RE: FTP Proxy

["David Gillett" <gillettdavid () fhda edu>]

> -----Original Message-----
> From: Fernando Gont [mailto:fernando () gont com ar]
>
> At 11:19 29/01/2004 -0800, David Gillett wrote:
>
> > > If the client is configured to do passive transfers, the
> > > client will use the connection requests for both the control
> > > and data connections.  That means, you won't need to allow
> > > incoming connection requests to hosts inside your network.
> > > I think it's the best option.
> >   Which is "best" depends on whether you're looking from the
> > client side or the server side, and what kind of border security
> > you have at each end.
> >   If you have stateful firewalls with FTP fixup, they can listen
> > to the FTP control conversation and permit the requested data
> > connections as needed -- and this is true regardless of which
> > direction wants to open the data connection.
>
> This requieres more processing in the firewall, though.
> Because the PORT command must be "patched" in the stream, it 
> may be the 
> case that the firewall not only needs to recalculate TCP's 
> checksum, but 
> may have to "recalculate" the sequence numbers, too. (The 
> "patched" PORT 
> command might be longer or shorter than the original one).

  Who said anything about PATCHING the PORT commands?  All the firewall
has to do is READ them, so it knows what ports the hosts have chosen
to use.  By the time the handshake wants to happen, the firewall
knows to allow it for this one time. 
 
> >   If you rely on packet filters, either the client side or the
> > server side has to allow arbitrary data connections to be opened.
> > The only closure of this hole you can implement is that if the
> > server opens the data connection ("active" mode), the source port
> > number will be 20.  [In "Hacking Exposed", there's passing reference
> > to doing a pen-test against a network that would permit any
> > connection sourced from port 20; this is why it was configured that
> > way.]
>
> Sorry, I didn't understand that part where you said "this is 
> why it was configured that way".

Q:  Why did an admin configure their border to allow any connections
sourced from port 20 to come in?

A:  So non-PASV FTP clients on his network could work.  The only other
reason you'd see random traffic sourced from a low port number like 
this is if it's using some special penetration tool.

> >   It isn't that passive mode is "better" than or "more secure" than
> > (boy, have I heard that one claimed a lot of times!) active 
> mode; it's
> > that if you're not using stateful firewalls that know about FTP,
> > passive mode dumps all the risk on the server instead of the clients.
>
> It's probably more easy to configure the FTP server to use 
> some specified 
> port range (and thus allow incoming connections on only those 
> ports) than 
> configure *all* the clients that want to access your FTP site 
> in a similar way.

  BUT that's not how PASV FTP works!  In PASV, the *CLIENT* picks a
random port number, and sends the server a PORT command that says "I'm
about to connect to your port XXX, please bend over and drop your
pants."  The server doesn't get to say "Please only use ports YYY-ZZZ."
 
> BTW, the FTP server was external to his organization, so... 
> why should *him* take the risk?

  If I run an FTP server, must I assume *all* of the risk?  If so,
I'm going to get really picky about who I trust to connect to it....

David Gillett



---------------------------------------------------------------------------
Ethical Hacking at InfoSec Institute. Mention this ad and get $720 off any 
course! All of our class sizes are guaranteed to be 10 students or less. 
We provide Ethical Hacking, Advanced Ethical Hacking, Intrusion Prevention, 
and many other technical hands on courses. 
Visit us at http://www.infosecinstitute.com/securityfocus to get $720 off 
any course!  
----------------------------------------------------------------------------