Re: FTP denial of service attack

[lundberg () WU-FTPD ORG (Gregory A Lundberg)]

aleph:

Please kill this thread.  It has devolved into misinformation and religion.
Posters are arguing points of the FTP, some without even the vaugest hint
they understand the protocol.

PORT mode and third-party PASV mode
-----------------------------------
   The FTP user-PI MUST have an active listen on the remote-DTP (either a
   local listenning port, or another server's PASV port), before sending a
   PORT command to the server-PI.

   The FTP server-PI MUST establish the PORT data connection before sending
   a positive (2yz) reply to the PORT command.

   A properly crafted third party DoS is possible, effecting the PORT-mode
   server, the PASV-mode server, or both.  With properly implemented TCP,
   the passive (listening) remote-DTP is vulnerable to this type of attack.

   Standard FTP Bounce Attack defenses will prevent a third-party DoS of
   this type.

   In a two-party attack, the most likely effected machine is the client
   running the attack; it is unlikely the client wishes to DoS itself, so
   this is a very unlikely mode.

PASV mode
---------
   The FTP server-PI MUST have an active listen before sending the positive
   (2yz) reply to the PASV command.

   If the remote-DTP establishes the data connection to the server-DTP, and
   the user-PI then issues a subsequent PORT command, the server-PI MUST
   close the data connection before activating the listen on the new port
   and sending the positive (2yz) reply to the subsequent PASV command.
   This leaves the old data connection in a CLOSE WAIT state, at best, or
   FIN WAIT 2 state if the attacker simply abandons the data connection
   instead of properly closing it.

   As has been shown (I did it with an expect script), and attack of this
   nature is trivial to produce.

SUMMARY
-------
   An attack of this nature is a well-known problem with the TCP.  While
   changes to the TCP might help prevent it, the best method is some form
   of connection-rate throttle on the data connection, progressively
   slowing the PASV command processing (optimally, before activating the
   new listen) under some criteria.  The intention is to allow normal
   operation to proceed with minimal delay, slow down potential DoS
   attacks, and return to normal operation once the appearent attack has
   subsided.

OTHER ACTIONS
-------------
   FTP servers traditionally do not record data connection activity.  As
   has been suggested, server authors should add this capability to allow
   system administrators to better monitor and analyze their servers.

   Since the command channel activity is (usually) already logged, this
   additional logging does little to assist researching the culprit.  The
   attack originated from the client-side of the control connection (which
   is logged on most modern servers).  The client-side of the data
   connection may or may not be the same client.  If it is not, it is
   almost certainly an unwitting third party.  WU-FTPD and many other FTP
   servers log data connections where the client-side does not match the
   control connection.  This is sufficient to determine whose host is
   improperly protected against FTP Bounce Attacks should the victim
   adminstrator choose to pass along the warning.

-- 

Gregory A Lundberg              WU-FTPD Development Group
1441 Elmdale Drive              lundberg () wu-ftpd org
Kettering, OH 45409-1615 USA    1-800-809-2195


<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>