>On Fri, 20 Dec 1996, Ken Hardy wrote:
>
>> The problem is ...
>>
>> The applet opens a connection back to its home system on port 21, the
>> FTP port. The firewall allows outgoing FTP, so that's fine. The
>> applet then issues a PORT command on the FTP channel to tell the remote
>> FTP server to make a connection to a data socket that it's opened on
>> some other port, as per the FTP protocol spec. The firewall, which
>> normally prevents all inbound connections, sees the PORT command and
>> opens that port to the applet's machine for the incoming FTP transfer.
>>
>> But the firewall is unable to know that the commands are coming from an
>> applet and not a "real" FTP client, and the applet used port 23
>> (telnet) or 25 (smtp) or 139 (netbios) in the PORT command. So now the
>> blackhat's system has an open channel to the chosen port on the machine
>> running the applet. Firewall? What firewall?
>
>Port command? What port command?
>
>Virtually all modern ftp clients support the passive option. I force my
>users to use it for just this reason, and I haven't heard too many
>complaints.
>
>Proxying return FTP connections is going too far in the direction of
>appeasing the user.
>
Isn't this the benefit of using more than one means of protection? A simple
packet filter close this hole, by simply not allowing any inbound traffic
to port 23. For example, our packet filtering allows NO inbound traffic to
ports <1024, except for certain services to certain hosts. So no matter
what the firewall thinks is OK, the packet filter won't let it through. I
would think the problem described above is due more to misconfiguration
than to a real "hole." If I'm wrong, please correct me, someone.
-------------------------------------------------------------
"He who dies with the most toys, still dies."
|
|
