Novell Security

Novell's NetWare has been around for many years, though it is not the dominant network opera system anymore. Early versions were limited in their capability to keep track of events, but this changed with NetWare 4.x. The most useful tool for older systems is the AUDITCON tool, which canbe used to configure and audit a wide rang of system events.

SYSCON and AUDITCON

The SYSCON utility that was used in NetWare 3.x was limited in the type of information it could yide to the administrator. It was basically limited to statistical information such as the number of blocks read/written and the services the server provided. In NetWare 4.x the AUDITCON utility pr vides an advanced tool that is superior to SYSCON in two ways:

• The information is more granular. File-system events, such as access and modifications to individual files or directories, can be tracked. Events are also audited for NDS objects.

• The auditing role has been separated from the administrator's role, enabling an employee other than the administrator to act as the network auditor.

Both of these features are significant advances. The first makes the information gathered more than just statistical. You can now track access and the type of access to individual files or objects. The second can be used to ensure that the network administrators, usually all-powerful people who can do anything on the network, are also held accountable their actions. Network security is not compromised by the auditor, however, because this person does not have to be granted administrator-like rights to objects such as the SYS : SYSTEM directory. The administrator's and the auditor's functions are separated.

After the administrator has enabled auditing on volumes or containers and designated the auditor, the auditor can use the AUDITCON utility to check the system. Using AUDITCON, the auditor can modify which events are audited on which resources, and can produce reports showing auditing information.

Auditable Events

The precise granularity of things you can audit is what makes AUDITCON a powerful tool. The person who has been set up as the auditor can perform these actions:

• Audit by event—This includes file-related events such as open, read, write, and create files or directories. These can be audited for all users (global) or on a per-user basis. You can also audit printer queue events (QMS), server events (such as when it is brought down or restarted), and user events (such as user logins and logouts or the creation or deletion of user objects).

• File or directory events—You can select files or directories for which all access will be audited.

• User—You can select individual users for which auditable events will be recorded.

Auditing Files

The auditing software uses several places to store its data:

• NET$AUDT.DAT—This file can be found at the root of every volume that has auditing enabled. It is always flagged as an open file to prevent anyone other than the auditor from accessing it directly. This file stores binary information in a binary format only for the volume on which it resides.

• NDS Database—Auditing for events for the directory (NDS) is stored in the NDS database.

• AUD$HIST.DAT—This file is used to keep track of actions taken by the auditor(s). After all, someone has to watch the watcher! When more than one auditor is assigned to the network, each should have a separate user account so that this file can be used to track the actions taken by each auditor, giving still more checks and balances to the system.

• NET$AUDT. CFG—This file contains audit file configuration information and is found at the root of the volume that is being audited. Using the AUDITCON utility, you can change the configuration information stored here, such as the maximum size the audit file can grow to, whether to allow more than one auditor to access the audit file at the same time, and whether dual-level passwords are used, among other things. The dual-level password requires an additional auditor password to be used when changing configuration information.

Using AUDITCON to Enable Auditing

An Admin user can enable auditing on a volume by running the AUDITCON utility. From the main menu, select the Enable Volume Auditing option and enter the password for that volume. If an old audit data file exists on the volume, it is replaced by the new file.

After this has been done, the administrator should give the volume password to the auditor, who should run AUDITCON and change it to a new value that the administrator does not know. Note that if the password is forgotten, the volume must be deleted and re-created if you want to change the password. You cannot recover the password. Also, without the correct password, you can disable auditing on the volume!

To change the audit password, the auditor should run the AUDITCON utility and select Audit Files Maintenance. From the next menu, select Auditing Configuration and then Change Audit Password. When prompted, enter the new password.

Producing Reports

Reports are produced to translate the binary auditing data into a format readable by humans. These reports can be produced by selecting Auditing Reports from the AUDITCON main menu. For security purposes, you should never leave these reports in a directory that can be easily accessed by other users. Instead, view or print the report text files and then delete them. You can always rerun the report later if you need to obtain another copy.

When producing an audit report, you can select events by date, time, and event; you also can choose to include or exclude selected files, directories, or users. This filtering capability makes it easy to get right to the important data when you are troubleshooting a security breach. If you are performing a regular review of the system, you can select all data and spend hours poring through it, but a large volume of data will most likely make it easy to miss an important event. In other words, when performing an analysis of the data, it's best to have a target objective of files or events, or possibly users, you need to keep an eye on.

NetWare Auditing Solutions

NetWare 6.5 contains an auditing utility developed by Blue Lance (www.bluelance.com) called LT Auditor+ Server Edition for NetWare, which replaced the Novell Advanced Audit Service (NAAS) added to NetWare 6. LT Auditor+ Server Edition for NetWare is a "light" version of Blue Lance's popular LT Auditor+ that supports only a single NetWare 6.5 server

If you need support for eDirectory, Windows 2000/NT, or other advanced features, you should consider upgrading to the full version of LT Auditor+ 8 SP4 or use Novell's own Audit 2.

In addition to providing LT Auditor+ Server Edition for NetWare as part of NetWare 6.5, Novell also sells its own full-featured auditing solution known as Novell Audit 2, an upgraded version of Novell Nsure Audit 1.0. Novell Audit 2 is a cross-platform auditing product that supports Novell NetWare 4.2 and above; Windows NT 4.0, 2000, 2000 Server, XP and Server 2003; SUSE Linux Enterprise 8; Solaris 8 and 9; RedHat Linux 7.3, 8, AS, and ES 2.1.

Novell Audit 2 works by using an agent which is used to collect data on an object, such as a server. A secure logging server receives this information from agents on the network. Agents are configured through a simple text-based configuration file known as the logevent. On a NetWare server, this file is called /etc/logevent.cfg; on Linux and Solaris, as /etc/logevent.conf; on Windows, as logevent.cfg in the default Windows folder (usually \Windows or \WinNT). Novell supplies a Java-based Platform Agent Configuration Tool to provide a graphical editor for the logevent file.

Novell Audit 2 can receive log events from Novell eDirectory 6.x, DirXML 2.0, NetMail 3.5 and above, iChain 2.2 SP1, BorderManager 3.8, NetWare NSS and NetWare Traditional file systems.

You can learn more about Novell Audit 2 by visiting its home page at the URL www novell.com/ products/audit /.

RMON (Remote Monitoring) continue...

As this list shows, RMON provides a greater deal of functionality compared to SNMP. It allows for the collection of statistical data from all levels of the OSI reference model, including applications at the top in RMON2.

Because Ethernet and Token-Ring networks operate in a fundamentally different way, additional groups are defined in RFC 1513 that are specific to Token-Ring networks:

• Token-Ring Statistics—A group to store information about the behavior of the ring, from traffic volume to the number of beacons occurring, ring purges, and other information specific to Token-Ring.
• Token-Ring History—Similarto the History group used for Ethernet, this group keeps track of events on a historical basis.
• Token-Ring Station—Detailed information about each station on the ring can be found here.
• Station Order—Thephysical order of stations in the ring can be determined by information stored in this group.
• Station Config—Configuration information for stations is stored here.
• Source Routing—Monitors information about Token-Ring source routing for inter-ring traffic.

Alarms and Events

RMON agents can be programmed to take actions when specific things happen on the network. The Alarms and Events groups provide an important intelligence function.

Configuring an alarm consists of specifying a variable to be watched, the sampling interval, and the event that will be performed when a threshold is crossed. The threshold can be a rising or a falling threshold, or both. For example, an alarm can be set to notify you when something begins to go awry, and to tell you when the situation gets better.

An event that is generated by an alarm can be configured to send an SNMP trap message to one or more management consoles, and store the event in the Log Table. The management station can then take the actions it deems necessary, including retrieving information from the Log Table.

Establishing a Baseline

When making decisions on how to set up alarms and the events they generate, you should consider how the network functions normally. First monitor the network using RMON agents over a long period, noting when variations in traffic or errors occur. Make note of any fluctuations that regularly occur for specific dates or for a particular time of day.

Different network segments might require different sampling intervals and thresholds. For example, a local LAN segment might be subject to wide variations depending on only a small number of users, whereas a major backbone might fluctuate much less as traffic from many segments is blended together. When deciding on a sampling period, it's best to use a shorter interval for a segment that experiences frequent fluctuations and a longer interval for a segment that behaves in a more stable manner.

Response to alarms can be in the form of immediate corrective action, as in the case of a defective device, or a long-term solution such as additional capacity or equipment. Regularly review the baseline values you set, and change them as network usage or topology changes. If alarms and events are not configured to reflect activity that is of a genuine concern, network operators might begin to ignore them, much like what happened to the boy who "cried wolf."

NT Security continue...

A final choice for directory objects is whether to audit only the current directory or to enable auditing for all of its subdirectories. This simplifies the administrators task when auditing is being configured. Caution is necessary, though. If you turn auditing on for the NT system directories and subdirectories, your event- logging activities will slow down the computer. Because all major executables are in these directories, this is unfortunate. Watching for Trojan Horses in system directories is reasonable goal for an IDS. Your only alternative is to be more granular in configuring auditing. For example, you could monitor everything except for read and execute events. This should catch most Trojan Horse attempts. However, if there is a file that only administrators should access, you might want to monitor any activity against that file. Be selective, or you quickly will notice sluggishness in your system's performance.

When you enable auditing for an object, the appropriate bits ate set in that object's SACL. This activity itself generates an event that shows up in the log. Therefore, if you have turned auditing on for an object, and later you see an event that turns auditing off for that object, something unpleasant might be going on in your system.

Although not all NT IDS vendors choose to do so, a program can attach to the security event log and monitor events in real time. Today, Kane's Security Monitor and Centrax's eNTrax tools both periodically read the event log rather than process events in real time. An option to read the logs on an interval basis or to capture events in real time probably will be seen in future versions.

Not all events in the NT log contain sufficient data for IDSs to work. For example, remote logins do not identify the originating IP address or node name in the event record. An IDS vendor needs to gather this information from elsewhere in the system and correlate the information with the appropriate events—no trivial task. If the IDS is loaded as a service when the system boots, then process trees for login users can be constructed by monitoring the event log. Process and thread identifiers are associated with kernel data structures for sockets, pipes, and other communications data. Therefore, coalescing this information is possible and the IDS can use it to disconnect a remote user, who is hacking the system.

There also have been cases in which events that an IDS depended upon were no longer emitted after service packs were installed. Ripple effects of bug fixes are the leading suspects for this problem. You undoubtedly have been hit by this same type of problem when vendors of other products choose to deprecate an interface that you were relying upon for an in-house application.

Event Records

Information provided in the NT event log record includes header fields followed by an event specific description. Header fields are listed in Table 10.1. Table 10.2 shows the fields usually found in an event description.

Not all fields are always filled in for the record. For example, if a user's privileges are modified, in the Privileges field of the event record, you will find information describing what changed. Any time you see that someone has gained an administrator privilege, it's time to investigate and determine whether the change was legitimate. Object accesses are reported in the Accesses field of the description. Both fields can contain multiple lines of information when inspected through the Event Viewer on NT or through your IDSs browser.

Table 10.1 Header Fields for an Event Record

date time event ID

source of the record (security, application, system)

type of event

category (object access, system event, user event, and so on)

computer node name

user name

Table 10.2 Event Description Fields

object server name object type (file or user, for example) object name a handle ID operation ID process ID primary User Name

primary domain client user name client domain client login ID information about any object accesses information about any privileges changed

Luckily, if you have an IDS for NT, you do not need to sit and watch events as they appear in the event log. Instead the IDS will summarize the information and display alerts when necessary. If you have the option of deciding which attacks to watch for, or if your IDS will notify you about select individual events, then you might want to think about what you should monitor to catch NT attacks. The next few sections give recommendations and describe well-known attacks against NT. The topics covered are not meant to be exhaustive. New NT hacks are posted regularly. See the NTbugtraq archives maintained by Russ Cooper at www.ntbugtraq.com. He also moderates the NTbugtraq mailing list.

NT Security

Subjects in NT are processes and threads. Each process and thread is associated with an access token that is a complex data structure defining characteristics of the subject. One of the most important attribute lists in the access token is its privileges. Any time a process or thread is able to increase its privileges, that subject is able to access other resources that might normally be off limits.

Access control lists are associated with objects. Two different ACLs—object ACLs and system ACLs. Object ACLs control access requests by subjects. System ACLs control activities, such as auditing for that object. Depending on the type of object, the ACL entries vary. For example, access control entries (ACE) for files are different than they are for registry keys.

Based on this simple review, you probably see some of the important events to monitor on NT systems. Any time a change is made to a user's privilege list in the user database you want to be notified. Changes to ACLs for important system files and directories also are potential preludes to an attack. As in UNIX systems, you should watch for attempts to install Trojan Horses. Especially serious is any attempt—successful or not—to increase the privileges associated with a thread or process.

Sources of Data for NT IDSs

By now, it should be apparent to you that intrusion detection is a special case of monitoring. Performance monitoring tools track network traffic, system resource utilization, and application behavior. IDSs also need data from various sources to operate effectively.

Vulnerability scanners that assess the state of your machines operate in one of two modes. Remote assessments are carried out from a central console and targeted at individual nodes in your network. With a remote scan, no special software is needed on the target machines. Local assessments are undertaken by software specifically installed on the node. When a scan is activated by a remote manager station or by a scheduled job, the local scanning software runs on the target node itself.

NT local vulnerability assessment tools operate much the same way as UNIX scanners. They look at configuration information on the system, inspect the contents of files, scour through registry entries, and attempt to crack passwords in the SAM. Other features, such as file-integrity checkers, are supported as well. Recall that a local scanner has the advantage of operating on the system as a login user. This means that the local scanner can read files and access other resources that a remote scanner cannot. Of course, you must install the local scanning code on each target.

Remote scanners against NT systems probe for known network configuration problems, check for back-level programs with holes, and attempt to gain access to the system by breaking in as normal users or as the administrator. The source of data for these IDSs is primarily feedback that comes from interacting with NT network services or applications, such as the Internet Information Server (IIS). Remote scanners benefit from the fact that they do not run client code directly on the target. For this reason, vendors can combine both NT and UNIX probing into the same product. As in the case of UNIX remote scanners, it is possible to peer into some of the internals of an NT system even though you are not running a process on that system. For example, if the trust relationship is configured to permit remote access, some NT registry entries can be inspected. Microsoft's Server Message Block protocol also divulges information to remote scanners, including the list of currently logged in users.

Network sniffers for UNIX and NT often are combined into one product, too. The source of data is the same for UNIX and NT network sniffers. Only the attacks monitored varies between the two operating system types. Many attacks are equally applicable to the IP stacks on both, such as SYN Flood.

System-level IDSs in UNIX and NT rely on different datastreams. NT provides an event log (or audit log) that tracks many important activities on the system. Vendors, who write system-level IDSs for NT, such as Centrax and Kane, depend on the event log for the data that drives their engines.

NT Event Log

There are really three different event logs in NT—system, application, and security. The security log is the one IDS vendors are most interested in watching. Records are stored in a log file as events occur. NT Administrators can control the behavior of the logging subsystem in a number of ways. Space is controlled by defining a limit on the size of the log file. When the threshold is hit, options include the following:

• Overwriting events that are only N days old
• Pushing out the oldest records as new ones come in
• Halting the system to prevent loss of an audit trail

To configure auditing, you first decide which event categories you want to monitor:

• Logins and logouts
• File and object accesses
• Changes in user rights
• Processes or thread events, such as creation and termination
• Changes to the security policy for the system, such as giving additional privileges to a user
• Restart, shutdown, and other system events

When you know which categories of events to monitor, you must enable auditing for individual users and objects. Auditing is turned on for a user through the user and group manager application. To enable auditing for an object, such as a file or directory, you use the File Manager. For a file, you can select whether to monitor success or failures for the following access types:

• Reads
• Writes
• Executes
• Deletes
• Permission changes
• Ownership changes