FTP.microsoft.com initiates all data port connections from random,
high-numbered TCP ports, instead of the RFC-mandated port 20. This apparently
was intentional- there's a registry setting called "EnablePortAttack" that,
when turned on, will cause the server to initiate connections from 20 again.
Of course, the reason I noticed this is that we were using a filtering rule for
some machines in our firewall that allowed incoming TCP connections from port
20 to high-numbered destination ports so that outbound FTP would work. Since
ftp.microsoft.com's FTP-data connections weren't coming from port 20, they
weren't allowed in.
I don't completely understand the rationale behind this "fix", and I'm
wondering if there's some general weakness in the FTP protocol that I'm not
aware of that they're trying to address. I'm familiar with the "FTP Bounce"
attack (see ftp://avian.org/random/ftp-attack), and I'm wondering if this is
some strange way of ensuring that somebody using an NT FTP server as the
middleman in such an attack isn't initiating connections from a low-numbered
port. Anybody know more?
-Robert
--
Robert Dana <bob @
worldcom .
com> (713) 650-6522 x40
WorldCom Director of Network Services
Wolf Communications, Houston, TX Go WorldCom!
|
|
