[3]Inserting ">" before "From" is so common that some published books still contain the occasional ">From" in the text, where the ">" was inserted as authors exchanged drafts via electronic mail.Although electronic mail systems these days include elaborate workarounds for such problems, so that a large binary file may be split into small pieces and encoded on the sending side and decoded and reassembled on the receiving side, the workarounds are cumbersome and error prone. Also, people may want to actively look for files, instead of waiting for someone to send them. Therefore, even when electronic mail is available, it's useful to have a method designed for transferring files on request.
Furthermore, you may not want to transfer files between machines; you may want to have a single copy of a file but use it on multiple machines. This is file sharing. File sharing protocols can be used as file transfer protocols (first you share the file, then you make a local copy of it), but they also allow you to use a file more or less as if it were a local file. File sharing is usually more convenient than file transfer for users, but because it provides more functionality, it is less efficient, less robust, and less secure.
Printing is often based on file sharing or file transfer protocols; this makes a certain amount of sense, since you have to transfer the data to the printer somehow.
What makes these files undesirable? The primary worry at most sites is that users will bring in Trojan horse software. Although this can happen, actually the larger concern is that users will bring in computer games, pirated software, and pornographic pictures. Although these are not a direct security problem, they present a number of other problems (including wasting time and disk space and introducing legal problems of various sorts), and they are often used as carriers for viruses. If you make sure to do the following, then you can consider inbound FTP to be a reasonably safe service that eases access to important Internet resources:
To get access to the files you've made available, users log into your system using FTP with a special login name (usually "anonymous" or "ftp"). Most sites request that users enter their own electronic mail address, in response to the password prompt, as a courtesy so that the site can track who is using the anonymous FTP server, but this requirement is rarely enforced (mostly because there is no easy way to verify the validity of an electronic mail address).
In setting up an anonymous FTP server, you'll need to ensure that people who use it can't get access to other areas or files on the system, and that they can't use FTP to get shell-level access to the system itself. Writable directories in the anonymous FTP area are a special concern, as we'll see in Chapter 17, "File Transfer, File Sharing, and Printing".
You'll also need to ensure that your users don't use the server inappropriately. It can be very tempting for people to put up files that they want specific people to read. Many times people don't realize that anybody on the Internet can read them, or they do realize this but believe in security through obscurity. Unfortunately for these innocents, a number of tools attempt to index anonymous FTP servers, and they succeed in removing most of the obscurity.
You may have heard of other file transfer protocols. Trivial File Transport Protocol (TFTP) is a simplified FTP protocol that diskless machines use to transfer information. It's extremely simple so that it can be built into hardware, and therefore supports no authentication. There's no reason to provide TFTP access outside of your network; ordinary users don't transfer files with TFTP.
Within a Unix site, you may want to use rcp to transfer files between systems. rcp (described in Chapter 18, "Remote Access to Hosts", with the rest of the so-called "Berkeley `r' commands") is a file transfer program that behaves like an extended version of the Unix cp command. It is inappropriate for use across the Internet because it uses a trusted host authentication model. Rather than requiring user authentication on the remote machine, it looks at the IP address of the host the request is coming from. Unfortunately, you can't know that packets are really coming from that host. There is an rcp replacement called scp that provides considerably more security, including user authentication and encryption of the data that passes across the network; it is also discussed in Chapter 18, "Remote Access to Hosts", along with the ssh command on which it is based.
The most commonly used file sharing protocols are the Network File System (NFS) under Unix, the Common Internet File System (CIFS) under Microsoft Windows, and AppleShare on the Macintosh. CIFS is part of a family of related protocols and has a complex heritage, involving Server Message Block (SMB), NetBIOS/NetBEUI, and LanManager. You will see all of these names, and some others, used to refer to file sharing protocols on icrosoft operating systems. Although there are differences between these protocols, sometimes with radical security implications, they are interrelated and, for the most part, interoperable, and at the highest level, their security implications are similar. In fact, at the highest level, all of the file sharing protocols have similar implications for firewalls; they are all insecure and difficult to use across the Internet.
NFS was designed for use in local area networks and assumes fast response, high reliability, time synchronization, and a high degree of trust between machines. There are some serious security problems with NFS. If you haven't properly configured NFS (which can be tricky), an attacker may be able to simply NFS-mount your filesystems. The way NFS works, client machines are allowed to read and change files stored on the server without having to log in to the server or enter a password. Because NFS doesn't log transactions, you might not even know that someone else has full access to your files.
NFS does provide a way for you to control which machines can access your files. A file called /etc/exports lets you specify which filesystems can be mounted and which machines can mount them. If you leave a filesystem out of /etc/exports, no machine can mount it. If you put it in /etc/exports, but don't specify what machines can mount it, you're allowing any machine to mount it.
A number of subtler attacks on NFS are also possible. For example, NFS has very weak client authentication, and an attacker may be able to convince the NFS server that a request is coming from a client that's permitted in the exports file. There are also situations where an attacker can hijack an existing NFS mount.
These problems are mostly due to the fact that NFS uses host authentication, which is easily spoofed. Because NFS doesn't actually work well across the Internet in any case (it assumes a much faster connection between hosts), there isn't much point in allowing it between your site and the Internet. It creates a security problem without adding functionality.
CIFS and AppleShare both rely on user authentication instead of host authentication, which is a slight improvement in security. However, AppleShare is not capable of supporting flexible methods of user authentication with normal clients. You are limited to using reusable passwords, which means that attackers can simply capture passwords. CIFS can provide good authentication and good protection in recent versions. However, backward compatibility features in CIFS increase its vulnerability, as it attempts to support older clients that have much weaker security. Furthermore, CIFS actually provides an entire family of services, some of them even more vulnerable than file sharing. (For instance, it provides a general-purpose remote procedure call mechanism that can be used to allow arbitrary programs to communicate with each other.) Although it is possible for a firewall to understand CIFS and allow only some operations through (in order to allow CIFS file sharing but not other CIFS-based protocols), this is quite complex, and few firewalls are capable of it. It's also not clear how useful it would be, since file sharing and other services are intertwined; the commands for reading data from files and for reading data from other programs are the same.
There are file sharing protocols designed for use on networks like the Internet; for instance, the Andrew File System (AFS) uses Kerberos for authentication, and optionally encryption, and is designed to work across wide area networks, including the Internet. NFS, CIFS, and AppleShare are all shipped as part of popular operating systems, while AFS is a third-party product. Because of this, and because AFS and Kerberos require significant technical expertise to set up and maintain, AFS is not widely used outside of a small number of large sites. If you have a need to do secure, wide area network filesystems, it may be worth investigating AFS, but it is not covered here.
[4]Or recombine the protocols and operating systems in any combination you wish, as all three platforms will support all the protocols if you install enough extra software.