Access Control List
Access control is a key part of Novell BorderManager 3.7 security. This section provides information about using access control, and describes what access rules are, what an access control list is, and how access control works on a Novell BorderManager 3.7 server. It contains the following subsections:
Access control is the process by which an administrator can regulate and monitor user access to intranet or Internet services. Access control supplies a much broader range of network security options than packet filtering alone. Like packet filtering, you can use access control to provide network-level security (Level I firewall), but you can also use it to provide circuit-level security (Level II firewall) and application-level security (Level III firewall).
In addition, you can use access control to implement an overall security policy that is customized in far more detail to meet the needs of your site. You can define access by user, user group, time of day, application, and so on.
You use access control to specify which requests made through the Novell IP Gateway, Proxy Services, and Virtual Private Networks (VPN) should be allowed and which requests should be denied. For example, you might want to control the use of a particular proxy service, or you might want to limit who can use the Novell IP Gateway to connect to the Internet and specifically when they can make the connection.
By configuring access control to use SurfControl*, you can also create access rules that use SurfControl's URL categories. This enables you to implement category-based content filtering to control user access to entire categories of URLs that might contain objectionable Web content. For more information see the SurfControl Web site at .
Novell BorderManager 3.7 access control software works by allowing or denying access requests made through the Novell IP Gateway, Proxy Services, and VPN. For information about configuring these services, refer to the Novell IP Gateway, NAT, Proxy Services, and Virtual Private Network online documentation.
Novell BorderManager 3.7 access control consists of two elements:
Access rules are the primary elements of access control. They apply to clients requesting access through the Novell IP Gateway, Proxy Services, or a VPN. Access rules control traffic through a Novell BorderManager 3.7 server, usually between your company's intranet and the Internet.
By creating Allow or Deny rules, you can control access to the following:
You can configure access rules at the following NDS® or Novell eDirectoryTM object levels:
You can apply access rules across a wide range of users and resources by specifying rules for Organizations and Organizational Units. You can also create rules that apply specifically to individual users, IP addresses, and so on.
We recommend that you configure rules affecting all eDirectory users in a container high enough in the eDirectory tree to include all Server objects representing servers running Novell BorderManager 3.7. This ensures that the same rules are applied to all eDirectory users, irrespective of which Novell BorderManager 3.7 server they use to access the Internet.
When you create an access rule, you can specify the following elements:
The Action parameter specifies how the access rule functions, as follows:
The Access Type selection is the most important control element in an access rule. You can specify one of the following:
For proxy access rules, you can specify the type of proxy, the port number, the direction of the requests (Send, Receive, or Send & Receive), and details about file types you want to restrict.
The Source parameters represent users who want to access the company's intranet or the Internet through a Novell BorderManager 3.7 server. Each transaction on a network has a source and a destination. Depending on the Access Type selection you specified previously, the access rule configuration utility allows you to configure access rules that apply to different sources, as follows:
Specific eDirectory usernames, user groups, or containers are used to match an eDirectory name to an access request. Novell BorderManager 3.7 stores the eDirectory names of users, groups, and containers as fully qualified typeless names. The access control configuration utility displays eDirectory objects for you to choose. You cannot manually type eDirectory names into access rules.
Specific hostnames are used to match the DNS name in a user's access request.
Specific e-mail usernames or e-mail domain names are used to match the user's e-mail name and domain name in an access request.
Specific IP addresses, a range of IP addresses, or IP subnet addresses are used to match the IP address of the user's browser in an access request.
The Destination parameters represent the intranet or Internet host the user wants to access through the Novell BorderManager 3.7 server. Depending on the Access Type selection you previously specified, the access rule configuration utility allows you to configure access rules that apply to different destinations, as follows:
Specific hostnames are used to match the DNS name of the Web site the user wants to access.
Specific IP addresses, a range of IP addresses, or IP subnet addresses are used to match the IP address of the Web site that the user wants to access.
Specific URLs are used to match the Web page or Web site that the user wants to access. URLs can be specified for an entire Web site or for a particular Web page.
You can specify <Any>, meaning that the rule always applies, or you can set specific hours of the day and specific days of the week during which the rule is to apply. Use the grid displayed to specify times and days that are appropriate for your network and your users.
If you place a check in the Enable Rule Hit Logging check box, then all attempts to connect to destinations and services listed in the access rules are recorded in a log file.
Novell BorderManager 3.7 allows you to enter wildcards (*) in the following source and destination information:
A wildcard is used to skip one or more characters when matching two character strings. For example, the string *.xyz.com matches both www1.xyz.com and www2.xyz.com. Another example, the string *xyz* matches any character string that contains the letters xyz, such as abcxyzsd or ?xyz/.
NOTE: There is no wildcard match for eDirectory users, groups, and containers because you cannot manually type eDirectory user, group, or container names into an access rule.
When you use wildcards to match URLs, note that you will obtain a more specific match if you use // or / to anchor your wildcard name more specifically. For example, to match all URLs that have the letters cgi as part of the path, the best wildcard entry would be */cgi/*. This entry would match all the appropriate URLs, such as http://www.x.com/cgi/xyz. With a less specific use of wildcarding, such as *cgi*, your entry would match http://www.x.com/cgi/xyz, but it would also match http://www.cgi.com/xyz, a URL you did not intend to match.
As stated previously, you can configure access rules in NDS or eDirectory Country (C), Organization (O), Organizational Unit (OU), and Server objects. When Novell BorderManager 3.7 is loaded on a server, it collects the sets of access rules created at each of these eDirectory objects. It first collects rules from its own Server object, then from the Organizational Unit (OU) object above the Server object, the Organization (O) object above the OU object, and finally the Country (C) object above the O object. A Novell BorderManager 3.7 server's access control list is simply the collection of all these different sets of access rules in the order given. This consolidated list of rules controls the destinations or services that objects can and cannot access through the Novell BorderManager 3.7 server and also controls when the objects can access them.
The fact that Novell BorderManager 3.7 allows you to configure and store access rules in different eDirectory objects establishes a hierarchical relationship of access control rules. The location of a given set of access rules in an eDirectory tree defines which servers have those rules built into their access control lists, and in what order.
NOTE: The location of an access rule in an eDirectory tree determines which Novell BorderManager 3.7 servers read the rule and where the rule is placed in a server's effective rules list. No relationship exists between the context in which a rule exists and the context in which a user exists. A rule defined anywhere in the tree can affect a user defined anywhere else in the tree.
The sequence of each rule list that you create is maintained within the Novell BorderManager 3.7 server's access control list. When multiple rule lists are consolidated, rules defined at the server level are placed at the beginning of the access control list; rules defined closer to the root of the eDirectory tree are placed at the end. The sequence of rules in the access control list is important because when an access request is made, Novell BorderManager 3.7 reads the server's access control list from the beginning (the server's rule list) and acts on the first rule that applies to the request.
In this example, Acme Company has the following NDS or eDirectory tree, with different sets of access rules defined in five different places.
Figure 6
Access Control List
When border_server_1 builds its access control list, it first reads its own access rules, then the access rules in ou=mktg, then the access rules in o=acme. The access rules from the border_server_1 object will be first on the list. The access rules from the o=acme object will be last. The access rules are read from the cn= level up to the top level in sequence. In this example, border_server_1 will never read the access rules in either ou=sales or border_server_2.
However, when border_server_2 builds its access control list, it first reads its own access rules, then the access rules in ou=sales, then the access rules in ou=mktg, then the access rules in o=acme. Note that the rules in ou=sales are used only by border_server_2, because it resides under the ou=sales context.
If a user is granted access to both servers, and tries to access the Internet, the access control lists for the two servers would read as shown in the following table.
border_server_1 |
border_server_2 |
Rule 1 |
Rule 10 |
Rule 2 |
Rule 11 |
Rule 3 |
Rule 12 |
Rule 4 |
Rule 13 |
Rule 5 |
Rule 14 |
Rule 6 |
Rule 15 |
Rule 7 |
Rule 4 |
Rule 8 |
Rule 5 |
Rule 9 |
Rule 6 |
|
Rule 7 |
|
Rule 8 |
|
Rule 9 |
Again, no relationship exists between the location of a rule and the users or groups that are affected by the rule. The location of an access rule in the eDirectory tree affects only the order in which the access control list is read, and which rules exist in which server's access control list. Although access rules exist in one context, this does not mean that the rules are effective only for users under that context. Any access rule in the access control list of a Novell BorderManager 3.7 server controls access for all users who request access through that server.
For example, if the first access rule in the border_server_1 access control list is Allow Any, then anybody using that server will be able to access any Web site. If a user under ou=sales uses border_server_1 as the proxy server, that user will be allowed to access any Web site.
Novell BorderManager 3.7 processes access rules in the access control list sequentially to match an access request. When the access request matches an access rule, the action specified in the rule (allow or deny) is immediately applied to the access request and no further processing occurs. If there is no match between the access request and the entire set of access rules (the access control list), the default action (Deny Any) is applied to the access request.