When to Run an
FTP Server
On the surface, FTP servers seem to have a
lot in common with both Web servers (described in href="http:// /?xmlid=0-201-77423-2/ch20#ch20"> Chapter 20 ,
Running Web Servers) and file-sharing servers (described in href="http:// /?xmlid=0-201-77423-2/ch07#ch07"> Chapter 7 , File
and Printer Sharing via Samba, and href="http:// /?xmlid=0-201-77423-2/ch08#ch08"> Chapter 8 , File
Sharing via NFS). All these servers allow for the transfer of complete files
between computers, and so in some situations you may be able to successfully
use any of these server types. Each of these protocols does have its unique
strengths and weaknesses, though, any of which may be important in certain
situations. Major differences between FTP and other file transfer protocols
include the following: Authentication FTP servers require a username/password pair for access. (The
upcoming section, " href="http:// /?xmlid=0-201-77423-2/ch21lev1sec4#ch21lev1sec4"> Setting Up an Anonymous FTP Server ," describes one convention to allow users without a password
to gain access to your server.) Web servers usually don't require authentication,
although there are ways to add authentication to Web sites. Some file-sharing
protocols require username/password authentication, but others rely on IP-based
authentication. Accounts Because of FTP's username/password system, it can be a good way to
provide access to individual users' files from remote locations. NFS and Samba
can also be used in this way. Although Web servers can easily provide users
with access to their files, the public nature of most Web servers means that it
would take more configuration changes to provide security on these accesses. Encryption Standard FTP servers don't encrypt any data, including usernames
or passwords. This makes them risky to use over the Internet at large, although
anonymous mode can reduce some aspects of the risk for certain uses. There are
also a few secure FTP variants available that provide encryption, such as those
that ship with Kerberos (see href="http:// /?xmlid=0-201-77423-2/ch06#ch06"> Chapter 6 ,
Authenticating Users via Kerberos). Web servers don't usually encrypt data, but
secure variants are available. Samba can be configured to encrypt passwords,
and with more work can encrypt all data transfers with a matched Samba system
or a proxy server. NFS doesn't use passwords, so password encryption isn't an
issue, but NFS also doesn't normally encrypt data. The scp and sftp programs,
which are part of the Secure Shell (SSH) package, encrypt all data transfers,
and the latter can be a good substitute for FTP in many situations.TIP

If you must use a protocol that doesn't encrypt passwords,
particularly over an insecure network like the Internet, you should change
your passwords on a regular basis. This will minimize the window of
opportunity for any miscreant who might obtain a password.
Connections FTP, like Samba and NFS, relies upon a continuous connection. A
user can log into an FTP server and, if timeout parameters are set high enough,
do nothing for hours and then transfer a file. Web servers usually operate
differently, performing just one or a few transfers during a session. FTP is
different from most other file exchange protocols in that FTP uses two ports:
one for the control signals and one for actual data transfers. The client
always initiates the control connection to the server's port 21. Depending upon
the mode used (active or passive), the data connection may be initiated by the
client or the server. This odd arrangement can complicate the configuration of firewalls,
although most firewall products include simple ways to handle the issue. Direct file editing The file-sharing servers, such as NFS and Samba, excel at allowing
individuals to edit files from a remote computer as if those files were local. For
instance, a user can load a file directly from the file-sharing server into a
text editor and save the file directly back to the server without having the
file touch the local hard disk. Neither FTP nor HTTP was designed for this
purpose; to edit a file on an FTP or Web server, you must download it to a
local disk, save changes, and then transfer the file back to the server. There
are tools that let some OSs treat FTP servers more like file shares, though. For
instance, the Linux FTP Filesystem ( href="http://ftpfs.sourceforge.net" target="_blank">http://ftpfs.sourceforge.net )
enables this functionality for Linux. This is best considered a
workaround, though. Two-way transfers File-sharing servers and FTP both permit easy two-way transfers,
or permit the server administrator to restrict write access to parts or all of
the server. Web servers are most commonly used for one-way traffic, although
it's possible to transfer files from the client to the server via HTTP. Cross-platform
clients FTP and Web servers both work well with
clients that are widely available on just about any OS that supports TCP/IP,
even DOS. File-sharing protocols, by contrast, are usually more
platform-centricNFS serves UNIX and Linux clients; Samba serves DOS, Windows,
and OS/2 clients; and so on. These lines can often be crossed, but when
crossing platforms with file-sharing clients, there are often drawbacks, such
as restrictions on filenames, permissions, file attributes, and so on. You may
also require unusual or commercial client software that's not necessary to
interact with FTP or Web servers. Ease of server
configuration The default FTP server
configuration on most Linux systems allows individuals to read and write files
on the server with the same access permissions they'd have from a text-mode
login. If this is what you want, FTP server configuration can be fairly
straightforward. To a greater or lesser extent, NFS, Samba, and Web servers
require changes or additional configuration options to provide such access. On
the other hand, to provide anonymous or otherwise restricted access, you may
have to slightly alter an FTP configuration, whereas another server type's
default might be a better match.On the whole, FTP is a good choice for two
purposes: Local access for
local users If your Linux system has local
users, you can run FTP to allow those users to download or upload files from
other systems on your local network. This access might not be quite as
convenient as file-sharing access from the client's point of view, but it may
be easier for you to configure on the server. FTP's cross-platform availability
is also a boon in a cross-platform network. Anonymous access for
remote users Putting up an anonymous FTP site
allows remote users to easily download files from a file repository you
operate, or even to upload files anonymously, if you want to accept such
submissions. A Web server can make a good alternative for this function,
though, particularly if you don't want to accept anonymous uploads. If you
don't want to run a full Web site, the anonymous FTP solution may be just as
good.In both of these cases, you should be alert
to the security implications of FTP. If you want to provide local users with
access to files, you should ensure that only
local users can reach the server; the risk of password sniffing on the Internet
at large is great enough that unencrypted FTP isn't a good choice if you want
to provide local users with remote file access. Indeed, even if used only
locally, you may want to impose mandatory password expiration times to reduce
the risk should you have a local "bad apple" who sniffs passwords. Remote
anonymous access doesn't pose password risks, but you should consider disabling
access for conventional users to minimize the risks of a break-in. Also, providing
anonymous users with write access is potentially quite risky, particularly if
that access isn't restricted to certain controlled directories. If you allow
anonymous write access, you should take steps to keep files from being visible
to others until you've approved them, lest your site become a meeting place for
software pirates or other undesirables.