Tài liệu Protecting SAM and Security Hives phần 2 pptx

Table 9.3: Recommended Settings for the Account Lockout Policy
Setting Description Recommended
setting
Account
lockout
duration
The number of minutes a locked-out account will stay
locked out. If this is set to 0, the account will have to be
unlocked by an administrator or someone who has been
given the right to do so.
30 minutes
Account
lockout
threshold
The number of incorrect attempts at guessing a password
that can be made before the account is locked out.
5 invalid logons
Reset
account
lockout
counter after
The number of minutes after which the count of invalid
logon attempts will be reset. If the number of minutes
between one invalid logon and another is greater than the
number of minutes to which this setting is configured, the
previous invalid logon attempts won't matter.
10 minutes


N

ote A good password policy is essential to network security, but, unfortunately, it is
often overlooked. Here are several tips about the worst practices that you should
avoid under all circumstances:
• Do not create local Administrator accounts (or common domain-level
administrator accounts) using a variation of the company name, computer
name, advertising tag lines or dictionary words, such as
%companyname%#1, win2k%companyname%, etc.
• Do not create new user accounts with simple passwords that aren't required
to change the password after the first logon.
Be aware that none of the above-described settings can force your end users to
create strong passwords. Similarly, even the strongest password policy can prevent
users from writing down their passwords and attaching a note to their monitors,
sharing passwords with other users, or complaining to management when they have
to get help to reset a password they have forgotten.
Protecting the Local Administrator Account
When your Windows NT-based system is joined to a domain, the local Administrator
account is still present (as was already mentioned, it resides in
(%SystemRoot%\System32\Config\SAM). Actually, members of the Domain Admins
group can administer the local system only because this group is added to the local
Administrators group. Hence, it is necessary to protect the local Administrator's account
from unauthorized use or misuse. This goal could be achieved by taking the following
protective steps:
 As aforementioned, physical security is essential. Although this recommendation
might seem elementary, you must not overlook such obvious things. As statistics
have shown, most security incidents in corporate environments occur from the
inside. Therefore, it is necessary to physically secure all servers (they should be
placed in a physically secure room with monitored access) and critical
workstations (consider locking the cases or using removable hard drives that are
locked up at night). On physically unsecured systems, disable the ability to boot
from a CD or floppy. Also, for extra security, disable AutoRun functionality for

CD-ROM drives on physically insecure systems. Finally, when considering
physical security, do not forget about securing your backup media.
 Use NTFS on all partitions. For Windows 2000, Windows XP, and Windows
Server 2003, enable EFS (Encrypting File System)—a built-in powerful
encryption system, which adds an extra layer of security to drives, folders, or files.
Be sure to enable encryption on folders, not just files. All files that are placed in
that folder will be encrypted. In particular, it is recommended that the user encrypt
the TEMP folder, which is used by applications to temporarily store copies of files
being modified (notice that applications do not always clean that folder after
closing the files).
 Restrict the number of unnecessary user accounts, such as any duplicate user
accounts, accounts created for testing purposes, shared accounts, etc. Most generic
accounts have weak passwords and provide lots of unnecessary access rights. In
Windows NT 4.0, disable the Guest account. Although Windows 2000 and its
successors disable the Guest account by default, it is still recommended that you
make sure that someone has not enabled it. For additional security, assign a
complex password to the account anyway, and restrict its logon hours.
 Restrict the addition of local accounts to the local Administrators group, and
require a strong password for the local Administrator account. Rename the
Administrator account. Although this won't stop qualified intruders (they will use
the SID to find out what is the name of the Administrator account), it will still
result in a time delay. When renaming the local Administrator account, try to
avoid using the word "Admin" in its name. Also, consider creating a dummy
account named "Administrator", having a long, rather complex password and no
privileges. Enable auditing on this account to get information when someone is
tampering with it.
 Shut down and disable unnecessary services, since they take up system resources
and can open holes into your operating system. IIS, RAS, and Terminal Services
have security and configuration issues of their own, and should be implemented
carefully if required. You should be aware of all the services that run on your

servers and audit them periodically. Also, on Windows 2000 systems, it is
recommended that you remove OS/2 and POSIX subsystems if you do not use
them (and, in fact, they are used quite rarely). Removing these subsystems will
improve performance and reduce potential security risks. To remove the OS/2 and
POSIX subsystems, delete the \%SystemRoot%\system32\os2 directory and all of
its subdirectories, then use the Registry Editor to remove the following registry
entries: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OS/2 Subsystem for
NT key with all its subkeys, the Os2LibPath entry under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Environment, the Optional entry and all entries for OS2 and POSIX
under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\SubSystems. The changes take effect the next time the computer is
started. You might want to update the emergency repair disk to reflect these
changes.
 Disable DirectDraw. Here one should notice that disabling DirectDraw will impact
the programs that actually require it (mainly, these are modern games), but it will
not influence most business applications. Furthermore, this will prevent direct
access to video hardware and memory, which is required by the basic C2 security.
To do this, go to the
HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\DCI registry key
and set the Timeout value (REG_DWORD data type) to 0.
 Disable the default hidden shares. Windows NT-based systems create hidden
shares that are used by the SYSTEM account (also hidden). All Windows NT-
based operating systems open hidden shares on each installation for use by the
system account. However, you can view all shared folders on your computer by
typing the net share command from a command prompt. There are two methods of
disabling the default shares—first, you can stop or disable the Server service,
which removes the ability to share folders on your computer. To use the second
approach, edit the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServ

er\Parameters registry key. For server platforms, create the AutoShareServer value
(REG_DWORD) and set it to 0. For workstations, create the REG_DWORD value
named AutoShareWks and set it to 0. Keep in mind, however, that this security
measure might cause problems with applications.
 Restrict anonymous access to the computer. Anonymous users or services that log
on anonymously are automatically added to the Anonymous Logon built-in
security group (S-1-5-7). In earlier versions of Windows NT, such users or
services were able to access many resources (sometimes in cases where access
should have only been granted to authenticated users). Starting with Windows
2000, Microsoft introduced stricter security settings which prevent anonymous
access to all resources, except for those who have been explicitly assigned access.
You can do this by using the Local Security Policy MMC snap-in or by editing the
registry directly. To achieve this purpose using Local Security Policy, one had to
select the Additional restrictions for anonymous connections option under
Security Settings | Local Policies | Security Options, and then setting the No
access without explicit anonymous permissions option. To do the same thing by
editing the registry directly, it was necessary to create the REG_DWORD value
named RestrictAnonymous under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA registry
key and set this value to 0x2 (Hex).
In addition to these standard protective measures, Windows XP and Windows Server
2003 include a set of powerful new security features, which will be briefly considered in
the following few sections.
Windows XP and Windows Server 2003 Enhancements and Compatibility Issues
Windows XP and Windows Server 2003 have gone even further than Windows 2000 in
tightening the security system, and introduced a range of additional protective steps.
However, it is necessary to mention that if you decide to use them, this might cause some
administrative inconvenience, especially in mixed environments. Therefore, you must test
them carefully before deploying them.
Restricting Anonymous Access

In contrast to previous versions of Windows, the access token for anonymous users no
longer includes the Everyone security group. Therefore, the access token for anonymous
users contains SIDs for:
 Anonymous Logon
 The logon type (usually Network)
When an anonymous user tries to access a resource on a computer that is running
Windows XP, he or she is not granted permissions or group memberships that are
available to the Everyone security group. The SID for the Everyone security group is
present in the anonymous user's access token. It should be noted that in most cases this
restriction is desirable and appropriate. However, in some situations, for the sake of
backward compatibility, you may need to include the Anonymous Logon security group
into the Everyone group. For this very purpose, Windows XP and Windows Server 2003
have introduced a new registry value, EveryoneIncludesAnonymous, which can be set
using the methods described below.
To enable anonymous access via MMC, proceed as follows:
1. Start the Local Security Policy MMC snap-in, expand the Security Settings tree,
then select Local Policies | Security Options.
2. Double-click Network access: Let Everyone permissions apply to anonymous
users. By default, this policy setting is disabled (Fig. 9.22
).

Figure 9.22: Setting EveryoneIncludesAnonymous registry value via Local
Security Policy
3. To enable anonymous users to be members of the Everyone security group, click
Enabled. To prevent the inclusion of the Everyone security group SID in the
anonymous user's access token (the Windows XP and Windows Server 2003
default), click Disabled.
To set the EveryoneIncludesAnonymous registry value by using Registry Editor, proceed
as follows:
1. Start Regedit.exe and locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
2. Right-click EveryoneIncludesAnonymous, and then click Modify.
3. To enable anonymous users to be members of the Everyone security group, in the
Value data box, type 1. To prevent the inclusion of the Everyone security group
SID in the anonymous user's access token, type 0.
4. Quit Registry Editor.
Disabling the Administrator Account
This security option is only available in Windows XP and Windows Server 2003 and lets
you disable the local Administrator account. To do so, simply right-click the local
Administrator account, and select the Disable account command from the context menu.
In contrast to previous Windows NT-based systems, where local Administrator accounts
could not be disabled, Windows XP and Windows Server 2003 will allow you to do this
(Fig. 9.23
). This option is rather useful, since it eliminates the possibility of misusing the
Administrator password.

Figure 9.23: Disabling the local Administrator account

N
ote Because members of the Domain Admins group have administrative authority on
computers joined in their domain, you still maintain the ability to administer the
system. Also, the Administrator account will remain enabled when booting in safe
mode.
Selecting this feature, however, can have some interesting side effects. For example, if
you change the password policy after disabling the Administrator account, and this
account no longer meets the policy requirements, your attempt at reenabling it will fail. In
this case, another administrator must log on and reset the Administrator account
password. If there are no other administrative accounts, you will have to reboot to the
safe mode to fix the problem.
Limiting Local Account Use of Blank Passwords to Console-Logon Only

Admittedly, the password policy should prevent the use of blank passwords entirely.
However, you should recall that someone who has the password to the local
Administrator's account (or other account with membership in the local Administrators
group) could modify the local account and password policy to permit blank passwords
and modify an account in order to use it. When the use of blank passwords is limited to
console logon only (an option for only Windows XP and Windows Server 2003 systems),
an account with a blank password cannot be used for network logon. The user must work
on the Windows XP or Windows Server 2003 system in which the account exists. You
have effectively prevented an intruder from using the local Administrator account (or any
other privileged account) to access files, folders, registry keys, and so on, on this
machine. This configuration also prevents applications such as FTP, Telnet, and terminal
services from using an account with a blank password. However, Microsoft advises that
applications requiring remote access be written to bypass this setting.
Security Through Obscurity
Of course, security through obscurity will not work, if obscurity is your only line of
defense. However, making things more difficult for attackers is a useful practice,
especially when it comes to protecting the local Administrator account. The option
allowing one to rename this account existed already in Windows 2000, and remains a part
of Windows XP and Windows Server 2003. However, as was mentioned earlier, it won't
stop a qualified intruder, since the task of determining which of the accounts is the local
Administrator's account would not be too difficult. Being well aware of this weak point,
Microsoft has introduced several new protective measures, intended to make this harder.
They can be enforced via Group Policy (under Local Policy | Security Options). The list
of these new policies includes:
 Network access: Allow Anonymous SID and Name Translation. When this
setting is enabled, the system will answer anonymous requests for the name of the
account associated with SID belonging to the local Administrator account. Since
the local Administrator account is associated with the well-known SID, the task of
determining the new name of this account becomes trivial. If you disable this
setting, such an anonymous request will be denied. It is recommended that the user

enable this setting for all domain-level accounts via the Default Domain Group
Policy MMC snap-in. Local account settings can be different and may be set by
changing this security option within a group policy linked to the specific
organizational unit within which the machine account resides.
 Network access: Do Not Allow Anonymous Enumeration of SAM Accounts.
This Windows XP and Windows Server 2003 security option prevents anonymous
access to a listing of Security Accounts Manager (SAM) accounts.

N
ote This option is useful in obscuring information about the domain, especially if
your organization uses naming conventions for user accounts. If the attacker
knows that your organization uses naming conventions, he or she can deduce the
rules used in these conventions, and thus easily guess the correct account name
for some employees. On the other hand, it has implications for trusts, because
some functions require the ability to anonymously list accounts. For example,
the administrator of a trusting domain must be an authenticated user of a trusted
domain in order to perform administrative tasks such as accessing the list of
accounts of the trusted domain when assigning access to resources to trusted
domain users. Actually, when performing such tasks, Windows Server 2003
prompts for and account and password for the trusted domain.