< Day Day Up > 

Alternatives to FTP

As we've 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.

scp and sftp

As you already saw in Chapter 21, "Accessing and Controlling Tiger Remotely," two alternatives become available when you turn on the SSH server. 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. Unlike SSH, the FTP protocol and servers we've covered earlier in this chapter transmit passwords in clear text, adding yet another vulnerability to FTP itself. This makes scp or sftp a strongly preferred option for users that can use them (appropriate clients are necessary on the client end).

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 (Classic) Mac OS client that has built-in scp capabilities. For PCs, there are clients with built-in sftp clients. Running SSH removes most needs for an FTP server for real users of your machine. It does not provide a useful substitute for providing data or data-exchange capabilities to anonymous users, or FTP-guest type users. For these purposes, FTP still rules the roost.


As you might recall, proftpd can be configured as an anonymous-only FTP server. If your real users are transferring files via scp or sftp but you still need to distribute files to anonymous users, you might then consider running an anonymous-only FTP server alongside your SSH server.

Regularly checking the anonymous FTP area for any irregularities and keeping your proftpd current remain important activities.

Tunneling FTP over SSH

If, for whatever reason, running the SSH server is not sufficient to meet your users' needs, you can tunnel FTP connections through ssh logins. 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 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 proftpd's capability for configuration and creating specialized FTP servers to handle real and anonymous users. By removing the <Anonymous> context that comes with the default proftpd.conf file, 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 users' 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 proftpd server for this use.

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 use the only_from directive in xinetd. For machine, such an entry looks like:

 only_from       = localhost 

Another easy way to set up the restriction is to use the TCP Wrappers program that comes with the Mac OS X distribution.

In an enhanced /etc/hosts.allow file, you would do this with the following syntax:

 in.proftpd: <machine-IP> localhost: allow in.proftpd: deny 

If you use TCP Wrappers, you must also indicate this in /etc/xinetd.d/ftp. Add NAMEINARGS to the flags, which tells xinetd that the server itself and its runtime options are listed in the server_args directive. The server directive then lists tcpd. Here is a sample /etc/xinetd.d/ftp file using TCP Wrappers:

 service ftp {         disable = no         socket_type     = stream         wait            = no         user            = root         server          = /usr/libexec/tcpd         server_args     = /usr/local/PROftpd/sbin/in.proftpd         groups          = yes         flags           = REUSE NAMEINARGS } 

Finally, have xinetd re-read its configuration file by running killall -HUP xinetd.

If you must also have an anonymous FTP server running, and 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 alternative 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/proftp.


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 alternative services. You could call them something like proftp and proftp-data. Whichever port number you assign to the proftp service is the one to which the clients wanting to connect need to tunnel.


Set the Port directive to whatever port you have picked for the command channel.


Finally, wrap the alternative FTP server to allow connections from only 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 PassivePorts directive 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 and 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 realize now.

Don't worry if the wrapping concept or ipfw seems confusing right now. Use of TCP Wrappers and ipfw is discussed in Chapter 28. These details are mentioned here so that you can quickly find a summary of the important information about running two FTP servers in one place. We recommend that, where possible, you use scp and sftp instead of running an FTP server.

     < Day Day Up > 

    Mac OS X Tiger Unleashed
    Mac OS X Tiger Unleashed
    ISBN: 0672327465
    EAN: 2147483647
    Year: 2005
    Pages: 251 © 2008-2017.
    If you may any questions please contact us: