AppNote: NBM 3.8 Access Rules: Some Do's and Don'ts
Novell Cool Solutions: AppNote
By Bhavani S T, N Subramanian
Digg This -
Posted: 15 Jan 2004
|Bhavani S T||N Subramanian|
|Software Consultant||Senior Software Engineer|
Thanks to Subbaraju Uppalapati and Jerry Brower from Novell, and Marcus Williamson from Connectotel for their help with this AppNote.
Abstract: This AppNote discusses the recommended ways to configure access rules in Novell BorderManager 3.8 (NBM3.8) and provides details of tested and scalable limits of Access Rules at different eDirectory container levels. This document explains the global and specific rules that can be set on the server, and the criterion for choosing the duration to enable/disable ACLCHECK. This document also provides the information regarding the impact on performance across access rules at different eDirectory container levels.
Table of Contents:
- Access rules and Access control list
- BorderManager components used in Access Rules
- Access Rule Methods
- Lab Testing
- Runtime Switches for ACLCHECK.NLM
- Useful Links
|Products||Novell BorderManager 3.8|
|Audience||network administrators, technical support personnel|
|Prerequisite Skills||Familiarity with basic BorderManager operation, concepts of eDirectory and the tree structure.|
A Novell BorderManager 3.8 (NBM3.8) server secures your network, allowing you to implement your business security policy by configuring a broad set of rules that specify which sites, protocols and content can be accessed by internal resources. The server also monitors requests and responses between the Internet and internal Client computers, controlling who can access which computers on the corporate network. It allows configuration based on URL, content filtering rules and protocol rules that control the internal clients that access the Internet. Site and content rules specify which sites and contents can be accessed. Protocol rules specify whether a particular protocol is available for communication in an inbound or an outbound or in both directions.
NBM3.8 firewall prevents unwanted and unauthorized communications into or out of the protected networks. It operates at the application layer of the 7 layer OSI model.
A firewall is a network component that controls the traffic flowing between internal (private) networks and external (public) networks, such as the Internet. Firewalls can also be used to separate your internal data networks (intranets) to protect valuable company data such as research and development, corporate financial data, personnel files, and other sensitive information.
Novell BorderManager 3.8, with its advanced security services, protects your confidential information from internal and external intruders. Novell BorderManager 3.8 packet filtering provides basic network security by controlling both Internet and intranet access at the network level.
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. Just 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).
Access rules are the primary elements of Access Controls. Access rules enable you to create rules that restrict or permit the source type access. It also determines which users should get access, and what type of access should be provided on a portion of data. By creating Allow or Deny rules, one can control access to many networks and web services, Novell IP Gateways, Proxy Services and URL's. One can configure access rules in eDirectory at the Country (C), Organization (O), Organizational Unit (OU), and Server objects.
"Access Control List" (ACL) is the collection of these different sets of access rules in a given order. This consolidated list of rules controls the destinations or services of objects that can or cannot access data through the NBM3.8 server. It also controls when the objects can access the data. ACL data structure is a stand-alone module that provides a list of access rules.
By loading this NLM the enabled proxy services will start working in the respective ports for which they are configured. This also enables the user to monitor the statistics for the proxy services.
The aclcheck.nlm is an interface between eDirectory and proxy.nlm.
This is a plug-in to the NWAdmn utility which provides the interface to add the configuration of the proxy services.
The following explains how access rules works on a NBM 3.8 server and how to configure these access rules. The access rules are stored in the eDirectory and they can be configured through the NWAdmn utility. NBM3.8 server supports both eDirectory login and NDS login method of NMAS authentication.
When NBM3.8 is loaded on a server, it collects the sets of access rules configured at each of these eDirectory objects. It first collects rules from its own Server object, then from its immediate parent container until it has collected rules till the top of the eDirectory structure. The effective rules of the server will be the sum on the server and the container rules above it. This effective list of rules controls the destination or services that objects can and cannot access through NBM3.8 server and it also controls when the objects can access them.
Note: The security policy feature of Virtual Private Network (VPN) is entirely moved to eDirectory and the option exists in the Access rules configuration of the NWAdmn utility
NBM3.8 access rules are basically a set of allowed or denied rules for the access type of the following:
- Application Proxy
The services which can be configured for the access type "Port" are HTTP, Daytime, DNS, Echo, Exec, Finger, FTP, FTP Data, Gopher, Hostname, Login, Name, Net News, Netstat, NNTP, POP2, POP3, Printer, Real Audio, RTSP, Shell, SMTP, SNMP, SNMP Trap, Sunrpc, Systat, Telnet, TFTP, Time, UUCP, and Whois. It is not advisable to configure allow/deny access rules apart from the above mentioned services. For access type "any", the port configuration indicates any of the above mentioned services. For example, if we configure deny for "Any" access type and if we are invoking Rconj and logging into machine which is the other side of a proxy, access rules will not deny this service because this service is not present in the currently available access type.
For the "URL", access type we can specify any specific HTTP URL with or without metacharacters in the URL line.
For the "Application proxy" access type, the available services are HTTP, FTP, SMTP Mail, News, Real Audio and RTSP, Generic TCP, Generic UDP and Telnet.
The access type can be configured for a specific eDirectory object, DNS hostname, Hostname IP Address, Subnet Address or any of the source type. We can specify the range of IP address (starting and ending) for source type hostname IP Address and we can specify a single IP address also. For subnet address, one can specify the subnet address and its mask for the configuration.
The way the rules are gathered and accessed by NBM3.8 server is:
- The Proxy service is started on the NBM server by loading the brdsrv.nlm.
- While proxy loads, aclcheck.nlm is loaded and it reads the access rules by querying the eDirectory. It collects all the rules from the server level and builds the access control list in runtime memory structures.
- The rules in the container levels above the server object are read and are appended to the server level rules in the runtime memory structures.
- This building of access control lists is a one time activity and further requests will be processed against this access control list.
- An implicit 'deny any to any' will be available at the end of effective rules. So when the request doesn't match any of the configured access rules, the request will be implicitly denied.
- All the configured effective rules will be stored in the memory of the BorderManager Server after aclcheck.nlm completes its reading from eDirectory.
The URL rules which are built using metacharacters such as "*" (for example http://www.novell.com/*) are not hashed and are stored in memory separately apart from the normal rules. Other rules are hashed and are stored separately in memory.
A rule on the top of the list always takes precedence over any rule that follows in the list. If a request matches the rule which is top in the list then that rule will be applicable. It has been observed that the number of rules at the server level really doesn't matter when it comes to providing a response for a request. If a rule is at the server level, the access rules access is faster. If you mix conflicting Allow and Deny rules in an access control list, you must ensure that the sequence of rules in the list produces the desired effect. It searches the list until it finds the first access rule that applies to the requesting object, and then it acts immediately on the rule to allow or deny the request.
The following observations are based on the simulated lab setup:
The server(s) configurations are as follows:
For S1 and S2 the system configuration was Compaq Proliant ML350, Pentium® III 733 MHz, 1GB RAM Dual processor
For S3 and S4 server the system configuration was Embedded AIC - 7899, A: 00 Maxtor ATLA 3104k-73, 1800MHz, 2GB RAM 4 processor
NetWare 6 SP3
- The number of access rules created and tested at the server level (first level in the tree) was 5000 rules. These rules include port, URL and application proxy access type. Rules are created for specified users and groups (which consists of set of users). URL rules were created using metacharacters ("*"). The processing of ACLCHECK when a request comes from the client is same for all the rules irrespective of its position in Access Control List.
- If numbers of access rules at the server level exceed more than 1000 rules then the time taken for ACLCHECK to read the rules from eDirectory and build the access control list will be around 4 to 6 minutes. During this time the server blocks all the requests since ACLCHECK will yield the server processes and memory.
- If the configured access rules are incorrect (for example, not able to resolve the DNS name and if wrong URL was provided) then time taken for ACLCHECK to load on the server will be around 10-15 minutes. 500 wrong rules are configured on the server level and it took around 15-20 minutes for ACLCHECK to perform. The more wrong URL's configured, the longer ACLCHECK will take to load since it tries to resolve DNS entries which in turn return wrong entries which are displayed at the server console.
- The number of access rules created and tested at the Organization (O) level was around 400 rules and these rules includes the port and URL access type. These rules are also created for specified users and groups (which includes for the users and groups under Organization (O) and Organizational Unit (OU)). URL rules were created using metacharacters ("*").The processing of ACLCHECK when a request comes from the client for the users under organizational (O) is same for all the rules irrespective of its position in Access Control List.
- The number of access rules created and tested at organizational unit (OU) level is around 150 rules and these rules include the URL rules only. The URL rules are created using the specified users and groups under the organizational unit and using metacharacters. For groups under Organizational Unit (OU), processing of the page will slow down and the rendering of the page will be comparatively slower (The page having more links, gif's and images).
- The number of access rules created and tested for the server under Organizational Unit is around 1000 rules and these rules are only URL rules. As explained above while processing ACLCHECK for groups (which consist of users under organizational and organizational unit) the rendering of page will slow down (The page having more links, gif's and images).
- Loading ACLCHECK for a server which is beneath a sub-container of an Organization (O) takes more time than a server which is directly under an Organization (O) itself.
- Using ACL's does not require the server to have the replicas of all partitions. If a read/write replica is present at one partition, it can access the rules up to the country(C) or Organizational (O) object.
- Third-party URL filtering solutions such as N2H2 or SurfControl were enabled at the server level. The access rules comprising of third party URL filtering solutions were configured at the server level for a specified user and groups and processing of these rules were normal.
- Modification of any object state/attributes in the eDirectory which is also part of ACL will not take effect until ACLCHECK is restarted. For example, if a member in a group located within an organization or organizational unit is deleted from eDirectory, then one should unload the proxy.nlm and aclcheck.nlm and load those NLMs again.
- No Access Rules can be configured at the root level.
- When ACLCHECK is reading the rules from eDirectory, all the connections to the server is blocked. So when a client request is generated the request will not be processed until ACLCHECK completes its task.
- The third-party URL filtering solutions can be configured only at server level. These types of rules cannot be enabled at container level, as the database for this third party content filtering solutions are stored as files only on the server where they have been configured.
- Only one third-party URL filtering solutions may be used at a time.
- Configuration of VPN client policy using NWAdmn will not take any effect in NBM 3.8 as all the VPN policies can only be configured through iManager.
- If there are more embedded links/images/gif present in the page that has been requested there will be a slight delay in rendering those pages when compared to pages with normal text information.
- For the server under an Organization Unit (OU) it was observed that it took ACLCHECK around 20-22 minutes to read the rules from eDirectory. This time taken for ACLCHECK to read the rules from eDirectory will increase if the server is below the containers. So, it is recommended to not have any request or response during those times as it will not be processed by the server. For example, using NWAdmn of a server where ACLCHECK is reading the rules from eDirectory, modifying access rules of any other server will lead to improper configuration of that server's rules.
- Servers will abend when ACLCHECK is reading the rules from eDirectory and if we unload proxy at the same time. So, it is recommended, to not perform any action on the server when ACLCHECK is reading the rules from eDirectory. ACLCHECK provides the console messages while reading the information from eDirectory, as follows. On commencing reading the rules it prints:
- If the page requested by a user who is member of a group under Organization Unit, the processing of ACLCHECK will be delayed and response will be slower.
- Access rules at the peer level of the server or the container will not be applicable with the effective rules.
"ACLCHECK.NLM is reading rules from NDS"
and once it ends it prints:
"ACLCHECK.NLM read rules from NDS"
The following switches can be specified on the LOAD ACLCHECK command in the NCF file where you start NBM.
/Bxxx - enables you to define how often ACLCHECK tests for changes in user group membership. (User groups can be used to create BorderManager Access Rules.) By default, ACLCHECK will check user groups every hour and will reread the rules if a change is detected. You might want ACLCHECK to do this only every few hours to reduce the number of times per day that the rules are re-read. When using this switch, replace xxx with an integer starting with 0. This is the number of hours ACLCHECK will wait before testing for group membership changes. For example, using /B0 disables ACLCHECK's regular testing for group membership changes and /B24 will cause it to test group membership and reread the rules only once per day (every 24 hours).
/G - Enables smart group change detection. This switch requires eDirectory DS.NLM version 7.44 or later on all servers that host replicas of the user partitions. By default, to check for changes to group membership, ACLCHECK reads all group memberships from every group mentioned in an ACL rule. Therefore, ACLCHECK must go through the tree to find the group and then reread each one of the members from the list for each group. This action alone requires a great deal of eDirectory processing. If a group membership change is detected, ACLCHECK must reread the rules and go through the tree again. With the latest version of eDirectory and the /G switch, ACLCHECK can now check a timestamp on the group object to know whether it has changed.
Accessing the server level access rules are faster irrespective of the position of the rules. Rendering of html page for the members inside the specified group will be comparatively slow with that of specific members. For the rules inside the Organizational Unit (OU) both for the specified users and groups, the response will be slower. It is recommended not to perform any operation on the server when ACLCHECK is reading rules from eDirectory. So if the server is at the organizational (O) level it is recommended to run ACLCHECK check frequently (say 1 hour). If the server is under any of sub-container it is recommended not to have ACLCHECK check frequently (once in a day around midnight when the number of request is minimum). It is not advisable to frequently change the rules at container level as this will take a long time for ACLCHECK to read rules from eDirectory.
Answers to some of the eDirectory tree structure related questions: http://www.novell.com/coolsolutions/nds/qna/nds_tree_design_questions.html
More switches for ACLCHECK: http://nscsysop.hypermart.net/bm35c09.html
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com