3.1 Overview of Access Control

Access control is a key part of Novell BorderManager 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 server. It contains the following subsections:

3.1.1 Using Access Control with BorderManager

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 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 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 (www.surfcontrol.com).

Novell BorderManager access control software works by allowing or denying access requests made through the Proxy Services, and VPN. For information about configuring these services, see Novell BorderManager 3.9 Administration Guide .

3.1.2 Implementing Access Control

Novell BorderManager access control consists of two elements:

  • Access rule: Specific rules that define which sources can access which destinations at what times.

  • Access control lists: Ordered sets of access rules that control intranet and Internet access through a Novell BorderManager server.

3.1.3 Access Rules

Access rules are the primary elements of access control. They apply to clients requesting access through the Proxy Services, or a VPN. Access rules control traffic through a Novell BorderManager server, usually between your company’s intranet and the Internet.

By creating Allow or Deny rules, you can control access to the following:

  • Many network and Web services

  • Novell BorderManager Proxy Services

  • VPNs

  • URLs

You can configure access rules at the following NDS® or Novell eDirectory™ object levels:

  • Country (C)

  • Organization (O)

  • Organizational Unit (OU)

  • Server

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. This ensures that the same rules are applied to all eDirectory users, irrespective of which Novell BorderManager server they use to access the Internet.

Access Rule Structure

When you create an access rule, you can specify the following elements:

Action

The Action parameter specifies how the access rule functions, as follows:

  • Allow—An Allow rule specifies that particular access requests are to be allowed based on the source, access type, destination, or time restrictions specified.

  • Deny—A Deny rule specifies that particular access requests are to be denied based on the source, access type, destination, or time restrictions specified.

Access Type

The Access Type selection is the most important control element in an access rule. You can specify one of the following:

  • Port: An access request made to a specific port based on well-known TCP/IP port numbers. For port access requests, you can specify the type of port, the port numbers, and the transport protocol (TCP, UDP, or TCP & UDP).

  • URL: An access request made to a specific URL based on a Web site or Web page.

  • Application Proxy: An access request made to a proxy server based on the proxies implemented in Novell BorderManager (HTTP, FTP, SMTP, NNTP, and Generic TCP/UDP). The control of application proxies is based on well-known TCP/IP port numbers, but it is more specific to the protocol used by the Novell BorderManager Proxy Services component.

    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.

  • VPN Client: A request made for access to a VPN server.

Source

The Source parameters represent users who want to access the company’s intranet or the Internet through a Novell BorderManager 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:

  • <Any> All users

  • One or more eDirectory users

  • One or more eDirectory user groups

    Specific eDirectory usernames, user groups, or containers are used to match an eDirectory name to an access request. Novell BorderManager 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.

  • One or more DNS hostnames

    Specific hostnames are used to match the DNS name in a user’s access request.

  • One or more e-mail usernames or e-mail domain names

    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.

  • An IP address or a range of IP addresses

  • One or more IP subnet addresses, including each subnet address’s subnet mask (255.255.252.0, for example)

    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.

Destination

The Destination parameters represent the intranet or Internet host the user wants to access through the Novell BorderManager 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:

  • <Any> All users

  • One or more DNS hostnames

    Specific hostnames are used to match the DNS name of the Web site the user wants to access.

  • An IP address or a range of IP addresses

  • One or more IP subnet addresses, including each subnet address’s subnet mask (255.255.252.0, for example)

    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.

  • One or more newsgroup names

  • One or more e-mail user names or e-mail domain names

  • Uniform Resource Locator (URL)

    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.

Time Restriction

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.

Rule Hit Logging

If you select Enable Rule Hit Logging, all attempts to connect to destinations and services listed in the access rules are recorded in a log file.

3.1.4 Using Wildcards in Access Rules

Novell BorderManager allows you to enter wildcards (*) in the following source and destination information:

  • Hostname

  • URL

  • E-mail name

  • E-mail domain

  • News Group

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. Or, 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, 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.

3.1.5 Access Control Lists

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 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 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 server and also controls when the objects can access them.

Hierarchical Relationship

The fact that Novell BorderManager 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 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 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 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.

Example of the Hierarchical Relationship

In this example, CompanyA has the following NDS or eDirectory tree, with different sets of access rules defined in five different places.

Figure 3-1 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=companya. The access rules from the border_server_1 object will be first on the list. The access rules from the o=companya 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=companya. 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:

Table 3-1 Access Control Lists for two servers

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

Rule Processing

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 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 can access any Web site. If a user under ou=sales uses border_server_1 as the proxy server, that user is allowed to access any Web site.

Novell BorderManager 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.