Protecting NDS from Malicious Internal Attacks with NetVision's DirectoryAlert

Articles and Tips: article

W. Dale Cave
DirectoryAlert Architect
NetVision, Inc.

01 Mar 2000

NetVision's DirectoryAlert version 2.0 protects NDS from both internal and external intruders by alerting you in real-time as security violations occur. DirectoryAlert provides important details in these instances that can assist in preventing violations from reoccurring.

While other products focus on the health of the directory, attacks through firewalls, scheduled processes and server performance, DirectoryAlert provides real-time, security, auditing and reporting on any and all objects within the NDS tree.

After describing the DirectoryAlert architecture, this AppNote demonstrates how to configure DirectoryAlert, monitor security violations, and help prevent security violations.

For more information about NetVision's DirectoryAlert, including quick-start and deployment guides, visit the product Web site at:

http://www.netvision.com/directoryalert/

DirectoryAlert leverages NetVision's patented Global Event Services (GES) technology. GES is an efficient and scalable directory-base event system that is also used in the Novell Synchronicity product line, also developed by NetVision. (Novell Synchronicity synchronizes NDS users and groups to other platforms such as Microsoft Windows NT, Microsoft Exchange, Lotus Notes, and NetWare 3.)

For information on Novell Synchronicity, visit Novell's product Web site at:

http://www.novell.com/products/synchronicity/

DirectoryAlert Architecture
Monitoring Security Violations
Creating Directory Policies
Preventing Security Violations
Conclusion

DirectoryAlert Architecture

After describing the DirectoryAlert architecture, this AppNote demonstrates how to configure DirectoryAlert, monitor security violations, and help prevent security violations.

For more information about NetVision's DirectoryAlert, including quick-start and deployment guides, visit the product Web site at:

http://www.netvision.com/directoryalert/

For information on Novell Synchronicity, visit Novell's product Web site at:

http://www.novell.com/products/synchronicity/

Copyright © 2000 by Novell, Inc. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the express written permission of Novell.

All product names mentioned are trademarks of their respective companies or distributors.

DirectoryAlert Architecture

DirectoryAlert consists of the following components:

GES NetWare Loadable Module (NLM)
DirectoryAlert Agent
NetWare Administrator Snapins
Monitor Settings (Identification, Registration, and Event Consumers)

GES.NLM

DirectoryAlert is powered by NetVision's Global Event Services. GES.NLM is an innovative service that runs on NetWare 4.10 or later. GES provides real-time notification of events to any client at any location on the network that has sufficient rights granted. Since GES is event-driven, no polling of NDS occurs. Only events that are being monitored (configured through NetWare Administrator) are distributed to the DirectoryAlert Agent, making GES and DirectoryAlert real-time and extremely scalable.

DirectoryAlert Agent

The DirectoryAlert agent is a Windows NT service that logs in and authenticates to NDS. GES sends applicable events, DirectoryAlert then formats the information and reports to any number of Event Consumers.

NetWare Administrator Snap-ins

DirectoryAlert has two NetWare Administrator snap-ins for easy and convenient management. One manages GES and the other manages DirectoryAlert. The GES NetWare Administrator snapin supports the configuration of GES through NDS. The DirectoryAlert snapin supports the management of DirectoryAlert Monitor Settings and the viewing of reporting information that has been sent to NDS objects.

Monitor Settings

DirectoryAlert allows tremendous flexibility in the monitoring and reporting of NDS events. Monitor Settings are user-definable requests for event notification. There is no limit to the number of Monitor Settings that can be defined. Each monitor setting has three types of information that can be set: Identification, Registration, and Event Consumers.

Identification. The Identification information contains the name of the Monitor Setting and a brief description (see Figure 1). This information is helpful when viewing the list of all Monitor Settings and when being notified of an event.

Figure 1: DirectoryAlert's Monitor Settings main page.

Registration. Each item in Monitor Settings contains a list of registrations (see Figure 2). These registrations are simply requests to receive NDS events. Almost all NDS events, such as attribute changes, object creations, object deletions, object renames, object moves, and so on, can be monitored.

Figure 2: Monitor Settings Registration page, showing Context tab.

In the example in Figure 2, the NDS events "DSE_ADD_VALUE", "DSE_DELETE_ATTRIBUTE" and "DSE_DELETE_VALUE" are being registered. The DirectoryAlert documentation details the events and their purposes. The ones listed here will track attribute value additions, attribute value deletions and attribute deletions. Note that an attribute deletion occurs when the last value of an attribute has been deleted.

For each registration, four types of additional filtering are supported:

Context
Classes
Attributes
Objects

These additional filters are logically ANDed together to allow very specific filter criteria.

Context. The Context restriction filters events that do not match the context or subtree specified. Figure 2 shows the Registration page of a Monitor Setting with the Context tab enabled. Note that you can select a specific container or an entire subtree.

Classes. The Classes restriction filters events that do not match the list of classes specified. Figure 3 shows the Registration page of a Monitor Setting with the Classes tab enabled.

Figure 3: Monitor Settings Registration page with Classes tab selected.

Figure 4 shows the schema class list that is displayed when browsing the classes.

Figure 4: DirectoryAlert's Class List.

Note that you can filter All Classes or any subset of Selected Classes. The list may be exclusionary if you check the "Exclude Classes" checkbox.

Attributes. The Attributes restriction filters only those events that relate to the attributes specified. Figure 5 shows the Registration page of a Monitor Setting with the Attributes tab enabled.

Figure 5: Monitor Settings Registration page with Attributes tab selected.

Figure 6 shows the entire attribute list when browsing the attributes.

Figure 6: DirectoryAlert's Attribute List.

Note that all attributes can be filtered or any subset of attributes. The list may be exclusionary with the selection of the "Exclude Attributes" button.

Objects. The Objects filter allows only those events that satisfy this object criterion to be reported. Figure 7 shows the Registration page of a Monitor Setting with the Objects tab enabled.

Figure 7: Monitor Settings Registration page with Objects tab selected.

Note that all objects can be filtered or any subset of objects. The list may be exclusionary with the selection of the "Exclude Objects" button.

Event Consumers. Event Consumers are DirectoryAlert extensions that report the events. DirectoryAlert has Event Consumers that report to text files, XML files, LDIF files, e-mails, pagers, databases (ODBC compliant), SNMP, and NDS. This extensible architecture allows other reporting destinations to be supported rapidly without having to revise DirectoryAlert (see Figure 8).

Figure 8: Creating a new Monitor Setting on the Event Consumers page.

The Installed Event Consumers list shows the available Event Consumers. Any combination of these Event Consumers can be configured for each Monitor Setting.

In this example, when the event defined by the registrations (not shown here) occurs, the notification will be sent to a database, to an NDS object, to an e-mail address, and to a file. When each of these Event Consumers is added to the Event Consumers to Receive Event list, a configuration dialog specific to the Event Consumer is displayed. A specific Event Consumer can be specified more than once; for instance, the event can be reported to two databases, six e-mails, four pagers, and so on.

Monitoring Security Violations

Let's suppose your company has a habit of using NDS groups and occupational roles for assignment of rights and privileges within NDS. ACLs granted to individual objects are not only deemed unmanageable but are also considered a security risk because of such unmanageability.

After installing NetVision DirectoryAlert, perform a details on the DirectoryAlert object within the tree and select the Monitor Settings page. In our example, the DirectoryAlert server object is the last object in the list and has the name "DirectoryAlert" and icon as shown in Figure 9.

Figure 9: DirectoryAlert Server object, as shown within NetWare Administrator.

Within the DirectoryAlert Details page, click the New... button to create a new Monitor Setting. A Registration dialog appears with a list of Monitor templates. These Monitor Templates are simply pre-defined Monitor Settings. Select "ACL Changes to [Root]" (see Figure 10).

Figure 10: New Monitor Setting using the "ACL Changes to [Root]" template.

Click Next in the wizard. The Monitor Setting Identification page appears allowing the change of the Monitor Setting name and description.

Click Next in the wizard. The Monitor Setting Registration page appears showing the registrations already set. These were automatically set because of our selection of the Monitor Template "ACL Changes to [Root]".

Click Next in the wizard. The Monitor Setting Event Consumers page appears. In this example, notification will be sent to an ODBC compliant database, the NDS Object DirectoryAlert.NetVision, e-mail account dcave@netvision.com, and to a file.

Click Finish on the wizard and OK on the DirectoryAlert server object. With the DirectoryAlert Agent already running, this new Monitor Setting will automatically be detected.

To test this, I logged in as Admin.NetVision and assigned SneakyUser.Other. NetVision ACL rights to [Root] with Object rights set to Supervisor. Within seconds, information on this event activity was sent to the Event Consumers configured for this Monitor Setting.

Figure 11 shows the e-mail message that was sent by the DirectoryAlert Agent. In this example, the "From" user is the same as the "To" user because I have configured the DirectoryAlert Agent to use my personal e-mail address.

Figure 11: E-mail notification of ACL changes to Root.

The event information was also sent to a database, to an NDS object, and to a file.

Creating Directory Policies

Directory security violations can come by malicious theft of rights, by accident, or through inexperience. Roles, Templates, and Groups are intended to ease the granting of directory rights and administration, but they can also be used to commandeer rights. Other security-related incidents may come in the form of applying security restrictions or ACLs contrary to corporate IS or security policies.

Some organizations have strict and formal policies and procedures for directory management. Others have less stringent rules, but nevertheless have directory preferences and expectations. These policies are simply rules to which an organization would like its directory, in whole or in part, to adhere.

This section gives a number of examples of directory policies, and then demonstrates how to configure DirectoryAlert to monitor, audit, and report NDS changes pertinent to these policies, all in real time. I'll give example scenarios in just two categories of violations: Access Rights Violations and Password Violations. While these are only a small sampling of the types of security and policy concerns an organization may have, they demonstrate the ease and flexibility of enforcing NDS and security standards and policies.

Access Rights Violations

This section has examples of violations relating to access rights. It describes Monitor Settings relating to group memberships, security equals, templates, ACLs, and roles.

Scenario 1: An administrative group has had its user membership list changed.

Violation Relates to: Group Memberships

Monitor Template Name: "Group Membership Changes"

Special Configuration: Because we want to monitor a specific group we need to specify the group name. In the Registration page of a new Monitor Setting, select the Objects tab and browse for the NDS group of interest. Be sure to do this for each event in the Event Name list box (see Figure 12).

Figure 12: Specifying specific objects for a registration.

Notification: Notification will occur whenever a user is added or removed from the specified group.

Scenario 2: A common user was just granted security equivalence to Admin.

Violation Relates to: Security Equal to

Monitor Template Name: (Not applicable)

Special Configuration: Add NDS Events DSE_ADD_VALUE, DSE_DELETE_ VALUE and DSE_DELETE_ATTRIBUTE. For each of these events, add the attribute filter "Equivalent to Me" and the object filter of the Admin object.

Notification: Notification will occur whenever any object is granted security equivalence to the Admin object. Keep in mind that we are looking for the "Equivalent to Me" attribute change on the Admin object, not the "Security Equals" attribute. The "Security Equals" attribute is what changes for the object that just got granted security equivalence to the Admin object.

Scenario 3: Someone just changed an NDS object template.

Violation Relates to: Templates

Monitor Template Name: (Not applicable)

Special Configuration: Add NDS Events DSE_ADD_VALUE, DSE_DELETE_ VALUE and DSE_DELETE_ATTRIBUTE. For each of these events, add the class filter "Template" or the actual object filter of the instantiated Template.

Notification: Notification will occur whenever any template object is modified (or a specific one if specified).

Scenario 4: An object was just granted (or had revoked) ACL Changes to a Country, a Locality, an Organization, or an Organizational Unit.

Violation Relates to: ACLs

Monitor Template Name: "ACL Changes to Organizational Containers"

Special Configuration: None.

Notification: Notification will occur whenever ACLs change for objects of type Country, Locality, Organization, or Organizational Unit.

Scenario 5: The occupant list of an NDS Role object has just been updated.

In this scenario, an occupant has been added (or removed) from the role, thereby granting (or revoking) the occupant object immediate rights as that role permits.

Violation Relates to: Roles

Monitor Template Name: (Not applicable)

Special Configuration: Add NDS Events DSE_ADD_VALUE, DSE_DELETE_ VALUE and DSE_DELETE_ATTRIBUTE. For each of these events, add the class filter "Role Occupant".

Notification: Notification will occur whenever any occupant of any role is removed or added.

Password Violations

This section has examples of violations relating to password violations. It describes Monitor Settings relating to user login restrictions, user password restrictions, and intruder lockout.

Scenario 1: An account has just been enabled or disabled.

Violation Relates to: User Login Restrictions

Monitor Template Name: "User Account Disabled Changed"

Special Configuration: None.

Notification: Notification will occur whenever a user account is enabled or disabled. Other login-related events refer to enabling/disabling password expirations, changing the date/time of the password expirations, setting/removing current connection limits, and monitoring last login times.

Scenario 2: A user account has just been set to not require any password.

Violation Relates to: User Password Restrictions

Monitor Template Name: "User Require Password"

Special Configuration: None.

Notification: Notification will occur whenever any user has a change relating to the Require Password restriction. Other user password-related events refer to allowing the user to change the password, setting the minimum password length, forcing periodic password changes including the required password change interval and time, requiring unique password, and limiting grace logins and setting those limits.

Scenario 3: An account has been "locked" because an invalid password was attempted and exceeded the retry limit NDS set for the account.

Violation Relates to: Intruder Lockout

Monitor Template Name: "Intruder Lockout Change"

Special Configuration: None.

Notification: Notification will occur whenever any user intruder lockout has been set or reset.

Preventing Security Violations

Let's say a user, JUser.Other.NetVision, notifies the help desk that his password is not working. The help desk staff member examines the details on the user, selecting the NDS Event Details page. This is the page that displays DirectoryAlert events reported to this object. An example is shown in Figure 13.

Figure 13: NDS Event Details on User JUser.

This page shows the sequence of events pertinent to his account (all information can not be displayed in this graphic):

JUser logged in
JUser logged out
Admin changed JUser's password
JUser logged in again (he must have known the new password)
Admin changed JUser's password again while he was still logged in (this is the problem)
JUser logged out
JUser unsuccessfully tried to log in six times

DirectoryAlert provides information never before available. The NDS administrator can configure what information he or she would like reported and have it reported to the NDS object to which it refers. These capabilities can be extremely useful in securing the directory, resulting in one or more of the following situations:

Securing the workstation
Securing the site
Strengthening password and/or other security policies
Apprehending the culprit

Conclusion

NetVision's DirectoryAlert provides unprecedented real-time alerting for a broad range of NDS object activities. By monitoring NDS for security and policy compliance, DirectoryAlert can be used to report violations, determine who, when, and how these violations occurred, and assist in preventing further similar violations.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.