Looking at NT Security through UNIX Glasses

Arthur Donkers

Although Sys Admin magazine has firm roots in the UNIX world, it is impossible to avoid NT, whether we like it or not. In particular, the topic of integrating NT and UNIX becomes an issue. In this integration, security becomes an important factor. It would be a bad idea to breach your security when adding one or more machines to your current networking environments. To help deal with these issues, this security column is dedicated to NT security. We will look at NT security through the eyes of a UNIX system administrator in an attempt to bridge the gap.

NT Security

As we all know, there is only one main source of NT (although a lot of systems manufacturers package their systems with NT, it all comes from the same root). Unlike with UNIX, there is no myriad of versions and implementations for NT. Therefore, comparing UNIX and NT is a very dangerous and difficult thing - which version and implementation of UNIX do you choose for comparison?

Therefore, I have tried to limit myself to the common denominator of UNIX security. In those cases where NT might have an advantage because of features, I have tried to note specific UNIX versions and implementations that also offer that feature.

The focus of UNIX security (or any other security for that matter) falls into two categories:

Prevention - to take measures in preventing unauthorized access to systems and data

Detection - to detect any illegal activity on a system or network that might lead to unauthorized access

Lately, concern has shifted from unauthorized access to disruption. The number of denial-of-service attacks is rising, and appropriate measures must be taken to prevent or limit damage from such an attack. Note that a denial-of-service attack has no intention of gaining unauthorized access, but tries to disrupt the normal functioning of the system by using excessive resources or crash the machine. In an improperly configured system, this may lead to unauthorized access; in other cases it causes damage by lost production hours, lower levels of service, etc.

To achieve an appropriate level of security, UNIX has a number of built-in means, which are listed below. We will then take a look at NT how similar means are implemented.

User Isolation

On UNIX, each user has (or should have) a unique ID. Furthermore, a user can be a member of one or more groups. If configured properly, each user is isolated from the others by means of the permissions used in the file system. A user has a unique username and password, a home directory, and a startup program that is executed whenever the user logs on to the system.

On most of the modern UNIX implementations, the password information is stored in a different file (the shadow password file) from all the other user information. This is because the password information is only used by the system when the user logs on; all other information should be available to everyone. So to prevent everybody from reading the (encrypted) passwords, they are stored in a separate file (shadow passwords). This file can only be accessed by the system itself (root access). By using the shadow system, you can prevent a normal user from launching a password guessing attack through such programs as Crack.

In a networked UNIX environment you may encounter NIS+ (formerly known as Yellow Pages). With NIS+ the user information is shared on the network, allowing for a centralized management of user information and passwords. A user is authenticated by a central server, and has the same user ID and password all over the network. Using NIS+ can be a security risk.

Using the unique user ID, actions performed on the system can be traced back to a user. This information is stored in a number of system log files. These log files can be read by the system administrator or a dedicated program with sufficient privileges.

On NT, a similar system is available. Users all have a unique name. A user ID is not visible but is used internally by the system. Each user can be (should be) given his or her own home directory where he or she can store files. This directory may be located on the local machine, or on a central server on the network. A user can be a member of one or more groups, and a number of groups are available on the system by default. Groups may be created when needed. Privileges are related to these groups, so a user is added to a group, he or she is automatically rewarded with the associated privileges.

NT uses User Policies. A general profile can be created with the Policy Editor. In this Policy Editor, you can specify the minimum length of a password, its validity period, and a password history (to prevent users from re-using their old passwords). You can also set the number of attempts a user gets for entering a password and what will happen when he or she fails to enter the correct password (account lockout). Finally, you can configure whether a user may connect via the network or modem and when a user may work on the system. This information is stored in the password database and Registry of NT. Both of these are files in a system specific format and can only be read by specifically designed programs. The administrator can edit the Registry using the Registry Editor.

There is a word of warning related to this Registry Editor. Default NT (4) installations allow a user to use the Registry Editor to edit the Registry on another machine, via the network. If you have a large number of administrators (or each user has administrative access to their local workstation), you should protect the Registry on your central servers from this. This can be done by using the Registry Editor to set the following entry:

Hive:
HKEY_LOCAL_MACHINE
Key:
System\CurrentcontrolSet\Control\SecurePipeServers
Name:
\winreg

If you have a network of NT machines, you can use something similar to NIS+. You can use the domain structure of NT. In a domain environment, there is a Primary Domain Controller (PDC) with a number of Backup Domain Controllers (BDC) that are used to authenticate users and distribute privileges. Local workstations are made part of a domain, and all users needing access to that station must be authenticated by the PDC. All authentication information of the PDC is regularly replicated to the BDCs. On your corporate network you can even create a number of different domains, each with its own PDC and BDCs. To allow users from one domain to use data on a server in another domain, you can define trust relationships between different domains. Within such a trust, a user is authenticated by his or her PDC, and given credentials. These credentials can then be used to access data in another domain. Be very careful in defining these trust relationships.

And what Crack does for UNIX, L0phtcrack does for NT. With L0phtcrack, someone can download the user database (including the encrypted passwords) from a domain controller to a local machine. L0pthcrack can also be used, with an appropriate dictionary, to launch a password guessing attack on that file. This attack runs on a local machine and can therefore run virtually invisibly. You might be surprised how many passwords can be guessed in a short period of time (women's names, for example, seem to be very popular passwords, as are car brands).

Each user can also be given a LOGON script that will be executed every time that user logs on. By using this script, you could "mount" shares and things like that. NT also keeps track of all actions a user performs, in a number of different directories.

Filesystem

On a UNIX system, each object in the filesystem has an owner and a group associated with it. For both the owner and group a number of permissions can be set or cleared. If someone who wants to access an object is neither the owner or a member of the group, the "other" permissions of the object are used to control access.

For each set of permissions (owner, group, other) the following settings are available. Their interpretation depends on the type of object.

r You may read the contents of the file or list the contents of a directory

w You may write data to the file, or add/delete files to/from a directory

x You may execute a file as a program, or change your default directory to that particular one.

By setting the correct permissions, you can control who has access to what. On some UNIX implementations, access to an object can also be controlled by Access Control Lists (ACLs). An ACL is connected to an object and is a list of permissions granted to a user who want to access that particular object. So, each time the object is accessed, the ACL is checked. However, this feature is not available on all UNIX implementations.

On NT, a similar accessing scheme is possible. An object in the file system is protected by permissions in much the same way as UNIX. However, NT has more permissions available for setting on an object. Besides the familiar Read, Write, and Execute, NT offers the following permissions:

Delete					Permission to delete file
Change Permissions 			Permission to change permissions
Take Ownership				Permission to become owner of a file

For a directory (called a Folder under NT), there are also permissions to list the contents of a folder, add files to the folder, and such.

Under NT 4, these permissions can be set using the Explorer. By selecting an object and using the right mouse button, you get a menu in which you can select the Properties of an object. In this Properties window, you can display and set the permissions of an object.

Besides setting permissions, you can also set auditing events on an object. Whenever an object is accessed in a certain way, an auditing event is generated in the security log. Such an event is linked to the "use" of one of the permission bits. So, when an object is accessed via the Read permission bit, and the auditing is enabled for Read, each time the object is read, an event is generated in the security log. This is implemented by ACLs that are invisible to the user. An ACL is connected to the object, and every time an ACL rule matches, it generates an event in the security log. Such events should be set on critical system files, especially on the Registry and a number of files in the boot directory (on an Intel-based NT system):

File
Permissions
\Boot.ini, \Ntdetect.com, \Ntldr
Administrators: Full Control
SYSTEM: Full Control
\Autoexec.bat, \Config.sys
Everybody: Read
Administrators: Full Control
SYSTEM: Full Control
\TEMP directory
Administrators: Full Control
SYSTEM: Full Control
CREATOR OWNER: Full Control
Everyone: Special Directory Access -
Read, Write and Execute, Special File
Access - None

This table shows the permissions on these files. Auditing events should be generated for all other accesses, so you can keep track of who is accessing these files in which way. Protecting the Registry is obvious. The proper functioning of your NT machine totally depends on the Registry being consistent and complete. So, you should set an audit event on illegal or unwanted access to the Registry.

You can also enable events on users who are logging on and off. This is a good thing, because you can keep track of who was on your system and when. These permissions are granted to a group, of which a user is a member. So by combining the permissions with groups on an object you can control who has what access to an object.

For folders, you also have the ability to define a sharing mode. On an NT machine you can offer a directory, and all files and directories below it, on the network. In this offering, you can specify whether the access is Read Only or Full Access. In the first case, users on the network can only read data from that shared directory. In the second case, they can also write and create files. Sharing a directory on the network should be done with great care. By offering the wrong directory, or a directory with the wrong permissions, you might give away control of your system.

Network

In most cases, a UNIX machine is not an isolated system. It is connected to a local network, or even worse (from a security point of view) to the Internet. So, once you have secured the system itself, you must secure its network connection.

One of the most important things to control on a networked UNIX system is the access of the superuser (root) via the network. Do you or do you not allow root to access your UNIX machine directly over the network. From a convenience point of view you might say yes. From a security point of view, you should definitely say no. Do NOT allow root direct telnet or rlogin/rexec access to your UNIX machine. So, by editing your /etc/securetty file, or by using SMIT to disallow network access, you can make sure root cannot telnet to your system. If you still need direct root access, you might consider using SSH (Secure Shell). This offers roughly the same features as rlogin/rexec, but uses encryption for the traffic and an authentication scheme based on a Public Key algorithm. If you configure it properly, you can make a secure and reliable connection from one system to another as the root user.

For NT, you can also control whether the NT superuser (called the Administrator) can access the machine via the network. Again, you should disable this access. The real Administrator account cannot be locked out when you supply a bad password, so a potential hacker can keep trying passwords to gain access. Furthermore, if that same hacker has managed to crack your Administrator password via L0phtcrack, he or she could gain access via the network. So, disable the network access for Administrator. You could also rename the real Administrator account to a name you can remember, but is difficult to guess. You then create a fake Administrator account without any privileges. And by enabling logon events and filtering for the fake Administrator, you can take immediate action whenever someone tries to log on as Administrator (either via the network or directly from the console).

You should also disable all unnecessary network services. On a UNIX system, this is relatively easy - most network services are handled by the inetd super daemon. This daemon is configured via the /etc/inetd.conf file. By commenting out (or deleting) all unnecessary services, and restarting inetd, you effectively disable all of these services.

On an NT machine, this is not so easy. Most services are part of an application, so you must go through those applications. You can disable most of them via the Network object in the Control Panel. Furthermore, you need to disable (uninstall) IIS if you are not using it.

Conclusion

Although most marketroids would have us believe that NT is completely different from UNIX, in real life these differences are not as big. Both have disadvantages and advantages. Under UNIX, you have complete control by means of the different config files you can edit by hand. Under NT, these configurations are all done through a convenient graphical user interface. Although you might wonder what happens beneath that exterior once you press a button.

About the Author

Arthur Donkers graduated from the Delft University of Technology with a degree in Electrical Engineering and a major in Computer Architecture. Since then he has worked for a number of major software houses in the Netherlands. His primary field of interest is in datacommunications, especially the security aspects involved. He now is the founder and owner of Le Reseau, a company specializing in security-related issues for UNIX, OpenVMS and Windows NT, and the application of Linux in corporate environments.