The netperm table (/usr/local/etc/netperm-table) contains configuration information for the Gauntlet Firewall. The kernel, proxies, and other applications read configuration information from this table.
The recommended method of configuring the Gauntlet Firewall is through the Gauntlet Firewall Manager graphical user interface. Edit the netperm table only if you:
Have an unusual configuration, such as four network interface cards
Need to configure an option that you cannot set through the Gauntlet Firewall Manager
Changes you make to the netperm table may conflict with the settings generated by the Gauntlet Firewall Manager.
This chapter describes the Gauntlet Firewall's network permissions (netperm) table by discussing the different types of rules:
Policies are collections of general configuration information. Policies allow you to closely map your security requirements to the configuration of your Gauntlet firewall. Gauntlet configuration policies often include information such as:
Types of proxies that the firewall can start
Permitted (or denied) destinations for requests
Authentication requirements
The source address of the request is the basis for a policy. You define policies for a set of hosts. You can easily use the same set of rules for a group of hosts by creating a generic policy describing what these hosts can and cannot do.
In addition to policy rules, the netperm table includes configuration information for proxies and other firewall applications, such as:
Userid and groupid under which a proxy should run
Directories that the proxies should use as their root directories
Messages that proxies should display when denying or accepting requests
Length of idle time before the proxies should terminate the connection
More specific lists of permitted and denied destination networks for a particular proxy
Suppose, for example, that the SMAP proxy reads the netperm table and determines the userid under which it should run and the directory into which it should place mail. The TELNET proxy reads the netperm table to determine how long a session must be idle before it disconnects the session. The specific configuration options for each proxy are described in Chapter 4, “Attribute Reference.”
You can also include rules to permit or deny a particular service for requests to specific addresses or networks. For example, you can configure the HTTP proxy to deny requests to a particular host or network. All of the other proxies, such as the smapd server, continue to use the generic policy and send information to that site, while the HTTP proxy denies requests to that site.
Because the proxies and applications read the netperm table from top to bottom and stop on the first match, you must put proxy-specific rules before the generic policies. When the relevant proxy parses the configuration information, it uses the proxy specific rule rather than the more general policy rule.
For example, the FTP proxy includes a specific rule that denies requests to the destination ftp.bigu.edu. You have created a policy for untrusted hosts, near the bottom of the netperm table, which includes a rule that allows all proxies and applications to send to any destination. Because the more restrictive rule is above the generic policy in the netperm table, the FTP proxy uses the restrictive rule and denies requests to ftp.bigu.edu.
Other Gauntlet applications such as the authentication server and the IP screening utility also read configuration information from the netperm table. For example, configuration information in the netperm table tells the authentication server how many incorrect login attempts to allow before disabling an account.
As part of the startup process, a proxy or application reads the netperm table looking for applicable configuration rules. It parses the table from top to bottom, looking for rules that match its name. It also matches wildcard rules that apply to all applications. For example, the TELNET proxy (tn-gw) looks for rules that match tn-gw and *.
The proxy goes through these steps:
It uses the rules to determine if it can accept the request from the source address.
It determines whether the requested service is an explicitly permitted service.
If the request is not permitted, the proxy denies it.
If the request is permitted, the proxy uses the other rules to determine whether it has to authenticate the request, and whether it can send the request to the specified destination.
The application also finds and uses rules for itself in the netperm table.
For example, using the default untrusted policy, the TELNET proxy allows TELNET requests from any outside network to any destination. The proxy also uses the untrusted policy to determine that it has to authenticate the user and it gets information about which server it should use to authenticate the user.