--dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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. --=20 Gregory A Lundberg WU-FTPD Development Group 1441 Elmdale Drive lundberg@wu-ftpd.org Kettering, OH 45409-1615 USA 1-800-809-2195 --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5 iQB1AwUBOFFTEg2nXFkJc83RAQGyxgL7BfkvU3yTj6Ql2LFhmOjBbT7+dEoNyVJg BEQShDeIWNPWMHttC/YCqeNkM3AFKLGp1Sq8cDIRY2F0Meqh/6YwOw6EONhrXc9W LjFUXmmq79oEq9IwTe0hKrqUzStGkDU7 =fwgN -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO--
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:20:09 PDT