As we have mentioned, turning on the FTP server makes your machine more vulnerable to attacks from the outside. There are other, more secure options you could consider using as alternatives to FTP.
If you turn on the SSH server, two alternatives become available. You can transfer files either with secure copy ( scp ) or secure FTP ( sftp ). Transfers made using scp or sftp are encrypted, thereby providing an extra level of security. Specifically, the client creates a tunnel through SSH, using the standard port 22, and executes an sftp-server process on the server end, which sends data back through the encrypted channel. The sftp and sftp-server executables are part of the SSH package. With FTP, however, passwords are transmitted in cleartext, adding yet another vulnerability to FTP itself.
With the SSH server turned on, you can transfer files to other machines running SSH servers. Likewise, those machines can transfer files to your machine by using scp or sftp . In addition, there exists a freely available Mac OS client that has built-in scp capabilities. For PCs, there's a client that has a built-in sftp client. Running SSH removes almost any need for an FTP server. We discuss SSH in detail in Chapter 14, "Remote Access: Secure Shell, VNC, Timbuktu, Apple Remote Desktop."
As you may recall, wu- ftpd can be built as an anonymous-only FTP server. If your real users are transferring files via scp or sftp , but you still have a need for an anonymous FTP area, you might then consider compiling an anonymous-only FTP server and running that alongside your SSH server.
Regularly checking the anonymous FTP area for any irregularities and keeping your wu-ftpd current are still important activities.
If, for whatever reason, transferring files with the scp and sftp commands isn't sufficient to meet your needs, you can tunnel FTP connections through ssh logins (see Chapter 14 for more information). This enables you to protect the command channel, but can't easily protect the FTP data channel. If you're administering an FTP server, you can moderately increase your system security by using an FTP configuration that encourages users to tunnel their FTP connections into your machine.
As was mentioned earlier, if you provide an open FTP port for your users to connect to, they'll be likely to try it, and likely to enter their user ID and password on the clear-text data channel to attempt login. You can bias your users against this behavior by exploiting wu-ftpd 's capability for configuration and creating specialized FTP servers to handle real and anonymous users. By creating a real-users-only FTP server, using the --disable-anonymous compile-time option for wu-ftpd , you can create a server that allows only real users to log in. To protect this server, you can restrict access to it to only connections originating from the server machine itself. This way, the data from the connections never visibly passes over the network, and any connections that come in over the network are rejected, preventing users from unintentionally disclosing their information. SSH can then be used to create tunnels between the user's client machines and the server, so that their command channels are carried encrypted over the network to the server, and unpacked on the server. Because the connection to the command channel looks (to the FTP server) as if it's coming from the server machine itself (where it's being unpacked), it is allowed, and because it came to the server over the encrypted SSH tunnel, it is protected against prying eyes. Here you'll learn how to configure a wu-ftpd server for this use. Chapter 14 discusses in detail how to set up a client to tunnel an FTP connection to a server configured like this.
You may need the --disable-pasvip option to get the tunneling to function properly.
To make tunneling work on the server side, you have to wrap the FTP server to accept connections only from itself. The easiest way to set up the restriction is to make use of the TCP Wrappers program that comes with the Mac OS X distribution.
In the method that uses only the /etc/ hosts .allow file, you would do this with this syntax:
in.ftpd: <machine-IP> 127.0.0.1 localhost: allow in.ftpd: deny
If you must also have an anonymous FTP server running, or even if you don't, it's a good idea to run the FTP server you're trying to make secure on noncanonical ports for FTP (such as 31 for ftp , 30 for ftp-data ). If you're running an anonymous-only server, leave it running on the standard FTP ports ( 21 for ftp , 20 for ftp-data ).
As you've seen, you don't need to edit anything to run an FTP server on the standard ports. All that's left, then, is to configure your real-user FTP server and install it on an alternate set of ports. Follow these steps:
For ease of administration, it's a good idea to have each FTP server installed in a distinctly separate location. For example, you could install your anonymous FTP server in /usr/local/ftp and your real users' FTP server in /usr/local/wuftp .
Pick a set of unused port numbers . We like ports close to the standard FTP ports for convenience 31 and 30 are our favorites.
Edit the /etc/services file to include the alternate services. You could call them something like wuftp and wuftp-data . Whichever port number you assign to the wuftp service is the one to which the clients wanting to connect need to tunnel.
Again for convenience, name the alternative FTP server itself something similar to the service name , such as wuftpd . It is automatically installed as in.ftpd in whatever location you specified during the build, but you can rename that file.
Finally, wrap the alternative FTP server to allow only connections from itself, but allow the anonymous FTP server access from all machines.
If you also decide to run Mac OS X's built-in firewall, ipfw , you must add statements to allow ipfw to grant access to the alternative FTP server. In addition, set the passive ports control to the ftpaccess file to a range of ports, such as 15001-19999. Then add a statement to the rules for ipfw to allow access to whatever range of ports you specified with passive ports . You might find that you have to keep tweaking your ipfw , anonymous, and real FTP configurations until everything works in harmony. Be sure to check your logs as you're doing this. They're more informative than you might at first realize.
If you decide to run the types of FTP servers suggested in this section, you might find that guest accounts do not work. This appears to be a version-specific bug, or an unexpected consequence of some recent change, as we've used all these capabilities simultaneously before. Also, please note that only the channel that carries the username, password, and command information can be tunneled. The channel that travels between machines when you actually transfer a file using FTP can't be protected in this fashion. For many users, though, this protection is sufficient.