Anonymous AccessAnonymous access does not require a user account or password. Older versions of Windows required anonymous access for many applications and services to run. As these versions of Windows were updated and as new versions of Windows were introduced, fewer operating system services and fewer server applications required anonymous access. The following options for managing anonymous access are available in Windows Server 2003. Security Principals, Authorization, and Anonymous AccessSecurity principals are entities that the security subsystem recognizes and that can be granted rights and permission on the computer. Users, groups, and computers are security principals. Access to computer and network resources is granted directly to user and computer accounts or indirectly via their group membership. Access or authorization can therefore be restricted. User accounts can also be created for use by services, or services may be assigned to use the Local System account, Network, or Local Service account. This enables software that must run in the background to run and be controlled by granting its logon account authorization in the form of rights and permissions. Both user and computer accounts can be explicitly granted membership in Windows groups and can become members of implicit groups based on the actions of the account. Anonymous connections, connections that do not use accounts or passwords, are often authorized access to resources via explicit access granted to the implicit anonymous group or by the inclusion of the implicit anonymous group in some other group, such as the Everyone group. Anonymous access, however, can be abused. Anonymous access might be used to find out information about a system, such as its user list, SIDs, or security policy, to better attack it. Anonymous access also might be used to launch an attack. The anonymous connection has been used in several attacks against Windows computers. Windows Server 2003 provides several Security Options that can be used to configure better control over anonymous connections. Windows Server 2003 also requires fewer anonymous connections to function and is by default more secure against attacks based on anonymous access. One of these restrictions is that the anonymous SID, the identifier granted to a user or process connecting anonymously, is not part of the Everyone group on Windows Server 2003. Therefore, the anonymous connection does not provide as much access as can be gained in earlier versions of Windows. You will need to learn more about anonymous connections to protect systems from attacks that use them. Anonymous Access to ResourcesSome shares are created during installation for the purpose of supporting remote administration. In general, these shares should not be modified or deleted. Shares that you create, however, should be protected from anonymous access. One of the default shares is IPC$, which is required for remote administration when shared resources are viewed. The IPC$ service, by default, provides for anonymous access to support various Windows services. This support makes it possible to connect to the IPC$ share on a Windows computer without providing a user name and password. The IPC$ share is used in the following scenarios: To share named pipes. For remote administration and when viewing shared folders. By some legacy services to enumerate user information. For example, on Windows NT 4, RAS uses this share to determine whether the user has the right to log on remotely. By some downlevel computers to complete password changes; access to this share is required. To configure access to resources in a trusting domain; the administrator needs access to this share. Do Not Attempt to Delete the IPC$You cannot delete the IPC$ share because it is essential in a network environment. Anonymous access to this share may be necessary for certain types of processing. You must understand the dangers of unre stricted anonymous access and use appropriate action to protect your systems from them, but you must be aware that at this time, it is not possible to eliminate all anonymous access. Locally, you know that this is not possible. If you understand how access is gained, you will understand that an anonymous connection must take place before credentials can be exchanged that will authenticate the user. The danger is that unmanaged anonymous access may provide unauthenticated access to a computer's file system, or worse. Anonymous access also bypasses accountability efforts because the user's identity cannot become part of the log. There is no way to tell who has accessed information when an anonymous access is allowed. If an attacker is able to make an anonymous connection, she might be able to obtain information that might be used in an inappropriate or illegal way, such as compromising the system. Anonymous connections to Windows Server 2003 are restricted by default. You can examine and modify these controls. Pre-Windows 2000 Compatible Access Group MembershipThe Pre-Windows 2000 compatible access security group is a local group only present on Windows 2000 and Windows Server 2003 domain controllers. By default, this group has read access to user and group objects in Active Directory. Membership in this group is configured when a Windows 2000 or Windows 2003 server is promoted to domain controller. The installer is asked if all computers in the domain will be at least Windows 2000; if the answer is yes, no user or group is added to the Pre-Windows 2000 compatible access security group. However, if you have pre-Windows 2000 computers from which domain users will need to log on, you should add the anonymous group to the Pre-Windows compatible access security group. Hence, anyone obtaining anonymous access could potentially also browse the user and group objects in Active Directory. If necessary, you can add or remove the anonymous group from the Pre-Windows 2000 compatible access security group. This group is listed in the Active Directory Users and Computers console, and its membership can be modified by opening its properties and adding or removing users and groups from the Member page. The Pre-Windows 2000 compatible access security group also has access to folders, files, and registry keys that are sometimes required by legacy services. Adding the anonymous group to the Pre-Windows 2000 compatible access security group also provides anonymous users access to these resources. If you understand which access is required in your environment, you can restrict access to resources by anonymous users by modifying the ACLs on resources. Well-Known SIDsWell-known SIDs are those SIDs that are the same on every system. The name is often a bit misleading. Some well-known SIDs are actually a local representation of a well-known RID. For example, the RID of the local Administrator account is 500, but each system will have a unique local Administrator account SID because the SID includes some unique information that identifies the computer on which is exits. Well-known SIDS represent common entities and even implicit groups (groups whose membership is defined by the actions a security principal takes versus being explicitly added to the group). Well-known SIDs are important for two reasons. First, because they are well-known, an attacker might be able to use them to discover information about the system, or simply use them in an attack. An example of this might be the use of the well-known local Administrator account SID. While an attack that references the Administrator account by name may fail if the account name has been changed, an attack using the well-known Administrator SID will not. Note, however, that the attacker must discover the unique portion of the SID that identifies the machine before she can compose the local Administrator's SID and use it in an attack. (See the section on anonymous access to see how this might be possible and how to protect against it.) The second important thing about well-known SIDs is that they may be added to the access token of a security principal. If the security principal is, for example, attempting to access a network resource and is able to authenticate, then the well-known SID for the implicit NETWORK group will be added to their access token. If this SID has been used to grant access to system resources, then its inclusion in the access token will provide that access. Table 3-7 lists and defines well-known SIDs for Windows Server 2003.
Anonymous SID and Name TranslationA security identifier (SID) is a character string used to represent Windows accounts and groups. When a new user account or new group is added to the account database, a unique SID is assigned. Those accounts and groups created by the system during installation are assigned SIDs at that time. These SIDS are known as "well-known SIDs" because they are either exactly the same or have the same ending for every installation of Windows. One well-known SID is the Administrator account. To the operating system, it's not the account name that matters, but the SID. In many attacks, an attempt is made to obtain administrative privileges by obtaining the account name and password of an account in the local Administrators group. When an attempt is made to access a resource, the SIDs are compared to Access Control lists that include SIDs and the permissions assigned to them. It's understandably more desirable for an attacker to obtain the username and password for an administrative-level account than for an ordinary user account. Hence, an attacker will attempt to crack the password for the Administrator account. A common security practice is to obscure the local Administrator account by changing its name, thus foiling or at least delaying the attacker who now has to crack all accounts and try them one-by-one. However, because the Administrator account has a well-known SID, an attacker might be able to deduce it if he can gain anonymous access to the computer. He then could write code, or use code written by another, to determine the name of the Administrator account by first listing all SIDs and looking for the one using the well-known RID of the Administrator account. Likewise, if an entire account list cannot be accessed but the name of one account is known, an attacker with anonymous access might be able to construct the SID of the administrator account by translating the known user account to its SID to obtain the machine portion of the SID and then composing the administrator account by adding the well-known Administrator account RID, 500, to the machine portion and then translating this SID to a username. By default, Windows Server 2003 is protected against anonymous SID name translation. The Group Policy security option Network Access: Allow Anonymous SID/Name Translation is set to Disabled and prevents the use of tools that might translate well-known or other SIDs to usernames. Maintain this security setting as Disabled to prevent the use of such tools and thus the exposure of these accounts. If the list of user accounts is known, an attacker can attempt to run password- cracking attacks against the each account. The following Security Options can be used to close holes provided by anonymous access. Network Access: Do Not Allow Anonymous Enumeration of SAM AccountsAfter an anonymous connection has been made, an unprotected Windows computer may allow enumeration of the accounts in the SAM database. To prevent this, this security option should be enabled. (The default is disabled in Windows Server 2003.) If the security option Network Access: Do Not Allow Anonymous Enumeration of SAM Accounts and Shares is Enabled, this setting is ignored. If the list of user accounts is known, an attacker can attempt to run password-cracking attacks against each account. Network Access: Do Not Allow Anonymous Enumeration of SAM Accounts and SharesThis security option is Enabled by default, so it prevents enumeration of SAM accounts and shares via an anonymous connection. If accounts can be enumerated, password-cracking attacks can be launched against them. If shares are known, connection attempts can be launched. Network Access: Let Everyone Permissions Apply to Anonymous UserBy default, the anonymous group (an implicit group that contains all current anonymous connections) is not a member of the Everyone group. Thus, any rights or permissions of resource access that are granted to the Everyone group are not available to anonymous users. This security option is set to Disabled by default. If you enable this setting, you could reverse this security control and reduce security on your Windows Server 2003 system. This should not be done.Chapter 5. Limit Anonymous Access to Named PipesNamed pipes provide a transport for communications between the client and server processes of a software application. This inter-process communication can be written to require authorized and authenticated connection. For example, a security descriptora list of which users and groups can access a resource and what they can do with itcan be applied. However, if the security descriptor grants full control to the LocalSystem account, to administrators, and to the creator owner or read permission to members of the Everyone group, and the anonymous account, it may provide undesirable access, including elevation of privileges if the pipe has privileged access to a database or other resource. You should seek to prevent anonymous connections to named pipes or restrict them. However, this may prevent applications from running or from running correctly. If you must provide anonymous access to named pipes, use the security option Network Access: Named Pipes That Can Be Accessed Anonymously to list those named pipes that can be accessed anonymously. The default entries for this security option are listed in Figure 3-22. If a named pipe is not listed here, and anonymous access is required, the application may be broken. You can add or delete the names of named pipes from this security option. Figure 3-22. Manage named pipes.Before modifying this setting, you should understand how named pipes may be used in the applications used on specific computers. Use this security option to allow or prevent this type of anonymous access. By default, several named pipes are listed as approved for anonymous access. For increased security, you should determine which of these are not used by specific computers and remove those that are not necessary. Removing unnecessary connection paths reduces the attack surface. Every anonymous connection could be used in some sort of attack, either known or as yet to be developed, so if you do not need to use these connections, remove them and reduce the potential for compromise. In many cases, you will find you can remove some of these connection opportunities. The default approved named pipes, their uses, and recommendations about their use can be found in Table 3-8. If you determine that you can remove specific named pipes, be careful in doing so. Use the security option to ensure success. If you must edit the registry, use the following instructions and be sure to leave each con nection name on a separate line. A return should also be entered after the last entry in the list. To edit the registry:
Restrict Anonymous Access to SharesThe security option Network Access: Shares That Can Be Accessed Anonymously lists two shares by default. If they are not used, they should be removed. The shares are listed in Table 3-9. |