 | Chapter 21 Firewalls |  |
| Chapter 21 Firewalls | |
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).[9] It should not be your file server. We'll discuss how you configure each of these services, and then how to protect the gate.
[9] We advise against putting your anonymous FTP depository on your firewall. However, if your resources are really so limited that you can't obtain another machine, and if you absolutely must have FTP enabled, this is the way to do it.
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.[10]
[10] There are many nuances to configuring your DNS service in a firewall situation. We recommend you see DNS and BIND by Albitz and Liu, and Building Internet Firewalls by Chapman and Zwicky, both published by O'Reilly & Associates.
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.)
Configure the gate so all outgoing mail appears to come from the gate machine; that is:
All mail messages sent from the inside network must have the To:, From:, Cc:, Sender:, Reply-To: and Errors-To: fields of their headers rewritten so an address in the form [email protected] is translated to the form [email protected].
Because all mail from the outside is sent through the gate, the gate must have a full set of mail aliases to allow mail to be redirected to the appropriate internal site and user.
Mail on the internal machines, like office, must have their mailers configured so that all mail not destined for an internal machine (i.e., anything not to a company.com machine) is sent to the gate, where the message's headers will be rewritten and then forwarded through the choke to the external network.
All UUCP mail must be run from the gate machine. All outgoing UUCP messages must have their return paths rewritten from company!office!user to company!user.
There are many advantages to configuring your mail system with a central "post office":
Only one machine needs to have a complex mailer configuration.
Only one machine needs to handle automatic UUCP path routing.
Only one machine needs to have a complete set of user aliases visible to the outside.
If a user changes the name of his or her computer, that change needs to be made only on the gate machine. Nobody in the outside world, including electronic correspondents, needs to update his or her information; the change can easily be installed by the administrator at the gate machine.
You can more easily use complete aliases on your user accounts: all mail off- site can have firstname_lastname in its mail header.
If a user leaves the organization and needs to have his or her mail forwarded, mail forwarding can be done on the gate machine. This eliminates the need to leave old accounts in place simply to allow a .forward file to point to the person's new address.
Configure news so the gate machine is the main news machine in the organization:
All outgoing articles must have the Path: and From: lines set to show only the gate machine. This setup is not difficult to do if the news is present only on the gate machine - standard news software provides defines in the configuration file to build the headers this way.
Internally, news can be read with NNTP and rrn, trn, nn, xrn, etc.
Alternatively, the news spool can be directory (usually /usr/spool/news) exported read-only by the gate machine to the internal machines. Posting internally would still be via NNTP and inews.
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.[11]
[11] Note that running NFS on the gate just for FTP access is dangerous and we do not recommend it.
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.[12] 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.
[12] Because the account has /usr/ucb/ftp as its shell, the FTP program's shell escape (!) will not work properly. This prevents the ftpout account from being used for other purposes.
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:
Create the ftpout account on the gate with an asterisk (*) for a password (doing so prevents logins).
Make the ftpout account's home directory owned by root, mode 755.
Create a file ~ftp/.rhosts, owned by root, that contains a list of the local users who are allowed to use the ftpout service.
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:
Log into the ftpout account on the gate.
Use the ftp command to transfer files from the outside computer to the gate.
Log out of the ftpout account.
Connect to the gate computer using the ftp command from the user's own machine.
Transfer the files from the gate to the user's personal workstation.
Delete the files on the gate.
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.[13]
[13] Actually, consider not allowing rlogin in the first place and just using Telnet. And beware of password sniffers, who don't care if your name and password are random.
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.
|  | |
| 21.3 Example: Cisco Systems Routers as Chokes |  | 21.5 Special Considerations |