Net work Security August 7 999

retest to be sure that the fixes software can easily introduce Aleph One’s outstanding were all done, and done new vulnerabilities. New BUGTRAQ), and these may properly. Any change in vulnerabilities are discovered pertain to an organization just configuration, any change in and publicized on a daily basis tested. Vulnerabilities should be hardware, any change in (on public mailing lists such as reassessed on a regular basis.

Auditing NT - Part 2 Alison Webb

This second article on NT auditing focuses on controlling users: whether or not they use the system, what they can do once they are in, and how to keep a record of what they have done. As with the operating system configuration that we looked at in the last article, you will need administrator access to review many of the security settings, and to review the security log. You will also be using tools supplied in the NT Resource kit to get listings of information that cannot be effectively scanned online.

User authentication

We start at the beginning with the authentication checks that NT does before any user is allowed on to the system.

Domains

If you have an extensive network, or one that controls groups of users with very different needs, you may have them organized in different domains. Each NT domain is controlled by a particular server (the primary domain controller) and has its own user list associated with it. However, analogous to the Unix trusted host, it is possible for one domain controller to trust the authentication carried out by another. Although cross-domain auditing is outside the scope of this article, you do need to check at the outset whether or not you will have to review it at your site. Check the Trust Relationships option in User Manager for Domains (in the Administrative Tools option of the Programs option in the Start menu) to see if this applies to you. If so, then you need to consider whether the trust placed in another network is justified.

14

The password policy

While you are browsing User Manager for Domains, you can

also look under Policies at the password policy. As usual, the main authentication check applied to users is their knowledge of a secret password. The site can dictate to some extent how easy or difficult to hack these passwords must be; the screen display shows the default settings as in Fig. 1,

We are used to the pros and cons of the different options, and I won’t repeat the arguments here, apart from pointing out one notable omission: any restraint on the form of the password. NT users can choose, for instance, simply to repeat the same character six times. To improve this,

figure 1. Default settings.

0 1999 Elsevier Science Ltd

August 7 999 Network Security

administrators can use a program in NT ResKit, passprop.exe, to force adequate password complexity (a mix of upper and lowercase letters and numbers or symbols). The same program can alS0

enforce administrator lock-out if he or she enters the wrong pass- word too many times, unless they are logging on at the domain controller itself. If you run passprop without parameters, you will display the current settings,

Users

To carry out the tests I list below, you will need a list of all users, and NT is not too good at providing this. I normally use the program AddUsers.exe (in the Reskit again) to list the users, their groups and any other information the site includes to a file which I analyse with IDEA. I combine this list with the onscreen browse in User Manager to do the following standard tests:

Are the users current? Are any IDS for unidentified users?

I match the names of users held in the NT to the phone book, or

other employee list, to identify unknown IDS.

Have users more than one ID?

Most audit software includes tests for duplicates, or you can simply summarize the file on username.

Does group membership conform with job descriptions?

I normally look at a sample here, including a couple of operational departments, and the system administrators.

Are individual password settings?

I also browse at least a sample of user settings to identify those with variations on the standard password policy shown in the screen dump above. NT allows the user administrator to change the standards to accommodate special requests (so passwords never expire, for example). Such requests may be valid, so you need to pursue exceptions to find out the justification (if any!) for them.

Are any IDS redundant?

I also run some checks to find out if all the IDS are currently in use, which I discuss in more detail under logging, later in this article.

User rights

As well as the file permissions I will come to in the next section, NT can grant users certain powerful rights on an individual basis. The most important of these are listed below, and you can browse them for your site under User Rights Policy under Policies in User Manager for Domains,

Additional controls over administrator IDS

Ideally, and at a large site, administrator log on should be restricted to certain workstations only, to reduce the risks of hacking. The lockout should be set as it is for normal users in the policy. Administrators are often worried about this, but for them, it applies to workstations only. The administrator will always be able to log on at the console - another reason why it is important

RIGHT

Log on locally This allows the user to log on at the server console.

Shut down the system (SeShutdownPrivilege)

Act as part of the operating system

Log on as a service This allows the user to perform security services,

Replace a process level token This allows a user to modify a security access token.

Bypass traverse checking This allows users to modify files to which they have access rights, even though they are in a read-only directory.

Change system time Allows resetting of the internal clock

Manage auditing and security log This is required to view the security log entries.

RESPONSIBILITY

Administrators and operators.

Administrators and operators.

This should not be necessary for people,

No named user should need it.

Again, no one should need this.

It is important to know how it is set, for reviewing file access

Administrators only,

The auditor should have access to it. Admini- strators do not need it to view and clear the log,

0 1999 Elsevier Science Ltd 15

Network Security August 7 999

that it is physically secure. The program passprop.exe in the Resource Kit can be used to enforce this setting. Many sites rename the original Administrator account, and set up a dummy Administrator account with no rights. They then monitor this via the Security Log to get early warning of illegal access attempts. If you think this is appropriate at your site, you may want to suggest it.

Restrictions on users in profiles and login scripts

Login scripts are associated with users and run at login time, to set options for the user. Profiles are similarly associated with each user, and set the desktop options the user can see. They can be very effective in limiting user access. The ADDUSERS.exe list shows the login script and the profile associated with each user, and they are also shown in each user’s entry under User Manager for Domains,

Login scripts are easy to review: you just browse the files. Profiles are messy. They comprise a collection of Registry settings, the results of which you can view in c:\winnt\profiles\username.You can see to some extent by browsing these files what options are available to the user. The base information is stored in a .DAT file under the user name, but you cannot read it. The only way to get a really good idea of how the profile works is to log on using it yourself.

Access control

Thus NT has the usual authentication checks. Once you are in, it operates the sort of file access control that we are used to from Novell and Unix systems, but only if disk partitions are formatted NTFS, as I discussed in

16

the first article. This explains why NTFS partitions are the sensible choice for a secure site.

However, there is an important difference between the traditional Unix and Novell operating systems and NT. Because of its client/server design, NT end-users will be able to see other processors on the network, including other users’ workstations, It is not likely that all of these workstations will be running NT: they may still have only Windows 95 or 98 (or even Windows 3.11). This means it is not possible to use NTFS formatting to control access to their files. We need additional measures to stop them being open to any network browser.

NT therefore also has a ‘share’ option, which allows users to share (or not share) their drives or directories with other users. The user can decide if this share gives full access rights, or read-only: and it is possible to set a password on the data too. If, say, I am alone in my department in having a CD ROM drive, and I set it up as shared, then other people in my department will be able to install new software from my drive on their own PCs. if my machine runs Windows 3.11, however, there is no way for me to specify which users I want to share with: it’s all or nothing. So anyone around on the network when there is a disk in my drive can access it as well.

As you can imagine, it happens not uncommonly that users set shares on local document directories so everyone in the department can see their work, forgetting that everyone else in the organization can now do so too. In practice, most security- conscious sites try to ban shares in a policy, and encourage users to store key data on networked NTFS drives by backing it up for them.

Your audit work in this area should include finding out what the policy is, and what instructions are given to users about sharing files and directories. You can find out what is happening in practice by browsing a sample of servers and workstations to see that any shares do not jeopardize security. Alternatively, and much easier, there is third-party software available to scan the drives for you. If your site has this, you may be able to run it, or to see the reports from it, rather than having to work through the network devices yourself.

Remember that additional pro- tection is provided by disabling or physically protecting workstation external drives-and this can be done by Registry settings (see the first article for details).

As I’ve said above, files on the server disks can be protected by setting NTFS file permissions. Reviewing them file by file is tedious, to say the least, but you can list the lot using yet another NT utility from the Resource Kit, SHOWACLSEXE. I normally run this to list the file permissions for the entire partition, and then analyse the resulting file with a file interrogation tool like IDEA.

I normally pick a sample of key files to review, including:

configuration files; system files; a sample of application files.

The file c2ntfacl,inf, in the NT Resource kit, is useful here: it tells you what the access control should be to secure a range of system files.

Logging

This file access review Completes our review of the NT settings. However, it’s one thing blocking

0 1999 Elsevier Science Ltd

August 7 999 Network Security

Success Failure

Log on and log off Yes Yes

File and object access No Yes

Use of user rights No Yes

User and group management Yes Yes

Security policy changes Yes Yes

Restart, shutdown and system Yes Yes

Process tracking No No

Table 1. A typical audit polic): designed to keep manageable amounts of information.

the holes: it does not necessarily mean that the mice won’t find a way in.

To complete the audit, it is useful to see if there are any traces of illegal activity, and for this, you need to review the NT log.

NT allows you to record various types of system event, and the records you choose to keep are defined in User manager, Policies. See Table 1 for a typical audit policy, designed to keep man- ageable amounts of information,

If this isn’t your site’s default, you will need to make sure that the options are set on far enough in advance to give you enough information.

I normally try to analyse a month’s data as part of an operating system audit. This normally means compromises between the information I would like, and the information the site is prepared to keep. File and object access, for instance, can display interesting statistics about who uses what data and also, more importantly, an audit trail of changes to Registry settings - but the volume of records means that usually, the site is reluctant to keep the information.

The first check you need to do is that the log contains all the records it should, and has not been corrupted. The checks you need to do are:

0 1999 Elsevier Science Ltd

7. Check the Registry entry CrashOnAuditFail in /-/KEY_ LOCAL_MACHINE \ SYSTEM \ CurfentContfolSet \ Control \ Lsa.

This needs to be set on, because then the system will halt if there is an error writing to the audit logs (for instance, if they have filled the space assigned to them by the system manager). Although this sort of control was standard in mainframe systems, normally it isn’t in the newer network-based systems, but not really for very good reasons -just the fear of making a mistake and inconven- iencing users in a rather public way.

2. Check the options set for the security log to ensure a// events are recorded (Event Viewer, Log settings).

Check that the file size is sufficiently large (the default is only 512 KB - one or two day’s worth at most sites), and that the log wrapping is set to ‘Do not overwrite”. If wrapping is allowed, not only will you lose data, but the system will not generate a 516 (discarded events) entry, and so will not signal the loss,

Once the log is written, you need to review it and, normally, I save the records as a text file and analyse them with file interro- gation software. To copy the file, use Event Viewer and Save As. I then split the records into groups and audit them.

7. System ever-b

These are records numbered

512

513

514

515

516

517

System reboot events

System Shutdown events

Authentication package

initiated

Valid logon process started

Security events discarded

Audit log cleared

Every reboot (512) should be followed by a 514 (starting authentication package). If not, the security checking at logon may be disabled.

There should be no 516 records. There should be no 517 events that are not explicable. Any system shutdown records should be traced to a shutdown of which the administrators are aware,

2. Policy change events

608 User right assigned

609 User right removed

612 Audit log modified

You may want to follow-up any of these with change-control records.

3. Use of privileges

Failures particularly may be

attempts at penetration.

576 Privilege assigned. The

system will record the

assignment of common

privileges, but not their use,

as this generates so many

records.

577 Privileged service called

578 Privileged object operation

4. Login attempts

Successful logins are type 528; logoffs 538. Numbers between the two indicate various types of error. You can review these in detail, with the scope of what

17

Network Security August 7 999

you do limited only by time and your imagination,

One thing I nearly always do with login records is to match them to the full list of users and look for registered users with no login records. This tells me which user IDS are not in use, perhaps because their owners have left or changed jobs or are back- packing around the world. The results are a pointer to the care with which the system is administered.

Findings

Having done your audit, what sort of things are you likely to find? In my experience, although NT is now used to control user

populations at least as large as those of the old mainframes, procedures at the moment still tend to be much more informal. For instance, most mainframe sites charge users according to the facilities they use, and thus log what goes on so they can work the bills out. These log files are a rich source of items of audit interest. Often, departments are just charged for their share of NT by number of desks -so there is no need to keep detailed logs, and no concept of the importance of recording and reviewing key events. Even the idea of a standard password policy may be foreign to some system administrators.

It is interesting to speculate about whether or not this will

change as technicians become more familiar with NT functionality and its management. As we have seen, most of the security features we need are there - the bits missing are generally the clerical procedures to support them. Perhaps in five years time, they’ll be tightened up, or perhaps the cost of tight security will be judged too expensive for the level of risk.

The worst position must be the ignorant one, and this is where many sites new, or relatively new, to NT are now. Perhaps where we can help most as auditors is by auditing such sites now, pointing out clearly what risks there are, and what cost is involved in reducing them.

Barr Offers Congressional Oversight Amendment on ECHELON Wayne Madsen

On 13 May 1999, Georgia Republican Congressman Bob Barr successfully introduced an amendment to the Intelligence Authorization Act that would require the Department of Justice, the National Security Agency (NSA), and the CIA to provide to the Congress oversight information on America’s international eavesdropping of telecommunications. Within 60 days of the amended Bill’s enactment a report must be made to Congress setting forth the legal basis and procedures whereby the intelligence community gathers communications intelligence. The amendment is specifically directed at the international communications surveillance system known as Project ECHELON.

Barr’s amendment resulted from communications spying agency his inability to get any information to “deny proper information for from the NSA on ECHELON, which the House Permanent Select the congressman cited as an Committee on Intelligence attempt by the world’s largest (HPSCI) to conduct meaningful

oversight responsibilities”. Barr said it was abuses by agencies like the NSA and CIA in the 1970s that ori- ginally resulted in the enactment of public laws that established both the House Permanent Select Committee on Intelligence and the Senate Select Committee on Intelligence.

The adoption of Barr’s amendment was only possible with the support of the HPSCl’s chairman, Congressman Porter Goss of Florida, himself a former CIA officer. Goss, who has become known as a virtual rubber stamp chairman for the intelligence community, was apparently irked when he requested from NSA information on surveillance programs like ECHELON. According to Barr, Goss was rebuffed by the General Counsel of NSA. Barr said: ‘in recent communications between the chairman and the NSA, the general counsel of the NSA interposed what, by any stretch of the imagination, is a

18 0 1999 Elsevier Science Ltd