begin quoting Tracy R Reed as of Mon, Jan 30, 2006 at 02:26:27AM -0500: [snip] > I disagree. There is nothing inherently wrong with FTP. FTP opens a > command channel which exchanges commands with the host and when it is > time to transfer a file it opens another channel on a negotiated > ip/port. Many protocols work this way including the relatively recent > (compared to FTP) SIP protocol. It is a perfectly valid way to handle > things. NAT breaks the end to end nature of the internet and causes the > protocols involved to have to be much more complicated and handle > everything within one TCP session.
Don't blame NAT for that. Blame default-deny policies (the only sensible policy, IMNSHO), as a default-deny firewall would break things in exactly the same way -- why is why some people go with default-allow instead of default-deny... (against the advice of the security weenies). FTP is considered a security risk in part because of clear-text passwords, but also for its ability to map out networks behind firewalls. The "open a channel back to <IP>" capability is not a feature, it's a broken design. (Shoot, if machine A connects to machine B, why would you want machine B to make a connection back to machine A? Both programs now need to create and manage client and server sockets. Far simpler for machine B to give machine A a magic token on the control channel, and for machine A to contact machine B (again) using the magic token. Even HTTP gets it right.) We can't criticize 'em too much, 'cuz they were inventing it all as they went along; now, however, you'd think we'd've learned something, and would stop making the same old mistakes. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
