Designing and Planning Windows NT External Security

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Tom Dodds, Eric Miyadi, and Tom Fuchs, Microsoft Consulting Services, Southern California

On This Page

AT A GLANCE
Corporate Security Position
Creating a Security Policy
Creating a Security Policy Document
Securing the External DMZ—Firewall and Router Security
Securing a Windows NT Internet Information Server
Validation Options
How Some Sample Accounts Use Their DMZ
More Information

AT A GLANCE

Key Point: A security policy should ensure the reliability, availability, and supportability of all systems and data on a Windows NT external network—the part of the network that is unsecured or exposed to the Internet.

Detail: High Task: Planning, Deploying

Article Section	What's There
Corporate Security Position	What proper security policies, procedures, and technologies are needed to protect your organization from inadvertent or intentional damage or loss of data.
Creating a Security Policy	Outlines a general security policy that applies to access, management, and hosting within the network environment.
Creating a Security Policy Document	How to establish standards in a thorough security policy, using an example based on an MCS engagement.
Securing the External DMZ—Firewall and Router Security	Discusses how to secure your DMZ—the area in which your servers are typically placed to provide the best security.
Securing a Windows NT Internet Information Server	Provides guidelines for creating a hacker-resistant Windows NT Web server environment.
Testing and Evaluating the Current Security Level	Outlines a series of possible solutions to handle archiving and retrieval of changes that occur when new Web sites and applications are installed on Web servers.
Validation Options	Describes three ways that MCS client accounts have provided secure access to their users: Basic security and Secure Sockets Layer (SSL), Windows NT challenge-response, and a Lightweight Directory Access Protocol (LDAP)-based directory architecture.
How Some Sample Accounts Use Their DMZ	Examines how different companies choose to implement security based on their core business requirements.
More Information	List of relevant Knowledge Base articles.

Security must be a serious component of any design discussion, a need that this article addresses by outlining the tasks required to create a security policy that ensures the reliability, availability, and supportability of all systems and data on a Windows NT external network—the part of the network that is unsecured or exposed to the Internet. It is a big topic because developing security is a big job. Like all big jobs, it begins with a single task: creating a general security policy document for the outside network.

WARNING: This article makes recommendations for tuning the Windows NT registry using the Registry Editor. Using the Registry Editor incorrectly can cause serious, system-wide problems that require you to reinstall Windows NT. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

Corporate Security Position

Maintaining a secure site is crucial. You must put the proper security policies, procedures, and technologies in place to protect your organization from inadvertent or intentional damage or loss of data.

Perhaps your enterprise is not attractive to hackers and other intruders and thus does not require much in the way of security. This may or may not be true: a recent survey of over 560 companies by the Computer Security Institute (CSI) and the FBI International Computer Crime Squad in San Francisco showed that 75% of the respondents reported financial losses due to security breaches ranging from financial fraud, theft of proprietary information, and sabotage on the high end to computer viruses and laptop theft on the low end. Total estimated losses: $100,119,555. The probability of mischief is high enough that no one can afford to feel immune.

What are you Trying to Secure?

First, you need to know what you are trying to protect. For example, a firewall consists of a number of components and systems between two networks and it is generally implemented to limit access to information from users inside and outside the enterprise. Fair enough, but before this means anything practical to your planners, you need to define information. Which information should be limited to internal users? Is there information outside your organization that shouldn't be accessed by users inside? Is there information that is used by one group but not required by others? Should all information be limited based on need to know? You have to define security policies for your enterprise. Only then can you develop the proper testing and auditing facilities that can keep your network secure.

What Level?

The two extremes of enterprise security:

• Information that is not allowed should not be accessed. This leaves it to the Information Technology (IT) group to determine who gets to access what information. This is a restrictive arrangement, but a controllable one—so "tight" that it usually discovers security holes or issues with products that require additional effort.

• Information that is not disallowed can be accessed. This leaves users primarily responsible for what information they access or are allowed to access. Users prefer this arrangement, but it can be troublesome from a security standpoint—it makes it almost impossible to control data security.

In reality, your company will probably have to adopt a security policy that straddles these extremes—a policy that controls yet promotes data access so that users can get to the information they need.

Assigning permissions is not as simple as it should be. You need a thorough understanding of how your company operates (how it really operates, not just how it is supposed to operate) before you can decide which group or individual needs access to which data. This is complicated when the corporate net is connected to the Internet: should everyone have Internet access, or should it be restricted to those who need the Internet to perform their jobs? Notice that this effort does not actually restrict access: it is simply trying to find out in what ways access should be restricted. Establishing permissions is another task entirely.

Internet-based services such as e-mail bring security risks (for one thing, they facilitate the misuse of information from inside and outside your company) along with inherit design weaknesses if you do not plan and implement them correctly.

Creating a Security Policy

In today's distributed, client-server environment, corporate data is stored on server platforms, where it is expected to be at once available and secure. The degree to which these mutually antagonistic goals are achieved is often a measure of the success and viability of your enterprise. This section outlines a general security policy that applies to access, management, and hosting within the network environment. A policy has to address areas of security such as:

• Physical and location security

• Creating a security policy document

• Reacting to a security exposure

The security policy includes guidelines and standards that try to eliminate the common kinds of attacks that threaten most companies. The emphasis is on try. The policy attempts to derive and define a workable solution that provides an acceptable level of security. A thorough policy specifies:

• What is acceptable Web conduct and what isn't

• Who has access to the site and who authorizes the access

• Who is responsible for security upgrades, backups, and maintenance

• What kinds of material is allowed on Web server pages

• What needs to be protected on the site and from whom

• How software and pages are tested and evaluated before being installed in production

• How complaints and requests about the server and page content will be handled

• How security incidents will be responded to

• Who is authorized to speak for the organization to members of the press, law enforcement, and other entities in the event of questions or an incident

• Who is contacted in case of an emergency

Physical Security

Physical security means the steps taken to protect the actual machines used to store and process sensitive and/or valuable data. Protecting against accidental or deliberate access (including changes to the way the computer is set up) should not prevent users from doing their work nor should it erect unrealistic or inconvenient barriers to user resources.

Standard Security

For standard security, the computer system must be protected, as any valuable equipment would be. Generally, this involves housing the computer in a building that is locked and out-of-bounds to unauthorized users.

Backups

Regular backups protect data from all sorts of hazards: hardware failures, honest mistakes, viruses, and malicious mischief. The Windows NT Backup utility is described in Chapter 6, "Backing Up and Restoring Network Files" in Microsoft Windows NT Server Concepts and Planning There are also third-party backup solutions.

Because files must be read to be backed up, and written to be restored, backup privileges should be limited to administrators and backup operators—people who can be trusted with read and write access to all files.

Auditing

Often you don't know about a breach of security until you find it, usually by auditing the network. Effective auditing can also uncover actions that pose a security risk and identify the user accounts from which the actions were taken. Establishing an audit policy requires that you balance the auditing cost (in disk space and CPU cycles) against its advantages. System setup and capacity may dictate how many functions you can audit realistically. At the very least you should audit failed log on attempts, attempts to access sensitive data, and changes to security settings.

High-Level Security

Depending on the level of security required, you can implement additional security measures to create a high-security environment. First you need to identify which computers, if any, contain sensitive data at high risk for theft or intentional violation and disruption. Security for these machines, or their subnet, can be augmented with more stringent security features than those used for the rest of network. You can begin by examining the network's physical links.

Network Level Security

When you put a computer on a network, you add an access route to the computer that should be secured against some level of intrusion—from casual to intentional. User validation and protections on files and other objects are sufficient for standard-level security, but high-level security demands that you secure the physical network.

The main risk is unauthorized network taps. If your network is set up completely within a secure building (a rarity) the risk of unauthorized taps is minimized or eliminated. If the network is not completely within direct physical control, you have to decide on a level of realistic protection and institute it, beginning with physical security. If, for instance, cabling passes through unsecured areas, consider using optical fiber links rather than twisted pair—it is much harder to tap a fiber and siphon off data.

A second, and more common, risk these days is Internet access. The security issue here cuts both ways because this sort of connection provides access to and from the Internet community. In essence, this means that just about everyone in the world with access to a computer has a shot at your system. To get in, however, they have to come through the outside network, and a later section in this article explains how to secure this network and lock down its configuration.

Controlling Access

No computer is ever completely secure if people other than the authorized user can sit down and tinker with it. If you cannot physically secure a computer, try to:

• Disable the floppy-based boot if the computer hardware provides the option. If the computer doesn't require a floppy disk drive, remove it.

• Lock the CPU case with a key that is stored away from the computer.

• Use the Windows NT file system (NTFS) on the entire hard disk.

• Remove the network card if the computer does not need network access.

If possible or practical, keep unauthorized users away from computer power and reset switches. The most secure computers (other than those in locked and guarded rooms) give users access to only the keyboard, monitor, mouse, and printer. You can lock up the CPU and removable media drives and allow only authorized personnel to have access to them.

By default, Windows NT allows any program to access files on floppy disks and CDs. A highly secure, multi-user environment allows only the person interactively logged on to access those devices, so interactive users can write sensitive information to these drives confident that no other user or program can see or modify it.

This mode allocates system floppy disks or CDs to a user as part of the interactive log-on process, then frees them automatically for general use or reallocation when that user logs off. Make it a standard practice to remove sensitive data from the floppy or CD-ROM drives before logging off.

Server Types

Here are some examples of real world solutions implemented by Microsoft Consulting Services:

• Centralized, corporate server farm (most complex)

• Centralized departmental server

• Small office server (least complex)

Physical security requirements differ for each case. The centralized, corporate server farm needs the highest level of security because it handles large amounts of strategic business data. If intruders were to destroy, alter, copy, or kidnap this data, the business would suffer financially and probably be subjected to legal action by its clients and investors. In sum, this network requires very high security. All systems need some kind of security, but most do not need this much.

The discussion begins with the most complex environment and then works back to the simpler ones.

Centralized, Corporate Server Farm

Once upon a time, all processing occurred on a central processor configured with "dumb" remote terminals. This seems primitive by current standards but it certainly was easy to secure. Now, distributed computing environments require security from the end-user desktop, through the departmental server, to the central servers.

Recently, network designers have begun consolidating departmental servers that previously were scattered around the enterprise. Consolidation allows designers to use common hardware platforms, combine workloads, and tighten security for servers and data. The growing demand for high performance, data-rich corporate Web sites has also fuelled the need for Web server farms that connect to the Internet. In addition to the standard security precautions required for Internet connectivity, these systems also need to be centralized and physically secured.

In one case handled by MCS, the location for the Web server farm started out as the telephone patch bay. This tiny room was renamed the "server room," but a new name was not enough to provide the expandability, proper security or ventilation required over time by a Webfarm. The company ended up relocating the farm to an appropriate environment—a costly correction. If you are going to create a "server" room, evaluate your plan by the suggestions and criteria below. Some seem to be general, not security, concerns, but all of them affect the security of the proposed site:

• Build or renovate the room to house the current equipment and provide enough extra space to expand the installation to at least double initial capacity. Make sure it has enough room to maintain, install, relocate, and remove equipment easily.

• Locate the room in the center of the building, or at least in a location that does not use an exterior wall.

• Locate the room in the basement or on one of the upper floors of the building, but not in places that inhibit delivery and removal of equipment.

• Locate the room close to the building cabling ducts that will carry the networking cables to other parts of the building. Ensure that this core "backbone" facility is also secured and that all access points are monitored by the security control room.

• Provide a large enough room to allow the air-conditioning plant to operate effectively.

• Provide a professional air-conditioning system, capable of maintaining a temperature of between 18 and 20 degrees Celsius and sized to cope with a fully loaded room.

• Provide a false floor to accommodate the cabling for the systems and deep enough to allow easy access and reconfiguration.

• Provide solid walls all around. If there is a false ceiling, then extend the walls above the false ceiling to prevent entry from above.

• Provide a secure, fireproof doorway, wide enough to allow easy delivery and removal of the largest piece of equipment.

• Install a sophisticated alarm system with sensors on all doors and at all access points including the ceiling and the false floor. Include smoke detectors and water detectors as well as movement sensors.

• Plan for a nearby security monitoring room. This room needs to be staffed 24x7 and must monitor all access points and all environmental checkpoints relating to the system.

• Employ a professionally trained and experienced security officer and team. If you use a third-party company to handle security, ensure that its personnel pass through the security clearance checks and that they also sign non-disclosure agreements (NDAs).

• Limit access to the computer room to people who require access, then run security checks on them—in-house staff as well as support and maintenance staff—and have them sign NDAs.

• Install an access control system that monitors and logs all access to the computer room. Establish a manual backup system to ensure that access is controlled and monitored during periods when the access system is bypassed for maintenance, machine installation, etc.

• Establish a system that records all details relating to the regular removal and delivery of backup media and equipment.

• Ensure that any communication cabling that exits the computer room is secure. If cabling needs to pass through an unsecured area, use fiber optic cable if possible.

• Install an emergency power supply. This may range from a simple uninterruptible power supply (UPS) unit to a full electrical generator. Ensure that this power system is also installed in a secure, controlled environment that is monitored by the security control room.

• If the air conditioning system requires water, provide two independent water connections.

• Ensure that the air conditioning cooling towers are secured and monitored by the security control room.

• Provide a fire-proof safe to store on-site backup media and other essential documentation and equipment. This can be a separate fireproof room leading into the computer room via a safe door. Install monitors and fire and water sensors in this room as well.

• If possible, construct a "dark site" similar to the production computer room but located some distance from it. You can use this to house a fully configured backup system, or to install a replacement system in the event of a disaster. An alternative to this is to make use of a third-party DRP service. In either case, provide duplicate communication links to the backup site.

• Implement a regular audit process that tests all monitor points, access points and environmental checkpoints as well as testing the manual procedures.

• Run regular disaster response exercises to test the validity of the backup media and documentation as well as to minimize time-to-restore.

• Implement a fully functional change control system.

Centralized Departmental Servers

Smaller systems are usually developed by smaller companies that cannot afford all of the measures above. Nor do they need all of them. The basic needs are to control and monitor server access, and to provide servers with a dedicated, secure location, air conditioning, and an uninterruptible power supply.

In you use a smaller departmental Web server to provide additional services such as application processing or data storage, you need to take more stringent security measures. These sorts of server rooms can be considered scaled-down versions of the central server farm computer room described above and you should consult the master list for ideas on protecting the environment, screening personnel, and limiting access and vulnerability.

Small Office Servers

Smaller office servers connected to the Internet provide Web services but they also expose the system to security dangers inherent in Web access. These require many of the same security measures as described for the centralized server farm, although size, budget, and need may make a complete security setup an unrealistic goal.

Install these smaller Web servers in a secure, monitored environment similar to that described for the centralized server farm, then scale the overall mechanisms and methods down appropriately. Instead of monitoring the site with a dedicated security team, use an office supervisor, Internet service provider, or power user. Secure all communication links and routes.

Establish procedures to ensure that backup media are stored safely (on- and off-site), that all movement of media and equipment is monitored and recorded, that backup procedures and media are tested regularly, and that a disaster recovery plan is tested and in place. If necessary, hire a local support company or hardware vendor to ensure that replacement equipment is available in the event of a disaster.

Creating a Security Policy Document

Once you understand how to physically secure the system, the next step is to establish standards in a thorough security policy. For one thing, it helps you plan security logically; for another, it helps you track performance and procedures; for a third, you may need to have things in writing if you take legal action against someone who breaks into your system. The sample policy in this section is based on an MCS engagement with a large financial institution. The document began with two direct statements:

1. Access to external Web services as provided by the financial institution and its subsidiaries is for authorized company use only.

2. To provide protection of corporate information as required by the Information Security Policy, appropriate precautions must be taken while engaging in any activity on external Web services (including the Internet) to ensure that corporate information is protected from unauthorized access, modification, destruction, or disclosure.

Note: The financial institution that much of the balance of this article examines has branch offices throughout the United States and uses Windows NT 4.0 for its operating system. The challenge it faced was to plan and configure a large Windows NT network accessible by business partners over Web server, while safeguarding its network.

Server Security

The next section detailed the physical access and data backup procedures for their demilitarized zone (DMZ)—the server location designed to provide the best security. Their plan stated that:

No internal corporate network at the financial institution can be connected to the external DMZ network without firewall protection. Complete firewall architecture is in place to protect the corporate network from the Internet and no internal network is allowed to circumvent this security by directly attaching or multi-homing a server in the DMZ. In particular:

• Any device placed in the Web DMZ (server, router, sniffer, printer, etc.) that is accessible by personnel not employed by the financial institution must be approved by the Security team before it is placed on the network.

• All DMZ servers must be kept in a secured locked location.

• The floppy drives of all DMZ servers must be disabled, and, if possible, removed.

• Server backups and emergency repair disks must be kept in a secure location away from the server.

• No one who is not an employee of the financial institution can be given direct access to the DMZ from an internal or external location without authorization from the Security team. All such access must take place through the firewall unless explicitly approved by Security team management.

Classes of Information Allowed on External Web Services

The document next focused on handling information and connections in the DMZ. In particular, the account required:

• Confidential information. Only information classified as Public can be posted on the Web server—no confidential or personal information.

• Restrictions on posting or downloading copyrighted materials. All users must comply with copyright and software licensing agreements. It is explicitly against the Corporate Information Security Policy to violate such agreements. Uploading or downloading copyright protected material is expressly prohibited. Displaying or posting copyrighted material on any extranet or Internet server is expressly prohibited.

• Virus precautions. All information downloaded from external Web services or posted to the Web server must be immediately scanned for viruses using the approved virus-scanning software. A procedure must be put into place on all Web servers to keep virus definition files current. No e-mail message can be passed from any Web server until it has gone through the virus checking procedure. Any e-mail found to contain a virus will be removed from the system.

  Terminating External Session not Actively in Use. Sessions not actively in use must be disconnected. A procedure to time-out all idle connections will be put into place. All Windows 9x and Windows NT users must use a screen saver password and set the default activation to five minutes. Windows NT Workstation users must use the operating system's ability to lock the workstation when not in use. For sensitive systems other security measures will be put into place to protect the data. Some of the physical security measures will include:

  • Installing protective covers and case locks on systems

  • Using boot passwords and other built-in desktop security features

  • Disabling and/or removing floppy drives

  • Setting the CMOS to boot only from the local hard drive

  • Using Smartcards and Smartcard readers on high-security machines

Password Management

By setting strict controls for password creation and management, the security policy document eliminates ambiguity, imposes standards, and educates users on the value of proper procedures. It also defines password requirements and procedures. Here are some password policy statements taken from the policy document discussed above:

Users must maintain the confidentiality of user accounts and passwords. Users must not use the same passwords for accessing external (Web) and internal (corporate) systems because user accounts and passwords are transmitted over external services, such as the Internet, in clear text and easily intercepted. Strong passwords are required on the external DMZ. For more information see Knowledge Base article 161990, Title: How to Enable Strong Password Functionality in Windows NT.

Some guidelines for password use:

• Passwords must have at least seven characters and must contain at least one capital letter and one number.

• All passwords used by the built-in Windows NT accounts must be changed to conform to the password standard.

• All accounts must have passwords. Blank passwords are not permitted.

• Passwords must not be shared. Users should change passwords immediately if they are learned by anyone else.

• Passwords must be changed every thirty days. A history of the last six passwords is kept to force users to cycle no less than seven.

• Password must never be written down or sent in e-mail.

Unacceptable Usage

Users have to know what they can and cannot do. A security policy should describe unacceptable activities and inform users that their activities will be monitored and that violations of policy may have repercussions. The financial institution's policy characterized as unethical and unacceptable any activity which purposely:

• Seeks to use Web services for private or personal business.

• Seeks to gain unauthorized access to any resources within or outside of the financial institution.

• Disrupts the intended use of the financial institution and/or the Web service.

• Wastes resources (work time, line capacity, computer time) through such actions.

• Destroys the integrity of or misuses any information assets.

• Compromises the privacy of any other user or department.

• Damages the system.

• Compromises corporate proprietary material.

• Places material on any DMZ platform that is considered inappropriate, offensive, or disrespectful to others.

The policy also states: the financial institution reserves the right to monitor any and/or all external Web service related activity. Any users found in violation of this policy are subject to denial of access, and action that may culminate in termination of employment and/or criminal prosecution.

Reacting to a Security Exposure

No matter how tight the security is on an external DMZ there is still a risk of exposure from an external or internal source. Should a violation of security policy occur, you need a plan that will help you react to it. From the financial institution's policy:

Any suspicious activity or suspected security compromises to the Web must be reported to the Information Security Department. The security team will take appropriate action to determine the severity of the attack.

In particular, Security will work to completely understand the seriousness of the attack and take the following actions:

• Verify the integrity of the system or systems and take appropriate action

• Shut down all compromised areas to curtail exposure

• Determine the type of attack and its origin

• Take appropriate action to restore systems to normal operation

• Complete necessary steps to eradicate the security hole on all servers to eliminate recurrences

• Categorize the type of attack and if necessary take action against the perpetrator(s) (including legal action)

• If the attack is serious enough, assign a company spokesperson to contact the media to avoid damaging publicity

The actions taken by the security team will depend on the seriousness of the attack and depending on whether it is initiated by an "insider" or an "outsider." For insider violations the security team will take these actions:

• For minor offenses, issue a verbal warning.

• Warn in writing and/or reassign or demote employees who repeatedly violate the security policy.

• Terminate or take legal action against employees who repeatedly violate security or who commit a serious offense (see Unacceptable Usage section above).

For outsider attacks (for example, arising from Internet-based entities or applications) the Internet security team will:

• Find out the identity of the offending application or individual.

• Outline an action plan depending on the severity of the attack. If the attack warrants legal action, provide proper evidence handling.

• Implement and follow change control and testing procedures to plug any security breach.

• Conduct a post-mortem study of the attack. This will help the team improve the security policy, fully document how the incursion occurred, create detailed audit trails in the event of an attack, and finalize any required fixes to the DMZ.

Security Resources

Now that the security team has an internal security policy to enforce, the next challenge is staying current on all the latest security issues. This section outlines a variety of sources that can help with this task.

Microsoft Sources

Microsoft's internal Web site dedicated to the latest security information and issues: https://www.microsoft.com/Security/default.asp.

Other Sources

Security Incident Response Teams

• Computer Incident Advisory Capability (CIAC)— https://www.ciac.org/

• Computer Emergency Response Team (CERT) Coordination Center— https://www.cert.org/

• Australian Computer Emergency Response Team (AUSCERT)— https://www.auscert.org.au/

• NASA Automated Systems Incident Response Capability (NASIRC)— https://www-nasirc.nasa.gov/

• Computer Operations, Audit, and Security Technology (COAST)— https://www.cs.purdue.edu/coast/coast.html

• Computer Security Technology Center (CSTC)— https://ciac.llnl.gov/cstc/CSTCHome.html

• Federal Computer Incident Response Capability (FedCIRC)— https://www.fedcirc.gov/

Government Security Evaluation Sites

• National Computer Security Center Home Page— https://www.radium.ncsc.mil/tpep/

• Cryptographic Standards Validation Program at NIST— https://csrc.nist.gov/cryptval /

Standards Organizations

• World-wide Web Consortium (W3C)— https://www.w3.org/

• Internet Engineering Task Force (IETF)— https://www.ietf.org/

• ECMA— https://www.ecma.ch/

• Internet Society— https://info.isoc.org/

Security Organizations

• International Computer Security Association— https://www.ncsa.com /

• Applied Computer Security Associates— https://www.acsac.org/acsa.html

• Association for Computing Machinery Special Interest Group on Security, Audit and Control— https://www.acm.org/sigsac/

• Network Security International Association— https://www.netsec-intl.com/

• International Association for Cryptologic Research— https://www.microsoft.com/applicationcenter/evaluation/sysreqs/default.mspx /

• International Information Systems Security Certification Consortium— https://www.isc2.org/

Security Standards and Protocols

• IETF Requests for Comment— https://www.rfc-editor.org/

• Secure Electronic Transactions (SET)— https://www.setco.org/

• Kerberos Authentication Protocol— https://web.mit.edu/kerberos/www

Newsgroups

• alt.Security.*—Many different security related newsgroups can be found here

• Alt.2600—An area of newsgroups frequented by the hacker community

• Microsoft.public.windowsnt.*—Newsgroups on Windows NT that often contain security topics

• Comp.security.*—A set of newsgroups relating to security topics

• Microsoft.Public.Proxy—A discussion of issues relating to Microsoft Proxy Server

Other Security-related Web Sites

• https://www.ntsecurity.net

• https://www.ntbugtraq.com

• https://www.gocsi.com/

• https://www.icsa.net/

• https://www.somarsoft.com

• https://www.rsa.com/

• https://www.telstra.com.au/mobilenet/phones/wap2/security.htm

Mailing Lists

• NT Security Digest—A monthly synopsis (distributed via e-mail) of the recent security developments and discoveries. To subscribe, connect to https://www.ntsecurity.com

• NTBugTraq—A technically focused mailing list dedicated to Windows NT Security issues. To subscribe, connect to https://www.ntbugtraq.com/

• Cert Advisory List—A mailing list dedicated to announcing new security issues on all platforms. To subscribe, send e-mail to certadvisory-request@cer.org

Securing the External DMZ—Firewall and Router Security

Connecting servers to the Internet is the prime interest of many networking configurations, and this trend no doubt will continue until virtually every network is in some way connected. For all that this increases communications and opens a world of resources to every desktop, it also creates serious security concerns. And these are well justified given the nature of the Internet today. The days of academic fellowship that shaped the Internet in the early years are long gone, replaced by a competitive environment in which companies showcase themselves and their products to the rest of the world, and hordes of otherwise innocuous people prowl the lines rattling doorknobs in search of an unlocked portal. Companies have reason to worry about their exposure to intrusion, and that reason intensifies each time a break-in is reported—which happens with depressing frequency.

This is the networked world we live in. In response to these challenges, organizations across the Web work tirelessly on security research, design, and enhancement. The good news is this allows companies to learn about issues and provide fixes quickly. The bad news is that this imposes significant demands on security personnel in particular and company resources in general.

You need to provide as much security as is practical and possible "up front," and this section discusses how to secure your DMZ—the area in which your servers are typically placed to provide the best security. As system administrator you are responsible for creating and maintaining this secure environment.

First Step: Some Examples

At the very least, a DMZ requires a router. A more sophisticated design would include two routers and a firewall. How complex your configuration needs to be depends on factors such as:

• How much security you need

• What sort of connectivity your system maintains to other networks (internal—corporate network; external—Internet)

• How many servers you need to protect

The two diagrams below show DMZ configurations common in corporate environments today. Both provide excellent protection for the internal network. Figure 1 shows a simpler configuration; the configuration in Figure 2 protects the DMZ servers with the same security features used to protect the internal network, controlling DMZ access from the trusted and untrusted sides of the firewall. It is more complex but more secure.

Typical DMZ configurations are shown below:

Figure 1: : Simple DMZ configuration

Figure 2: : DMZ configuration controlling DMZ access from the trusted and untrusted sides of the firewall

After DMZ topology, the most important step in securing the environment is controlling its traffic. You need to determine who is allowed to connect and who is not, and then enforce those rules, usually with routers and firewalls.

Routers can provide packet filtering, which controls traffic flow between two nodes, but this tends to decrease router performance so you have to be careful not to overuse it. Check your router utilization before and after.

Firewalls protect internal resources from external access. They are more "intelligent" than routers: they can provide packet filtering and stateful inspection (decision-making algorithms that control traffic flow), so they can be used to create and enforce security policies, and to restrict inbound/outbound traffic based on variables such as:

• Protocol ID

• Destination/source port

• Destination/source IP address

The protocol ID is typically Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), although other protocols (GRE, for instance) are sometimes required. The firewall assigns each protocol a series of ports, usually on the basis of a service or task. UDP and TCP are assigned what are called "well known ports." A short list (a subset) of well-known ports starts below. For a full list, see The Windows NT 4.0 Workstation Resource Kit ("Port Assignment for Registered Ports"). You can find this on TechNet.

The destination port typically is determined by the type of service that the client is seeking and thus can be discerned before the connection is made. For example, the Post Office Protocol Version 3 (POP3) is defined as port number 110, so clients seeking to retrieve e-mail from the mail server should connect to port 110.

The source port is typically randomly selected from the pool of unassigned ports and typically will be greater than 1024 (as this is presumed to be the last defined port).

The source and destination IP addresses are self-explanatory. If the client has an IP address assigned by Dynamic Host Control Protocol (DHCP) it is impossible to define a filter that would permit this client to connect to an inside resource because you can't always be sure what the client's "true" address is. A solution to this problem would be to create a filter based on a series of pooled addresses or subnets.

Short list of well-known ports.

Port number	Process name	Description
1	TCPMUX	TCP Port Service Multiplexer
5	RJE	Remote Job Entry
20	FTP-DATA	File Transfer Protocol—Data
21	FTP	File Transfer Protocol—Control
23	TELNET	Telnet
25	SMTP	Simple Mail Transfer Protocol
42	NAMESERV	Host Name Server
49	LOGON	Logon Host Protocol
53	DOMAIN	Domain Name System
69	TFTP	Trivial File Transfer Protocol
70	GOPHER	Gopher
80	HTTP	HTTP
103	X400	X.400
110	POP3	Post Office Protocol version 3
137	NETBIOS-NS	NetBIOS Name Service
139	NETBIOS-DG	NetBIOS Datagram Service
150	NETBIOS-SS	NetBIOS Session Service
156	SQLSRV	SQL Server
179	BGP	Border Gateway Protocol

Configuring Firewall Security

Typically, you would assume that no traffic needs to cross the firewall. This is the most secure configuration. From there, you proceed to evaluate user needs, which typically will have well defined parameters:

• Destination ports

• Source and destination IP addresses

• Protocol ID

Based on these requirements, you can decide to allow specified kinds of traffic to enter from outside. For example, an e-mail administrator asks that remote users be able upload their e-mail while away from the office. If you decide to allow this traffic, you know that it will have these properties:

• Mail server IP address (fixed)

• Client IP address (variable)

• Port 25 (SMTP) on the mail server (fixed)

• Client source port (variable)

To allow remote users access, you would have to allow all external clients to hit port 25 of the internal mail server. This is referred to as punching holes in the firewall. The more you punch, the more difficult it is to keep your system secure.

Additional Firewall Features

Firewalls can implement more sophisticated services than packet filtering:

• Application proxy

• Circuit-level proxy

• Stateful inspection (intelligent decision-making algorithms that control traffic flow)

The major difference between packet filtering and proxy services (application and circuit-layer) is that the proxy does not let traffic through. Instead, the firewall establishes two connections:

• An internal client (inside of a firewall)

• An external resource (outside of a firewall)

These connections allow the client and server to communicate, but not directly—the proxy is in the middle. This minimizes security exposure but increased overhead on the proxy can reduce performance. The good news is that given the relatively slow nature of the Internet links (T1 compared to 10-MB Ethernet) the performance reduction is negligible.

There are two common types of proxy services: application and circuit-layer. Typical firewall software provides both to some degree. Application proxy services are provided only for certain types of applications because the firewall has to be designed to accommodate specific protocols such as HTTP or POP3. For example, when a browser client makes a page request to the proxy server, the server examines the request and proxies it to the destination server. Circuit-layer proxy is a "generic application proxy." In this case, the firewall does not need to handle a protocol for the client-server exchange: it simply takes a request for a connection from a given port and proxies it to the external server.

Firewalls also provide stateful inspection. This is an umbrella term for intelligent decision-making algorithms that control traffic flow. The algorithms collect pertinent information about the connection state from all of the relevant layers of the stack (current and previous) and assess it to decide whether to permit a packet to pass. Stateful algorithms can be very sophisticated and they can provide a very high level of security. The cost for this service is reduced performance.

Packet filtering, proxy services, and stateful inspection require that you understand DMZ traffic so that you can assess user needs accurately and derive a sensible security policy that in turn dictates the DMZ configuration.

Other Proxy Security Features

Most proxy servers offer services beyond the standard functionality discussed above. MS Proxy, provides three such features.

Reverse proxy enables proxy server to provide secure access to an internal Web server (not exposing it to the outside) by redirecting external HTTP (application proxy) requests to a single designated machine. This is not suitable for multi-server Web hosting (reverse hosting, described next, takes care of this) but it can be quite valuable when working with a single site.

Reverse hosting allows proxy server to redirect HTTP (application proxy) requests to multiple internal Web servers. Access to multiple servers can be provided as subwebs of one large aggregate Web site or as multiple independent Web servers. More flexible than reverse proxy but equally secure, this method enables you to abstract the physical architecture of your Web sites by mapping multiple servers to a single logical one. Both options benefit from MS Proxy Server's caching functionality.

Server proxy provides the same functionality as reverse proxy and reverse hosting, but unlike these features it works with protocols other than HTTP to provide secure access from the Internet to internal resources such as internal mail or SQL server. To an outside user, the proxy server appears to be the mail or SQL server. Basically, server proxy responds to external requests on behalf of the internal servers, which simply have to run the proxy client that redirects the listen directive on a given port to a proxy server. The security benefit is obvious: placing servers behind a proxy prevents direct tampering from the outside and fools would-be attackers into thinking that the proxy server is the box containing the information they want.

Reverse proxy can be very useful. For instance, suppose you need to allow a Web server to query an internal database. There are several ways to do this. You can replicate the database to the outside, if it is not too large, but this puts the contents' integrity at risk. It may make more sense to move the Web and database servers behind the firewall and use reverse proxy or reverse hosting to get at the site. This option is very secure, although the overhead of running multiple Web servers behind the proxy may tax the proxy's ability to service Web requests from internal clients.

A third alternative is better yet: place the Web server in the DMZ and use the server proxy functionality to query the database. This option, shown below in Figure 3, provides good security and performance.

Figure 3: : Web server in the DMZ; server proxy queries the database

Before you select any of these options you should analyze your requirements so that you can balance necessary security against performance/usability.

Virtual Private Networks and Secure Remote Access

Now that the DMZ is in place, another option corporations are considering is using this outside network to provide secure tunneled access into the corporate network. This solution eliminates the high costs associated with creating and maintaining a private remote access network. Microsoft Consulting Services has been engaged by many accounts to design a solution based on the Point-to-Point Tunneling Protocol (PPTP).

PPTP and the Point-to-Point Protocol (PPP) are supported by the Windows NT 4.0 and Office 2000 Remote Access Service/dial-up networking clients and by Windows 9x dial-up networking (built into Windows 98; Windows 95 requires an upgrade). PPTP uses the Internet as an infrastructure to connect clients or remote networks to a main corporate network. With Remote Access Service (RAS), users have direct dial-up, circuit-based access to a corporate network. With PPTP connection, users first establish direct dial-up, circuit-based connection to an Internet Service Provider (ISP) then use an encrypted "tunnel" over the Internet that connects to a corporate PPTP server. Figure 4 shows a PPTP RAS connection:

Figure 4: : PPTP architecture

Advantages of PPTP

• Eliminates long distance telephone costs associated with the use of 1-800 or local corporate RAS numbers. The user can dial a local number to access the Internet instead.

• Reduces RAS infrastructure costs such as modem and Integrated Services Digital Network (ISDN) adapter pools. Instead, the ISP handles all modem and ISDN upgrades while the corporation maintains a connection to the Internet to handle PPTP traffic.

• Gives users access to the same applications that they would use over a direct-dial RAS connection.

• Is supported under both Windows NT 4.0 and Windows 9x.

PPTP and Firewalls

PPTP provides secure access to remote private networks by allowing the remote network to authenticate the user as if the user had dialed into a RAS server, and by using the compression and encryption capabilities of the underlying PPP protocol.

There are two approaches to using firewall techniques for protecting a PPTP server and the private network to which it is providing secure internet access: place the PPTP server on the Internet with a firewall behind it to protect the served network, or place a firewall server on the Internet, with the PPTP server between the firewall and the private network.

Figure 5: : PPTP Server location options

In the first case, the administrator enables PPTP filtering on the PPTP server so that the server receives only PPTP packets. Then, additional filtering in the firewall behind the tunnel server can be applied to admit packets based on source and destination addresses or other criteria.

In the second case, the firewall must be enabled to recognize and pass PPTP packets to and from the PPTP server in addition to any other filter criteria.

The first approach is better because it screens all but PPTP packets from the tunnel server, then submits the data carried in the tunnel to additional filtering after decryption and decompression. The second approach can raise a security issue because the firewall filters cannot look inside the PPTP packet.

Firewall Requirements

PPTP sends data using IP GRE packets (IP protocol 47) and controls the tunnel using a TCP connection to port 1723. To filter PPTP packets through a firewall, you must make these changes:

1. Configure the firewall to allow traffic on IP protocol 47. This enables PPTP GRE packets, which carry the data flow. The data within the GRE frame can be encrypted and/or compressed if the client and server are so configured.

2. Configure the firewall to allow traffic sent to or from TCP port 1723. This is the PPTP control channel for configuring and managing the tunnel between the client and the tunnel server. The packet filter should include the address of the tunnel server. That is, out-bound traffic with port 1723 as the source port or the destination port should be allowed only from the tunnel server, and in-bound traffic with port 1723 as the source port or the destination port should be allowed only to the tunnel server. This is not necessary, but it enhances firewall security.

Security and Data Encryption

PPTP uses the RAS "shared-secret" encryption process, so called because both ends of the connection share the encryption key. PPTP uses the PPP encryption and PPP compression schemes. The PPP uses Compression Control Protocol (CCP) to negotiate encryption.

The PPTP client provides its user name and password to the PPTP server. A session key is derived (using the RSA RC4 standard) from the hashed password stored on both client and server, then is used to encrypt all data that is passed over the Internet. The remote connection is kept private and secure.

Also, the data in PPP packets is encrypted then encapsulated into a larger IP datagram for routing over the Internet to the PPTP server. If an Internet hacker intercepts an IP datagram, all that is discernible is an indecipherable collection of media headers, IP headers, and the PPP packet containing a block of encrypted data.

Encryption

Communication across the Internet requires both encapsulation and data stream encryption to be viable. PPTP provides multi-protocol encapsulation, or "tunneling" services, allowing IP, Internetwork Packet Exchange (IPX), and NBF packets to be used across the Internet. Microsoft's Point-to-Point Encryption (MPPE, 40- and 128-bit) provides confidentiality for transmitted data.

Microsoft clients and servers can use MPPC (Microsoft Point-to-Point Compression) and/or MPPE (Microsoft Point to Point Encryption) during the CCP negotiation process. When encryption is requested, 40- or 128-bit session key encryption is negotiated.

The user name and password of the PPTP client are available to the PPTP server and supplied by the PPTP client. An encryption key is derived from the hashed password stored on both the client and server. The RSA RC4 standard is used to create this 40-bit (128-bit) session key based on the client password. This key is used to encrypt all data that is passed over the Internet, keeping the remote connection private and secure. A new key is generated after every 256 packets.

Note: Users in the United States and Canada can obtain a 128-bit session key through a cryptography pack for use inside the U.S. The 128-bit key is derived from both the hashed password and the unique MSCHAP challenge. The U.S. Commerce Department will often grant permission to distribute "high security" products (allowing 128-bit encryption) to international offices of U.S.-based companies.

Data in PPP packets is protected as described above. Internet Protocol Security (IPSEC, currently under development), provides encryption, authentication, integrity check and replay protection for IP packets. IPSEC primarily provides network layer security for IP, not tunneling functionality per se, so while it is viable for server-server tunneling (such as between routers) it does not yet provide all the functionality required in client-server tunneling (see the table below).

As a result, IPSEC largely complements, but does not overlap, the functionality provided by PPTP and L2TP. This makes it attractive to combine the flexibility of Layer 2 VPN protocols (PPTP/L2TP) with the security provided by IPSEC. Microsoft will support such a "merged VPN" platform (PPTP or L2TP running over IPSEC) in Windows 2000.

In order to protect existing customer investments, Windows RAS and routing-based VPN solutions provide a smooth migration path from an existing PPTP infrastructure to a platform based on L2TP, IPSEC, and EAP. Windows 2000 will support client/server PPTP and L2TP based VPNs running over IPSEC, as well as server-server tunnels based on PPTP, L2TP, and IPSEC.

Security features

Features	PPTP	L2TP	IPSEC
Authenticated Tunnels		X
Compression	X (MPPC)	X (MPPC)
Token/Smart Card	X (EAP)	X (EAP)	X
Address Assignment	X	X
Multi-protocol	X	X
Encryption	X (MPPE)	X (MPPE)	X

Securing a Windows NT Internet Information Server

Securing the Web servers is always a major concern. This section provides guidelines for creating a hacker-resistant Windows NT Web server environment. It documents the process MCS used to secure IIS for the financial institution. The following is the set of steps and the template used to document each Internet server's configuration.

Server Hardware Platform

Financial Institution's Web server hardware platfo

System	Compaq Proliant 3000R
Processor	Dual 300-MHz Pentium Pro
Memory	256 MB RAM 512 K L2 Cache (std.)
Disk Subsystem	3 9-GB Drives in RAID-5 Array SMART-2SL Array Controller Optional: 4th 9-GB Drive as hot spare
Network	Netelligent 10/100 Controller (on-board) Netelligent 10/100 Controller (add-in PCI card)

Disk Subsystem

The disk subsystem was configured for hardware-level RAID and configured the three 9-GB disk drives as a single RAID-5 disk set.

Disk Controller Cache

Battery backup was enabled for the disk controller's cache. Controller caching was set to 75% read and 25% write-back.

Netelligent Network Interface Card

10/100-autodetect was enabled for the NIC.

Use a chart like this to document firmware configuration

Component	Rev. level

Apply SoftPaq updates as needed to obtain the minimum acceptable revision levels for firmware.

Windows NT Server

These Windows NT features and components were deployed. The table lists sources for the files. MCS installed all major components in the order they are listed.

Windows NT features and components and their source

Feature/component	Rev. level
Windows NT Server 4.0 Core OS Compaq Proliant Multiprocessor HAL Compaq SmartArray Driver Compaq Network Driver Transmission Control Protocol/Internet Protocol (TCP/IP) IIS 4.0	Compaq SmartStart CD
Windows NT Server 4.0 Service Pack 3 or 4 (When it is an approved standard)	Compaq SmartStart CD
Internet Explorer 4.01 Standard Installation No Active Desktop	Required by Option Pack (IIS 4.0)
Windows NT 4.0 Option Pack FrontPage 98 extensions Internet Information Server Internet Service Manager WWW Server Data Access Components 1.5 Data Sources (Jet and Access, SQL Server) Index Server System Files Language Support Catalog Directory: D:\Inetpub Microsoft Management Console Windows NT Option Pack Common Files	Windows NT 4.0 Option Pack CD
Transaction Server MTS Core Components Install to C:\Program Files\Mts Use Local Administration account Windows Script Host
Windows NT Hotfixes	Obtain fromhttps://www.microsoft.com/downloads/search.asp?
Compaq SSD Driver Updates	Obtain from https://www.compaq.com

Windows NT SP3 Hotfixes

Until SP4 is an approved standard, the financial institution is applying the appropriate SP3 hotfixes to the Web server. Many hotfixes address security and denial-of-service issues. Install the following list of hotfixes to the Web server (note: these hotfixes are included with SP4).

Apply the post SP3 hotfixes in this order (see note below):

Fix folder	Executable date	KB article(s)
Asp-fix	05/28/97 12:00AM	165335
Dns-fix	06/09/97 12:00AM	142047, 154984, 154985, 167629, 169461
Iis-fix	06/20/97 12:00AM	143484
Lsa-fix	06/25/97 12:00AM	154087
Lm-fix	07/11/97 12:00AM	147706
Zip-fix	07/14/97 12:00AM	154094
Getadmin-fix	07/15/97 12:00AM	146965, 168748, 170510
Winsupd-fix	08/07/97 12:00AM	155701
Ndis-fix	08/08/97 12:00AM	156655
Scsi-fix	09/05/97 12:00AM	171295
2gcrash	11/01/97 12:00AM	173277
Simptcp-fix	11/01/97 12:00AM	154460
Ide-fix	11/18/97 12:00AM	153296
Wan-fix	11/20/97 12:00AM	163251
Roll-up	11/24/97 12:00AM	147222
Joystick-fix	12/11/97 12:00AM	177668
SAG-fix	12/11/97 12:00AM	177471
Pent-fix	12/11/97 12:00AM	163852
Iis4-fix	12/12/97 12:00AM	169274
Teardrop2-fi	x01/09/98 08:23PM	179129
Tapi21-fix	01/12/98 06:29PM	179187
Pcm-fix	02/11/98 05:10PM	180532
Srv-fix	02/12/98 06:24PM	180963
ASPDataFix	07/07/98 08:00PM	188806

Note: Install the hotfixes in ascending order of the date/time stamps of the self-installing executables. Track all the latest security patches at www.microsoft.com/security.

Windows NT SP4

Installing and testing all these post SP3 hotfixes is costly and time consuming. The better approach is to install Windows NT Service Pack 4, which contains all the SP3 fixes plus the latest year 2000 updates and support for the Euro currency. SP4 is the best solution from a security perspective. For a complete list of the SP4 fixes, see the release notes or Appendix A. Some of the important ones are:

• All public fixes created to resolve customer issues since Windows NT 4.0 released (including the list documented above for SP3).

• All previous service pack updates (SP1, SP2, and SP3). SPs are cumulative and contain all previous service packs and hotfixes.

• The new system key for strong encryption. This tool allows you to configure the Windows NT Accounts Database to enable additional encryption, further protecting the database. Once enabled, this encryption cannot be disabled. For more details see Knowledge Base article 143475, Title: Windows NT System Key Permits Strong Encryption of the SAM.

• A new utility, SETPRFDC.EXE, and new functionality added to NETLOGON, allow for directing the SC_client to a preferred DC for the secure channel. SETPRFDC.EXE is a command-line utility that can be run in batch or with the AT scheduler in the format: SETPRFDC <TrustedDomain> <ListOfDcsInTrustedDomain> (DC1, DC2, etc.) You do not need to restart your computer when you use SETPRFDC. For more information see Knowledge Base article 167029, Title: Resource and Master Domain DCs Do Not Load Balance Validation.

• New performance and security updates to PPTP that greatly increase data transfer speeds when run on the PPTP client and server system. A new version of MSCHAP (MSCHAP V2) has been implemented for VPN connections. For more information, see Knowledge Base article 189595, Title: PPTP Performance & Security Upgrade for WinNT 4.0 Release Notes.

• A bug fix in the Event Log service that requires the SE_SECURITY_NAME privilege, also known as the Security privilege, to be enabled in order to view and manage the security event log. By default, Windows NT grants the privilege to Administrators and local System. However, the privilege must also be enabled in the program accessing the security event log in order to take effect. Prior to this change, members of the Administrators group and services running as local System could open the security log for read or change access without enabling the Security privilege. For more information, see Knowledge Base article 188855, Title: Security Privilege Must Be Enabled to View Security Event Log.

• Enhancements for the year 2000, including:

  The User Manager and User Manager for Domains recognize the year 2000 as a leap year.

  The date/time control panel applet can update the system clock.

  Find Files supports only numeric character recognition in the decades field.

  Word document properties recognize both 1900 and 2000 as valid centuries and support years of four digits.

  The DHCP administrator program supports the years between 2000-2009 with a minimum of two digits.

• The Security Configuration Editor (SCE), which is an integrated security system administrators can use to define and apply security configurations for Windows NT Workstation and Windows NT Server installations. SCE also helps you inspect installed systems to locate any degradation in security. For additional information, see the README file in the MSSCE folder.

System Requirements for SP4

• Service Pack releases are cumulative: SP4 contains all previous Service Pack fixes and any new fixes created after Service Pack 3.

• Windows NT Workstation 4.0, Windows NT Server 4.0 or Windows NT server 4.0 Enterprise Edition.

Note: Before you install SP4, read the release notes: they contain vital information as well as installation instructions.

To download SP4, copy from TechNet or go to: https://www.microsoft.com/ntserver.

The security officer should make sure that all the servers in the outside network are up to date, with all the latest security patches. SP4 makes this task much simpler by allowing the administrator to install all post-SP3 hotfixes using a single upgrade. Once testing is completed, SP4 will be a must for MCS client security. Also, the security officer should continue to monitor security standards organizations and related newsgroups, Web sites, mailing lists etc., for alerts, developments, and patches that occur after SP4.

NT System Directory Structure

The financial institution installed Windows NT Server to C:\MSWNT, not the default directory, to provide a layer of security against Trojan horse attacks that assume the default C:\WINNT directory.

System Settings

System Control Panel settings decided on by the financial institution security team

Properties	Setting
Application performance	Maximum boost
Virtual memory	Single pagefile of 128M on C:
Environment	Accept defaults
System startup	Windows NT Server Version 4.0 (default)
Show list for	3 seconds
System recovery settings
Write an event to the system log	Enabled
Send an administrative alert	Enabled
Write debugging information to	Enabled; %SystemRoot%\MEMORY.DMP
Overwrite	Enabled
Automatically reboot	Enabled

Directory and File Permissions

Directory permissions applied to the Windows NT directory (C:\MSWNT)

Directory	Permissions
C:\MSWNT And all subdirectories	Administrators: Full control CREATOR OWNER: Full control Everyone: Read Server Operators: Read SYSTEM: Full control

Permissions applied to subdirectories

Directory	Permissions
C:\MSWNT\REPAIR	Administrators: Full control
C:\MSWNT\SYSTEM32\CONFIG	Administrators: Full control CREATOR OWNER: Full control Everyone: List Server Operators: List SYSTEM: Full control
C:\MSWNT\SYSTEM32\SPOOL	Administrators: Full control CREATOR OWNER: Full control Everyone: Read Server Operators: Change SYSTEM: Full control
C:\MSWNT\Cookies C:\MSWNT\Downloaded Program Files C:\MSWNT\History C:\MSWNT\Subscriptions C:\MSWNT\Temporary Internet Files C:\MSWNT\WEB	Administrators: Full control Not shared Everyone: Special (based on requirements) Not shared Server Operators: Change Administrators: Full control SYSTEM: Full control Administrators: Full control

Directory and file permissions set in the root-level directory of the boot partition (C:)

Directory	Permissions
\BOOT.INI \NTDETECT.COM \NTLDR	Administrators: Full control System: Full control SYSTEM: Full control
\AUTOEXEC.BAT \CONFIG.SYS	Administrators: Full control Everyone: Read Administrators: Full control SYSTEM: Full control
\TEMP directory	Administrators: Full control CREATOR OWNER: Full control Everyone: Special (based on requirements) Server Operators: Change SYSTEM: Full control

Network Configuration

The financial institution used the charts below to document each server's network level configuration. The example below outlines the configuration for all of the production Web servers.

Identification chart for production Web servers

Computer name	XXXXXX
Domain	XXXXXX
Role in domain	XXXXXX

Identification chart for network services

Service	Properties	Setting
Computer Browser	Other Domains for Browser Service	None (default)
NetBIOS Configuration	LAN adapter (LANA) numbers	Accept defaults as configured by binding analysis
RPC Configuration	Name Service Provider	Windows NT Locator (default)
	Network Address	None (default)
	Security Service Provider	Windows NT Security Service (default)
Server	Optimization	Maximize Throughput for Applications (default)
	LAN-Man 2.x Browser Announcements	Disable (default)
Workstation	No configurable properties

Also, you should disable commands such as: Finger, Netstat, systat, echo, FTP, Telnet, and the Berkeley "r" commands (rlogin, rsh, rdist, etc.) by either removing them or placing them in a secured directory other than under %SYSTEMROOT%.

Network Protocols and Adapters

Configure TCP/IP only: The public adapter is publicly registered with the Internet Domain Name System (DNS). Web clients on the Internet connect to the Web server on this adapter. The financial institution documents the network configuration using this template:

Public adapter configuration

Properties	Setting
IP Address(es) and masks	x.x.x.x mask: y.y.y.y
Gateways
Enable PPTP Filtering	Disabled (default)
Enable Security	Enabled
TCP Ports	Permit only: 80, 443
UDP Ports	Permit only: None
IP Protocols	Permit only: TCP, ICMP (based on requirements)
Host Name (Internet)
Domain (Internet)
DNS Servers (in searched order)
Domain Suffix Search Order	Accept defaults
Primary WINS Server	None
Secondary WINS Server	None
Enable IP Forwarding	No

Network Bindings

Bindings determine what network services are available on the network adapter(s). Correctly configuring the bindings is essential to securing the Web server.

Bindings configured in the network control panel

Adapter	Enabled/disabled
Public	Enabled
TCP/IP Protocol	Enabled
WINS Client (NetBIOS over TCP/IP)	Disabled
NetBIOS Interface	Disabled
Server	Disabled
Workstation	Disabled

Router and Port Changes

Safeguards to consider, based on those implemented by the financial institution:

• Filter out ports 137 (nbname), 138 (nbdatagram), 139 (nbsession) on the outside router, to prevent a hacker from port-scanning the Internet router to validate the existence of a Microsoft Network.

• Block all non-essential TCP/IP ports.

• Set up proper packet filters on the routers to prevent security exposures. This requires detailed planning and an intimate knowledge of TCP and UDP port utilization.

• Disable IP forwarding on all Web servers especially if there are any multi-homed servers. Multi-homed servers (two network cards, one connected to the internal network and one connected to the external network) are considered a security risk and, as such, require special handling.

Services

Do not allow a secured Windows NT server running IIS to be used to run any other services, it makes the server more vulnerable. Shut down any nonessential services.

Server configuration for the financial institution

Service	Description	Startup
Alerter	Send alert messages, such as disk full, to administrators. Depends upon the Messenger service.	Disabled
ClipBook Server	Used for DDE	Disabled
Computer Browser	Used to list Windows Networking computers on the network	Disabled
Content Index	Index Server	Automatic
DHCP Client		Disabled
Directory Replicator	Used to replicate directories with other domain controllers	Disabled
EventLog	Event Log Service	Automatic
FTP Publishing Service		Disabled
IIS Admin Service	Web-based Administration	Automatic
License Logging Service		Automatic
Messenger	Used to send network messages to Windows Network machines and users	Disabled
MSDTC	Microsoft Distributed Transaction Coordinator	Automatic
Network DDE		Disabled
Network DDE DSDM		Disabled
NT LM Security Provider		Automatic
Plug and Play		Automatic
Protected Storage	Used by IIS and IE	Automatic
RPC Locator		Automatic
RPC Service		Automatic
Server		Automatic
Site Server Auth. Service		Automatic
Site Server Content Deployment		Automatic
Site Server LDAP Service		Automatic
Site Server List Builder Service		Automatic
Site Server Message Builder Service		Automatic
Spooler		Automatic
Task Scheduler		Automatic
TCP/IP NetBIOS Helper		Disabled
Telephony Service		Manual
UPS		Manual
Workstation		Automatic
WWW Publishing Service		Automatic

User and Group Accounts

It is important to maintain and track all server accounts if you want to maintain a secure environment.

The financial institution's current list of accounts and groups

Account	Purpose	Notes
XXXXX (Administrator)	Account for System Administration	This is the Administrator account created during NT Setup. Rename this account to XXXXX
Guest	Guest access	Disable this account.
IUSR_XXXXX	IIS Anonymous Access
IAPP_XXXX	IIS Web Application Manager Account
LDAP_ANONYMOUS	Anonymous account for MP LDAP Server	Used with Membership Server

Local Groups

Group	Description	Members
Account Operators	Members can administer domain user and group accounts	Administrators
Administrators	Members can fully administer domain controllers	Administrators
Backup Operators	Members can bypass file security to backup files	None
GRPAUOMicrosoft	Group for AUO Accounts	None
Guests	Users granted guest access to the computer/domain	Domain Guests
Print Operators	Members can administer domain printers	None
Replicator	Supports file replication in a domain	None
Server Operators	Members can administer the domain servers	None
Users	Ordinary users	Domain Users

Global Groups

Group	Description	Members
Domain Admins	Designated Administrators of the Domain	Administrators
Domain Guests	All domain guests	Guest
Domain Users	All domain users	All users except Guest

Windows NT User Rights

The default column includes user rights assigned when Windows NT Server, Service Pack 3, and the Windows NT Option Pack are installed.

The financial institution's user rights with changes noted

User right	Default	Changes
Log on locally	Account Operators Administrators Backup Operators Server Operators Print Operators	Administrators Backup Operators Server Operators IIS Accounts attempting to connect to the Web server
Shut down the system	Account Operators Administrators Backup Operators Server Operators Print Operators	Administrators
Access this computer from the network	Administrators Everyone	Administrators IIS accounts attempting to connect to the Web Server Backup Operators Server Operators
Act as part of the operating system	(None)
Add workstations to the domain	(None)
Back up files and directories	Administrators Backup Operators Server Operators
Bypass traverse checking	Everyone
Change the system time	Administrators Server Operators
Create a pagefile	Administrators
Create a token object	(None)
Create permanent shared objects	(None)
Debug programs	Administrators
Force shutdown from a remote system	Administrators Server Operators
Generate security audits	(None)
Increase quotas	Administrators
Increase scheduling priority	Administrators
Load and unload device drivers	Administrators
Lock pages in memory	(None)
Log on as a batch job	(None)
Log on as a service	(None)
Manage auditing and security log	Administrators
Modify firmware environment variables	Administrators
Profile single process	Administrators
Profile system performance	Administrators
Replace a process-level token	(None)
Restore files and directories	Administrators Server Operators Backup Operators
Take ownership of files or other objects	Administrators

Passwords

The financial institution implemented the Windows NT SP3 password filter to force the use of strong passwords. To turn on high security for all passwords, follow this procedure on all secure domain servers:

1. Install Windows NT 4.0 SP3.

2. Copy PASSFILT.DLL to the %SYSTEMROOT%\SYSTEM32 folder.

3. Use Registry Editor (REGEDT32.EXE) to add the value Notification Packages under HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \Lsa, of type REG_MULTI_SZ, under the LSA key. If this key already exists, go to Step 4.

4. Double-click the Notification Packages key and, if the value FPNWCLNT is already present, add PASSFILT under it.

5. Click OK and then exit Registry Editor.

Shut down and restart the computer running Windows NT Server. For more information see Knowledge Base article 161990, Title: How to Enable Strong Password Functionality in Windows NT.

Registry Key Changes and Additions

Secure Event Log Viewing

The financial institution restricted the Guest account and null logons from accessing the event logs.

Changes to the default registry configuration to restrict Guest account

Hive	HKEY_LOCAL_MACHINE
Key	\System\CurrentControlSet\Services\EventLog\Application
Value Name	RestrictGuestAccess
Type	REG_DWORD
Value	1

Hive	HKEY_LOCAL_MACHINE
Key	\System\CurrentControlSet\Services\EventLog\Security
Value Name	RestrictGuestAccess
Type	REG_DWORD
Value	1

Hive	HKEY_LOCAL_MACHINE
Key	\System\CurrentControlSet\Services\EventLog\System
Value Name	RestrictGuestAccess
Type	REG_DWORD
Value	1

Require SMB Message Signing

Message signing is an SP3 feature that prevents "man-in-the-middle" attacks using LAN Manager protocols. Even though the security team disabled LAN Manager on the external adapter, the financial institution's security team requested message signing for additional layer of security.

Message signing registry settings

Hive	HKEY_LOCAL_MACHINE
Key	\System\CurrentControlSet\Services\LanManServer\Parameters
Value Name	RequireSecuritySignature
Type	REG_DWORD
Value	1

Hive	HKEY_LOCAL_MACHINE
Key	\System\CurrentControlSet\Services\LanManServers\Paremeters
Value Name	EnableSecuritySignature
Type	REG_DWORD
Value	1

Note: You must also apply these settings (along with Service Pack 3) to any other Windows NT Servers or Workstations with which the Web server communicates using SMB (LAN Manager upper-level protocols).

Hide the Previous Logon Name in Winlogon

The configuration at the financial institution hides the previously used logon from the Logon screen to prevent a hacker from discovering a valid user name.

Hide previous logon name registry setting

Hive	HKEY_LOCAL_MACHINE
Key	\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon
Value Name	DontDisplayLastUserName
Type	REG_SZ
Value	1

Add a Banner to NT Logon Process

For legal purposes, the financial institution server logon process carries a banner notifying users that the server is a corporate resource, that the network is for authorized use only, and that all activities may be monitored.

Logon banner registry setting

Hive	HKEY_LOCAL_MACHINE
Key	\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon
Value Name	LegalNoticeText
Text	Sample: All users must be authorized to access Web systems. All activities are monitored.

Auditing

Audit Policy

To maintain a secure environment you must continually monitor systems. Using the Windows NT User Manager, financial institution configured auditing to track the following events:

Auditing settings

Event	Success	Failure
Logon and Logoff	X	X
File and Object Access		X
Use of User Rights
User and Group Management	X	X
Security Policy Changes	X	X
Restart, Shutdown, and System	X	X
Process Tracking

Event Logs

Even though overwriting security events is not recommended, financial institution chose to do so and used these settings for all Windows NT Event Logs (Application, Security and System):

Event log settings

Max. Log Size	4,096 K
Event Log Wrapping	Overwrite events older than 7 days

Configuring Internet Information Server

Secure Sockets Layer Support

Secure Sockets Layer (SSL) provides an encrypted communications channel for user authentication between the Web server and Web clients. To enable SSL Version 3.0, the financial institution requested and installed an X.509 public-key Server ID certificate, available from any Certificate Authority.

For their Web server, they obtained a Global ServerID certificate from Verisign. The Global Server ID supports 128-bit encryption for clients both within and outside the United States and Canada, although you should carefully research export requirements for other countries. The Global Server ID requires an annual renewal. Using Key Manager, they created a new key for the WWW Service.

The financial institution template for documenting the key request process

Request File
Key Name
Password
Bit Length
Organization Name
Organizational Unit	Company Organization or Division
Common Name
Country
State/Province
City/Locality
Your Name
E-mail Address
Phone Number

Configuring Webs in Internet Information Server

IIS creates a default Web site at install time. The financial institution retained this Web site for system management purposes.

They created separate Web sites and locations for each site located on the box.

Template for documenting Web sites

Description	Home
Select IP Address	IP address of external LAN adapter
TCP Port	80
SSL TCP Port	443
Home Directory	D:\Web\wwwroot\Home
Allow Anonymous Access	No
Home Directory Permissions
Read	Yes
Script	Yes
Execute	No
Write	No
Directory Browsing	No

Overall Web site properties

Description	Company Internet
IP Address	IP address of external LAN adapter
TCP Port	80
SSL TCP Port	443
Connections	Unlimited
Connection Timeout	900 seconds
Enable Logging	Yes
Active Log Format	W3C Extended Log File Format

Operator Properties

Operators

Administrators SiteServer Administrators

Performance properties

Estimated Hits per Day	Fewer than 100,000
Bandwidth Throttling	Disabled
Maximum Network Use	N/A
HTTP Keep-Alives	Enabled

Home directory properties

Content Source	Local Directory
Local Path	D:\Web\WWWroot\Home
Access Permissions	Read Only
Content Control	Log Access Only
Application Settings
Name	Default Application
Isolated Process	No
Permissions	Execute (including script)

Documents properties

Enable Default Document	Yes
Default Document List	Default.asp Default.htm
Enable Document Footer	No

Directory security properties

Anonymous Access and Authorization Control	Yes (for unsecured pages)
Secure Communications	Yes
Require Secure Channel	No (this may change) Note: Select SSL on a per page basis
Client Cert. Authentication	Do not accept (may be introduced later)
IP Address & DNS Restrictions	None

HTTP headers properties

Enable Content Expiration	No
Custom HTTP Headers	None
Content Rating	Default
MIME Map	Default

FrontPage Server Extensions

FrontPage is a design tool for Web developers. It also provides a set of extensions that facilitate some of its functionality by installing binaries directly onto the Web server. This allows FrontPage to automatically maintain Web site integrity (prevent broken links) and to add functionality by providing the Web page designer with some runtime controls: Web-bots and Web themes. It also allows users to designate permission for the "FrontPage" Web site: administrator, author, or browser.

These rights are enforced according to permissions granted to the DLLs that perform the functions. They are available locally and remotely (over the Internet). If not set up properly or monitored they can be used to compromise the security of your Web site.

Because of continual problems with administrators not resetting these rights properly, the financial institution chose to remove these extensions from the server. The staging servers still use FrontPage extensions but none of the DMZ servers have them installed. To accomplish this they made certain that none of the FrontPage directories are posted to the final production Web site. They removed all directories that FrontPage might have installed, including:

• _vti_bin

• _vti_bin\_vti_aut

• _vti_bin\_vti_adm

• _vti_pvt

• _vti_cnf

• _vti_txt

• _vti_log (this one will be present only in the root Web server directory)

FrontPage also uses a FRONTPG.INI file to locate any components that might have been installed. It is located in the %SYSTEMROOT% directory.

Tasks for Security Officer

Configuring proper security on an IIS is only one of the major tasks required to create a secure Web presence. The financial institution felt that it was equally important that a security officer be appointed to monitor, update, and improve the DMZ, and to maintain the integrity of the security model. Some of the tasks they assigned to this person included:

• Help create the security model and enforce its standards and guidelines.

• Identify and monitor suspicious activity, internal threats, password and account violations, suspicious e-mail activity, access to sensitive information, and security incursions.

• Outline the procedure, protocol, and activities required when responding to a security threat.

• Implement and track Web activities using tools such as packet sniffers, system logs, audit logs, Network Monitor, and Performance Monitor alerts.

• Maintain self-assessment tools that look at the server security and probe for potential weaknesses. Some example tools are: ISS Secure Scanner, Kane's Security Analyst and Security Monitor, BindView, NOSAdmin for NT, and the standard TCP/IP Tools (finger, whois, ping, etc). These tools are described in detail in Designing and Planning Internal Security .

• Discover and respond to new types of security exposures.

• Fully understand the incident reporting process and the use of Incident reporting tools (Internal Process Definition and Computer Emergency Response Team advisories).

• Review news groups, monitor mailing lists, and attend security conferences.

• Monitor Web sites such as https://WWW.NTSecurity.Com , https://WWW.NTBugtraq.Com , and www.microsoft.com/security/ for the latest alerts and issues.

• Create the backup and disaster recovery plan for the DMZ.

• Manage secure content updating from the development and staging Web servers to production.

• Approve all CGI scripts that are required by a development team before they are placed on the DMZ Web server (a separate testing model will be created for CGI scripts to address concerns about CGI and security implications).

• Track all servers in the DMZ to make sure they have the latest virus software. Scan all files and put a procedure in place to keep virus definitions up to date.

• Continually monitor all DMZ servers to make sure that the security model is always current and fully intact.

Third-party Audits

After they completed and put their security model in place, the financial institution considered having a third party attempt to uncover overlooked issues or security risks. Companies of this type (you can find them on the Internet):

• Scan remotely to try to uncover any security vulnerabilities and look for any of the common hacker signatures in the Web DMZ.

• Supply detailed audits of possible weaknesses in the DMZ security structure.

• Attempt penetration testing by running hacker-like attacks against the DMZ.

• Consult on the design of the DMZ infrastructure and the creation of the security model.

• Analyze firewall security by using various infiltration techniques.

• Evaluate the problem escalation process, backup, and disaster recovery techniques.

There are many risks involved with hosting data on the Web, and they can generate problems despite the best efforts of security teams to protect that data. Third-party evaluation can help assure its integrity, confidentiality, and safety.

Testing and Evaluating the Current Security Level

Security Evaluation Tools

Once you establish a secure DMZ, you have to understand how to monitor and manage changes to the security model to ensure its soundness. Failure to authorize or track changes can result in debilitating security issues. In one case, a developer turned on default author rights for FrontPage extensions, creating a security hole that would have allowed a hacker to overwrite the Web site. (If you can believe this, a hacker identified the hole and reported it, rather than committing any mischief. This company dodged a large-caliber bullet.) And you have to remember that inadvertent damage to information resources (a directory unintentionally destroyed) is just as troublesome and expensive as a commando-style attack. You need to protect your infrastructure and resources against all kinds of damage.

Some type of change management is an absolute necessity. The Microsoft Solutions Framework (MSF) formalizes the change management process used at Microsoft. (See www.microsoft.com/solutionsframework for more detail.) Control is the issue: you can create a Web site that allows people to submit change requests for authorization. When permission is given, an engineering change notice is generated and the security document updated. This sort of change management can help you sleep much better.

With change management fully in place, the administrator still needs some tools for ongoing DMZ monitoring. Windows NT Server comes with some utilities useful in this effort:

• User Manager. To create a security policy, manage advanced rights and user accounts.

• Network Monitor. To capture and diagnose traffic at a protocol level.

• Server Manager. To track connections, shares, and server status.

• Event Viewer. To study system, security, and application-level events.

• Performance Monitor. To track thousands of system and performance level counters to generate alerts, look for errors or issues, and track system capacity. (The Windows NT 4.0 Resource Kit has complete details on ways to use PerfMon.)

These tools are helpful but you also need tools that more directly monitor security effectiveness. Third-party tools available for this purpose are described in Designing and Planning Internal Security .

Managing Web Server Changes

This section builds on the previous one by outlining a series of possible solutions to handle archiving and retrieval of changes that occur when new Web sites and applications are installed on Web servers.

The discussions below deal with porting registry information from system to system. This can be successful only when two systems contain identical (or close to identical) hardware; otherwise it is unsupported. Research this carefully before trying it.

Option 1—Standard Windows NT Backup and Tools

This is the low-end solution. It addresses system change issues by physically logging the information being modified, using standard tools such as Rdisk and Regback, and storing the information manually and remotely for recovery after catastrophic failure.

Many third party backup solutions (Cheyenne, Computer Associates, Veritas) include the capability to back up and restore a complete Windows NT system (image backup, registry and file backups etc.). If your security policy calls for on-demand recovery, this option will not meet your needs. Backup solutions can provide an alternative if over-the-network solutions fail, so you might want to consider testing them as you work through security options. The entire registry and file backup process is easy to automate.

Option 2—Windows Script Host

The Windows NT Option Pack comes with the Windows Script Host (WSH). This is a classical scripting engine that enables JSCRIPT or VBSRIPT to manipulate the IIS admin objects. If the provisioning process is scripted, the information can be entered using an "answer file," that can be processed by a script designed to modify administration objects. You can use these files as a method of collecting change information that can then be automatically moved to a remote server and used remotely to rebuild a down server during the recovery process.

A known limitation of WSH is that it currently can administer IIS only. This will be overcome in Windows 2000, which exposes the administration of all operating system facets through the scripting functionality. In Windows NT 4, however, WSH cannot capture Windows NT configuration information, so you must incorporate other methods with it to create a complete recovery process. Tools available for this are described below.

In addition to the server backups you should also back up the registry, which contains crucial configuration information. Windows NT's RDISK.EXE backs up the registry and creates a floppy disk that setup can use to recover the server after a crash or registry corruption. If all program files are also restored, the server should be fully recovered.

Windows NT system configuration requires administrators to restore the registry specific to a machine, not the registry of a similar machine. Even machines that seem to have the same configuration can have subtle hardware differences (BIOS levels, ROM settings etc.) and problems can occur if the wrong registry is restored. Your security team should put in place a procedure to track registry backups box by box.

You have to run RDisk from the console of the system being backed-up. This can be a problem, in which case you can use ERDisk (https://www.aelita.com) to run RDisk over the wire.

When the crashed system and the recovery system run on identical or very similar hardware, you can recover the system remotely by using ERDisk to restore the entire registry or specific portions of it. After the changes are applied to the live box, you can boot it remotely.

You can make configuration changes to accommodate inter-system hardware variance.

A third tool is IntraSoft's KeyVision (https://www.keyvision.com).

KeyVision features

Feature	Benefit
Centralized Registry Information	Concurrent access to registry settings for all machines and users across the Web Servers
Auditing and Rollbacks of Registry Changes	Thorough histories of registry changes and chronological backtracking speeds diagnosis and recovery of registry issues, so you can get a Web server back online faster.
User-Definable Rules and Notification	Administrators can define specific alert-generating registry events, so corrective action can be taken to prevent potential problems.
Simultaneous Real-time Registry Modifications	Multiple registry changes can be applied simultaneously to multiple systems using KeyVision registry keysets.
Multi-level Windows NT Security Access	Using the Windows NT security structure, Web administrators can be granted three levels of access to registry information: Administrator, Operator, and Read-only User access.

Monitoring Network Health

Along with monitoring configuration changes, you should also monitor issues that affect the system's running state so that administrators can be alerted in the case of a failure.

Option 1—Use the Built-in Performance Monitor and Event Log

Windows NT has some built-in tools to monitor system failures. You can set up the event log and Performance Monitor to alert administrators of critical system resource failure, including system, security, and application events. Windows NT also supports Simple Network Management Protocol (SNMP) and can be integrated with an existing SNMP network management solution.

Option 2—Third-Party Solutions

You can use a third-party solution such as WebWatcher from Avesta Technologies to monitor system health. It monitors Web servers and other network devices, automatically detecting the applications running on Web and FTP servers and testing them in real-time. Administrators can use it to search for any TCP-supported server type. In addition to watching the Web, this tool also watches routers and gateways, and has support for SNMP agents. When a device fails to respond, WebWatcher notifies the appropriate people by e-mail.

Other tools include WebSniffer from McAfee, which includes agents that gather network protocol and server statistics, a repository that acts as the central database, and software that monitors communications between the Web Server and its users to identify performance problems and provide early warning of slowdowns.

It is important to test these solutions in a lab before choosing one.

The operations described in this section are intrusive and you must thoroughly understand and test them before you use them in your production environment.

Validation Options

When designing security for the DMZ you should also consider user and file level security. The next section outlines three ways that MCS client accounts have built their security to provide secure access to their users:

• Basic security and Secure Sockets Layer (SSL)

• Windows NT challenge-response

• A Lightweight Directory Access Protocol (LDAP)-based directory architecture

Using Basic Security and SSL

Basic authentication uses the local account database to validate remote users, but it does not encrypt this information and the user account and password are passed over the Internet in clear text. The SSL encryption scheme can be used to overcome this shortcoming.

SSL reduces the risk associated with doing business on the Web. It prevents network eavesdropping and sniffer-based attacks. It secures the logon sequence and data, and verifies data integrity. It provides the following benefits:

• The authentication process identifies and directs data to the proper server.

• The encryption and transfer mechanisms ensure that the data is routed properly.

• The process of reading the data at the server verifies that the information has not been tampered with.

In addition, SSL allows administrators to decide if a client-side certificate is required to access a particular virtual server or folder. In this case the server would request an X.509 certificate back from the client in order to validate the identity. For more information on SSL, connect to the RSA data security Web site at https://www.rsa.com.

Here's the user logon sequences (Figure 6):

1. User directs Web browser to connect to the Web Server (HTTP, TCP port 80).

2. In response to the client request to access a secure area of the site, the Internet Web server establishes a secure, encrypted connection. Over this connection, the Internet Web server presents an SSL-secured logon Web page. (HTTPS, TCP port 443).

3. User enters ID and password, then submits the information to the Web server. (HTTPS, TCP port 443).

4. Web server (Basic Authentication Service) passes the user ID and a password challenge to the Local Security authority for validation.

5. Local Logon Service queries the local account database for account credentials (access and rights) and returns the data to the Authentication Service.

6. Authentication Service verifies user ID and password. Assuming proper validation, the logon page then redirects the client to the application or set of secure pages and sends that information to the Web client.

Figure 6: : Basic security and SSL

Advantages

• Basic security is supported by most browsers and platforms (Internet Explorer and Netscape in particular).

• It is relatively simple to implement.

• SSL encrypts the password sequence and verifies the accuracy of the data.

Disadvantages

• Accounts must be maintained in the DMZ and on separate servers, obviating a central account database. All accounts are created and administrated server by server.

• Account administrators have to gain direct access to the DMZ to maintain user names, passwords, and security equivalencies.

• Using encryption based on SSL slows performance. Lab testing can verify how much.

Using Windows NT Challenge-Response

Windows NT challenge-response is more secure than the basic authentication method. Challenge-response first attempts to log the user on using the credentials supplied when the user first logged on to the machine. If this fails, the user is prompted with a logon dialog requesting a user name and password, which are then validated against the Windows NT security accounts database. If this succeeds, the user is given an access token that contains all relevant security equivalencies for the domain. Administrators use these security settings to assign proper rights to the Web server's resources.

If both Windows NT challenge-response and basic security are enabled, the Web server uses the highest level of security supported by the Web server: challenge-response if possible, otherwise basic.

Windows NT challenge-response uses a full cryptographic exchange with the user's browser to validate the username and password. The actual password is never transmitted over the Internet, and this protects you against network spies who steal passwords off the wire.

A sample user scenario looks like this (Figure 7):

1. User directs Web browser to connect to the Web Server (HTTP, TCP port 80).

2. In response to the client request, the outside Web server establishes a secure, encrypted connection using Windows NT challenge-response.

3. Over this connection, the Web server presents a secured logon Web page and the user enters a user ID and password and submits the information to the Web server.

4. This information is validated against the Windows NT Server Domain Account Database Web Server (Windows NT Logon Service), which passes user ID and a password challenge to the Domain Security authority for validation. This information is not transmitted over the Internet.

5. The Authentication Service verifies the user ID and password. If this succeeds, the Authentication Service constructs a session ID and passes it to the Web client as an access token. The logon page then redirects the client to the application or secure page and sends that information to the Web client.

Figure 7: : Windows NT challenge-response

Advantages

• Windows NT challenge-response allows you to continue to use standard Windows NT domain architecture.

• Domains allow you to administer all DMZ user accounts centrally and assign rights to servers using this central account database.

• Challenge-response requires no client or browser software changes.

Disadvantages

• Does not support firewalls or proxies.

• Not yet supported by Netscape.

• Does not yet support delegation to secondary servers, so user credentials cannot be passed to another machine. For example, when a request comes in to IIS, the user account credentials cannot be passed to Microsoft SQL Server on a secondary machine.

Using an LDAP Based Directory

The Membership Directory is the Microsoft implementation of a directory service that supports Lightweight Directory Access Protocol (LDAP) which in turn provides the means to communicate with the Membership Directory. With Membership, you can create a centralized, extensible directory structure. It can also allow you to secure the account database by placing it behind the firewall.

With a Membership database, here is a user session sequence (Figure 8):

1. User points Web browser to the Web Server (HTTP, TCP port 80).

2. An encrypted connection using SSL is established. The Web server uses it to present a Logon Web page (HTTPS, TCP port 443).

3. User enters ID and password, and they are passed to the Web server (HTTPS, TCP port 443).

4. Extranet Web server (Site Server Authentication Service) passes user ID and a password challenge to the LDAP Service on the Membership and Messaging Server (LDAP, TCP Port 1003).

5. LDAP Service queries the Membership Directory SQL database and returns the data to the Authentication Service on the Web server (ODBC over TCP/IP, TCP port 1344).

6. Authentication Service verifies user ID and password. If they are valid, the Authentication Service constructs a session ID and passes it to the Web client as a cookie with a limited time-to-live (TTL) setting. The logon page then redirects the client to the Web Site or application menu and sends that page to the Web client.

7. Client selects the desired Web-based information, which passes a request for a Web page to the Web server, which passes the front page of the selected Web or application to the client.

Figure 8: : Membership database user session sequence

Advantages

Placing the Membership infrastructure behind the firewall:

• Protects the account database by locating it behind the firewall. You can further enhance security by placing two network cards in the DMZ network—one on the public network and one on a private network. Filters on the firewall would allow traffic from the private network to enter the internal network, and would block all other traffic.

• Makes it possible to scale Membership to thousands of users. This allows you to build expandability into your design.

• Creates a centralized standards-based LDAP directory that can be integrated or migrated to future LDAP infrastructures such as Windows 2000.

• Eliminates the need to punch holes in the firewall because all administration takes place on the corporate network.

Disadvantages

• Requires development skills.

• Creates a separate set of corporate accounts from the existing Windows NT SAM. You would have to understand Membership and Windows NT to merge the two databases.

When to Use Each Solution

• Each of these has been implemented in a full production environment. Solutions were chosen based on business and technical requirements.

• A very large company chose to implement basic/SSL to secure its outside presence because:

• They had no control over the type of browser that would connect to the site. The solution had to support Netscape and Internet Explorer, so Windows NT challenge-response could not be used because Netscape does not support it.

• They wanted an off-the-shelf solution that could be implemented quickly with very little development effort. The basic/SSL solution required only that they obtain a key from Verisign and install it in IIS.

• Users connecting to the site must be required to have valid user names and passwords. The configuration used Windows NT Servers (not BDCs or PDCs) for local security and access control lists to manage user accounts and secure area access.

Another MCS client chose to allow business partners to gain access to its infrastructure using Windows NT challenge-response because:

• All accounts needed to be maintained in the central account database. Creating a domain in the DMZ allowed them to do this.

• Site developers could take advantage of additional development features supported by Internet Explorer, including NTLM authentication, enhanced implementation of DHTML, including screen repainting and event bubbling, VB Script, Microsoft Wallet, and some of the personalization settings.

• Administrators could assign security to server data and resources for both internal users and business partners using the DMZ central account database. SQL Server, and Exchange Server could also take advantage of this domain security model.

A large entertainment company used an LDAP-based directory because they:

• Required that the infrastructure support many more accounts than can be currently handled by the Windows NT SAM.

• Required a standard Internet-based security scheme. Using Membership in Microsoft's Site Server product allowed them to build the directory based on the LDAP standard.

• Wanted to centralize all security behind the firewall.

How Some Sample Accounts Use Their DMZ

Companies choose to implement security based on their core business requirements, which means that they choose how they will communicate with business partners by following the requirements outlined in their security policy. This section looks at two rather different examples drawn from MCS cases. In the first, a Los Angeles-based company (referenced in Designing and Planning Internal Security ) preferred not to allow business partners direct access to the internal network, opting instead to place content outside the corporate network in the DMZ. In the second, the financial institution focused on in this article chose to allow certified business partners to gain direct access to internal servers using the Point-to-Point tunneling protocol. In the third, a large company known as Moby Inc. (referenced in SMS Infrastructure and Deployment Strategy: A Large Company Scenario) used server proxy to provide e-mail services over the Internet.

First Example—SSL and Basic Security

As part of their security policy the Los Angeles-based company decided that business partners would not be allowed direct access to the corporate network. All pertinent business partner information would be securely replicated to the DMZ.

Figure 9 shows the company's security setup: Basic and SSL on all secure sites. Each secure site would register with the InterNIC and obtain a domain name. Each would be assigned a TCP/IP address using the current class C range of addresses obtained from the Internet service provider. Their secure sites would have their domain names and IP addresses housed on a single server in the DMZ.

Using the Key Manager tool, the administrators created a key definition file that was submitted to Verisign. After about two weeks, Verisign returned the key and it was installed onto the server using the same Key Manager tool.

No direct access is allowed from the corporate network to the DMZ. All content is replicated using Site Server's Content Management service. This uses the standard replication model that includes development, staging and production replication servers (Figure 9).

Figure 9: : Basic and SSL security implementation at the Los Angeles-based company

Replication Overview

Content Management software transmits content across multiple servers. At the company, Content Management sends content to a staging server, where it goes through an approval process, after which changes are replicated to the DMZ on a daily schedule. The Los Angeles-based company's replication architecture is shown below.

Figure 10: : The company's content replication model

How the Process Works

Content developers replicate updated versions of their content to the staging servers. Content that meets required standards is copied using replication to the proper DMZ server. The firewall makes sure that security is maintained throughout the replication process.

Figure 10 shows a firewall that supports a series of internal servers replicating to all required DMZ servers (a many-to-many scenario). In other words, as long as the proper filters are created, any internal server can replicate to any external server. Not all firewalls support this model; research and testing can confirm what methods any individual firewall can support.

Firewalls

Content management can be configured to replicate content through firewalls by allowing outgoing communication over TCP port 507. The source and destination IP addresses will be known in advance as well. The only issue may be that the source TCP port is randomly selected, though most firewalls permit source port numbers over 1024 without restrictions.

Another way to accomplish that is to use the Proxy server. A properly configured client can replicate the content through the proxy server. For complete details see Knowledge Base article 189746, Title: How to Use Proxy Server with Content Replication System.

Issues

This design worked very well for the Los Angeles-based company, and they are still using it today. There are some issues however:

• Because all accounts are local to the secure server, all administration must take place on that box. And as more business partners require access, account creation and management has become difficult. The company has decided to move to an LDAP-based security scheme so they centralize security using the Membership database found in Microsoft Site Server.

• Some content is just too large and cannot be replicated. The company plans to address this by using Proxy Server's reverse or server proxy feature to securely present data externally.

• 128-bit SSL cannot be exported outside the United States and Canada and the State Department has not granted the Los Angeles-based company permission to use it on sites requiring international access, so these sites are configured with 40-bit encryption.

The next configuration shows a large financial institution that needed to allow business partners direct access to the corporate infrastructure

Second Example—Using the DMZ with PPTP

The financial institution's initial configuration for this new "connected" Internet network used Windows NT 4.0 SP4 as the Server operating system, configured a PPTP VPN Server in the DMZ, and set up a Microsoft 2.0 Proxy Server to protect the internal network. Also, the PPTP Server was configured with two network interface cards to create a multi-homed server architecture (See Figure 11).

Using Microsoft 2.0 Proxy Server

To understand the software relationships, think of MS Proxy as a network application while PPTP is a network protocol that requires routing support. Operationally, this means that every packet transmitted to and from the Proxy Server is either sourced or destined with the Proxy Server's IP address. By contrast, PPTP packets use the PPTP server as a router and may have other machines as both the source and destination addresses.

One of the challenges the financial institution faced was securely using both the Proxy Server and the PPTP Server. For security reasons, Proxy's user manual recommends turning off IP forwarding for the box on which proxy is installed. This presented a problem, however: PPTP requires IP forwarding because PPTP exposes the local end of the secure, encrypted tunnel as the virtual IP interface. With IP forwarding, Windows NT Server can forward packets correctly from the PPTP tunnel to the internal network. This was solved by installing Service Pack 3 (or higher) on the PPTP Server and enabling PPTP filtering across the Internet interface. PPTP filtering prevents Windows NT Server from accepting non-PPTP packets from the Internet interfaces. The Proxy Server was located internally, in its own network behind the choke router.

DHCP/WINS/DNS Considerations

Another challenge was to define how clients get assigned the proper name server addresses in a PPTP world. Using Figure 11 as a reference, you can follow the process:

1. Business partners obtain a PPP connection via RAS to the Internet.

2. Once connected, they launch a Virtual Private Network (VPN) connection that requests an IP address for the PPTP server from the ISP's DNS or that directly connects using the IP address of the outside PPTP server.

3. If multiple PPTP servers exist, the outside DNS completes the look-up and sends the address of one of the PPTP servers back to the RAS client in a round robin fashion.

   

   Figure 11: : PPTP configuration at the financial institution

4. RAS client opens a PPTP tunnel to one of the PPTP servers with its Windows NT account information. RAS/PPTP servers provide PPP configurations to remote clients using the IPCP protocol. The RAS/PPTP server can be configured to acquire IP address from a DHCP server on behalf of remote clients, but this is for IP addresses only. Alternatively, the RAS server can be configured with a static IP range borrowed from the local subnet. In either case, the remote clients will inherit the DNS and WINS configuration of the RAS/PPTP server itself. No IP mask or DNS domain name is passed to the client for remote connections.

5. If logon is successful, the RAS server passes name resolution information back to the client, which becomes a node on the corporate network.

6. At this point the client is an encrypted node on the financial institution's corporate network. All transactions take place over the encrypted PPTP tunnel.

7. All access to the Internet is now provided by the internal Proxy Servers and not the ISP. If clients wish to use their ISP's Internet access facilities, they must first drop their VPN connection.

An alternative: A large multi-national client found it necessary to host WINS servers specifically for remote users to prevent them from polluting the internal name space. The WINS servers pull replicas from the enterprise WINS servers, but do not replicate back into the WINS enterprise namespace. This prevents remote users from registering NetBIOS machine names that might conflict with internal naming standards.

Third Example—Using Server Proxy to Provide E-mail

The last example is of an account using server proxy to provide e-mail services over the Internet. The system administrator for Moby Inc. placed a Microsoft Exchange Server using the Internet Mail Connector (IMC) on the internal network behind Microsoft Proxy Server. With this configuration, an Exchange Server can provide Internet e-mail service by using the WinSock Proxy client and relying on features of Proxy Server 2.0 for protection. In addition, the Exchange Server computer will not require an additional registered Internet IP address.

The WinSock Proxy Client allows you to bind services or applications to the external network interface of the server computer running Microsoft Proxy Server, which makes them available to hosts on the Internet. The proxy server then listens for connections on their behalf.

For example, if you bind an internal SMTP/POP mail server to the Microsoft Proxy Server, mail clients or SMTP servers on the Internet can contact this mail server by connecting to the Proxy Server's Internet IP address. To remote computers on the Internet, these services appear to be running on the Proxy Server computer.

For information on configuring this option and a full list of well-known ports, see The Windows NT 4.0 Workstation Resource Kit ("Port Assignment for Registered Ports"). You can find this on TechNet.

More Information

Here's a list of other Microsoft Knowledge Base articles referenced in this article:

• 143475, Title: Windows NT System Key Permits Strong Encryption of the SAM.

• 189595, Title: PPTP Performance & Security Upgrade for WinNT 4.0 Release Notes

• 167029, Title: Resource and Master Domain DCs Do Not Load-Balance Validation

• 188855, Title: Security Privilege Must Be Enabled to View Security Event Log

• 161990, Title: How to Enable Strong Password Functionality in Windows NT

• 189746, Title: How to Use Proxy Server with Content Replication System

Microsoft TechNet
May 1999
Volume 7, Issue 5