Полезная информация

Building Internet Firewalls

Building Internet FirewallsSearch this book
Previous: 2.1 Electronic MailChapter 2
Internet Services
Next: 2.3 Remote Terminal Access and Command Execution

2.2 File Transfer

Electronic mail transfers data from place to place, but it's designed for small files, in human-readable form. Electronic mail transfer protocols are allowed to make changes in a message that are acceptable to humans (for instance, inserting ">" before the word "from" at the beginning of a line, so that the mailer doesn't get it confused with a header line), but are unacceptable to programs.[1]

[1] 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 go out and 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.

File Transfer Protocol (FTP) is the Internet standard protocol for this purpose. In theory, allowing your users to bring files in is not an increase of risk over allowing electronic mail; in fact, some sites offer services allowing you to access FTP via email. In practice, however, people will do more file transfers when FTP is available, and are more likely to bring in undesirable programs and data.

What makes these programs and data 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, which tend to take up an annoying amount of time and disk space, but don't represent a major security risk. 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:

How about the other side of the coin: allowing other people to use FTP to transfer files from your computers? This is somewhat riskier. Anonymous FTP is an extremely popular mechanism for giving remote users access to files without having to give them full access to your machine. If you run an FTP server, you can let users retrieve files you've placed in a separate, public area of your system without letting them log in and potentially get access to everything on your system. Your site's anonymous FTP area can be your organization's public archive of papers, standards, software, graphics images, and information of other kinds that people need from you or that you want to share with them. For many organizations, establishing an FTP site is the first step towards doing business on the Internet.

To get access to the files you've made available, users log into your system using FTP with the special login name "anonymous." Most sites request that users enter their own email 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 email 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 8.

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.

UUCP (UNIX to UNIX CoPy) is an older file transfer protocol used over modems, and it is sometimes still used for the transfer of Usenet news and email even over the Internet, particularly by sites with intermittent Internet connections. Such sites use UUCP-over-TCP to obtain their email from their service provider whenever they bring their network connection up. While it used to be common, few sites now provide anonymous UUCP service for file access. As a file transfer protocol, it is of interest only to people who don't have an Internet connection and use modems. Unless your entire business involves providing information for downloading, UUCP is probably not useful for your external users.

File Service Protocol (FSP) is a file transfer protocol developed for circumventing FTP restrictions. Ordinary users can't set up FTP servers, but they can set up FSP servers, and FSP transfers will go through when FTP transfers have been blocked. There are two disadvantages in setting up an FSP server:

FSP does have some actual advantages over FTP - being designed for stealth makes it a very sparing user of resources - but there are almost no legitimate FSP users, and its history makes it unlikely there will be many.

Within a site, you may want to use rcp to transfer files between systems. rcp (described in Chapter 8 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.

Previous: 2.1 Electronic MailBuilding Internet FirewallsNext: 2.3 Remote Terminal Access and Command Execution
2.1 Electronic MailBook Index2.3 Remote Terminal Access and Command Execution