In message on 09/01/10(08:25:44)
you Jacob Lundberg wrote:
|One of the ways people try to prevent ftp port bounce attacks and
|probing is to require in the FTP server that the PORT command must
|specify the same IP as the originator of the control channel. Is this
|possible with DeleGate? From the documentation, it seems like DeleGate
|only supports turning the PORT command off entirely.
Even if PORT is turned off, clients can establish active connections
by using EPRT as "EPRT |1|10.20.30.40|12345|" for example.
|Either of these two things would work while still allowing PORT commands:
|1) An option to ignore the IP given in a PORT command and silently use
|the same IP as the control channel.
|2) An option to reject the PORT command if the IP address is not the
|same as the one in the control channel.
|Both of these options would be non-RFC-compliant behavior, but several
|security audit standards are requiring something of this sort.
Thank you for your description of the problem. Maybe I should follow
the following documents in CERT about "FTP Bounce."
From version 9.9.8-pre13, DeleGate acts as your 2) by default.
It can behave as 1) with an option FTPCONF="bounce:cb"
---- Manual.htm#ftp-bounce ----
-- default: FTPCONF=bounce:no
controls how to manipulate FTP Bounce.
no -- reject any FTP Bounce
do -- permit any FTP Bounce
th -- don't care FTP Bounce (backward compatible)
cb -- convert FTP Bounce to "EPRT |||port|"
rl -- reject FTP Bounce by REJECT="ftp-bounce:*:clientHost"
use EPSV (instead of PASV) with FTP servers
use EPRT (instead of PORT) with FTP servers
9 9 Yutaka Sato, CSDP http://delegate.org/y.sato/
( ~ ) National Institute of Advanced Industrial Science and Technology
_< >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller