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 [EMAIL PROTECTED]
Kettering, OH 45409-1615 USA 1-800-809-2195
PGP signature