The Gauntlet system includes a network browser-based interface (“forms-based”) designed to make it easy for you to quickly configure and run the system. The Gauntlet management interface supports all common Gauntlet administrative functions and is organized (like this chapter) into the following browser forms:
![]() | Note: In addition to the use of the browser interface, you may, if you prefer, directly modify some of the files that this interface configures. Refer to “Viewing the Gauntlet File List” for more information. |
For initial configuration, you may prefer to simply step through the forms in order by selecting the Continue button at the bottom of each form as you finish with each form. Return to the previous form by clicking on Back. As you become more familiar with the interface and your configuration, you may prefer to go directly to any form by clicking on the appropriate form name in the bars at the top and bottom of a form.
You can view additional information on many subjects by selecting any linked word or phrase on the form. You can “unclutter” forms by hiding sections that you are already familiar with or that do not concern you. To hide a section of a form, click on the Hide button, shown in Figure 3-1.
The selected area is hidden from view and is represented by an Unhide button, shown in Figure 3-2.
Click on the Unhide button to display more detailed configuration information on the corresponding section.
![]() | Caution: Clicking on Hide or Unhide buttons causes any unsaved changes on that page to be thrown away. |
When you are satisfied with your configuration of a form, select Save at the bottom of the form. (In some forms, separate portions are added to databases when you select the Add button, and there is no general Save button for those forms.) Any known error in your configuration of the form is reported at this time, and you are given the opportunity to fix the error. You must save the configuration of each form you modify while you are still in the form for your modifications to be remembered. Note that clicking Add or Save does not cause any actual system configuration to take place—you can still exit or change any of the fields on any of the forms until you select the Configure All button at the bottom of the initial introductory form.
Do not select Configure All until you are sure that all of the forms are set up as you want them. Many (but not all) forms provide defaults which may suit your situation; the defaults are conservatively chosen so that network services are disabled until you specifically enable them.
To access the management interface, you must be logged in as root. The command to start the management interface is gauntlet-admin. In a few seconds, a browser form requesting the Gauntlet administrative password should appear on your display. (If this is the first time you have run gauntlet-admin, you are prompted to create a Gauntlet administrative password. Also, if there is no root password on the Gauntlet host, you are prompted to enter a root password.) Refer to “Remote (Network) Connections” for information on remote access to the administrative interface.
The following sections describe each of the Gauntlet management forms. Note that the forms-based interface is designed to be self-sufficient, and it may present enough information for you to make all appropriate configuration decisions. This documentation is intended to provide additional background information and may considerably overlap the information available through the forms.
Figure 3-3 and Figure 3-4 illustrate the Gauntlet introductory management form. This form is both the entry point and the exit point of the forms-based management interface. From this form, you can go directly to any of the other management forms, or begin a sequential configuration sequence. When you have configured all the forms as desired, you must return to this form and select Configure All for the actual Gauntlet system configuration to occur.
![]() | Caution: Do not select Configure All until you have configured all the other forms appropriately. |
The introductory management form describes how to use the forms-based interface, and then contains a list of form names at the bottom of the page that allow you to access another form, go to the next form, or configure your system.
The section of the form called “Getting Started” provides a Minimize Exposure button which you can click to reduce possible security risks. If you click Minimize Exposure, the system reports on what it looks for and on any changes made. If there are areas where it cannot make changes but changes are considered desirable, those are reported too.
You begin configuring your firewall in the “First Time Configuration” section by clicking Begin Configuration, but first read “Managing Your Firewall” for some issues regarding direct file editing.
The last part of the introductory management form displays the sections covered by each of the other browser forms, and a list of links to those other forms is in the bar on the bottom if you wish to go directly to any of them. This document follows the sequential procedure you will follow if you click Begin Configuration on this form and each Continue button on the following forms.
If you want to see a list of the files that the Gauntlet configuration manipulates, click on the view link in the “Managing Your Firewall” portion of the introductory form. If you do not want to use the forms-based interface, you can directly edit these files although we do not recommend doing so. Refer to Table 3-1 for reference page information on the command line interface.
Table 3-1. Gauntlet File and Command Line Documentation
Reference Page | Description |
|---|---|
authmgr(1M) | network authentication client program |
authsrv(1M) | network authentication daemon |
ftp-gw(1M) | FTP proxy server |
http-gw(1M) | Gopher/HTTP proxy |
netacl(1M) | TCP network access control |
plug-gw(1M) | generic TCP plugboard proxy |
rlogin-gw(1M) | rlogin proxy server |
rsh-gw(1M) | rsh proxy server |
tn-gw(1M) | Telnet gateway proxy |
smap(1M) | sendmail wrapper client |
smapd(1M) | sendmail wrapper daemon |
tn-gw(1M) | TELNET proxy server |
x-gw(1M) | X gateway service |
netperm-table(4) | configuration and permissions database |
The Gauntlet networks and interfaces configuration form (Figure 3-5 and Figure 3-6) uses the standard Silicon Graphics Network Setup tools to configure the firewall's network interfaces. If you have not already configured your network setup with these tools, click Network Setup to configure the firewall hostname, network interfaces, and IP addresses; click ISDN Setup to configure ISDN; and click PPP Setup to configure PPP.
The Gauntlet networks and interfaces configuration form allows you to specify trusted and untrusted networks (see “Base Policy”). Until you make changes on this form, all networks are considered untrusted, and only the Gauntlet system itself is trusted.
You can use a terminating asterisk as a wildcard to represent “all” in network addresses, for example:
192.168.128.*—all IP addresses beginning with “192.168.128”
192.168.*—all IP addresses beginning with “192.168”
*—all IP addresses
![]() | Note: Something like 192.*.128.* won't work; only a terminating asterisk is allowed. |
The Gauntlet Firewall supports the concept of “trusted networks.” These are the networks that are permitted to use firewall services without user authentication (see “Authorizing Users Form”). Typically, the trusted networks are your internal, local networks.
Click on the ADD button and then specify the IP address of each network you want to add to the list of trusted networks.
If a network is neither trusted nor untrusted, users from that network will not be permitted to use the firewall services nor even attempt authentication. For this reason, the typical default entry for untrusted networks is all networks (other than those indicated configured as trusted), represented as a single asterisk. This means that users from any network other than an explicitly trusted one must pass authentication.
You can add to the list of untrusted hosts by clicking on the ADD button. If you list only specific network addresses as untrusted, that means that those networks may access your network if they pass authentication, but no other networks (except explicitly trusted networks) may even attempt authentication (access is immediately refused). If you leave the list of untrusted hosts blank, that means that no network access (other than from specifically trusted networks) is allowed to attempt authentication. All such access is immediately refused.
Users from an untrusted network can still access firewall resources if they have an entry in the authentication database of the firewall, that is, they are specifically allowed to use the services. Refer to “Authorizing Users Form” for information on how to establish user authentication.
Specifying trusted interfaces allows the firewall to guard against IP address spoofing. If informed about which network interfaces are connected to trusted networks, Gauntlet will require that packets claiming to be from a host on a trusted network come over one of the trusted interfaces.
Specifying trusted interfaces is required—you cannot have trusted networks without trusted interfaces.
Specifying trusted ports allows you to permit traffic through the firewall (completely unimpeded) for protocols and applications for which you do not have a proxy. InPerson™ is an example of an application that requires direct access to specific ports in order to work through a Gauntlet firewall. Note that this is only relevant when the Gauntlet firewall is positioned to be the router between internal and external networks.
Use the routing configuration form (Figure 3-7) to specify your routing implementation.
If you already have a customized routing configuration file for gated on the Gauntlet host and want to keep using it, check the box for “Preserve the gated.conf file if it exists?”
If you are going to let Gauntlet generate a new gated.conf file, click on ADD under Explicit Routes and then add the network, gateway, and “hop” metric to each network you add. (Use a metric of “0” if the gateway is an interface on the Gauntlet host, and a “1” if it is anywhere else.)
Entering a destination network as “default” sets the default route.
Figure 3-8 illustrates an example routing configuration.
If hosts on your internal network are running a routing daemon, they should eventually acquire the default route from the Gauntlet host, or the route can be explicitly added to those hosts by their administrators.
The proxy server configuration form (Figure 3-7 and Figure 3-11) allows you to control network services through the Gauntlet firewall. You can enable and disable particular services, specify timeout values and port numbers, and so on. Each service can be configured separately.
If you want to allow network logins to the firewall, specify this by checking the box for “Do you want connections allowed TO the firewall?” If this box is not checked, you must configure the firewall at the system console—not from a network login. Network logins are convenient, but could lessen the security of the firewall.
When logins are enabled, administrators can connect to the firewall by accessing the rlogin or telnet proxies. Example 3-1 illustrates a sample Telnet session.
magnolia-% telnet fwall Trying 127.0.0.1 port 23... Connected to localhost. IRIX System V.4 (rfwall) login: root Password: IRIX Release 5.3 IP22 rfwall Copyright 1987-1994 Silicon Graphics, Inc. All Rights Reserved. Last login: Wed Aug 16 14:05:49 PDT 1995 by UNKNOWN@localhost You have mail. rfwall 1# setenv DISPLAY magnolia.abc.sgi.com:0 rfwall 2# gauntlet-admin |
![]() | Note: If you log in from the network (you must have enabled network logins) to the firewall host, you may need to set the DISPLAY environment variable to your host to be able to use gauntlet-admin. |
![]() | Caution: Network logins should only be used over secure links when absolutely necessary. Another option for remote access to the firewall is to connect a modem to one of the serial ports to enable controlled dial-in access for administrators only. |
You must also specify if you want to enable transparent proxies. With transparent proxies, user requests to connect to a particular service on an external host using a supported application protocol, pass through the proxy server as if the user were communicating directly with the network host. If you do not enable transparent proxies, the user must first connect to the proxy server, and then from the proxy server, connect to the desired network host. Transparent and non-transparent connections are illustrated in Figure 3-9.
Next, specify which services you want to enable. Many of the services allow you to specify a timeout value (click the Unhide button if you don't see it) so change the default timeout value of any service if it does not suit your needs. (The timeout value is the number of seconds the server maintains a connection before it times out due to inactivity.)
If you enable a service, it means the firewall will run a daemon supporting that service. For example, enabling Telnet means that a proxy Telnet server will run on the Gauntlet firewall to mediate and enable Telnet connections. It will be a transparent Telnet proxy if you have enabled transparent proxies. Note that you must also have configured the Networks/Interfaces Configuration Form correctly for the service to work.
If you enable FTP on the firewall, you can specify a timeout value and also specify if you want to enable anonymous FTP. The Gauntlet configuration sets up anonymous FTP according to the recommendations in “Setting Up Anonymous FTP” in the IRIX Advanced Site and Server Administration Guide. Also, if enabled, anonymous FTP prevents users from untrusted networks from using the FTP application proxy.
If you enable the Telnet proxy, enter a number of seconds for it to timeout when idle (or accept the default of 3600 seconds—one hour).
If you enable the rlogin proxy, enter a number of seconds for it to timeout when idle (or accept the default of 3600 seconds—one hour).
Check these boxes to enable the corresponding proxy server. No further configuration is required. X Windows is for use in conjunction with telnet and rlogin proxies only. See x-gw(1M) for an example session.
If you enable HTTP (Hypertext Transfer Protocol for World Wide Web access), you must also specify the following:
which port the HTTP server should use—the default is “8080”.
which user ID the HTTP server should use—the default is “uucp”.
which group ID the HTTP server should use—the default is “6”.
which default URL the HTTP server should provide—the default is “” (none).
NNTP Proxy Server Configuration
Enable NNTP for USENET News access. If configured with the addresses of an internal and external news server, the firewall gateways NNTP traffic bidirectionally between the two systems. Host IP addresses or DNS names may be used. When configuring news on the internal and external servers, both systems should be set to feed news to the firewall, rather than attempting to exchange it directly. For example, if the internal news server is “nntp.sgi.com” with IP address 192.33.112.100 and the external news feed is “news.uu.net” with IP address 11.11.11.11, configure the proxy with the appropriate names and addresses, and then configure the news software on “nntp.sgi.com” to transfer articles to the firewall. The upstream news feed “news.uu.net” would also transfer articles to the firewall.
The DNS configuration form (Figure 3-12) helps you configure the files necessary to run a minimal DNS master server configuration for your site. This configuration is enough to function as the external server in a dual-DNS configuration, or as the basis for a site-wide server or other site-specific server. If you are the site-wide DNS server, add appropriate entries for each of the hosts on your network. If you prefer to preserve your existing DNS configuration, be sure that the “Preserve the current DNS configuration?” box at the top of this form is checked, because the default is to not preserve the current configuration.
When you join the Internet, you will need to participate in the Internet-wide DNS hierarchy. There are several popular methods of having your site's DNS information available on the Internet. Some sites have their service provider serve the information for them. For sites that choose to run their own DNS server, there are two common firewall configurations. One involves running two DNS servers, an internal and an external server. This is often referred to as a split-DNS or dual-DNS configuration. The other involves running a fully-populated DNS server on the external host. In either case, the GAUNTLET host would be a common choice to run a DNS server on, either as the external part of a dual-DNS configuration, or as the single DNS server for the site.
DNS, the name service used on the Internet, should be configured for your site to give out the addresses that other sites need to contact you. This might include the address of your router, your firewall host, and any other machines you want others to be able to communicate with. In the case of a simple firewall comprised of a dual-homed host, the dual-homed host would be a DNS server, providing the address of the Internet side of its network connection. In the case of a screened subnet, the DNS server could be any of the “public” hosts in the subnet, and it could provide addresses for all of these hosts and the router.
You should also set up the DNS Mail eXchanger (MX) record to advertise the name of the host(s) responsible for mail at your site. This may be the firewall host or another host. Do not publish internal hostnames and addresses on the firewall host. If you have a single firewall host performing multiple services, say FTP and WWW serving, use CNAME records to “alias” the services to the hostname. This makes it easy to move these services to different hosts if you want to separate them later.
Configuring DNS is a task that is very difficult to automate reliably, as many sites' DNS configurations vary widely. The purpose of the DNS configuration tools included with the Gauntlet firewall is to give the administrator a quick means of setting up a basic, working DNS. More advanced DNS management will require manual operation and familiarity with the DNS software.
Gauntlet uses the Silicon Graphics example DNS configuration files to configure DNS for your firewall. If you are not sure how to fill in the DNS configuration form, refer to the chapter on “The BIND Name Server” in the IRIX Advanced Site and Server Administration Guide.
Use the Sendmail configuration form (Figure 3-13) if you want to use the Gauntlet browser-based interface to modify the Gauntlet firewall's Sendmail configuration. If you prefer, you can use the IRIX configmail tool, or edit the
/etc/sendmail.cf file directly. Be sure to check the Preserve the current sendmail.cf file? button if you do this, because the default is to not preserve the current configuration.
Refer to sendmail(1M), configmail(1M) and IRIX sendmail” in the IRIX Advanced Site and Server Administration Guide.
Your mail system should be configured cooperatively with your DNS configuration. That is, whichever machine your DNS server is advertising as your Mail eXchanger (MX) host, must have its endmail.cf configured to accept mail for your network and to do the appropriate thing with it once it is received. Usually that means to forward the mail to a master mail machine on the internal network, which knows users' internal addresses, and how to deliver the mail to them.
![]() | Note: The convention is to use the domain name of your network as your electronic mail address. For example, user “harry” at company XYZ corporation, whose domain name is XYZ.com would have the electronic mail address of “harry@XYZ.com”. To reinforce the electronic mail address of your site, and to make it easy for others to reply to your users' mail, we recommend that you configure your sendmail.cf to rewrite all your addresses to conform to this convention. |
Figure 3-14 illustrates the swIPe configuration form. swIPe provides IP network address authentication, that is, it ensures that the IP packets are coming from who they say they are, protecting against IP address spoofing. IP address authentication could be used in conjunction with permission sets to guarantee that interaction is only occurring between confirmed entities. Encryption protects against unauthorized access to data. Use encryption for data that crosses over untrusted networks and that must be kept secret and be protected against alteration.
Peers are two Gauntlet firewalls configured to support authentication or encryption between them. There must be a Gauntlet host at each end of any session that is secured in this fashion. Refer to Figure 3-15 for an illustration of two Gauntlet hosts acting as peers in a network path that passes through the Internet.
You can use the reports and logfiles form (Figure 3-16) to configure some basic reporting mechanisms on the Gauntlet firewall.
The system automatically generates reports, and you can specify yourself (and other users in a comma-separated list) to receive these reports by e-mail.
You may also specify which reports you want to receive (daily, weekly, or both), how often you want the report software to run and how long you want system log files to be saved. Save the files for at least seven days if you want to receive full weekly reports.
You should assign either yourself or another trusted user as the system Postmaster (to receive any generic mail addressed to “Postmaster” at the Gauntlet host).
An example of log file entries generated by the Gauntlet firewall is shown in Example 3-2 (lines have been shortened for readability). If you do not want certain types of entries to be recorded in the log file, you can specify them using egrep syntax in the field provided on this form (see egrep(1)). For example, enter “localhost” in the egrep field to keep lines which include the string “localhost” from appearing in the log file output. Be careful not to specify filters which are too broad and that prevent you from seeing warnings and notices you want to see.
Aug 10 02:00:08 6F:rfwall syslogd: restart Aug 10 06:56:22 5D:rfwall netacl[1355]: permit host=boston.esd.sgi.com... Aug 10 06:56:22 5D:rfwall tn-gw[1355]: permit host=boston.esd.sgi.com/... Aug 10 06:56:32 5D:rfwall tn-gw[1355]: permit host=boston.esd.sgi.com/... Aug 10 06:56:32 5D:rfwall tn-gw[1355]: connected host=boston.esd.sgi.c... Aug 10 06:56:32 5D:rfwall netacl[1356]: permit host=localhost/127.0.0.... Aug 10 10:45:41 5D:rfwall authsrv[1893]: BADAUTH smith (tn-gw midas.wp... Aug 10 10:45:45 5D:rfwall authsrv[1893]: BADAUTH exit (tn-gw midas.wpd... <etc> |
Refer to Chapter 4 for command-line and file information on reports.
The authorizing users form (Figure 3-17) allows you to specify which users can access services from an untrusted network if they successfully authenticate themselves. Several different authentication mechanisms are supported.
Adding a user with the Add Users form (Figure 3-18) means that the user can use all of the enabled services. The group field lets you associate groups of users.
![]() | Note: Adding users and groups here does not create IRIX accounts or groups for the users—just proxy server authorization. |
Figure 3-19 illustrates user authentication on the Gauntlet host.
You have several choices in setting a user's authentication protocol:
password—Plain text passwords. This is not recommended for use under any circumstances for accessing a network from over an untrusted network. Plain text passwords are included as an option principally for sites that wish to do chargeback accounting or individual accounting of firewall use.
skey—S/Key software system that uses a challenge-response model to implement authentication. S/Key is a freely available software authentication system from Bellcore. It is included “as is” with the Gauntlet firewall—-the IRIX executable users need to generate responses is /usr/bin/key. If you want to use S/Key on other systems as well as IRIX, you can download source code from the site listed in “Additional Resources”. Refer to Example 3-3 for an example of an S/Key authentication session.
MDauth—another authentication system, but less widely known and available than S/Key. MDauth is also a software-based system that uses challenge response. It is based on MD5 checksums. MDauth is included “as is” with the Gauntlet firewall. Especially in heterogeneous environments, it may be preferable to use S/Key to MDauth. The IRIX executable users need to generate responses is
/usr/etc/softmd5.
When editing a user record, if the Password: field is not empty, the new value will be used to reset the user's existing password entry for whatever authentication protocol he or she uses. If you make an error when editing a user record, simply select the Reset button, which aborts any changes that were made.
Example 3-3 shows an S/Key authentication session from the point of view of a user on a remote client. Note that this assumes the administrator of the system has already added the user in the authentication database as an S/Key user with a password known to the user, and that the user has access to the /usr/bin/key program on the client.
% telnet fwall Trying 192.111.28.11... Connected to fwall.esd.sgi.com. Escape character is '^]'. Username: jones Skey Challenge: s/key 662 rf20257: |
At this point, the user must run the key program on the client to generate a response to the server challenge:
% key 662 rf20257
Enter secret password: fxdkiux
CHAR BAN SHOT HOP SALT HURT
|
The user then enters the response back at the server prompt:
Skey Challenge: s/key 662 rf20257: CHAR BAN SHOT HOP SALT HURT Login Accepted tn-gw-> |
![]() | Caution: The user client should be secure. Note that S/Key does echo the password to the screen so the user should be sure that no one sees the password. |
After a certain number of authentication sessions, a new password must be set for S/Key. The remaining number of authentication sessions for the current password is the first string in the S/Key server challenge (662 in the example).