This chapter tells you how to create new policies, add or deny proxy services, deny services by network or host, and control services by user, group, or time. The chapter has the following sections:
You can create additional policies to fit your security requirements for different groups of inside hosts and networks. Remember that all policies are based on the source address of the request. Creating a new policy involves modifying the netperm table.
To create a new policy:
Add a line indicating:
Source networks that use the policy
Name of the policy
Add rules indicating which proxies this policy allows.
Add rules indicating permitted destinations, authentication, and logging.
Place the policy lines above or below the section generated by the Gauntlet Firewall Manager, as appropriate (see “Precedence in Netperm Tables”).
Suppose, for example, that the generic policy for Yoyodyne uses the default Gauntlet trusted policy. The security policy for Yoyodyne calls for restricting a particular group of systems (and set of addresses) to TELNET and rlogin to a particular set of outside networks.
To implement this policy, you can create a more restrictive policy:
1 #define inside hosts who will use the policy 2 *: permit-hosts 204.255.154.0:255.255.255.128 -policy restrictive 3 #define the policy 4 policy-restrictive: permit-proxy netacl-telnetd tn-gw 5 policy-restrictive: permit-proxy netacl-rlogind rlogin-gw 6 policy-restrictive: permit-destination 192.33.112.* 7 policy-restrictive: authenticate * 8 policy-restrictive: authserver 127.0.0.1 |
Line 2 indicates that all proxies and applications (*) should use the restrictive policy for requests from the designated subnet. If you specify the policy for only the TELNET (tn-gw) and rlogin (rlogin-gw) proxies instead of for all (*), all other proxies (such as the HTTP and FTP proxies) skip this policy and use another policy.
Lines 4 and 5 indicate that this policy permits the TELNET and rlogin proxies. All other proxies with requests from hosts within 204.255.154.0:255.255.255.128 deny the request after parsing these lines.
Line 6 indicates that these proxies can send requests to the set of destinations: 192.33.112.*. The TELNET and rlogin proxies deny requests to any other destinations after parsing this line.
Lines 7 and 8 indicate that users on these networks must authenticate with the authentication server on the firewall.
You must put this policy above the trusted policy so the proxies will use these rules rather than the more permissive trusted policy. You may also want to create a matching restrictive untrusted policy to restrict access from outside networks to this internal subnet.
Note that this type of policy may not prevent users on this inside network from reading news and sending e-mail. The recommended setup for the Gauntlet firewall calls for central mail and news servers on the inside networks. The news readers and mail agents on the restricted subnet communicate directly with the news and mail servers. These servers, which are not on the restricted subnet, communicate directly with the firewall.
If, however, you are running mail and news servers on the firewall, this more restrictive policy does deny e-mail and news activities from the restricted subnet.
You can add proxy services at any point as your security policies change. This section addresses the changes you must make to the netperm table to use the proxy. See the Gauntlet for IRIX Administrator's Guide for information on other configuration requirements for the various proxies.
To add a proxy service:
Add the name of the proxy to the permit-proxy line of the appropriate policy.
Add a section for proxy-specific rules above the policy sections. These rules can include items such as userid, groupid, time-out, and denial messages. Consult the reference information for the proxy for information on proxy options.
For example, suppose that Yoyodyne wants to add support for Quote of the Day (qotd) service for users on its inside networks. This involves using the proxy. First, add a line to the trusted policy:
99 policy-trusted: permit-proxy qotd-gw |
Next, create a section above the policies in which you define the communications rules for the Quote of the Day connection:
95 # QotD (through plug proxy) rules 96 # ----------------------------------------- 97 qotd-gw: port qotd * -plug-to qotd.bigu.edu -port qotd |
You can remove proxy services as your security policies change. You can use the Proxy Configuration options in the Gauntlet Manager graphical user interface, or you can modify the netperm table.
To remove a proxy service, remove or comment out the permit-proxy line in the appropriate policy.
For example, assume Yoyodyne no longer wishes to allow users to rlogin from outside networks. The administrator modifies the untrusted policy:
44 #policy-untrusted: permit-proxy rlogin-gw |
You can deny services to and from specific networks and hosts. You can do this for all the proxies through a policy, or for individual proxies.
When you deny service, you can specify by IP address or by host. If you specify by IP address, proxies deny access based on that IP address. Be sure that you explicitly deny all IP addresses a system or site may have.
Because, in most cases, a proxy sees an IP address for only a given connection request, there are additional considerations when specifying hostnames in permit or deny rules. The firewall must perform additional processing steps to convert the address that is in the packet and the hostname that is in the configuration rule to the same format so that it can compare the values.
If you deny by hostname, the proxy must use DNS to map the source or destination address (in the packet) into a hostname. If the proxy cannot perform this mapping, it considers the address to be unknown.
You can deny access from a particular host or network on a per-proxy basis or on a general basis.
To deny access by proxy, add a deny-hosts line to the specific proxy.
For example, Yoyodyne does not want anyone on any system at Big University to have TELNET access to Yoyodyne:
50 tn-gw: deny-hosts *.bigu.edu |
Later, Yoyodyne determines they need to deny access only from the dial-in systems at Big University:
50 tn-gw: deny-hosts dial*.bigu.edu |
You can also deny access from a particular host or network for all proxies and applications.
To deny access for all applications, add a deny-hosts line above the untrusted policies. Use a wildcard as the keyword to indicate that the rule applies to all policies.
You must include this rule above the policy rules. The policies are based on permitted hosts. Including the deny-hosts rule in a policy has no effect because the application is using the permit-hosts rule that defines the policy.
Note that the SMAP proxies do not use the policy rules, so you still receive mail from the denied host or network.
For example, Yoyodyne does not want anyone or any service at Big University to communicate with Yoyodyne:
103 *: deny-hosts *.bigu.edu ... 140 *: permit-hosts * -policy outside |
You can deny access to a particular host or network on a proxy or general basis.
To deny access by proxy, add a deny-destination line to the specific proxy.
For example, Yoyodyne does not want anyone on the inside networks to transfer files using FTP from any hosts at Big University:
55 ftp-gw: deny-destination *.bigu.edu |
You can also deny access to a particular host or network for all proxies and applications.
To deny access for all applications, add a deny-destination line to the appropriate policy.
For example, Yoyodyne does not want anyone on the inside network to communicate with Big University:
108 policy-trusted: deny-destination *.bigu.edu |
Note that the SMAP proxies do not use the policy rules, so you can still send mail to the denied host or network.
You can control access to the following proxies on a per user, per group, or time of day basis:
| ck-gw | Circuit proxy | |
| ftp-gw | FTP proxy | |
| rlogin-gw | Rlogin proxy | |
| rsh-gw | Rsh proxy | |
| tn-gw | TELNET proxy |
You can permit or deny access to certain proxies by user or group as follows:
Add the operations attribute to your authsrv configuration to specify who can perform the operation and what services they can access.
Add the authenticate attribute to the appropriate policy or proxy to require users to authenticate before using the service.
Add the extended-permissions attribute to the appropriate policy or proxy to indicate that the authentication server should check information specified by the operations keyword.
For example, Yoyodyne wants to permit only members of the group Developer to use the rlogin proxy when accessing outside hosts:
55 authsrv: permit-operation group Developer rlogin-gw * .... 100 rlogin-gw: authenticate * 101 rlogin-gw: extended-permissions * |
These commands prevent any other users who are not members of group Developer (in the Gauntlet authentication database) from using the rlogin proxy.
You can permit or deny access to certain proxies by time of day.
To control access by time of day:
Add the operations attribute to your authsrv configuration to specify who can perform what operations, and what services they can access, and when.
Add the authenticate attribute to the appropriate policy or proxy to require users to authenticate before using the service.
Add the extended-permissions attribute to the appropriate policy or proxy to indicate that the authentication server should check information specified by the operations keyword.
Suppose, for example, that Yoyodyne wants to deny TELNET between 5:00 p.m. and 11:00 p.m.:
55 authsrv: deny-operation user * tn-gw * * time 17:00 23:00 56 authsrv: permit-operation user * tn-gw * * ... 100 tn-gw: authenticate * 101 tn-gw: extended-permissions * |
Line 55 denies TELNET access between 5:00 p.m. and 11:00 p.m.
Line 56 permits TELNET access. You must include this rule because you must explicitly permit operations when you specify extended permissions.
The deny rule must appear before the permit rule because the proxies use the first matching rule. If you specify the permit rule before the deny rule, the authentication server would never read the deny rule, because the permit rule matches all TELNET operations.