Securing What s Most at Risk: A Checklist


Once you have an effective system in place for promptly installing security fixes (and doing so shouldn t take long), you ll benefit from plugging the biggest potential holes in your network and server configuration. The checklist in this section is intended to bring your machines to a reasonably secure default state that gives you protection against the biggest threats. Depending on the results of your risk assessment (see Chapter 4 and Chapter 5), it might be necessary for you to take additional steps to bolster your network s security.

Step 1: Patch

Getting the right patches onto your machines is critical. Without them, your servers and workstations are vulnerable; with them, they re better protected. (Of course, patches can t compensate for weak policies or lack of auditing.) Here s what you need to do:

  1. Install the most current operating system service pack. Service packs are cumulative collections of security and bug fixes up to a certain point in time. You should always have the most recent service pack installed on your Windows servers. For example, Windows 2000 Server Service Pack 4 contains literally hundreds of fixes to vulnerabilities that were identified after the Windows security push, many of which have no otherwise available hotfixes. (The only exception to this rule: if you re using third-party applications like virus scanners or fax connectors, make sure that they re compatible with the service pack before you install them !) Once you have a solid service pack foundation, you can fill in hotfixes that were released after the service pack code was finalized. Note that this recommendation is not an excuse to slap a service pack on your machines without testing it on a staging or lab server first!

  2. Install the most current application service pack. Whether you re using Exchange or some other application, you ll find that applications have specific service packs, too. Just like the Windows service packs, these application service packs are tested collections of fixes. By not installing them, you re cheating yourself.

  3. Decide how you re going to distribute patches. Whether you do it manually or with the assistance of an automated tool like SUS or SMS, you must have a systematic way to get new patches onto your machines. The road to administrative hell is paved not with good intentions, but with ad hoc patch distribution schemes. A consistent, repeatable process ensures that as new patches are released, you get them installed in a timely way.

  4. Make sure all your servers start from the same baseline. At a minimum, all your servers need to have the same service packs installed. I know of one large Exchange site with 70 Exchange servers that had no less than 42 different software configurations on those servers, making patch management a nightmare.

  5. Patch what needs to be patched, right now! The “b switch for MBSA is your friend because it gives you an immediate report of the baseline patches required to bring machines to the minimum suggested MSRC configuration. If you prefer, you can use the commercial HFNetCheck Pro tool or another third-party scanner ”the key is to find out what patches you re missing so that you can get them in place right away. For the long term , the best way to implement this step is through a scheduled task that uses MBSA ( without the “b switch, because you ll want your ongoing scans to look for all missing patches, not just the baseline ones) to scan your systems for needed patches, combined with an SUS or SMS setup that deploys patches for you.

  6. Go back to step 2. Patch management is a process, not a destination. Once you have your systems to a consistent baseline, you ll find that the baseline is moving upward as new patches are released. Don t slack off on this; the one patch you fail to install might be all that stands between you and an attack that exploits the unpatched flaw. Remember Law #5: Eternal vigilance is the price of security.

Step 2: Set Strong Policies

Once your systems are correctly patched, you should consider the impact that policies have on your overall security. The easiest way for an attacker to break in is to steal legitimate credentials. Accounts with weak, short, or nonexpiring passwords give the attacker a big advantage. (Be sure to tell your users not to use incremental or sequential passwords, like password0, password01, password02, and so on. Those are no harder to crack than ordinary dictionary words.)

start sidebar
The Ultra-Short Guide to Group Policies

The Group Policy engine introduced in Windows 2000 Server is a fascinating beast . It greatly eases the process of defining and distributing settings for all sorts of things, from security-critical items such as account lockout periods to trivial settings such as what desktop background is used as the default. If you don t understand everything about GPOs, don t fret. This sidebar teaches you the four critical things you need to know.

  1. You edit GPOs with the Group Policy editor Microsoft Management Console (MMC) snap-in, Gpedit.msc, or with the Group Policy Management Console (GPMC), which only works on Windows Server 2003. Policy settings are grouped according to the objects they affect. The interesting security settings are either in Computer Configuration Windows Settings Security Settings or User Configuration Windows Settings Security Settings. For our purposes in this book, almost all of what we do is focused on the items in the Computer Configuration tree.

  2. GPOs can be applied to individual machines or to machines in an Active Directory site, domain, or OU. For local machines, you create policy settings by using the Local Computer Policy object. For Active Directory objects, you use the appropriate snap-in (for example, Users And Computers for OU- targeted policies) to open the object s Properties dialog box, where you ll find the Group Policy tab.

  3. There s a complex set of rules that determines what the resultant set of policies (RSoP) is for a particular computer or user. That s because a single security principal might have policies from parent domains, Active Directory sites, and OUs all applied. The local GPO is applied first, followed by policies specified by (in order) the site, the domain, the parent OU, and the OU the object is in. If there are multiple policies, their settings accumulate. When settings conflict, the last one applied takes precedence. On Windows 2000 Server, you can use the Gpresult tool (part of the Windows 2000 Server Resource Kit, and available for download from http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpresult-o.asp ) to identify which GPOs are in effect on a particular machine. However, on Windows Server 2003, you ll find that GPMC has some terrific (and easy-to-read) RSoP reporting capabilities.

  4. Policies aren t applied immediately; you have to wait for them to replicate between domain controllers and from domain controllers to client machines. You can force an update on Windows Server 2003 machines with the gpupdate /force command, or with secedit /refreshpolicy machine_policy /enforce on Windows 2000 servers.

    Once you understand these four basic facts, you ll be well-equipped to set GPOs to apply the policies discussed in the following sections. For more information on how to work with GPOs to their fullest, see the Additional Reading section at the end of the chapter.

end sidebar
 

Setting Auditing Policies

Maintaining a good security audit log is a key part of proper security practice. A solid audit process helps you know when someone s attacking and what they re doing. It can also provide valuable advance warning of break-ins, assuming that you re monitoring the logs to see what s in them. In its various security operations and hardening guides, Microsoft recommends that you enable auditing at a high level in your Active Directory tree, not on lower level constructs like OUs. The precise auditing settings you use might vary somewhat, depending on how you choose to handle analyzing and retaining audit log data. However, there are three basic steps that give you a solid set of basic auditing data (as described in Chapter 3 of the Windows Server 2003 Security Guide and Chapter 6 of the Security Operations Guide for Windows 2000 Server ).

First, set an event log policy on your Exchange servers. The event log policy, available in Computer Configuration Windows Settings Security Settings Event Log Settings for Event Logs, allows you to control the maximum sizes of the event logs and what happens when the security event log fills up. The most important setting here is to disable the Shut Down The Computer When The Security Audit Log Is Full setting. Exchange can generate a large volume of logon and logoff events, so it s possible to fill up the security log and unexpectedly take down your Exchange server. Note that this is a trade-off: if you leave this setting on, an attacker can launch a denial of service (DoS) attack against your machine by filling up the event log. If you turn it off, an attacker can flood the log with bogus events and cover his or her tracks. You ll have to evaluate the relative risks of these two scenarios and decide which lowers your risk the most. You can adjust other settings, such as event log sizes, according to your environment s requirements.

Second, decide which events you re going to log. Windows itself supports logging nine categories of events (described in more detail in Chapter 19, Security Auditing ). Some events are more useful than others. For Exchange servers, the most interesting events are those that tell us when someone tried and failed to access a resource. Accordingly, your audit policy should, at a minimum, log failures for account lockout and logon events. Use the recommendations in Chapter 19 to figure out what other log events you re interested in. You should probably plan on auditing policy change events, system events, and privilege use events as a baseline. Table 6-2 shows some suggested events you should probably log.

Table 6-2: Events You Should Log as Part of Your Auditing Strategy

Event Type

What to Log

Why

Account logon

Failure

Exchange servers generate many of these events as users log on and off. You re interested in failed logon attempts more than successful ones.

Account management

Success, Failure

These events are logged when accounts are created or destroyed , so it s useful to be able to track when account actions occur.

Directory service access

Nothing

These events are generated every time any service or user requests data from Active Directory. The volume of events generated is unmanageably large.

Logon

Failure, Success

These events are generated when services or computers log on with their service accounts. You ll want to know when those attempts fail. If you see success events when there s no corresponding service activity, that s a warning sign.

Object access

Failure

These events are logged any time a principal for whom auditing is enabled requests access to an audited object. You control what gets logged by controlling what you audit, but you ll definitely want to see failed access attempts for audited objects.

Policy change

Failure, Success

Policy change events are logged when someone tries to change a system or group policy, including the settings that control auditing and logging. Watch for these events ”if you see unexplained policy changes, that s a warning flag.

Privilege use

Failure

These events are logged when a user tries to use specific privileges (including Act as part of the operating system and Debug programs ). Any time you see a failed privilege use event, someone is trying to escalate his or her privileges. This is a significant warning.

Process tracking

Nothing

These events reflect when processes are created, paused , stopped , or terminated . They ll fill the event log if you let them.

System events

Failure, Success

System events are logged when the system shuts down (unexpectedly or not).

Finally, put procedures in place to regularly review your event logs. An automated tool like Microsoft EventComb (available as part of the Security Operations Guide for Windows 2000 Server ), Microsoft Operations Manager, or Rippletech s LogCaster can make this much easier. Even without a fancy tool, though, you should regularly be looking for the critical event types described in Chapter 19.

Setting Strong Password and Account Policies

People generally prefer convenience over security, so if you give them a way to bypass security measures, they usually will. (See Appendix A, Law #2: Security only works if the secure way also happens to be the easy way.) Your best defense against this natural human tendency (remember, administrators are people, too) is to apply and enforce policies that require the use of complex passwords, force passwords to expire periodically, and control what happens to accounts with too many failed logon attempts. You set account and password policies in the Account Lockout Policy and Password Policy nodes in the Computer Configuration Windows Settings Security Settings Account Policies object section of a GPO. The default settings for these policies are unnecessarily lax, so you ll want to tighten them up. Be forewarned, however, that if you set overly restrictive password policies, your users will probably just start writing their passwords down, which is not a good idea! Try to find a middle ground between extra-strong passwords and sloppy habits so that those yellow sticky notes with passwords on them disappear from your organization.

Tip  

Although you can apply these policies to individual computers, OUs, or sites, you should always apply them to the entire domain. Applying account or password policies at the OU or site level makes them apply to accounts on the local computer only . See Knowledge Base article 255550 for more details.

start sidebar
Administrator Passwords

I ve been administering computers for a while now, and I think it s fair to say that administrators can be divided into two categories: those who pick long, hard-to-remember passwords and those who don t. The administrator accounts on Windows machines are valuable and powerful, and it s important that they be protected against dictionary and password-guessing attacks. The same is true for service accounts that have access to multiple mailboxes (like, for instance, your backup or antivirus scanners probably use). Here are some suggestions for extra hardening of critical account passwords:

  • Make them 16 characters or more in length. As soon as you create a password longer than 15 characters , Windows warns you ”because in doing so, you are preventing it from storing the easily cracked Lan Manager hash, which means that password can t be used to log on to machines running Microsoft Windows 95, Windows 98, or Windows Me. That s a very small price to pay for an important improvement in password strength.

  • Use Unicode characters or symbols. Remember the old trick of using the Alt key plus keys on the numeric keypad to enter symbols? Try throwing an or a ¢ in your password.

  • Use things you ll remember but that no one else is likely to guess. Shocking nonsense is a good way to choose something you ll remember; a passphrase like vomit* basketball or Exploding#Hairpiece is memorable yet unlikely to be guessed by an attacker.

    The security materials listed in the Additional Reading section at the end of this chapter have a great deal of useful information on password policies, including good explanations of why Lan Manager hashes are evil and how to prevent them from being used on your network.

end sidebar
 
Account Lockout Settings

Lockout policies are mistakenly deployed in many environments. Although it s true that locking out an account with excessive password changes can prevent brute force password attacks, lockout can be used as a DoS mechanism, and it can cause serious inconvenience to legitimate users. As with other security decisions, deciding whether or not to use lockout is a matter of balancing the expected increase in security with the anticipated risk of a DoS attack or service interruption. Because this is a balance, it s hard for me to give you a one- size -fits-all policy for the use of lockout. Microsoft generally recommends increasing password strength instead of immediately applying lockout policies. If you make your domain passwords strong enough, you can be confident that they won t be subject to dictionary attacks (although the hashes could still be brute forced). Some further steps will add to your security without using overly aggressive lockouts:

  • Setting the LockoutDuration value to 0 locks the account out until an administrator can unlock it. This is a big hassle for users, a significant risk for DoS attacks, and a strain on your administrative resources. It might be appropriate for critical high-value accounts, but it s not the best general use.

  • Rename the Administrator account. Even though an attacker who can get network access can look up the account name by looking up the well- known security identifier (SID), renaming the account makes it much harder for a network- borne password-guessing attack to succeed.

  • Add a dummy account named Administrator and give it a strong password ” then disable it. That allows you to monitor attackers attempts to hack your machines without any real risk that they ll gain anything valuable by succeeding.

  • Block the Common Internet File System (CIFS) ports (TCP and UDP 135, 137, 138, 139, and 445) from the Internet. Internet-based DoS attacks that use rapid, repeated logon attempts to lock out domain accounts are becoming increasingly common. There s never a good reason to allow inbound CIFS traffic directly through your firewall, especially now that Microsoft Office Outlook 2003 and Exchange Server 2003 support remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP; described in Chapter 11, Securing Internet Communications, and Chapter 13, Securing Outlook ).

  • Consider restricting the use of SMTP authentication, as described in Chapter 8. A number of spammers are using dictionary-based password grinders to guess passwords through the SMTP AUTH verb, which doesn t leave nearly as many footprints as CIFS-based attacks.

Password Policy Settings

The six settings in the Password Policy group control what happens when users try to change their passwords. The settings are as follows :

  • Enforce Password History controls whether or not Windows remembers previously used passwords (actually, their hashes). Setting this policy keeps users from using one or two passwords (say, their dog s name and their mother-in- law s name) and toggling between them at each password change.

  • Maximum Password Age and Minimum Password Age control when users can and must change passwords. When a password reaches the maximum age, it expires and users must change it before they can log in. After changing the password, a user cannot change it again until the interval specified by the minimum password age has passed. (This prevents users from changing an expired password to a temporary password and then changing right back to the just- expired version.)

  • Minimum Password Length controls how short a password is acceptable. The default, 0 characters, allows blank passwords, which are unadvisable.

  • Password Must Meet Complexity Requirements regulates whether users must choose complex passwords. For our purposes, a complex password is at least six characters long and contains at least one uppercase English letter, at least one lowercase English letter, at least one number, and at least one nonalphanumeric character. Note that this is a low degree of complexity ” l0phtcrack and other hacker tools can power through this level of complexity pretty easily. To be safer, make sure you teach users to use eight- character or longer passwords, and to intermix numbers , letters , punctuation, and special characters (like the infamous Euro symbol). The bigger the range of characters used, the larger the search space.

  • Store Password Using Reversible Encryption For All Users In The Domain controls whether or not Windows stores password hashes that can be reversed . Remember our discussion of hash functions in Chapter 2, Security Protocols and Algorithms ? They re not reversible. Storing reversible passwords is sometimes required for remote-access systems, but Exchange itself doesn t require them, and you shouldn t turn them on if you can avoid it.

Table 6-3 shows the applicable settings, their default values, and the values recommended for acceptable security.

Table 6-3: Recommended Settings for Password Policies

Policy

Default

Microsoft s Recommendation

Enforce Password History

Remember 1 password

Remember 24 passwords

Maximum Password Age

42 days

42 days

Minimum Password Age

0 days

2 days

Minimum Password Length

0 characters

8 characters

Passwords Must Meet Complexity Requirements

Disabled

Enabled

Store Password Using Reversible Encryption For All Users

Disabled

Disabled

The account lockout policy settings govern what happens when a preset number of failed logon attempts occur. You need lockout policies because without them an attacker can repetitively try passwords until he or she finds one that works (or until he or she finds some easier target to attack). The policy encompasses five separate settings:

  • Account Lockout Duration is the period in which failed logon attempts count toward the threshold. For example, let s say you set the duration to 30 minutes. If any account gets more than the threshold number of failed logon attempts during any 30-minute period, the account is locked out.

  • Account Lockout Threshold controls how many failed logon attempts are required to trigger a lockout. The default setting of zero means that accounts will never be locked out. At a minimum, set this policy to allow five failed attempts before locking out the account. A value of three failed attempts is even more secure.

  • Reset Account Lockout After specifies how long a locked-out account remains locked out. During the lockout period, the account cannot be used to log on, even with the correct password, unless an administrator resets the account. By default, no lockout duration is defined. You should set a duration of at least 30 minutes.

  • Passwords Must Meet Complexity Requirements controls whether passwords have to be complex or not. In this case, complex means passwords that are at least six characters long and contain three of four character groups (A “Z, a “z, 0 “9, and punctuation or special symbols). Additionally, complex passwords must not contain any part of the username.

  • Store Passwords Using Reversible Encryption specifies whether passwords should be stored in a way that allows someone who captures the stored data to derive the password. This is required in only two cases: if you re using digest authentication with IIS or if you re using the Challenge Handshake Authentication Protocol (CHAP) with the Internet Authentication Service (IAS). In all other cases, this should be off.

Step 3: Lock Down IIS

The IIS Lockdown tool configures IIS version 4.0, 5.0, and 6.0 for better security than the default installation. Almost everything it does can be done manually, but it s much easier to apply security settings all at once than piecemeal. IIS Lockdown works in concert with the URLscan filter, which screens out URLs that don t match patterns you specify. By properly installing and configuring these tools, you can significantly increase the security of your Exchange servers.

Note  

You should run IIS Lockdown on all your Windows servers, not just your Microsoft Outlook Web Access or IIS servers. Remember, in Windows 2000 Server, IIS is always installed and enabled by default, so be sure to secure all your servers ”even if they re only visible on the intranet. Windows Server 2003 doesn t enable or install IIS by default, so this is not as critical for those machines.

The first step is to download the IIS Lockdown package, available from http://download.microsoft.com/download/iis50/Utility/2.1/NT45XP/EN-US/iislockd.exe . The package is ready to run as is; execute Iislockd.exe and you ll be in business. The wizard is extremely simple to use. Here s how it works:

  1. You ll see a Welcome page, followed by the ubiquitous EULA page. Click I Agree and then click Next to proceed.

  2. The Select Server Template page (see Figure 6-5) lists about a dozen templates you can apply. The original versions of IIS Lockdown required special manual configuration on Exchange servers; version 2.1 (and later) allow you to select the Exchange 2000 Server template to secure the server, without requiring any additional tweaking on your part. Select the appropriate template and click Next.

  3. The Internet Services page allows you to specify which services you want to run: the IIS HTTP, SMTP, FTP, and NNTP servers each have check boxes. The Exchange template automatically turns off the NNTP and FTP servers, leaving you with check boxes available for HTTP and SMTP. Note that NNTP is required for public folder management. It s generally acceptable to shut it off on front-end servers as long as you don t want to manage public folders using the front end. Make sure both check boxes are selected, and then click Next.

  4. The Script Maps page lets you selectively turn off script mapping for specified extensions. By default, IIS Lockdown turns off all the mapped script types except .asp. This causes a problem if you re using the Outlook Web Access Change Password feature (see Chapter 14), which requires a set of .htr files. This feature is turned off by default. If you re allowing Outlook Web Access password changes, make sure the .HTR Scripting (.htr) check box is cleared before you click Next.

    click to expand
    Figure 6-5: Be sure you select the appropriate template, or Exchange will abruptly stop working properly.

  5. On the Additional Security page (see Figure 6-6) you turn off individual IIS directories, such as the notorious IIS Samples and MSADC directories. The only directories you can choose to enable are IISAdmin and Scripts. You can also choose whether you want to restrict file permissions to keep anonymous users from launching system utilities or writing to Web directories. IIS Lockdown sensibly sets these bits for you ”leave them selected to get the best possible protection. The biggest danger on this page for Exchange administrators is in accidentally selecting the Disable Web Distributed Authoring And Versioning (WebDAV) check box. WebDAV is used by a variety of Exchange components (including the public folder management tools), so if you turn it off you ll find that these components don t work very well. Note that Exchange doesn t use the IIS WebDAV implementation (instead, it uses the famous DAVex DLL), but turning on WebDAV blocking will break Exchange just the same.

    click to expand
    Figure 6-6: The Additional Security page. Make sure the Disable Web Distributed Authoring And Versioning (WebDAV) check box is cleared.

  6. The URLScan page prompts you to install the URLScan filter. URLScan is an Internet Server Application Programming Interface (ISAPI) filter extension that filters incoming requests against a set of criteria you specify. For example, it can block any URL request for a verb you don t want to allow (say, POST or HEAD requests). It can also block URLs over a certain length or that contain patterns of data, both of which are commonly found in attempts to exploit IIS vulnerabilities. Note carefully the caveat on this page: Microsoft recommends that you read the URLScan documentation (or Knowledge Base article 309508) to gain a better understanding of what URLScan changes and what effects that might have on your Exchange configuration.

  7. The final wizard page is a summary that tells you what changes IIS Lockdown is going to make. This is your last chance to back out before making the changes.

    Note  

    Don t select the Remove Services check box. If you do, they ll be removed, but when you apply patches the missing services won t be patched. If you ever add the removed services back to the machine, they ll be unpatched.

When you lock down the server, a file called Oblt-log.log is created in the System32\Inetsrv directory. As long as you don t edit or remove this file, if you run IIS Lockdown again, it asks you whether you want to undo the lockdown by using the log file to reverse the changes made. If you ve uninstalled or removed services, reversing the lockdown won t put them back; you ll have to do it manually.




Secure Messaging with Microsoft Exchange Server 2003
Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)
ISBN: 0735619905
EAN: 2147483647
Year: 2004
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net