Developing an Access Rules Plan
Novell Cool Solutions: Feature
By Scott Jones
Digg This -
Posted: 25 Jan 2002
Versions: BorderManager 3.5, 3.6
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 BorderManager server, usually between your company's intranet and the Internet.
There are many things to consider when developing an Access Rules plan for your company, and any time you spend during the planning stages will pay off big time during the implementation and beyond.
You need to understand when to use Packet Filters, and when to use Access Rules. You need to know how to enable Access Rules, and decide which security postures make sense for you. You need to define a workable list of functional roles that will service your organization for a long time. And you need to decide when you will require user authentication.
Here are some guidelines and tips that you may find useful as you develop your plan.
- Packet Filters vs.Access Rules
- Enabling Access Rules
- Security Posture
- Functional Roles
- Example: Basic Access Rule List
- More Info
|Packet Filters||Access Rules|
|Work at the network transport layers||Work at the application layer|
|Only packet headers are inspected, not the payload**||Client and server dialogue encapsulated in TCP/IP**|
|Executed by extensions of the IP stack (IPFLT31.NLM)||Executed by BMEE applications (proxy, gateways, VPN)|
|Based on open standards (same as Cisco, Checkpoint, Linux, etc.)||Based on proprietary code (industry security principles/Novell mechanism)|
|May be defined by...
- source/destination port
|May be defined by...
- BorderManager service
|Configured at server console using FILTCFG.NLM||Configured in NetWare Administrator|
|Supports logging (mainly for diagnostic use)||Supports logging|
|Relatively low CPU overhead||Slightly more CPU overhead|
|A component of NIAS (included in NetWare)||A component of BorderManager|
** As a result, packet filters take precedence over access rules.
To enable access rules, check the "Enforce Access Rules" box on the BorderManager Setup page on the server object.
Access rules apply to all transactions attempted through the BMEE server. A default rule of Deny All is placed on the server object, and gets pushed down (stays at the end of the list) as new rules are created.
Unlike ZENworks policies, BorderManager rules are not user- or container-centric, they are server-centric. Each time a BMEE server comes online, the server searches the tree for rules from the server object up to the root. It will only search upward, not across Os or OUs. Each rule found is placed in the ACL of the server. They are ordered as follows:
- Rules created at the Server object
- Rules created at the parent container of the Server object
- Rules created at other up-line containers
- Rules created at the O container
Each user request is checked against the ACL to determine if a rule exists that applies to that request. If an applicable rule is found, the search stops. Therefore, server-based rules take precedence.
An example will help illustrate how this works:
O=EMEA (rule=DENY ALL)
|______OU=Corp (rule=DENY ALL)
|______OU=Legal (rule=ALLOW ALL)
If users exist in all three containers, you might think that only users in the Legal container would have access through BMEE_Server. But since the server looks at rules from the Server object up, it would find an applicable rule for all requests at OU=Legal (rule=Allow All). So, users in all three containers have full access.
The needs of each network drive rule placement decisions. In small environments, putting all rules on the Server objects can help keep things simple. However, rules implemented at a container can eliminate duplication because they can apply to multiple subordinate servers. They can also facilitate administrative roles, but be mindful of replica placement. Follow the standard NDS design principles by avoiding excess tree walking, too many replicas, and replication across WAN links. Note that CyberPatrol rules can only be set on Server objects. This is by design, to ensure license compliance.
Deny All and Allow by Exception
- Recommended for packet filtering.
- Blocks all activity unless expressly allowed by company policy.
- No IP packet type should be allowed in or out through a firewall unless its security risk has been evaluated and weighed against business requirements.
Allow All and Deny by Exception
- Recommended for web proxy access rules.
- Allows all activity unless expressly denied by company policy.
- Practice shows that less administrative time is required to block undesirable web sites than to grant access to sites needed for business reasons.
As with ZENworks, a "functional role" is a group of users with the same functional requirements from a network application or service. Some users, for example, may only require access to a limited number of web sites for the purpose of ordering parts and materials. Their functional role might be met by access rules that allow them to suppliers' sites and nowhere else. IS personnel, on the other hand, typically require access to a wide variety of hardware and software company sites for research and support. Their functional role might be met by access rules that block adult, sports, and entertainment sites, but allow access to most other sites.
To simplify access rule entry and administraion, identify the fewest number of functional roles for your organization that will meet business requirements. The needs of most organizations, even very large ones, can be met with a handful of Access Levels that can be defined in a corporate policy document. For example:
|Level 1||Unrestricted access||Executives and IS staff|
|Level 2||Adult, gambling, and potentially illegal sites are blocked, but all else is allowed||Managers and other professional staff members|
|Level 3||All recreational catagories blocked, including B2C eCommerce sites and general interest news, access allowed only to a specified list of business partner sites||Clerical staff, clerks, etc.|
|Level 4||No access||All others|
BorderManager proxies support user authentication for two reasons:
- To allow the logging of activity by NDS user name
- To allow for Identity-Based Access Rules
A "transaction" is the combination of a user request and the response from the target server. (AKA query and response.)
As discussed earlier, on proxy startup ACLCHECK.NLM walks the tree from the server object to the root looking for access rules that apply to the server and compiles an ACL (Access Control List).
When access rules are enabled, the proxy service measures every transaction against the ACL to determine if a rule exists that applies to that transaction.
Access rules can be defined by specifying an NDS user, group, or container object as the source of a transaction. These are Identity-Based Access Rules.
While checking the ACL, to determine whether or not an identity-based access rule applies to a given transaction, the proxy must know who the user is and authentication is required.
By default (and most commonly), the proxy is configured to always authenticate, but it may be configured to authenticate only when necessary to execute the ACL.
|Allow||All||cn=NetAdmin.ATL.Novell||All (allows the NetAdmin group unrestricted access)|
|Allow||URL||All||Specified URL list (to allow needed sites that are in the CyberNOT lists)|
|Deny||URL||All||Specified URL list (to block unwanted sites that are not in the CyberNOT lists)|
|Deny||URL||All||Specified CyberNOT categories|
|Allow||All||All||All (default posture - allow all and deny by exception)|
|Deny||All||All||All (with Rule Hit Logging enabled)|
- For more information about Access Rules, see this section of the documentation:
- How to Use Wildcards in Access Rules
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com