Null Sessions
Chapter 5 describes Windows NT accounts, groups, and privileges in detail. At this point, you need to be aware that an ID named SYSTEM exists on every Windows NT computer. This ID, which has almost unlimited privileges on the local computer, has no password—you cannot log on to this account. Privileged processes in Windows NT run, almost without exception, as system.
Some complications arise when a service that runs as system needs to access a remote resource. The destination machine does not recognize, nor give deference to, some other machine's system ID. Because the service runs as system, it does not have a password to present. The service therefore tries to set up an SMB connection with an undefined (null) username, empty password string, and undefined domain name during stage three of the client/server negotiation process described in the preceding section. The connection that results if the negotiation is successful is on behalf of the anonymous user and is therefore called an anonymous session or null session.
Security-Related Considerations with Null Sessions
Null sessions pose a dilemma. Certain null sessions are created on behalf of processes used in establishing trust between domains and also in other contexts. You can use the Server Manager tool to see the sessions established on any given machine. Open Start, Programs, Administrative Tools, Server Manager. A list of servers in the current domain displays. Double-click any of them to see the sessions established to that server11. (Note, however, that null sessions are not limited to share and named-pipe access mechanisms to reach remote resources.) If you click on the Users button, you can determine exactly to whom each session belongs (see Figure 3.8). If you see Anonymous, you can be sure that it indicates that a null session to that computer exists. You can also determine whether null sessions have connected to resources by looking through a system's Audit log for data concerning the user named Anonymous. Although the system and domain do not have a user account for Anonymous, this entry is the one that results from connections opened by null sessions.
){kind=link}
The real danger of null sessions is that they are designed to be used by the SYSTEM ID. Yet at the same time, they are unprivileged sessions that can be initiated by the ever dangerous Everyone group on the remote machine. The network result is a default absence of protection for the remote resources that can be accessed via null sessions. The potential for misuse should by now be readily apparent.
Solutions for Null Sessions
The dilemma in dealing with null sessions is that Windows NT, to some degree, depends on them. You could disable them, but at the cost of possible disruption of certain network services (for example, Windows NT's passthrough authentication used in establishing trusted access between domains).
By default, Windows NT systems at least restrict the way null sessions can be opened. They do not allow null sessions to be opened on any system through any existing share or named-pipe access mechanism. Not changing the default Registry setting that controls null sessions is in general a good move for the sake of security. It may, however, be necessary for the sake of some applications to override this default. In this case, use a Registry editor to reach the following path:
\System\CurrentControlSet\Services\LanmanServer\Parameters
If you want to allow null session access through shares and named pipes, you need only to create a subkey named RestrictNullSessAccess under Parameters and set its value to 0. (Note that the key type must be REG_DWORD.) Once again, making this modification is not advisable for security's sake in most settings, but it may be necessary to allow a select set of applications to work. To that end, you can specify shares that can be accessed by null users, regardless of the value of RestrictNullSessAccess. You can view and edit the names of the individual shares and named pipes through which null sessions can access system resources by examining and editing NullSessionShares and NullSessionPipes under Parameters. Each item that appears indicates a share or named pipe that can be accessed through null (anonymous) sessions. In this manner, you could selectively limit access via null sessions without disabling null sessions completely, thus reducing the potential for disruption. Finally, if you are running Windows NT 4.0 with Service Pack 3 or higher, you can make another Registry change to restrict access by the anonymous user (as described in Chapter 5).