The gate machine is the other half of the firewall. The choke forces all communication between the inside network and the outside network to take place through the gate; the gate enforces security, authenticating users, sanitizing data (if necessary), and passing it along.
The gate should have a very stripped-down version of some operating system. It should have no compiler, for example, to prevent attackers from compiling programs on it. It should have no regular user accounts, to limit the places where an attacker can enter.
You concentrate a great deal of your security effort on setting up and maintaining the gate. Usually, the gate will act as your mail server, your Usenet server (if you support news), and your anonymous FTP repository (if you maintain one). It should not be your file server. We'll discuss how you configure each of these services, and then how to protect the gate.
For these examples, we use a hypothetical domain called company.com. We've named the gate machine keeper.company.com and an internal user machine office.company.com.
Either the choke or the gate must provide Internet Domain Name Service ( DNS ) to the outside network for the company.com domain. Usually, you will do this by running the Berkeley name server ( BIND ) on one of these machines.
Occasionally, the names of computers on your internal network will be sent outside; your name server should be set up so that when people on the outside try to send mail back to the internal computers, the mail is sent to the gate instead. The simplest way to set up this configuration is with a name server MX record. A MX record causes electronic mail destined for one machine to actually be sent to another.
Configure your name server on the gate so that there is a MX record with a wildcard DNS record that specifies all of the hosts within your domain.
For example, this rule specifies that any mail for inside the company.com domain is to go to keeper:
*.company.com. IN MX 20 KEEPER.COMPANY.COM
In this manner, people on the outside network will be able to reply to any electronic mail that "escapes" with an internal name. (Be advised that a specific A record will outweigh a wildcard MX record. Thus, if you have an A record for an internal machine, you will also need to have an MX record for that machine so that the computer's email is properly sent to your mail server.)
There are many advantages to configuring your mail system with a central "post office":
Again, there are advantages to this configuration beyond the security considerations. One benefit is that news is maintained on a central machine, thus simplifying maintenance and storage considerations. Furthermore, you can regulate local-only groups because the gate machine can be set to prevent local groups from being sent outside. The administrator can also regulate which internal machines are allowed to read and post news.
If you wish to support anonymous FTP from the outside network, make sure the ~ftp/pub directory resides on the gate machine. (See Chapter 17 , for information about how to set up anonymous FTP .) Internal users can access the ~ftp/pub directory via a read-only NFS partition. By leaving files in this directory, internal users can make their files available to users on the outside. Users from the outside use FTP to connect to the gate computer to read and write files. Alternatively, you may wish to make these directories available only to selected internal machines to help control which users are allowed to export files.
The best way to give internal users the ability to use FTP to transfer files from remote sites is to use proxies or wrappers. This approach is more secure and easier to configure. Proxies are readily available; consider using the TIS Firewall Toolkit (see Appendix E, Electronic Resources for ways to obtain it), or SOCKS (described in Chapter 22 ). You will need to have an FTP client program that understands proxies. Fortunately, the FTP clients in many World Wide Web browsers already do so. They are also considerably easier to use than the standard UNIX FTP client.
Another way that you can pass FTP through a firewall without using proxies is to create a special account on the gate machine named ftpout . Internal users connect via Telnet or rlogin to the gate and log in as ftpout . Only logins from internal machines should be allowed to this account.
The ftpout account is not a regular account. Instead, it is a special account constructed for the purpose of using the ftp program. If you want added security, you can even set this account shell to be the /usr/ucb/ftp program. When local users wish to transfer files from the outside, they will rlogin to the ftpout account on the gate, use ftp to transfer the files to the gate, log out of the gate computer, and then use a read-only NFS partition to read the files from the gate. The ftpout account should have a UID that is different from every other user on the system - including the ftp user.
The ftpout strategy is less secure than using proxies. It allows users to view files that are brought in by FTP by other users. It also requires the cooperation of your users to manage the disk space on the gate machine. Nevertheless, it is a serviceable strategy if you cannot implement FTP proxies.
There are a number of different ways in which you can protect the ftpout account from unauthorized use. One simple approach follows:
Legitimate users can now use the ftpout by issuing the rlogin command:
% rlogin gate -l ftpout
The ftpout account must log (via syslog , console prints, or similar means), all uses. It must then run the ftp program to allow the user to connect out to remote machines and transfer files locally to the gate.
Using the ftpout account is a cumbersome, two-step process. To transfer files from the outside network to the inside network, your users must follow these steps:
Transferring files from internal machines to machines on the other side of the firewall requires a similar roundabout process.
The advantage of the ftpout system is that it allows users to import or export files, but it never makes a continuous FTP connection between internal and external machines. The configuration also has the advantage that it lets you keep a central repository of documents transferred via FTP , possibly with disk quotas. This configuration saves on storage. (Be advised, though, that all users of the ftpout account will share the same quota. You may wish to install a cron job that automatically deletes all files in the ftpout directory that have not been accessed in more than some interval, such as 90 minutes.
You can create additional accounts, similar to ftpout , for users who wish to finger people on the outside. You can use a scheme exactly like the one described above for FTP to let local users use Telnet with remote sites. Do not use the same user ID and group for the telnetout account that you used for the ftp command.
Alternatively, you can create your own dedicated servers or proxies on the gate for passing finger , Telnet, and other services.
Many sites using gates disable the finger service, because finger often provides too much information to outsiders about your internal filesystem structure and account-naming conventions. Unfortunately, the finger command also provides very useful information, and disabling its operation at a large site may result in considerable frustration for legitimate outside users.
As an alternative, you can modify the finger service to provide a limited server that will respond with a user's mailbox name, and optionally other information such as phone number and whether or not the user is currently logged in. The output should not provide the home directory or the true account name to the outside. The output also should not provide the last login time of the account; intruders may be able to use this information to look for idle accounts.
The biggest difficulty with firewall machines arises when a user is offsite and wishes to log in to his or her account via the network. After all, remote logins are exactly what the gate is designed to prevent! If such logins are infrequent, you can create a temporary account on the gate with a random name and random password that cannot be changed by the user. The account does not have a shell, but instead executes a shell script that does an rlogin to the user's real account. The user must not be allowed to change the password on this gate account, and must be forbidden from installing the account name in his or her local .rhosts file. For added security, be sure to delete the account after a fixed period of time - preferably a matter of days.
If there are many remote users, or users who will be doing remote logins on a continuing basis, the above method will work but is unlikely to be acceptable to most users. In such a case, we recommend using the setup described above, with two changes: let users pick a gate account name that is more mnemonic, and force them to use some type of higher-security access device, such as a smart card ID, to access the gate. If passwords must be used on the gate accounts, be sure to age them frequently (once every two to four weeks), and let the machine generate the passwords to prevent users from setting the same passwords as those for their internal accounts.