Here a brief explaination on the security on Passive FTP.
This has the same impact on the machines running passive ftp now a days

As you know, FTP is a TCP/IP application-level protocol—not a Microsoft invention. Passive FTP is described as part of the FTP protocol specification in IETF Request for Comments (RFC) 959, which you can find at http://www.w3.org/protocols/rfc959. Before I explain passive FTP (sometimes called PASV for the actual FTP command that requests this kind of connection), let me review how standard, or active, FTP works.

In active mode, an FTP client connects from a random unprivileged port (N > 1024) to the FTP server’s control port 21. The client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server connects back to the client’s specified data port from the server’s data port (by default, port 20). These steps describe FTP active mode events:

1.The client (from port X, a random port number greater than 1024) connects to the FTP server on port 21 and requests a connection.
2.The FTP server performs security checks. In this order, the server checks whether
■the IP address is allowed
■the user is permitted
■the FTP site permits Read (if a Read request) or Write (if a Write request) access
■NTFS permissions allow the requested access
If the client meets all these security criteria, the connection process continues.

•The client waits for a connection from the FTP server on port X+1. (The FTP server usually uses port 20 to initiate contact with the client’s port X+1.)
When I first explored how FTP works, I was surprised to find that the server initiates contact to the client to deliver data—thus, FTP is active. To the client, an outside server appears to have initiated contact, an action many firewalls don’t allow—with good reason. Any computer could use the client computer’s open port to send information to the client.

Developers created passive FTP to address the security problem of having the client computer wait for server contact (and the resulting conflict with firewall rules). When you use passive FTP, the client initiates both connections to the server:

1.The client (from port X, a random port number greater than 1024) connects to the FTP server on port 21 and requests a connection.
2.The FTP server performs all security checks.
3.The client issues a PASV command to the server.
4.The server responds by sending a PORT command back to the client that includes a random port number greater than 1024 (e.g., port Z).
5.The client connects from port X+1 to port Z on the FTP server to transfer data.
Passive FTP clearly solves a client-side FTP problem. However, it creates new problems on the server side because to support passive FTP, you must let the client connect to any high port on the server. Fortunately, because the client initiates both the control and the data port connections, many firewalls can monitor the requests and permit the connections even though they aren’t on standard FTP ports.

Having distinguished active FTP from passive FTP, I can now address your questions about whether passive FTP is a major security risk and—if it is—how you can address that risk. In general, FTP is a security risk because of insecure logon mechanisms. That statement aside, you need to know about one other problem.

In my description of the passive FTP event sequence, note that in Step 4, the server sends the client a random port number greater than 1024. IIS 4.0 does exactly that; however, IIS 5.0, by default, assigns passive port numbers sequentially. For example, the first client connects to the FTP server on port 2055. IIS assigns the next FTP client request port 2056, the one after that port 2057, and so forth. If you can determine what FTP port is in use, you know what port IIS will assign next. If you can then connect to that port, IIS won’t require you to authenticate because that port is part of a previously authenticated FTP session. After you’re connected, you might be able to read or write data to the server. (See the Microsoft article “IIS Answers PASV Commands with Port Numbers in Sequential Order” at http://support.microsoft.com/support/kb/articles/q260/9/34.asp for information about this IIS 5.0 behavior.) Windows 2000 Service Pack 1 (SP1) alters this IIS 5.0 behavior so that FTP offers random port numbers just as IIS 4.0 does. A registry entry can disable this IIS 5.0 behavior on Win2K servers that don’t run SP1. However, because of the numerous other IIS fixes that the Win2K service packs contain, I strongly suggest that you apply the latest service pack rather than edit the registry.