- Shopping Bag ( 0 items )
Developers of Web-based applications get expert guidance for taking advantage of the sophisticated security features in Windows 2000 ? all in one comprehensive volume. This definitive guide provides a solid foundation in security theory and concepts, explains the key software design considerations for various categories and levels of security, and discusses ways to apply the appropriate security to mitigate risk. It also covers a range of security technologies, including NTLM authentication, Kerberos ...
Ships from: Chatham, NJ
Usually ships in 1-2 business days
Developers of Web-based applications get expert guidance for taking advantage of the sophisticated security features in Windows 2000 — all in one comprehensive volume. This definitive guide provides a solid foundation in security theory and concepts, explains the key software design considerations for various categories and levels of security, and discusses ways to apply the appropriate security to mitigate risk. It also covers a range of security technologies, including NTLM authentication, Kerberos authentication, SSL/TLS, CryptoAPI, ACLs, Active Directory services, certificates, and COM+ security.
Because IIS is a Windows 2000 system service and relies heavily on the security functionality in Windows 2000, it's assumed in this chapter that you have read Chapter 3, "Windows 2000 Security Overview," or have a good working knowledge of Windows 2000 security.
We'll cover the following topics in this chapter:
A New Feature of IIS 5-WebDAV Defined in RFC 2518 (http://www.ietf.org/rfc/rfc2518.txt), Web-based Distributed Authoring and Versioning (WebDAV) is a set of extensions to the HTTP 1.1 protocol that allows users to collaboratively edit and manage documents on Web servers. IIS 5, Microsoft Internet Explorer 5, and Microsoft Office 2000 support WebDAV.
You can find more information about WebDAV at the WebDAV Resources Web site (http://www.webdav.org) and at the Microsoft Developer Network (MSDN) Web site at http://msdn.microsoft.com/standards/WebDAV.asp.
In the anonymous access scenario, you don't care who the user is-users have access to all the resources you want them to have access to and no more. A good example of this is simple Web presence; most Web sites use anonymous access for their home page and their marketing or sales material. For example, the vast majority of www.microsoft.com uses anonymous access, including its sales, marketing, and developer-related materials.
Identified access is for Web areas where you are providing personalized services-you are not giving users access to private data known only to the company and the user. For example, you have the option to customize the home page of The Microsoft Network, www.msn.com, so that you can see your favorite stock quotes, news sources, leisure categories, and so on. This Web information is not confidential; it is customized.
In the authenticated access scenario, you need to know who the user is and the user has to have access to data that might be private, sensitive, or personal.
Notice that as you progress from anonymous to authenticated access there's a greater need to trust the user's credentials, as shown in Figure 5-1. For anonymous access, there's far less of a need to know who the user is; in fact, some might argue that you needn't care at all. For identified access, you need to know who the user is but only to the extent needed to provide a service or personalized but public content associated with that identity. With authenticated access, access is denied if you cannot confirm the credentials of the calling user.
Figure 5-1. Valuable information requires stronger credentials.
Each of these scenarios depends on the degree to which you trust the credentials supplied by the user. Anonymous access requires no credentials, identified access uses weak credentials, and authenticated access requires strong credentials. The strength of the credentials required is related to the value or sensitivity of the data you are providing. This is not to say that sales and marketing information available to all users is not valuable, but it is not as valuable as projected sales and marketing information internal to the organization.
In the example shown in Figure 5-2, the public area of the fictitious Exploration Air Web site requires no authentication (anonymous access), and the internal part of the site requires either HTTP 1.1 Digest authentication or Integrated Windows authentication, both of which are covered later in this chapter. The directories used to serve the content should be controlled by access control lists (ACLs) according to who the users are. Notice the use of the Deny access control entry (ACE) for the anonymous user account on the internal directory in the figure. If the administrator accidentally sets anonymous access as a valid authentication scheme, the anonymous account will still be denied access to the site content because of this ACL setting.
Web authentication protocol details Web authentication requires multiple interactions between the Web browser and the Web server. The general steps, as shown in Figure 5-3, are as follows:
Figure 5-3. Overview of Web authentication protocols data flow.
As shipped, the Web server in IIS 5 supports the following authentication .protocols:
Each of these is explained in detail in the following sections, so let's get started with the weakest of all the authentication schemes, anonymous access.
Anonymous access Technically, anonymous access is not an authentication scheme because the calling user is never asked to present credentials such as a password. However, Windows 2000 requires that all users authenticate themselves before they access any resource. To this end, IIS provides a default user account called IUSR_machinename as the Anonymous User account for anonymous access. All anonymous access is performed in the context of this account.
The account is defined at setup time with a very strong password-comprising uppercase and lowercase letters, numbers, and punctuation-and can be changed by the administrator later, but you are not obliged to use this and only this account for anonymous access. In fact, you can set different user accounts to be used in different parts of your Web space, such as at a Web server, virtual directory, directory, and file levels.
You can change the account in the IIS administrative tool like so:
You can also set the anonymous account programmatically by using Active Directory Services Interface (ADSI). Refer to Chapter 13, "Security Administration with ADSI, WMI, and COM+," for an example.
Failure to configure the account this way will compromise the security of your Web site because all anonymous access will operate in the context of the anonymous account. You have been warned!
Why change the Anonymous User account? It's useful to change the Anonymous User account if you host multiple Web sites. You can set up one Anonymous User account per Web site and set ACLs on the resources used by that Web site. For example, say you host www.SiteA.com and www.SiteB.com. You could then set the account for www.SiteA.com to be AnonA and the account for www.SiteB.com to be AnonB. The scenario would look like that in Figure 5-4.
Figure 5-4. Using different Anonymous User accounts for different Web sites. Privileges required when using the Anonymous User account There has been much confusion about the Anonymous User account and anonymous access in IIS relating to which privileges are required for the account. The question is, "Does the Anonymous User account need network logon or interactive logon privileges?"
The answer is, it depends!
If you have the Allow IIS To Control Password option checked in the Anonymous User Account dialog box, the account must have the Access This Computer From The Network privilege; otherwise, the Log On Locally privilege is required. IIS will log the account on using different techniques, depending on the Allow IIS To Control Password setting, which is our next topic.
The Allow IIS To Control Password setting If the Allow IIS To Control Password setting is checked, IIS calls a subauthenticator to validate the password. Subauthenticators are implemented as dynamic-link libraries (DLLs). A subauthentication DLL allows the authentication information stored in the Windows 2000 user account database (the Security Accounts Manager [SAM] or the Directory) to be augmented with other account validation capabilities.
For example, a server might supply a subauthentication DLL that validates a user's password via a different algorithm or specifies special workstation restrictions. All of this can be accomplished using subauthentication DLLs without sacrificing the use of the Windows 2000 user account database and its administration tools.
IIS 5 supplies a subauthentication DLL called IISSUBA.DLL to verify that the password is correct and then informs Windows 2000 that the password is valid so that the user can log on. Note that this functionality is available in Internet Information Server 4 also.
Accounts authenticated using a subauthentication DLL are always network logons and thus must have the Access This Computer From The Network privilege.
For more information about subauthentication DLLs, refer to the MSDN CDs or to http://msdn.microsoft.com.
If Allow IIS To Control Password is not checked, IIS will log the account on using the Windows API LogonUser and pass in the name of the Anonymous User account as well as the password, both of which are stored in the IIS configuration store, the metabase. Hence, if the control password setting is not set, the anonymous account must have the Log On Locally privilege.
Basic authentication Basic authentication is a simple authentication protocol defined as part of the HTTP 1.0 protocol defined in RFC 2617 (available at http://www.ietf.org/rfc/rfc2617.txt). Although virtually all Web servers and Web browsers support this protocol, it is extremely insecure because the password is in cleartext (also called plaintext), meaning it's passed over the network "in the clear." (Actually, it's not in the clear; it's base64-encoded, which is so trivial to decode that it might as well be cleartext!). Basic authentication works well through proxy servers and firewalls.
Basic authentication, as implemented in IIS 5, requires Windows 2000 accounts, either in the SAM or in Active Directory. This allows the Web site to use ACLs to determine access to resources. When a user connects to a Web site using Basic authentication, IIS gets the username and password from the HTTP Authorization header, calls the LogonUser API, and then impersonates the user.
By default, users accessing your Basic authentication Web server need the right to log on locally, although this can be changed in the IIS metabase by using ADSI. Refer to Chapter 13 for this method.
So, why change the logon type? The LogonUser API allows you to determine how the account is logged on. For example, the account can be logged on using log on locally, network, or batch privileges. Interactive logon is the default because it's the most flexible setting for most environments; it's not necessarily the most secure. Giving users this privilege allows them to log on to the Web server if they have physical access to the server.
The flexibility of a local logon is a legacy of Windows NT 4 and IIS 4. If an account is authenticated using NTLM or is logged on with network privileges, the account cannot access secured resources on another remote computer. While the issue of client delegation is resolved in Windows 2000 by using Kerberos, the only way to work around this in Windows NT with IIS 4 and Windows 2000 with IIS 5 in a non-Active Directory environment is to log the account on using log on locally privileges.
With log on locally privileges, information about the client, such as group membership and privileges, is stored so that the account can perform an offline logon if the server performing the logon cannot access a domain controller. The downside to storing this information is its effect on speed-it takes a certain amount of time to load and store the data.
Nevertheless, you can get the best of both worlds-speed and the ability to "hop" onto a remote server securely-by using the batch logon privilege. However, few user accounts have this privilege, so you must grant the privilege to the users in question.
The Network Logon With Cleartext password setting Just to make things a little more interesting, there's another option! Once you give a user the network privilege-again, the Access This Computer From The Network privilege-you can allow the user to hop off the IIS server and onto a remote server by using a flag in the call to LogonUser that is new to Windows 2000: the Network Logon With Cleartext password setting. This is a new implementation in Windows 2000 of the network logon, a way of using the network privilege when calling LogonUser. This capability can be set only by using ADSI, as we'll describe in Chapter 13...
|Ch. 1||Security 101||3|
|Why Build Secure Applications?||3|
|Why is Security Difficult?||4|
|The Golden Rules (and Some Others)||7|
|Threats, Safeguards, Vulnerabilities, and Attacks||12|
|Ch. 2||A Process for Building Secure Web Applications||15|
|A Security Design Process||16|
|Ch. 3||Windows 2000 Security Overview||43|
|The Impact of Active Directory||44|
|User Accounts and Groups||48|
|Domains and Workgroups||48|
|DOMAIN/Account Names and User Principal Names||49|
|Security Identifiers (SIDs)||53|
|Access Control Lists||57|
|Miscellaneous Windows 2000 Security Features||73|
|Ch. 4||Internet Explorer Security Overview||85|
|Code Safety and Malicious Content||87|
|SSL/TLS and Certificates||93|
|Ch. 5||Internet Information Services Security Overview||99|
|IIS Authorization - the Marriage of Windows 2000 Security and the Web||149|
|IIS Process Identities||154|
|Ch. 6||SQL Server Security Overview||163|
|Logins, Users, and Permissions||166|
|Network Security Options||169|
|SQL Server Logins||170|
|SQL Server Database Users||175|
|SQL Server Database Roles||178|
|SQL Server Permissions||181|
|Ch. 7||COM+Security Overview||191|
|Using DCOM over the Internet||212|
|Ch. 8||Practical Authentication and Authorization||217|
|Where to Perform Authentication and Authorization||218|
|Application vs. Operating System Identity Flow||222|
|Relative IIS Authentication Performance||222|
|Example Authentication and Authorization Scenarios||223|
|A Warning About Custom Authentication and Passwords||244|
|Ch. 9||Practical Privacy, Integrity, Auditing, and Nonrepudiation||247|
|Privacy and Integrity Overview||248|
|Where Privacy and Integrity Issues Occur||250|
|Mitigating Privacy and Integrity Threats||255|
|An Introduction to Nonrepudiation||279|
|Ch. 10||Building a Secure Solution||287|
|Putting Together a Secure Solution||289|
|Speed vs. Security Trade-Offs||303|
|Ch. 11||Troubleshooting Secure Solutions||309|
|Tools and Logs Available to You||309|
|The Art of Reading a Windows 2000 Logon Event||315|
|The Art of Reading an IIS Log Entry||321|
|Problems and Solutions||322|
|Ch. 12||Securing Against Attack||337|
|Why People Attack Web Servers||338|
|How People Attack Web Servers||339|
|Some Common Attacks||353|
|How to Detect Whether You're Under Attack||362|
|User Input Attacks||375|
|What to Do If You're Under Attack||383|
|Staying Up-to-Date on Security Issues||384|
|A Final Thought||385|
|Ch. 13||Security Administration with ADSI, WMI, and COM+||389|
|What is WMI?||390|
|What is ADSI?||390|
|Example Management and Security Configuration Code||391|
|Ch. 14||An Introduction to Kerberos Authentication in Windows 2000||407|
|What is Kerberos Authentication?||408|
|How Kerberos Authentication Works||410|
|Kerberos Ticket Flow||414|
|Ch. 15||An Introduction to Cryptography and Certificates in Windows 2000||423|
|The Fundamentals of Cryptography||424|
|The Basics of Certificates||434|
|Cryptography and Certificates in Windows 2000||450|
|App. A||Windows 2000 Well-Known SIDs|
|App. B||Strong Passwords|
|App. C||Windows 2000 Default Ports|
|App. D||Internet Information Services Authentication Summary|
|App. E||Security-Related IIS Server Variables|
|App. F||Secure Web Server Checklist|
Posted October 19, 2000
I've read many books about computer and network security, and this blows away all of them. It's easy to read, extremely pragmatic and, as far as I know, it is the ONLY BOOK that discusses how to design, build and troubleshoot end-to-end security. The degree to which Michael discusses 'real-life' security issues is incredible, there is so much information in this book, and I thought I knew how to build secure solutions. You gotta buy this book, it'll save you time and consulting feesWas this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted August 22, 2000
Posted August 7, 2000
This title covers in a very readable form many areas of Windows 2000 security. There are also a number of useful tools on the CD. For example, a C/C++ common buffer-overrun problem API analyzer. This along with Keith Brown's Programming Windows 2000 Security are 'must buys.'Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.