File Migration Utility (FMU)

This is the second tool that Services for NetWare 5.0 provides that you can use only on Windows 2000 Server. FMU is used to migrate files and directories from NetWare volumes to Windows 2000 disks, while keeping intact security permissions. You can use this tool with both the IPX/SPX and TCP/IP protocols.

When you migrate files from NDS to Windows 2000, the MSDSS utility discussed in the preceding sections can be used to create a file that FMU uses to maintain user and group relationships and rights associated with files and directories. Before using FMU, be sure to read these sections! MSDSS maps organizational units (OUs) and organizations from NDS to the Active Directory by creating local security groups for every NDS OU and organization.

FMU is installed when you install MSDSS. To start the actual file migration process, click Start, Programs, Administrative Tools, and then File Migration Utility. The File Migration Utility Wizard, pops up and performs some preliminary functions. When it has finished, the Next button becomes available. Click Next and you'll see a large property sheet that has tabs, each of which can be used to perform a step in the migration process.

In the Step 1 tab, you must enter the full path for the migration log that you created using MSDSS. You can use the Browse button to locate the file if you don't recall where it was created. After you locate the file, click the Load Data button to read in the file. Note that at the bottom of the screen you'll see a display called Steps Completed, with boxes numbered 1 through 5. If you do not have time to complete the entire migration process in one session, or if you have to stop and rethink the process, you can look here to see what you've done so far. You can use the Allow Step Completion inAny Order check box if you want to perform steps out of order. Each time you click the Next button you move to another step. Using this check box, you can bring up any of the steps. The View Maps and Access Rights buttons enable you to view how access rights are mapped between Windows 2000 and NetWare access rights. This might be necessary, for example, if you have a file that has the NDS Modify right associated with it. By default, this maps to the Windows Read right. You can change this to the Write right if you want to by using the Access Rights button. Click the Next button to continue.

The Step 2 tab shows you the Active Directory account that you used to log in to the Windows 2000 server. Use the NetWare Connections button to show any current connections you have made to NetWare resources. If you have yet to log on to NDS or a bindery server, use the Log On to Novell button to do so at this time. Enter the required NDS or bindery account name and password, and click Next.

Step 3 enables you to select the source and target of the migration task. Use this step to select the NDS or bindery volume or directories that you want to migrate to the Windows 2000 server. Under Target, select the Windows 2000 file shares or directories that will be used as the location for the files to be migrated. When you've finished making selections, click on Map and then, of course, click the Next button.

In Step 2 you review your Windows logon and can log on to the Novell network if you have not yet done so.

Step 4 enables you to create a log file and select options for generating the log file that will be created during the migration process.

If the migration will involve a lot of files, you can help reduce the size of the log file by using the Enable Compression (NTFS only) check box. If you want to append a date and timestamp in the log- file to determine when a file was actually migrated, use the next check box. The Stop Migration If Disk Reaches Capacity check box does just what it says!

You also can set a maximum size for the log file in the Maximum File Size field, or leave it at the default of zero to allow the file to grow to any size. If you set a value for this field, the check box underneath it, Overwrite Log File When Maximum Size Is Reached, should be used so that the process will continue if the log file exceeds the size you set.

The radio buttons under New Log Entries enable you to elect to either append new entries or overwrite existing entries when you use the same log file to perform migrations at different times. The Log Detail Level drop-down menu enables you to select the amount of information that is logged for each file. When you've finished configuring the log file, click Next to proceed to the next step.

Step 5 is used to scan the volumes and directories you selected as sources from NDS or NetWare for the migration. Click the Scan button and the program counts the directories and the files within them, and checks that the correct access rights are associated with each volume (or directory/file).

If any errors occur, you can choose to continue and simply use a manual method for copying the files or directories. However, if a large number of errors is encountered, the FMU utility will stop and you'll need to rethink your migration. Go back to the previous steps in the process to see whether you've entered any incorrect information or ignored access rights required to access the NDS or bindery data.

Another thing that can cause errors during the migration process is opened or locked files on the NetWare server. You might want to perform Steps 1 through 5 and save the actual migration (Step 6) until a time when you can obtain downtime for your NetWare servers to ensure that all files and directories that are to be migrated are accessible. For example, to perform the migration, you must be logged on to the Windows 2000 server with an account that is a member of the Domain Admins group.

Finally, when you are ready to perform the actual data transfer, step 6 enables you to start the process. On the step 6 tab, click the Migrate button. Depending on how much data is to be transferred from Netware to Windows 2000, the process can just take just a few minutes or many hours.

After you've migrated your files to Windows 2000 servers, you should perform testing to be sure that your clients can connect to the Windows 2000 servers and that the files and directories are set up as you planned. After everything checks out, consider the migration a success and decommission those NDS servers!

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.

What to Monitor on NT part 1

How do you know what to monitor on an NT system? First, you definitely want to watch for any well-known hacks. Most NT IDSs do this today. The next kind of event you want to know about is anything that might affect the security of your system. No doubt that sounds a bit broad. Unfortunately, this description is vague and does encompass a number of events. Here are some examples:

• A new user is added to your system.
• The administrator logs in or logs out.
• The administrator establishes a trust relationship.
• Someone deletes a critical system file.
• Someone changes another user's profile.
• Someone takes ownership of another user's file.

These types of activities are all single events that can affect the security of your system. Even a single login event is something you might want to monitor. How much to monitor depends on how tight your security must be. System monitors, such as KSM and eNTrax, have a predefined set of events or signatures they detect. If you don't know which of these events to capture, select all of them until you have a better idea of what's important. Two very important event categories to keep an eye on in NT are privilege changes and impersonation. Both are ways one can gain additional privileges.

Increased Privileges

When a user is created on the system, a set of default privileges is granted. Privileges allow a user to perform operations such as shutting down the system, adding other users, acting as part of the operating system, creating processes, logging in remotely, and backing up files belonging to others. DAC and privileges together limit what an individual user can do on the system.

A privilege vector is stored with the user definition in the system. Privileges associated with a group also are stored with the group information in the SAM. When a user logs in, the privilege vector is constructed from privileges assigned to that user and privileges defined for groups to which the user belongs. The complete set of privileges controls what kinds of operations that user is allowed to initiate while logged in to the computer. A privilege that enables a user to act as an administrator is something to be carefully monitored. The GetAdmin hack introduced earlier in the book grants administrator rights to an arbitrary user by exploiting an NT bug. The event log contains enough evidence to spot when this happens. To distinguish the GetAdmin hack from a legitimate change in privileges, the IDS must contain a signature relating multiple events. Nonetheless, the event log does allow an IDS to detect GetAdmin.

NT administration somewhat simplifies the task of assigning privileges to user and groups. Sets of common privileges are grouped into rights. Instead of assigning individual privileges to a user, you normally assign rights through the user and group manager application. If you want, you can select privileges one at a time and grant them to specific users, too.

The NT audit log reports privilege changes for users in distinct event records. IDSs watch the log for these entries to alert you to possible security problems. The privilege vector associated with an access token also can be altered through programming interfaces provided with NT. This means that the administrative GUI is not the only way for users to increase their privileges. You saw that UNIX systems had a number of facilities for increasing privileges. SUID programs in UNIX give users temporary privileges associated with the owner or group associated with that program. NT has similar capabilities through impersonation.