Dr. Tom Shinder's ISA Server and Beyond with CDROM

[email protected] With more than 1,500,000 copies of our MCSE, MCSD, CompTIA, and Cisco study guides in print, we ...

Author: Thomas W. Shinder

16 downloads 1061 Views 35MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

[email protected] With more than 1,500,000 copies of our MCSE, MCSD, CompTIA, and Cisco study guides in print, we continue to look for ways we can better serve the information needs of our readers. One way we do that is by listening. Readers like yourself have been telling us they want an Internet-based service that would extend and enhance the value of our books. Based on reader feedback and our own strategic plan, we have created a Web site that we hope will exceed your expectations. [email protected] is an interactive treasure trove of useful information focusing on our book topics and related technologies. The site offers the following features: ■ One-year warranty against content obsolescence due to vendor product upgrades. You can access online updates for any affected chapters. ■ “Ask the Author” customer query forms that enable you to post questions to our authors and editors. ■ Exclusive monthly mailings in which our experts provide answers to reader queries and clear explanations of complex material. ■ Regularly updated links to sites specially selected by our editors for readers desiring additional reliable information on key topics. Best of all, the book you’re now holding is your key to this amazing site. Just go to www.syngress.com/solutions, and keep this book handy when you register to verify your purchase. Thank you for giving us the opportunity to serve your needs. And be sure to let us know if there’s anything else we can do to help you get the maximum value from your investment. We’re listening.

www.syngress.com/solutions

Ultimate CD-ROM Collections Now Available!

Incredible Value for Only $99.99 each Receive the CD of your choice with seven books in PDF format. You would pay over $350 for these books in hard copy format. Ultimate Cisco CD Managing Cisco Network Security (List Price: $59.95) Building Cisco Networks for Windows 2000 (List Price: $59.95) Configuring Cisco AVVID (List Price: $59.95) Administering Cisco QoS for IP Networks (List Price: $59.95) Building Cisco Remote Access Networks (List Price: $49.95) Configuring Cisco Voice Over IP (List Price: $59.95) Cisco AVVID and IP Telephony Design & Implementation (List Price: $69.95)

Ultimate Windows 2000 CD Managing Active Directory for Windows 2000 Server (List Price: $49.95) Managing Windows 2000 Network Services (List Price: $49.95) Configuring Windows 2000 Server Security (List Price: $49.95) Windows 2000 Server System Administration Handbook (List Price: $49.95) Deploying Windows 2000 with Support Tools (List Price: $49.95) Windows 2000 Configuration Wizards (List Price: $39.95) Troubleshooting Windows 2000 TCP/IP (List Price: $49.95)

Ultimate .NET CD BizTalk Server 2000 Developer’s Guide for .NET (List Price: $49.95) XML .NET Developer’s Guide (List Price: $49.95) VB .NET Developer’s Guide (List Price: $49.95) ASP .NET Web Developer’s Guide (List Price: $49.95) C# .NET Web Developer’s Guide (List Price: $49.95) .NET Mobile Web Developer’s Guide (List Price: $49.95) Designing SQL Server 2000 Databases for .NET Enterprise Servers (List Price: $49.95)

Ultimate Network Security CD Hack Proofing Your Network (List Price: $49.95) Hack Proofing Windows 2000 Server (List Price: $49.95) Hack Proofing Linux: A Guide to Open Source Security (List Price: $49.95) Hack Proofing Sun Solaris (List Price: $49.95) Hack Proofing Your E-Commerce Site (List Price: $49.95) Hack Proofing Your Web Applications (List Price $49.95) Managing Cisco Network Security: Building Rock Solid Networks (List Price $59.95)

Visit www.syngress.com for details.

1 YEAR UPGRADE BUYER PROTECTION PLAN

Dr. Tom Shinder’s

ISA Server Beyond and

Real World Security Solutions for Microsoft Enterprise Networks

Thomas W. Shinder, M.D. Debra Littlejohn Shinder Martin Grasdal

Technical Editor

Syngress Publishing, Inc., the author(s), and any person or firm involved in the writing, editing, or production (collectively “Makers”) of this book (“the Work”) do not guarantee or warrant the results to be obtained from the Work. There is no guarantee of any kind, expressed or implied, regarding the Work or its contents.The Work is sold AS IS and WITHOUT WARRANTY. You may have other legal rights, which vary from state to state. In no event will Makers be liable to you for damages, including any loss of profits, lost savings, or other incidental or consequential damages arising out from the Work or its contents. Because some states do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation may not apply to you. You should always use reasonable care, including backup and other appropriate precautions, when working with computers, networks, data, and files. Syngress Media®, Syngress®,“Career Advancement Through Skill Enhancement®,” and “Ask the Author UPDATE®,” are registered trademarks of Syngress Publishing, Inc. “Mission Critical™,”“Hack Proofing®,” and “The Only Way to Stop a Hacker is to Think Like One™” are trademarks of Syngress Publishing, Inc. Brands and product names mentioned in this book are trademarks or service marks of their respective companies. KEY 001 002 003 004 005 006 007 008 009 010

SERIAL NUMBER KQMCTFTRCA 522CSMBG22 A2CY67NGP9 NR57JKGLD8 T3GF6NV67S XDE4GHK7Z2 5T3BY7P88S W4CFD65T9G TFV89V6X5S HUN45F8AS4

PUBLISHED BY Syngress Publishing, Inc. 800 Hingham Street Rockland, MA 02370 Dr. Tom Shinder’s ISA Server and Beyond: Real World Security Solutions for Microsoft Enterprise Networks

Copyright © 2002 by Syngress Publishing, Inc. All rights reserved. Printed in the United States of America. Except as permitted under the Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher, with the exception that the program listings may be entered, stored, and executed in a computer system, but they may not be reproduced for publication. Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 ISBN: 1-931836-66-3 Technical Editor: Martin Grasdal Cover Designer: Michael Kavish Acquisitions Editor: Andrew Williams Page Layout and Art by: Shannon Tozier Developmental Editor: Jonathan Babcock Copy Editor: Mary Millhollon, Beth Robers CD Production: Michael Donovan Indexer: Rich Carlson Distributed by Publishers Group West in the United States and Jaguar Book Group in Canada.

Authors Thomas W. Shinder, M.D. (MCSE) is a computing industry veteran who has worked as a trainer, writer, and a consultant for Fortune 500 companies including FINA Oil, Lucent Technologies, and Sealand Container Corporation.Tom was Series Editor for the Syngress/Osborne series of Windows 2000 certification study guides and is author of the best selling book Configuring ISA Server 2000: Building Firewalls for Windows 2000 (Syngress Publishing, ISBN: 1-928994-29-6).Tom is the editor of the Brainbuzz.com Win2k News newsletter and is a regular contributor to TechProGuild. He is also a content editor, contributor, and moderator for the World’s leading site on ISA Server 2000, www.isaserver.org. Microsoft recognized Tom’s leadership in the ISA Server community and awarded him their Most Valued Professional (MVP) award for the first time in December of 2001. Debra Littlejohn Shinder (MCSE) is author of Scene of the Cybercrime: Computer Forensics Handbook (Syngress Publishing, ISBN: 1-931836-65-5), co-author of Configuring ISA Server 2000: Building Firewalls for Windows 2000 (Syngress Publishing, ISBN: 1-928994-29-6) and Troubleshooting Windows 2000 TCP/IP (Syngress Publishing, ISBN: 1-928994-11-3), as well as contributor to numerous other technical books. Along with her husband, Dr. Thomas W. Shinder, Deb does network consulting in the Dallas-Ft.Worth area, designs Web sites for businesses, municipalities and non-profit organizations, and teaches in the Dallas County Community College District’s technical training programs. As a former police officer and Police Academy instructor, she specializes in computer/network security and forensics. Deb has written hundreds of articles for Web and print publications such as TechRepublic, CNET, Swynk.com, BrainBuzz.com, and WinXP News. She has also written numerous online courses for DigitalThink, Inc. and prepared curricula for classroom instruction. She has contributed to Microsoft’s TechNet, and speaks at conferences such as the BlackHat security briefings and Certification Expo. She edits the A+ weekly newsletter for CramSession and writes a weekly feature for the Net Admin News. Deb has been writing since she finished her first (still unpublished) novel in ninth grade. She edited her high school and college newspapers and wrote and edited newsletters for city employees and police associations. Prior to v

entering the tech field, she had articles published in law enforcement and self-help psychology publications. She is a member of the IEEE’s IPv6 Working Group and has written and tech edited questions for various certification practice exams.

Contributor Mark Burnett is an independent security consultant and freelance writer who specializes in securing IIS. He is co-author of Maximum Windows Security and Special OPS: Host and Network Security for Microsoft, UNIX, and Oracle (Syngress Publishing, ISBN: 1-931836-69-8). Mark is a regular contributor to many security-related magazines, newsletters, and Web publications. As editor of www.iissecurity.net, Mark shares his own unique research as well as that from security researchers around the globe.

Technical Editor and Contributor Martin Grasdal (MCSE+I, MCSE/W2K, MCT, CISSP, CTT, A+), Director of Web Sites and CTO at Brainbuzz.com, has worked in the computer industry for over nine years. He has been an MCT since 1995 and an MCSE since 1996. His training and networking experience covers a broad range of products, including NetWare, Lotus Notes,Windows NT and 2000, Exchange Server, IIS, Proxy Server, and ISA Server. Martin also works actively as a consultant. His recent consulting experience includes contract work for Microsoft as a Technical Contributor to the MCP Program on projects related to server technologies. Martin has served as Technical Editor for several Syngress books, including Configuring ISA Server 2000: Building Firewalls for Windows 2000 (ISBN: 1-928994-29-6), and Configuring and Troubleshooting Windows XP Professional (ISBN: 1-928994-80-6). Martin lives in Edmonton, Alberta, Canada with his wife, Cathy, and their two sons. vi

Contents About the CD-ROM

xiv

Foreword and Acknowledgements

xv

Chapter 1 Defending the Network with ISA Server—and Beyond Introduction ISA Server Overview The Increasing Importance of Security ISA Server Authentication Installing ISA Server Planning and Design Issues Installing ISA Server in a Stand-Alone Configuration Upgrading a Stand-Alone ISA Server to an Array Member Installing ISA Server on a Domain Controller Selecting the ISA Server Client Getting Started with ISA Server Installing Service Pack 1 What’s Included in SP1 Determining the Version of SP1 Installed Downloading and Installing the Service Pack on the ISA Server Upgrading Client Computers to SP1 Service Pack 1 Issues Supporting Network Design Using Application Center 2000 with ISA Server ISA Server and Windows .NET Third-Party Software Add-Ons for ISA Server ISA Server Certification Beyond ISA Server Summary, Defensive Tactics Fast Track, Frequently Asked Questions

1 2 3 3 11 15 15 30 37 41 42 46 51 52 53 54 56 56 57 58 58 59 60 61 63

Chapter 2 Defense Plan 1: The Trihomed DMZ Introduction Configuring a Trihomed DMZ The Network Layout ISA Router Configuring the ISA Server Ping Testing the Connections Publishing DMZ SMTP Servers Publishing a DMZ SMTP Mail Relay Server Publishing a Web Server Publishing an FTP Server on a Trihomed DMZ Segment

69 70 70 72 73 74 75 77 87 90 99 99 vii

viii

Contents

How FTP Works Using Packet Filters to Publish the PORT Mode FTP Server Using Packet Filters to Publish the PASV Mode FTP Server External Network Clients Cannot Use the DMZ Interface to Connect to the Internal Network Summary, Defensive Tactics Fast Track, Frequently Asked Questions

100 105 107

Chapter 3 Defense Plan 2: The Back-to-Back DMZ Introduction Configuring a Private Address Back-to-Back DMZ Allowing Inbound VPN Connections through a Back-to-Back ISA Server DMZ Configuring a Public Address Back-to-Back DMZ Outbound Access for Internal Network Clients through a Public Address DMZ Inbound VPN Access through the Public Address DMZ Publishing Servers on the Private Address DMZ on the External ISA Server Summary, Defensive Tactics Fast Track, Frequently Asked Questions

117 118 118

Chapter 4 Defense Plan 3: The Internal “Pseudo” DMZ Introduction Using TCP/IP Filtering (TCP/IP Security) Configuring TCP/IP Filtering Summary of TCP/IP Filtering Using Routing and Remote Access Service (RRAS) Packet Filters Configuring RRAS Packet Filters Using IPSec Policies Elements of an IPSec Policy Creating IPSec Policies to Support Communications between the LATDMZ and the Internal Network Summary, Defensive Tactics Fast Track, Frequently Asked Questions

211 212 214 215 219 219 221 235 235

Chapter 5 Defense Plan 4: Advanced Server Publishing Introduction Disabling Socket Pooling Disabling Web and FTP Service Socket Pooling Disabling SMTP and NNTP Service Socket Pooling Disabling IIS Services on the ISA Server Server Publishing Publishing Terminal Services on the Internal Network Publishing Terminal Services on the ISA Server Publishing Terminal Services on Both the ISA Server and Internal Network Publishing TSAC Sites Publishing FTP Servers on the Internal Network Publishing FTP Servers Co-Located on the ISA Server Using Web Publishing Rules to Allow Secure FTP Access Publishing HTTP and HTTPS (SSL)

255 256 260 262 263 264 265 266 271

110 112

173 192 195 201 203 205

240 250

274 275 285 295 304

Contents

ix

Servers with Server Publishing Rules Publishing pcAnywhere on the Internal Network Web Publishing Incoming Web Request Listeners Destination Sets Public DNS Entries Private DNS Entries Terminating an SSL Connection at the ISA Server Bridging SSL Connections Secure FTP Connections Using SSL Publishing a Certificate Server Summary, Defensive Tactics Fast Track, Frequently Asked Questions

309 313 316 317 317 318 319 321 337 347 349 352

Chapter 6 Defense Plan 5: Protecting Mail Services Introduction Configuring Mail Services on the ISA Server Computer Publishing the IIS SMTP Service on the ISA Server Message Screener on the ISA Server Publishing Exchange Server on the ISA Server Publishing Outlook Web Access on the ISA Server Message Screener on the ISA Server and Exchange Server Configuring Mail Services on the Internal Network Publishing Exchange Server on the Internal Network Exchange RPC Publishing Publishing Outlook Web Access on the Internal Network Exchange Server Message Screener on the Internal Network Exchange Server GFI’s Mail Security and Mail Essentials for SMTP Servers MailSecurity Versions Installing MailSecurity for SMTP Gateways Configuring MailSecurity Summary, Defensive Tactics Fast Track, Frequently Asked Questions

357 358 359 360 367 371 401 411 417 417 420 428 429 433 434 434 437 443

Chapter 7 Understanding Windows Default Access Control Settings Introduction Overview of Security Groups and Access Control The Administrators Group The Users Group The Power Users Group Configuring Security during Windows 2000 Setup Default File System and Registry Permissions Default User Rights Default Group Membership Summary, Defensive Tactics Fast Track, Frequently Asked Questions

447 448 448 450 451 452 453 457 472 479 482

Chapter 8 Using the Security Configuration Tool Set Introduction Security Configuration Tool Set

487 488 488

x

Contents

Security Configuration Tool Set Components Security Configurations Security Configuration and Analysis Database Security Configuration and Analysis Areas Security Configuration Tool Set User Interfaces Configuring Security Account Policies Local Policies Event Log Restricted Groups Registry Security File System Security System Services Security Analyzing Security Account and Local Policies Restricted Group Management Registry Security File System Security System Services Security Group Policy Integration Security Configuration in Group Policy Objects Additional Security Policies Summary, Defensive Tactics Fast Track, Frequently Asked Questions

488 492 492 494 496 502 502 504 510 512 514 516 519 521 522 522 523 523 524 524 525 527 528

Chapter 9 Defending Your Data with the Encrypting File System 533 Introduction 534 The Role of EFS in a Network Security Plan 535 Using the Encrypting File System 536 Encryption Fundamentals 537 How EFS Works 539 User Operations 541 Encrypting a File or Folder 542 Accessing an Encrypted File 545 Copying an Encrypted File 546 Preventing Files from Being Encrypted on a Server 547 Moving or Renaming an Encrypted File 547 Sharing an Encrypted File (in Windows XP/.NET) 548 Decrypting a File 549 Using the Cipher Utility 550 Encrypting a Directory 552 Employing Recovery Operations 552 EFS Architecture 561 EFS Components 561 The Encryption Process 564 The EFS File Information 567 The Decryption Process 569 Summary, Defensive Tactics Fast Track, Frequently Asked Questions 571

Contents

xi

Chapter 10 Protecting Data in Transit with IP Security Introduction Network Encroachment Methodologies Snooping Spoofing Password Compromise Denial-of-Service Attacks Man-in-the-Middle Attacks Application-Directed Attacks Compromised Key Attacks IPSec Architecture Overview of IPSec Cryptographic Services IPSec Security Services Security Associations and IPSec Key Management Procedures Deploying Windows IP Security Evaluating Information Determining Required Security Levels Building Security Policies with Customized IPSec Consoles Flexible Security Policies Flexible Negotiation Policies Filters Creating a Security Policy Summary, Defensive Tactics Fast Track, Frequently Asked Questions

577 578 579 579 580 581 582 584 584 585 586 587 592 594 596 596 598 599 601 606 608 609 623

Chapter 11 Authenticating Users with Smart Cards Introduction Understanding Smart Card Technology “Under the Hood” of the Smart Card Understanding Smart Card Authentication Smart Card Interoperability ISO 7816, EMV, and GSM The PC/SC Workgroup GlobalPlatform Microsoft’s Smart Card Support Smart Card Components Service Providers Enhanced Solutions Client Authentication Public Key Interactive Logon Secure E-Mail Summary, Defensive Tactics Fast Track, Frequently Asked Questions

627 628 629 629 630 631 632 632 632 633 636 636 641 641 642 648 650

Chapter 12 Creating a Public Key Infrastructure with Certificate Services Introduction PKI Concepts Public Key Cryptography Public Key Functionality

655 656 657 657 659

xii

Contents

Protecting and Trusting Cryptographic Keys Windows 2000 PKI Components Certification Authorities Certificate Hierarchies Deploying an Enterprise CA Trust in Multiple CA Hierarchies Installing a Windows 2000 PKI Enabling Domain Clients Generating Keys Key Recovery Certificate Enrollment Renewal Using Keys and Certificates Roaming Revocation Trust Public Key Security Policy in Windows 2000 Trusted CA Roots Certificate Enrollment and Renewal Smart Card Logon Applications Overview Web Security Secure E-Mail Digitally Signed Content Encrypting File System Smart-Card Logon IP Security Preparing to Implement the Windows 2000 PKI Backing Up and Restoring Certificate Services Summary, Defensive Tactics Fast Track, Frequently Asked Questions Chapter 13 Keeping Your IIS Web Servers Safe Introduction Preparing the OS Adding and Removing Components Preparing the File System Installing IIS Locking Down COM and Database Access Hardening TCP/IP Securing the Internet Information Service Running the IIS Lockdown Wizard Securing IIS Global Settings Securing the Default and Administration Web Sites Disabling Internet Printing Disabling or Securing the FrontPage Server Extensions Configuring URLScan Securing Web Sites Building a Directory Structure

664 669 671 672 673 674 675 679 679 680 684 694 694 695 695 698 701 702 706 709 709 709 710 711 712 712 713 713 715 720 727 728 729 729 729 730 733 738 738 739 743 744 746 747 748 753 753

Contents

Setting Master WWW Properties Securing by Content Type Authenticating Users Using Anonymous Authentication Using Basic Authentication Using Digest Authentication Using Integrated Windows Authentication Using Client Certificate Mapping Summary, Defensive Tactics Fast Track, Frequently Asked Questions

xiii

754 760 765 766 766 767 768 769 770

Appendix A Defending Your 802.11 Wireless Network Introduction Understanding Wireless Networks Wireless Communication in a Wireless Network Wireless Local Area Networks 802.11 Wireless Network Topology and Services Understanding Wireless Security Performing a Security Analysis Common Exploits of Wireless Networks Using a Layered Approach Understanding and Configuring Service Set Identifiers Wired Equivalent Privacy Protocol (WEP) MAC Filtering and Authorization 802.1X RADIUS Authentication Additional Security Measures for Wireless Networks Summary

773 774 774 775 779 784 787 788 790 794 795 798 805 807 823 827

Index

829

About the CD-ROM The CD-ROM that accompanies this book contains: ■

Transcender’s Installing, Configuring, and Administering Microsoft ISA Server 2000 Exam, ISA-CERT Version 1.0.

■

30-day evaluation copy of VMware Workstation 3.2 for Windows. VMware Workstation 3.2 for Windows Copyright 1998-2002,VMware, Inc. All Rights Reserved. Software protected by U.S. patent No. 6,397,242 and patents pending.VMware is a trademark of VMware, Inc. Visit www.vmware.com to obtain your 30-day evaluation license and key. If you do not have Internet access, e-mail [email protected] for your license and key.

■

E-book of Dr.Tom Shinder’s ISA Server and Beyond.

■

E-book of Hack Proofing Your Network First Edition.

xiv

Foreword and Acknowledgements We first came up with the idea of an ISA Server and Beyond book almost a year ago. Soon after the release of our best selling book Configuring ISA Server: Building Firewalls for Windows 2000, we realized that our work wasn’t complete.While we felt we did a good job of covering the basics of ISA Server and how to get it to work, there wasn’t enough material on the most sophisticated and complex configurations. The ISA Server community has grown enormously since we finished our first book on ISA Server. At the time of this writing, ISAServer.org has over 10,000 members and over 65,000 unique visitors per month generating over a million page views. Many visitors to the ISAServer.org site have read our first ISA Server book, and they want to learn more about how to perfect more advanced configurations. The first part of this book covers the least understood and most under documented ISA Server configurations.We discuss the details of how to configure various DMZ topologies, from the trihomed DMZ to the back to back DMZ to the completely undocumented LAT-based DMZ. DMZs are the cornerstone of a highly secure Internet publishing and internal network security scheme and the proper configuration of ISA Server DMZs can go a long way toward securing your internal network.We also cover advanced topics in Web and Server Publishing. Making servers located behind the ISA Server available to the Internet is one of the most popular ISA Server features. Unfortunately, we were not able to cover the intricacies of Web and Server Publishing in the first ISA Server book.This book fills that gap and provides you with detailed, and (until now) undocumented methods you can use to publish virtually any type of server to the Internet. Dozens of pages are dedicated to publishing Exchange Server services and Outlook Web Access. In no other location will you find the wealth of new and detailed information on ISA Server publishing that you’ll find in these pages. In the second half of this book, we take you beyond ISA Server and into the realm of general network and Windows 2000 security. Network security has become the bellwether of our age, and no book on firewall security can be worth its salt without some coverage of the services that the firewall is designed to secure.You’ll learn about default Windows 2000 permissions, IIS security, EFS, wireless security, and IPSec.When you pair the information contained in these chapters with what you learn about ISA Server, you’ll be assured that you have a powerful armamentarium to defend your network. You’ll notice that I make liberal use of VMware in the first part of this book.While I would have liked to show you the configuration details on any one of the number of production networks we’ve set up, it would not be wise from a security point of view to expose our customer’s network screenshots in such a widely distributed security book. VMware provides a perfect platform for testing a tremendous variety of ISA Server configuration scenarios. Most of the time we can use VMware to create routed virtual xv

xvi

Foreword

networks of ISA Servers,Web servers, mail servers, and clients to test our designs. I guarantee that the practice you gain while setting up your ISA Server scenarios in VMware will pay off handsomely by giving you valuable experience and insights that you would never otherwise have realized.We’ve included a demonstration version of VMware Workstation 3.2 for Windows on the CD that accompanies this book. I did not write this entire book alone, and without the help of many people, this book never would have seen the light of day. My lovely wife, Deb Shinder, wrote Chapter 1 and rewrote and made comprehensive revisions and enhancements to the material in Chapters 7, 9, 10, 11, and 12.This book would read like just another Windows security book if it weren’t for Debi’s prodigious talents. I could never have finished this book, or have done anything else of value in my life without her. I dedicate this book and its success to her. Extra special thanks go to Andrew Williams. Andrew kept pressing me to get this book done, and without his gentle cattle prodding, this book would have been finished sometime in the year 2005. Jon Babcock made sure that everything came out right, and that I submitted Visio files instead of .gifs! My dear friend Martin Grasdal wrote the seminal piece on Wireless networking in the second half of this book, as well as performing a technical edit on all chapters in this book. Martin is one of the most knowledgeable network engineers I’ve ever had the pleasure to know, and it has been our good luck to benefit from his knowledge and experience in both the first ISA Server book and this book. Mark Burnett wrote the chapter on IIS security. Mark is one of the stars of IIS security, and we are especially pleased to have his expert assistance and contributions to this book. IIS security is paramount for all of us who want to use ISA Server to publish our IIS Web sites. I think you’ll get quite a bit of useful information from his chapter. There are literally thousands of others who have contributed to this book. All the participants of the Microsoft newsgroups, ISAServer.org Web boards, and ISAServer.org mailing list have contributed to the ISA Server knowledge base. Key players on the ISA Server team at Microsoft have also contributed greatly to what we know about ISA Server today. It’s impossible to list them all by name, but there are a few who I must mention because of their enormous influence: Joern Wettern for his unique insight into ISA Server; Zach Gutt and Ari Fruchter for being the best Microsoft managers I’ve ever had the pleasure to work with; Ronald Beekelaar for being such a computer genius and ISA Server junkie; Steve Riley for reminding me of myself when I was a 20 year old long hair Berkeley undergraduate (and for being a penultimate ISA Server guru); Craig Nelson for being a really relaxed dude and “the VPN man”; Steven Pouseele for his tireless efforts at educating the masses (and me) at ISAServer.org; and most of all, Jim Harrison, for his limitless energy in supporting the ISA Server community and for his unusually good sense of humor. Special mention goes to the owner and master of ISAServer.org— Stephen Chetcuti.The ISA Server community would be a much smaller and much sadder place if not for his dedication and tireless commitment to ISAServer.org. —Thomas W. Shinder, M.D. www.isaserver.org/shinder

Chapter 1

Defending the Network with ISA Server—and Beyond

Defensive Tactics in this Chapter: ■

ISA Server Overview

■

Installing ISA Server

■

Getting Started with ISA Server

■

Installing Service Pack 1

■

Supporting Network Design

■

ISA Server Certification

■

Beyond ISA Server

; Summary ; Defensive Tactics Fast Track ; Frequently Asked Questions 1

2

Chapter 1 • Defending the Network with ISA Server—and Beyond

Introduction Our first ISA Server book, Configuring ISA Server 2000, was written while we were still struggling to master a completely new piece of software, one that was very different in features, functionality, and complexity from its predecessor, Microsoft Proxy Server 2.0. We were working with beta releases during much of the writing, and then revising the material to address changes in the final release. In the year and a half since that book came out, we’ve gotten to know ISA Server much more intimately.Through working with it on a daily basis on our network, assisting and supporting others in the “real world” and via ISA newsgroups, mailing lists, conferences, and the www.isaserver.org Web site, we’ve come to know its quirks, peculiarities, and limitations, and learned some tweaks and tricks that will make it work better. We have also come to understand, even more than before, that ISA or any other firewall solution is only one part (albeit an important one) of a comprehensive network security plan.The importance of multilayer security becomes more evident every day, as hackers and attackers work industriously to find ways through the barriers we set up. No single product can provide full protection for your network’s data and integrity, regardless of how good it is. This book is the natural follow-up to the first. Although it can stand on its own for those who have some experience using ISA Server, we recommend that anyone new to the product read Configuring ISA Server 2000 first, as this book will not cover in detail the basic issues that were addressed there.This book will delve into issues that did not exist when we wrote the first (such as ISA Service Pack 1 and using ISA with Windows .NET servers) and advanced configuration and network design issues (such as using ISA Server in different types of DMZs/perimeter networks, advanced server publishing techniques involving terminal server and Exchange server, and defending your mail services with ISA Server).

NOTE The material in the next three sections of this chapter—ISA Server Overview, Installing ISA Server, and Getting Started with ISA Server—contain material that is intended for new ISA users. This is the only area of information in this book that will overlap with that of the previous book. If you already have experience with ISA, you might want to skip ahead to the section entitled Installing and Using Service Pack 1, where the all-new material begins. The remainder of the book assumes that you already have a thorough understanding of ISA Server features and functions.

This book also goes beyond ISA Server, examining other parts of your multilayered security plan.We discuss how to use Windows security features (such as the Security www.syngress.com

Defending the Network with ISA Server—and Beyond • Chapter 1

Configuration Toolset, the Encrypting File System, IPSec, and IIS security) and how to implement smart card authentication and secure wireless networks. We hope this book will provide additional guidance to network professionals who are using ISA Server in complex network situations, until it’s time to take the next step beyond ISA Server 2000: the next generation of ISA, which is code named Stingray and is in beta testing at the time of this writing.

ISA Server Overview Microsoft’s Internet Security and Acceleration (ISA) Server replaced Microsoft Proxy Server 2.0, providing full-fledged firewall functionality for a much more robust security solution, along with improved caching/Web performance features. In the current security-conscious business climate (made more so by the events of September 11, 2001 and subsequent speculation that terrorists might be planning attacks on the cyberspace infrastructure), the security aspect has naturally drawn the most attention.

The Increasing Importance of Security As we progress into the twenty-first century, most companies and individuals who use computers have those systems connected to the global Internet at least part of the time. Even at the consumer level, 24/7 connectivity is becoming the norm as DSL, cable modem, and satellite technologies become more widely available and increasingly easier to set up and use.This gives computer users access to a tremendous wealth of information that they didn’t have before, and makes many of their jobs easier—but it also creates vulnerabilities. Logic dictates that if the users of your local network are able to access resources on computers all over the world, users of some of those computers might also be able to access yours.The connection is two way, and if you don’t take steps to protect your internal network from intruders, it will be easy for a moderately knowledgeable hacker to read the files stored on your network servers, copy confidential data, and even implant viruses or erase your hard disks. However, it’s not only confidentiality of information that is at stake. Some network administrators might not realize that security can be a concern even if the data on your network is not of a “top secret” nature.The integrity of your data is also crucial. A security solution focuses on keeping outsiders from accessing data that is private and ensuring that important data is not destroyed or changed. Security threats come in many “flavors,” but can be broadly divided into two categories: external threats and internal threats. For example, a Denial of Service (DoS) attack perpetuated by a hacker at a remote location is an external security threat. Accidental deletion of important files by a company employee onsite is an internal threat. At first glance, it might seem that ISA Server only protects you from external www.syngress.com

3

4


threats—those that attempt to penetrate your LAN from the Internet. However, ISA also allows you to restrict outgoing network traffic, and in that way offers protection from some (although certainly not all) internal security threats as well.

The Firewall Solution ISA Server performs the functions of a full-featured dedicated firewall. A firewall provides a much higher level of security than a proxy server (which just “stands in” for the local computers, hiding them from view on the global network). Firewalls are specifically designed to control access, preventing unauthorized data from entering the network and restricting how and what type of data can be sent out. A network firewall acts as a barrier to prevent “bad data”—whether that be virus code or simply messages to or from unauthorized systems—from spreading from the outside network (usually the Internet) to the internal network, and also to prevent packets of a particular type or to or from a particular user or computer from spreading from the LAN to the outside network. Firewalls can be implemented in different ways.Vendors offer a wide variety of firewall software packages that run on your gateway computer. Many vendors provide hardware firewall solutions, in which a separate device incorporates a computer system that runs special proprietary firewall software. Either way, the firewall program (or set of programs) generally works in conjunction with a router program or a Network Address Translation (NAT) program.These programs forward packets to the appropriate destination once they have been authorized to enter or leave the network.The firewall must also work with a proxy, which makes requests for Internet data and services on behalf of the internal computers. ISA Server combines these components—proxy, NAT, and firewall—into one package.This makes it easier to deploy and administer than separate software programs and/or hardware devices.

ISA Server Features In addition to its multilayer firewall functionality (packet filtering, circuit filtering, and application filtering), ISA Server offers such security and performance features as: ■

Integrated virtual private networking (VPN) ISA Server can be used to set up either a remote access VPN between a client and gateway, or a multiple member VPN tunnel from server to server.

■

Integration with Active Directory ISA access policies and server configuration information are integrated with the Windows 2000 Active Directory for easier and more secure administration.

www.syngress.com

Defending the Network with ISA Server—and Beyond • Chapter 1 ■

Intrusion detection This exciting new feature can be set up to send you an alert if/when a particular type of attack is attempted against your network (for example, if an outsider attempts to scan your ports).

■

Support for Secure Network Address Translation (SecureNAT) The extensible NAT architecture that is implemented by ISA provides a secure connection for clients that don’t have the Firewall Client software installed, including Macintosh and UNIX clients and other non-Microsoft operating systems that are running TCP/IP.The SecureNAT configuration provides a true “transparent” firewall solution for your network.

■

Bandwidth allocation The percentage of bandwidth allocated to a specific user, communication, client, or destination can be controlled by Bandwidth Rules that an administrator creates, to optimize network traffic usage.

■

Secure server publishing Internal servers can be made accessible to specific clients, while the servers are protected from unauthorized access.

■

Enterprise management ISA, like Windows 2000, was designed for greater scalability and more focus on the enterprise market than previous Microsoft products. ISA allows you to set enterprise-level policies as well as array-level policies, and management of ISA arrays is easily centralized.

■

Monitoring and report generation ISA Server allows you to monitor its performance and create detailed security and access logs and graphical reports. Report generation can be scheduled, and remote administration lets administrators monitor the use and performance of the ISA server from an off-site location.

■

E-mail content screening ISA Server provides for screening of e-mail content by keywords, to allow administrators to implement and enforce strict security policies.

■

H.323 Gatekeeper functionality This feature allows for use of videoconferencing software, such as Microsoft NetMeeting, through the proxy, and NetMeeting directory functionality (replacing some of the functionality of ILS).

■

Enhanced software for use of streaming media This includes live stream splitting, and caching of Windows Media content (when using Windows Media Server).

■

Extensibility Microsoft has built into the software mechanisms to allow developers to write and implement their own security features, such as HTTP application filters that are implemented as “Web filters.” Non-Web Proxy packet inspection can be extended through the implementation of application filters. www.syngress.com

5

6


In the previous book, we looked in detail at each of ISA’s feature categories, including firewall security,Web caching, Internet connection sharing, unified management, and extensible platform features. For more specific information about all of these, please see Configuring ISA Server 2000 (Syngress Publishing, Inc. ISBN 1-928994-29-6).

ISA Server’s Layered Filtering Firewall products support the filtering of messages to either allow data to pass through or prevent it from doing so according to specified criteria. ISA Server, when installed in firewall mode or integrated mode, can perform filtering at the packet layer, the circuit layer, or the application layer. Let’s look briefly at how each of these works.

Packet Filtering Packet filtering does most of its work at the network layer of the OSI networking model (equivalent to the internetwork layer of the DoD model), dealing with IP packets. Packet filters examine the information contained in the IP packet header of a message, and then either permit the data to cross the firewall or reject the packet based on that information. When IP packet filtering is enabled, the ISA server will intercept and evaluate packets before passing them on to a higher level in the firewall, or to an application filter. The information the packet filter uses to make its decision includes the IP address of the source and/or destination computer(s) and the TCP or UDP port number (the port numbers are in the transport layer header, so technically although packet filtering generally operates at the network layer, it also processes some higher-layer information). Packet filtering allows the data to proceed to the transport layer only if the packet filtering rules allow it to do so. Packet filtering lets you block packets that come from a particular Internet host, or those that are destined for a particular service on your network (for example, the Web server or SMTP server). Because ISA Server is designed as a security solution, by default enabling packet filtering causes all packets coming into the LAN from the external network interface (the interface connected to the Internet) to be excluded—unless a packet filter, access policy, or publishing rule exists that explicitly allows them. In fact, even if packet filtering is not enabled, ISA Server will not permit packets to enter the internal network unless you explicitly configure rules to permit access. ISA Server provides administrators with flexibility in configuring packet-filtering behavior.There are two types of static IP packet filters that can be configured: ■

Allow filters You specify the packet types that should be allowed to pass through the firewall (either incoming or outgoing traffic); all other packets will be prevented from crossing the firewall. For a service to listen on a particular port, you will need to configure a packet filter to allow traffic on that port (unless the port is opened dynamically by a policy or publishing rule).

www.syngress.com


Block filters You configure filters to explicitly block specified ports. Block filters are used in conjunction with allow filters to give you more flexibility and granularity of control over exactly what traffic will be permitted through the firewall.

NOTE If block and allow filters conflict, the block filters will override, thus erring on the side of more security.

Dynamic packet filtering provides higher security because it opens the necessary port(s) only when required for communication to take place, and then closes the port immediately after the communication ends.

ISA SERVER ALERT Note that dynamic packet filtering works only when the packet filter is configured to use the external interface of the ISA server as the local adapter. Dynamic packet filtering does not work when you configure packet filters to allow access to servers on a trihomed DMZ segment.

Packet filters cannot perform filtering based on anything that is contained in the data field of the packet, nor can they use the state of the communication channel to aid in making the decision to accept or reject the packet. If you need filtering decisions made based on either of these, you will need to use filtering that operates at a different layer (circuit or application filtering).

Circuit Filtering While packet filtering is a widely used and understood concept for many network administrators, circuit filtering might be less familiar to you. Microsoft’s ISA Server documentation makes scant mention of it, and TechNet contains only a few references to it. In fact, circuit filtering seems to be “lumped in” with packet filtering in most discussions, as if the two were the same. In fact, there is an important difference, but there’s nothing mysterious or difficult to understand about it: circuit filters simply operate at a higher layer of the OSI model, the transport layer (host-to-host layer in the DoD model). Circuit filters restrict access based on host machines (not users) by processing the information found in the TCP and UDP packet headers.This allows you to create filters that would, for example, prohibit anyone using computer A from using FTP to access computer B. www.syngress.com

7

8


When circuit filters are used, access control is based on TCP data streams or UDP datagrams. Circuit filters can act based on TCP and UDP status flags and sequencing information, in addition to source and destination addresses and port numbers. The ISA Firewall service works at the circuit level with most Internet applications and protocols, making them perform as if they were directly connected to the Internet. This is true both for clients that have the Firewall Client software installed, and for those that don’t (the latter being known as SecureNAT clients). If the Firewall client is installed, Internet applications communicate using WinSock. It works a little differently for SecureNAT clients. In this case, circuit-level filtering uses a SOCKS filter to forward requests from SOCKS 4.3 applications to the Firewall service. See the discussion of SOCKS and WinSock later in this chapter.

ISA SERVER ALERT SecureNAT clients running non-SOCKS-compliant software are not able to take advantage of the full range of features provided by the Firewall client software. The only exception to this rule is if there is an application filter to support the protocol in question. For example, SecureNAT clients cannot access FTP sites without the aid of an application filter. ISA Server provides the FTP Access Application Filter to support SecureNAT clients. Firewall clients do not need the help of the FTP Access Application Filter to access FTP sites.

Circuit-level filtering allows you to inspect sessions, rather than packets. A session is sometimes thought of as a connection, but actually, a session can be made up of more than one connection. Sessions are established only in response to a user request, which adds to security. Circuit filters don’t restrict access based on user information; they also cannot interpret the meanings of the packets.That is, they cannot distinguish between a GET command and a PUT command sent by an application program.To do this, you’ll have to use application filtering.

Application Filtering There are times when you might want to filter packets based on the information contained in the data itself. Packet filters and circuit filters don’t use the contents of the data stream in making filtering decisions, but you can do this with application filtering. An application filter operates at the top layer of the networking model, the (appropriately named) application layer. Application filters can use the packet header information, but are also able to allow or reject packets based on the data contents and the user information.

www.syngress.com


You can use application filtering to control access based on the identity of the user, and/or based on the particular task the user is attempting to perform.With application filters, criteria can be set based on commands issued by the application.This means, for example, that you could restrict a particular user from downloading files to a specified computer, using FTP. At the same time, you could allow that user to upload files via FTP to that same computer.This is possible because different commands are issued depending on whether the user is retrieving files from the server or depositing them there. Application gateways are considered by many firewall experts to be the most secure of the filtering technologies.This is because the criteria they use for filtering covers a broader span than the other methods. Sometimes hackers write malicious programs that use the port address of an authorized application, such as port 53, which is the DNS address. A packet or circuit filter would not be able to recognize that the packet is not a valid DNS request or response, and would allow it to pass through. An application filter, however, is able to examine the contents of the packet and determine that it should not be allowed. Application filtering sounds like the perfect solution to all your security concerns, but there are drawbacks.The biggest problem is that there must be a separate application layer gateway for every Internet service that you need to support.This makes for more configuration work; however, this weakness is also a strength that adds to the security of the firewall. Since a gateway for each service must be explicitly enabled, you won’t accidentally allow services that pose a threat to your network. ISA Server solves some of these problems through the implementation of “smart” application filters. Application filtering is the most sophisticated level of filtering performed by the Firewall service, and is especially useful in allowing you to protect your network against specific types of attacks such as malicious SMTP commands or attempts to penetrate your local DNS servers.

ISA Server Editions Microsoft offers ISA Server in two different editions. Either can be installed in one of three different installation modes.We’ll take a brief look at the differences between the two editions and the three modes in this section, to assist you in making the correct choices for your network.

ISA Standard Edition The ISA Server Standard Edition is appropriate for small business networks (or even sophisticated home networks), and for implementation on a departmental basis in larger organizations.This edition works well in a peer-to-peer (workgroup) environment; the Standard Edition is installed on a stand-alone Windows 2000 server or can be installed on a Windows 2000 Server that is a member of a Windows 2000 or Windows NT 4.0 www.syngress.com

9

10


domain. ISA Server Standard Edition cannot store configuration information in the Active Directory, and it does not require Active Directory. Nonetheless, the Standard Edition offers the same firewall functionality,Web caching capability, performance, ease of management, and extensibility as the Enterprise Edition.The Standard Edition will support a server with multiprocessor capability as long as it has no more than four processors. Because it cannot be used as part of an array, the Standard Edition is more limited in terms of scalability. It supports hierarchical caching, as does the Enterprise Edition, but does not support distributed caching.The ISA Standard Edition cannot store policy information in the Microsoft Active Directory, as the Enterprise Edition does.

ISA Enterprise Edition The ISA Enterprise Edition is designed for maximum scalability to the largest, hightraffic enterprise networks. Fault tolerance, centralized management, and multiple level policy application are at the core of the Enterprise Edition’s feature set. Whereas the Standard Edition supports up to four processors, there is no limit on processor support in the Enterprise Edition. Perhaps more importantly, whereas the ISA Standard Edition is a stand-alone ISA Server only (although the stand-alone ISA Server can be installed on a member server in a Windows 2000 or Windows NT 4.0 domain), the Enterprise Edition allows you to group ISA servers together in arrays to provide fault tolerance and distributed caching, and spread the load of high network traffic across the group of machines. Response time for clients is improved, and if one server in the array goes down, you still maintain ISA functionality. The Enterprise Edition integrates fully with the Windows 2000 Active Directory, where its configuration and policy information are stored. Using Active Directory, enterprise-level policies can be defined and applied to one or multiple server arrays throughout the enterprise.This is referred to as tiered policy. Of course, increased functionality comes at a price.The Enterprise Edition is considerably more expensive than the Standard Edition (by several thousand dollars). In determining which edition of ISA Server is most appropriate for your network, you should consider your specific needs and cost/performance factors. If you have the Enterprise Edition of the software, ISA servers can be installed as members of a server array.The Enterprise Edition can also be installed as a stand-alone server, although it would be difficult to justify the much higher price of the software if you do not intend to use what is perhaps its most important additional feature. A big advantage of joining multiple ISA servers in an array is the ability to manage them as one entity. All the servers in an array share the same configuration; that is, you only have to configure the array itself—the configuration is then applied to all its members. Because arrays provide for distributed caching capability, performance is enhanced as well. www.syngress.com


Fault tolerance is the basis of server clustering.To a limited extent, an ISA Server array functions as a cluster of ISA servers—in the same way Windows 2000 clustering technology causes multiple Windows 2000 servers to act as one entity, so does the formation of an ISA array enable multiple ISA servers to do the same. Also similar to clustering, arrays allow for load balancing of Web Proxy client requests to spread server requests across the group of servers.

ISA Server Authentication In order to gain access to a resource on your network, users must be authenticated; that is, their credentials must be checked to determine that they have the appropriate rights and permissions to access that object. In addition to Windows 2000 authentication required for access, when the user is attempting to access the resource over the Internet, going through an ISA server in firewall or integrated mode that is protecting your network from outsiders, the user might also have to be authenticated by the ISA server. ISA provides different authentication options, depending on the type of client.The authentication methods available for each client type are as follows:. ■

Firewall clients Firewall client authentication is automatic; no configuration is required.The user credentials of the requesting user are used.

■

SecureNAT clients There is no user-based authentication for SecureNAT clients. Access can be granted or denied based on IP addresses contained in client address sets, but not based on user information.

■

Web Proxy clients Client authentication method can be configured. Client authentication is not required by default, but ISA can be configured to require that clients send authentication information. Authentication methods include basic, digest, integrated Windows authentication, or client certificate. It’s important to note that you can never use Kerberos to authenticate with the Web Proxy service.This is specific to Web Proxy service authentication and has no effect on the Firewall service authentication.

As you can see, there are four authentication methods to choose from when configuring settings for Web Proxy clients: ■

Basic authentication

■

Digest authentication

■

Integrated Windows authentication

■

Client certificate authentication (does not apply to browser-based Web Proxy clients, but is used in a Web Proxy chaining configuration)

www.syngress.com

11

12


These methods will be familiar to many administrators as the same authentication methods that are used by Internet Information Server (IIS) 5.0, Microsoft’s Web server software that is included with Windows 2000.The authentication method(s) can be configured in the array’s Properties sheet. Let’s look at each of the authentication methods in a little more detail.

Basic Authentication When you select the basic authentication option for the Web Proxy client access, the user will be asked to provide a username and password before being allowed access.This will be checked to confirm that there is a matching user account on the ISA Server or in a trusted domain. Be aware that this information is sent in cleartext—no encryption is used to protect the integrity of the credentials. Although the data is a base 64 encoded text string that must be decoded to extract the password in intelligible form, anyone with knowledge of this can decode the information. Obviously, this method is more secure than requiring no authentication at all, but can present a serious security risk because the password is vulnerable to interception by a hacker using a packet sniffer, as it travels over the Internet.

NOTE Base 64 encoding techniques are explained in RFCs 1521 and 2045. This encoding technique uses 65 US-ASCII characters, with 6 bits representing each printable character and one extra character (the 65th) representing a processing function. It is a method of converting binary data for transmission in which each sequence of 3 bytes is converted to a sequence of 4 bytes. It is also used for encoding of Internet mail and in HTTP basic authentication.

The “up” side of basic authentication is that virtually all Web browsers support it, so compatibility isn’t an issue. Basic authentication is actually a component of the HTTP protocol that Web browser software uses to communicate with the Web server.

Digest Authentication Digest authentication goes a step further than basic authentication. Although the process is similar, the user credentials are hashed before being sent over the network. Hashing involves applying a mathematical calculation to the binary bits that make up the data being sent.This is a one-way process; that is, it is not possible to take the result of the calculation and reverse engineer it to come up with the original data (the username and password).This, of course, adds a great deal more security to the transaction.

www.syngress.com


NOTE To use digest authentication, all members participating in the transaction must be members of a Windows 2000 or .NET domain, and passwords must be saved with reversible encryption.

Integrated Windows Authentication ISA Server can be configured to use Windows 2000 authentication, which is especially secure because the username and password don’t have to be sent across the network. This eliminates the possibility of interception in transit.There are two protocols that can be used when integrated Windows authentication is selected: ■

Kerberos v5 The default protocol for Windows 2000 domains

■

Challenge/Response NT LAN Manager (NTLM) authentication

Kerberos Authentication Kerberos is a logon authentication protocol that is based on secret key (symmetric) cryptography. It usually uses the DES or Triple-DES (3DES) algorithm, although with the latest version, Kerberos v5, algorithms other than DES can be used. Kerberos uses a system of “tickets” to provide verification of identity to multiple servers throughout the network.This works a little like the payment system at some amusement parks and fairs where, instead of paying to ride each individual ride, customers must buy tickets at a central location and then use those to ride the rides. Similarly, with Kerberos a client who wants to access resources on network servers is not authenticated by each server; instead, all of the servers rely on “tickets” issued by a central server, called the Key Distribution Center (KDC). The client sends a request for a ticket (encrypted with the client’s key) to the KDC. The KDC issues a ticket called a Ticket Granting Ticket (TGT), which is encrypted and submitted to the Ticket Granting Service (TGS).The TGS can be running on the same physical machine that is running the KDC.The TGS issues a session ticket to the client for accessing the particular network resource that was requested (which is usually on a different server).The session ticket is presented to the server that hosts the resource, and access is granted.The session key is valid only for that particular session and it is set to expire after a specific amount of time. Kerberos allows mutual authentication; that is, the identities of both the client and the server can be verified. For a more detailed explanation of how Kerberos works, see the Kerberos v5 Administrators Guide at www.lns.cornell.edu/public/COMP/krb5/admin/admin_2.html. www.syngress.com

13

14


Remember: Kerberos authentication cannot be used by browser-based Web Proxy clients to communicate with the Web Proxy service. Browser-based Web Proxy clients can only use NTLM to communicate with the Web Proxy service. However, Kerberos can be used in a Hierarchical Web Caching configuration seen when you chain Web Proxy servers. In this case, the downstream ISA server can use Kerberos to authenticate with the upstream ISA server.

NTLM Authentication NTLM is a Microsoft logon authentication method, used by Windows NT domains and supported by Windows 2000/.NET in case “down level” client computers (those running NT or Windows 9x) want to log on to the network. NTLM v2 is the current version, and provides more security than NTLM v1.Version 2 is supported by Windows 2000 and NT 4.0 with SP4 or higher. If the Directory Services client software (which is available on the Windows 2000 Server CD-ROM) is installed on Windows 9x computers, NTLM v2 can be used (however, it is necessary to edit the Registry to enable it). Unlike Kerberos, when a client wants to access a server’s resources using NTLM, that server must contact the domain controller to have the client’s identity verified.The client doesn’t have credentials already issued (the session ticket in Kerberos) that the file or application server knows it can trust.

Client Certificate Authentication Finally, the Web Proxy client can use Secure Sockets Layer (SSL) for authentication. This involves the use of a client certificate and a server certificate.The server first sends, in response to a client request, a server certificate that provides authentication of the server. If the server requests that the client authenticate itself, the client sends a client certificate to the server.

ISA SERVER ALERT Its important to note that a browser-based Web Proxy client cannot establish a secure channel with its ISA Server’s Web Proxy service. Client certificate authentication is used in a Web Proxy chaining setup. The downstream Web Proxy service can present a client certificate to the upstream ISA Server’s Web Proxy service. This allows the downstream and upstream ISA servers to use a secure channel for Web Proxy chaining.

Certificates are digital “documents” that verify the identity of a client or server, and are issued by a trusted third party to which that identity has been satisfactorily proven. The trusted third party is called a certification authority (CA) and can be external (outside

www.syngress.com


the organization) or internal.Windows 2000 Server provides the ability for companies to set up their own CAs to issue certificates internally. Certificates contain identifying information about the certificate holder. If client certificate authentication is configured, the ISA server identifies itself as an SSL Web server to the client, by sending a certificate to the client.The ISA server then requires that the client send a valid certificate before access will be granted. The process of encrypting or decrypting client requests and then passing them on to the Web server to which they are addressed is called SSL bridging. This process is used by the ISA server when it initiates or ends an SSL connection. In the Web Proxy chaining configuration, you are actually bridging the HTTP request made by the browser client as an HTTPS connection between the downstream and upstream ISA Server servers. Moreover, if the original request is an HTTP request, the request is again bridged so that the HTTPS message between the ISA servers is bridged as an HTTP message that is sent to the Web server on the Internet. When a client Web browser requests an S-HTTP (Secure HTTP) object (by default on port 8080, although if you have upgraded to ISA Server from Proxy Server 2.0, it will be 80, and can be any port you want to assign) through the ISA server, a different process is used, called SSL tunneling. In this scenario, the client creates a tunnel through the ISA server directly to the Web server on which the requested object resides.

Installing ISA Server The actual process of installing ISA Server is usually pretty straightforward. However, it’s absolutely critical that you plan your ISA deployment beforehand.The amount of thought and analysis that you put into deployment planning, especially if you are designing an ISA Server solution for the enterprise, will optimize ISA Server’s performance and minimize the chance of making a critical error that will adversely affect your security or access schemes. In this section, we will discuss: ■

Planning and design issues

■

Installing ISA Server as a stand-alone

■

Upgrading a stand-alone ISA server to array membership

■

Installing ISA Server on a domain controller

Planning and Design Issues The ISA server is an integral part of your security configuration scheme, and you do not want to just install the server and hope that everything works out right. Carpenters have an old saying: “measure twice, cut once.” If you thoroughly map out your design, you’ll avoid potential problems in the future. www.syngress.com

15

16


In this section, we’ll focus on planning and design issues as they are relevant to the installation of ISA Server.The primary issues of concern are: ■

Network and hardware specifications

■

The edition of ISA Server to be installed

■

The mode in which ISA Server will be installed

■

Stand-alone versus array configurations

■

Client configuration requirements

■

ISA Server Internet connectivity

You should make firm decisions about each of these ISA Server design issues before you begin your installation.The decisions you make at this point will determine your choices when it comes time to install ISA Server itself. Because ISA can be installed in several different ways for different functionality, there are a number of factors you must take into consideration before you start the installation process. In the following sections, we discuss each of these considerations in more detail.

Network and Hardware Requirements Before installing ISA Server, you will need to assess what hardware is required to meet the needs of your organization’s ISA Server deployment plan. An organization that has 50 network clients and only chooses to use the Web Proxy service will have very different requirements than an organization with 30,000 network clients that wants to avail itself of all the networking services ISA Server has to offer.

System Requirements Whether you choose to install one or one hundred ISA servers, each server must meet minimum hardware and software requirements.The minimum requirements for any ISA server—regardless of the role the machine might play on the network—are: ■

Windows 2000 Server Family operating system with Service Pack 1 or above installed

■

A Pentium II or K7 processor or above running at 300 MHz or faster

■

At least 128MB of RAM (Microsoft recommends 256MB of RAM minimum)

www.syngress.com


NOTE If you are “hardware challenged” and must use a minimal RAM configuration, you should dedicate the machine to only ISA and not use it for any other services. This includes file sharing and Web services. We recommend that you get as much RAM as your hardware budget allows. You will notice considerable Web cache improvement if the amount of RAM in the machine exceeds the size of your Web cache.

■

A minimum of 20MB of disk space for the program files

■

A minimum of 2GB of disk space for the Web cache

■

At least two network interfaces—one to the internal network and a second to an external network, such as the Internet or corporate backbone (the exception would be an internal server acting as a caching-only server)

■

Partitions formatted in NTFS to store the program, log, and cache files

■

A Windows 2000 domain if enterprise policies will be implemented

Processor Requirements The rate limiting factor when it comes to processor requirements can be boiled down to the number of rules per second that the ISA server needs to evaluate. An ISA server with a few rules, but high throughput, might have roughly the same requirements as a machine that has many rules but little throughput through its external interface. Therefore, you can use the speed of the external interface as a guideline for the level of processor support your ISA server requires. See Table 1.1 to assess your processor requirements. Table 1.1 Processor Requirements External Interface Data Rate Less than 10 Mb/second 10–50 Mb/second >50 Mb/second

Processor Requirement

Type of Connection

Pentium II or K6-3 300 MHz Pentium III or K7 500 MHz Pentium III or K7 500 MHz Add a processor for each increment of 50 Mb/second

ISDN, cable, or DSL T3 or comparable Real Fast

Remember that these recommendations are minimums. Many factors determine hardware needs in a particular environment. For example, one consideration in your disk www.syngress.com

17

18


space plan is for the log files and reports that will be stored on your ISA server.The log files can grow very quickly, depending on the level of logging you have configured on your server. If you enable packet filtering and detailed Web Proxy service logging, even a small network can easily generate log files in the range of 5 to 10MB per day. If you are working on larger networks, you can expect your log files to expand at the rate of 50 to 100MB (or more) per day if you carry out detailed logging. It is a good idea to dedicate a partition of at least 1GB to your log files if you plan to carry out even a moderate amount of logging.You will need a month’s worth of log files to create many of the more interesting reports that ISA Server can generate. Moreover, you might want to create reports spanning multiple months, in which case you will need all of the log files available on disk.

ISA SERVER ALERT If you log to a database, make sure you have a large amount of disk space available. The database size will grow even faster than what you see when logging to text files on the local ISA server. You should make at least 10GB available to your ISA logging database.

Network Interface Configuration You should have at least two network interfaces if you plan to use the ISA server as a firewall. However, if you want to use the server as a Web-caching server only, you can use a computer with a single, internal network interface. If you configure multihomed computers, at least one of those interfaces will be directly connected to the Internet or to a network backbone. If you connect directly to the Internet, the interface can be an Ethernet connection (for example, to a DSL or cable modem), ISDN, or analog modem connection. For the internal network interface, you will likely use an Ethernet connection. If you plan to use a perimeter or DMZ network, that network can be connected to a third interface connected to the ISA server.That interface will be considered an external interface, and should be configured with public addresses. An ISA server that acts only as a Web-caching server can get by with a single internal network interface. Network clients will send their requests to the ISA server’s internal interface, and the ISA server will forward those requests to its gateway to the Internet. Responses from Internet servers will be returned from the Internet-connected machine to the single-homed Web-caching server, which in turn will return data to the ISA clients.

www.syngress.com


Installation Modes Before you install the ISA Server software, you should decide in which mode to install it.There are three choices: ■

Firewall mode

■

Cache mode

■

Integrated mode

In integrated mode, the firewall and caching modes are combined so that you get the benefits of both security and Web access acceleration in one package.When you choose to deploy ISA Server in only one mode or the other (firewall or cache), you should be aware that the feature set differs depending on the mode selected.Table 1.2 outlines which features are available in either or both modes. Table 1.2 Mode Choice Effect on Available Features Available in Firewall Mode

Available in Cache Mode

Available in Either Mode

Server publishing

Web-caching service

VPN Packet filtering Application filtering

N/A N/A N/A

Access policy (available only for HTTP in cache mode) Web publishing Real-time monitoring and alerts Report generation

Installing in Firewall Mode Firewall-mode ISA servers support virtually all ISA Server features, with the exception of the Web cache.The Web-caching feature is very memory and processor intensive; therefore, it makes sense to exclude this feature for a server whose primary purpose is to act as a firewall. A firewall should not run extra services to minimize the risk of exposure.

Installing in Cache Mode When you install the server in cache mode, you intend that server to work as a Web Proxy server only.The Web Proxy service supports the HTTP, HTTPS, FTP, and Gopher protocols. If you want to support only these protocols and take advantage of the Web-caching features, but don’t want to implement a full-fledged policy-based firewall, the Web cache option is a good one. A cache mode server is best placed on the internal network, in which case you can use a single interface. Be sure that you implement some type of firewall solution at the edge of your network to protect your internal computers from Internet intruders. www.syngress.com

19

20


Installing in Integrated Mode The integrated mode ISA server allows you to take advantage of all the features ISA Server has to offer.The ISA server acts as both a firewall and caching/acceleration solution to provide security while enhancing Web performance.

Stand-Alone versus Array Configuration ISA Server Enterprise Edition can be installed as either an array member or as a standalone server.There are many advantages of installing the server as an array member, including: ■

The ability to implement enterprisewide array policies via Active Directory

■

The ability to implement a common configuration for multiple ISA server computers

■

The option to expand the scope of a single ISA server to multiple servers with a common configuration

■

Fault tolerance

For an ISA server computer to be installed as an array member, the Active Directory must first be prepared.The procedure for preparing the Active Directory is called enterprise initialization. This is accomplished via the Installation wizard included on the ISA Server CD.You can choose to manually run the ISA enterprise initialization and then install ISA Server a later time. If you choose to install ISA Server in an array configuration, the setup program will check to see if the schema has been properly modified before continuing. Once the array member is installed, a single enterprise array policy can be implemented on any array in your organization. All arrays are able to access configuration information because the settings are stored in the Active Directory.This is a nice faulttolerance method for your configuration because the Active Directory is replicated throughout the organization, and there will be multiple copies of your array policies distributed among all domain controllers.

NOTE If you have the Standard Edition of ISA Server, you won’t have the choice to deploy an array. The Standard Edition is a viable solution for small companies with relatively simple requirements, but is not designed to scale to the needs of complex enterprise networks.

www.syngress.com


ISA Client Configuration A critical aspect of your ISA Server design is the ISA Server client base you expect to support. Proxy Server 2.0 supported what were known as the Web Proxy client, WinSock Proxy client, and SOCKS Proxy client.The SOCKS service is no longer required, and the WinSock Proxy client has changed its name. The client types supported by ISA Server include: ■

The Firewall client

■

The Web Proxy client

■

The SecureNAT client

Each client type offers it own advantages and disadvantages. Let’s examine these features now and assess how they fit into an overall ISA design plan.

The Firewall Client Network clients configured as Firewall service clients are able to access all WinSock protocols.When applications on the Firewall client send TCP or UDP requests to the Internet, the Firewall Client software installed on the Firewall client will intercept the request and forward the request to the Firewall service on the ISA server. The primary advantage of configuring a machine as a Firewall client is that you can control access to protocols, sites, and content on a per-user or per-group basis.This allows you more granular control over your access policies than you have compared to the SecureNAT client.The SecureNAT client cannot control access via user authentication, only via IP address, in a manner similar to the SOCKS service in Proxy Server 2.0. The disadvantage of configuring a host as a Firewall client is that you must install the Firewall client software. Not all operating systems support the Firewall Client software.The only operating systems that support the Firewall Client software are: ■

Windows 95 OSR2

■

Windows 98

■

Windows ME

■

Windows NT 4.0

■

Windows 2000

■

Windows XP

This represents a departure from the support that was offered by the Firewall client’s older brother, the WinSock Proxy client.The WinSock Proxy client software provided with Proxy Server 2.0 supported Win 3.x machines using a 16-bit client software www.syngress.com

21

22


installation.The Firewall Client software does not include a 16-bit client. Keep this in mind if you have the ill fortune of needing to support Windows 3.x machines. Another major advantage of using the Firewall client is that it will work with just about every application protocol, even those that will require multiple connections between the client and the server (these protocols are often referred to as “complex protocols”). NAT will not support complex protocols that require secondary connections unless there is an application filter to support the protocol.

ISA SERVER ALERT If you must support Win 3.x machines, one workaround is to use the WinSock client provided with Proxy Server 2.0. Of course, you must have a copy of Proxy Server 2.0 to implement this solution. You can do this because the Firewall client and the WinSock client are interchangeable. This means you do not need to install the Firewall client on your machines that already have the WinSock Proxy client installed. You can also use the Firewall Client software to connect to the WinSock Proxy service on a Proxy Server 2.0 server. While the Firewall service on the ISA Server works a bit differently than the WinSock Proxy service on Proxy Server 2.0, the client side essentially works the same. However, we recommend that you install the updated Firewall Client software on all machines that support it. This is especially important if you install ISA Server Service Pack 1. After installing ISA Server Service Pack 1, you should immediately update the Firewall Client software.

The Web Proxy Client The Web Proxy service provides access to a limited set of protocols, including: ■

HTTP

■

S-HTTP (SSL secured HTTP)

■

FTP

■

Gopher

While we can safely dismiss Gopher from our consideration, the other protocols represent the bulk of typical Internet connectivity requirements for the majority of organizations that might want to implement an ISA Server solution. If all you require are these protocols, a Web Proxy client/server configuration might be the best fit for your organization. Even if you need to install the Firewall Client software to take advantage of other WinSock applications, you might still want to configure your machines as Web Proxy clients because of the performance advantage you’ll gain for Web access via HTTP 1.1 CERN-compliant browsers. www.syngress.com


ISA SERVER DEFCON 1 For security reasons, you should completely disable Gopher access from your internal network. There is a security issue related to the Gopher protocol and ISA Server (http://support.microsoft.com/default.aspx?scid=kb;en-us;q323889). You can install the patch or create a protocol rule that blocks the Gopher protocol. Gopher uses TCP port 70.

The Web Proxy client has the advantage of not requiring installation of any dedicated client software. If your browser supports Proxy client configuration, as does Internet Explorer, you can take advantage of direct communication with the Web Proxy service.The Web Proxy service supports user authentication, which gives it an advantage over the SecureNAT client.

The SecureNAT Client SecureNAT clients require no client software or application configuration, which makes them the simplest client type in terms of setup and deployment.To become a SecureNAT client, all you need to do is: ■

Configure the client to use the ISA server as its default gateway, or

■

Point the SecureNAT client to a gateway that will be able to route Internet bound packets to an ISA server.

The SecureNAT client is able to take advantage of the Web cache when the HTTP Redirector Application Filter is enabled. However, even though the SecureNAT client is able to use the Web cache portion of the Web Proxy service, SecureNAT clients cannot be authenticated against the Active Directory,Windows NT 4.0’s SAM, or a server’s local security accounts database. Access controls for SecureNAT clients are implemented via IP address rather than user or group membership. Small organizations that do not have easy access to technical support assistance or those that do not want to install or configure client software will benefit most from the SecureNAT client.

Choosing the Best Client(s) for Your Network You are not limited to implementing a single ISA client configuration; you can take advantage of various combinations of clients. For example, you can configure an ISA client as a Web Proxy and Firewall client and take advantage of the features provided by both services, or you can configure a client to be a SecureNAT and a Web Proxy client and take advantage of authentication for Web protocols.

www.syngress.com

23

24


The only mutually exclusive client configuration pair is the Firewall client and the SecureNAT client.That is because the Firewall client will always intercept all TCP and UDP communications.There is no way the SecureNAT client configuration will be able to service TCP and UDP requests when the computer is configured as both a SecureNAT and Firewall client. However, the machine configured as a SecureNAT and Firewall client will be able to access non-TCP/UDP protocols via its SecureNAT client configuration.

Internet Connectivity and DNS Considerations ISA Server supports just about any interface you want to use to connect to the Internet.Your external interface can be: ■

ISDN

■

Analog

■

DSL

■

Cable

■

T-Carrier

■

X.25

■

ATM

An important consideration is whether you want to implement a dedicated or a dial-up solution for Internet connectivity.The advantage of a dedicated connection is speed and reliability.The prime disadvantage of dedicated connections is cost. However, even the cost of dedicated connections is coming down. In areas that support cable and DSL connections, you can have a dedicated connection to the Internet for well under $100 US per month. It is vital that you consider the level of service you require before deciding on what type of connection to use on the external interface. Many businesses seem almost hypnotized by the low prices and potential for high-speed access that DSL and cable connections offer. However, those businesses are often left grinding their teeth and cursing their providers. Here’s the problem:You are not usually guaranteed bandwidth or level of service with these types of connections. Although you typically purchase a certain level of service based on the optimal down and up speeds provided by the interface, those numbers define upper limits of service more often than they guarantee a minimum level of service. Currently, both cable and DSL should not be considered reliable enough on which to base your corporate Internet solution.They are more “rich man’s hobbies,” to quote a well-heeled DSL engineer we know. www.syngress.com


If your business requires a reliable and dedicated connection to the Internet, in our experience you will be best served by using established technologies such as T-carrier and ISDN. Although the cost of these connections is much higher, you won’t have to worry about the connection being unavailable.

NOTE Some telephone companies and cable companies offer a “business level” of service that provides more guarantee of reliability than consumer service packages (and consequently costs more). However, from our experience, there is no significant improvement in reliability. The primary advantage of these types of packages is that you get a dedicated IP address. Dedicated IP addresses are mandatory if you want to implement server publishing scenarios. At the time of this writing, Microsoft is moving away from official support for server publishing on interfaces that do not have dedicated IP addresses.

Gathering Information for the Installation The installation process will proceed more smoothly if you gather the answers to the following questions before beginning to install ISA Server: ■

Where are the installation files that you will use to install ISA Server?

■

Do you have appropriate permissions to install ISA Server?

■

What is the CD key, and where is the product license?

■

Will the Active Directory schema need to be updated?

■

What server mode will you use?

■

Where will you store the program files, log files, and Web cache?

■

What are the network IDs for the hosts on your internal network?

■

What ISA features do you want to include in your installation?

■

Will you be creating or joining an array?

In the following sections, we will look more closely at each of these questions.

Installation Files You can access the installation files either from the product CD-ROM or from a network installation share point. If you are installing from a share point, make sure that the Share and NTFS permissions at the source allow you to install the program.

www.syngress.com

25

26


Permissions You must be logged on with an account that has permission to install the program. If you are installing a stand-alone ISA server, you must at least be a member of the Administrators group for that machine. If you want to install an enterprise array, you must be a member of the Domain Administrators group. If you have a multiple forest environment, you should be a member of the Enterprise Admins group, and if you are responsible for initializing Active Directory, you also have to be a member of the Schema Admins group.

CD Key and Product License The 10-digit CD key is located on the CD case.You might also find it on the product packaging. Have the license readily available, photocopy or scan it, and then put it in a safe place.

NOTE Having multiple copies of your product licenses and storing them in a safe, centralized location is an important part of your fault tolerance plan. Doing this will save you a lot of grief if your company should become the subject of a software audit.

The number of processors determines how much you’ll pay for licensing ISA Server, because the licensing fees are based on the number of processors on the server. Since the costs can increment significantly for a multiprocessor machine, you might consider installing ISA Server on a system with a single processor, and then carrying out performance monitoring to aid you in making a cost/benefit analysis of a multiple processor solution. Table 1.3 contains the pricing structure for ISA Server production licenses at the time of this writing. Table 1.3 Production Licensing Structure for ISA Server ISA Server Version

License Price

ISA Standard ISA Enterprise

$1499.00 US per CPU $5999.00 US per CPU

www.syngress.com


NOTE Production licenses are required for ISA servers that will be part of a production network. Development licenses can be obtained through MSDN, and special pricing applies to Application Service Providers (ASPs). Call your Microsoft representative for more details on special pricing structures.

Active Directory Considerations If you plan to install an enterprise array, the machine onto which you are installing ISA must be a member of a domain.You will also need to be able to connect to a domain controller during the installation. Confirm network connectivity to a domain controller before beginning the installation. As mentioned earlier, when you perform an enterprise initialization, you will be altering the Active Directory so that it can store array configuration information. Remember that in a Windows 2000 domain, alteration to the schema is a one-way process, and you cannot go back and restore the schema to its previous state.

NOTE This situation is improved on Windows .NET domains. If you run a Windows .NET domain, you will be able to make changes to the schema and reverse them if you need to.

Server Mode Decide in advance what server mode you will assign to the ISA server—cache, firewall, or integrated.The decision should be arrived at after conferring with your security group and determining exactly what function(s) this ISA server will perform on your network.

Disk Location for ISA Server Files Determine where you want to install the ISA Server program files.These files will only require about 20MB of disk space and do not incur much read/write activity, so you will usually be safe installing them to the default location, which is in the Program Files folder on the boot partition. You will also need to decide during installation where you want to place your Web cache files. It is best to place these on a RAID array formatted as NTFS (if available). The RAID and NTFS configuration will ensure the best performance possible. www.syngress.com

27

28


NOTE RAID 0 provides the highest performance. There’s no reason to use parity in your Web Caching file array since the information in the Web cache can be built up again in a short time. However, if you use a parity array, you can save some bandwidth by not requiring the cache to be built up again.

Although you will not need to decide where to put your log files during installation, you should have your server configured so that you can adjust the configuration to put the logs on their own partition if possible, and set it up so that the partition is a RAID 5 volume separate from the one on which you have the Web cache file located. By default, the log files are placed on the boot partition, but after installation is complete, you will be able to change the location via the ISA Administration console.

Internal Network IDs and the Local Address Table You will be asked to configure the Local Address Table (LAT) during the installation routine.To prepare the LAT correctly, you need to know what network IDs are in use inside your company.The LAT is used to determine if requests should be sent directly to an internal server, or if they should be subjected to ISA Server rules and policies. Never place the IP address of the external interface of the ISA server in the LAT.

ISA Server Features Installation A few services are treated as “add-in” services by the ISA Server installation routine. You will want to determine beforehand whether you need to install these services as part of your ISA Server deployment.These optional services are: ■

The H.323 Gatekeeper Service

■

The Message Screener

■

The H.323 Gatekeeper Administration Tool

The H.323 Gatekeeper allows multiple inbound and outbound calls using a program such as NetMeeting to conduct voice, video, and data sessions.The H.323 Administration tool allows you to administer the service.Thus, if you install the service, you should install the tool as well.

NOTE As part of the installation routine, the ISA Server setup will change the TCP/IP driver’s dynamic port range. It will be increased to 65,535 (the effect takes place when the computer is rebooted after installing).

www.syngress.com


The Message Screener is a tool you use together with secure Mail Server publishing.The Message Screener tool allows you to check incoming mail for a number of elements, such as keywords. If you plan to implement secure Mail Server publishing, you should install this tool.

Addressing Special Installation Issues For detailed guidance on planning and installing ISA Server with different network configurations, check out Microsoft’s Installation and Deployment Guide, which is available on the ISA Server installation CD. If you are migrating to ISA Server from Microsoft Proxy Server, you should first read the Migrating from Microsoft Proxy Server 2.0 document that is also included on the CD.

Designing & Planning… Pre-Installation Checklist Before starting the installation, you should perform the following tasks: 1. Ensure that Windows 2000 Server is installed on your ISA Server machine, including the most recent service pack. At a minimum, you must install W2K Service Pack 1 before you install ISA Server. 2. Configure the server that will be hosting the ISA Server installation. Check out the article on www.isaserver.org by Jim Harrison, Configuring ISA Server Interface Settings, which will walk you through the setup of your ISA Server machine’s network adapters. Detailed instructions for such security measures as disabling File and Print Sharing on the external interface are included in this article as well. 3. Figure out what your internal network will encompass, both presently and in the future, concerning IP addresses. If the addressing scheme is complex, write down the addresses. You will need this information again later. 4. If your internal network contains more than one range of IP addresses (for example, 192.168.x.y and 10.x.y.z), you need to create the routing table on the server that is to be the ISA server, via the command shell route command (if you only have one address range, Windows will do this for you). To prevent problems later, be sure to view the routing table before installing ISA Server to make sure it’s correct.

www.syngress.com

29

30


For more guidance on planning the ISA Server setup, check out two articles on www.isaserver.org by Tom Shinder and Jim Harrison, Designing an ISA Server Solution on a Simple Network and Designing an ISA Server Solution on a Complex Network. Both of these articles can be found in the Learning Zone at www.isaserver.org.

Installing ISA Server in a Stand-Alone Configuration In this section, we will go through each step required to install ISA Server as a standalone server on a Windows 2000 Advanced Server computer. Later, we will perform the enterprise initialization and upgrade the stand-alone server to an array member. We begin the installation by placing the installation CD into the CD-ROM drive. The autorun begins and we are presented with the installation options screen, as shown in Figure 1.1. Figure 1.1 Setup Allows You to Choose the Option of Installing ISA Server

Note that you have six options: ■

Review Release Notes Select this option to read the latest information about ISA Server that did not make it into the help files.We highly recommend that you read this first. If you don’t want to read it right away, you should at least print it. It will contain important information that you must know before beginning the configuration phase of the ISA Server.

■

Read Installation Guide The installation guide is a pared-down version of the help file.This guide focuses on the concepts that are important to the planning, installation, and basic configuration of ISA Server.You should also print this and read it at your leisure.

■

Register ISA Server Use this link to register your server online.

www.syngress.com


Run ISA Server Enterprise Initialization Use this link to prepare the Active Directory for configuring an ISA Server array.

■

Install ISA Server This option begins the installation of ISA Server.

■

Read About Migrating to ISA Server This link opens a document that provides information about how to upgrade from Proxy Server 2.0 and Windows NT 4.0 installations that have Proxy Server 2.0 installed on them.

The following steps walk you through the process of installing ISA Server: 1. Click on the Install ISA Server option.The “Welcome to the Microsoft Security and Acceleration Server 2000 installation program” dialog box will appear.The information screen informs you that you can only install the product on one server, if that’s the license you have. Be aware of the different licensing guidelines for ISA Server Standard Edition and Enterprise Edition. Click Continue. 2. Next, you will be prompted to enter your 10-digit CD key from the ISA Server CD case. Do so and click OK. 3. After entering the CD Key you will get your product ID number.This is the number that you must provide to Microsoft Product Support Services if you want to get any technical assistance from them.Take a screen shot of this dialog box, write down the product ID number, and put it in a safe place. Make multiple copies so that they’re always available. Click OK to move to the next step. 4. The next screen will show the End User License Agreement (EULA).You must click I Agree to continue the installation process. 5. Next, you must choose an installation option from the following: ■

Typical Installation Installs all the components on the boot partition and does not include the “add-on” products.The add-ons can be installed later if you choose not to install them at this time.

■

Full Installation Includes all the basic installation files and the add-on products, and will install them to the boot partition.

■

Custom Installation Allows you to choose which components you want to install in a granular fashion.

■

Change Folder Allows you to change the location of the core program files. If you do not want to install the program to the Program Files folder on the boot partition, click Change Folder and change the location of the core program files. For this walkthrough, we will click Custom Installation. www.syngress.com

31

32


6. When you select the custom installation, a dialog box appears that allows you to choose the components to install.There are three options, as shown in Figure 1.2. ■

ISA Services

■

Add-in services

■

Administration tools

You must install the ISA Services. However, you can customize your selections for Add-in services and Administration tools. Figure 1.2 Selecting Which ISA Components to Install in a Custom Install

7. If you select Add-in services and click Change Option, the dialog box in Figure 1.3 appears. Make your selection(s) and click OK. Figure 1.3 Installing the H.323 Gatekeeper and/or the Message Screener as Add-In Services

www.syngress.com


8. The Administration Tools selection allows you to install the Administration Tools and/or the H.323 Gatekeeper Administration Tool as shown in Figure 1.4. If you are installing the full product on the server, you will want to install the Administration Tools.You can also choose to install just the Administrative Tools on a Windows 2000 Professional computer and administer any server or array in your organization. If you choose to install the H.323 Gatekeeper Administration Tool, it will place a node in your ISA Administration console that will allow you to configure the H.323 Gatekeeper service. Make your selection(s) and click OK. Figure 1.4 Selecting the Administration Tools

9. If this is the first ISA server to be installed in an array and you have not yet run the Enterprise initialization tool, you will now see a dialog box that informs you that the computer cannot join an array until it is part of a Windows 2000 network and the ISA Server schema is installed in Active Directory.You are notified that continuing the installation will install ISA Server as a stand-alone server. Click Yes to continue the installation in stand-alone mode. 10. The next dialog box asks you to choose the server mode: firewall, cache, or integrated.To use both the security and acceleration features of ISA Server, select the Integrated mode option and click Continue (you are also given an option to exit setup at this point, or to request help with selecting the appropriate mode). 11. A notification box will tell you that Setup is stopping the IIS Publishing service (W3SVC), and that after setup completes, you should uninstall IIS or reconfigure all IIS sites not to capture ports 80 and 8080.The service must be stopped to continue the installation, but will be restarted by the end of the installation. Click OK.

www.syngress.com

33

34


Designing & Planning… Implications of Running IIS on an ISA Server Computer We recommend that you avoid running IIS services on the ISA Server computer at all costs. The reason for this is that each IIS service opens a potent portal of attack for Internet criminals to take advantage of. This is especially true for the IIS WWW service. The only time you should run the WWW service on the ISA server is if you are forced to do so by your employer. You should explain to the individual who insists that you run a Web server on the ISA server itself that this is a dangerous configuration and that if at all possible, the Web server should be removed from the firewall. If you must install a Web server on the ISA server, you should disable IIS socket pooling. IIS socket pooling is applied to all IIS services, and allows the IIS services to host multiple virtual servers and conserve system resources. However, socket pooling was not designed for multihomed machines running as firewalls. When socket pooling is enabled for a service, the service listens on all interfaces. This can create port contention issues when you try to publish services on the internal network. For more information on socket pooling and how to disable it, check out Tom Shinder’s article The Misery of IIS 5.0 Socket Pooling at www.isaserver.org/shinder.

12. The next step is to configure the Web cache settings, as shown in Figure 1.5. To enable the Web cache, you must place a check mark in the Enable caching check box.You are also presented with a list of drives that can support the Web cache.You must place the cache on an NTFS drive. FAT partitions or volumes will not appear on the list.The default setting is to create a 100MB Web cache file on the partition that has the most free disk space. After you enter the size of the cache, you must click Set. After you have made these settings, click OK. 13. The Local Address Table (LAT) configuration dialog box appears next, and provides you a chance to configure the LAT during setup, as shown in Figure 1.6. If you choose not to configure the LAT at this time, or if you change your mind regarding the configuration of the LAT, you can change the settings via the ISA Server Administration Console after the installation is complete. After configuring the LAT, click OK.

www.syngress.com


Figure 1.5 If You Enable Caching, You Must Set the Drive(s) and Maximum Size for Each Cache

Figure 1.6 Configuring the LAT During Setup

Configuring & Implementing… Configuring the LAT There are two ways that you can approach configuring the LAT. You can manually enter the start and end addresses in the Edit frame on the left side of the dialog box, or you can use the Table button. When manually entering the information, you can include the entire range of your network IDs. Note that we have entered an illegal address for the start address for the LAT. This is fine and will not impair the functionality of the LAT. If you choose to use the Table button, ISA Server will try to create the LAT for you based on the network ID of your internal interface. In addition to the network ID of your internal interface, it will also add the three private network ranges: Continued

www.syngress.com

35

36


■

192.168.0.0/24

■

172.16.0.0/12

■

10.0.0.0/8

If you choose to let ISA Server construct the table for you, be sure to check it over very carefully. If you have a network with multiple logical IP segments, you will need to include all of these segment IDs in your LAT. Otherwise, requests for those internal network clients will be subjected to the rules created for requests for external network requests.

14. Next, you will be given the choice to launch the Getting Started wizard to configure array and enterprise policies. If this is your first time installing ISA Server, we recommend that you let the wizard walk you through the steps.To do so, ensure that Start the ISA Administrator Getting Started Wizard is checked, and click OK. 15. The Getting Started welcome screen, shown in Figure 1.7, is presented as the ISA Administration console is opened.You can use the wizard to help walk you through the steps of configuring the server. However, you should have a thorough understanding of ISA Server and all the implications of the settings you create before you work with the Getting Started wizard. Once you have a firm understanding of ISA Server, the wizard might help you configure your server in an orderly fashion. Figure 1.7 You Can Use the Getting Started Wizard to Configure the ISA Server

www.syngress.com


NOTE It is a best practice to use only the minimum required subnets in the LAT. Therefore, you should obtain the LAT configuration from the routing table of the internal interface.

The stand-alone ISA server is now installed. In the next section, we will show you how to upgrade your stand-alone server to an array member.

Upgrading a Stand-Alone ISA Server to an Array Member You must have a Windows 2000 domain deployed and available if you want to make the server a member of an enterprise array.The computer on which you want to perform the upgrade will need to be a member of the Windows 2000 domain.

NOTE If the machine is a member of a Windows NT 4.0 domain, the enterprise upgrade will not work because the Windows NT 4.0 domain controller does not have the Active Directory in which to store the enterprise array configuration information.

The first step, if you are creating a new array, is to initialize the enterprise.

Performing the Enterprise Initialization Before you promote your stand-alone server to an array member, you need to complete the enterprise initialization.This is the process of updating the Active Directory schema so that it will support the ISA Server array configuration information.There are two ways you can perform the initialization: ■

From the Startup Installation screen.

■

From the ISA Server installation files, in the i386 directory, run the msisaent.exe application.

The same steps are involved regardless of which method you choose. In the following walkthrough, we will start the initialization from the Startup Installation screen. 1. When you put the CD-ROM in the drive, the autorun feature will bring up the same dialog box you saw in Figure 1.1.You can also get it to run by www.syngress.com

37

38


clicking on the isaautorun.exe file in the root of the installation files hierarchy.To run the enterprise initialization, click on the Run ISA Server Enterprise Initialization icon. 2. The next dialog box will inform you that the ISA Server schema is about to be installed to Active Directory, and warns you that the action is not reversible.You are asked if you want to continue. Click Yes to do so. 3. Next, you will be asked how you want to apply enterprise policy, as shown in Figure 1.8.When you choose to use Array Policy Only, an enterprise policy will be created, but it will not be automatically applied to the array.You will have the opportunity to manually assign an enterprise policy to the array after the initialization is completed by configuring it in the ISA Management console.When you choose Use this enterprise policy, a default policy is created with the name Enterprise Policy 1.You can change the name if you wish. If you select this option and do not select the Also allow array policy, any array policies will be replaced by the enterprise policy. If you are thinking of choosing this option, be sure to back up your existing array policy prior to the enterprise initialization in the event that you want to restore the existing array policy (stand-alone policy as well) on the server. If you choose the Also allow array policy option, both the enterprise policy and the array policies will be applied. However, array policies can only further limit the policies set for the enterprise.What this means is that an array policy cannot have any allow rules. The only allow rules will be those determined by the enterprise policy.The Also allow publishing rules to be created on the array option does exactly that. Publishing rules must be created on each server of an array separately, because the IP address(s) listening for requests for a published server will be different for each server. If you do not choose this option now, you can do so after the enterprise is initialized and you promote the stand-alone server to an array.The Use packet filtering on the array enforces packet filtering on the array(s) to which this policy is applied.This forces packet filtering and cannot be overridden by an array policy.

NOTE As indicated on the interface, the Also allow array policy option only allows you to create policies that are more restrictive than the Enterprise policy. The Use array policy only option allows you to create Web-caching arrays but avoid the use of enterprise policies. If you find enterprise policies difficult to work with, you can leverage the power of caching arrays while avoiding the somewhat cumbersome enterprise policy configuration issues.

www.syngress.com


Figure 1.8 Specifying How to Apply the Enterprise Policy at the Array Level

4. After you make your selections in the previous step and click OK, you will see a notification box telling you to wait while Setup installs the ISA Server classes and properties in Active Directory.When the process is finished, another box will appear, advising you that ISA Server enterprise initialization successfully imported the ISA schema into Active Directory and you can now install ISA Server as a member of a domain array. Click OK.

NOTE If there were problems with updating the Active Directory, you will receive an error dialog box and you will have to troubleshoot problems with Active Directory and perhaps connectivity. After updating the Active Directory to support your array, you can begin the process of promoting your stand-alone ISA server. Before promoting the server, confirm that you have connectivity with a domain controller in your Windows 2000 domain. You might also want to back up your configuration if you have not yet done so.

5. To promote the stand-alone ISA server to an array member, first open the ISA Server MMC. Right-click the array node in the left pane and select Promote…, as shown in Figure 1.9. 6. A notification box will inform you that you are about to promote the server to an array, and that the operation is not reversible, as shown in Figure 1.10. You will be asked if you want to continue. Click Yes to do so. 7. Now the promotion process will begin. Several things happen during the promotion, and you’ll be informed of these events in the Promoting array dialog box, shown in Figure 1.11.These steps include:

www.syngress.com

39

40

Chapter 1 • Defending the Network with ISA Server—and Beyond ■

Converting a stand-alone server to an array

■

Storing configuration in the Active Directory

■

Stopping all services

■

Committing changes

■

Restarting all services

■

Refreshing array list

Figure 1.9 Use the ISA Server MMC to Promote the Stand-Alone Server to an Array Member

Figure 1.10 You Will Be Informed that the Promotion to Array Is Not Reversible

Figure 1.11 The Dialog Box Will Change as the Promotion Process Advances

www.syngress.com


After the promotion process completes, the Array Properties dialog box will show the type as “Domain,” as shown in Figure 1.12. Before promotion, the type is shown as “Standalone.” Figure 1.12 The Array Properties Box Showing the Type as “Domain” After the Promotion

The Properties box will also have a new tab, Policies, that is used to configure how the array will use enterprise policies that you have configured.

Installing ISA Server on a Domain Controller A common problem that we’ve encountered while supporting ISA Server users is that of installing ISA Server on a domain controller. In general, it is not recommended that you install ISA Server on a domain controller; however, this is a common issue for those who use Small Business Server (SBS) and must run all the SBS servers on a single machine. Many of the problems that occur with this configuration are related to interface and DNS configuration. If you have only a single server, it will need to be configured as a DNS server in addition to the other Server services it is running, because an Active Directory DC needs a DNS server to add AD-related entries. Another problem is that the ISA Server must be multihomed. Multihomed domain controllers have a number of issues, including problems with NetBIOS and the Browser service. Despite the problems, many users have successfully installed and used ISA Server on a Windows 2000 domain controller. For detailed information on how to ensure that

www.syngress.com

41

42


ISA and your domain controller can peacefully coexist, see the article titled Installing ISA Server on a Domain Controller by Tom Shinder at www.isaserver.org/pages/ articles.asp?art=17.We will expand on this information in Chapter 5, “Defense Plan 4: Advanced Server Publishing”. For detailed instructions on how to get Outlook Web Access to work with ISA using Small Business Server 2000, including a “how to” on disabling socket pooling, see the article entitled OWA and ISA Server by Martin Grasdal at http://infocenter.cramsession.com/techlibrary/gethtml.asp?ID=1107.

Selecting the ISA Server Client There are three types of clients supported by ISA Server: ■

Firewall clients Computers with the Firewall Client software installed and enabled.

■

SecureNAT clients Computers that are ISA server clients but do not have Firewall Client software installed.

■

Web Proxy clients Refers to client Web applications that are configured to use ISA Server.

By definition, a SecureNAT client cannot also be a Firewall client for TCP and UDP requests. On the other hand, both Firewall clients and SecureNAT clients can also be Web Proxy clients.Then, if the Web Proxy client configuration cannot handle a particular request, the Firewall and/or SecureNAT client configuration can step in.The Firewall client is the only client type that requires you to actually install client software on the client computer; however, you must configure the client machine’s Web browser to make it a Web Proxy client. See Table 1.4 for a comparison of the three client types. Table 1.4 Comparison Chart of ISA Client Types Firewall Client

SecureNAT Client

Web Proxy Client

Supports WinSock applications

Requires application filters for multiconnection protocols Works on all operating systems with TCP/IP installed

Supports the HTTP, S-HTTP, FTP, and gopher protocols

Does not support user-level authentication

Supports user-level authentication

Only works on Windows operating systems Supports user-level authentication

www.syngress.com

Works on all operating systems, via a Web browser


Firewall Client ISA Server’s Firewall client is equivalent to the WinSock Proxy client in Proxy Server 2.0; it is used for applications such as RealAudio,Windows Media, IRC,Telnet, and any other Internet service that is written to the WinSock application programming interface (API). The Firewall Client software can be installed on any 32-bit Windows operating system, including the following: ■

Windows 95 OSR2 (also known as Windows 95b)

■

Windows 98

■

Windows Millennium Edition (ME)

■

Windows NT 4.0

■

Windows 2000

■

Windows XP

These are the only operating systems in current release at the time of this writing that will run the ISA Firewall Client software.The Firewall client is automatically enabled when installation is completed. Installing the Firewall client writes a log file on the computer to which the software is installed.This file has setup information that includes such useful information as which services were running during installation and what client applications were installed.The log file is helpful in troubleshooting problems that you encounter during installation. Note that if you reinstall the Firewall Client software, the log file will be overwritten. The Firewall client uses a LAT, which is installed to the hard disk of the client computer (in Program Files\Microsoft Firewall Client).The LAT file is named Msplat.txt.The LAT is used to determine whether a request made by a WinSock application should be sent to the ISA server or directly to the computer on the internal network.The LAT defines addresses that are “trusted” by the ISA server. Communications between trusted hosts are not screened by the ISA server.When the Firewall client computer calls another computer on the LAT, the communications do not go through the ISA server. The primary advantage of the Firewall client is that it allows you to apply access policies to authenticated users, rather than just to computer IP addresses. Users who are authenticated via NTLM or Kerberos can have specific rules, such as bandwidth limitations, applied to their user accounts.This is the best reason for using the Firewall client instead of SecureNAT. Another compelling reason to use the Firewall client is that you can use a much wider range of protocols.The SecureNAT client is limited to simple www.syngress.com

43

44


protocols, and those protocols must be listed in the Protocol Definitions node of the ISA Server Management console.The only exception to this SecureNAT client limitation is when there is an application filter in place to support the SecureNAT client’s access to complex protocols. Once installed, the Firewall client can be configured to automatically detect the ISA server, as shown in Figure 1.13. Figure 1.13 The Firewall Client Can Be Configured to Automatically Detect the ISA Server

SecureNAT Client Any computer configured with a default gateway capable of routing Internet bound requests through the internal interface of the ISA server is a SecureNAT client. Although these computers will not be able to benefit from all the features of ISA without the Firewall client software, they can still use most of its access control features. SecureNAT clients do not, however, support user level authentication or complex protocols (without an application filter). SecureNAT clients can ping external addresses (those on the other side of the ISA server), while computers configured only as Firewall clients cannot. You do not have to install any special software on the clients to make them SecureNAT clients. However, you do need to configure their TCP/IP settings. If your network setup is simple (that is, if there are no routers between the client computers and the ISA server), you should set the default gateway to be the IP address of your ISA Server machine.The default gateway is the “way out” of the internal network; it is the address to which packets are sent if their destination address is not on the local subnet.Thus, all Internet traffic will go to the ISA Server machine, which will then forward the requests out over the Internet (assuming the packets are not rejected because of ISA’s packet, circuit, or application filtering rules).

www.syngress.com


You can either configure the SecureNAT clients’TCP/IP settings manually or you can use the Dynamic Host Configuration Protocol (DHCP) to assign the clients their IP addressing, subnet mask, and default gateway information. If you use DHCP, you must select the Obtain an IP address automatically check box on the TCP/IP Properties sheet. If your network is larger and more complex and there are routers between the SecureNAT clients and the ISA server, the default gateway settings on the clients will be configured with the IP address of the router on the local subnet. In this situation, the router must be configured to route Internet bound traffic to the ISA server. Other TCP/IP settings, such as the DNS server settings, depend on whether the clients will be requesting data from Internet servers only, or will also be requesting data from internal servers. If the former, you can use the IP addresses of DNS servers on the Internet; otherwise, a DNS server on the internal network, configured to resolve both internal and external IP addresses, should be used.

Web Proxy Client We mentioned earlier that a computer can be a Web Proxy client at the same time it is a Firewall client or a SecureNAT client.The requirements for a Web Proxy client are: ■

The client must have a CERN-compatible Web browser installed.

■

The Web browser must be configured to use the ISA server.

A request for Web objects sent from a Web Proxy client will be directed to the Web Proxy service on the ISA server.The Web Proxy service will determine whether the access is allowed, and might retrieve the requested object from cache (if it is there) or cache the object when it is returned from the Internet. There are two ways to configure the browser to use ISA Server’s Web Proxy service. If the Web Proxy client has the Firewall client software installed, the Web browser settings can be configured automatically during the setup of the Firewall client. If the client isn’t automatically configured, you can manually configure the browser settings to use the Web Proxy service. If you’re using Internet Explorer, this is done via the Tools | Internet Options | Connections setting. You only have to check a check box (Use a proxy server) in the LAN Settings property sheet, and enter the name of the ISA server or array and a valid port number (the default for ISA Server is 8080).The SecureNAT client will use the Web Proxy service regardless of whether you have configured the CERN-compliant settings in the browser (because the default HTTP Redirector settings forward requests to the Web Proxy service), so you might wonder if making these settings is unnecessary.We highly recommend that you configure your SecureNAT client’s browsers as Web Proxy clients.This will allow user/ group access controls for site and content rules.With user/group access controls for site www.syngress.com

45

46


and content rules, you will be able to control what sites users and /or groups can access and what types of files users and/or groups can access via the Web Proxy service.

NOTE CERN stands for “Conseil Europeen pour le Recherche Nucleaire” in French, or the European Laboratory for Particle Physics. Although most of the laboratory’s work is devoted to research in nuclear physics, CERN played a pivotal role in developing the World Wide Web, and setting standards that resulted in the spectacular growth that made it the global forum it is today. The most popular Web browsers, including Microsoft Internet Explorer and Netscape Navigator/ Communicator, are compatible with the CERN standards.

Getting Started with ISA Server Microsoft has thoughtfully provided a Getting Started wizard to walk you through many of the ISA configuration processes.Tasks for which you can use the wizard include: ■

Creating client address sets

■

Configuring packet filters

■

Creating destination sets

■

Configuring protocol rules

■

Configuring site and content rules

■

Applying server security

■

Creating dial-up entries

■

Configuring firewall and Web routing rules

■

Configuring firewall and Web Proxy clients

■

Creating cache policy

The wizard is accessed by clicking the top node in the ISA MMC (named Internet Security and Acceleration Server) when in Taskpad view, as shown in Figure 1.14.

www.syngress.com


Figure 1.14 You Can Use the Getting Started Wizard to Make ISA Setup Less Painful

NOTE Most ISA administrators seem to find the Advanced view most useful for dayto-day ISA administration, so you might want to change from Taskpad to Advanced view after completing the wizard. To change the view, click the View menu at the top of the MMC and select the desired view.

You can make changes later to the settings that you make with the wizard.

Setting Up Open Access for Testing the ISA Installation In the following sections, we will address the most common issue that comes up when ISA users first deploy the product: how to set up “open access” in order to determine whether ISA is working, that is, whether you still have Internet connectivity after installing ISA.The tasks involved include opening all of the packet filters, sites and content, and protocols.

ISA SERVER ALERT The “open access” configuration is used for testing. Because all protocols, sites, and content are available to the network’s internal clients, this is not a secure configuration and should not be run on your production network, as it defeats the purpose of ISA Server. We recommend that during testing, the ISA server, along with one test client, be disconnected from the rest of the internal network. We also strongly recommend that you turn off IIS on the ISA server before opening access for testing.

www.syngress.com

47

48


Disabling Packet Filtering Packet filtering is a powerful tool that you can use to protect your ISA Server computer from attack. However, packet filtering interferes with running applications and services on the ISA server itself. If you want to use applications on the ISA server (such as POP3 and SMTP applications), you need to create individual packet filters for them. This can be time consuming if you’re doing a simple proof-of-concept testing configuration.You can disable packet filtering and make all applications on the ISA server able to access the Internet. Follow these steps to open all packet filters and create an open access policy for all applications on the ISA server itself: 1. In the left pane of the ISA MMC, expand the Access Policy node. 2. Right-click the IP Packet Filters node and click Properties. 3. In the IP Packet Filters Properties dialog box, remove the check mark from the Enable packet filtering check box. 4. Click Apply. Allow ISA Server to restart the services. Click OK to leave the IP Packet Filters Properties dialog box.

NOTE Because this configuration opens the test network to attackers, make sure your ISA server and test client computer behind the ISA server are not connected to the production network. You should also ensure that IIS services are not enabled on the ISA Server computer.

Allowing All Sites and Content The next step in configuring ISA for open access is to create a rule that will allow access to all sites and all the content on those sites (if there isn’t one already).To do so, follow these steps: 1. In the left pane of the ISA MMC, right-click the Site and Content Rules node, select New, and then select Rule. This will invoke the New Site and Content Rule wizard. 2. The first page of the wizard asks you to name the rule. Again, choose a name that describes its function (such as “Allow All”). Click Next. 3. On the next page, you are asked to select the type of action the rule will perform. Click the Allow option. Click Next. www.syngress.com


4. On the next page, you are asked to specify whether the rule will apply to destinations, schedules, clients, or all three, or whether to create a custom configuration. Click the Custom option. Click Next. 5. On the next page, you must select destinations to which the rule will apply. Select All destinations in the drop-down box. Click Next. 6. On the next page, you must select a schedule for applying the rule. Select Always in the drop-down box. Click Next. 7. On the next page, you must specify the types of clients to which the rule will be applied. Click the Any request option. Click Next. 8. On the next page, you must select the types of content to which the rule will be applied. Select the Any content type option. Click Next. 9. The last page of the wizard summarizes your choices.Verify that they are correct and click Finish (or click Back to make changes). The new site and content rule will appear in the right pane of the MMC.

Opening All Protocols The third and last task you must perform to create your open access configuration is to create a protocol rule that will allow all protocols to pass through.

NOTE Creating a protocol rule will allow Firewall clients access to all allowed protocols, but SecureNAT clients will have access only to those protocols for which there is a protocol definition.

Follow these steps to create the new protocol rule: 1. In the left pane of the ISA MMC, right-click the Protocol Rules node, select New, and then select Rule. This invokes the New Protocol Rule wizard. 2. The first page asks you to give the new protocol rule a name.Type an appropriate name (such as “Allow All”). Click Next. 3. On the next page, you are asked to specify the rule action. Click the Allow option. Click Next. 4. On the next page, you are asked to select the protocols to which the rule will apply. Select All IP traffic in the drop-down box. Click Next.

www.syngress.com

49

50


5. On the next page, you are asked to select a schedule for applying the rule. Select Always in the drop-down box. Click Next. 6. On the next page, you are asked to select the client types that will be allowed access to the protocols. Select Any request. Click Next. 7. The last page of the wizard will summarize your selections.Verify that they are correct and click Finish (or click Back to make changes). The new protocol rule will appear in the right pane of the MMC. Although not necessary, it’s a good idea to restart the Web Proxy and Firewall services after changing these configurations.To do so, follow these steps: 1. In the left pane of the ISA MMC, expand the Monitoring node. 2. Click the Services node under it. For each service, right-click the service name and select Stop. 3. After all services have been stopped, right-click each and click Start.

Configuring & Implementing… Using a Dial-Up Connection There are a few extra steps to take if you’re using a dial-up connection with your ISA server: 1. In the left pane of the MMC, expand the Network Configuration node. 2. Right-click the Network Configuration node and select Properties. 3. In the Properties dialog box, check the Use dial-up entry check box. Click OK. 4. Click the Routing node under Network Configuration in the left MMC pane. 5. Right-click the Last rule in the right pane, and select Properties. 6. In the Properties dialog box, click the check box for Use dial-up entry, and click OK.

www.syngress.com


NOTE You might want to be able to test connectivity directly from the Web browser on the ISA server. You can do this by making the Web browser a Web Proxy client or by accessing the Internet directly. Since packet filtering is disabled, the client will have access to all protocols. If you want to make the browser a Web Proxy client, you can configure it with the IP address you’re using for the Outgoing Web Requests listener or with 127.0.0.1.

Now you can use the open access configuration to test basic Internet functionality through the ISA server.With this configuration, you should be able to access any type of content and publish servers without problems. Once you’ve completed testing, you should disable all the open access entries (disabling them, rather than deleting them, provides you with a quick way to open all access again if you need to do so for testing purposes without having to go through this entire process again).

Installing Service Pack 1 Throughout the following chapters in this book, we take for granted that you have installed Service Pack 1 (SP1) on your ISA servers. SP1 includes several updates and fixes (in fact, SP1 itself has been updated; Microsoft recommends that customers who installed SP1 prior to January 24, 2002 should install the latest build over the previous one on all computers that run ISA Server).

NOTE You can download the latest version of SP1 from the Microsoft Web site at www.microsoft.com/isaserver/downloads/sp1.asp.

SP1 can be applied to both the Standard and Enterprise Editions of ISA Server. It works only with licensed versions and is not compatible with the 120-day evaluation version of ISA Server.You’ll need to have Windows 2000 SP2 installed on the Windows 2000 computer on which ISA is running before you install ISA SP1. If you installed the beta version of SP1, you can upgrade it to the release version.

NOTE SP1 is required to run ISA Server on Windows .NET Standard or Enterprise Server, beta 3 or higher.

www.syngress.com

51

52


You’ll need a minimum of 36MB of free disk space to install the service pack, although it uses only 12MB after the computer is reset following installation.

What’s Included in SP1 If you’re a prudent (and typically paranoid) network administrator, you probably want to know what’s in SP1 before you install it on your machine(s). According to Microsoft, the service pack includes the following: ■

Hot fixes (all that have been released)

■

Fixes that address customer reports to Microsoft Product Support Services (PSS)

■

Code that increases the stability of the ISA services and admin tool

■

Fixes recommended by security experts outside of Microsoft

■

Code that makes it possible for ISA to work with .NET Standard and Enterprise Server operating systems

SP1 also gives you the ability to uninstall specific hot fixes that are installed after SP1, on an individual basis.

ISA SERVER ALERT The only way to uninstall hot fixes that were released/installed before you installed SP1 is to uninstall SP1 itself. This will uninstall all hot fixes included in SP1 (which includes all hot fixes released prior to its release). You cannot uninstall the fixes individually. If you installed later hot fixes after SP1, you must uninstall them individually before you can uninstall SP1. The most recently installed hot fix must be installed first. Use the Add/Remove Programs applet in Control Panel to uninstall SP1 and/or to uninstall individual fixes installed after SP1. Just select Microsoft ISA Server Service Pack 1 and Hot Fixes. To remove an individual hot fix installed after SP1, select it from the list and click Remove. To uninstall SP1, just click Remove. When you installed SP1, the files that are necessary to return ISA Server to its pre-service pack state are saved in a folder called $UNINSTALL_ISA_SP$ in binary form. Uninstalling SP1 will restore these files.

A detailed list of the individual fixes that are addressed by SP1 is available on the Microsoft Knowledge Base Web site. See KB Article Q313249 for this information.

www.syngress.com


Determining the Version of SP1 Installed Here’s how to find out which version of SP1 (if any) is installed on your ISA computer: 1. Click Start | Programs | Microsoft ISA Server | ISA Management. 2. In the ISA MMC, expand the Internet Security and Acceleration Server node in the left pane, and then expand Servers and Arrays. 3. Expand the ISA server name (ISABOX in Figure 1.15). Figure 1.15 Check the ISA Server’s Properties to Determine Which Service Pack (If Any) Is Installed

4. Click Computer. 5. Right-click the computer name in the right details pane, as shown in Figure 1.15, and select Properties. 6. In the Properties dialog box, note the number in the ISA Server version field. As of the writing of this book, the latest version of SP1 was 3.0.1200.166. If any number other than this appears in the Properties dialog box, you should install the current version.

NOTE You can check the Microsoft Web site (www.microsoft.com/isaserver) to determine whether newer service pack versions have been released.

Figure 1.16 shows the Properties dialog box on a machine with no service pack installed. www.syngress.com

53

54


Figure 1.16 The ISA Server Version Field Indicates Whether a Service Pack Is Installed

Figure 1.17 shows a machine with the initial version of SP1 installed. Figure 1.17 If a Service Pack Is Installed, the ISA Server Version Field Shows the Version

Downloading and Installing the Service Pack on the ISA Server The first step in installing the service pack is to download it from the Microsoft Web site at www.microsoft.com/isaserver/downloads/sp1.asp.You can select from several language versions: English, French, German, Japanese, and Spanish.The file is named isasp1.exe and is 2.8MB in size. Note that the filename is the same for the original and

www.syngress.com


current versions of the service pack, so you cannot tell which version of the executable you have based on the filename.

NOTE If you have a slow connection or you’re unable to download SP1 over the Internet, you can order it on CD from Microsoft’s trial store for $9.95. The CD includes all the language versions except Japanese. TechNet subscribers receive the service packs on CD as part of their membership benefits.

After you’ve downloaded the service pack, run the isasp1.exe file from the local hard disk or network share (or if you have the CD, run it from the CD).You will first be prompted to accept the End User Licensing Agreement. Update files will be copied to the computer.When the update is complete, the dialog box shown in Figure 1.18 appears, prompting you to restart the computer. Figure 1.18 You Must Restart the Computer After the Installation of SP1

After the ISA Server computer reboots, check the Properties box again to ensure that the latest version of SP1 (3.0.1200.166) is indeed installed, as shown in Figure 1.19. Figure 1.19 When You Have the Proper Version of SP1 Installed, the Version Number Will Be 3.0.1200.166

www.syngress.com

55

56


Upgrading Client Computers to SP1 Computers running the ISA Firewall Client should be updated with the client fixes that are included with SP1, as this increases stability.The SP1 upgrade addresses problems experienced by the Firewall client when it is under a high load and using WSPAD, conflicts with third-party layered service providers that cause connectivity problems, and problems with the Firewall client that might be experienced after upgrading the operating system to Windows XP. After SP1 has been installed on the ISA Server machine, you can upgrade the clients by connecting to the mspclnt share directory on the ISA server and running setup.exe.This starts the Firewall Client Installation wizard. Choose the Repair option, as shown in Figure 1.20. Figure 1.20 Updating the Firewall Client in the Firewall Client Installation Wizard

When the wizard completes the update process, you will be prompted to restart the client computer.

Service Pack 1 Issues An independent security evaluation of ISA Server Service Pack 1 was conducted by Foundstone, Inc. (www.foundstone.com) prior to the service pack’s release in February 2002.The Foundstone team uses extensive testing that includes custom hacking tools, known exploits, and other means to detect penetration and attack vulnerabilities. According to the white paper published by Foundstone (available on the Web at www.foundstone.com/pdf/isaserver_wp.pdf), the ISA Server development team at Microsoft resolved the concerns that were presented to them after testing, and Foundstone concluded that ISA Server with SP1 is an effective firewall solution for enterprise-level networks.

www.syngress.com


ISA SERVER ALERT Some ISA users have experienced problems with DNS queries following the installation of SP1. If you are using internal DNS servers to resolve DNS queries, you might find that DNS doesn’t work after you install the service, until you restart the ISA server a second time (following the automatic restart after the installation). This always seems to fix the DNS problem.

Supporting Network Design Because security and network performance—the two-pronged purpose of ISA Server—are so important in today’s interconnected world, ISA Server plays a vital role in your overall network design. Of course, exactly how and where ISA will be implemented depends on the particulars of your network (including size), your security needs, and the type of business you do. Possible scenarios include: ■

ISA Server as a stand-alone firewall server to protect your small to mediumsized network from Internet intrusion.

■

ISA Server as part of an e-commerce solution, to speed customer access to your Web site and provide security for financial transactions using X.509 certificates.

■

ISA Server as a Web-caching server, to provide faster Web access to knowledgebased workers on your LAN.

■

An ISA Server array, to distribute the load of client requests and provide fault tolerance.

■

ISA Server as an Internet connection sharing solution.

■

ISA Server as a secure publishing solution, to protect the Web servers on your local network.

■

ISA Server as part of a perimeter network (DMZ) solution.

There are a number of circumstances in which specific network design factors or special needs of the organization will require additional solutions for fully integrating ISA Server into the network. In the following sections, we discuss how you can use Application Center 2000 to provide centralized management of your ISA servers in a network where Active Directory has not been deployed, running ISA Server on the Windows .NET Server operating systems, and third party add-on software that can be installed on your ISA servers to provide added features and functions.

www.syngress.com

57

58


Using Application Center 2000 with ISA Server The Enterprise Edition of ISA Server allows you to manage and configure the ISA servers on your network from a central location—but it is designed to work with Active Directory.What do you do if you haven’t deployed Active Directory on your network, but still want centralized control? There is a solution: use Microsoft’s Application Center 2000 in conjunction with ISA. Application Center 2000 is a Microsoft tool for managing Windows 2000 Web applications as part of a high availability Web services deployment plan. It allows you to automatically apply changes to a group of servers in a cluster.You can find out more about Application Center 2000 at www.microsoft.com/applicationcenter/default.asp. Application Center can also be used to manage multiple servers running the ISA Server Standard Edition, creating a “pseudo array.”This gives you the benefits of centralized administration without requiring that you deploy Active Directory.You need to install both products—ISA Server and Application Center—on each server that will be a member of the cluster.The array policy for all the ISA servers will be stored on the machine that acts as cluster controller for the Application Center cluster, and you make changes to the array members on the cluster controller.

NOTE Not all of the features of an enterprise array on an Active Directory network are available to the pseudo array that is created by using Application Center. Distributed Cache Array Protocol (CARP) and centralized security groups are not supported, and you cannot use tiered policies.

Using Application Center to manage your ISA servers offers many benefits, but imposes additional requirements (which might result in additional cost). For example, all the server hardware needs to be identical, and the software configurations on all the servers need to be the same. For more information about using ISA Server with Application Center on a nonAD network, along with detailed instructions on how to set up the network and servers, see the white paper on Microsoft’s Tech Net Web site at www.microsoft.com/ technet/treeview/default.asp?url=/technet/prodtechnol/acs/deploy/MgISA-AC.asp.

ISA Server and Windows .NET The next generation of the Microsoft server family,Windows .NET server, is available for customer preview (Release Candidate 1) at the time of this writing and is expected to be released in the last quarter of 2002 or first quarter of 2003.The .NET server family consists of four members: Standard Server, Enterprise Server, Datacenter Server, www.syngress.com


and Web Server.The .NET framework (which can also be added to and run on Windows 2000 Server) focuses on the use of XML and the products include improved performance, security, and reliability features. Many organizations that put off upgrading to Windows 2000 and are still running NT networks are expected to upgrade directly to .NET. ISA Server will run on Windows .NET Servers; however, there are some caveats. If you’re running ISA on a Windows 2000 Server and want to upgrade to .NET, you have to install the ISA SP1 first. If you want to install ISA on a server that’s already running .NET Server, you’ll get error messages during the installation process that say “ISA Server is not supported by this version of Windows,” because the packet filter extension driver can’t be loaded.You can go ahead and install despite the error messages, but then you must apply SP1 before ISA will work properly.The .NET Server should not be connected to the Internet until you have finished installing both ISA and SP1.

NOTE The 120-day evaluation version of ISA Server available at the time of this writing cannot be run on Windows .NET Server. If you’re running it on Windows 2000 Server, you must remove it before upgrading the server to Windows .NET.

You might encounter some issues after you get ISA and SP1 installed on your Windows .NET Server. For example, if the Internet Connection Firewall (ICF) is enabled, the ISA Firewall service won’t start.You need to disable ICF.

Third-Party Software Add-Ons for ISA Server Since ISA Server’s release and as it has grown in popularity, a number of third-party software vendors have developed add-on products to enhance ISA’s functionality. It’s inevitable with any piece of software such as ISA that as users learn what it will and won’t do, they develop “wish lists” of features they’d like to see added. Microsoft is generally good about listening to this type of feedback and incorporating many of these new features into future versions of their products. However, what does a company do if it really needs those features in the meantime? Moreover, what about features that aren’t needed or wanted by the majority of users, but are extremely useful to a subset of users? That’s where enterprising software developers come in. The number of add-ons offered for ISA Server is surprising, considering the fact that, at the time of this writing, it has only been available to the public for less than two years.We counted over 40 add-on products mentioned on the www.isaserver.org Web site alone.These products fall into several different categories, including: www.syngress.com

59

60

Chapter 1 • Defending the Network with ISA Server—and Beyond ■

Access Control

■

Content Security

■

Intrusion Detection

■

Networking Utilities

■

System Hardening

■

Anti Virus

■

Reporting Tools

■

Caching Enhancements

■

High Availability and Load Balancing Solutions

■

Monitoring and Administration add-ons

■

Security Services

Some of the ISA add-ons that we’ve tried and/or that are most often mentioned in the ISA Server user community include GFi’s DownloadSecurity for ISA Server, Rainfinity’s RAIN Connect, N2H2’s content filtering product, and the reporting tools from Burst Technology (btLogAnalyzer) and WebTrends Corporation.We have also heard good reports about Stonesoft’s Stonebeat Full Cluster for ISA Server, which provides high availability and dynamic load balancing.

ISA Server Certification Microsoft’s certification exam 70-227, Installing, Configuring and Administering Microsoft Internet Security and Acceleration (ISA) Server 2000, is destined to replace exam 70-088, Implementing and Supporting Microsoft Proxy Server 2.0, when the latter is retired (retirement is scheduled for June 30, 2003).The Proxy Server exam was a popular elective choice for the Microsoft Certified Systems Engineer (MCSE) track in the past, and many new MCSE candidates are choosing the ISA Server exam as one of the two required electives. Although this book is not designed specifically as an exam prep or study guide, we hope that, used in conjunction with Configuring ISA Server 2000, it will serve as a supplement to the training materials and study kits for those who are looking for more than just a surface understanding of how ISA works “under the hood.”We believe that knowledge will help to lay a foundation for persons contemplating taking exam 70-227, especially if our books are also used in conjunction with an objective-oriented study guide. The Microsoft exam objectives are a good starting point for anyone who aspires to master this complex product, as they cover installation (including upgrade from Proxy

www.syngress.com


Server 2.0 to ISA Server), configuring and troubleshooting the ISA Server services, configuring and managing policies and rules, setting up and administering the client computers, and monitoring and analyzing ISA Server use. All these topics are important not only to exam takers, but to working IT administrators who plan to deploy ISA Server on their networks.This book is intended for both audiences (realizing that those two audiences will overlap in many cases, as student/exam takers get jobs and must put their knowledge to work in the field, or experienced professionals who have been working with the products on production networks decide to test their knowledge and obtain official documentation of their skills). Microsoft has targeted ISA Server for the enterprise market, and that notion is reflected in their stated audience profile for the exam: candidates are expected to have at least a year of experience operating in a medium to very large networking environment (defined as 200 to 26,000+ users and multiple physical locations) where the Windows 2000 operating system is in use.We know that some of our readers fit this description and others don’t. Our goal in writing both of these books was to provide value both to those who are rolling out ISA Server in a large-scale network for mission-critical applications, and those who are deploying it on a small home network to familiarize themselves with the product as they study for the exam.

Beyond ISA Server Implementing the ISA Server firewall is an important step in protecting your network from intruders and attackers, as well as controlling the access of internal users to inappropriate or potentially dangerous Internet sites and services. However, there is much more that you must do as part of a comprehensive security plan. In addition to the chapters that deal with advanced configurations of ISA Server, this book will look at some other aspects of how to secure a Windows 2000 network, including: ■

Windows 2000 built-in security features Windows 2000 provides many built-in security features that can be used to protect your computers and network.These include the ability to change the default access control settings by refining the permissions that are granted by default to predefined security groups.

■

The security configuration toolset This is Microsoft’s response to a need expressed by systems administrators for a centralized, easy-to-use program that would allow them to set security for domains, organizational units, and local machines, rather than having to learn and use multiple tools for these tasks. Also included is the Security Configuration and Analysis MMC snap-in that

www.syngress.com

61

62


makes it possible to quickly and easily analyze a computer’s current configuration and compare it to predefined or custom security templates and apply changes. ■

The Encrypting File System EFS provides Windows 2000 (and XP/.NET) users with a built-in mechanism for encrypting data on the disk, on a file-by-file or folder basis. File encryption is an important part of the security plan in an environment that includes sensitive data stored on the network (such as client records, personnel information, financial data, trade secrets, or any other data that should remain confidential).

Other security considerations are not specific to Windows-based networks, but many Windows sys admins are implementing these new methods of security and need guidance in integrating them into a Windows environment.These include: ■

Smart card authentication Windows 2000 supports the use of smart cards for logon authentication, and this gives administrators a way to increase the security of the logon process by requiring that a user provide not only something he or she knows (an account name and password) in order to log on to the network, but also something he or she has in possession: the physical card on which is embedded a chip that contains the user’s certificate and other information.

■

Wireless network security 802.11 wireless technologies have made it possible for laptop users to roam away from their desks and still stay connected to the company network without the inconvenience of cables. However, wireless networks have opened many new security holes that must be addressed; otherwise, there is a grave risk of comprising the security of the network. Out of the box, the default settings on most wireless equipment leave the network wide open to knowledgeable intruders, but there are many measures that can be implemented to provide better security and still enjoy the benefits of wireless communications.

■

Web server security Web servers represent a point of vulnerability for many corporate networks because they are accessible via the Internet. Microsoft’s Internet Information Services (IIS) Web server software, like other Web server software, has a number of security holes when using default settings and/or unpatched versions of the program.There are many things a savvy administrator can do to increase the security of the network’s IIS-based Web servers.

This book will address all of these issues.

www.syngress.com


Summary In this introductory chapter, we provided an overview/review of Microsoft ISA Server’s features and functionality, installation tips, and how to update the ISA Server and clients with Service Pack 1.We included new information about incorporating ISA Server into your network design, using Application Center 2000 to manage ISA Servers in a non-Active Directory network, running ISA Server on Windows .NET Server, and information about some of the many third-party software packages that can be added to ISA Server to enhance its functionality. We then went beyond ISA Server to discuss major network security issues that are often encountered by the administrators of Windows-based networks in the enterprise, including the use of Windows’ built-in security features such as the default access control settings, Security Configuration Toolset, and the Encrypting File System (EFS). Other security considerations we discussed include the use of smart cards to authenticate users on the network, securing 802.1 wireless networks, and providing better Web security when using IIS as your Web server. Network security is no longer a luxury that administrators can choose to ignore; our systems are vulnerable to a plethora of potential dangers.We need only read the newspapers to know that information warfare—the use of technology to disrupt the communications infrastructure on which companies and individuals increasingly depend—is not just an interesting idea; it’s already a reality. Major corporations have lost millions of dollars due to lost productivity, data loss or damage, and other consequences of both casual and calculated attacks.Whether the work of a sophisticated and skilled hacker or a clueless script kiddie, an attack on your organization’s network can be financially devastating. It is essential that network professionals have the proper tools available to protect their networks, and the documentation that will help them to get the most out of those tools. ISA Server, through its firewall functionality, provides one such tool. However, installing it on your network is not enough.There are many different ways in which ISA can be deployed, and many tricks to configuring it to perform exactly the functions you need in your own organization. In Chapters 2 through 6, we will delve into advanced configuration techniques that can be used to tailor your ISA Servers’ functionality to fit your individual needs.Then, in Chapters 7 through 15, we’ll go beyond ISA Server to look at other aspects of defending a Windows-based network.

www.syngress.com

63

64


Defensive Tactics Fast Track ISA Server Overview ; Microsoft’s Internet Security and Acceleration (ISA) Server replaced Microsoft

Proxy Server 2.0, providing full-fledged firewall functionality for a much more robust security solution, along with improved caching/Web performance features. ; ISA Server performs the functions of a full-featured dedicated firewall. specifi-

cally designed to control access, preventing unauthorized data from entering the network and restricting how and what type of data can be sent out. ; ISA Server, when installed in firewall mode or integrated mode, can perform

filtering at the packet layer, the circuit layer, or the application layer.

Installing ISA Server ; You should make firm decisions about each ISA Server design issue before you

begin your installation.The decisions you make at this point will determine your choices when it comes time to install ISA Server itself. ; Minimum hardware requirements for any ISA server—regardless of the role

the machine might play on the network—include Windows 2000 Server with SP1 or above; PII or K7 processor at 300 MHz or faster; minimum of 128MB of RAM (256MB recommended); 20MB disk space for program files, 2GB disk space for Web cache, two network interfaces. ; ISA Server can be installed in one of three modes: firewall, cache, or integrated. ; ISA Server Enterprise Edition can be installed either as an array member or as

a stand-alone server. ; ISA Server supports three client types: Firewall,Web Proxy, and SecureNAT.

Installing Service Pack 1 ; SP1 can be applied to both the Standard and Enterprise Editions of ISA

Server. It works only with licensed versions and is not compatible with the 120-day evaluation version of ISA Server.

www.syngress.com


; SP1 can be downloaded from the Microsoft Web site at www.microsoft.com/

isaserver/downloads/sp1.asp.You can select from several language versions: English, French, German, Japanese, and Spanish.The file is named isasp1.exe and is 2.8MB in size. ; After SP1 has been installed on the ISA Server machine, you can upgrade the

Firewall clients by connecting to the mspclnt share directory on the ISA server and running setup.exe.

Supporting Network Design ; Application Center 2000 can be used to centrally manage ISA servers on the

network if you do not have Active Directory implemented. ; ISA Server will run on Windows .NET servers, but ISA SP1 must be installed

(either before upgrading from Windows 2000 to .NET, or after installing ISA on a .NET server).The .NET server should not be connected to the Internet until you have finished installing both ISA and SP1. ; There are dozens of third-party software add-ons available for ISA Server that

add more functionality and features, many of which are reviewed on the www.isaserver.org Web site.

ISA Server Certification ; Microsoft’s certification exam 70-227, Installing, Configuring and Administering

Microsoft Internet Security and Acceleration (ISA) Server 2000, is destined to replace exam 70-088, Implementing and Supporting Microsoft Proxy Server 2.0, when the latter is retired (retirement is scheduled for June 30, 2003). ; The Microsoft exam objectives are a good starting point for anyone who

aspires to master this complex product, as they cover installation (including upgrade from Proxy Server 2.0 to ISA Server), configuring and troubleshooting the ISA Server services, configuring and managing policies and rules, setting up and administering the client computers, and monitoring and analyzing ISA Server use. ; Microsoft has targeted ISA Server for the enterprise market, and that notion is

reflected in their stated audience profile for the exam: candidates are expected to have at least a year of experience operating in a medium to very large networking environment (defined as 200 to 26,000+ users and multiple physical locations) where the Windows 2000 operating system is in use. www.syngress.com

65

66


Beyond ISA Server ; Windows 2000 provides many built-in security features that can be used to

protect your computers and network.These include the ability to change the default access control settings by refining the permissions that are granted by default to predefined security groups. ; The security configuration toolset is Microsoft’s response to a need expressed

by systems administrators for a centralized, easy-to-use program that would allow them to set security for domains, organizational units, and local machines, rather than having to learn and use multiple tools for these tasks. ; The Encrypting File System (EFS) provides Windows 2000 (and XP/.NET)

users with a built-in mechanism for encrypting data on the disk, on a file-byfile or folder basis. ; Other security considerations, including smart card authentication, wireless net-

work security, and Web server security, are not specific to Windows-based networks, but many Windows sys admins are implementing these new methods of security and need guidance in integrating them into a Windows environment.

Frequently Asked Questions The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form.

Q: Must I install the schema to Active Directory each time I install an ISA server on my enterprise network?

A: No.The ISA schema only has to be installed once for the entire enterprise, when you install the first ISA server.

Q: What are the advantages to installing a single ISA server as a lone member of an array, instead of installing it as a stand-alone server?

A: If you anticipate that you might want to extend the ISA deployment to an array in the future, it will be easier to do so if you have installed your ISA server as a sole member of an array.Then, all you have to do is add more servers to the array later. Arrays offer several advantages: all the servers in the array share a common configu-

www.syngress.com


ration and can be managed together, saving on administrative time. Enterprise policies can be applied to all the servers in an array, and having an array distributes the load across the multiple servers, increasing performance and providing fault tolerance.

Q: Can ISA Server be installed in a Windows NT 4.0 domain? A: Yes. Although ISA Server can only be installed on a Windows 2000 Server machine, that machine can be a stand-alone server in a Windows NT 4.0 domain. ISA Server must be installed as a stand-alone server in this environment; you cannot configure an array, because the configuration information will be stored in the local Registry rather than in a centralized location (Active Directory).

Q: Can I use ISA Server to protect our network from viruses? A: ISA Server does not come with built-in virus detection.There are a number of third-party vendors who can supply application filters for ISA Server that can protect your network from viruses.Web filters can assess data moving through the Web Proxy service and scrub the data to remove the virus content. GFI Software’s “Internet Security for ISA Server” product is a Web filter that removes viruses from the Web Proxy service communications. Other filters can examine Instant Messenger, SMTP, and NNTP traffic.The built-in SMTP Message Screener can remove attachments from e-mail, but it does not screen for viruses.

Q: What’s the best type of DNS setup for ISA Server? Is there anything I should do to optimize my network before installing ISA Server?

A: There’s a good chance that you’re going to publish internal servers so users on the Internet can access their resources. It’s very common for both internal and external network clients to want to access the same servers.The problem that most organizations run into is that internal network clients should not use the ISA server to access internal network resources.The way you get around this problem is by creating a “split” DNS infrastructure. It’s called “split” because you need to split your DNS zone configuration so that internal and external network clients access different DNS servers for the same zone. For example, if you’re hosting resources for mydomain.com on the internal network that are accessible to external network hosts, you need to create one DNS zone that external network clients will use, and another zone that internal network clients will use. Although both zones will be authoritative for mydomain.com, the IP addresses in the resource records will be different.The public DNS zone will contain the IP addresses you use on the external interface to publish the servers on the internal network, and the private

www.syngress.com

67

68


zone will contain the private IP addresses on the internal network that internal network hosts will use to connect to the servers.

Q: What client type should I use? All my systems run some version of an NT-based operating system.We have Windows NT 4.0,Windows 2000, and Windows XP systems.

A: You should configure your machines as both Firewall clients and Web Proxy clients. The combination of Firewall and Web Proxy clients will give you the best performance with the highest level of service and protection.The only machines that should be configured as SecureNAT clients are those you’re publishing to the Internet and domain controllers. It is generally a very bad idea to install the Firewall client on a domain controller.

www.syngress.com

Chapter 2

Defense Plan 1: The Trihomed DMZ


Configuring a Trihomed DMZ

■

Publishing DMZ SMTP Servers

■

Publishing a Web Server

■

Publishing an FTP Server on a Trihomed DMZ Segment

■

External Network Clients Cannot Use the DMZ Interface to Connect to the Internal Network

; Summary ; Defensive Tactic Fast Track ; Frequently Asked Questions 69

70

Chapter 2 • Defense Plan 1: The Trihomed DMZ

Introduction A demilitarized zone (DMZ) is a network segment that lies between the internal network and the Internet. Consider a DMZ segment as a type of “no man’s land” where anyone or anything unfortunate enough to find its way to that segment is considered free game for attack.You must assume that any network host placed on a DMZ segment will be attacked and compromised. Maybe not today, maybe not tomorrow, but some day. A DMZ segment can have public or private addresses. If you have two ISA Server computers, or an ISA server and another firewall, you can create a “back-to-back DMZ.”The back-to-back DMZ can have public or private network addresses.When you use public addresses, your DMZ segment becomes a direct extension of the Internet.The major difference between the Internet and your public address DMZ segment is that the hosts on the DMZ segment are under your administrative control. The private address DMZ segment isn’t considered a direct extension of the Internet, the reason being that a network address translator or proxy has to be interposed between the private address DMZ hosts and the Internet.The private address DMZ segment is more secure because there is no way to directly route packets to and from the Internet; the packets must traverse the NAT or proxy.

Configuring a Trihomed DMZ ISA Server supports the trihomed DMZ configuration in addition to the back-to-back DMZ setup.The trihomed DMZ has the following interfaces: ■

A public interface with a public network address

■

A DMZ interface with a public network address

■

An internal network interface with a private network address

The trihomed DMZ setup is less flexible than the back-to-back DMZ configuration because you don’t have the choice between public or private network addresses. The trihomed DMZ demands the use of public IP addresses.You cannot use private addresses on the DMZ segment of a trihomed ISA Server computer. The public addresses on the DMZ segment must consist of a subnet of the pubic address block assigned to you by your ISP. One of the most common errors we see when looking at problematic trihomed DMZ configurations is when the ISA Server administrator has configured the DMZ segment network ID to be on the same network ID as the external interface of the ISA server.The public interface and the DMZ interface must be on two different network IDs.

www.syngress.com

Defense Plan 1: The Trihomed DMZ • Chapter 2

ISA SERVER ALERT You cannot use the ISA Server software to create a private address DMZ segment. However, ISA Server does support multiple internal network interfaces. These internal network interfaces are contained in the Local Address Table (LAT). There are methods you can employ to create a private address (LATbased) DMZ. We’ll talk about those in Chapter 4, “Defense Plan 3: The Internal ‘Pseudo’ DMZ”

The reason for having the public and DMZ segments on different network IDs is that packets moving from the external network to the DMZ segment are routed. Routers can only route packets between different network IDs. Routers will not route packets between two interfaces on the same network (moving packets between two interfaces on the same network ID would be considered “bridging”).When you configure the ISA server as a trihomed DMZ, you are creating a routed connection between the external interface and the DMZ segment. The fact that the ISA server acts as a mere packet filtering router between the external interface and the DMZ segment is something you should consider before implementing the trihomed DMZ.While a packet filtering router certainly has its place, you might want a bit more access control over what moves into and out of your DMZ than what a packet filtering router has to offer. The packets moving between the external interface of the ISA server and the DMZ segment are not subject to the Firewall or Web Proxy services’ access policies.You cannot control inbound or outbound access to and from the DMZ segment using user/group identification and destination sets. In addition, you can’t take advantage of the protection you would receive by NATing between the external interface and the DMZ segment. Access control into and out of the DMZ segment is based solely on: ■

Source IP address

■

Destination IP address

■

Source TCP or UDP port

■

Destination TCP or UDP port

■

ICMP type and code

■

IP Protocol number

The trihomed DMZ configuration introduces a single point of failure. If a network intruder is able to compromise the ISA Server computer configured for a trihomed www.syngress.com

71

72


DMZ, that attacker will have access to the DMZ segment and the internal network. In contrast, if you used a back-to-back DMZ configuration, the intruder would only compromise the external ISA server and have access to the DMZ segment. He would have to start all over again on the internal ISA server in order to access the internal network. If the trihomed DMZ still sounds like something you want to do, then continue reading as we describe how to configure a trihomed DMZ.There are several “gotcha’s” to the trihomed DMZ configuration. Pay close attention and you’ll get it done right the first time!

The Network Layout In our trihomed DMZ lab, we’ll configure the trihomed DMZ according the layout shown in Figure 2.1.There are three network segments: ■

The public network: 192.168.1.0/24

■

The DMZ segment: 192.168.1.0/26 (subnet ID 64)

■

The internal network: 10.0.0.0/24

Note that the DMZ segment hosts will be on a network ID different from the external interface of the ISA server. In this example, we are using a private network ID on the external interface and the DMZ interface. In a production environment, both the external and DMZ interfaces would be connected to public networks. Note that we’ve subnetted the external network ID so that we can represent the situation you’ll run into when subnetting your public address block. Let’s look at the server configuration more closely so that you can use these to configure your own trihomed DMZ test setup.

CLIENTDC Here is the server configuration for the CLIENTDC computer on the internal network. IP Address: 10.0.0.2/24 DG: 10.0.0.1 (the internal interface of the ISA Server) DNS: 10.0.0.2 WINS: 10.0.0.2 DNS Service installed and configured to resolve public host names WINS Service installed Active Directory installed Microsoft Exchange 2000 installed NetBIOS Name: CLIENTDC FQDN: CLIENTDC.internal.net

www.syngress.com


Figure 2.1 ISA Server with a Trihomed DMZ Configuration

10.1.1.2/24

10.1.1.1/24 192.168.1.199/24 192.168.1.0/24 192.168.1.33/24 192.168.1.67/24 192.168.1.0/26 192.168.1.69/24 10.0.0.1/24 SMTPDMZ

10.0.0.0/24 10.0.0.2/24 CLIENTDC

ISA Here is the configuration for the internal, external and DMZ interfaces on the ISA server.

Internal Interface IP Address: 10.0.0.1/24 Default Gateway: None DNS: 10.0.0.2 WINS: 10.0.0.2

External Interface IP Address: 192.168.1.33/24

www.syngress.com

73

74

Chapter 2 • Defense Plan 1: The Trihomed DMZ Default Gateway: 192.168.1.199 (the internal interface [LAN interface] of the router) DNS: NONE WINS: NONE

DMZ Interface IP Address: 192.168.1.67/26 Default Gateway: None DNS: NONE WINS: NONE DNS Service NOT installed WINS Service NOT installed Active Directory NOT installed NetBIOS Name: TRIHOMEISA FQDN: TRIHOMEISA.internal.net Member of the internal network domain.

DMZSMTPRELAY IP Address: 192.168.1.69/26 DG: 192.168.1.67 (the ISA Server's DMZ interface) DNS: NONE WINS: NONE No services installed except Internet Information Services NetBIOS Name: SMTPDMZ FQDN: SMTPDMZ.external.net

Router The router in this lab is a dual-homed Windows 2000 computer configured as a router using the Routing and Remote Access Service (RRAS).

Interface #1 (the DMZ Interface) IP Address: 192.168.1.199/24 Default Gateway: NONE DNS: NONE WINS: NONE

www.syngress.com


Interface #2 (the Public Interface) IP Address: 10.1.1.1 Default Gateway: NONE DNS: NONE WINS: NONE NetBIOS name: ROUTER FQDN: N/A No services installed other than RRAS

Laptop (External Network Client) IP Address: 10.1.1.2/24 DG: 10.1.1.1 (the public interface of the router) DNS: 10.0.0.2 WINS: 10.0.0.2 No services installed NetBIOS name: EXTERNALCLNT FQDN: N/A

This configuration is pretty much the standard one we’ll been using throughout the book.The primary difference is that Exchange 2000 is installed on a domain controller on the internal network.We did this so we could test the SMTP relay server on the DMZ segment’s ability to forward SMTP messages to Exchange 2000 Server’s SMTP service on the internal network. Note the default gateway configuration on the DMZ host machine.The default gateway for all hosts on the DMZ segment is the IP address of the ISA Server interface connected to the DMZ segment. One of the more common errors we see is that ISA Server administrators configure the DMZ hosts to use the external interface (or even the internal interface) of the ISA server as the default gateway.

Configuring the ISA Server You should plan your ISA Server configuration in advance, and then configure the server accordingly.The reason for this is the ISA server doesn’t like you to add and remove interfaces after the ISA Server software is installed.This is not to say that you can’t add and remove interfaces, it’s just that you might run into unexpected and difficult to troubleshoot problems if you do. It’s a far superior decision to install and configure the interfaces on the ISA Server computer before you actually install the ISA Server software. www.syngress.com

75

76


There will be times when you need to add or remove an interface after installing the ISA Server software. One way to make sure that nothing expected happens is to uninstall ISA Server and then reinstall it after adding or removing the interface.The drawback of this approach is that you need to reconfigure the ISA server.You can use one of the available import/export scripts to do this, but these scripts don’t store the entire server configuration (such as the SMTP filter settings).

ISA SERVER ALERT You can’t use the ISA Server integrated backup file together with an ntbackup of ISA Server folder hierarchy and the system state because the system state is no longer valid after adding or removing an interface. The ISA Server integrated backup file is only useful for restoring a previous configuration on the same ISA Server installation. If you uninstall and reinstall, the integrated backup file will be of no use.

Use the following procedure to add or remove an interface: 1. Go into the Services applet in the Administrative Tools menu and set the startup type of the following services to disabled: ■

Microsoft Web Proxy

■

Microsoft Firewall

■

Microsoft ISA Server Control

■

Microsoft Schedule Content Download

■

Microsoft H.323 Gatekeeper

2. Shut down the ISA server and add the interface. 3. Start the ISA server and log in as an administrator. 4. After adding the new interface, configure the TCP/IP settings for that interface. If you removed an interface, there’s nothing more you need to do. 5. Go back into the Services applet in the Administrative Tools menu and set the startup type for each of the ISA Server services to automatic. 6. Restart the ISA server. All the services should start up normally. Confirm that the ISA Services started normally by checking the Application log in the Event Viewer. ISA Server also doesn’t appreciate it if you change the IP address on any of its interfaces while the ISA Server services are running.You might want to change IP

www.syngress.com


addressing information on the interfaces while working with your trihomed ISA Server setup, as it’s common to test out different subnetting configurations. If you want to change IP addressing information on the ISA Server computer’s interfaces after ISA Server is installed, perform the following procedure: 1. At the command prompt, type net stop mspfltex and press Enter to stop the services listed. 2. Next, type net stop gksvc and press Enter to stop the Gatekeeper service. 3. Now, type net stop IPNAT and press Enter to stop the NAT driver. 4. Change the IP addressing information on the interface of your choice. 5. After changing the IP addressing information, type net start mspfltex at the command prompt and press Enter. 6. Type net start IPNAT and press Enter to start the ISA Server NAT driver. 7. After starting the packet filter extensions and the NAT driver, type net start isactrl to start the ISA Server Control Service. 8. Start the Web Proxy and Firewall services by using net start “Microsoft Web Proxy” and net start “Microsoft Firewall” (the quotation marks are required). The ISA Server services should start up without problems and you won’t need to restart the ISA Server computer.

Ping Testing the Connections We agree that ping is one of the most useful tools in our network diagnostics armamentarium.This is especially true when testing connectivity between the computer interfaces participating in your trihomed DMZ configuration.This brings us our first challenge: the default settings on the ISA server do not allow us to ping any of the interfaces we need to test in our trihomed DMZ.

ISA SERVER ALERT Perform this testing only when the ISA server is not connected to the Internet. Although ISA Server is able to handle denial of service (DoS) exploits based on ping, allowing ping requests to the external interface is considered a security risk. Enable the ping filters during your testing while not connected to the Internet, and then disable the ping filters when testing is done and before you connect the server to the Internet.

www.syngress.com

77

78


There are several packet filters included in the default ISA Server configuration: ■

ICMP unreachable in

■

ICMP timeout in

■

ICMP source quench

■

ICMP ping response (in)

■

ICMP outbound

■

DNS filter

■

DHCP client

The ICMP unreachable in packet filter allows the ISA server to receive ICMP unreachable messages from routers on the Internet.The ICMP timeout in packet filter allows the ISA server to receive ICMP timeout messages from Internet routers.These ICMP timeout messages are critical to the functioning of tracert, so if you want to use tracert to test external network hosts, don’t delete that filter! The ICMP source quench filter allows the ISA server to receive ICMP source quench messages from upstream routers.The source quench message allows routers to tell the ISA server to slow down sending data because the router sending the message is too busy.The ICMP ping response (in) filter allows the ISA server to receive ICMP query responses to an outbound ping request. If the ISA server did not have this filter, it would be able to send outbound pings (ICMP query requests), but wouldn’t be able to accept the ping responses (ICMP query responses).

NOTE Many cable companies employ DHCP technologies that prevent the ISA server from rebinding the same IP address. When the ISA server tries to use a DHCP request message to rebind its IP address, it receives a NACK from the DHCP server and must go through the DHCP discover process. This keeps the ISA server acting as a DHCP client from keeping the same IP address across lease periods. The cable companies believe this will discourage users from setting up Internet servers (such as Web, FTP, and SMTP) on their connections. You can use Jim Harrison’s ISA_IP_Refresh.vbs tool to get around this problem. Just schedule this tool to run before 50 percent of your lease period runs out. Make sure to make this a recurring schedule. Download this tool at http://isatools.org.

The ICMP outbound filter allows all ICMP message types and codes outbound from the ISA server and from the internal network.The ISA Server computer will always be www.syngress.com


able to use this filter, but on the internal network, only SecureNAT clients will be able to use this filter. If an internal network client is configured as only a Firewall and/or Web Proxy client, it won’t be able to use the ICMP outbound filter. Only the SecureNAT client configuration can use non-TCP/UDP protocols. The DNS filter allows the ISA server to send and receive DNS queries and perform its duties as proxy DNS server for Web Proxy and Firewall clients.The DHCP client filter allows the ISA server to use DHCP on the external interface.While this isn’t an optimal situation, the ISA server can support DHCP on its external interface.

Creating an Inbound ICMP Ping Query Packet Filter on the ISA Server External Interface We need packet filters to allow ping testing.The first interface we should test is the ISA server’s external interface. A packet filter to allow inbound ICMP Ping Query must be created in order to ping the external interface of the ISA server. Perform the following steps to create the inbound ICMP Ping Query packet filter: 1. In the ISA Management console, expand your server name and then expand the Access Policies node. Right-click on the IP Packet Filters node, point to New, and then click Filter. 2. Type the name of the filter on the first page of the IP Packet Filter Wizard (Figure 2.2). In this example, we’ll call it ICMP Ping Query (in) and click Next. Figure 2.2 The New IP Packet Filter Welcome Page

www.syngress.com

79

80


3. On the Filter Mode page (Figure 2.3), select Allow packet transmission and click Next. Figure 2.3 The Filter Mode Page

4. On the Filter Type page (Figure 2.4), select the Predefined option button and click the Down arrow in the drop-down list box. Select the ICMP ping query filter and click Next. Figure 2.4 The Filter Type Page

www.syngress.com


5. On the Local Computer page (Figure 2.5) select the IP address on which you want to receive the ICMP ping query messages. In this example, we have a single IP address bound to the external interface of the ISA server. Because there is a single IP address on the external interface, we can select the Default IP addresses for each external interface on the ISA Server computer. This allows 192.168.1.33 to accept ICMP ping query messages.What if we had multiple IP addresses bound to the external interface of the ISA server and we wanted to allow inbound ICMP ping query requests on each address? In that case, we need to create several inbound ICMP ping query packet filters; one for each IP address bound to the external interface of the ISA server. There is no way to create a single “global” inbound ICMP ping query packet filter. Select the default option and click Next. Figure 2.5 The Local Computer Page

6. On the Remote Computers page (Figure 2.6), select which remote computer will be able to send ICMP ping query messages. In this case, we want to allow all remote computers to send the query. Select All remote computers and click Next. 7. Review the settings on the last page of the wizard and click Finish. 8. From the external client computer (Laptop), open a command prompt and type ping 192.168.1.33.You will see replies to your ICMP ping queries.The reason for this is the ISA server has a packet filter allowing it to receive your ping query messages.The ISA server already had a pre-built packet filter that allowed it to respond, the ICMP outbound packet filter.

www.syngress.com

81

82


Figure 2.6 The Remote Computers Page

9. Go back to the client computer and type ping –t 192.168.1.33. Return to the ISA server and right-click on the ICMP ping query packet filter you just created and click the Disable command. Notice that it takes a few seconds for the packet filter to turn itself off. Once you see the ping queries time out, go back to the ISA Server computer and enable the inbound ICMP ping query packet filter.Watch how long it takes for the packets to be allowed.

Creating an Inbound ICMP Ping Query Packet Filter to the DMZ Host’s Interface Creating packet filters to allow access to the external interface of the ISA server is easy. You can use the built-in packet filter types when you run the wizard and get it right every time.Things aren’t quite so straightforward when you create packet filters to allow access to the hosts on the DMZ segment. Let’s create a packet filter that allows inbound ICMP query messages to the DMZ host at 192.168.1.69 (refer to Figure 2.1 to refresh your memory on the setup).The packet filter looks like what you see in Figures 2.7 and 2.8.This packet filter allows inbound ICMP query requests to the DMZ host computer. Notice in Figure 2.8 that we included the IP address of the specific DMZ host’s IP address. If you want to allow pings to all the hosts on the DMZ segment, you could select the These computers (on the perimeter network) option and enter the network ID and subnet mask for the DMZ segment.

www.syngress.com


Figure 2.7 The Filter Type Tab on the DMZ Ping Query Packet Filter

Figure 2.8 The Local Computer Tab on the DMZ Ping Query Packet Filter

ISA SERVER ALERT You don’t need a packet filter to allow ICMP queries to the external interface of the ISA server in order to allow the ISA server to pass through the ICMP query to the DMZ host. This means you can deny ICMP Query messages to the external interface of the ISA server and allow ICMP Query messages to a host on the DMZ segment.

www.syngress.com

83

84


Go to the external network client computer (Laptop) and ping 192.168.1.69 after you create the DMZ Ping Query (in) packet filter.What happened? It didn’t work! Why? The reason the ping request from the external network client didn’t work is that there wasn’t a packet filter allowing an outbound response to the incoming ICMP ping query packet.You might think that if you created a packet filter allowing incoming ICMP ping query packets that the ISA server would create a “dynamic packet filter” that would automatically open a filter for a response—it doesn’t. The packet filter allowing the DMZ host to reply to the incoming ICMP ping query looks like what you see in Figures 2.9 and 2.10. Figure 2.9 The Filter Type Tab for the DMZ ICMP Response Packet Filter

Figure 2.10 The Local Computer Tab on the DMZ Ping Response Packet Filter

www.syngress.com


ICMP Echo Reply (ping response) messages have a Type value of 0 and a Code value of 0. ICMP Echo Request (ping query) messages have a Type value of 8 and a Code value of 0.

NOTE The Internet Message Control Protocol (ICMP) is used for more than just ping and tracert diagnostic testing. For a good overview of ICMP, check out Microsoft’s KB article Q170292 “Internet Control Message Protocol (ICMP) Basics.”

Now with the two filters DMZ Ping Query (in) and DMZ Ping Response (out) the DMZ host computer will be able to accept the ping queries and send out ping responses. Go to the external client computer (Laptop) and ping the DMZ host at 192.168.1.69. Bingo! It works.

Pinging the ISA Server Interfaces from the DMZ Hosts The DMZ host needs to be able to communicate with its default gateway, which is the IP address of the ISA Server interface on the DMZ segment. It’s important to test connectivity with the DMZ interface, and ping is a good tool to test connectivity. There’s just one problem: you can’t ever ping the ISA Server interfaces from a DMZ host! It seems somewhat strange that a DMZ host can’t ping a local interface, especially when that interface is the DMZ host’s default gateway. It appears that it’s the responsibility of the ISA Server Control Service (isactrl) for blocking the ICMP echo requests from the DMZ host to the ISA Server’s DMZ interface. If you go to the command prompt and type net stop isactrl, it will stop a number of services.You’ll also notice that you can now ping the ISA Server DMZ interface from the DMZ host computer. If you type net start isactrl at the ISA Server computer, only the ISA Server Control Service will start; the Firewall service will not automatically start with it.Try pinging the ISA Server’s DMZ interface now. It doesn’t work! Since we can’t create any packet filter or set of packet filters to allow pinging any of the ISA Server interfaces from a DMZ host, we’ll have to find another method to test connectivity between the ISA server and the DMZ host.The best way to do this is to configure packet filters that allow external network clients to ping DMZ hosts.

Creating a Global ICMP Packet Filter for DMZ Hosts In the previous examples, we tried to be selective and created packet filters for very specific traffic. In actual practice you might find it better to create an “all purpose”

www.syngress.com

85

86


ICMP packet filter that will allow all hosts on the DMZ segment to use ICMP to ping external hosts and to be pinged by external hosts. Figures 2.11 and 2.12 describe this custom packet filter. Notice in this DMZ ICMP All (both) packet filter that traffic is allowed in both directions for all ICMP types and all ICMP codes. For the Local Computer, we include the entire IP subnet rather than a particular host on the subject.This makes it simple to ping any host on the DMZ segment from an external host, and to ping an external host from any DMZ host. Figure 2.11 The Filter Type Tab on the DMZ ICMP All Packet Filter

Figure 2.12 The Local Computer Tab on the DMZ ICMP All Packet Filter

www.syngress.com


Publishing DMZ SMTP Servers SMTP servers often find themselves on DMZ segments.The SMTP server is a good candidate for the DMZ segment because it must accept incoming SMTP messages from Internet-based SMTP servers.This direct contact with Internet servers makes the SMTP server computer vulnerable to attack, and thus a candidate for a DMZ segment. You can create a packet filter to allow incoming SMTP messages to the SMTP server on the DMZ.Your first thought might be that you can use the predefined SMTP server packet filter—wrong! The reason for this is the SMTP server needs to negotiate a series of instructions with the SMTP client machine. If you use the predefined SMTP server packet filter (when you run the Packet Filter Wizard), you won’t be able to receive SMTP mail on the DMZ SMTP server. Try this: Run the Packet Filter Wizard on the ISA server. On the Filter Type page, select the SMTP filter. Configure the filter to allow SMTP traffic to the DMZ host computer and allow all remote computers to use the filter. Figure 2.13 shows the predefined SMTP selected on the Filter Type page of the Packet Filter Wizard.This SMTP packet filter allows inbound access to TCP port 25. Figure 2.13 The Filter Type Page

After creating the SMTP filter, go to the external network client, open a command prompt, and try to telnet to the SMTP service on the DMZ host. Using our network diagram, you would go to the Laptop computer, open a command prompt, type telnet 192.168.1.69 25, and press Enter (Figure 2.14).

www.syngress.com

87

88


Figure 2.14 The Telnet Attempt Fails

As we discussed earlier, these predefined packet filters work just fine when the service you want to make available is listening on the external interface of the ISA server. For example, if you were running Exchange 2000 on the ISA server itself, you could create an SMTP packet filter using the predefined SMTP packet filter settings found in the Packet Filter Wizard and the packet filter would work great! However, as you’ve seen, the predefined packet filters don’t work very well for DMZ hosts. Since the predefined packet filter doesn’t work, you’ll need to create a custom SMTP packet filter. Use the Custom option in the Packet Filter Wizard. On the Filter Settings page, configure the options as shown in Figure 2.15.This is a bidirectional filter.This custom filter allows all TCP source ports to send messages to TCP port 25 on the DMZ host computer. Moreover, because the packet filter is bidirectional, the DMZ host computer can send messages to all ports from its own TCP port 25.This allows the SMTP client on the external network to send messages, and the SMTP server on the DMZ segment to receive responses (Figure 2.16). After creating your bidirectional SMTP server packet filter, go back to the external network client and try to telnet to the DMZ SMTP Server host computer again.You should see something like what appears in Figure 2.17.The successful telnet session indicates that the channel between the external client and the SMTP server on the DMZ segment is intact.

www.syngress.com


Figure 2.15 Creating a Custom Filter for SMTP Messages

Figure 2.16 Inbound and Outbound Packets Allowed by the Custom SMTP Packet Filter

Outbound packets: Source Port TCP 25 Destination Port ANY

Inbound packets: Source Port ANY Destination Port TCP 25

DMZ Host Internal network

www.syngress.com

89

90


Figure 2.17 Custom SMTP Packet Filter Allows a Successful Telnet Session

Publishing a DMZ SMTP Mail Relay Server In the last section, you saw how you can publish an SMTP server on a DMZ segment. Let’s now take this one step further and see how you publish an SMTP mail relay server on the DMZ segment. The DMZ host acting as an SMTP relay will relay mail to another SMTP server under your control. In our example network, the SMTP server on the DMZ segment is configured to relay mail to the Exchange server on the internal network.We need to fulfill the following requirements to make this scenario work: ■

A packet filter to allow incoming SMTP messages to the DMZ mail relay server.

■

Remote domains configured on the mail relay server to allow relay for mail domains under your administrative control.

■

A second packet filter to allow the SMTP mail relay server to send mail to the Exchange 2000 SMTP server on the internal network.

■

A server publishing rule that makes the internal network SMTP server available to the DMZ SMTP relay server.There are two ways you can do this: 1) configure the server publishing rule to allow connections on the external interface, and 2) configure the server publishing rule to allow connections from the DMZ interface.

www.syngress.com


Figure 2.18 shows our goals in terms of network traffic flow for the first scenario: 1. A packet filter allowing inbound TCP 25 from any port.This packet filter allows any Internet host to send SMTP messages to the mail relay server on the DMZ segment. 2. A second packet filter allows the DMZ SMTP relay server to send packets to the IP address on the external interface of the ISA server that is used to publish the internal network Exchange 2000 SMTP service.We need to create this packet filter to allow the DMZ SMTP server to have access to the server publishing rule. 3. A server publishing rule that allows the DMZ mail relay server to send packets to the internal network Exchange 2000 SMTP service. Figure 2.18 Publishing a DMZ Mail Relay Server 1

Packet filter allows inbound TCP 25 from external network hosts

2

Packet filter allows DMZ SMTP relay to send packets to the external IP address of the ISA Server used in the SMTP Server Publishing Rule

3

Server Publishing Rule allows the DMZ SMTP relay to send packets to the internal network Exchange 2000 SMTP service 2 3

1

DMZ Host Internal network

The packet filter you created to allow incoming SMTP messages to the DMZ mail relay server is the same as the one you created in the previous section (Figure 2.15). However, in the first scenario, you need a second packet filter to allow the SMTP mail www.syngress.com

91

92


relay to send mail to the internal network Exchange 2000 SMTP service (the DMZ mail relay server acts as an SMTP client in this circumstance). Figures 2.19 through 2.21 demonstrate the packet filter you need to create to allow the SMTP relay server to send SMTP messages to the published Exchange 2000 SMTP server when the Exchange 2000 SMTP service is published on the external interface. Figure 2.19 Packet Filter Allows Outbound TCP 25

Figure 2.20 Limiting the Packet Filter to a DMZ Host

Note this packet filter’s level of selectivity. On the Local Computer tab (Figure 2.20), you see that it applies only to the SMTP mail relay server. Only the SMTP mail relay www.syngress.com


server will be able to use this filter to send out messages to TCP port 25.You can see on the Remote Computer tab (Figure 2.21) that this filter will only allow outgoing messages to TCP port 25 to be sent to 192.168.1.33.This is the IP address on the external interface of the ISA server on which we will publish the internal network Exchange server’s SMTP service. Figure 2.21 Setting the Remote Computer Limitation for the Packet Filter

ISA SERVER ALERT Remember that the DMZ segment and the external interface of the ISA server are on different network IDs. In Figures 2.19 through 2.21, notice that the DMZ host is IP address 192.168.1.69 and the external interface of the ISA server is at 192.168.1.33. These might appear to be on the same network ID if you’re used to working with classfull addressing. However, the DMZ segment uses 26 bits for its network ID and is on subnet ID 64, which puts the DMZ segment on a different network ID from the external interface.

You need to create remote domains on the SMTP mail relay server to prevent your DMZ SMTP server from becoming an open relay.The remote domains allow the SMTP mail relay server to receive mail for mail domains under your administrative control and reject incoming mail for all other mail domains.This prevents spammers from using your DMZ mail relay server as a gateway for their evil spamming deeds! Perform the following steps to create the remote domain, and configure the remote domain to relay to the published SMTP server:

www.syngress.com

93

94


1. Open the Internet Information Services console from the Administrative Tools menu. 2. Expand the server name and then expand the Default SMTP Virtual Server node. 3. Right-click the Domains node, point to New, and click Domain. 4. On the first page of the New SMTP Domain Wizard (Figure 2.22), select the Remote option and click Next. Figure 2.22 Specifying a Remote Domain

5. On the Select Domain Name page of the New SMTP Domain Wizard (Figure 2.23), type in the name of your mail domain. For example, if your Exchange server will be accepting mail for your users at external.net, type in external.net in the Name text box. Click Finish. 6. Double-click on the remote domain you created. Place a check mark in the Allow incoming mail to be relayed to this domain check box (Figure 2.24).This allows the SMTP service to forward mail sent to this mail domain. Select the Forward all mail to smart host option, and then type in the IP address of the external interface of the ISA server used in the server publishing rule to publish the internal network SMTP server.The reason why you put the external address of the ISA server is that the external interface is listening on behalf of the internal network’s SMTP server. It is important that you put the IP address in brackets. If you don’t, the SMTP server will treat it as an FQDN and try to resolve the IP address to an IP address! Click Apply, and then click OK.

www.syngress.com


Figure 2.23 The Select Domain Name Page

Figure 2.24 Configuring the Relay

ISA SERVER ALERT It’s extremely important that you use square brackets when you configure the IP address of the smart host. If you use parentheses, it will not work! If you find that messages are not being forwarded to your smart host, double check that you included the straight brackets ( [ ] ) in your smart host configuration.

www.syngress.com

95

96


The final step is to create the server publishing rule for the internal network SMTP server.The publishing rule includes a client address set that we’ll use to prevent any server except the one on the DMZ from sending mail to it. 1. Expand the Publishing node in the left pane of the ISA Management console, and right-click the Server Publishing Rules node. Point to New and click Rule. 2. Give the rule a name on the first page of the New Server Publishing Rule Wizard. In this example, we’ll name the rule Exchange SMTP Service. Click Next. 3. On the Address Mapping page (Figure 2.25), put in the internal IP address of the Exchange server and the IP address on the external interface of the ISA server on which you want to listen for incoming SMTP messages. Click Next. Figure 2.25 Creating the Address Mapping

4. On the Protocol Settings page, select the SMTP Server protocol. Click Next. 5. On the Client Type page, select the Specific computers (client address sets) option. 6. On the Client Sets page (Figure 2.26), click Add to add the client address set. In this example, we’ve already created a client address set named 69.The IP address 192.168.1.69 is included in this client address set.When we limit access using this client address set, only the computer with the source IP address 192.168.1.69 will be able to use this rule to send incoming SMTP

www.syngress.com


messages to the internal network Exchange server. Click Next after adding the client address set. Figure 2.26 Creating a Client Address Set

7. Review the settings on the last page of the wizard. If they are correct, click Finish. If you made a mistake, click Back to get to the place where you can fix it. That’s it! The only thing left is to add the address of your SMTP relay server to a public DNS server so that Internet hosts can access the MX records for your mail domain. External SMTP clients and servers will be able to send mail to the SMTP mail relay server on the DMZ.The SMTP mail relay server forwards the mail to the internal network Exchange server via the external IP address on the ISA server used in the SMTP server publishing rule. With this setup, no computer on the Internet can send mail directly to the internal network SMTP server via the server publishing rule, because the client address set in the SMTP server publishing rule limits access to the rule so that only the SMTP mail relay server on the DMZ segment can use it.You can test this yourself by trying to telnet into the internal network Exchange server from a host other than the one included in the client address set. It won’t work! The first scenario shows how you can use packet filters to allow the DMZ host to send traffic to the external interface of the ISA server to access the published Exchange 2000 server. Another way to allow only the SMTP mail relay server on the DMZ segment to access the Exchange 2000 SMTP service on the internal network is to use the DMZ interface IP address in the server publishing rule. In this case, the ISA server will

www.syngress.com

97

98


only listen for SMTP messages on the DMZ interface; it will not listen for SMTP messages on the external interface. In this case, you need to configure the following (Figure 2.27): ■

A packet filter allowing external network hosts to send SMTP messages to the DMZ mail relay server

■

Remote domains on the DMZ mail relay server

■

A server publishing rule that publishes the internal network Exchange 2000 SMTP service to the IP address on the DMZ interface of the ISA server

Figure 2.27 SMTP Server Publishing Rule on the DMZ Interface 1

Packet filter allows inbound SMTP messages to SMTP relay server

2

Smart host configuration causes SMTP relay to forward SMTP messages to DMZ interface used in Server Publishing Rule

3

Server Publishing Rule forwards SMTP messages to Exchange 2000 SMTP service

3

1

2 DMZ Host Internal network

This configuration limits connections to the Exchange 2000 SMTP server publishing rule to the IP address of the ISA server’s DMZ interface. In this case, you do not need to create a packet filter to allow the DMZ host access to the IP address of the ISA server’s DMZ interface because the DMZ interface is local to the SMTP relay server. The server publishing rule should be configured to allow only the DMZ mail relay server access to the server publishing rule.

www.syngress.com


Publishing a Web Server Publishing a Web server on the DMZ segment is easy. Create a packet filter that allows bidirectional traffic with the destination being TCP port 80, from any source port. Select the Custom option in the New Packet Filter Wizard, and then use the settings shown in Figure 2.28. Figure 2.28 HTTP Packet Filter

Although you don’t get all the frills, bells, and whistles you get when you publish a Web site using a Web publishing rule, publishing a site on a DMZ segment using a packet filter has one big advantage: you get the actual source IP address of the host making the request in the Web server’s log files (Figure 2.29).This is a limitation of Web publishing; you could also get the source IP address of the Internet host in the Web server’s log files by putting the Web server on the internal network and using a server publishing rule.

Publishing an FTP Server on a Trihomed DMZ Segment The File Transfer Protocol (FTP) is one of the most popular, but also the most misunderstood protocol.We get questions every day from router and firewall administrators asking why a particular FTP client or server configuration isn’t working. If these administrators understood how FTP works, they could easily solve their FTP problems. Once you understand FTP and how it affects your firewall or router configuration, you’ll be in much better shape to fix your FTP-related problems.

www.syngress.com

99

100


Figure 2.29 Log File Showing the IP Address of the Internet Host Computer

How FTP Works FTP is a messy protocol in that it requires multiple connections, sometimes in both directions. In the ISA Server world, we call protocols that require multiple connections “complex protocols.” How connections are made depend on the FTP protocol mode. There are two FTP modes: ■

Normal or PORT or Active

■

Passive or PASV

Normal or PORT or Active Mode FTP When an Active mode FTP client sends a request to an FTP server, the client opens two response ports.The first is used to send a request to the FTP server on the server’s TCP port 21.This creates the FTP command channel. FTP commands and responses are sent to and from the FTP server and client through the command channel.The second response port is used to accept data from the FTP server. When the FTP client establishes the command channel link, the FTP client sends over the command channel a request for data. Included in this request is a response port (the second port opened by the FTP client) to which the FTP server can send the data. The FTP server sends the data from the FTP server’s TCP port 20 to the response port indicated by the FTP client in the PORT command. For example, a PORT mode FTP client wants to obtain a file from an FTP server. The sequence of events would go like this: www.syngress.com


101

1. FTP client opens response ports TCP 6000 and TCP 6001 (random ports in the high number range). 2. FTP client sends a request to open a command channel from its TCP port 6000 to the FTP server’s TCP port 21. 3. FTP server sends an “OK” from its TCP port 21 to the FTP client’s TCP port 6000 (the command channel link).The command channel is established at this point. 4. FTP client sends a data request (PORT command) to the FTP server over the command channel.The FTP client includes in the PORT command the data port number it opened to receive data. In this example, the FTP client opened TCP port 6001 to receive the data. 5. FTP server opens a new inbound connection to the FTP client on the port indicated by the FTP client in the PORT command.The FTP server’s source port is TCP port 20. In this example, the FTP server sends data from its own TCP port 20 to the FTP client’s TCP port 6001. Note in this conversation that two connections were established: an outbound connection initiated by the FTP client, and an inbound connection established by the FTP server. It’s also important to realize that the information contained in the PORT command (sent over the command channel) is stored in the data portion of the packet.

Passive or PASV Mode FTP Passive or PASV mode is the most popular implementation of FTP, the reason being that PASV mode is a bit more secure because it does not require you to allow new inbound connections. Most popular browsers default to PASV mode FTP when the browser is used to access FTP sites. One of the major advantages of PASV mode is that the FTP server does not need to create a new inbound connection when responding to the FTP client’s request for data. All new connections are outbound connections. As we’ll see later, this can make PASV FTP more firewall friendly. The PASV mode FTP client opens two response ports when it initiates a connection with the FTP server.This is similar to how the PORT mode FTP client behaves. The initial connection establishes the command channel.The FTP server accepts the command channel request on its own TCP port 21. After establishing the command channel, the FTP client sends to the FTP server a PASV command through the command channel.The PASV command tells the FTP server to open a port for the data channel.The FTP server opens a TCP port in the ephemeral port range (>1023) and tells the FTP client the port number opened via the command channel. Once the FTP client obtains the TCP port number for the data

www.syngress.com

102


channel, the FTP client initiates a new connection to the FTP server to establish the data channel. For example, a PASV mode FTP client wants to obtain data from an FTP server. The sequence of events would go like this: 1. FTP client opens response ports TCP 6000 and TCP 6001 (random ports in the ephemeral port range). 2. FTP client sends a request to open a command channel from its TCP port 6000 to the FTP server’s TCP port 21. 3. FTP server sends an “OK” from its TCP port 21 to the FTP client’s TCP port 6000.The command channel is now established. 4. FTP client sends a PASV command requesting that the FTP server open a port number that the FTP client can connect to establish the data channel. 5. FTP server sends over the command channel the TCP port number with which the FTP client can initiate a connection to establish the data channel. In this example, the FTP server opens port 7000. 6. FTP client opens a new connection from its own port TCP 6001 to the FTP server’s data channel 7000. Data transfer takes place through this channel.This represents a new outbound request made by the FTP client. Note that the PASV mode FTP client initiates all connections; the FTP server never needs to create a new connection back to the FTP client.This eliminates the need for the FTP server to create a “backchannel” or a new inbound secondary connection.

Challenges Created by the FTP Protocol Challenges the FTP protocol creates are different depending on whether you’re the client side or the server side firewall administrator. Let’s look at the FTP protocol from the following perspectives: ■

The PORT mode FTP client-side firewall

■

The PORT mode FTP server-side firewall

■

The PASV mode FTP client-side firewall

■

The PASV mode FTP server-side firewall

www.syngress.com


103

PORT Mode FTP Client-Side Firewall How do you handle PORT mode requests from your FTP clients? These are the ports you need to allow inbound and outbound to support PORT mode FTP client requests made from behind your firewall: ■

Outbound TCP port 21 (to support the control channel)

■

Inbound TCP ports 1024 and above (to support the data channel)

The packet filters required to support PORT mode FTP clients don’t lead to a very secure firewall/router configuration. Another significant problem is that you must allow new inbound connections (non-ACK packets) access to the internal network. Allowing new, unsolicited inbound connections to such as wide range of ports represents a definite security concern. One way of dealing with this problem is to allow inbound connections to the ephemeral ports from source port TCP 20. In this way, you limit access to what is assumed to be the FTP server data port.The problem is that there are a number of tools available allowing you to set your source port manually.You cannot be sure that incoming connections from TCP port 20 are actually sourcing from an FTP server.The reason for this is that packet filters do not examine the data portion of the request. You can improve on the situation somewhat by limiting inbound access to the high-number ports only from TCP port 20 and from a limited number of IP addresses of trusted FTP servers.The major drawback here is that you must be able to identify (in advance) the trusted FTP server addresses.You still have to be concerned with someone spoofing a source port and IP address.

PORT Mode FTP Server-Side Firewall What if you’re the firewall/router administrator who has to deal with an FTP server behind your firewall? In this case, you need to open the following ports: ■

Outbound TCP ports 1024 and above (to allow the FTP server to connect to the FTP client’s source port)

■

Inbound TCP port 21 (to allow the FTP client to establish the control channel)

This is less hazardous than the situation the FTP client-side firewall administrator has to handle. However, it’s still considered poor security practice to allow such a wide range of ports outbound access just to support a single server application. Any client on the internal network will have access to network services on the Internet that use the high-number TCP ports for a primary connection.

www.syngress.com

104


One way to improve the situation is to allow outbound access to the high-number ports only when the source port is TCP port 20. In this way, you can assume that only the FTP servers behind the firewall are able to connect to these high-number ports on the Internet.You could strengthen this even more by limiting access from TCP port 20 to the high-number ports to the IP addresses of the FTP servers on your internal network.You still have to deal with problems of spoofed IP addresses and manipulated port numbers.

PASV Mode FTP Client-Side Firewall If you’re the firewall administrator on the PASV mode FTP client side, you’ll need to open the following ports: ■

Outbound TCP port 21 and TCP ports 1025 and above (to allow the FTP client outbound access to the FTP server’s control channel and data ports)

■

Inbound TCP ports 1025 and above (to allow the FTP server to send data to the FTP client)

The port requirements aren’t that different from those required by the PORT mode FTP client, with the exception that the PASV mode FTP client requires outbound access to TCP ports 1025 and above.While this doesn’t seem like a big difference, it is in fact a tremendous difference. In order to allow the PASV mode FTP client outbound access to the FTP server, you must let these clients have outbound access to all high-number ports. Since you have no way of determining in advance what high-number port the FTP server will assign to the data channel, all the high-numbered ports must all be opened outbound.

ISA SERVER DEFON 1 Note in this discussion that we’re talking about nonstateful packet filters. In this case, you need to open ports to allow the FTP server to send packets to the high-number ports the FTP client software opens to send and receive data. With a stateful firewall, you will not need to open these ports for PASV connections, because the response sent by the FTP server is over a connection already established by the FTP client. ISA Server is a stateful firewall when using protocol rules and publishing rules, but it is not stateful when passing packets to hosts on a public address trihomed DMZ segment.

This might be okay if you had a way to ensure that only the FTP clients access FTP servers on these ports.The problem is you cannot easily control what applications access what ports. Even if you did limit just FTP clients to these ports, you would be blocking other applications access to the high-number ports—a less than ideal situation! www.syngress.com


105

To add insult to injury, you must also allow inbound access to all high-number ports (assuming that your firewall is not stateful).The result is that you must allow inbound and outbound access to all high-number ports—an untenable security configuration. One way you can improve the packet-filtering situation is to limit access to outbound TCP 21 from certain clients. However, you still run into the spoofing problem. ISA Server solves this problem by using protocol rules, which can be applied to client address sets and/or users/groups.

PASV Mode FTP Server-Side Firewall These are the ports you need to open on the server side of the PASV mode connection: ■

Outbound TCP ports 1025 and above (so the FTP server behind the firewall can send responses to the FTP client)

■

Inbound TCP port 21 and TCP ports 1025 and above (so the FTP client can establish the command channel and the data channel)

This is the converse of the packet filter configuration required to support the FTP client.TCP ports 1024 and above must be opened for inbound and outbound access. You could get a modicum of control by limiting what IP addresses have access, but you run into the same problems as you do with the PASV clients.

Using Packet Filters to Publish the PORT Mode FTP Server Now that you understand FTP better, let’s get to the business of creating packet filters to support FTP servers in the DMZ. Let’s create packet filters to support the PORT mode FTP server. PORT mode requires that we allow inbound requests to TCP port 21 from any port, and outbound requests from TCP 20 to any port. Figure 2.30 shows the configuration for each of the packet filters. The first packet filter allows the inbound connection to TCP port 21 and establishes the control channel (Figure 2.31). It is set with the following parameters: ■

Filter name FTP 21 (in)

■

IP protocol TCP

■

Direction Both

■

Local port Fixed port

■

Local port number 21

■

Remote port All ports www.syngress.com

106


Figure 2.30 Creating Packet Filters to Support a PORT Mode FTP Server

1

Packet filter allows inbound TCP 21 from any IP address and any high port number

2

Packet filter allows outbound 1024 and above from the IP address of the FTP server at its TCP port 20

1

2

Internal network

DMZ FTP Server

Figure 2.31 Packet Filter to Allow Inbound TCP Port 21

The second packet filter allows the FTP server on the DMZ segment to send data out its TCP port 20 to the dynamic port opened by the FTP client computer (Figure 2.32). www.syngress.com

Defense Plan 1: The Trihomed DMZ • Chapter 2 ■

Filter name FTP 20 (out)

■

IP protocol TCP

■

Direction Both

■

Local port Fixed port

■

Local port number 20

■

Remote port All ports

107

Figure 2.32 Packet Filter to Allow the FTP Server to Respond from TCP Port 20

Using Packet Filters to Publish the PASV Mode FTP Server You can use packet filters to allow access to PASV mode FTP servers on your DMZ segment.The first packet filter allowing creation of the FTP control channel is the same as the one you created to allow PORT mode FTP connections.The second packet filter allows the FTP client on the external network to make the inbound connection request to the FTP server on a high port (Figure 2.33).These are the parameters for the packet filter to support the PASV mode FTP in the DMZ: ■

Filter name FTP PASV (in)

■

IP protocol TCP

■

Direction Both

■

Local port Dynamic

■

Remote port All ports www.syngress.com

108


Figure 2.33 Packet Filter to Allow Access to PASV Mode FTP Server

1

Packet filter allows inbound access to all high ports and outbound access to all high ports 1

Internal network

DMZ FTP Server

Notice that this isn’t the most secure packet filter.This filter allows all high source port connections to all dynamic port (ports 1024 through 5000) connections on the FTP server (Figure 2.34). Figure 2.34 Packet Filter for the PASV Mode FTP Server

www.syngress.com


109

Beware the “Allow All” Packet Filter Sometimes you just want to open all ports inbound and outbound to and from the DMZ segment for testing purposes.This “All Open” packet filter configuration is useful for “proof of concept” testing.You definitely don’t want to allow this filter to be active when the server is connected to the Internet. The “All Open” packet filter does not allow all traffic to move into and out of the DMZ segment. For traffic moving to and from the DMZ segment, you need to create “All Open” packet filters for ICMP,TCP, and UDP individually.The “All Open” packet filter requires at least three separate packet filters.

ISA SERVER ALERT Note that these three packet filters do not include an “All Open” IP protocol filter. If you need to allow access to particular IP protocols (such as IP protocol 47 for GRE), then you should create those packet filters separately.

For example, suppose you want to allow all TCP traffic inbound and outbound to and from the DMZ segment. Figure 2.35 shows the Filter Settings page in the New IP Packet Filter Wizard. If you wanted to create an “All Open” packet filter for UDP packets, just change the IP protocol to UDP. Figure 2.35 An “All Open” TCP Packet Filter

An ICMP “All Open” packet filter is shown in Figure 2.36.The IP protocol is set for ICMP.The direction is Both. The Type is All types, and the Code is All Codes.

www.syngress.com

110


Figure 2.36 An “All Open” ICMP Packet Filter

ISA SERVER DEFCON 1 Placing FTP servers in the DMZ segment requires that you open many ports to allow inbound and outbound access. You can get around this problem by placing your FTP servers on the internal network. You can take advantage of the FTP Access application filter when you use server publishing rules to publish FTP servers on the internal network. The FTP Access application filter will manage the ports for you. The FTP application filter will dynamically open the required ports, and then close them when the FTP session is complete. You can even place the FTP server in an internal network, LAT-based DMZ to improve security. We’ll discuss private address, LAT-based DMZ segments in Chapter 4. You’ll learn the inside information on FTP Server Publishing in Chapter 5, “Defense Plan 4: Advanced Server Publishing”.

External Network Clients Cannot Use the DMZ Interface to Connect to the Internal Network People have tried some unusual configurations with the trihomed DMZ setup. One of the most popular is trying to “loop through” the ISA server by publishing an internal network server via a server publishing rule so that the internal server is accessed through the DMZ interface by an external network client. As we covered earlier in our discussion on publishing the SMTP mail relay server, you can create a server publishing rule that listens only on the ISA server’s DMZ interface. www.syngress.com


111

Publishing servers to the DMZ interface works great when the client is a DMZ host. However, publishing servers to the DMZ interface does not work at all if the client is on the external network.The ISA server will not allow external network clients to access the DMZ interface. If you create a server publishing rule that listens on the DMZ interface, only hosts on the DMZ segment will be able to access the internal network server via this server publishing rule. This a nice security benefit of the trihomed DMZ. For example, if you create an SMTP server publishing rule that listens on the DMZ interface, an SMTP mail relay server can forward packets to an internal network SMTP server via the server publishing rule. External network clients, no matter how hard they try, will not be able to access the internal network SMTP server via the server publishing rule because the ISA server will never pass packets from the external interface directly to the DMZ interface. ISA Server likes to be efficient. It makes no sense to loop through the DMZ if you need to communicate with servers on the internal network. If you want external network clients to communicate with servers on the internal network, create a Web or server publishing rule that listens on the external interface of the ISA server. Sure, you can get to the internal network indirectly by using an intermediary computer such as an SMTP mail relay server, but you cannot loop through the DMZ interface to access an internal network server (Figure 2.37). It’s impossible so don’t even try. Figure 2.37 External Network Client Attempting to Loop through the External Interface to the ISA Server DMZ Interface 1

External network client attempts to access the public address DMZ interface on the ISA Server by going directly through the external interface

2

Packet is blocked from accessing the the DMZ interface. External network clients cannot directly access the DMZ interface on the ISA Server

3

Hosts on the DMZ segment can directly access the DMZ interface on the ISA Server

1

2 3 Internal network

DMZ Host

www.syngress.com

112


Summary In this chapter, we covered principles of trihomed DMZ configuration. Packets moving from the external network to the trihomed DMZ segment are always routed. Network Address Translation (NAT) never applies to packets moving between the external network and the trihomed DMZ segment.The reason for this is the trihomed DMZ segment must always contain public addresses. In addition, these packets are not subject to same access policies that control inbound and outbound access through publishing and protocol rules.The ISA server acts as a packet-filtering router instead of providing fullfeatured firewall capabilities available when you use publishing and protocol rules. In the next chapter, we’ll look at how you can take advantage of ISA Server’s full firewall capabilities by creating a private address back-to-back DMZ segment.

Defensive Tactic Fast Track Configuring a Trihomed DMZ ; Trihomed DMZ segments must always use public addresses. ; Access control to and from a trihomed DMZ segment is done with packet

filters. ; “Dynamic” packet filtering is not available when creating packet filters to

allow access to and from the trihomed DMZ segment.You must create explicit packet filters for both inbound access and outbound responses. ; The trihomed DMZ configuration provides a single point of failure. If

possible, you should consider implementing a back-to-back DMZ if you require a non-LAT-based DMZ segment. ; The external interface and the DMZ interface must be on different network

IDs. If you put the external and DMZ interfaces on the same network IDs, you create a bridge.You need to route packets, not bridge them. ; You can install multiple DMZ segments.The “trihomed” DMZ is an example

of a single public-address DMZ segment.You can add more DMZ adapters and have multiple public-address DMZ segments. However, you will need to subnet your block appropriately. ; The predefined packet filters apply to packets arriving at the external interface

of the ISA server.You need to create custom packet filters to allow packets to and from DMZ hosts.

www.syngress.com


113

Publishing DMZ SMTP Servers ; SMTP relay servers work well on DMZ segments. ; SMTP relay servers can directly communicate with the DMZ interface. ; External network servers can never directly communicate with the DMZ

interface. ; The SMTP relay on the DMZ needs to be configured with remote domains.

The remote domains are those mail domains over which you have administrative control. ; The SMTP relay can forward packets to the external interface of the ISA

server or to the DMZ interface. ; The preferred security solution is to publish the internal network SMTP to

the DMZ interface, and then configure the SMTP relay on the DMZ to use the IP address of the DMZ interface as its smart host. ; You must configure custom packet filters to allow inbound access to the

SMTP relay; the predefined packet filters won’t do the job. ; Access controls should be placed on the server publishing rule that publishes

the internal network SMTP server so that only the DMZ mail relay can use the server publishing rule.

Publishing a Web Server ; Publishing a Web server on the DMZ segment requires a custom packet filter. ; You can configure a SQL server publishing rule to allow a Web server access

to an internal network SQL server. Like the SMTP relay, its best to use the DMZ interface IP address in the SQL server publishing rule.

Publishing an FTP Server on a Trihomed DMZ Segment ; The FTP protocol creates special challenges to firewall security; it definitely

was not designed with security in mind. ; PASV mode FTP provides more security on the client side because all

connection requests are outbound.This is in contrast to PORT mode, where the FTP server needs to be allowed to make a new inbound connection to send data to the FTP client.

www.syngress.com

114


; Running FTP servers in the trihomed, public-address DMZ creates security

issues because a large number of ports must be opened to support the protocol.You can temper some of the security issues by restricting access to the packet filters to special IP addresses and source ports. ; You will have a higher level of security for your FTP servers if you place them

on the internal network.The FTP application filter will manage connections for published FTP servers.This removes the requirement of opening a large number of ports into the DMZ.

External Network Clients Cannot Use the DMZ Interface to Connect to the Internal Network ; External network clients can never directly communicate with the DMZ

interface. ; DMZ hosts can directly communicate with the DMZ interface. ; External network clients can access internal network resources with the help

of an intermediary on the DMZ segment. For example, an external network SMTP server can send messages to an internal network SMTP server by going through the DMZ SMTP mail relay server.

www.syngress.com


115


Q: Why would I create a trihomed DMZ? There seems to be many disadvantages to this configuration.

A: The trihomed DMZ configuration does have its share of disadvantages. First, you introduce a single point of failure. If someone compromises the ISA server, he has direct access to both the DMZ segment and the internal network. Second, you must use static packet filters to allow inbound and outbound to and from the DMZ segment.The trihomed DMZ configuration should be considered an “economy” solution for those administrators who don’t have the resources to put together a back-to-back DMZ configuration.

Q: We use Exchange 5.5 on our internal network. I would like to put an IIS server on the DMZ segment and allow users to access the internal network Exchange server from an OWA server on the DMZ. Can I do this? If so, how?

A: You can do this, but there’s a major problem with this type of configuration. In order for the OWA server to allow users to log in to OWA, you must make the server a member of the internal network domain.This creates a major security problem, as you’ve extended your private network’s security zone into the DMZ segment.This is especially problematic because the trihomed DMZ segment is a direct extension of the Internet and is protected only by static packet filters. However, the configuration is possible.You’ll need to allow intradomain communications through the ISA server.This is accomplished by creating a number of server publishing rules.

Q: I can’t connect to my DMZ! I’ve run Network Monitor on my servers on the DMZ segment, and no packets from external network clients are arriving to the servers on the DMZ.What could the problem be?

A: The most common reason for this is that you’ve put the external interface and the DMZ segment on the same network ID. Remember that the ISA server must be able to route packets between the external network and the DMZ segment. In order to route packets, the ISA server external and DMZ interfaces must be on different network IDs.

www.syngress.com

116


Q: I can’t ping the external interface from a DMZ host.Why not? A: Don’t worry, this is normal.There is no combination of packet filters that will allow you to ping the external interface of the ISA server. If you need to test connectivity, you should use telnet. If the services aren’t yet in place, you can use Jim Harrison’s very cool WinSock Tool.You can find the WinSock Tool at http://isatools.org.

Q: I have an ISA server with three NICs: LAN—192.168.1.0/24, DMZ— 192.168.2.0/24 and WAN—xxx.xxx.xxx.xxx. I want to create a trihomed DMZ. Will this work?

A: You can create a private address LAT-based DMZ, but the ISA server will not recognize it as a DMZ segment.The ISA server only recognizes DMZ segments that are not in the LAT.You could take the DMZ NIC out of the LAT, but then external network clients would not be able to reach it, because the ISA server routes packets from the external network to the DMZ. Routing won’t work when you use private addresses; you need a Network Address Translator (NAT) to do this. The problem is that ISA Server will never NAT between the external network and the DMZ segment.

Q: I want to put multiple Web servers on the DMZ segment. How should I configure my DNS to support these multiple Web servers?

A: You can put as many Web servers on the DMZ segment as you have IP addresses available.You will need to enter the addresses for these Web servers in your public DNS. Put the actual IP addresses of these servers in the DNS; do not put the IP address of the external interface of the ISA server into the DNS.The reason for this is that external network client connect directly to the servers on the DMZ. In contrast, when you publish internal network servers via a Web or server publishing rule, you enter the IP address on the external interface of the ISA server (used in the publishing rule) into the public DNS.

Q: I want to ping my internal network clients from the DMZ, but I can’t seem to get the right combination of packet filters.What do I need to do to allow DMZ hosts to ping internal network computers?

A: You can’t ping internal network clients from the DMZ.The reason for this is that DMZ hosts are considered part of the external network.The only way in which external network hosts can communicate with internal network hosts is through publishing rules. ISA Server supports publishing only TCP- and UDP-based protocols. Since ping uses ICMP instead of TCP/UDP, you cannot publish “ping servers.” www.syngress.com

Chapter 3

Defense Plan 2: The Back-to-Back DMZ


Configuring a Private Address Back-to-Back DMZ

■

Configuring a Public Address Back-to-Back DMZ

; Summary ; Defensive Tactics Fast Track ; Frequently Asked Questions

117

118

Chapter 3 • Defense Plan 2: The Back-to-Back DMZ

Introduction Most “in the know” ISA Server administrators consider the trihomed DMZ configuration a bit of a kludge, the reason being that the trihomed DMZ configuration represents a single point of failure. If someone is able to compromise the single ISA server hosting both the DMZ segment and the internal network, he will be able to access resources on both the DMZ and the internal network.While we should expect the resources on the DMZ to be compromised, we should not accept compromise of internal network resources. This might be overstating the case.There have been no reported incidents where someone has compromised a correctly configured ISA server.Therefore, it’s not entirely accurate to say that it would be easy to compromise the ISA server and access both the internal network and DMZ resources. However, mistakes do happen, and sometimes an Internet criminal gets lucky.That’s why we need firewall fault tolerance.The ideal firewall fault tolerance scheme is the back-to-back firewall configuration. It’s not the end of the world if the external firewall is compromised when using a back-to-back firewall configuration; the attacker will only be able to access resources on the DMZ.The intruder will have to compromise the internal firewall to access resources on the internal network.You’ll already be on the alert because you’ll know about the compromise of the external firewall and take countermeasures to prevent the attacker from taking down the internal firewall. You can use ISA Server to create two types of back-to-back DMZ segments: ■

The private address back-to-back DMZ

■

The public address back-to-back DMZ

Each has its advantages.The rest of this chapter is dedicated to looking at these back-to-back firewall configurations in more detail.

Configuring a Private Address Back-to-Back DMZ Private address back-to-back DMZs can be constructed with two ISA servers, or one ISA server and a third-party software or hardware firewall. If you choose to use a thirdparty firewall, that firewall should be placed on the Internet and the ISA server should be placed behind the third-party firewall.The third-party firewall has an interface on the Internet and the DMZ segment, and the ISA server has an interface on the internal network and the DMZ segment.

www.syngress.com

Defense Plan 2: The Back-to-Back DMZ • Chapter 3

119

ISA SERVER DEFCON 1 The ISA server should be the internal firewall in the back-to-back DMZ setup because you want it to be a member of the internal network domain. When the ISA server is a member of the internal network domain, it can leverage the Active Directory or Windows NT 4.0 SAM to authenticate users and groups. There would be no way to allow the ISA server to leverage the account databases if it were the external firewall. To allow an external ISA server to access the account database, you would need to extend the internal network’s security zone into the DMZ. Doing so would violate the integrity of the internal network and simplify an intruder’s job of accessing internal network resources.

We are going to limit our discussion to configurations where there are two ISA servers in the private address back-to-back DMZ; there are just too many third-party firewalls, and all of them have different configuration features and interfaces.The same principles we discuss in this chapter as they apply to the external ISA server can be applied to the external third-party firewall. The private address back-to-back DMZ is the most secure DMZ configuration you can implement.This setup uses private IP addresses on the DMZ segment between the ISA servers.You can take advantage of many of the ISA server features that are not available when you use a trihomed DMZ (where you’re required to use public, untrusted IP addresses on the DMZ) because you are using private IP addresses and including the DMZ segment addresses on the external ISA server’s Local Address Table (LAT). Once you include the DMZ segment’s address in the LAT, you can use protocol rules, site and content rules,Web publishing rules, and server publishing rules to control inbound and outbound access to and from the DMZ segment.This is far more secure than using static packet filters. The back-to-back private address DMZ has the following features: ■

There are two ISA servers: an “internal” and an “external.”

■

The external ISA server has an interface on the Internet and one on the DMZ segment.

■

The internal ISA server has an interface on the DMZ segment and internal network.

■

The DMZ uses private IP addresses (RFC 1597).

■

The DMZ network is in the LAT of the external ISA server.

■

The DMZ network is not in the LAT of the internal ISA server.

www.syngress.com

120

Chapter 3 • Defense Plan 2: The Back-to-Back DMZ ■

You can use Web and server publishing rules to control inbound access to the DMZ from external network hosts.

■

Outbound access control should focus on the internal ISA server; the external ISA server’s main duty is to protect the DMZ segment.

Figure 3.1 shows a back-to-back private address DMZ. Figure 3.1 A Back-to-Back DMZ Topology

Net ID: 192.168.2.0/24

Net ID: 222.222.222.0/24

Net ID: 192.168.1.0/24

Net ID: 192.168.2.0/24

Back-to-Back DMZ: Private Addresses on DMZ

External ISA Server Configuration The external (or edge) ISA server has an interface directly connected to the Internet and an interface on the DMZ segment.The DMZ segment IP addresses must be in the external ISA server’s LAT.You can control inbound access to the DMZ segment using Web and server publishing rules when you place the DMZ segment’s IP addresses in the LAT. Although the DMZ segment is considered a trusted network by the external ISA server, it is not trusted by the internal ISA server and it is not on the internal ISA server’s LAT.This allows you to protect the internal network from DMZ traffic while allowing you to leverage all of the features provided by the Firewall and Web Proxy services. The private address DMZ segment allows you to use Web and server publishing rules to control inbound access to the DMZ, and protocol rules to control outbound www.syngress.com


121

access from the DMZ. Publishing rules and protocol rules provide much more flexibility than packet filters do. As you learned in our discussion of the trihomed DMZ in Chapter 2, “Defense Plan 1:The Trihomed DMZ,” packet filters don’t allow you to fine-tune your inbound and outbound access controls. Tables 3.1 and 3.2 describe the configuration of the external ISA server. The interface configuration on the external ISA server varies with the type of interface you use, but the following represents a good generic configuration. Table 3.1 External Interface Setting

Value

IP address Subnet mask Default gateway DNS WINS NetBIOS over TCP File and printer sharing

Assigned by ISP Assigned by ISP Assigned by ISP None None Disabled Disabled

Table 3.2 Internal Interface Setting

Value

IP address

Any IP address that is valid for your DMZ segment. We typically use the first valid IP address for the network ID. Any subnet mask that is valid for your DMZ segment. None None None Disabled Disabled

Subnet mask Default gateway DNS WINS NetBIOS over TCP File and printer sharing

The external ISA server doesn’t require DNS or WINS server addresses on any of its interfaces. Reasons for this include: ■

The external ISA server isn’t running any other services; it’s a firewall, not a “fire sale.”

■

The external ISA server won’t be performing proxy DNS. Neither DMZ hosts or hosts on the internal network will be configured as Firewall or Web Proxy www.syngress.com

122


clients of the external ISA server. Only Firewall and Web Proxy clients use the ISA server to perform proxy DNS. Firewall and Web Proxy clients on the internal network will use the DNS configuration on the internal ISA server. ■

WINS should not be used on a DMZ segment.WINS is used to support NetBIOS-dependent services, and the NetBIOS interface should be disabled on all servers on the DMZ segment. If you must use NetBIOS-dependent services on the DMZ segment, you should use an LMHOSTS file to resolve local names.

One situation in which you might consider DNS settings on the external ISA server’s interfaces is when you use Web publishing rules to publish HTTP, S-HTTP, and FTP services on the DMZ segment.Web publishing rules can use a DNS host name to decide where to forward packets accepts on the incoming Web requests listener (Figure 3.2). Figure 3.2 Using an FQDN in the Web Publishing Redirection

You could configure a DNS server address on the primary interface of the external ISA server that resolves names to the correct DMZ IP address for a Web published resource on the DMZ. However, since only the ISA server would be using this DNS server to resolve names included in a Web publishing rule, you’re better off using a HOSTS file and forgetting about configuring a DNS server for such a limited function. Another advantage is that HOSTS files are used first for name resolution. If you did use a DNS server setting on the external ISA server, and your public DNS was hosted by a third party, you wouldn’t run into problems with host headers.

www.syngress.com


123

ISA SERVER ALERT Name resolution on the external ISA server is not required. The only time you need name resolution is if you use FQDNs in your Web publishing rules. If you do use FQDNs in your Web publishing rules, you must make sure that the FQDN resolves to the IP address of the Web server on the DMZ segment. The FQDN must not resolve to the public IP address on the external interface of the ISA server. That situation would cause a loop, because the packet would arrive on the external interface of the ISA server, and then the Web publishing rule would forward the packet back to the external interface of the ISA server. Since your public DNS uses the external IP address of the external ISA server to point to your Web published DMZ servers, you must not depend on the public DNS for name resolution for your Web publishing rules. The best way around this is to use a HOSTS file. Since the HOSTS file is evaluated before a DNS query is sent, you could even configure an external DNS server on an external ISA server’s interface, and the names of your published Web servers would still resolve to the private IP address on the DMZ segment.

Suppose you want to put your public Web site on the DMZ segment. External users will use the URL www.dmzwebsite.net to access the site. If you configure the Web publishing rule to use the FQDN (as shown in Figure 3.3) for the redirection, you will avoid the dreaded 14120 error (http://support.microsoft.com/default.aspx?scid= kb;en-us;Q288396) and be able to use host headers on the Web server. Just add to your HOSTS file an entry for www.dmzwebsite.net and put in the private network address the site uses on the DMZ. Figure 3.3 Using an FQDN in a Web Publishing Rule to Prevent the Dreaded 14120 Error

www.syngress.com

124


ISA SERVER ALERT Microsoft KB article Q288396 indicates that this problem is seen only when internal network clients attempt to access resources on a Web published server. Although there is no documentation on this issue, you will find that if you do not use an FQDN and have that FQDN resolve to the internal IP address of the published server, your application log will be littered with 14120 errors. These errors will appear each time an external network client connects to a Web published server.

Internal ISA Server Configuration The internal ISA server has an interface on the private address DMZ segment and the other interface on the internal network. Only the internal network IP addresses are contained in the internal ISA server’s LAT.You do not put the DMZ addresses into the LAT. The private addresses on the DMZ segment are untrusted by the internal ISA server. Even though it contains private IP addresses, the DMZ segment is considered an untrusted network, and only trusted addresses are contained in the LAT. Segregate traffic on the DMZ away from the internal network by removing the DMZ IP addresses from the internal ISA server’s LAT. As far as the internal ISA server is concerned, the DMZ segment is as untrusted and unsafe as the Internet. When configuring your LAT, make sure you include only the internal IP address ranges.There is an option in the LAT configuration dialog box allowing you to configure the LAT to include all private network ID address ranges (Figure 3.4).That option automatically allows all private network IDs to be part of the LAT, regardless of whether you’re using these network IDs on your internal network.You don’t want to do that because the DMZ includes private IP addresses.Tables 3.3 and 3.4 list the settings and their values for the external and internal interfaces, respectively. Figure 3.4 Configuring the LAT

www.syngress.com


125

Table 3.3 External Interface Setting

Value

IP address Subnet mask Default gateway DNS WINS NetBIOS over TCP File and printer sharing

Assigned by ISP Assigned by ISP Assigned by ISP None None Disabled Disabled

Table 3.4 Internal Interface Setting

Value

IP address

Any IP address that is valid for your DMZ segment. We typically use the first valid IP address for the network ID. Any subnet mask that is valid for your DMZ segment. None None None Disabled Disabled

Subnet mask Default gateway DNS WINS NetBIOS over TCP File and printer sharing

Allowing DMZ Servers Access to the Internal Network If you need to make resources on the internal network available to a server on the DMZ, you can configure a publishing rule that allows a particular server on the DMZ to access the internal server.You might want to do this if you have a Web server on the DMZ that needs access to a SQL server on the internal network.You create a client address set that includes the Web server’s IP address and allow access to the server publishing rule to that client address set. One thing you definitely do not want to do is allow privileged private network communications to traverse the internal ISA server. For example, you do not want to allow any servers on the DMZ to be members of the internal network domain. If you require Active Directory support for services on the DMZ segment, you should create a domain dedicated to servicing the DMZ segment. It is critical that you do not extend your private network’s security zone into the DMZ.

www.syngress.com

126


With that said, an argument can be made for allowing intradomain communications across the internal ISA server when you use private address DMZ segments.The DMZ is secure because it’s protected by the external ISA server, and the private address DMZ segment has the same level of security as an internal network protected by a single ISA server. On the other hand, the whole reason for having a DMZ segment is to create a security zone that’s separate and distinct from the security zone defined for the internal network.There should be no common credentials or service dependencies between the DMZ and the internal network segment. From this point of view, the only difference between the DMZ segment and the “free range” Internet (public address) is that the DMZ segment is under your administrative control and the Internet is not. As with most things, there is a middle ground when considering the private address DMZ configuration.The private address DMZ isn’t really as unsecure as a public address DMZ. On the public address DMZ, you’re depending on the kindness of packet filters. The level of support provided by the full force of the Firewall and Web Proxy services provide you a large measure of confidence that your private address DMZ will not be compromised in the near future, and if it is, the scope of damage will be limited.

Allowing Outbound and Inbound Traffic to and from the Internal Network You need to consider how you want to implement access control on both the internal and the external ISA server in the back-to-back ISA server configuration.The internal ISA server should be used to control outbound access for your internal network users. The internal ISA server is a member of the internal network domain; therefore, it’s able to leverage the user database in the internal network’s NT or Windows 2000 domain for outbound access control.The external ISA server should not be used for outbound access control. It is not a member of the internal network domain and should not have access to internal network user accounts.The primary job of the external ISA server is to protect the DMZ segment and to control access between the Internet and the DMZ segment. Remember that the DMZ segment includes all the servers on the DMZ and the external interface of the internal ISA server.

ISA SERVER DEFCON 1 While you should not use the external ISA server as a primary means of access control for internal network users, you can still use user-based access controls on the external ISA server. As you’ll see later in this chapter during the discussions on Web Proxy and Firewall Service chaining, you can use user accountbased access controls to allow the downstream ISA server special access that is separate and distinct from outbound access allowed to servers on the DMZ.

www.syngress.com


127

You configure the policy elements and access policies used to control outbound access on the internal ISA server in the same way you would if you had a single ISA server on the network.The only difference is how you configure the internal ISA server to communicate with the upstream external ISA server. There are two ways you can configure the downstream, internal ISA server to communicate with the upstream, external ISA server: ■

Configure the downstream, internal ISA server to be a SecureNAT client of the upstream, external ISA server

■

Configure the downstream, internal ISA server to be a Firewall client of the upstream, external ISA server

The easiest configuration is to make the internal ISA server a SecureNAT client of the external ISA server. All you need to do is configure the default gateway on the external interface of the internal ISA server to use the internal interface of the external ISA server as its default gateway.You then create protocol rules on the external ISA server to allow what traffic can go outbound from the DMZ to the external network. You can create a client address set on the external ISA server computer that includes the IP address of the external interface of the internal ISA server computer.You can then use this client address set to control outbound access from the DMZ to the external network. For example, let’s say that you have a back-to-back ISA server configuration.You have configured site and content rules and protocol rules on the internal ISA server to control outbound access for your internal network users. On your external ISA server, you can create a site and content rule and a protocol rule that allows outbound access to all sites, content, and protocols to the internal ISA server’s external IP address.This is contained in a client address set (Figure 3.5). This type of outbound access control at the external ISA server is easy to set up because you don’t have to worry about micromanaging outbound access controls on the external ISA server.Your primary concern with the external ISA server is to control the nature of inbound access to the DMZ segment from the Internet. If someone does get into the DMZ and compromises one of the hosts on the DMZ segment, you want to make sure he can’t send outbound messages through the external ISA server. There are some limitations to this approach: ■

The internal ISA server is a SecureNAT client.Therefore, it won’t be able to take advantage of complex protocols (those requiring secondary connections) without the aid of application filters on the upstream ISA server.

www.syngress.com

128


SecureNAT clients can only access protocols included in the Protocol Definitions node of the ISA server to which they connect; in this case, the SecureNAT internal ISA server can only access protocols.

■

As a SecureNAT client, the internal ISA server cannot send credentials to the external ISA server’s internal interface.

Figure 3.5 Controlling Access on the External ISA Server

Client address set configured on external ISA Server that includes IP address of internal ISA Server’s external primary interface

External ISA Server is configured with Protocol and Site and Content Rules that control outbound access from the external interface of the internal ISA Server External ISA Server Web

SMTP

Internal ISA Server

Internal ISA Server configured with Protocol and Site and Content Rules to control outbound access for internal network clients

Suppose an intruder was able to break into the DMZ network and take control of one of the DMZ host computers.There’s a good chance that the intruder will want to be able to connect to the Internet from the DMZ host to so he can download some hacking tools to will help him access the internal network.The attempt at outbound access should fail because your protocol and site and content rules on the external ISA server allow outbound access only to the IP address on the external interface of the internal ISA server. If the intruder were wise, he might know that you’ve configured such limitations to outbound access and might attempt to spoof the source address of his outgoing messages.The attacker would change the source address of the outbound packets to be the IP address of the external interface of the ISA server.The problem for the intruder is that when the packets return to the DMZ, they will be returned to the IP address of www.syngress.com


129

the external interface of the internal ISA server. No problem, as there are ways around that issue, too. Because there are ways for the hacker to deal with this problem, a more secure solution is to require credentials to access resources on the external network.You accomplish this by requiring user-based access controls on your protocol and site and content rules.

ISA SERVER ALERT You might wonder how Web and server publishing fits into this equation. If you only allow user-based outbound access through the external ISA server, how will servers published on the DMZ segment be able to respond to incoming requests made to them via the Web and server publishing rules? No problem! The ISA server publishing rules take care of it. There is no need to create special rules to allow published servers outbound access; outbound access permission is assumed when you create the publishing rule. The only exception to this is PORT mode FTP. In this case, the FTP server needs to create a new outbound connection from its own TCP port 20. Since this outbound connection is a new connection and not in response to a connection made by the external network client, you will need to create a protocol and site and content rule that will allow this server outbound access. Moreover, that rule will have to apply to an IP address in a client address set because you do not want to install the Firewall client on published servers. This is yet another reason to avoid publishing FTP servers if you can help it, or at least allow just PASV mode connections. PASV mode will not require the FTP server to create a new outbound connection.

SecureNAT clients are able to access simple protocols only, which require only a single connection.This is in contrast to complex protocols that require secondary connections; for example, FTP, RPC, H.323 protocols, and most Internet games. The only time a SecureNAT client can access protocols requiring secondary connections is when there is an application filter to support the connection. Clients on the internal network will be able to use both PORT and PASV mode FTP to access resources on the external network when the internal ISA server is a SecureNAT client. The reason for this is that the FTP access application filter on the external ISA server supports the request coming from the SecureNAT internal ISA server. However, if there were an outgoing request for a complex protocol and no application filter were in place, the request would fail because the internal ISA server is a SecureNAT client. You can see that while configuring the internal ISA server as a SecureNAT client is easy, it might not be the best option. A better solution is to configure the internal ISA server to use the external ISA server as an upstream server in a chained configuration. You can configure both the Firewall service and the Web Proxy service to chain with

www.syngress.com

130


the external ISA server.The chained configuration allows you to configured user-based access controls and gives you a wider array of protocols that you can support for outbound access.

Configuring Firewall Chaining Firewall chaining allows the firewall service of the downstream ISA server to communicate directly with the Firewall service on the upstream ISA server.This makes the downstream ISA server a Firewall client to the upstream ISA server. Both your SecureNAT and Firewall clients on the internal network will be able to take advantage of the firewall chaining configuration. However, the firewall chaining configuration will not turn the SecureNAT client requests on the internal network into Firewall client requests. Firewall chaining does not add functionality to the internal network SecureNAT client. Perform the following steps on the downstream (internal) ISA server to configure firewall chaining in the back-to-back ISA server configuration: 1. Open the ISA Management console. Expand your server name, right-click the Network Configuration node, and select Properties. 2. The Network Configuration Properties dialog box has a single tab, the Firewall Chaining tab. Select the Chain to this computer option (Figure 3.6). Note the graphic on the Firewall Chaining tab, which shows a hierarchical arrangement of ISA Server in a firewall chaining configuration. Keep that graphic in mind when configuring firewall chaining in your organization. Figure 3.6 The Firewall Chaining Tab

www.syngress.com


131

3. In the Chain to this computer text box, type in the name of the upstream ISA server. Note that you must put a name here; if you put an IP address in this text box, the chaining will fail. 4. If you want to force the downstream ISA server to authenticate with the upstream ISA server, put a check mark in the Use this account check box. Click Set Account.This opens the Set Account dialog box (Figure 3.7). Enter an account that is valid on the external ISA server. Note that you must use the COMPUTERNAME\Username format when entering the account. Although Figure 3.7 shows that we’re using the Administrator account on the upstream server, you should not use the built-in Administrator account. Create an account on the upstream ISA server that is dedicated for use by the downstream ISA server.This account should have a long, unusual name and a very complex password of more than 15 characters. Click OK after adding the name and password. Figure 3.7 Configuring the Account to Use with the Upstream ISA Server

5. Be sure to check the Use dial-up entry check box if you use a dial-up connection for your external interface. It’s unlikely that your back-to-back DMZ is going to use a dial-up entry on the external interface, but anything is possible. Click Apply and then click OK in the Network Configuration Properties dialog box. 6. Go to <systemroot>\system32\drivers\etc and open the HOSTS file with Notepad. Add the name and IP address of the external ISA server to the HOSTS file.You need to create the HOSTS file entry because there is no DNS or WINS server that will resolve the name of the internal interface of the external ISA server. Adding this name to the HOSTS file is the simplest and most elegant way to handle resolving the name. There are advantages to firewall chaining that you might not have considered.Take a look at Figure 3.8. Did you know that when you configure a downstream ISA server to connect to an upstream ISA server, you’re not dependent on the routing infrastructure to support SecureNAT clients behind the downstream ISA server? It’s true! The ability to leave your routing infrastructure as is without having to change the default gateway settings on all interposed routers to route Internet bound requests to www.syngress.com

132


the internal interface of the ISA server will come as good news to many administrators. The downstream ISA servers will be able to access the Internet as long as your routing infrastructure has a route to the IP address of the internal interface of the upstream ISA server.You are not dependent on default-gateway or gateway-of-last-resort configurations on the network between the downstream and upstream ISA servers. Figure 3.8 Firewall Chaining Obviates the Need to Reconfigure Routers If downstream ISA Servers were configured as SecureNAT clients to the upstream, the entire routing infrastructure would have to be configured to support routing Internet bound requests to the internal interface of the ISA Server

When downstream ISA Servers are Firewall clients to the upstream (via Firewall chaining), no change in default gateway configuration is required; just a route to the network ID for the internal interface of the upstream ISA Server

Router

Router

Router

Router

Router Router

Firewall

ISA SERVER DEFCON 1 It’s critical that you use a computer name in the Firewall Chaining dialog box. We’ve spent many hours trying to figure out what the problem was with our Firewall Chaining configuration. It always came down to the fact that an IP address was used instead of a computer name, or the account name to use to authenticate with the upstream server was configured incorrectly.

Allowing the Remote WinSock Protocol (RWSP) on the External ISA Server We’ve assumed that the configuration on the external ISA server will be “All Open.” By that, we mean there is a protocol and site and content rule that allows the downstream, www.syngress.com


133

internal ISA server access to all sites, all content, all protocols, at all times.This might not be the optimal configuration; you might want to lock down the outbound access controls on the external ISA server. For example, suppose you want to allow only outbound HTTP, FTP, SMTP, NNTP, and DNS from internal network clients. In order to allow these protocols outbound access to the Internet, you must first create a protocol rule on the internal ISA server that allows these protocols. The internal ISA server can be chained with the upstream, external ISA server.This essentially makes the internal ISA server a Firewall client to the external ISA server. When an internal network client sends an FTP request from the internal network to the internal ISA server, the internal ISA server’s Firewall service intercepts the request and forwards it as a Firewall client request directly to the Firewall service on the external ISA server.The downstream ISA server is a Firewall client to the upstream ISA server and it forwards the request from the internal network Firewall client. If you create a protocol rule that only includes protocol definitions for HTTP, FTP, SMTP, DNS, and NNTP, the request from the internal network client will fail.Why? Because the Firewall client must communicate with the Firewall service using either TCP or UDP port 1745. Look at the packet trace in Figure 3.9. Figure 3.9 RWSP Requests Arriving at the Internal Interface of the External ISA Server

www.syngress.com

134


The external interface of the internal ISA server has the IP address 10.0.1.2, and the name of the external ISA server is ISAEXT. Notice in the selected frame in Figure 3.9 that the internal ISA server is acting as a Firewall client to the external ISA server and is sending a proxy DNS request to the upstream ISA server via TCP 1745—the Remote WinSock Proxy (RWSP) port! That explains why you see www.msn.com in the ASCII for the frame. You must include both the TCP and UDP RWSP protocol definitions in your protocol rule on the external ISA server.You will be able to access the Internet using the other protocols in the protocol rule after you add the RWSP protocol definitions to the protocol rule.

ISA SERVER ALERT Because the external interface of the internal ISA server is on a trusted network, you would expect that the internal interface of the external ISA server would accept the RWSP requests from the internal ISA server without a protocol rule. However, from our experience with firewall chaining, it appears that this rule is required.

You might be thinking, “but I don’t have to create protocol definitions for the RWSP protocols and I don’t have to include those definitions in a protocol rule on the internal ISA server”—you’re right.Why? No one knows, or at least no one who does know is talking. Figure 3.10 shows the protocol rule on the external ISA server that would allow the DNS, FTP, HTTP, NNTP, SMTP, and RWSP protocols through. Figure 3.10 Limiting Protocol Access

www.syngress.com


135

NOTE You might have noticed in your ISA server reports that much of the traffic is attributed to an UNKNOWN protocol. ISA Server treats all protocols for which there is no protocol definition as “unknown.” You might be able to reduce the amount of UNKNOWN traffic appearing in the reports by adding the TCP and UDP RWSP protocols to your protocol definitions.

The Firewall Client, Firewall Chaining, and the HTTP Redirector Here’s an interesting problem you might run into that would take you hours to solve if you hadn’t read this book! Consider the following scenario: You have an internal and external ISA server in a back-to-back ISA server configuration.The internal ISA server is configured for firewall chaining with the external ISA server. Authentication is required for Firewall client requests at both in the internal and external ISA servers.The internal network client is running as a Firewall client only and is not configured as a Web Proxy client. Figure 3.11 illustrates this. Figure 3.11 Firewall Clients and the HTTP Redirector

Authentication required to access Protocol and Site and Content Rules on the upstream ISA Server; Outbound Web requests listener also forces authentication External ISA Server

Downstream ISA Server configured for Firewall chaining with upstream ISA Server Internal ISA Server

Internal network clients must authenticate with the internal ISA Server to access the Web Proxy and Firewall services - clients configured as Firewall clients

www.syngress.com

136


RESULT: All HTTP requests from internal network clients configured as Firewall clients are denied, but the Firewall client is able to successfully perform nslookup queries. Why would the HTTP requests from the Firewall clients on the internal network fail? Consider what happens when the HTTP Redirector filter is enabled.When the Firewall client sends an HTTP request to the internal ISA server, the request is intercepted by the HTTP Redirector.The default configuration of the HTTP Redirector is to forward all HTTP requests to the Web Proxy service. When requests from Firewall clients are forwarded to the Web Proxy service on the internal ISA server, the credentials sent to the ISA server by the Firewall client are not included.The Web Proxy service will ask the requesting host computer for credentials, but only the Web Proxy client understands this request. Since the Firewall client computer in this scenario is not configured as a Web Proxy client, the request fails. Let’s say that you configure the HTTP Redirector filter on the internal ISA server to forward requests directly to the Web server (Figure 3.12).This will allow the HTTP request from the internal Firewall client to be accepted by the Firewall service on the internal ISA server, and the request will be passed to the Firewall service on the external ISA server. Figure 3.12 Reconfiguring the HTTP Redirector

What happens when the request makes it to the Firewall service on the external ISA server? The same thing that happened on the internal ISA server! The HTTP request is intercepted by the HTTP Redirector on the external ISA server and passed to the Web Proxy service.The credentials the internal ISA server sent to the external ISA server’s Firewall service are not passed up to the Web Proxy service. Since the Web Proxy service on the external ISA server requires authentication, the request is denied.

www.syngress.com


137

The moral of this story is that if you’ve configured only firewall chaining between the upstream and downstream ISA servers and your internal network clients aren’t configured as Web Proxy clients, you have to make sure that the HTTP Redirector Filter is configured to pass requests directly to the external server on both the internal and external ISA server to prevent this type of failure in HTTP requests from internal network Firewall clients. The unifying principle here is that credentials passed to the Firewall service are not passed to the Web Proxy service. Only Web Proxy clients can pass credentials to the Web Proxy service. Configuring the browser on the internal network client, and configuring Web Proxy chaining would fix this problem, and you would not need to configure the HTTP Redirector to forward requests directly to the Web server.

NOTE If the internal network client were a SecureNAT client, it would not be able to get past the internal ISA server. However, if you did not request credentials to access HTTP on the internal ISA server, the SecureNAT client on the internal network would be able to access the Internet, despite the fact that credentials are required on the external ISA server. The reason for this is that the internal ISA server provides the required credentials to the external ISA server.

Configuring Hierarchical Web Caching (Web Proxy Chaining) You can configure the Web Proxy service to do something like firewall chaining.The primary differences is that you make the downstream ISA server a Web Proxy client of the upstream ISA server. You configure hierarchical Web Proxy caching by configuring Web routing rules.You configure the hierarchical Web caching configuration between the internal and external ISA server by performing the following steps on the internal ISA server computer: 1. In the ISA Management console, expand your server name and then expand the Network Configuration node. 2. Right-click on the Routing node, point to New, and click Rule. 3. Assign the rule a name on the first page of the wizard (Figure 3.13), and click Next. 4. On the Destination Sets page (Figure 3.14), select the All destinations option.This allows the internal ISA server’s Web Proxy service to forward all

www.syngress.com

138


requests it receives from internal network clients to the Web Proxy service on the upstream ISA server. Click Next. Figure 3.13 Welcome Page of the New Routing Rule Wizard

Figure 3.14 The Destination Sets Page

5. Select the Route to a specified upstream server option on the Request Action page (Figure 3.15).This allows you to configure the address of the upstream server on the following page. Click Next to continue. 6. Now we get to the real action: the Primary Routing page (Figure 3.16). In the Server or array text box, enter the name of the upstream ISA server.You can use an IP address instead of a name if you like (unlike the situation you saw with the firewall chaining configuration). Since you went out of your way to configure a HOSTS file entry to support the firewall chaining configuration, you might as well use the name for the upstream ISA server you placed in the HOSTS file.The Port and SSL Port text boxes accept the port numbers used www.syngress.com


139

on the upstream ISA server’s Outgoing Web Requests listener for HTTP and HTTPS communications.Yes, you can secure the connection between the downstream and upstream ISA server using SSL.This is in contrast to the situation with browser-based Web Proxy clients, where you cannot configure the browser-based Web Proxy client to use a secure SSL connection with its ISA Server’s Web Proxy service. Put a check mark in the Use this account check box and click Set Account. Enter the username and password in the same way as you did with the firewall chaining configuration. Set the authentication type as Authenticated Windows to prevent the credentials from moving across the DMZ in cleartext (note that if you secure the channel using SSL between the downstream and upstream server, the credentials will not be available to sniffers). As with the firewall chaining example, make sure you create an account on the upstream server that’s dedicated for the downstream Web Proxy Service. Click Next to continue. Figure 3.15 The Request Action Page

Figure 3.16 The Primary Routing Page

www.syngress.com

140


7. You configure how you want the downstream Web Proxy service to handle requests when the upstream server is not available (Figure 3.17).The correct answer is Ignore requests in our back-to-back DMZ scenario.You might want to use a backup route, such as a modem connected to the downstream server, or another upstream ISA server if you have access to multiple upstream ISA servers. Click Next to continue.

Figure 3.17 The Backup Routing Page

8. You set how you want cached Web objects to be retrieved on the Cache Retrieval Configuration page (Figure 3.18).The most inclusive option is the A valid version of the object; if none exists, retrieve the request using the specified requested action, and is the one you should select in the back-to-back DMZ hierarchical Web caching situation. Click Next to continue. Figure 3.18 Cache Retrieval Configuration Page

www.syngress.com


141

9. You determine what general types of objects should be cached on the Cache Content Configuration page (Figure 3.19).The If source and request headers indicate to cache, then the content will be cached is the default selection, and is the one you should select in the back-to-back hierarchical Web caching scenario.This is the preferred selection, as it’s usually not a good policy to cache dynamic content. Click Next. Figure 3.19 The Cache Content Configuration Page

10. Review your selections and click Finish on the Completing the New Routing Rule Wizard page (Figure 3.20). Figure 3.20 The Final Page of the Wizard

Hierarchical Web caching has many of the same advantages you get with the firewall chaining configuration (and more): ■

The downstream ISA server becomes a Web Proxy client of the upstream ISA server. www.syngress.com

142


The routing infrastructure of the internal network doesn’t need to be changed to support SecureNAT client configuration (requests are made to the IP address of the upstream ISA server’s Outgoing Web Requests listener).

■

You can use credentials to authenticate to the upstream Web Proxy service.

■

Web access is much faster and perceived performance much greater on the client side.

The downstream ISA server acts as a Web Proxy client to the upstream ISA server, which means that the downstream ISA server can send credentials to the upstream. If you didn’t configure Web Proxy chaining between the upstream and the downstream, the downstream would be only a SecureNAT client. SecureNAT clients can’t send any credentials to an ISA server, not even when that SecureNAT client is a downstream Web Proxy server The downstream ISA server doesn’t depend on the routing infrastructure to get the HTTP request to the upstream ISA server because the Web Proxy client (the downstream ISA server communicates directly with the Web Proxy service of the upstream ISA server. Had you configured the downstream ISA server to be a SecureNAT client, then you would have to change your routing infrastructure to make sure that Internet bound packets are forwarded to the internal interface of the upstream ISA server.With the hierarchical caching configuration, the only route required is a route to the network ID of the upstream ISA server’s Outgoing Web Requests listener. You can also clamp down on outbound access by using credentials.When the downstream ISA server is configured as a Web Proxy client to the upstream, the downstream ISA server can send credentials to the upstream ISA server’s Web Proxy service. This solves the problem we encountered with the firewall chaining configuration mentioned earlier.You can force authentication on the upstream ISA server’s Outgoing Web Requests listener and the downstream ISA server will be able to comply with that requirement because as a Web Proxy client, it can send credentials to the Web Proxy service on the upstream ISA server. Perhaps the best reason to configure Web Proxy chaining is that performance is much better. If you configure the downstream ISA server as a SecureNAT client instead of a Web Proxy client, the downstream requests will have to pass through the HTTP Redirector filter. Passing a request from the Firewall service to the Web Proxy service via the HTTP Redirector consumes processor cycles and time. Passing requests directly from the Web Proxy client to the Web Proxy service is more efficient and leads to better perceived performance for end users.

www.syngress.com


143

Web Proxy Chaining and Upstream Caching Arrays Performance will be even better if the upstream ISA servers participate in a caching array. After you create the routing rule that establishes the Web Proxy chain, double-click on the rule and then click on the Action tab. Click Settings to the right of where it says upstream server and you’ll see something like what appears in Figure 3.21. Figure 3.21 Configuring the Downstream to Poll the Upstream Array

Notice that the Automatically poll upstream server for array configuration is checked by default.This setting allows the downstream server to be a CARP client by downloading the upstream array’s configuration. Included in this array configuration is information that the Web Proxy client can use to determine, in advance, on what array member a particular Web object can be found based on the hash of the URL. If the downstream Web Proxy service didn’t perform this routing calculation itself, it would have to depend on the upstream array member (that the downstream ISA server is configured to use) to perform the routing function. Because the upstream array is likely busier than the downstream ISA server, waiting for the upstream array will result is lower performance. However, even if you require the upstream array member to do the CARP routing, it’s still faster than making the downstream ISA server a SecureNAT client.

NOTE CARP and the concepts of parallel (distributed) and hierarchical routing are quite interesting! If you have the time, check out my article on these subjects at http://itresources.brainbuzz.com/TechLibrary/GetHtml.asp?ID= 1225&CatID=230. You’ll be glad you did.

www.syngress.com

144


Performance Issues with Hierarchical Web Caching You might have problems with slow performance when you configure a Web Proxy chaining, the most likely reason being slow or failed name resolution.The name resolution problem seems to focus on the downstream ISA server. Both the upstream and the downstream ISA servers might attempt to resolve the FQDN requested by the Web Proxy client on the internal network.This won’t happen if you have configured the downstream ISA server to communicate with the upstream properly (as described in this chapter).You can easily diagnose the problem by running Network Monitor on both the downstream and upstream ISA servers. After starting Network Monitor, go to a Web Proxy client computer on the internal network and go to an obscure Web site that’s unlikely to be in the Web Proxy DNS cache.You should see only the upstream ISA server attempting to resolve the name. The reason why only the upstream ISA server resolves the name is that when Web Proxy chaining is configured, the downstream ISA server is a Web Proxy client of the upstream ISA server.Web Proxy clients allow the Web Proxy service to resolve DNS host names on their behalf.That’s why the downstream ISA server allows the upstream to resolve names on its behalf. These are our observations in the field using Network Monitor to confirm them. However, some users have reported a problem with slow name resolution when configuring Web Proxy chaining when the DNS infrastructure isn’t set up according to our specifications.The following circumstances must be extant to reproduce the problem: ■

The downstream ISA server must be configured as a Web Proxy client of the upstream ISA server.

■

The DNS server that the downstream ISA server uses cannot resolve Internet host names.

■

There is a site and content rule on the downstream ISA server that limits access to anything but “all destinations,” or a Web publishing rule that applies to any destination type other than “all destinations.”

The best solution is to configure the internal ISA server with the IP address of a DNS server that can resolve both internal and external host names. For example, you can have an internal network DNS server configured to perform recursion for internal network DNS clients (which includes the internal interface of the ISA server).That DNS server can resolve Internet host names for the ISA server.You could also disable recursion and configure the internal DNS server to use a forwarder, which is a more secure solution. Why does the internal ISA server even need to resolve host names? After all, it’s the external ISA server that needs to be able to resolve host names to IP addresses so www.syngress.com


145

that the request can be forwarded to the appropriate server on the Internet; the internal ISA server just needs to forward requests from internal network clients to the external ISA server. The problem is that the internal ISA server does a little more than just forward requests to the external ISA server.The internal ISA server will perform name resolution to determine whether shrewd users are trying to get around site and content or Web publishing rules by using an IP address (to get around rules you’ve created based on FQDNs) or an FQDN (to get around rules you’ve created based on IP addresses). It slows things down quite a bit when the ISA server can’t do name resolution for these requests. Note that this only seems to occur when there are rules that prevent access to all sites and content.

ISA SERVER ALERT What’s interesting is that the requests are not denied. Apparently, the ISA server will wait until the reverse DNS query times out, and then just go ahead and forward the requests without this “extra” confirmation that the request is valid.

For example, suppose you created a site and content rule that denies access to www.hotmale.com. One of your problematic users knows that you’ve blocked the site, so she tries to access the site by typing its IP address http://216.205.191.201.The internal ISA server will attempt a reverse lookup on this address to determine whether the site should be blocked. If the DNS server used by the internal ISA server is not able to perform the reverse lookup, the ISA server will wait for the request to time out and then allow the request to go through anyway. However, it takes so long for the request to time out that the salacious user will probably have given up by that time. If you can’t set up the optimum DNS name resolution configuration, you can prevent name resolution on Web publishing rules and site and content rules (and routing rules) by adding the following Registry values (ISA Server SP1 must be installed): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Proxy\Parameters\ SkipNameResolutionForPublishingRules : DWORD : 1 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Proxy\Parameters\ SkipNameResolutionForAccessAndRoutingRules : DWORD : 1

You should notice a profound improvement in internal network Web Proxy client performance after making the these changes. www.syngress.com

146


NOTE You might want to implement the first setting (SkipNameResolutionFor PublishingRules) even if you have an optimum DNS configuration because it prevents reverse lookups on inbound requests. The reason for this is that it prevents the ISA server from doing a lookup for nonqualified requests. Many worms will send requests for “www” or other nonqualified names. There is a risk that the ISA server will qualify the request by adding its own domain name to the request, and forward the request to a server name in that domain. For example, if the worm sends a request to “www” and the ISA server belongs to mycompany.com, the ISA server will try to qualify the request and send www.mycompany.com for resolution. If you’re publishing a server by that name, the request will be forwarded to the server and could potentially infect the internal server. Moreover, if the intruder sends the request to your IP address, and it resolves to a name you’ve included in a publishing rule, the worm will be able to get in.

Configuring a Secure Channel between the Downstream and Upstream ISA Server You can configure a secure SSL channel between the downstream and the upstream ISA server.You might want to do this if you don’t trust the network between the downstream and the upstream, especially for your SSL connection to the Internet.You can configure the Web Proxy chaining configuration so that allowed communications are sent between the two via an SSL tunnel. Do the following to create a secure channel between the downstream and upstream ISA servers: 1. Both the upstream and the downstream ISA servers need a machine certificate from a certificate authority (CA). 2. The upstream ISA server needs a server certificate.The downstream ISA server doesn’t necessarily need a server certificate, but it needs a certificate in its certificate store so that it trusts the same root authority that assigned the certificate to the upstream ISA server. 3. The outbound routing rule on the internal ISA server must be configured to support the upstream ISA server’s SSL port—by default, this is TCP 8443. Double-click on your routing rule that you use to forward all outbound requests, and click on the Action tab.You will see what appears in Figure 3.22.

www.syngress.com


147

Figure 3.22 The Action Tab on the All Requests Routing Rule

4. Click Settings. Make sure the SSL port is set for the same port you’ve configured on the upstream ISA server’s Outgoing Web Requests listener. The default setting is 8443 in the Upstream Server Setting dialog box (Figure 3.23). Figure 3.23 Configuring the Upstream SSL Port

5. Click on the Bridging tab on the downstream ISA server. In the Redirect HTTP requests as frame, change the option so that the SSL requests (establish a secure channel to the site) option is selected. Click Apply, and then click OK. 6. Go to the upstream ISA server, right-click on the server name in the ISA Management console, and select Properties.Then, click on the Outgoing Web Requests tab.

www.syngress.com

148


7. On the Outgoing Web Requests tab (Figure 3.24), make sure that the Enable SSL listeners check box is selected. Note that the default port is 8443.You can change this if you want to, just make sure that you also change the setting use for the SSL port on the downstream ISA server’s configuration. You should also select the Ask unauthenticated users to identification check box.This causes the Outgoing Web Requests listener to force authentication for outbound Web requests. Figure 3.24 Configuring the Upstream ISA Server’s Outgoing Web Requests Listener

8. Double-click on the listener entry. In this example, the same listener configuration is used for all internal IP addresses.Therefore, we could double-click on the ISAEXT entry as shown in Figure 3.25. 9. In the Add/Edit Listeners dialog box, put a check mark in the Use a server certificate to authenticate to web clients check box.The Integrated check box on this page indicates that the Outgoing Web Requests listener will accept integrated authentication to access protocol and site and content rules. Click Select. 10. In the Select Certificate dialog box (Figure 3.26), select the certificate you want the upstream ISA server to use to create the SSL channel with the downstream.This is a machine certificate that will appear in the machine’s certificate store. Select the certificate and click OK. www.syngress.com


149

Figure 3.25 Editing the Properties of the Outgoing Web Requests Listener

Figure 3.26 What Appears in the Web Browser When a Proxy Chain Loop Occurs

11. Click OK again, and then click Apply in the server’s Properties dialog box. You’ll be asked if you want to restart the Web Proxy service. Select your preferred option, and click OK. When setting this up, make sure you restart the servers after installing the certificates and again after you complete the configuration.While we can’t give you a compelling reason for doing this, we can tell you that you’ll save yourself a lot of work and anxiety if you just restart the servers after making the changes. How do you know if your secure channel is working? You can use the netstat –na command or you can use Network Monitor. Go to an internal network client and start browsing the Web. Now go to the upstream ISA server after you’ve browsed a few sites. Open a command prompt and type netstat –na.You’ll see entries for the internal interface of your external ISA server showing an established connection on TCP port

www.syngress.com

150


8443 with the external interface of the internal ISA server.Three of these are shown in Figure 3.27. Notice that the TCP port 8080 is listening, but there are no connections to it. Figure 3.27 Using the netstat Command to Find the Secure Channel Connections

ISA SERVER ALERT If you want to find your connections to port 8443 more quickly, you can use the find command with the netstat command. Use the command netstat –na | find “:8443”. The result is that you will only see lines that have the string :8443. When you use the find command, you don’t have to wade through hundreds of links just to find the entry of interest.

You can also use Network Monitor to confirm that your secure channel is functional. Configure Network Monitor on the upstream ISA server to listen on its internal interface.When finished, start browsing the Web from an internal network client. Go back and stop Network Monitor and you’ll see communications between the upstream and downstream ISA servers over TCP port 8443.There won’t be anything going over TCP port 80 because the channel between the two servers is secure (Figure 3.28). Figure 3.28 Using Network Monitor to Capture the Secure Channel Connection

www.syngress.com


151

Publishing a Web Server on the Private Address DMZ Segment You publish servers on the private address DMZ segment the same as you would if your Web server were on the internal network.You can use either Web publishing or server publishing rules to allow external network users access to your Web server on the private address DMZ segment. We’ve noticed that people who have configured security for outbound access on the external ISA server (by making the downstream ISA server a Web Proxy and Firewall client of the upstream and then setting user-based access controls on the external ISA server for outbound access) will create protocol rules to allow the DMZ Web server outbound access.This is not required.The reason why is that the Web server doesn’t need to make any new outbound connections to the client making the request. The ISA server creates a “dynamic protocol rule” to allow the published server to respond to the external client’s request.

NOTE There is an exception to this situation. If you publish an FTP server on the DMZ segment and you do not create a site and content rule that allows the FTP server access to all sites and content, the FTP server publishing rule will fail. The reason for this is that the FTP server needs to create a new outbound connection when sending data over the data channel in PORT mode.

Be mindful of name resolution issues when you publish servers on the private DMZ segment. External network clients resolve the name of your public Web site to the IP address of the external interface of the external ISA server. Internal network clients could resolve the name of the Web site on the private address DMZ segment to either the public address on the external interface of the external ISA server or the actual private IP address the server uses on the DMZ segment. Our recommendation is that you configure your DNS infrastructure so that internal network clients access the Web servers on the DMZ segment via the Web server’s IP address on the DMZ, rather than by “looping back” through the external interface of the external ISA server computer (Figure 3.29). This presents an interesting challenge to your DNS zone designs. Should the DMZ servers’ private addresses be put in your internal zone database files, should you put the public addresses for the DMZ servers in zone files on your public DNS servers, or should you create a completely separate DNS zone just for the servers on the DMZ?

www.syngress.com

152


Figure 3.29 Looping Back through the External Interface of the External ISA Server in a Back-to-Back Private Network DMZ Configuration External ISA Server sends “looped” request back to the Web Server on DMZ

Internal ISA Server resolves name of DMZ Web server to IP address on external interface of the external ISA Server, “looping through” the external ISA Server’s external interface Client sends request to internal ISA Server

Workstation

Workstation

ISA SERVER DEFCON 1 If you want to loop back through the external interface of the external ISA server, you need to make sure that the internal network client is a Web Proxy client and the downstream ISA server needs to be a Web Proxy client of the upstream ISA server (Web Proxy chaining). You need the requests proxied by the Web Proxy service instead of just NAT’ed by the Firewall service. If the internal ISA server sends a request to the upstream as a plain SecureNAT client of the upstream ISA server, the request to the DMZ host through the external interface of the external ISA server might fail because of the “isotropic bounce” phenomenon. The ISA server that is a SecureNAT client sends the request to the external ISA server. The external ISA server dutifully forwards the request to the published server on the private address DMZ network. The published server receives the request forwarded by the external ISA server. The published server

www.syngress.com


153

receives the source IP address of the internal ISA server because the external ISA server included this information in the forwarded request. The published server on the DMZ directly answers the internal ISA server acting as a SecureNAT client. The problem is that the internal ISA server expects an answer from the external ISA server, not from the published server on the DMZ; therefore, the answer from the published server is ignored and dropped by the internal ISA server.

This presents an interesting challenge when designing your DNZ zones. How should the addresses for the servers in the DMZ segment be resolved? Should you put the private addresses the servers on the DMZ user into your private network’s DNS? Should you put the public addresses that are used in the server publishing rules to publish your DMZ servers into your private network’s DNS, or should you create a entirely separate zone for your internal network clients to use when accessing resources on the DMZ? We believe the best solution is to put the private addresses for the servers on the DMZ segment in your private network DNS servers. Since only your internal network clients have access to these DNS servers, no external user will ever be able to access the actual IP addressing scheme you use on the DMZ segment.The key concept here is that you keep the public and private DNS infrastructure separate. Speaking of name resolution, you’ll want to take care of a special problem that can crop up due to how name resolution works on the external ISA server.When an external client sends a request for a Web resource located on the DMZ segment, the request will be something like www.dmzhost.net. In the most common scenario, the external ISA server is configured to use a public DNS server. Because of this, the ISA server resolves the name www.dmzhost.net to the external interface of the ISA server. There’s nothing wrong with this, but it presents real problems if you want to optimize the data in your Web Proxy logs.To get the most meaningful data in your Web Proxy logs, you should configure your Web publishing rules to redirect to the published server using the same name the external client uses to access the resource on the DMZ segment. An example of this configuration appears in Figure 3.30. Can you see where you might run into a problem when you use a public DNS server on the external ISA server and configure the Web publishing rule in this way? You’ll end up with a loop condition, because the public DNS resolves the name to the external interface of the ISA server.The external ISA server will forward the request to the external interface of the ISA server, and when the external interface of the ISA server tries to forward the request again, it sends it back to the external interface of the ISA server! The solution is to create a HOSTS file entry for www.dmzhost.net.The entry in the HOSTS file is automatically placed in the DNS cache.The cache is always checked www.syngress.com

154


before a DNS server is queried.This allows you to enter the DMZ address of the published server into the HOSTS file. Now when the external ISA server receives the request for www.dmzhost.net, the request is forwarded to the DMZ Web server. Figure 3.30 Redirecting a Web Publishing Rule Using the Same Name the External Client Uses to Access the Published Resource

ISA SERVER ALERT Another benefit you’ll see when you use the HOSTS file is the disappearance of the dreaded 14120 error. You can create a Web publishing rule using the IP address of the DMZ host instead of an FQDN and you’ll avoid the loop. However, your Event Log will be littered with 14120 errors. One way to eliminate 14120 from your Event Viewer is to disable the alert for Resource Allocation Errors. However, the HOSTS file is a better solution because you won’t have to disable the alert (which can be a helpful troubleshooting tool).

Publishing Internal Network Web Sites in a Private Address Back-to-Back DMZ Publishing private address DMZ Web servers is a virtual no-brainer compared to publishing Web sites on the internal network through the back-to-back private address DMZ.The main reason for this is that we typically don’t think about Web routing pules. Most ISA servers we have had the pleasure to deal with are focused on allowing outbound access. In a back-to-back private address DMZ, we just configure the downstream ISA server to be a Web Proxy client of the upstream ISA server using a Web www.syngress.com


155

routing rule that forwards all requests to the upstream ISA server.The Web routing rule uses the destination set All destinations (Figure 3.31) This usually works fine and all requests are routed to the upstream ISA server. Figure 3.31 What Appears in the Web Browser When a Proxy Chain Loop Occurs

While this setup works if all you’re concerned about is outbound access for internal network clients, this “default” routing rule on the internal ISA server can wreck havoc on your Web publishing rules. In our ideal back-to-back private address DMZ, you’ve configured the downstream ISA server to be both a Web Proxy and Firewall client to the upstream ISA server. As you saw earlier in this chapter, this type of setup works great and allows better security for outbound access through the external ISA server. You’ll run into problems with Web publishing if you use a default Web routing rule on the internal ISA server that forwards all requests going through the Web Proxy service to the upstream ISA server’s Web Proxy service.What you’ll end up with is a “proxy chain loop.” Figure 3.32 shows what the external client will see in the browser when such an error occurs. You’ll also see an error appear in the application log (Figure 3.33).What’s of interest here is that this entry is seen on the external ISA server.The Web routing error is actually on the internal ISA server, not the external ISA server! What causes this proxy chain loop? Let’s look at what happens when an external network client makes a request for www.internal.net (Figure 3.34).The server is located on the internal network behind the internal ISA server.

www.syngress.com

156


Figure 3.32 What Appears in the Web Browser When a Proxy Chain Loop Occurs

Figure 3.33 Proxy Chain Loop Error in the Application Log Seen on the Internal and External ISA Server Computers

1. The external network client sends the request for www.internal.net to the external interface of the external ISA server. 2. The external ISA server has a Web publishing rule that redirects the request to www.internal.net.There is a HOSTS file entry on the external ISA server that matches www.internal.net to the IP address on the external interface of the internal ISA server that is configured as the Incoming Web Requests listener for the site.This Web publishing rule is configured to send the original host header.The request is forwarded to the internal ISA server.

www.syngress.com


157

3. The request for www.internal.net is received by the external interface of the internal ISA server.The internal ISA server is a Web Proxy client of the external ISA server and has a Web routing rule configured to send all requests intercepted by the Web Proxy service to the upstream ISA server’s Web Proxy service.The internal ISA server’s Web Proxy service sends the request for www.internal.net to the external ISA server because of the Web routing rule. 4. The internal and external ISA servers detect the proxy chain loop.The external ISA server returns to the external client information about this error, and both the internal and external ISA servers register the error in their application logs. An alert also appears in the ISA Management console. Figure 3.34 A Proxy Chain Loop Due to a Configuration Error in the Web Routing Rules External client

www.internal.net Internal ISA External ISA www.internal.net

Web Server

www.internal.net www.internal.net A Proxy Chain Loop occurs when the Web Routing Rule on the internal ISA Server is configured to forward all requests to the upstream Web Proxy service

You can avoid this error by configuring a Web routing rule that forwards all requests for external destinations to the upstream ISA server’s Web Proxy service (Figure 3.35). Since the published server is on the internal network, and the name www.internal.net resolves to the internal IP address of the Web server (either because you have a HOSTS file entry on the internal ISA server, or you configured your internal DNS infrastructure in such a way as to resolve www.internal.net to its internal network IP address), the request is forwarded to the internal Web server based on the Web publishing rule configured on the internal ISA server. Notice that the Web routing rule that forwards requests to the upstream ISA server does not interfere with forwarding the inbound requests to the internal Web server.The Web routing rule only applies to external destinations, and since the server being published with the Web publishing rule is an internal destination, the Web routing rule doesn’t apply. What routing rule does apply to this request? The default Web routing rule. www.syngress.com

158


Figure 3.35 A Routing Rule Applied to All External Destinations

The default rule is always applied last.The action for the default rule is to process requests by retrieving them directly from the specified destination (Figure 3.36). Figure 3.36 The Default Routing Rule Is Configured to Obtain Objects from the Specified Destination

Let’s see if we can boil down the important configuration settings on the internal and external ISA server computers in the private address back-to-back DMZ configuration (Tables 3.5 and 3.6).This will help you replicate the optimum configuration for your private address back-to-back DMZ configuration on your own network.

www.syngress.com


159

Table 3.5 External ISA Server Configuration Setting

Value

Incoming Web Requests listener

The Configure listeners individually per IP address option is selected and an IP address bound to the external interface is dedicated to the listener. The Use the same listener configuration for all internal IP addresses option is selected. All IIS services are disabled. Autodiscovery information publishing is disabled. All Open User—all sites and content are available at all times to the user account created for the internal ISA server’s Web Proxy service to use for Web Proxy chaining. This account is created on the external ISA server and is used on the internal ISA server when configuring the downstream ISA server as a Web Proxy client (downstream Web chaining client). If you don’t want to use user based access controls (the most secure method), you can create a client address set and control access using the set. All Open User—all protocols are available at all times to the user account created for the internal ISA server’s Firewall service to use for firewall chaining. This account is created on the external ISA server and is used on the internal ISA server when configuring the downstream ISA server as a Web Proxy client (downstream Web chaining client). If you don’t want to use user-based authentication (the most secure option), you can use a client address set and allow access to the set. Packet filtering is enabled. IP routing is enabled. Enable intrusion detection is enabled. Enable filtering IP fragments is enabled. Enable filtering IP options is enabled. All attacks are selected on the Intrusion Detection tab. PPTP through ISA firewall is enabled. Web publishing rules are configured on the external ISA server using an FQDN that matches what the user sends to the HTTP request. (That is, the entry in the Destination Set and the entry in the Redirect the request to this internal Web server text box are the same.) A HOSTS file entry is created for each published server and it resolves to the IP address used on the internal ISA server’s Incoming Web Requests listener.

Outgoing Web Requests listener IIS services Autodiscovery Site and content rule

Protocol rules

IP packet filters

Web publishing rules

Continued

www.syngress.com

160


Table 3.5 External ISA Server Configuration Setting

Value

Server publishing rules

Server publishing rules are configured to listen on any of the external IP addresses on the external ISA server. The requests are redirected to any of the external IP addresses on the internal ISA server. Create destination sets to support Web publishing rules.

Policy elements: destination sets Policy elements: client address sets

Policy elements: protocol definitions

Caching configuration properties

Firewall and Web routing

www.syngress.com

Create client address sets to support outbound access control from the DMZ to the Internet through the external ISA server. Client address sets would only be required if you did not want to use user-based access controls for outbound access through the external ISA server. You should not need to create any special protocol definitions on the external ISA server. The reason for this is that the downstream ISA server is a Firewall client of the upstream and therefore does not suffer from the limitations of being a SecureNAT client. However, for complex protocols, you might need to configure the appropriate primary and secondary connections for the complex protocols so that the upstream ISA server knows how to handle the request. HTTP and FTP caching is enabled. Configure conservative caching policies on the external ISA server. You can finetune them on the internal ISA server (where the vast majority of requests originate). No firewall or Web routing configuration changes are required on the external ISA server to support communications with an upstream. However, if you have multiple ISA servers in a Firewall or Web Proxy chain, the upstream ISA server might be downstream to another ISA server. In that case, you will need to configure firewall and Web routing to make the ISA server a Firewall and Web Proxy client of the upstream. You might also want to configure Web routing rules to support requirements other than Web Proxy chaining.


161

Table 3.6 Internal ISA Server Configuration Setting

Value

Incoming Web Requests listener

The Configure listeners individually per IP address option is selected and an IP address bound to the external interface is dedicated to the listener. The Use the same listener configuration for all internal IP addresses option is selected. All IIS services are disabled. Autodiscovery information publishing is enabled. Site and content rules are configured to meet your outbound access requirements. Fine-tune your outbound access control on the internal ISA server, not on the external ISA server. The reason why you want to finetune your outbound access policy on the internal ISA server is that the internal ISA server is a member of the internal network domain. Because the internal ISA server is a member of the internal network domain, it will be able to control outbound access based on user/group membership. Protocol rules are configured to meet your outbound access requirements. Fine-tune your outbound access policy on the internal ISA server, not on the external ISA server. Packet filtering is enabled. IP routing is enabled. Enable intrusion detection is enabled. Enable filtering IP fragments is enabled. Enable filtering IP options is enabled. All attacks are selected on the Intrusion Detection tab. PPTP through ISA firewall is enabled. Web publishing rules are configured on the internal ISA server using an FQDN that matches what the upstream ISA server sends to the HTTP request. You should have configured the Web publishing rule on the upstream ISA server to include the original host header. (That is, the entry in the Destination Set and the entry in the Redirect the request to this internal Web server text box are the same.) A HOSTS file entry is created for each published server and it resolves to the IP address used by the server on the internal network. Server publishing rules are configured to listen on any of the external IP addresses on the internal ISA server. The requests are redirected to the IP address of the server on the internal network.

Outgoing Web Requests listener IIS services Autodiscovery Site and content rule

Protocol rules

IP packet filters

Web publishing rules

Server publishing rules

Continued

www.syngress.com

162


Table 3.6 Internal ISA Server Configuration Setting

Value

Policy elements: destination sets Policy elements: client address sets

Create destination sets to support Web publishing rules.

Policy elements: protocol definitions Caching configuration properties Firewall and Web routing

Create client address sets to support outbound access control out of the internal network through the internal ISA server. Create protocol rules as needed on the internal ISA server to allow access control for internal network client access to external networks. HTTP and FTP caching is enabled. Customize the caching policies on the internal ISA server. Configure firewall routing so that this computer is a Firewall client to the upstream ISA server. Be sure to enter the credentials correctly and use the name of the upstream server, not the IP address.

Publishing an SMTP Relay on the Private Address DMZ Segment A popular DMZ configuration is to put a one or more SMTP relay servers on the DMZ segment.The advantages of this include: ■

External SMTP servers never directly interact with internal network SMTP servers.

■

External miscreants can never directly interact with internal network SMTP servers.

■

Outbound mail can be sent to the SMTP relay servers and queued there in the event that the Internet connection becomes unavailable.

■

Multiple relay servers on the DMZ provide fault tolerance and load balancing for your SMTP messaging infrastructure.

■

You can offload the duty of spam filtering from your main mail server by placing the filtering software on one or more of the SMTP relay servers.

SMTP relay servers also make it easy for you to prevent an open relay configuration. Open relays accept mail from anyone sent to any domain. Spammers can take advantage of open relays and sent GBs of spam e-mail through a single well-connected open relay.You don’t want your organization’s mail servers blacklisted by allowing an open relay to be under your administrative control. www.syngress.com


163

Publishing an SMTP relay on the DMZ segment requires that you do the following: ■

Create DNS records on a public DNS server so that MX queries for your mail domain resolve to the external interface of the external ISA server computer.You can create multiple MX records for a single domain and assign different weights to each MX record.

■

Create an SMTP server publishing rule on the external ISA server that redirects requests to the IP address of the SMTP relay on the DMZ segment.

■

Configure the SMTP relay with domains that are under your administrative control.These are the domains for which you receive mail.These domains are configured to relay to a smart most, which is the external interface of the internal ISA server.

■

Create a server publishing rule on the internal ISA server that redirects the SMTP messages to your internal SMTP server.

Figure 3.37 shows the basic configuration. Figure 3.37 SMTP Relay Server Configuration Internet SMTP Server

Internet

External VPN/ISA DMZ SMTP Relay 1

SMTP Relay 2

Internal VPN/ISA

www.syngress.com

164


Creating the Public DNS Records for Your Mail Domains Your have a number of options when it comes to adding the MX record. If your DNS records are hosted by your ISP, you can just call them or use the Web interface they provide to add MX records for your mail domain.You can also use the Windows 2000 or Windows .Net DNS server to host your own DNS records. Many organizations prefer to host their own DNS because it’s easier to manage and control their DNS records. If you use a Windows 2000 DNS server to host your own DNS, perform the following steps to create MX records for your mail domains: 1. Open the DNS console from the Administrative Tools menu. 2. Expand your Reverse Lookup Zones node in the left pane of the console. Make sure you have a reverse lookup zone for the network ID of the external interface on which the external ISA server is located. If not, create one. Just right-click on the Reverse Lookup Zones node, click on New Zone, and follow the instructions provided by the wizard. 3. Expand the Forward Lookup Zones node in the left pane of the console. Find your mail domain and click on it.You need to create a Host (A) record for the IP address on the external interface of the external ISA server. Right-click on the forward lookup zone and click the New Host command. Enter the Name of the server, the IP address that you’re using to publish the server, and create a pointer record, as shown in Figure 3.38. If you don’t plan to change your record frequently, you might consider changing the TTL to something longer than one hour. Figure 3.38 Creating a Host Record for the SMTP Server Publishing Rule

4. The MX record depends on the Host (A) record. Right-click on the domain name and click the New Mail Exchanger record. Click Browse to drill down to your domain name, and then double-click on the Host (A) record www.syngress.com


165

you created (Figure 3.39). If you have more than one mail server, you can set a mail server priority so that one server is used preferentially over another. If you set them both at the same value, a mail server will be selected at random by the client SMTP server. As with the Host (A) record, we highly recommend that you increase the Time To Live (TTL) (unless you are using a dynamic address and DDNS). If you set the TTL for 24 hours or longer, you can survive periodic disruptions in your DNS publishing rules and still be able to receive mail. Figure 3.39 Creating the MX Record for Your Mail Domain

ISA SERVER ALERT We highly recommend that you create one or more MX records for your mail servers. Although MX records are not required (per RFC), many commercial mail servers might not want to work with your mail server if you don’t create an MX record. Another reason why you should create MX records is for fault tolerance. You can create two or more MX records and use these for load balancing and fault tolerance. If one of your DMZ SMTP relay servers becomes unavailable, external SMTP servers will be able to use the information in your MX records to forward mail to a secondary SMTP server in your domain.

Creating the SMTP Server Publishing Rule on the External ISA Server The next step is to create the SMTP server publishing rule on the external ISA server. Server publishing rules are relatively straightforward, as all you need to provide is: www.syngress.com

166


The external IP address you want the rule to listen on

■

The TCP or UDP protocols you want the rule to listen for

■

The IP address you want the rule to forward the request to (in this case, on the DMZ segment)

The Firewall service uses the LAT to determine which addresses are internal and which are external.The Firewall service will use a server publishing rule to forward requests from the external network to a LAT network host.You can’t use server publishing rules to forward requests from a LAT segment to another LAT segment, and you can’t use them to forward requests from an external segment to another external segment. If you want to do these things, you can use DMZ segments or RRAS routing, respectively. Perform the following steps to create the SMTP server publishing rule on the external ISA server computer: 1. Make sure the IIS SMTP service has been disabled on the external computer. IIS is installed and enabled by default on Windows 2000 computers, but is not installed on Windows .Net servers. If the IIS SMTP service is enabled, it will compete for TCP port 25 on the external interface because of socket pooling issues.You can start creating the server publishing rule after the SMTP service is disabled. 2. Open the ISA Management console and expand your server or array name. Expand the Publishing node and right-click on the Server Publishing Rules node. Point to New, and click on Rule. 3. On the first page of the wizard, give the rule a name. In this example, we’ll call it SMTP Relay 1 (Figure 3.40). Click Next. Figure 3.40 Naming the New Server Publishing Rule

www.syngress.com


167

4. On the Address Mapping page, type in the IP address of internal server and External IP address on ISA Server (Figure 3.41).You might find it easier to click the Browse button when adding the external IP address that the rule will listen on, as this will show all the IP addresses bound to the external interface.We recommend that you do not use the Find button for the internal server, as we’ve found it to be of little use. Click Next. Figure 3.41 Entering the External IP Address and the DMZ SMTP Relay Server’s IP Address in the Address Mapping Page

5. On the Protocol Settings page (Figure 3.42), select the SMTP Server protocol. ISA Server defines “server” protocols as protocols with inbound primary connections. For example, if you want to create a protocol definition for an SMTP server, you would make the primary connection TCP port 25 inbound. That is how the built-in SMTP server protocol definition is defined. Click Next to continue. Figure 3.42 Selecting the Server Protocol in the Protocol Settings Page

www.syngress.com

168


6. Select the Any request option on the Client Type page.You want to allow any SMTP server to send mail to your DMZ SMTP relays, so the Any request option is appropriate.This won’t be the case on the internal ISA server, as you’ll see later. 7. On the last page of the wizard, review your settings, and click Finish.

Configuring the DMZ SMTP Relay Server The SMTP server in the private address DMZ segment should be thought of as a bastion host.The traditional definition of a bastion host is a computer with at least one interface directly connected to the Internet. An expanded interpretation of bastion host includes any computer allowing inbound communications from an Internet host. Note that in our private address DMZ that external network clients do not have direct communication with the SMTP server because the external client must go through the ISA server. This is an important distinction because ISA server isn’t just routing the requests from a public network host and the SMTP server on the DMZ segment. ISA Server has “smart” application filters that can help protect your servers from harm by Internet intruders. In the case of our SMTP relay server on the DMZ, the ISA server can use its SMTP application filter (Figure 3.43) to protect the DMZ SMTP server from buffer overflow attacks. Figure 3.43 The SMTP Command Tab

You can secure your DMZ host by applying a security template (security .inf file). Because this server should be used only for SMTP relay, you don’t need to support a slew of extraneous services. Applying security templates can seriously hamper, and often www.syngress.com


169

disable, core networking services on a Windows 2000/Windows .Net server.This is actually a good effect of the security templates on DMZ hosts, because all you want to support is the SMTP service. None of the security templates will disable the SMTP service. See Chapter 10, “Protecting Data in Transit with IP Security,” for details on how to apply a security template. Make sure that you always thoroughly test a security template before deploying it in your product network.

ISA SERVER ALERT The SMTP application filter is very useful in blocking dangerous buffer overflow attacks. However, there is one drawback to the SMTP application filter: it does not support authentication. If you try to secure your SMTP server by requiring authentication, and then enable the SMTP application filter on the ISA server (located in front of the SMTP server), the authentication request to the SMTP server will fail. We recommend that you enable the SMTP application filter for security reasons, but realize that external users (including your traveling employees) will not be able to use these SMTP servers; your relay servers are to be used only by Internet SMTP servers that relay mail to your domains. External users should use their own ISP’s SMTP servers when sending mail via SMTP. This is somewhat problematic when using IMAP4, which requires the use of SMTP to send mail. The problem with this option is that often the external user doesn’t have access to another SMTP server. For example, you have an employee calling in from an hotel room fitted with a broadband connection. The road warrior has a connection, but no SMTP server. We’ll examine possible solutions to this problem in Chapter 6

Perform the following steps on the DMZ SMTP relay computer: 1. Before going to the SMTP relay, make sure that the SMTP application filter on the external ISA server is enabled. If not, enable the filter and restart the Firewall service. 2. At the SMTP relay server, open the Internet Services Manager from the Administrative Tools menu. 3. In the Internet Information Services console, click on each service except for the Default SMTP Virtual Server, and click the square “stop” button in the button bar.You want to stop all IIS services except for the SMTP service (Figure 3.44).This will stop the extra IIS services from running.To make sure that the services do not start up again after a restart, you should go to the Services applet in the Administrative Tools menu and set the startup type for the NNTP, FTP, and WWW services as Manual or Disabled.

www.syngress.com

170


Figure 3.44 Stopping the IIS Services in the Internet Information Services Console

4. Right-click on the Default SMTP Virtual Server node and click Properties. 5. On the General tab (Figure 3.45), change the IP address from All Unassigned to a specific IP address bound on the server’s interface.You should also enable logging so that you can track messages.This will be a great benefit when you need to trace down Internet criminals who try to use your SMTP servers to commit illegal acts. 6. Click on the Access tab.You don’t have to worry about Access control because you are not using authentication-based access control.The same goes for Secure communication and Connection control. Click Relay restrictions. 7. In the Relay Restrictions dialog box, make sure that the Only the list below option is selected and that the list is empty. Remove the check mark from the Allow all computers which successfully authenticate to relay, regardless of the list above check box (Figure 3.46).We never want any computer, authenticated or not, to relay through the virtual server.The only relay will be through specific remote domains we configure on this server. Click OK in the Relay Restrictions dialog box.

www.syngress.com


171

Figure 3.45 Changing the Listening IP Address for the SMTP Service

Figure 3.46 Disabling Relay on the Default SMTP Virtual Server

8. Click the Messages tab (Figure 3.47). Set message size, session size, number of message per connection, and number of recipients per message parameters here.These settings can be used to prevent the server from becoming overburdened, as well as enforcing network mail policy. Be sure to type in an e-mail address that non-delivery reports (NDRs) can be sent to in the Send copy of Non-Delivery report to text box. If you don’t want to apply any restrictions, just remove the check marks from the check boxes. Click Apply and then click OK. 9. Now we need to create the Remote Domain for each mail domain under our administrative control. Right-click on the Domains node, point to New, and click Domain. www.syngress.com

172


Figure 3.47 The Messages Tab in the SMTP Server Properties Dialog Box

10. On the Welcome page of the New Remote Domain Wizard, select the Remote option and click Next. 11. On the Select Domain Name page (Figure 3.48), type in your mail domain name. If you manage multiple subdomains, you might want to include an asterisk (*) wildcard character in the domain name, such as *.mymaildomain.com. If you do not manage any subdomains, you can forego the wildcard. Click Finish to create the remote domain. Figure 3.48 Entering Your E-Mail Domain on the Select Domain Name Page

www.syngress.com


173

12. You e-mail domain now appears in the right pane of the console. Doubleclick the domain name. Place a check mark in the Allow incoming mail to be relayed to this domain check box (Figure 3.49). Select the Forward all mail to smart host option and then enter the IP address of the external interface of the internal ISA server that you will use on the server publishing rule on the internal ISA server to publish your internal network SMTP server. Make sure the IP address is in brackets, or the server will try to resolve the IP address to an IP address (the server will think the IP address is an FQDN if you don’t use brackets). Click Apply and then click OK. Figure 3.49 Allowing Mail to Be Relayed to Your Internal ISA Server

Allowing Inbound VPN Connections through a Back-to-Back ISA Server DMZ Virtual private networking is a very hot topic—and for good reason.You can save a huge amount of money by replacing your existing dial-up remote access solution with a virtual private network (VPN) solution. Get rid of long distance bills and 800 numbers and replace the old infrastructure with a high-speed Internet connection. Fortunately for ISA Server administrators, ISA Server is up to the task of handling VPN network communications.The ISA Server VPN wizards make configuring a VPN server a virtual no-brainer.The wizard does the work of configuring ISA Server packet filters, and it also configures and starts the Routing and Remote Access Service (RRAS). Just a couple of tweaks to RRAS might be required after the wizard is done. Once your custom tweaks are in place, you’re ready to roll.

www.syngress.com

174


ISA SERVER ALERT The ISA Server VPN Server wizard does a pretty good job at creating the proper packet filters and configuring and starting the RRAS. However, you might want to customize elements of the VPN server configuration to meet the special requirements of your network. For some quick hints and tips on VPN server configuration, check out www.isaserver.org/pages/articles.asp?art=56. For a comprehensive review of Microsoft VPN services, check out www.microsoft.com/vpn.

One VPN problem that seems to vex many ISA Server administrators is how to allow external network VPN clients access to an internal network in a back-to-back private address DMZ environment.The problem is that many admins might not have worked with tunneling VPN tunnels inside of other VPN tunnels.This configuration is often referred to as VPN passthrough because an initial tunnel is established to the external ISA server, and the second tunnel passes through the established connection to the external ISA server to access the internal ISA server. To make the configuration as easy as possible, we’ll look at the following issues: ■

Configuring the internal ISA server

■

Configuring the external ISA server

■

Configuring the VPN client computer

As you’ll see, allowing your external network VPN clients access to your internal network through a back-to-back ISA server configuration is quite easy—once you know how.

Configuring the Internal ISA Server In a back-to-back ISA server configuration, the ISA server with an interface in the DMZ and an interface on the internal corporate network is considered the internal ISA server.This ISA server will act as the end point for the final VPN link for external network VPN clients and allow them access to resources on the internal network. Interface configuration is straightforward, as shown in Tables 3.7 and 3.8. Table 3.7 Internal Interface Configuration Setting

Value

IP address

Address valid on the network segment to which the interface is connected. Mask appropriate for the network segment to which the interface is connected.

Subnet mask

Continued

www.syngress.com


175

Table 3.7 Internal Interface Configuration Setting

Value

Default gateway

No default gateway should ever be configured on the internal interface of an ISA server. Use static routing table entries or routing protocols to support routing on the internal network. Address of the DNS server on the internal network. Make sure that the internal interface is listed first on the adapters list seen in the Advanced dialog box in the Network and Dial-up Connections window. This adapter can be configured to dynamically register with a DDNS server on the internal network. Address of the WINS server on the internal network. NetBIOS over TCP/IP should be enabled.

DNS server

WINS server

Table 3.8 External Interface Configuration Setting

Value

IP address

Address valid on the network segment to which the interface is connected. Mask appropriate for the network segment to which the interface is connected. IP address of the internal interface of the external ISA server. Note that this will not break your Firewall and Web Proxy chaining configuration. A DNS server address is not required on the external interface. If you have your network infrastructure configured so that the internal DNS server can resolve Internet host names, no other DNS server will be required. This adapter should not be configured to dynamically register with a DDNS. No WINS server address is configured on the external interface of the ISA server. NetBIOS over TCP/IP should be disabled. File and printer services should be disabled.

Subnet mask Default gateway

DNS server

WINS server

While the interface configuration is simple, you have to prepare the network to support the VPN servers and clients.We recommend that you install one or more DNS servers on your internal network that can resolve Internet host names.You can do this by ensuring that the Root Hints file is primed on the DNS server, and that the ISA servers in the path to the Internet have access policies that allow the DNS server access to both TCP and UDP port 53 outbound. Create a protocol rule allowing the internal DNS servers outbound access to UDP and TCP port 53, and apply that rule to a client address set that includes the IP addresses of your internal network DNS servers.

www.syngress.com

176


ISA SERVER DEFCON 1 We recommend that you disable recursion on your internal network DNS servers, and configure the DNS servers to use your ISP’s DNS server as a forwarder. The reason for this is your ISP’s DNS servers have a much larger DNS cache than your DNS server can ever have. Using your ISP’s DNS server will significantly improve the performance of DNS queries, and when recursion is disabled, “host not found” messages are returned to the user much faster. You should also use separate DNS servers for internal network clients and external network clients. DNS servers used by internal network clients can be configured to use recursion or a forwarder to resolve Internet host names for internal network clients. DNS servers used by external network clients should never be configured to allow recursion. You do not want your external DNS servers to answers queries for any domain outside of those under your administrative control. That is to say, you do not want the DNS servers to answer queries for any domain except for those you’ve configured on that server. Allowing the DNS server to perform recursion opens the server up to wellknown DNS exploits, such as cache poisoning.

All of your published servers should be included in a client address set (or several client address sets, depending on your environment), so that you can apply the client address set to protocol and site and content rules on the ISA server.You need to control outbound access using a client address set because there is usually no one logged on to a published server. In fact, it’s good security policy to log all users off a server if no one is managing it. If someone is logged on to the server, an exploit could be carried out against it under the security context of the logged-on user. While many Windows 2000 texts state that you do not need a WINS server on your internal network, you’ll probably want to install one.Then, configure your VPN servers to be WINS clients if you want to support network browsing for your VPN clients. However, if you don’t need to support the dreaded browser service for your VPN clients, there is no compelling reason to install a WINS server (the exception being if you have NetBIOS-dependent applications or services). In the example we’re covering here, the internal ISA server is a member server on an internal network Windows 2000 domain.We will not cover issues involved with making the internal ISA server a domain controller (because it’s assumed that if you have taken the time and money to put together a back-to-back ISA server configuration, you don’t want to alter your configuration by making the internal ISA server a domain controller). If you want to know more about configuring the ISA server as a domain controller, check out this author’s article at www.isaserver.org/pages/articles .asp?art=17. www.syngress.com


177

ISA SERVER ALERT VPN clients can see domain computers in their “My Network Places” or “Network Neighborhood” if those computers are domain members. If the client has never been a domain member, you might experience problems with domain browsing. Even if the browse list does not appear, the client will still be able to connect to network resources using a UNC path, as long as you have a WINS server in place and the VPN clients are configured to use it. The most reliable way to ensure that the client gets the browse list is to join the client to the domain. This will be problematic for home users who have their own private networks. In that case, you might have success by having the remote client configure itself to be a member of a workgroup that has the same name as the NetBIOS name of the domain containing the browse list they want. You might want to consider using NetSwitcher (www.netswitcher.com/) to help you with these configuration changes.

Our goal is to create two VPN servers; the first is on the external ISA server, and the second is on the internal ISA server. External network clients first connect to the external VPN server. After the external network client connects to the external VPN server, it creates a second tunnel inside the first tunnel that will connect the client to the internal VPN server. Figure 3.50 shows the VPN connections to the external and internal ISA/VPN servers. Figure 3.50 Private Address Back-to-Back DMZ Architecture for VPN Connections

Internet

VPN Tunnel 1

VPN Tunnel 2

External VPN/ISA

Internal VPN/ISA

www.syngress.com

178


Configuring the VPN Server ISA Server makes it easy to configure the VPN server. Just perform the following steps on both the internal and external ISA servers: 1. Open the ISA Management console and drill down to the Network Configuration node. 2. Right-click on the Network Configuration node, and click All VPN Client Connections. 3. The Welcome to the ISA Virtual Private Network Configuration Wizard appears (Figure 3.51). Click Next. Figure 3.51 Starting the VPN Server Wizard

4. On the Completing the ISA VPN Server Configuration Wizard page, click Details and read what the wizard will do to your machine. After reading the details, click Back.Then, click Finish. 5. If RRAS isn’t already started, the wizard will start the service for you. It will also configure packet filters to allow inbound PPTP and L2TP/IPSec connections. That’s it! The wizard quickly and painlessly configured both RRAS and ISA Server to allow inbound VPN calls. However, your work isn’t completely done from the VPN/RRAS viewpoint.While the wizard does an admirable job, it might not get everything right or the way you want it when it comes to configuring the VPN server. You should go to the RRAS console and check out your configuration. If you need some help, check out www.isaserver.org/pages/article.asp?id=232. Another important consideration is how you configure remote access permissions for your VPN server.Will access be controlled by policy or by account configuration? www.syngress.com


179

You don’t have the choice to allow access by policy, and you must configure the individual accounts to have access if you have a mixed-mode Active Directory domain. If you have a native-mode domain, you can use RRAS policy to control access. Remember, the only reason to run in mixed mode is if you have a Windows NT 4.0 backup domain controller (BDC) in your domain. If you don’t, switch to native mode immediately!

Configuring the External ISA Server The ISA server interfacing with the untrusted network (the Internet) and the DMZ segment is the external ISA server.The external ISA server is the first point of attack for Internet intruders.This machine should be configured as either a stand-alone server in a workgroup, or as a member of a domain that is accessible from the DMZ segment. You want this machine to have nothing to do with the authentication environment for your internal network. Like the internal ISA server, interface configuration is straightforward on the external ISA server (Tables 3.9 and 3.10). Table 3.9 Internal Interface Configuration Setting

Value

IP address Subnet mask Default gateway

Address valid on the DMZ segment. Mask appropriate for the DMZ segment. Never put a default gateway on an ISA server internal interface. If you need to route to internal network segments, create static routing table entries or use a routing protocol. Variable. See explanation below. The interface should not register with a dynamic DNS server. Variable, but typically a WINS server is not used on a DMZ segment. If NetBIOS communications are not allowed on the DMZ (recommended), disable NetBIOS on the internal interface. If NetBIOS communications are not allowed on the DMZ (recommended), disable file and print sharing on the internal interface.

DNS server WINS server


Value

IP address Subnet mask Default gateway

According to your ISP. According to your ISP. Either assigned by your ISP or the upstream router connected to the Internet. Continued

www.syngress.com

180



Value

DNS server

Variable, but typically you only need a DNS server configured on the internal interface. None. NetBIOS should be disabled on the external interface. File and Print services disabled on the external interface.

WINS server

Notice that some of the settings on the internal interface of the external ISA server are variable.You might or might not have a dedicated name resolution scheme for your DMZ segment. If you have a public DNS server, there’s a good chance that you’re running a DNS server on the DMZ. If that’s the case, you might want to include that DNS server’s address on the internal interface of the ISA server. If you are hosting public DNS services on your internal network, enter the address of the external IP address on the internal ISA server, which is publishing your DNS server.The NetBIOS interface should generally be disabled on both of the external ISA server’s interfaces. However, if you require file and printer sharing and the Microsoft client on the internal interface, you’ll have to leave the NetBIOS interface enabled.We recommend turning it off to protect your external ISA server.

ISA SERVER DEFCON 1 Keep in mind that when a user establishes a VPN connection into the external ISA server, that user might be directly connected to your DMZ segment (which includes the external ISA server). You want to make sure that the user does not have permissions to access anything on the DMZ segment using the credentials supplied by the VPN client. Create a group on the external ISA server that has no permissions to access resources on the DMZ segment or the external ISA server itself. Put all accounts in this group. You can create a dedicated account that all users use to access the external ISA server, or you can synchronize domain accounts with the local account database stored on the stand-alone Windows 2000 server acting as the external ISA/VPN server.

VPN Server Configuration Issues There are a few VPN configuration issues worth noting before we proceed. First, make sure that you configure an IP address range the VPN clients can use when they connect to the external VPN server. It’s very unlikely there will be a DHCP server on the DMZ segment, so you’ll need to create a static address pool for the VPN clients.The internal ISA/VPN server can assign addresses obtained from a DHCP server on the internal network, or you can create a static address pool there, too. www.syngress.com


181

You do have the option is letting the assign via DHCP option stay as it is. If you do not have a DHCP server on the DMZ segment, the VPN clients will be assigned Automatic Private IP Addressing (APIPA) addresses in the 169.254.0.0/16 range. However, this complicates the routing configuration.The VPN clients still need to be able to access the external interface of the internal ISA server, and their only route to the internal DMZ server is through the DMZ.We recommend that you do not depend on autonet addressing and that you create a static address pool that is on the same network ID as the DMZ segment. If you want to use L2TP/IPSec, all machines participating in the VPN links must have a machine certificate trusted by the client and server machines.The easiest way to do this is to have all machines belong to the same domain and configure a group policy that auto-enrolls domain members and assigns them a machine certificate. Unfortunately, you can’t do this on the external ISA server, because it is not a member of the internal network domain.You will have to manually install the certificate on the external ISA/VPN server. The exception to this is to use a preconfigured preshared key. In this case, you can allow your Windows XP L2TP/IPSec clients to access the VPN server. In addition, the new L2TP/IPSec client for Windows NT 4.0 and Win9x supports preshared keys. Windows .Net supports preshared keys right out of the box.You’ll have to perform a Registry hack to get Windows 2000 VPN servers to support preshared keys for L2TP/IPSec connections.We’ll cover this subject in more detail later in this chapter. If you have machines that are not domain members (such as laptops), they can be assigned machine certificates by using the Web browser interface to the Microsoft Certificate Server.When you install the Microsoft Certificate Server, make sure you install it as a standalone root server, or else you will not have the option to use the browser to assign machine certificates.

ISA SERVER ALERT PPTP VPN servers do not require certificates. For a high level of security, you should require EAP/TLS client certificate authentication. The primary weakness of the PPTP VPN protocol is that the level of security is dependent on password complexity. EAP-TLS user certificate authentication bypasses this weakness. PPTP had to be used to allow non-Windows 2000/Windows XP/Windows .Net clients access to the VPN. However, Microsoft has recently released a L2TP/IPSec VPN client for downlevel Windows clients; check it out at http://support.microsoft .com/default.aspx?scid=KB;EN-US;Q325032&. Finally, if you want to allow L2TP/IPSec connections to the ISA/VPN server, you must disable ISA Server fragment filtering. You can do this in the Properties dialog box for IP Packet Filters in the ISA Management console.

www.syngress.com

182


The simplest configuration is to create you own certificates using the Windows 2000 Certificate Server.You always have the option of using third-party client and server certificates.You can install the third-party certificates using the method described by the vendor, although the procedure is typically the same for all certificate types.

Configuring the Client Connections When you configure the VPN client, keep in mind what you’re trying to accomplish: to create a pass-through VPN link.The first connection is to the external ISA/VPN server, and the second connection passes through the first VPN connection to create the link to the internal VPN server.To accomplish this, you first establish a VPN connection with the external ISA server, and then establish a VPN connection with the internal ISA server. Go to the VPN client computer to create the first link (this example uses a Windows 2000 client). In this example, we’ll go over how to configure the VPN client on a Windows 2000 computer. 1. Right-click the My Network Places icon on the desktop, and click Properties. 2. In the Network and Dial-up Connections window, double-click on the Make New Connection icon. 3. Click Next on the Welcome to the Network Connection Wizard page. 4. On the Network Connection Type page (Figure 3.52), select the Connect to a private network through the Internet option. Click Next. Figure 3.52 The Network Connection Type Page

5. On the Public Network page, select the appropriate option for your environment. If the client uses an always-on, directly connected link to the Internet, www.syngress.com


183

use the Do not dial the initial connection option. If the client needs to make a modem dial-up connection before initiating the first VPN connection, select the Automatically dial this initial connection option and select the ISP/modem DUN connectoid from the list. In this example, the client is directly connected to the Internet. Note that if you use a dial-up connection to connect to the Internet, you will not be able to use the first VPN link in the Automatically dial this initial connection for the second VPN link. Click Next. 6. On the Destination Address page (Figure 3.53), type in the FQDN or IP address of the external interface of the external ISA server. Click Next. (Note that in this example, we’re using a private address for demonstration purposes only.You will use a public address in your production environment.) If you use a dynamically assigned address on the external interface of the external ISA/VPN server, you can use a dynamic DNS service such as www.tzo.com. Your dynamically assigned IP address will be updated automatically for your domain, and you will be able to connect to the VPN server regardless of changing IP addresses. Figure 3.53 The Destination Address Page

7. On the Connection Availability page (Figure 3.54), select the option that best fits your security environment.We always select Only for myself for security reasons. Click Next. 8. On the Completing the Network Connection Wizard page (Figure 3.55), name the connection. In this example, we’ll call it VPNEXTERNAL.

www.syngress.com

184


Figure 3.54 The Connection Availability Page

Figure 3.55 The Completing the Network Connection Page

Now let’s configure the second VPN link that connects the client to the internal VPN server: 1. Right-click the My Network Places icon on the desktop and click Properties. 2. In the Network and Dial-up Connections window, double-click on the Make New Connection icon. 3. Click Next on the Welcome to the Network Connection Wizard page. 4. On the Network Connection Type page, select the Connect to a private network through the Internet option. Click Next. 5. On the Public Network page (Figure 3.56), select the Automatically dial this initial connection and select the name of the DUN connectoid used to www.syngress.com


185

connect to the external ISA/VPN server. Note that you can only do this on a client with a dedicated Internet connection, or if you chose not to include the dial-up connection to automatically dial when initiating the first VPN link. Click Next. Figure 3.56 The Public Network Page

6. On the Destination Address page (Figure 3.57), type in the IP address of the external interface of the internal ISA server. Click Next. (Note that in this example, we’re using a private address because the DMZ is a private address DMZ segment.While you do have the option to create a public address DMZ segment in a back-to-back configuration, the procedure is a bit different with the public address DMZ configuration.You only need to route the VPN protocols through the external ISA server, and an external VPN server is not required in a public address DMZ segment.) Figure 3.57 The Destination Address Page

www.syngress.com

186


7. On the Connection Availability page, select the option that fits your security environment best.We always select Only for myself for security reasons. Click Next. 8. On the Completing the Network Connection Wizard page, name the connection. In this example, we’ll call it VPNINTERNAL. That’s all there is to it! You’ll see your links in the Network and Dial-up Connections window (Figure 3.58). Figure 3.58 The VPN Connectoids Appearing in the Network and Dial-Up Connections Window

Double-click on the VPNINTERNAL link (seen in Figure 3.58). In the Connect dialog box that appears, click Connect. After you establish the first connection, you will see the dialog box for the second VPN link. Enter the appropriate credentials and click Connect (Figure 3.59). After the second VPN link is established, you’ll be informed of your success (Figure 3.60). Note in the Network and Dial-up Connections window that both the VPNINTERNAL and VPNEXTERNAL links are active.The VPNEXTERNAL link dialed up automatically to allow the VPNINTERNAL link to complete. You can go to the RRAS consoles of both the ISA/VPN machines and see the connections (Figures 3.61 and Figure 3.62). Notice that we have L2TP/IPSec connections here. An IPSec certificate was installed on both the VPN server and on the VPN client.The VPN server always negotiates with the VPN client the type of VPN link to create. L2TP/IPSec is used preferentially, but if the client or server does not support L2TP/IPSec, PPTP will be used.

www.syngress.com


187

Figure 3.59 Starting Up the VPN Link to the Internal Network

Figure 3.60 The VPN Link to the Internal Network Is Successful

www.syngress.com

188


Figure 3.61 The VPNEXTERNAL Port Status Dialog Box

Figure 3.62 The VPNINTERNAL RRAS Console

In Windows 2000, you can do some very crude monitoring of your L2TP/IPSec connections using the ipsecmon console (Figure 3.63). From the Run command, type ipsecmon and click OK.You’ll see your connections appear in the console. Note that the policy used is the default L2TP/IPSec policy.This policy is created automatically and you cannot view it in the IPSec Policy MMC.

www.syngress.com


189

Figure 3.63 The IPSECMON Utility

ISA SERVER ALERT Windows 2000 creates a default IPSec policy that its applies to L2TP/IPSec VPN connections. This policy is not viewable in the IPSec Policy management console. You can find out what the exact parameters are for the default IPSec Policy used for L2TP connections at http://support.microsoft.com/default .aspx?scid=KB;EN-US;Q248750&. You can disable the default IPSec policy and apply a custom IPSec policy that you create in the IPSec console by following the recommendations at http://support.microsoft.com/default.aspx?scid= KB;EN-US;q258261&. You can also configure the Windows 2000 Server to support pre-shared keys for L2TP/IPSec connections. This is helpful if you want to support L2TP/IPSec connections with downlevel Windows clients (via the new L2TP/IPSec client for 9x and NT), as well as Windows XP and Windows .Net. Instructions for this configuration can be found at http://support.microsoft .com/default.aspx?scid=KB;EN-US;Q240262&. Note that these pre-shared keys are stored in the Registry, which exposes them to anyone with Administrator access to the VPN client or server.

Notes on VPN Client Configuration While configuring the VPN client connection is easy, there are some issues of which you should be aware.The biggest problem you’ll come up against is the dreaded www.syngress.com

190


browser service.This service allows users to browse for internal network resources by using the My Network Places applet.We touched on some of these issues earlier in this chapter. Your best chance at getting the browse list is to configure the client to be a member of the domain, or to configure the client to be a member of a workgroup that has the same name as the domain name that contains the resources the VPN client needs to access. Users should also select the Log on using dial-up connection option (Figure 3.64). Figure 3.64 Logging On via Dial-Up Networking

After they click OK, users need to select the link used to connect to the internal ISA/VPN server, the DUN connectoid that links to the internal VPN server (Figure 3.65). Figure 3.65 Selecting the Network Connection to the Internal VPN

The user will be asked for credentials. After entering the credentials, they click Connect.You can make this easier by having the machine remember the credentials on the initial connection.They will be asked a second or third time for credentials, depending on whether they need to establish a dial-up link to their ISP. Once the link to the internal ISA/VPN Server is established, they will be logged on. No matter how you cut it, accessing resources via the browser service is going to be slow. However, this isn’t all bad, because the frustration with the browser service might just lead you to disable it throughout your organization.The browser service can be a tremendous security risk, because it allows anyone to look around for “interesting stuff ” on your internal network. It’s best to disable the browser service if you can, and make users connect to resources using a UNC path. An even better solution is to create drive mappings for the resources to which the users need to connect. www.syngress.com


191

Back-to-Back VPN Server Afterthoughts Setting up the back-to-back ISA/VPN server is relatively simple once you get all the steps down.The biggest problems are related to certificate assignments and the browser service.The certificate assignment problem can be solved, but there doesn’t appear to be any reliable fix for the performance problems with the browser service, other than implementing a WINS server (which is required for NetBIOS name resolution). As with any VPN rollout, make sure you have your name resolution and routing infrastructure,WINS and DNS configurations in place and working before you start configuring your VPNs. If you don’t, you will have many inexplicable problems that will be difficult to troubleshoot. Your Windows 2000/Windows XP/Windows .NET computers don’t have to rely on the NetBIOS for name resolution; they can use DNS to connect to resources on the internal network. However, most users will use unqualified requests to attach to internal network resources.This can create a problem if the client has no primary DNS suffix configured, and if the adapter hasn’t been configured with a domain suffix search list. Make life easier for yourself and configure the VPN server to assign the VPN clients a WINS server address.

Summing Up Back-to-Back Private Address DMZ Configuration To sum up the back-to-back private address DMZ configuration: 1. Two ISA servers—an internal and an external ISA server. 2. The external ISA server should have the DMZ segment IP addresses in its LAT. 3. The external ISA server uses private IP addresses on the DMZ segment. 4. Access control to servers on the DMZ is accomplished using publishing rules on the external ISA server. Do not use packet filters to control access to the DMZ. 5. The internal ISA server has the internal network IP address in the LAT; do not put the DMZ addresses in the internal ISA server’s LAT. 6. You can use publishing rules if you need a server on the DMZ to access a server on the internal network. 7. You should enable packet filtering on the internal and external ISA servers to optimize security.

www.syngress.com

192


Configure hierarchical Web caching and firewall chaining on the internal ISA server, and add the appropriate accounts to support this configuration on the external ISA server.

Configuring a Public Address Back-to-Back DMZ After going through the details and advantages of putting together a private address DMZ, you might think that we’re including information about how to put a public address DMZ segment here just to be complete.That’s almost true, but there are some real advantages to using a public address DMZ, as public address DMZ segments allow you to use some services that would otherwise be unavailable if you were using only a private address DMZ configuration. For example, suppose you wanted to use the H.323 Gatekeeper service and have all your internal network clients register with the internal ISA server’s H.323 Gatekeeper service.The clients would be able to register with the internal network Gatekeeper, but external network clients would never be able to call your internal network clients because the external ISA server is not able to publish the H.323 protocols and perform the dynamic connection management duties.There is no method that allows you to publish the H.323 protocols.You would need an H.323 protocol definition that supports H.323 publishing, and that protocol definition would need to be able to hook into an application filter that could manage the connections.While the H.323 Gatekeeper does do this to a certain extent, you would not be able to have the users register with both the internal and external H.323 Gatekeepers. Another example would be outbound access using standard (PORT) mode FTP. At this time, it’s impossible to use a PORT mode FTP client on the internal network in a private address back-to-back DMZ configuration when both of the firewalls are ISA Servers.The reasons for this are unclear, but it appears to be an issue with the FTP access. Its doesn’t matter if you’ve configured firewall chaining or not; PORT mode FTP clients on the internal network will not work in a back-to-back private address DMZ configuration. Probably the most important reason why you would want to consider a public address back-to-back DMZ configuration is to allow VPN connections directly to your internal ISA server.While you can use the “tunnel within a tunnel” (VPN passthrough) configuration and allow access to the internal network via VPN, some of your users might be challenged with the perceived complexity of making two connections to access the VPN.With a public address DMZ, there is no need for VPN passthrough. Figure 3.66 shows the public address DMZ setup with a VPN link reaching from the Internet to the internal network VPN server. www.syngress.com


193

Figure 3.66 Public Address DMZ with VPN Tunnel Direct to the Internal ISA Server Private Address DMZ with VPN Tunnel to Internal Network

Public Address DMZ 222.222.222.0/24 Packet Filters for: PPTP Receive IKE L2TP allow VPN protocols to be routed through the external ISA Server to the internal ISA Server Private Network 10.0.0.0/8

The advantages of using a public address DMZ is that you can route packets through the ISA server into the DMZ (and to the internal ISA server if you want).The packets are unchanged, the headers are unmolested, and complex protocols can pass through almost as easily as simple protocols. All you need to do is create packet filters. ISA Server acts as a simple packet filtering router with this design. The celebrity challenge is to get the ISA server to route packets when there is no LAT segment. If you’ve ever tried to install ISA Server without a LAT interface, the setup routine will complain loudly! You must designate a LAT segment during setup, and that LAT segment must include one of the interfaces on the ISA server.You can trick it or cheat by calling out a false address range. However, if you have a dual-homed server and denote one interface as a LAT segment member, then you have a single internal and a single external interface. ISA Server will never route from an external interface to an internal interface. Packets moving from the external interface to a LAT segment will always be translated (a form for routing, but not “pure” routing).The only way you can route packets from the external interface to another interface is to have at least a trihomed server. One interface must be external, at least one must be internal (on the LAT), and at least one

www.syngress.com

194


must be on a DMZ segment.With just three interfaces, you have the classic “trihomed” DMZ configuration. However, we don’t want a trihomed DMZ! We just want two interfaces and route through from the external interface to the public address DMZ interface.You can do this, but you’ll have to trick the ISA server into thinking it has three interfaces, and that one of the interfaces is on the LAT.

ISA SERVER ALERT Note that while the external interface and the DMZ interfaces are public interfaces and are located on public address network IDs, they cannot be on the same network ID. The DMZ network ID must be different from the external interface network ID. How you assign the network IDs is specific to your configuration, but usually you’ll have a router in front of the external ISA server that has a WAN and a LAN interface. The WAN interface is assigned by the ISP. The ISP assigns you a block of IP addresses that you can subnet and assign to the segment in front of the external ISA server and the DMZ segment. Keep in mind that the more subnets you create, the more host IDs you’ll lose due to the subnetting.

This trick is accomplished by using the Microsoft Loopback Adapter.The loopback adapter looks like a physical adapter to the operating system and to ISA Server.You assign a private IP address to the loopback adapter, and then when you install ISA Server, you configure the LAT for the network ID to which you assigned the loopback adapter. Do the following to install the loopback adapter: 1. Perform this procedure while logged on as a local admin and before you install ISA Server. 2. Open the Control Panel and double-click on the Add/Remove Hardware icon. 3. Click Next on the Welcome to the Add/Remove Hardware Wizard page. 4. Select the Add/Troubleshoot a device option, and click Next. 5. Choose the Add a new device option on the Choose a Hardware Device page, and click Next. 6. Choose the No, I want to select the hardware from a list option on the Find New Hardware page, and click Next. 7. Choose the Network Adapters option on the Hardware Type page, and click Next. www.syngress.com


195

8. On the Select Network Adapter page, select Microsoft from the list of Manufacturers. Click on the Microsoft Loopback Adapter in the right pane of the page. Click Next. 9. The wizard will install the device. Click Finish when the wizard completes. 10. Go into the Properties dialog box of the new interface and configure the interface with a private IP address. In fact, you don’t even have to use a private IP address; you can subnet your block to allow for a pubic address to be assigned to your dummy interface, but there’s no reason to waste good public addresses on a dummy interface. 11. Install ISA Server and configure the LAT to use the loopback adapter interface’s network ID as the LAT segment. At this point, you have a trihomed DMZ configuration.You configure packet filters to allow traffic through the DMZ the same way you do with the trihomed, as we discussed in the last chapter.You can put servers on the DMZ, or you can forward all traffic to the external interface of the internal ISA server.

Outbound Access for Internal Network Clients through a Public Address DMZ While you should take advantage of ISA Server’s packet-filtering capabilities and limit new inbound connections to only the traffic you want to let through, things are a bit different for outbound access.Your primary means of controlling outbound access from the internal network is by creating protocol and site and content rules on the internal ISA server.You configure the rules you need to control what internal users can access on the Internet or any other external network (including the public address DMZ segment). However, for outbound access through the external ISA server, you will have to use packet filters rather than protocol and site and content rules.The reason for this is that protocol and site and content rules apply only to hosts included in a LAT segment. Because the public addresses in the DMZ are not included in the external ISA server’s LAT, protocol and site and content rules can not be applied to the traffic traversing the DMZ and to the external ISA server. There are a couple of approaches you can take when configuring the outbound access packet filters on the external ISA server: ■

Create packet filters to allow all ICMP,TCP, UDP, and IP protocol traffic outbound access through the external ISA server

■

Create packet filters for only the protocols you want to have outbound access through the external ISA server

www.syngress.com

196


Allowing all outbound traffic through is your best bet when it comes to ease of use; you only need to configure four packet filters. Keep in mind that this provides you with no outbound access control at the external ISA server. Actually, the situation isn’t that dire, as you can configure the packet filters to apply only to the external IP address of the internal ISA server.This prevents these “all open” packet filters from being used by servers located on the DMZ segment. If you want to tighten up outbound access control on the external ISA server, you can create specific packet filters for only the protocols you want to allow outbound. For example, suppose you have protocol rules on the internal ISA server that allow outbound access for only HTTP and SMTP.You would create two packet filters on the external ISA server that look like Figures 3.67 and Figure 3.68. Figure 3.67 An Outbound SMTP Packet Filter

Table 3.11 lists the outbound SMTP packet filter’s characteristics. Table 3.11 Outbound SMTP Packet Filter Setting

Value

IP protocol Direction Local port Remote port Remote port number Local computer: this computer (on the perimeter network) Remote computer

TCP Outbound Dynamic Fixed port 25 External IP address of the internal ISA server

www.syngress.com

All remote computers


197

Figure 3.68 An Outbound SMTP Packet Filter

Table 3.12 lists the outbound HTTP packet filter’s characteristics. Table 3.12 The Outbound HTTP Packet Filter Setting

Value

IP protocol Direction Local port Remote port Remote port number Local computer: this computer (on the perimeter network) Remote computer

TCP Outbound Dynamic Fixed port 80 External IP address of the internal ISA server All remote computers

Note that in this example, we set the local computer on the perimeter network to be the external interface of the internal ISA server.This gives outbound access to the internal ISA server, but does not confer any outbound access capabilities to any other host you might place on the public address DMZ segment. If you wanted to create packet filters allowing outbound access for almost all Internet protocols, you would create five packet filters.Tables 3.13 through 3.17 list the five packet filters’ characteristics.

www.syngress.com

198


Table 3.13 The “All Open” IP Protocol Filter Setting

Value

IP protocol Direction Local computer: this computer (on the perimeter network) Remote computer

Any Both External IP address of the internal ISA server All remote computers

NOTE “All IP Protocols” appears to cover all protocols except ICMP, TCP, and UDP.

Table 3.14 All TCP Protocols Outbound Setting

Value

IP protocol Direction Local port Remote port Local computer: this computer (on the perimeter network) Remote computer

TCP Outbound All ports All ports External IP address of the internal ISA server All Remote Computers

NOTE TCP is a connection-oriented protocol; therefore, a packet filter is opened dynamically to allow the external server to respond to the client making the request. In our public address DMZ, the client making the request is the external interface of the internal ISA server.

Table 3.15 All UDP Protocols Outbound Setting

Value

IP protocol Direction

UDP Send/receive Continued

www.syngress.com


199

Table 3.15 All UDP Protocols Outbound Setting

Value

Local port Remote port Local computer: this computer (on the perimeter network) Remote computer

All ports All ports External IP address of the internal ISA server All remote computers

NOTE UDP is not a connection-oriented protocol; therefore, you must choose send/ receive rather than outbound. The internal ISA server is allowed to send a message, and the UDP server is allowed to send a response, but no session is established between the UDP client and server.

Table 3.16 All ICMP Protocols in Both Directions Setting

Value

IP protocol Direction Type Code Local computer: this computer (on the perimeter network) Remote computer

ICMP Both All types All codes External IP address of the internal ISA server All remote computers

NOTE You must allow ICMP in both directions, since the ICMP responses represent new inbound connections. For example, when you ping an external host, you send an ICMP Echo Request message. The machine that sends the response to the Echo Request sends back an ICMP Echo Response message, and this Echo Response represents a new inbound connection. Creating an All Types/Code outbound ICMP packet filter would not allow the Echo Response to reach the internal ISA server.

www.syngress.com

200


Table 3.17 PPTP Call Setting

Value

Predefined Direction Protocol number Code Local computer: this computer (on the perimeter network) Remote computer

PPTP Call Preset (both) Preset (47) All codes External IP address of the internal ISA server All remote computers

NOTE The PPTP Call packet filter is all you need to allow outbound VPN connections from your internal network, through the public address DMZ, and onto the Internet. There are no L2TP/IPSec filters to configure, since IPSec will not pass through the ISA server’s IPNAT service. There’s a lot hidden behind the scenes in this filter, because it hooks into an application filter that allows TCP 1723 as well. That’s why you do not need to create a separate packet filter for this.

While these packet filters support a great number of well-designed Internet protocols, they don’t support all protocols.There are protocols requiring the external server to make new inbound connections to the internal ISA server in response to an initial request made by a client behind the Internet ISA server. The best example of this is FTP. Are you saw in the trihomed DMZ chapter, FTP requires packet filters for both outbound and inbound access.The inbound access packet filters require that you open the entire range of high-number ports inbound. If you want to support PASV mode FTP, you have to open the entire range of ephemeral ports both inbound and outbound. Other complex protocols, such as RPC, have similar requirements. These examples of complex protocols demonstrate the weaknesses of traditional packet-filtering routers. If you do need to support new inbound requests for port ranges, you can use the all ports or dynamic ports entries in the packet filter configuration dialog box. Although the dynamic ports entry should represent 1024–5000, it doesn’t appear to work that way.The dynamic ports setting opens all ephemeral port numbers.

www.syngress.com


201

ISA SERVER DEFCON 1 If you don’t want to fool with packet filters getting in the way of inbound or outbound access, you can use the packet filter rules described for outbound access, but change the direction for TCP communication to “both.” For UDP communications, you’ll need to add another packet filter to support “Receive/ Send” and another for “Both.” To allow inbound access to PPTP, add a packet filter for “PPTP Receive.”

Inbound VPN Access through the Public Address DMZ One of the main reasons you want to implement a public address DMZ is to allow VPN connections directly to the internal ISA server.This allows you to get around the VPN passthrough situations you saw earlier.The direct connection with the internal ISA server also provides better performance because you’re not interacting with two computers that bear the encryption overhead required by VPN encryption protocols.

ISA SERVER ALERT Do not try to pass VPN protocols through an ISA Server packet-filtering router unless you have ISA Server Service Pack 1 installed. There were problems with the ISA Server packet filters pre-Service Pack 1, which prevented you from allowing inbound VPN protocols through the ISA Server packet filters.

Allowing Inbound PPTP Connections There are two things you need to do to allow inbound PPTP connections through the ISA servers: 1. Enable a PPTP Receive packet filter on the external ISA server. 2. Enable the VPN server on the internal ISA server. The PPTP Receive packet filter is interesting because when you look at the details of the packet filter, all it shows is access to IP protocol 47 in both directions.This packet filter doesn’t seem to be enough to allow PPTP through the ISA server, as you also need to allow TCP port 1723 through the external ISA server. So, what happened to the TCP port 1723 packet filter? It must be integrated into the PPTP Receive packet filter.There’s no documentation on this issue, but it’s clear that you only need to www.syngress.com

202


use the built-in PPTP Receive packet filter to allow inbound PPTP connections to your internal ISA server.

Allowing Inbound L2TP/IPSec Connections There are three packet filters you need to allow L2TP/IPSec connections inbound through the external ISA server: ■

A packet filter to allow inbound Encapsulating Security Payload (ESP) protocol packets

■

A packet filter to allow inbound Internet Key Exchange (IKE) protocol packets

■

A packet filter to allow Layer 2 Tunneling Protocol packets

Figures 3.69 through 3.71 show the Filter Settings page of the New IP Packet Filter Wizard for each of these packet filters required for inbound L2TP/IPSec VPN links to the internal network through the external ISA server. Figure 3.69 Packet Filter to Support Passing ESP Communications

Figure 3.70 Packet Filter to Support Passing IKE Communications

www.syngress.com


203

Figure 3.71 Packet Filter to Pass L2TP Tunnel Control Messages

Publishing Servers on the Private Address DMZ on the External ISA Server If you follow what’s happening on www.isaserver.org, you’ve encountered discussions where people say they want to put together a public address DMZ.They often receive a mild level of criticism for wanting to do so.The comments are usually that ISA Server costs too much money to use it just as a packet filtering router.You can use the RRAS packet filters if you want a packet-filtering router, or just use a router you probably already have on your network. As you learned in the previous discussion, there are valid reasons for wanting to use a public address DMZ.The question remains whether it’s worthwhile to use ISA Server as the front end firewall in a back-to-back public address DMZ configuration.We propose that there are good reasons to use ISA Server at the external firewall in a back-toback ISA Server configuration. For example, look at Figure 3.72. In this example, you can use ISA Server Web publishing and server publishing rules to make public servers available to Internet hosts.This is an ideal DMZ configuration. First, you’re able to take advantage of Web and server publishing rules to publish your public servers. Second, you keep the DMZ completely segregated from the internal network. Finally, you can manage the servers in the private address DMZ segment attached to the external ISA server using terminal services. Web publishing rules will allow you to use destination sets to publish multiple servers using a single IP address on the external interface of the ISA server .You can perform URL inspection and redirect requests from TCP port 80 to any TCP port you like when publishing Web and FTP servers using Web publishing rules on the private address DMZ connected to the external ISA server. Server publishing rules can be used

www.syngress.com

204


to publish any other protocol, and the servers published with server publishing rules are protected with the help of ISA Server’s smart application filters. Figure 3.72 Private Address DMZ Connected to the External ISA Server Private Address DMZ and Public Address DMZ Connected to External ISA Server

Public Address DMZ 222.222.222.0/24

Private Address DMZ 192.168.1.0/24

Mail

Private Network 10.0.0.0/8

Web/FTP

Combined public and private DMZ on external ISA Server allows routed VPN connections to internal ISA Server and creates secure private address DMZ

ISA SERVER ALERT In order to use Terminal Services in this configuration, you need to publish a Terminal server on the private address DMZ. If you need to access multiple Terminal servers on the DMZ, you will need to bind multiple IP address to the external interface of the external ISA server, or publish a single Terminal server and access the other Terminal servers inside a Terminal Services session on one server on the DMZ.

www.syngress.com


205

Summary In this chapter, we went over the configuration of back-to-back DMZ segments.The back-to-back DMZ provides a high level of protection for internal network hosts, and allows you to put your public servers on a DMZ segment that’s completely under your administrative control. Back-to-back DMZs provide an extra level of fault tolerance for your network security. If the external ISA server is ever compromised, you’re still protected by the internal ISA server. In this chapter, we discussed how to use ISA Server for both the internal and external firewall.The best solution is to use a third-party firewall as the external firewall and use ISA Server as the internal firewall. Review your rationale for creating a DMZ. Keep in mind that the purpose of the a DMZ is to create a separate and distinct security zone that is completely segregated from the internal network.This segregation allows you to keep the internal network secure even in the event of compromise in the DMZ. Remember that all machines in the DMZ are bastion hosts, and all bastion hosts will be compromised.Therefore, design your server configurations and security plans around this fact.You can significantly reduce the probability of DMZ server compromise by using a private address DMZ and by using an external firewall that can perform application layer filtering.We went over the particular configuration issues that arise when configuring both public address and private address DMZs.

Defensive Tactics Fast Track Configuring a Private Address Back-to-Back DMZ ; The private address DMZ is the most secure back-to-back DMZ

configuration. ; The private address DMZ allows you to use Web and server publishing rules

to make servers on the DMZ and on the internal network available to external network clients. ; The private address DMZ creates challenges when you need to connect to the

internal network via VPN; you will need to use VPN passthrough to access the internal network through the two ISA servers. ; Outbound access for internal network clients is controlled primarily by using

protocol and site and content rules on the internal ISA server. ; Limited outbound access controls can be exerted on the external ISA server.

www.syngress.com

206


; The optimal outbound access configuration is when the downstream ISA server

is configured as both a Web Proxy client and Firewall client of the upstream ISA server.This is accomplished using Firewall and Web Proxy chaining. ; Inbound access to DMZ and internal network servers is done using Web and

server publishing rules. Internal network servers must be published using two publishing rules; once on the external ISA server and again on the internal ISA server.

Configuring a Public Address Back-to-Back DMZ ; Public address DMZs use packet filtering to control inbound and outbound

access through the external ISA server. ; Packet filters allow a much lower level of access control compared to public

address DMZs. ; Public address DMZs can solve problems with complex protocols that do not

work well behind dual network address translators, such as FTP and H.323. ; Inbound VPN connections to the internal network are simplified with public

address DMZs.You do not need to create a VPN tunnel inside a tunnel (VPN passthrough). ; Public address DMZ servers do not need to be published. All you need to do

is create a packet filter to allow inbound access to the required server port. ; The public DNS entries for servers on the DMZ use the actual IP address of

the server. Since the servers on the DMZ use public addresses, you do not need to use the public IP address on the external interface of the ISA server for the name mappings.

www.syngress.com


207


Q: Why go through the problem of creating a back-to-back DMZ? Can’t I just put a single ISA server in front of my internal network and have it protect all of my resources?

A: A back-to-back DMZ gives you an extra layer of protection, as an Internet criminal would potentially have to break the security of the external and internal firewalls to get to information on your internal network.This should not be interpreted as an indictment of ISA Server firewall security.The DMZ segment allows you to create a completely separate security zone and place publicly accessible servers on that separate security zone. It’s the security conferred by creating the separate security zone that makes the DMZ most attractive. One of the most common mistakes administrators make when creating DMZs is to extend their security zone into the DMZ. If these administrators need to extend their security zones into the DMZ, then they don’t need a DMZ; they can bring those resources into the internal network.

Q: Is there any difference in level of security conferred by a private address and a public address DMZ?

A: Definitely.The private address DMZ is much more secure because you can leverage all of the features provided by both the Web Proxy and Firewall services. Outbound access is controlled using protocols rules and site and content rules, and inbound access is controlled using publishing rules. In the public address DMZ, the only access controls you have are packet filters. Packet filters have much less flexibility and security than protocol and site and content rules.The primary advantage of the public address DMZ is that you can get some complex protocols to work, such as H.323, PORT mode FTP, and RPC through the DMZ segment and to the internal ISA server and internal network.

Q: Are there special name resolution requirements for DMZ segments? A: External network clients and internal network clients access DMZ segment hosts differently. If you’re using a private address DMZ, external network clients access DMZ

www.syngress.com

208


hosts via the external IP address of the external ISA server publishing the resources on the private address DMZ. On the other hand, if you have a public address DMZ, external network clients access the DMZ hosts directly, since the external ISA server is routing the requests directly to the DMZ host.When an internal network client accesses a private address DMZ host, the internal network clients uses the private IP address of that host on the DMZ segment; the internal network client should never try to access the private address DMZ host by “looping back” through the external interface of the external ISA server. If you have a public address DMZ segment, the internal network client will access the DMZ host in the same way as the external network client: via the public IP address of the DMZ host. For public address DMZ segments, internal and external clients can use the same DNS servers to access the resources on the public access DMZ segment. If you use a private address DMZ segment, you will need to create a “split DNS”; one DNS zone for use by external network clients, and one for use by internal network clients.The external DNS zone is used by the external network clients to resolve addresses for private address DMZ hosts to the IP address on the external ISA server publishing the server.The internal DNS zone is used by internal network clients to resolve the names of private address DMZ hosts to the private IP address the host has on the private network.

Q: I want to put a front-end Exchange server on my DMZ and allow my users to access the back-end Exchange server via Outlook Web Access. Is this a good idea?

A: This is a horrible idea if you’re using a public address DMZ, because doing so will extend your internal network security zone into the Internet. Although there are simple ISA Server packet filters configured on the external ISA server, this does not provide adequate protection against attacks on your OWA server in a public address DMZ.You should also avoid putting the OWA server on the private address DMZ segment, because the primary purpose of the DMZ is to provide a separate security zone. If you extend your internal network security zones into the DMZ, you break much of the security provided by the DMZ. In that case, you’re much better off putting the front-end server on the internal network on a dedicated “public access” network.You can then using RRAS packet filters, router packet filters, or IPSec policies to control what packets move from the “public access” network and the “official” internal network. Note that all internal networks, including the “public access” network, are included in the LAT.

Q: My ISA server is a member of a Windows NT 4.0 domain. I have a PDC on the internal network and BDCs on the external network. How can I get the DCs to communicate with one another? www.syngress.com


209

A: The first thing we would consider is why you want to configure such a relationship. Is the external DC really on a DMZ segment? Is the external DC really on an external network? If so, you should consider moving the PDC into an internal network.You put your entire network at risk by putting a DC on a nontrusted segment. If your situation is that you have a campus LAN and several departmental LANs, that is a different situation. In the case of the campus LAN, the untrusted network is the backbone that connects the LANs.The departmental LANs are trusted since hosts on those LANs belong to the same domain.To solve this problem, create VPN gateway connections between the ISA servers at the edge of each departmental LAN segment.This way, you don’t have to worry about creating packet filters and publishing rules that will ruin your internal network security by violating your internal network’s security zone(s).

Q: How do I manage the machines in the DMZ? Can I use MMC consoles, or do I have to use Terminal Services?

A: Theoretically, you can use MMC consoles, but we’ve never figured out a way to do this.The MMC depends on RPCs, and there are some issues with outbound access for RPC.The best solution is to use Terminal Services to manage hosts on the DMZ segment. Make sure you configure the connection for high encryption, rename the administrator account, and use a long, complex password for the Administrator account.

www.syngress.com

This Page Intentionally Left Blank

Chapter 4

Defense Plan 3: The Internal “Pseudo” DMZ


Using TCP/IP Filtering (TCP/IP Security)

■

Using Routing and Remote Access Service (RRAS) Packet Filters

■

Using IPSec Policies


211

212

Chapter 4 • Defense Plan 3: The Internal “Pseudo” DMZ

Introduction In the last two chapters, we went over how you create DMZ segments using untrusted networks. In the trihomed DMZ configuration, the untrusted segment is a public address segment directly connected to the ISA server and is a subnet of your public address block. In the back-to-back DMZ configuration, you had the choice of using public or private addresses. In all cases, the DMZ segment was an untrusted network segment. Untrusted network segments are not in the LAT. Many organizations have only a small number of public IP addresses at their disposal. Creating a public address DMZ is out of the question for these organizations because they need to use their few public IP addresses to support Web and server publishing rules. Even if you have a large number of IP addresses at your disposal, you might not want to get another Windows 2000 or Windows .Net Server and a second copy of ISA Server to create either the public or private address back-to-back DMZ configuration. There is a way for you to create what could be considered a “pseudo-DMZ” out of a trusted network segment. The trusted internal network segment is contained in the LAT.You can install multiple internal interfaces on the ISA Server computer. Unlike the single external interface limitation that ISA Server has, there is no limit to internal or DMZ interfaces. You can place two or more network adapters on the ISA server that are dedicated to LAT network segments (Figure 4.1). Normally, ISA Server will route packets between these two network segments when IP routing is enabled on the ISA server via the IP Packet Filters Properties dialog box (Figure 4.2).The problem with this configuration is that ISA Server will route all packets between LAT segments. ISA Server sees all LAT segments as trusted network segments and therefore does expose these packets to ISA Server access policies. This is acceptable when all LAT segments are trusted, but it doesn’t work if you want to create a DMZ out of a LAT segment.Why would you want to do so? The primary reason is that you don’t have enough public IP addresses to create a trihomed DMZ. Another reason would be that you want to take advantage of Web and server publishing rules, like you can with a private address back-to-back DMZ, but you can’t afford to implement a second ISA server. If you find yourself in this situation, you need to create a LAT-based DMZ. It’s vital that you control what traffics moves between the LAT-based DMZ (LATDMZ) and other LAT networks. If you can accomplish that goal, you can have the same security with a LATDMZ as you would with any other type of DMZ segment.

www.syngress.com

Defense Plan 3: The Internal “Pseudo” DMZ • Chapter 4

213

Figure 4.1 LAT-Based DMZ Segment Internet

Internal Network 10.0.0.0/24

LAT DMZ 172.16.0.0/16 NNTP

Mail Web

Figure 4.2 The IP Packet Filters Properties Dialog Box

There are three techniques that you can use to create the LATDMZ segment: ■

TCP/IP Security (TCP/IP filtering)

■

Routing and Remote Access (RRAS) packet filters

■

IPSec policies www.syngress.com

214


TCP/IP Security is the simplest method but has limited utility; RRAS packet filters are less simple but more powerful and flexible than TCP/IP Security filters; and IPSec policies can become quite complicated but provide a great deal of flexibility and customization.With increasing complexity comes greater flexibility.You’ll do yourself a favor by learning about each technique and then implementing the one(s) that best suit(s) your needs.

ISA SERVER ALERT As we go through the techniques you use to create and support a LATDMZ segment, it’s important to consider the primary purpose of a DMZ segment, which is to segregate your security zones. The practical application of this principle means that you do not want any hosts on your DMZ segment to have any dependencies on security principles on the internal network (for example, the Active Directory). DMZ hosts must be considered bastion hosts, and as bastion hosts, they have a relatively high probability of being compromised. If you are compelled to extend your internal network’s security zone into the DMZ, move the server that is dependent on the internal network’s directory services out of the DMZ and into the internal network. Configuration will be more straightforward, and you lessen the risk of other hosts on the DMZ becoming potential launch points for an internal network attack.

Using TCP/IP Filtering (TCP/IP Security) TCP/IP filtering is a simple filtering method that you can use to control inbound access to servers on the LATDMZ segment.You can use TCP/IP filtering to control which TCP, UDP, or IP protocols have inbound access to the servers on the DMZ segment. TCP/IP filtering does not provide a way for you to control outbound access from the servers on the LATDMZ, nor does it provide a way for you to allow some clients inbound access to the LATDMZ host.TCP/IP filtering does not allow you to control outbound access from a LATDMZ host to an internal network client. It might seem that TCP/IP filters wouldn’t be of much use on a LATDMZ host. After all, you’re using Web or server publishing rules to control inbound access to the hosts on the LATDMZ, so there should be no reason for this type of additional security.You would expect that the only Internet traffic that can reach the LATDMZ hosts is traffic that you explicitly allow using Web and server publishing rules . While Web and server publishing rules allow you to control the traffic coming from the Internet, it’s still possible that one of the servers on the DMZ could be compromised either by an Internet-based host or someone who was able to connect to the

www.syngress.com


215

LATDMZ from the internal network or from another location (such as a network management segment or other “out of band” connection).TCP/IP filters give you added protection. Another advantage of TCP/IP filtering is that it controls inbound access to LATDMZ hosts using a kernel-mode process. Unlike the RRAS packet filters and IPSec policies that we’ll cover later in this chapter,TCP/IP filtering does not depend on user-mode processes or the Workstation/Server services. Security on user-mode services can be interrupted by various exploits such as buffer overruns that leave the server running and thus accessible to the intruder; cracking kernel-mode security processes is more complicated, and typically would end up “blue screening” the server.While this causes a denial of service (DoS) situation on the compromised host, it doesn’t allow the intruder to use the compromised server as a fulcrum for a subsequent attack against the internal network. TCP/IP filtering on a LATDMZ host provides a great layered security configuration when coupled with either or both RRAS packet filters and IPSec policies. However, there are some limitations to TCP/IP filtering of which you should be aware: ■

You cannot filter ICMP traffic with TCP/IP filtering.

■

You cannot filter outbound traffic using TCP/IP filtering.

■

You cannot configure selective access to particular computers/subnets using TCP/IP filtering; the filter applies to all inbound traffic equally.

■

You cannot block all UDP or TCP protocols by blocking IP protocols 6 and 17; you can block all UDP and/or TCP protocols by using an exception list.

With these limitations in mind, let’s look at how to configure TCP/IP Filtering.

Configuring TCP/IP Filtering Perform the following steps to configure TCP/IP filtering: 1. Open the Control Panel and then open the Network and Dial-up Connections applet (Figure 4.3). 2. Right-click on the interface you need inbound access control and click Properties. 3. Select the Internet Protocol (TCP/IP) and click Properties (Figure 4.4). 4. Click Advanced in the Internet Protocol (TCP/IP) Properties dialog box (Figure 4.5). 5. Click the Options tab in the Advanced TCP/IP Settings dialog box.

www.syngress.com

216


Figure 4.3 The Network and Dial-Up Connections Window

Figure 4.4 The Local Area Connections Dialog Box

Figure 4.5 The Internet Protocol (TCP/IP) Properties Dialog Box

www.syngress.com


217

6. Click the TCP/IP filtering entry and click Properties (Figure 4.6). Figure 4.6 The Advanced TCP/IP Settings Dialog Box

7. Place a check mark in the Enable TCP/IP Filtering (All adapters) check box. Note that doing so enables filtering for all adapters, but you configure the filters on a per-adapter basis.The same filters do not apply to all adapters (Figure 4.7). Figure 4.7 The TCP/IP Filtering Dialog Box

8. There are three columns: TCP Ports, UDP Ports, and IP Protocols. For each, you have two choices: Permit All and Permit Only. If you want to permit all packets for TCP or UDP traffic, then leave the Permit All option selected. If you want to allow selected TCP or UDP traffic, select the Permit Only option, click Add, and enter the appropriate port in the Add Filter

www.syngress.com

218


dialog box. In Figure 4.8, we allow only TCP ports 25 and 80 (SMTP and HTTP) and GRE (Generic Routing Encapsulation for PPTP–IP Protocol 47) inbound. All other inbound packets (except ICMP) will be dropped. Figure 4.8 Configuring Ports in the TCP/IP Filtering Dialog Box

9. If you want to block all UDP or all TCP traffic, select the Permit Only option and do not enter any port numbers in the UDP Ports or TCP Port column.You cannot block all UDP or all TCP traffic by selecting the IP Protocols Permit Only option and exclude IP Protocol 6 (TCP) and IP Protocol 17 (UDP). In Figure 4.9, we allow only inbound GRE. All other inbound packets are dropped except for ICMP. Note that if you wanted to allow inbound PPTP connection, this filter wouldn’t be enough; you would have to add a filter to allow TCP 1723. Figure 4.9 Permitting Only GRE Packets Inbound

10. You cannot block ICMP messages.This is true even if you select the IP Protocols column and select Permit Only and fail to include IP Protocol 1.

www.syngress.com


219

Internet Protocol Number assignments are listed in Microsoft Knowledge Base article Q289892.You can find a long list of TCP and UDP port number assignments at www.iana.org/assignments/port-numbers.

Summary of TCP/IP Filtering TCP/IP filtering is a good first step in protecting your servers in the DMZ from external network hosts, other hosts on the LATDMZ, and hosts on the internal network. As useful as TCP/IP filtering might be, it’s only a piece of your LATDMZ defense plan.You need to add RRAS packet filters and/or IPSec policies to make your LATDMZ a true DMZ segment.

Using Routing and Remote Access Service (RRAS) Packet Filters The Routing and Remote Access Service (RRAS) is part of every Windows 2000 and Windows .NET Server installation. RRAS is part of the default installation and there is no method to exclude it during setup. Although the service is installed, it is not enabled. You don’t have to run RRAS on the ISA Server machine. ISA Server can protect your DMZs and LAT segments without RRAS enabled.You can even route packets between LAT segments directly connected to the ISA server without RRAS enabled; just enable IP Routing in the IP Packet Filters Properties dialog box (Figure 4.10). Figure 4.10 The IP Packet Filters Properties Dialog Box

www.syngress.com

220


The problem with the built-in IP routing between LAT segments directly connected to the ISA server is that you can’t control traffic moving between the segments. Although ISA Server controls traffic moving between the external interface and the LAT segments, it trusts all traffic moving between the LAT segments and lets it pass uninspected. That’s fine for non-DMZ situations, but in our LATDMZ scenario, we need total control over what is sent from the LATDMZ segment to the internal network.We would also like to control traffic moving from the internal network to the DMZ segment. The good news is that you can exercise a great deal of control over what packets move between the LATDMZ segment and the internal network using RRAS packet filters.We can use ISA Server site and content and protocol rules to control outbound access to the Internet from DMZ hosts, but we need to use another method to control what happens between the LATDMZ and internal network segments. RRAS packet filtering is one of those methods. You have to start RRAS before you can use RRAS packet filters.You’ll likely find yourself in one of the following three scenarios: ■

RRAS was enabled before you installed ISA Server.

■

ISA Server is installed, and you haven’t started RRAS yet.

■

You enabled RRAS when you ran one of the ISA Server VPN wizards.

If RRAS was enabled before you installed ISA Server, you’ve already had to deal with the service dependency problems that crop up when you don’t let the ISA server enable RRAS. Hopefully you’ve resolved the problem, but if not, here’s the fix: 1. You need to make the Routing and Remote Access Service dependent on the ISA Server Control Service (isactrl).To do this, you must edit the Registry. 2. Open the Run command from the Start menu. In the Open text box, type regedt32 and click OK. 3. Navigate to the following key: HKLM\System\CurrentControlSet\Services\RemoteAccess

4. Double-click on the DependOnService value and add the isactrl string in the Multi-String Editor (Figure 4.11). Run this fix whenever you start RRAS independently of the ISA Server VPN wizards.You might find that the ISA Server services won’t start up properly or automatically if you don’t let ISA Server start RRAS.

www.syngress.com


221

Figure 4.11 The Multi-String Editor

You’re in good shape if you haven’t started RRAS and ISA Server is installed.We recommend that you let the ISA Server VPN wizards start RRAS.You don’t have to allow VPN connections. If you want to block incoming VPN connections, all you need to do is disable the VPN protocol packet filters that the VPN wizard creates to allow VPN connections into the network. Perform the following steps to let the ISA server enable RRAS for you: 1. In the ISA Management Console, expand your server name and then rightclick on the Network Configuration node. Click on the Allow VPN Connections command. 2. Click Next on the Welcome to the ISA Virtual Private Network Configuration Wizard page. 3. Click Finish on the Completing the ISA VPN Server Configuration Wizard page. 4. A dialog box will appear and ask if you want to start RRAS. Click Yes. After RRAS is started, go to the ISA Server Management console and you’ll see the following packet filters in the IP Packet Filters node: ■

Allow L2TP protocol IKE packets

■

Allow L2TP protocol packets

■

Allow PPTP protocol packets (client)

■

Allow PPTP protocol packets (server)

If you don’t want the ISA server to act as a VPN server, right-click on each of these packet filters and click Disable.

Configuring RRAS Packet Filters RRAS packet filters allow you to control traffic arriving and leaving a particular interface on the RRAS computer. In the case of the LAT-based DMZ, we are concerned

www.syngress.com

222


with controlling packets moving between the LATDMZ segment and the internal network.The ISA Server software will control what moves between the LAT segments and the Internet. You should rename the network interfaces before working with RRAS packet filters. Doing so will make it easier to identify which interface is the LATDMZ interface, the internal network interface, and the external network interface. Perform the following steps to change the names of the adapters: 1. Open the Network and Dial Up Connections window.This window contains all the network interfaces installed on your computer. 2. Right-click on the LATDMZ interface and click the Rename command. Type in the name LATDMZ and press Enter. 3. Right-click on the internal interface and click the Rename command.Type in the name LAN and press Enter. Do not name the internal interface INTERNAL.That name is already assigned to the virtual interface that the RRAS server uses for VPN connections. 4. Right-click the external interface and click the Rename command.Type in the name EXTERNAL.You should see what appears in Figure 4.12. Figure 4.12 Renaming the ISA Server Interfaces

5. Now open the Routing and Remote Access console from the Administrative Tools menu. Expand your server name and then expand the IP Routing node in the left pane of the Routing and Remote Access console. Click on the General node and you should see something like what appears in Figure 4.13.

www.syngress.com


223

Figure 4.13 The Routing and Remote Access Console

6. In the right pane you’ll see the names you assigned to the interfaces. Doubleclick on your LATDMZ interface and you’ll see what appears in Figure 4.14. Figure 4.14 The LATDMZ Interface Properties Dialog Box

www.syngress.com

224


How RRAS Packet Filters Work with a LATDMZ Segment RRAS packet filters work on an “exception” basis.You can allow all packets except for those for which you create a filter, or you can deny packets except for those for which you create an exception.This exception-based access control makes inbound and outbound access control to and from the LATDMZ segment challenging. For example, suppose you want to prevent any packets from moving from a host on the DMZ segment to any host on the internal network.The goal is to prevent traffic sourcing on the LATDMZ from reaching the internal network. In this example, our LATDMZ segment is on network ID 172.16.0.0/24.The internal network is on network ID 10.0.0.0/24. Follow these steps to prevent all traffic originating on the DMZ segment from entering the internal network: 1. In the Routing and Remote Access console, expand the server name, and then expand the IP Routing node in the left pane of the console. Click on the General node and then double-click on the LATDMZ interface in the right pane of the console. 2. In the LATDMZ Properties dialog box, click Input Filters. 3. In the Input Filters dialog box, click Add. 4. In the Edit IP Filter dialog box, put check marks in both the Source network and Destination network check boxes. In the IP address text box for the Source network, put in the network ID for the LATDMZ segment in the IP address text box, and put the subnet mask for the LATDMZ segment in the Subnet mask text box (Figure 4.15). In the IP address text box for the Destination network, put in the network ID that summarizes the internal network, and put in the subnet mask for that network ID in the Subnet mask text box. In the Protocol drop-down list box, select Any. Doing so applies the filter to all protocols. Click OK. 5. In the Input Filters dialog box (Figure 4.16), make sure that the Receive all packets except those that meet the criteria below option is selected. The input filter applies to all packets arriving to the interface.This filter allows all packets to be accepted by the LATDMZ interface except those that match the filter you created.This filter allows all packets to move between the LATDMZ segment and the Internet, but no packets are accepted from hosts on the DMZ segment if the destination network ID in the packet is that of the internal network.This prevents any host on the DMZ segment from accessing any resource on the internal network. Click OK.

www.syngress.com


225

Figure 4.15 Configuring the RRAS Packet Filter to Prevent Access to the Internal Network

Figure 4.16 The Input Filters Dialog Box

6. Click Apply and then click OK in the LATDMZ Properties dialog box. This packet filter completely isolates the DMZ segment from the internal network, while still allowing the ISA server to move packets between the DMZ segment and the Internet.You’ll be able to create Web and server publishing rules to make servers on the LATDMZ available to Internet hosts.The only difference between the LATDMZ and the internal network is that no direct communications take place between the LATDMZ and the internal network. You’re very limited in terms of the granularity of access control obtainable using RRAS packet filters.The ideal setup would allow you to prevent outgoing connections from the LATDMZ to the internal network except for a handful of protocols you want

www.syngress.com

226


to allow. For example, you might want to allow an SMTP relay server on the LATDMZ to send SMTP messages to an SMTP server on the internal network. Why can’t you allow this type of selective traffic? Think about the packet filters needed to allow TCP port 25 traffic from the DMZ segment into the internal network while at the same time blocking all other traffic. You could create a packet filter for TCP port 25 with the source network ID being the DMZ segment’s network ID, and the destination network ID the internal network’s network ID, and use the Drop all packets except those that meet the criteria below option. However, this would prevent packets from moving between DMZ segment hosts and the Internet! You wouldn’t be able to publish any servers on the DMZ segment because the packet filter would drop all packets except the packets for TCP port 25 destined for the internal network. Let’s change this a bit. In this case, you create a packet filter for TCP port 25 with the source network ID being the LATDMZ network ID, and the destination network ID being 0.0.0.0 (which represents all network IDs).You select the Drop all packets except those that meet the criteria below option.What happens? All hosts on the DMZ segment are able to send SMTP packets to any network.That’s good, but it would completely break any server publishing rule you have for HTTP, SMTP, NNTP, and so forth because it doesn’t allow outbound access to the high-number ports that the published servers on the DMZ segment need to respond to Internet clients. What if you selected the Receive all packets except those that meet the criteria below option? In that case, the DMZ interface would allow all traffic through except TCP port 25 traffic from the DMZ to the internal network! You can see how this exception-based packet filtering creates significant constraints on controlling traffic between the DMZ segment and the internal network.

ISA SERVER DEFCON1 It is possible to achieve a certain level of granular control over traffic moving between the LATDMZ and the internal network. You need to use the allow all traffic except option and then create packet filters for services that you want to prevent from reaching the internal network. For example, some services that you would not want to allow LATDMZ hosts access to on the internal network include HTTP, IMAP4, POP3, SMTP, NNTP, LDAP to Directory Service (TCP 389), LDAP to Global Catalog Server (TCP 3268), Kerberos authentication (UDP and TCP 88), NetBIOS (137/138/139), RPC endpoint mapper (TCP 135), DNS (TCP and UDP 53), and Direct Hosting and NetLogon (TCP 445). Creating packet filters for these ports will block access to the most commonly exploited services on the internal network.

www.syngress.com


227

The situation is far from hopeless, however.There are some things that we can do to make the LAT-based DMZ have just about the same functionality and accessibility we have with the private address back-to-back DMZ.What we need to do is identify our requirements, identify the problems, and then come up with solutions.

Requirements for Our LATDMZ Segment We need to address the following issues with our LAT-based DMZ segment to achieve the same functionality as we have with a private address back-to-back DMZ configuration: ■

Prevent LATDMZ hosts from directly accessing the internal network

■

Allow Internet traffic into the LATDMZ segment

■

Allow internal network hosts access to the Internet

■

Allow internal network hosts access to LATDMZ services

■

Allow LATDMZ hosts access to the internal network

Let’s explore each of these requirements in more detail.

Prevent LATDMZ Hosts from Directly Accessing the Internal Network The entire reason for creating a DMZ segment is to separate the DMZ and internal network security zones. If you wanted unfettered communication between LATDMZ servers and the internal network, you would just put the servers on the internal network.The entire reason for implementing the DMZ is to protect the internal network in the event a published server is compromised. The RRAS packet filter we created earlier prevents DMZ hosts from directly accessing the internal network. Unfortunately, this packet filter also prevents internal network clients from directly accessing resources on the LATDMZ segment.This can be a problem because internal network clients often need to access the publicly available servers on the DMZ. For example, suppose you publish a Web server on a private address back-to-back DMZ. External network clients access the server via the public IP address used by the Incoming Web Requests listener on the external ISA server. Internal network clients access the Web server via the actual private address used by the Web server on the private address DMZ.This prevents the internal network clients from having to “loop back” through the external interface of the external ISA server. Let’s look at another example. Suppose you publish a Web server on your internal network. External network clients access the Web server using the IP address on the external interface of the ISA server that’s Web publishing the Web server. Internal network clients access the Web server directly using the Web server’s actual IP address on www.syngress.com

228


the internal network.This prevents the internal network clients from having to “loop back” through the ISA server to access a server that’s on the internal network. The problem with the LAT-based DMZ is that the RRAS packet filter prevents internal network clients from directly communicating with LAT-based DMZ hosts. We’ll have to come up with a solution if we want the internal network clients to access resources on the LAT-based DMZ.

Allow Internet Traffic into the LATDMZ Segment We need to allow Internet traffic into the LATDMZ segment, and the hosts in the LATDMZ need to be able to respond to Internet hosts generating the traffic.Web and server publishing rules accomplish this goal. Publishing rules allow inbound traffic into the LATDMZ.The ISA server automatically creates “dynamic protocol rules” allowing the LATDMZ host to reply to the requests made by Internet clients. You don’t need additional RRAS packet filters to allow or deny traffic to and from the LATDMZ segment.The packet filter we created earlier only affects communications between the LATDMZ and the internal network. It will have no effect on packets moving between the LATDMZ and the Internet.

Allow Internal Network Hosts Access to the Internet Outbound access to the Internet for internal network ISA Server clients is unaffected by the RRAS packet filter.You control outbound access to the Internet using protocol and site and content rules.These rules have no effect on how internal network clients access DMZ hosts.The ISA server sees the LAT-based DMZ as part of the internal network and therefore doesn’t intervene in communications between trusted network hosts.

Allow Internal Network Hosts Access to LATDMZ Services Here is where the problems arise. Internal network clients might need to access Web, SMTP, NNTP, FTP, and other services on the DMZ segment.With the RRAS packet filter that prevents packets sourcing from the LATDMZ from reaching the internal network, it’s impossible for the internal network clients to directly communicate with clients on the DMZ segment.The only way the internal network clients will communicate with the servers on the LATDMZ is via Web and server publishing rules. The only way internal network clients are going to access services on the LATDMZ is by “looping back” through the external interface of the ISA server. I can hear you howling! How many times have we said “Don’t loop back through the external interface of the ISA server to access resources on the internal network?” Now it appears that we’re telling you to do just that: “loop back” through the external interface of the ISA server to access resources on the internal network.

www.syngress.com


229

ISA SERVER ALERT You normally avoid looping back through the external interface of the ISA server by creating a split DNS configuration. The split DNS configuration allows internal network clients to directly access resources on the internal network. The reason why clients loop back through the external interface of the ISA server to reach publishing servers is that the DNS server used by the internal network clients has the IP address on the ISA server used to publish the server. The split DNS configuration uses two DNS zones for the same domain name. One zone is used by the internal network clients, and the second zone is used by external network clients. For more information on the split DNS configuration, check out this author’s article at www.isaserver.org/pages/article.asp?id=995.

However, we’ll plead innocent because you’re not exactly “looping back” through the external interface of the ISA server to access resources on the internal network. You’re “looping back” through the external interface of the ISA server to access resources on a LATDMZ.The LATDMZ segment is trusted by the ISA server (because it’s on the LAT), but it’s not trusted by you.You’ve enforced your lack of trust by putting RRAS packet filters in place to prevent direct communications between the internal network and the LATDMZ segment. You will run into problems with this configuration because the ISA server still sees it as an attempt to “loop back” through the external interface.The reason why we harp on the issue of not “looping back” through the external interface of the ISA server to access internal network resources is that it doesn’t work for SecureNAT clients. If you’ve ever tried to access an internal network server that you’ve published via a server publishing rule from a SecureNAT client on the internal network by looping back through the external interface of the ISA server, you’ve discovered that it won’t work. SecureNAT clients can’t loop back through the external interface of the ISA server for reasons depicted in Figure 4.17. When a SecureNAT client sends a request to the ISA server to access resources through the external IP address on the ISA server used in a server publishing rule, the ISA server forwards the request to the publishing server on the LATDMZ.The ISA server does not replace the source IP address of the request that it forwards to the publishing server; therefore, the publishing server on the LATDMZ sees the request coming from the SecureNAT client’s IP address.The publishing server responds directly to the SecureNAT client; it does not respond to the ISA server.The SecureNAT client expects to receive a reply from the ISA server, so the SecureNAT client just drops the response from the publishing server. Of course, with our RRAS packet filters that prevent LATDMZ hosts from directly connecting to internal network hosts, the reply is stopped at the level of the packet filter. www.syngress.com

230


Figure 4.17 SecureNAT Client Looping Back through the External Interface

Internet 2 ISA Server forwards requests to the published FTP server. The source address in the forwarded request is the IP address of the SecureNAT client

ISA Server

1 Internal network client makes FTP request to internal network FTP by going through the FTP Server Publishing Rule on the ISA Server

Published FTP Server SecureNAT Client

3 The FTP server responds to the SecureNAT client, since it’s IP address was the source address for the FTP request. The SecureNAT client drops the packet because it expected a response from the internal interface of the ISA Server, not from the IP address of the FTP server

As an example of what happens when you try to loop back through the external interface of the ISA server, let’s look at what happens when we try to connect to an FTP server on the LAT segment from a SecureNAT client on the internal network. We’ll open a command prompt FTP to 192.168.1.33, which is the IP address on the external interface of the ISA server being used to publish an FTP server on the LATDMZ segment.What you’ll see is that the remote host closes the connection. Figure 4.18 shows a Network Monitor trace obtained at the FTP server on the LATDMZ. Notice the source and destination addresses in the middle frame.The FTP server isn’t responding to the ISA server; it is attempting to respond directly to the SecureNAT client (CLIENTDC with IP address 10.0.0.2).The response fails because our RRAS packet filter prevents any communications between hosts on the LAT-based DMZ segment and the internal network. One way around this problem is to configure all the clients on the internal network that need to access resources on the LATDMZ to be Firewall clients. Figure 4.19 shows a Network Monitor trace taken at the FTP server of a Firewall client on the internal network connecting to the FTP server on the LATDMZ. www.syngress.com


231

Figure 4.18 Network Monitor Trace at FTP Server

Figure 4.19 Network Monitor Trace Taken at FTP Server of Firewall Client Connecting to It

www.syngress.com

232


The FTP server responds to the ISA server, not to the IP address of the Firewall client on the internal network.The Firewall service proxies the requests between the Firewall client and the FTP server on the LATDMZ. In the days of Microsoft Proxy Server 2.0, the Firewall client software was called the “WinSock Proxy” client.When the WinSock Proxy (Firewall service) proxies the requests, it changes the source port so that the server on the LATDMZ responds to the ISA server instead of to the client that made the request. What if you can’t install the Firewall client on all the computers on the internal network? Maybe you have some Mac- or UNIX-based operating systems on the internal network that need access to publishing servers on the LATDMZ. Is there anything you can do? Yes, but you’ll have to use another technique to publish servers on the DMZ segment. Instead of using server publishing rules, you’ll have to install the Firewall client on the publishing servers and create a wspcfg.ini file.This allows the publishing server to respond directly to the ISA server instead of the SecureNAT client.The Firewall service manages the connection instead of the IP NAT service. Internal network clients can access HTTP and FTP resources on the LATDMZ if you configure them as Web Proxy clients.The ISA server proxies requests to the publishing FTP server on the LAT network. An interesting finding with the Web Proxy client is you can gain HTTP and FTP access to a LATDMZ server even when only an HTTP publishing rule is active for the publishing server. Figure 4.20 shows a Web Proxy client on the internal network accessing an FTP site on the LATDMZ with only an HTTP publishing rule allowing access to the publishing server through the ISA server. Another interesting finding is the IP address to which the publishing server responds when the LATDMZ server sends its response to the Web Proxy client. Instead of the external IP address on the ISA server used for the Incoming Web Requests listener, the LATDMZ’s adapter IP address is used.We assume the reason for this is that this IP address is used for the Outgoing Web Requests listener on the LATDMZ segment.

Allow LATDMZ Hosts Access to the Internal Network There are some scenarios where the servers on the LAT segment need to communicate with servers on the internal network.The most common setting for requiring LATDMZ hosts to communicate with internal network clients is when you put an SMTP relay on the LATDMZ.The SMTP relay needs to be able to forward mail for your domains to the SMTP server on the internal network. We run into the same challenges as we had with internal network clients accessing resources on the DMZ segment.To allow a server on the LATDMZ to access resources on the internal network, the server needs to be a Firewall client, or you will need to publish the internal network server that the LATDMZ needs to connect to by installing the Firewall client on the internal network server and configuring a wspcfg.ini file. www.syngress.com


233

Figure 4.20 A Web Publishing Rule Allows FTP Access to the Publishing Server

What option should you choose? Installing the Firewall client on the server on the LATDMZ requires that you configure an account that the server can use to contact the Firewall service on the ISA server.You really don’t want to extend your internal network’s security zone into the DMZ.You can get around this by configuring the server to use an account that’s local to the ISA server. However, if the DMZ server is compromised, the intruder might be able to use the credentials used by the Firewall client to gain access to services on the ISA server and through that mechanism access resources on the internal network.There aren’t any documented incidents where this has actually happened, but if you’re in a high-security environment, it’s something to keep in mind.

ISA SERVER DEFCON 1 If you install the Firewall client on the LATDMZ server for the purpose of connecting to a publishing server on the internal network, you’ll need to have the user account logged on to the LATDMZ server. The Firewall client needs the logged-on user context to connect to the ISA server using the Firewall client. It’s good security practice to not allow users to be logged on to a publicly accessible server, because an intruder can leverage the logged-on user account to carry out exploits. If the publishing server on the LATDMZ were compromised, the attacker could use the context of that user account to attack the ISA server and possibly internal network hosts.

www.syngress.com

234


Making the server on the internal network a Firewall client and configuring a wspcfg.ini file creates its own complications.When you publish a server using the Firewall client and a wspcfg.ini file, the only way to access that service is by going through the external interface of the ISA server! For example, look at the scenario in Figure 4.21.The SMTP relay on the LATDMZ segment is published via an SMTP server publishing rule.The SMTP server on the internal network is published via a wspcfg.ini file.The SMTP server on the DMZ can access the SMTP server on the internal network by looping back through the external interface of the ISA server. However, hosts on the internal network cannot send SMTP messages to the SMTP server on the internal network! The internal network clients will need to loop back through the external interface of the ISA server to send messages to the SMTP server on the internal network. Figure 4.21 Publishing an FTP Server Using the Firewall Client SMTP Server on Internal Network Published via WSPCFG.INI file The SMTP Relay can access the internal network SMTP server via the external interface of the ISA Server

SMTP Relay

ISA Server

Local machines on internal network cannot communicate directly with the SMTP service

Because of the security implications of putting the Firewall client on a DMZ server, we usually configure the server on the internal network as a Firewall client if we need a server on the DMZ segment to communicate with it when using the private address DMZ configuration.

www.syngress.com


235

ISA SERVER ALERT Using the Firewall client and wspcfg.ini file to publish servers is not for the faint of heart! If you’ve done server publishing using Microsoft Proxy Server 2.0, you’re already acquainted with the methodology and you do it the same way on ISA Server. The key difference is that you do not create server publishing rules and a wspcfg.ini file. You do not need to create server publishing rules when you use the Firewall client on the publishing server. We highly recommend that you review Jim Harrison’s article on the Firewall client at www.isaserver.org/pages/article.asp?id=236. For an example on how to publish an FTP server using a wspcfg.ini file, check out this author’s article on how to publish FTP servers on an alternate port at www.isaserver.org/pages/article .asp?id=196. For an example of how to publish an SMTP server using a wspcfg.ini file, check out www.isaserver.org/pages/article.asp?id=994. To learn about the inability to bind an IP address on the external interface of the ISA server for outbound communications, check out www.isaserver.org/pages/ article.asp?id=994.

Using IPSec Policies RRAS packet filtering allows you to lock down communications leaving the DMZ so that in the event a server on the LATDMZ is compromised, your internal network resources are safe.The main problem with RRAS packet filters is that they are not very flexible.The exception-based policies severely limit granularity of packet filters you can create because you have to take into account both the Internet and the internal network traffic when creating the filters. If you find that RRAS packet filters are too limiting, IPSec policies might be just what you need to get more granular access control between the LATDMZ and the internal network. Unlike RRAS packet filters, IPSec policies are not based on exceptions. Instead, they are based on IP filter lists, which are collections of packet filters similar to packet filters you configure on the ISA server itself. Before going into the details of configuring IPSec policies, let’s take a closer look at the components of an IPSec policy.

Elements of an IPSec Policy An IPSec policy contains these key elements: ■

Rules

■

Filter lists

■

Filter actions www.syngress.com

236


Many people don’t understand or appreciate the power and ease of IPSec policies because the IPSec wizards hide what’s happening when you configure an IPSec policy. You’ll find that when you disable the wizards, you’ll better understand how policies work.

Filter Actions When a packet matches one of the packet filters in an IP filter list, one of three possible action is carried out after a positive match: ■

Permit

■

Block

■

Negotiate security

You can see the these options in Figure 4.22. Figure 4.22 Actions Based on IP Filter List Match

These three actions are obscured somewhat because they don’t show up right in front of you in the Filter Action tab in the IPSec Rule Properties dialog box (Figure 4.23). Note in Figure 4.23 that the Deny action is not installed by default; you’ll have to create that yourself.We’ll create a deny filter action later in this chapter. The most important thing to understand regarding filter actions is they are applied after there’s a match with a particular packet filter in a filter list.The only filter actions are Deny, Permit (Allow), and Negotiate Security.

www.syngress.com


237

Figure 4.23 The Filter Action Tab

IP Filter Lists An IP filter list is a collection of packet filters that IPSec policies use to match incoming and outgoing packets against.When a packet matches the parameters in a particular IP filter list, a filter action is applied to the communication. An IP filter list is just a collection of packet filters that the IPSec policy agent uses to match incoming and outgoing packets against.When there’s a positive match, a filter action associated with that filter list is applied. Figure 4.24 shows an IP filter list that matches packets sourcing from a machine on the LATDMZ segment to TCP ports 25 and 1433 on IP address 10.0.0.2 on the internal network.Therefore, if this DMZ host sends a packet with any source port to 10.0.0.2 TCP port 25, it will find a match in this IP filter list. In the same way, if this DMZ host sends a packet with any source port to 10.0.0.2 TCP port 1433, it will also find a match in this IP filter list. An IP filter list contains a list of discrete packet filters where only one of them has to be matched.This makes sense, since there is no way a packet with any source port can be sent to TCP port 25 and 1433. When a packet matches one of the packet filters in the filter list, a filter action is triggered. As stated previously, there are only three filter actions: Permit, Deny, and Negotiate Security. One thing that makes the IP filter list confusing is that you’re pummeled with multiple filter lists on the IP Filter List tab in the Edit Rule Properties dialog box (Figure 4.25). An IPSec rule only uses a single IP filter list. It gets a bit confusing because you see multiple IP filter lists in the IP Filter Lists frame. Each entry is a list, but you can only select one list per rule. An IPSec policy can contain multiple rules. www.syngress.com

238


Figure 4.24 An IP Filter List

Figure 4.25 The IP Filter List Tab

IPSec Rules An IPSec rule contains an IP filter list and a filter action that’s applied when a packet matches one of the entries on the filter list. Notice in Figure 4.26 that there are three IP security rules with two of them selected. A single IPSec policy can contain as many rules as you want. One of the active rules denies all traffic to the internal network from the LATDMZ host, and one allows traffic from the LATDMZ host to a specific host on the internal network via TCP 25 and 1433.

www.syngress.com


239

Figure 4.26 IPSec Policy Rules

This brings up a very important feature of IPSec rules and how they compare to RRAS packet filters. IP rules are applied so that the rule with the most specific match in a filter list is applied. For example, there are two rules defined in the IPSec policy in Figure 4.26.The Internal TCP 25/1433 rule applies when a packet matches any source port on the LATDMZ computer and the destination is 10.0.0.2 TCP ports 25 and 1433.The Internal Network policy is configured with the source being any port on the LATDMZ computer and the destination being any port on network ID 10.0.0.0/24. Which rule is more specific? Since the first rule is applied to a specific destination computer, it will be applied before the Internal Network rule, which applies to the entire network ID. The ability to apply more specific rules first gives you many more options than the crude, exception-based rules you must use with RRAS packet filters.You can create a general IPSec rule that denies access to all the network IDs on the internal network. After denying all traffic destined to the internal network from the LATDMZ host, you can then fine-tune the IPSec policy with additional rules that allows you to “punch holes” in the Deny policy you created. As long as the destination IP address or network ID is more specific than the one you created in your general Deny rule, it will be applied before the Deny rule.This will give the LATDMZ host access to particular services and particular servers on the internal network. Another thing to notice is that you can allow inbound access to the LATDMZ host from all the hosts on the internal network without opening unneeded and unwanted ports from the DMZ to the internal network, and you can allow the ISA server to

www.syngress.com

240


control all traffic between the Internet and the DMZ hosts.The IPSec filter lists give you this flexibility. Let’s look at a scenario and how we would create an IPSec policy to meet our LATDMZ’s requirements.

Creating IPSec Policies to Support Communications between the LATDMZ and the Internal Network Before creating an IP policy to allow communications between the DMZ segment and the internal network, you need to decide what protocols you want to allow through. First, decide what packets you want to allow from the DMZ host to the internal network, and then decide what packets you want to allow from the internal network to the DMZ. Before going into the scenario, review the network diagram of the test lab we’re working with in Figure 4.27. Figure 4.27 Network Diagram Internet

172.16.0.1 LAT DMZ 172.16.0.0/16

10.0.0.1 Internal Network 10.0.0.0/24

172.16.0.2

10.0.0.2

DMZ Server

Internal Network Server

The ISA server has two interfaces.The LATDMZ interface has the IP address 172.16.0.1.There is a server in the LATDMZ with the IP address 172.16.0.2.The ISA

www.syngress.com


241

server has an interface on the internal network with the IP address 10.0.0.1, and there is a server on the internal network with the IP address 10.0.0.2. In this scenario, we want to allow the server in the DMZ to forward SMTP messages to the server on the internal network.We also want to allow internal network clients access to HTTP and FTP on the DMZ server. All other packets between the internal network and the LAT-based DMZ segment are dropped. Perform the following steps to create the IPSec policy: 1. On the DMZ server, click Start, point to Programs, and point to Administrative Tools. Click on Local Security Policy. 2. In the Local Security Policy console, right-click on the IP Security Policies on Local Machine node and click the Create IP Security Policy command. 3. Click Next on the Welcome to the IP Security Policy Wizard page. 4. On the IP Security Policy Name page, type DMZ Host in the Name text box and click Next. 5. On the Requests for Secure Communication page, remove the check mark from the Activate the default response rule check box.We want to use an IPSec policy to provide packet filtering, not to negotiate security.This is the best-kept secret of IPSec policies! You can use them for advanced packet filtering and you don’t have to worry about negotiating security. Click Next. 6. This brings you to the Default Response Rule Authentication Method page. Since we’re not negotiating security and we’re not using the default response rule, it doesn’t matter what authentication method we choose. However, if you choose the Windows 2000 default (Kerberos V5 protocol) option, you’ll get an error message. Select the Use this string to protect the key exchange (preshared key) and type 987654. Click Next. 7. On the Completing the IP Security Policy Wizard page, leave the check mark in the Edit Properties check box.This brings up the dialog box that allows you to create a rule that includes a filter list and filter action. Click Finish. 8. In the DMZ Host Properties dialog box, remove the check mark from the IP filter list. Remove the check mark from the Use Add Wizard. Click Add so you can create the filter list. 9. The IP Filter List tab (Figure 4.28) appears first in the New Rule Properties dialog box.The first thing we need to do is create a filter list to match packets against. Click Add to begin creating the filter list.

www.syngress.com

242


Figure 4.28 The IP Filter List Tab

10. In the IP Filter List dialog box, type All IP Traffic in the Name text box (Figure 4.29). Remove the check mark from the Use Add Wizard check box. Click Add to create a filter. Figure 4.29 The IP Filter List Dialog Box

11. In the Filter Properties dialog box (Figure 4.30), make sure the Source address is set for My IP address. For the Destination address, select the A specific IP subnet option. In the IP Address text box, type 10.0.0.0, and in

www.syngress.com


243

the Subnet mask text box, type 255.255.255.0. Leave the check mark in the Mirrored check box.This will apply the filter to packets with the exact opposite source and destination address and port numbers. Figure 4.30 The Filter Properties Dialog Box

12. Click on the Protocol tab (Figure 4.31). Note that the default setting matches all protocols—this is what we want.This filter matches all packets, regardless of protocol.We’ll then associate a Deny filter action to this filter. After creating this filter, we’ll poke holes in it with another IPSec rule to include in this policy. Click Apply, and then click OK. Figure 4.31 The Filter Properties Dialog Box

www.syngress.com

244


13. Click Close in the IP Filter List dialog box. Notice there is already an All IP Traffic filter. Double-click on that filter to read the description (Figure 4.32).The dialog box informs you that even though you created a filter that matches all IP traffic, it will not match broadcast, multicast, Kerberos, RSVP, and IKE packets.The implication is that you won’t be able to use an IPSec policy to block these types of packets.This should not present too much of a problem, as these protocols are not typically used to exploit servers on the internal network. Click Cancel in the IP Filter List dialog box. Figure 4.32 The IP Filter List Dialog Box

14. Click the option button to the left of the All IP Traffic filter list. 15. Click the Filter Action tab (Figure 4.33). Note that there is a Permit filter and two filters that are used to negotiate security.The Permit filter allows traffic-matching filters in the filter list you selected in the IP Filter List tab. In our scenario, we want to begin by denying all traffic between the DMZ and the internal network. In order to do so, we’ll have to create a new filter action. Remove the check mark from the Use Add Wizard and click Add to create the new filter action. 16. In the New Filter Action Properties dialog box (Figure 4.34), select the Block option. Click on the General tab.Type Block in the Name text box. Click Apply, and then click OK. 17. The Block filter action appears in the Filter Action dialog box (Figure 4.35). Select that option by clicking on the option button to the left of the Block filter action.This completes the configuration of the rule.What this rule does is match all packets for all protocols and applies the Block action. If you did nothing else, no traffic would be allowed between this machine and the internal network. Click Apply, and then click OK. www.syngress.com


245

Figure 4.33 The Filter Action Tab in the New Rule Properties Dialog Box

Figure 4.34 The New Filter Action Properties Dialog Box

You now have one rule that’s active on the Rules tab of the DMZ Host Properties dialog box. Remember that you can have multiple rules active in a single IPSec policy.You only need to create a single rule per filter action. If you wanted to deny access to more subnets or individual IP addresses, you could add more filter lists to the All IP Traffic rule. www.syngress.com

246


Figure 4.35 The Filter Action Dialog Box

The next rule we need to create will contain filter lists tied to a Permit filter action. 1. In the DMZ Host Properties dialog box, click Add to add another rule. 2. In the New Rule Properties dialog box, click Add on the IP Filter List tab to add a new filter list. 3. In the IP Filter List dialog box, type DMZ-Internal in the Name text box. Click Add to add a filter. 4. In the Filter Properties dialog box (Figure 4.36), make sure the My IP Address option is selected for the Source address. For the Destination address, select the A specific IP Address option. In the IP address text box, type 10.0.0.2 (which is the IP address of the SMTP server on the internal network). Leave the check mark in the Mirrored check box.This will allow the server on the internal network to reply to the DMZ server. 5. Click on the Protocol tab (Figure 4.37). In the Select a protocol type drop-down list box, select the TCP option. In the Set the IP protocol port frame, select the From any port option and the To this port option. In the To this port text box, type 25. Click Apply, and then click OK. 6. In the IP Filter List dialog box click Add to add a filter.

www.syngress.com


247

Figure 4.36 The Filter Properties Dialog Box

Figure 4.37 The Protocol Tab

7. In the Filter Properties dialog box, make sure the A specific IP Subnet option is selected for the Source address. In the IP Address text box, type 10.0.0.0 in the IP Address text box.Type 255.255.255.0 in the Subnet mask text box. For the Destination address, select the My IP Address option. Make sure the Mirrored option is selected, as this will allow the server on the internal network to reply to the DMZ server. Click on the Protocol tab. In the Select a protocol type drop-down list box, select the TCP option. In the Set the IP protocol port frame, select the From any

www.syngress.com

248


port option and the To this port option. In the To this port text box, type 80. Click Apply, and then click OK. 8. Repeat the procedure in step #7, but use the destination port 21. 9. In the IP Filter List dialog box, click Add to add a filter. In the Filter Properties dialog box, make sure the My IP Address option is selected for the Source address. For the Destination address, select the A specific IP Subnet option. In the IP address text box, type 10.0.0.0 (which is the IP address of the SMTP server on the internal network). Leave the check mark in the Mirrored check box.This will allow the server on the internal network to reply to the DMZ server. Click on the Protocol tab. In the Select a protocol type drop-down list box, select the TCP option. In the Set the IP protocol port frame, select the From this port option and the To any port option. In the From this port text box, type 20. Click Apply, and then click OK. 10. Your IP Filter List should look something like what appears in Figure 4.38. Click Close in the IP Filter List dialog box. Figure 4.38 The IP Filter List Dialog Box

11. In the New Rule Properties dialog box, select the DMZ-Internal filter list by clicking the option button to the left of it. Click on the Filter Action tab and select the Permit option. Click Apply, and then click OK. 12. Click Close in the DMZ Host Properties dialog box. 13. Right-click on the DMZ Host Policy and click the Assign command. 14. Go to the Administrative Tools menu and click the Services entry. In the Services console, find the IPSEC Policy Agent entry and click the Restart button in the console’s button bar. www.syngress.com


249

You can test this policy by going to a host on the internal network and using the command-line FTP application to connect to the FTP server on the DMZ segment. You should be able to connect with no problem. Be sure to use PORT mode FTP. The filter list you created to allow traffic through does not support PASV mode FTP connections. You should also try using the browser on a host on the internal network and connect to the Web server on the DMZ segment.You’ll have no problems connecting! However, if you try to telnet to TCP port 25 on the DMZ host, it won’t work because the filter list for the Permit rule doesn’t include an entry that allows hosts on the internal network to connect to TCP port 25 from any source port number. Now that you see the logic behind creating IP policies, you will be able to create policies to meet your own requirements. Keep in mind the following facts: ■

You can activate only one policy at a time.

■

An IPSec policy can contain multiple rules.

■

You usually will need to create one rule for each filter action.

■

Each rule can contain multiple filter lists.

■

A filter list is a collection of packet filters that are used to compare against packets coming to and leaving the interface; if there’s a match, the filter action associated with the rule is applied.

■

A single filter action is applied to a rule.

■

You cannot create a Block filter action; there is no default Block filter action included with Windows 2000.

■

Always disable the default response rule; enable only rules you intend to use.

www.syngress.com

250


Summary In the chapter, we went over techniques that you can use to implement a private address, LAT-based DMZ segment.The ability to use an internal network segment for a DMZ is important because you should be able to take advantage of the Web and server publishing rules to make servers available on the DMZ.The only other option for a trihomed ISA server for publishing servers on a DMZ segment is to use public IP addresses on the DMZ segment, and then use packet filters to make those servers available to the Internet. As you learned in the last two chapters, packet filters are not very flexible and do not leverage the security features provided by Web and server publishing rules. You can use TCP/IP security to perform basic access control for incoming packets to the DMZ host.TCP/IP filters don’t do much to protect the internal network from a DMZ host, but they can prevent the DMZ host from packets arriving on hosts on the internal network.TCP security filters only apply to incoming packets and have no influence on packets leaving the host configured to use TCP/IP security filtering. One advantage of using TCP/IP security filters is that they work in kernel mode and thus are less subject to compromise. RRAS packet filters provide a powerful and effective method to control traffic moving between the LAT-based DMZ segment and the internal network. RRAS packet filters work on an exception basis; you can allow all traffic except for that for which you create filters, or you can deny all traffic except for that for which you create filters.While you can obtain a certain level of granularity over packets moving into and out of the DMZ segment, the exception-based filter makes it difficult to create a universal Deny rule with exceptions. RRAS packet filters depend on the Routing and Remote Access Service (RRAS), which runs as a user-mode process.The operating system can continue to run even if there is an access violation in the RRAS service, which can create a security risk to the internal network if the RRAS service is disabled on the ISA server. IPSec policies are implemented on the DMZ host itself. IPSec policies leverage sophisticated filter lists and filter actions that comprise IPSec rules.You can create a general, global Deny rule and then create exceptions to the global Deny by creating more specific rules.The IPSec policy agent is a user-mode process, and thus can be interrupted and the operating system will still run, which can cause a security risk to internal network clients if the agent is compromise on the DMZ host.

www.syngress.com


251

Defensive Tactics Fast Track Using TCP/IP Filtering (TCP/IP Security) ; TCP/IP filtering controls traffic sent to the interface of the computer on

which TCP/IP filtering is configured. ; TCP/IP filtering has no effect on traffic leaving the interface. ; TCP/IP filtering has no effect on ICMP traffic. ; You can control inbound UDP and TCP traffic using TCP/IP filtering. ; You can use TCP/IP filtering to control IP protocol type traffic (such as

GRE IP Protocol 47). ; TCP/IP filtering is used mainly to protect DMZ hosts from traffic originating

from internal network hosts. ; TCP/IP filtering runs in kernel mode, which confers it a higher level

of security.

Using Routing and Remote Access Service (RRAS) Packet Filters ; RRAS packet filters can control traffic moving between any of the interfaces

on the ISA server computer. ; You can use RRAS packet filters and not run a VPN server or VPN gateway

on the ISA server; the only thing you need to do is disable the packet filters that the ISA Server VPN wizard creates. ; RRAS packet filters work on an exception basis; you can allow all traffic

except for that which matches your packet filters, or you can deny all traffic except for that which matches your packet filters. ; Exception-based filtering makes it difficult to control traffic on a granular

basis because you cannot apply filters to all networks without adversely affecting Web and server publishing scenarios on the DMZ segment. ; The most effective RRAS packet filters are those that prevent traffic sourcing

from the LATDMZ segment from reaching any host on the internal network. ; You can create complex filters denying specific traffic from the LATDMZ

into the internal network. For example, you can select the allow all traffic www.syngress.com

252


except option and then create packet filters for NetBIOS and SMB/CIFS ports, SMTP, NNTP, Kerberos, IPSec, POP3,Telnet, or whatever services you might be running on the internal network that you do not want LATDMZ hosts to access. ; RRAS packet filters can be used together with IPSec policies to create a

multilayer security configuration.

Using IPSec Policies ; IPSec policies are based on IPSec rules, filter lists, and filter actions. ; You should create one IPSec rule per filter action. ; You can put multiple packet filters into a single filter list. ; You can use multiple IPSec rules in an IPSec policy. ; IPSec policies allow a more granular level of access control than RRAS

policies do. ; IPSec policies apply rules based on more specific filter lists preferentially over

more general filter lists; filter actions associated with a specific IP address or subnet will be applied before a filter action that applies to all computers.

www.syngress.com


253


Q: Why would I want to create a LAT-based DMZ? A: There are a number of reasons to create a LAT-based DMZ.The most important is so you can take advantage of the features provided by the Firewall and Web Proxy services to filter traffic as it moves from the Internet to the published servers on the DMZ segment. If you don’t use the LAT-based DMZ configuration, you’ll have to implement a back-to-back DMZ—which introduces higher cost and high complexity. If you don’t want to use a back-to-back DMZ, your only other “official” choice is the public address DMZ segment.When you use public addresses, you have to use ISA Server packet filters to move traffic between the Internet and the DMZ segment. By using the LAT-based DMZ configuration, you get around the limitations of the traditional trihomed DMZ configuration and take advantage of ISA Server’s Web and server publishing rules to publish servers on a DMZ segment.

Q: I don’t want to allow any traffic to move between the LAT-based DMZ segment and the internal network. I want my DMZ to be a true DMZ that is not trusted by the internal network. How do I prevent direct communications between the LATbased DMZ segment and the internal network?

A: The best way to enforce this type of demarcation between the LAT-based DMZ and the internal network is by using RRAS packet filters. RRAS packet filters are configured on the ISA Server machine and prevent traffic sourcing from the DMZ segment from reaching the internal network. Because these filters are applied on an exception basis, the easiest way to do this is to prevent all traffic from the DMZ network ID from being passed directly to the internal network ID.

Q: I find the RRAS packet filters too restrictive.What I want to do is allow only selected traffic from the DMZ segment to the internal network, and then allow all traffic from the internal network directly to the DMZ.The reason I want to do this is to take some of the heat off the ISA server and let the internal network clients directly communicate with the servers on the DMZ. How can I do this?

www.syngress.com

254


A: The best way to accomplish this is by using IPSec policies. IPSec polices use filter lists, which are a collection of packet filters that are used to match against a filter action.You can create a global Deny rule that prevents a DMZ host from sending any traffic to the internal network.Then, you can create most specific rules that contain filters that allow specific protocols access to specific servers on the internal network.This allows hosts on the LAT-based DMZ segment to send and receive traffic from specific servers on the internal network.

Q: How does TCP/IP Security fit into the LAT-based DMZ configuration? A: TCP/IP Security can be used to control what protocols are allowed inbound access to a server on the LATDMZ segment.TCP/IP Security filters are more focused on protecting LAT hosts from clients on the internal network.The LATDMZ servers are protected from Internet hosts by the ISA server.The ISA server controls what protocols are allowed inbound from the Internet to the hosts on the DMZ segment.TCP/IP Security can be used to block all traffic to a LATDMZ server except for the protocols you want to allow.You can accomplish the same goal using RRAS packet filters and IPSec policies.The advantage of TCP/IP Security filters is that they run in kernel mode, as compared to the RRAS packet filters and IPSec policies, which depend on user-mode processes.

Q: I want to run a front-end/back-end Exchange Server configuration and put the front end in the LATDMZ segment.What can I do to make this happen?

A: The first question you have to ask is, “Why should I put the front end in the DMZ segment?” If you’re doing it for security reasons, think about the security implications of extending the internal network security zone into the DMZ segment.The entire purpose of the DMZ is to create a completely separate and distinct security zone. By creating such a separate security zone, even if a server on the DMZ is compromised, the accounts on the internal network are secure.The intruder will not be able to leverage accounts on the compromised server to access resources on the internal network. If you put a front-end server on the DMZ segment, you must make that front-end server a member of an internal network domain.

www.syngress.com

Chapter 5

Defense Plan 4: Advanced Server Publishing


Disabling Socket Pooling

■

Server Publishing

■

Web Publishing


255

256

Chapter 5 • Defense Plan 4: Advanced Server Publishing

Introduction ISA Server allows you to control what internal network clients can access on the Internet and what external, Internet-based clients can access on the internal network. You are “publishing” servers when you configure the ISA server to allow external network clients access to resources on the internal network. ISA Server supports two types of publishing: ■

Web publishing

■

Server publishing

Web publishing rules publish HTTP and FTP servers located on the internal network, and give you the ability to do the following: ■

Publish multiple Web servers using a single IP address on the external interface of the ISA server.

■

Use an Incoming Web Requests listener to accept inbound HTTP requests.

■

Authenticate with the ISA server at the Incoming Web Requests listener using basic, integrated, digest or certificate authentication.

■

Perform port redirection. Only the Web Proxy service can accept requests on a specific port on the external interface of the ISA server and forward it to an alternate port on an internal server.

■

Examine the HTTP header and make decisions on how to redirect the request based on the destination URL.

■

Bridge Secure Sockets Layer (SSL) requests as HTTP requests.This reduces processing overhead on the internal Web server and allows the ISA server to handle the SSL processing.

■

Bridge SSL requests as SSL requests.This allows the ISA server to terminate an SSL connection on its external interface and then create a second SSL connection between its internal interface and the Web server on the internal network.

■

Extend the security features provided by the Web Proxy service by installing Web filters. Even the URLScan ISAPI filter can be installed on the ISA server to improve security for your Web publishing rules.

To get a better idea of how Web publishing rules work, consider the following scenario: You have an ISA server with a single public IP address assigned to its external interface.You want to publish three Web servers on the internal network using one external

www.syngress.com

Defense Plan 4: Advanced Server Publishing • Chapter 5

257

network IP address.You also want to use the same public fully qualified domain name (FQDN) that users will type in to access the three servers on the internal network.The only difference is that the users will use a different path in the URL to access the servers; for example, /catalog, /specs and /orders. Note in this example that we used the path to determine what server the incoming request was redirected to.This is a very handy feature, but one limitation is that the request is redirected to the same folder on the server on the internal network.What you cannot do is have an incoming request to http://www.mydomain.com/server1 and redirect that request to http://server1.You can redirect to different servers based on the path, but you cannot redirect to an alternate path.This was something you could do with Proxy Server 2.0, but that functionality is not included with ISA Server. Another feature of Web publishing rules is that requests handled by Web publishing rules pass the IP address of the internal interface of the ISA server to the internal Web server.The original IP address in the incoming client request is not included.The internal Web server’s log files show all requests coming from the internal interface of the ISA server.This might create some problems for you if you want or need to analyze the Web server’s log files for traffic patterns.You’ll have to extract the information from the ISA server’s Web Proxy logs.

ISA SERVER ALERT The only way you can get the original source IP address in the Web server’s log files is to use server publishing rules. There is no way to pass the original source IP address to the internal Web server if you use Web publishing rules. There are a number of log analyzers you can run against the Web Proxy log that can assist you in site analysis. Check them out at www.isaserver.org/ software/ISA/Reporting/.

Server publishing rules allow you to publish almost any type of server. However, Server publishing rules lack the power and flexibility of Web publishing rules because a server publishing rule is essentially a reverse NAT mapping. Unlike Web publishing rules, Server publishing rules do not have a service such as the Web Proxy service to examine application layer headers. Server publishing rules give you the ability to do the following: ■

Map an IP address and port number on the external interface of the ISA server to an IP address on the same port number on an internal network server.

■

Publish any protocol that has a primary connection as inbound. Server publishing rules use protocol definitions found in the Protocol Definitions node in the ISA Server Management console. www.syngress.com

258

Chapter 5 • Defense Plan 4: Advanced Server Publishing ■

Use client address sets to control what IP addresses on the external network can access a server publishing rule. For example, you can publish a terminal server on the internal network and allow only the IP address of your home computer access to that server publishing rule.

■

Use “smart” application-layer filters that examine the application layer data as it moves through the ISA server.These application-layer filters perform a variety of functions to provide better security.

While server publishing rules do not automatically take advantage of applicationlayer data analysis, they will leverage the features of a number of application filters included with ISA Server. For example, you can publish SMTP, DNS, and POP3 servers on the internal network and have them protected against buffer overflows by enabling the SMTP, DNS, and POP3 application filters, respectively.The SMTP application filter can even go one step further and be used in conjunction with the SMTP message screener to filter out spam.The ISA Server SMTP Message Screener further extends the examination of the application-layer data by reviewing e-mail message content and blocking messages based on rules that you configure. Server publishing rules can use application filters to help them publish complex protocols. A complex protocol is any protocol requiring one or more secondary connections. As you learned in Configuring ISA Server 2000: Building Firewalls with Windows 2000, only Firewall clients can use complex protocols.This creates a problem for servers published via server publishing rules because these servers need to be configured as SecureNAT clients. ISA Server comes with the FTP Access application filter, which allows you to publish FTP servers, even though these servers are configured as SecureNAT clients. Since FTP servers require secondary connections, the FTP access application filter manages the connection for the FTP server (which is configured as a SecureNAT client) on the internal network. Server publishing rules allow you to publish almost any protocol, although you might have to create your own application filter to support servers requiring complex protocols. Another advantage that server publishing rules have over Web publishing rules is that you can record the actual source IP address in the publishing server’s logs. The ISA server does not replace the source IP address when passing packets via server publishing rules.

ISA SERVER DEFCON 1 Some people refer to the situation in which the ISA server does not replace the source IP address in the packet as “half NAT.” You can configure the ISA server to perform a “full NAT” and replace the source IP address with the IP address of the internal interface of the ISA server. This might be a preferred configura-

www.syngress.com


259

tion when you want to avoid changing your network infrastructure just to support publishing servers. When you enable “full NAT,” the only route required is one that allows the publishing server access to the network ID on which the internal interface of the ISA server is located. This allows you to avoid configuring a default gateway on the publishing server that routes packets to the Internet. Since the publishing server will not be responding to an Internet address, it will be responding to an internal network address (the address of the internal interface of the ISA server).

How do server publishing rules work? The ISA server’s external IP address on TCP port 25 receives an incoming packet.The ISA server checks to see if there is a server publishing rule that matches packets arriving on the ISA server’s external interface. If there is, the ISA server forwards the request to the internal network IP address listed in the server publishing rule. Server publishing rules work well if there is only one server on the internal network that you want to publish for a particular service. For example, we have a single IP address on the external interface of the ISA server and we publish a single SMTP server on the internal network.This works without any problems. However, what if we have two SMTP servers on the internal network and we want to publish them both? You can do this, but not with a single IP address on the external interface of the ISA server. Unlike the situation with the Web Proxy service and its Web publishing rules, you cannot publish the same service multiple times using a single IP address on the external interface of the ISA server. Publishing the same service multiple times with a single IP address on the external interface creates port contention.The ISA server realizes this and does not let you create two rules publishing the same service on the same external IP address.While the ISA server knows that you’re trying to use the same socket twice on the external interface when you try to create two server publishing rules, you can still have problems with port contention if you run other services on the ISA server that listen on the same port as the service you want to publish. Port contention created by non-ISA services on the ISA server is a common problem.This might happen if you are running any of the Internet Information Server (IIS) services on the ISA Server machine and then try to publish the same service located on an internal network server.You’ll encounter the same problem if you try to publish Terminal Services and the Terminal server is running on the ISA server, or if you have Exchange 2000 installed on the ISA server and try to publish IMAP or POP3 services on the internal network (or even when those services are located on the ISA server itself). Because port contention is a common problem for both Web and server publishing rules, let’s look at how to handle the most common reason for this problem: IIS socket

www.syngress.com

260


pooling. After you learn how to disable socket pooling, we’ll get down to the details of publishing various services on the internal network using Web and server publishing rules.

Disabling Socket Pooling Socket pooling is an IIS feature that allows IIS services to listen on all interfaces, regardless of the IP address you set the service to listen on. Socket pooling doesn’t pose a problem for a unihomed server on the internal network. In fact, socket pooling helps to improve IIS performance by allowing all of the IP addresses on the server to share the same set of sockets, which can significantly reduce resource consumption by the services.The problem is that socket pooling is not a good thing when the server is connected to multiple networks and not all of those networks are trusted.This is exactly the situation we usually have with a multihomed ISA server. The following IIS and Exchange services implement socket pooling: ■

The IIS Web Publishing Service (W3SVC)

■

The IIS FTP Publishing Service (MSFTPSVC)

■

The IIS Simple Mail Transport Protocol (SMTP) Service (SMTPSVC)

■

The IIS Network News Transport Protocol (NNTP) Service (NNTPSVC)

■

The Exchange 2000 Post Office Protocol (POP3) Service (POP3SVC)

■

The Exchange 2000 Internet Mail Access Protocol 4 (IMAP4) Service (IMAP4SVC)

If you run any of these services on the ISA Server machine, you should always disable socket pooling for that service and configure it to listen only on the ISA server’s internal interface. Alternately, you can disable IIS services on the ISA.

ISA SERVER DEFCON1 We recommend that you disable the IIS services on the ISA server. When properly configured, the ISA Server Firewall and Web Proxy services confer a high level of security against external network attacks. Adding services to the ISA server creates portals of attack that Internet criminals can use to compromise the ISA server and the internal network. Well-known exploits can be aimed against any of the IIS services and potentially disable security provided by the ISA Server software or create a denial of service (DoS) condition. The IIS Web Publishing Service is especially problematic in this regard. . Although we will spend quite a bit of time discussing methods you can use to publish services on the ISA server itself, never do so unless budgetary constraints prevent you from purchasing a dedicated ISA Server computer. You obtain a level of security based on how much money you can spend.

www.syngress.com


261

How do you know if socket pooling is enabled on the ISA server? You can you the netstat –na command to list all the active listening ports. Note that just because a port is listening doesn’t mean that anyone can connect to it. If you enabled packet filtering on the ISA server, none of the listeners on the external interface are available unless you explicitly create a publishing rule or packet filter allowing access to the socket (a socket is a combination of a TCP or UDP port number and an IP address). Figure 5.1 shows the results of a netstat –na before disabling socket pooling. Notice in the Local Address column the entries for IP address 0.0.0.0.Those entries indicate that the associated port is listening on all IP addresses. A large number of services are listening on all IP addresses.We need to disable socket pooling to prevent the server from listening on TCP ports 21 (FTP), 25 (SMTP), 80 (HTTP), and 119 (NNTP) for all interfaces Note that TCP 42 (WINS) and UDP 53 (DNS Query) are also listening on all interfaces.The TCP 42 entry indicates that a WINS server is installed on this ISA server (something that we should disable before bringing the server into production), and UDP 53 indicates that a DNS server is installed on this machine.There aren’t any contraindications to running a DNS server on the ISA server, but you should configure the DNS service to listen on the internal interface only.You can change the DNS service’s listening address in the server’s Properties dialog box in the DNS console. Figure 5.1 Results of netstat –na Before Disabling Socket Pooling

www.syngress.com

262


Disabling Web and FTP Service Socket Pooling W3SVC and FTP service socket pooling is disabled using the same method.The only difference is the service name you enter in the command line. Perform the following steps to disable FTP and/or Web service socket pooling: 1. Open a command prompt and navigate to the \Inetpub\Adminscripts\ folder. 2. Type net stop msftpsvc and press Enter.Type net stop w3svc and press Enter. 3. Type in the following command: cscript adsutil.vbs set msftpsvc/ disablesocketpooling true (to disable FTP service socket pooling) or cscript adsutil.vbs set w3svc/disablesocketpooling true (to disable W3SVC service socket pooling), and then press Enter. 4. You should see what appears in Figure 5.2. Figure 5.2 Disabling Socket Pooling

5. Restart the W3SVC by running net start w3svc at the command prompt. Restart the FTP service by running net start MSFTPSVC at the command prompt. If you run a netstat –na again after disabling Web and FTP socket pooling, you’ll see that they are still listening on all IP addresses.The reason for this is that the default setting for the built-in FTP and Web sites is to listen on all addresses. Keep in mind that

www.syngress.com


263

a service can still listen on all IP addresses even if socket pooling is disabled.The difference is that after you disable socket pooling, you then have the option to configure the service to listen on only one IP address.You’ll see the services listen only on the address you configure in the IIS console after you go into the IIS console and configure the sites to listen on the internal interface’s address. Figure 5.3 shows what you see after disabling socket pooling for FTP and WWW services, and what happens after configuring the services to use a specific IP address on the internal interface. Notice that immediately after disabling socket pooling, the FTP and Web services continue to listen on 0.0.0.0.You then see that both the FTP and Web services listen on 10.0.0.1 after configuring them to do so in the Internet Information Services console. Figure 5.3 Running netstat –na After Disabling Socket Pooling

Disabling SMTP and NNTP Service Socket Pooling You have to use a technique other than the one just discussed to disable socket pooling for the SMTP and NNTP services—why is unclear. In fact, no one seems to have any idea! We won’t let this lack of understanding prevent us from disabling socket pooling for these services. The first thing you need to do is get the mdutil.exe utility.You might be able to find it somewhere on the Microsoft Web site, but you’ll always be able to download it at ftp://ftp.tacteam.net/isaserver/mdutil.exe. Perform the following steps after downloading the mdutil.exe utility: 1. Put the Mdutil.exe executable in the \Inetpub\Adminscripts folder. 2. Open a command prompt window, change the focus to \Inetpub\Adminscripts, and run the following commands (Figure 5.4): ■

mdutil set -path smtpsvc/1 -value 1 -dtype 1 -prop 1029 -attrib 1 (for the SMTP service)

■

mdutil set -path nntpsvc/1 -value 1 -dtype 1 -prop 1029 -attrib 1 (for the NNTP service)

www.syngress.com

264


Figure 5.4 Disabling SMTP and NNTP Socket Pooling

3. You will need to run these commands multiple times if you have more than one SMTP or NNTP virtual server.The difference is that you increment the value in nntpsvc/1 and smtpsvc/1 to the next higher value. If you have two SMTP and NNTP virtual servers, the second time you run the commands you would include nntpsvc/2 and smtpsvc/2. 4. Go to the Internet Information Services console, right-click on the Default SMTP Virtual Server, and click Properties. Change the listening address to the internal interface of the ISA server. Do the same for the NNTP service so that it listens only on the internal IP address.

Disabling IIS Services on the ISA Server Disabling socket pooling handles the port contention problem, but the real solution is to disable IIS services on the ISA server.We can’t emphasize strongly enough how important it is to avoid running IIS services on the ISA server. In addition to increasing your security risks by running the IIS services, one of the most common reasons why publishing rules fail is that the ISA Server administrator has failed to disable socket pooling or the IIS services entirely. Even after almost two years and several hundreds of ISA Server installations, we continue to forget to disable IIS services on the ISA server. It’s only after the publishing rules fail that we realize our error! At one time, we recommended that you uninstall IIS from the ISA Server computer.While this fixes the IIS services problems, it introduces another.There have been

www.syngress.com


265

several reliable reports of problems installing and uninstalling ISA Server after uninstalling IIS.The only way to install or uninstall ISA Server is to reinstall IIS.There is no compelling reason to uninstall IIS; all you need to do is disable the IIS services. Perform the following steps to disable the IIS services: 1. Open the Services console from the Administrative Tools menu. 2. Double-click on the FTP Publishing Service in the right pane of the Services console. 3. In the FTP Publishing Services Properties (Local Computer) dialog box, change the Startup type to Manual.You’ll still be able to start the service without having to restart the server. If you set the Startup type to Disabled, you will have to change the Startup type to Automatic or Manual and then restart the server to start up the service. 4. Click Stop to stop the service. Click Apply, and then click OK. 5. Repeat these steps with the NNTP, SMTP, and WWW publishing services. You do not need to restart the ISA server for these changes to take effect.

Server Publishing Server publishing rules allow you to publish almost any type of server protocol. As noted earlier, server publishing rules essentially perform a reverse NAT that allows the ISA server to accept packets on a certain IP address and port number and forward them to the same port number to an IP address on the internal network.While server publishing rules do not allow the ISA server to examine the data portion of the communication on their own,“smart” application filters can be applied to protect communications forwarded by server publishing rules. In this section, we’ll look at how to publish the following services: ■

Terminal Services

■

Terminal Services Advanced Client (TSAC) Sites

■

FTP Servers

■

HTTP and HTTPS Servers

■

VNC Servers

■

pcAnywhere Servers

www.syngress.com

266


Publishing Terminal Services on the Internal Network Publishing a Terminal server on the internal network is relatively straightforward. All you need is a protocol definition with Primary Connection set for Inbound TCP 3389, and a server publishing rule that uses this protocol definition.The only thing that can interfere with Terminal server publishing rules is port contention.The best way to eliminate the Terminal Services port contention is to disable Terminal Services on the ISA server. However, most of us want to run Terminal Services on the ISA server to ease server administration, so we’ll go over how to run Terminal Services on the ISA server and publish an internal network Terminal server at the same time later in this chapter. Let’s begin with how to publish Terminal Services on an internal network server when Terminal Services is not running on the ISA server. Perform the following steps to publish a Terminal server: 1. Open the ISA Management console. Expand your server name and then expand the Policy Elements node. 2. Right-click on the Protocol Definitions node, point to New, and click Definition. 3. On the Welcome to the New Protocol Definition Wizard page, type RDP Server for the Protocol Definition name and click Next. 4. On the Primary Connection Information page, type 3389 for the Port number and change the Direction to Inbound. Click Next. 5. The Remote Desktop Protocol (RDP) does not use secondary connections, so select No and click Next. 6. Click Finish on the Complete the New Protocol Definition Wizard page. 7. Expand the Publishing node in the left pane of the ISA Management console. Right-click on Server Publishing Rules, point to New and click Rule. 8. On the Welcome to the New Server Publishing Rule Wizard page, type Terminal Server 1 in the Server publishing rule name text box and click Next. 9. On the Address Mapping page, enter the IP address of the Terminal Server on the internal network in the IP address of internal server text box. Click Browse and select the IP address on the external interface of the ISA server you want to listen for Terminal Services requests. Click Next. 10. On the Protocol Settings page, select the RDP Server protocol definition. Note that protocol definitions with a primary connection as inbound are

www.syngress.com


267

shown here. No protocol definitions with a primary connection as outbound will show up here. Click Next. 11. On the Client Type page, decide whether you want to allow all external hosts to connect to the Terminal server, or if you want to limit access to hosts contained in a client address set.You should limit the number of hosts that can connect to the Terminal server via the RDP server publishing rule. Note that you must enable packet filtering in order to apply a client address set to control what computers can access the server publishing rule. Packet filtering is enabled by default, but you might need to double check to ensure that it’s still enabled. Select the Client address sets specified below option and click Next (Figure 5.5). Figure 5.5 Selecting the Client Address Sets Option on the Client Type Page

12. On the Add Client Sets page, click Add. Select the client address set you created for Terminal Services clients and click Add.The client address set will appear in the Include these sets frame. Click OK (figure 5.6). Figure 5.6 Selecting the Client Address Set

www.syngress.com

268


13. Click Next on the Client Sets page. 14. Click Finish on the Complete the New Server Publishing Rule Wizard page. Now go to an machine configured as an external network client and connect to the Terminal Server by using the external IP address on the ISA Server used by the RDP Publishing Rule. After establishing the connection, check the name of the server you connected to by right-clicking on the My Computer icon and then clicking the Properties command. Click the Network Identification tab. If you see the name of the ISA Server instead of the internal network server, you forgot to disable Terminal Services on the ISA Server! Disable Terminal Services on the ISA Server, restart the computer, and try again.

Publishing Terminal Services on an Alternate Port You have to be careful about publishing Terminal Services. If intruders are able to connect to a Terminal server, they’ll have a powerful launch point for subsequent attacks. You’ve already seen how you can limit access to a few selected Terminal Services clients on the Internet by applying a client address set to the RDP server publishing rule. Using client address sets is a good start, but there’s more that you can do to secure your Terminal Services publishing rule. Since TCP port 3389 is a well-known port, and Terminal Services is an attractive service to attack, you might want to impede Internet criminals by changing the port number used by Terminal Services.You can change the listening port number to any unused port number on the ISA server’s external interface, and then publish the Terminal server on that alternate port. In order to do so, you’ll have to make a Registry change at the Terminal server and then change the port number that the Terminal Services client uses to call the Terminal server.

ISA SERVER ALERT You can get the Remote Desktop Client software from the Microsoft Web site at http://download.microsoft.com/download/whistler/tools/1.0/wxp/en-us/ msrdpcli.exe. If for some reason it’s not available there, you can always get it at our FTP site at ftp.tacteam.net/isaserver. We’ll keep the client software updated in the event there are changes. The new Remote Desktop Client software makes it easy to connect to Terminal servers listening on alternate port numbers, and allows you to have full color displays and sounds when connecting to Windows 2003 Terminal servers.

www.syngress.com


269

If you use the new Remote Desktop Client software to connect to a Terminal server, you don’t need to make any changes on the client side. All you need to do is include the port number in the address you’re calling. For example, if you want to call a published Terminal server at 1.1.1.1 and that Terminal server is listening on TCP port 58927, just enter the address 1.1.1.1:58927 on the Remote Desktop Client and it will make the connection. It’s not quite this easy with the original Windows 2000 or Windows NT 4.0 Terminal Services client software. Perform the following steps to change the listening port for the Windows NT 4.0 Terminal Services Edition Terminal Server and the Windows 2000 Terminal Server. These steps should be performed on the Terminal server you’re publishing on the internal network. However, you can also change the listening port for the Terminal server on the ISA server using the same procedure: 1. Click Start and then click Run.Type regedt32 in the Open text box and click OK. 2. Navigate to the following key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer \WinStations\RDP-Tcp

3. Find the PortNumber value in the right pane and double-click it. 4. In the DWORD Editor dialog box, select the Decimal option. Change the port number to something else. In this example, we’ll change it to 64646. Click OK. 5. Restart the Terminal server computer. Perform the following steps to create the new RDP server protocol definition: 1. Open the ISA Management console. Expand your server name and then expand the Policy Elements node. 2. Right-click on the Protocol Definitions node, point to New and click Definition. 3. On the Welcome to the New Protocol Definition Wizard page, type RDP Server 64646 for the Protocol Definition name and click Next. 4. On the Primary Connection Information page, type 64646 for the Port number and change the Direction to Inbound. Click Next. 5. RDP does not use secondary connections, so select No and click Next. 6. Click Finish on the Complete the New Protocol Definition Wizard page.

www.syngress.com

270


Perform the following steps to create the server publishing rule to publish the Terminal server on the alternate port: 1. Expand the Publishing node in the left pane of the ISA Management console. Right-click on Server Publishing Rules, point to New, and click Rule. 2. On the Welcome to the New Server Publishing Rule Wizard page, type Terminal Server 2 in the Server publishing rule name text box and click Next. 3. On the Address Mapping page, type in the IP address of the Terminal Server on the internal network in the IP address of internal server text box. Click Browse and select the IP address on the external interface of the ISA server that you want it to listen on for Terminal Services requests. Click Next. 4. On the Protocol Settings page, select the RDP Server 64646 protocol definition. Click Next. 5. On the Client Type page, select the appropriate client type. In this example, we’ll select Any request, but you should use a client address set in your production environment. 6. Click Finish on the Complete the New Server Publishing Rule Wizard page. The last step is to configure the Terminal Services client to use the alternate port number: 1. Click Start and point to Programs. Point to Terminal Services Client and click Client Connection Manager. 2. In the Client Connection Manager, click the File menu and then click New Connection. Go through the steps in the wizard to create a connection object for your published Terminal server. Remember to use the IP address or FQDN that resolves to the external IP address on the ISA server that’s publishing the Terminal server. 3. Click on the icon for the connection in the Client Connection Manager window, and then click the File menu. Click Export. Give the connection a name and save it on your desktop. 4. Right-click the Terminal Services client connection object on the desktop and click the Open With command. Select Notepad from the list of applications. If you are using a Win9x client, you’ll have to open Notepad and open the connection object within Notepad.

www.syngress.com


271

5. In Notepad, find the Server Port= entry and change it to the port number you’re using to publish your Terminal server. Save the file and close Notepad. 6. Drag the icon on the desktop onto the Client Connection Manager window. A Client Connection Manager dialog box will appear and ask if you want to replace the connection object with the new one. Click Yes. A Client Connection Manager dialog box appears and asks if you want to replace the connection settings for all duplicates. Click No. 7. Double-click on the connection object in the Client Connection Manager window. Log on and confirm that you’re connected to the correct server. Go to the ISA Server computer and run netstat –na.You’ll see an active connection to the alternate RDP server port used in the new server publishing rule.

Publishing Terminal Services on the ISA Server Publishing services on the ISA server is always problematic.Your goal should be to run as few services as possible on the ISA server computer. However, running Terminal Services on the ISA server is acceptable because you can create secure connections to the Terminal server, and Terminal Services provides the best way to remotely manage an ISA server.We consider Terminal Services as secure as an SSL Web-based remote management solution. Connections to Terminal Services will be even more secure with Windows 2003 because you’ll be able to use smart card authentication. You almost always have two options when publishing services on the ISA server itself.The easiest method is to create a packet filter so that external network clients can connect directly to the services via the external interface.The other way is to use a server publishing rule.The latter option can be used if you can configure the service to listen only on an IP address or set of addresses on the internal interface.

ISA SERVER ALERT Although you can always “publish” services that are on the ISA server itself by creating packet filters, the packet filter approach prevents you from using server publishing rules to publish services on the internal network using the same socket. Remember that a socket is the combination of an IP address, a protocol (TCP or UDP), and a port number. For example, if you create a packet filter to publish the Terminal server on the ISA server on 1.1.1.1 TCP port 3389, you will not be able to use 1.1.1.1 TCP port 3389 to publish a Terminal server on the internal network.

www.syngress.com

272


The Windows 2000 Terminal Server listens on all interfaces by default.This is similar to how the IIS socket-pooling feature works. Like the IIS socket pooling feature, you can configure it so that Terminal Services does not listen on all interfaces. Although you can choose what interface Terminal Services listens on, you cannot choose a specific IP address on the interface. If there are multiple IP addresses bound to the interface, Terminal Services will listen on all of them.This is an important consideration when you bind multiple addresses to the internal or external interface of the ISA server.

Publishing Terminal Services on the ISA Server Using Packet Filters Let’s look at how to publish Terminal Services using simple ISA Server packet filters: 1. Click Start and point to Programs. Point to Administrative Tools and then click Terminal Services Configuration. 2. In the Terminal Services Configuration console, click on the Connections node in the left pane of the console. In the right pane of the console, Double-click on the RDP-Tcp entry. 3. Click on the Network Adapter tab. Click the Down arrow in the Network adapter drop-down list box. Notice that the default is All network adapters configured with this protocol.You can also choose a specific adapter.The adapters are listed by the adapter manufacturer’s name rather than the name you give to the interface in the Network and Dial up Connections window.When publishing the Terminal server on the ISA server using packet filters, you can allow the Terminal server to listen on all interfaces. By doing it this way, you won’t have to loop back through the external interface to access the Terminal server from an internal network client. However, if you plan to publish the Terminal server by using server publishing rules, you’ll need to configure Terminal Services to listen only on the internal interface (Figure 5.7). 4. Open the ISA Management console. Expand your server name, and then expand the Access Policy node. 5. Right-click on the IP Packet Filters node, point to New and click Filter. 6. On the Welcome to the New IP Packet Filter Wizard page, type RDP (in) in the IP packet filter name text box and click Next. 7. On the Filter Mode page, select the Allow packet transmission option and click Next. 8. On the Filter Type page, select the Custom option and click Next.

www.syngress.com


273

Figure 5.7 Configuring Terminal Services to Listen on the Internal Interface

9. On the Filter Settings page, choose TCP for the IP protocol. Choose Inbound for the Direction. Choose Fixed port for the Local port and make the Port number value 3389. For the Remote port, select All ports (Figure 5.8). Click Next. Figure 5.8 Configuring the RDP Packet Filter

10. On the Local Computer page, select the option that best fits your situation. The Default IP addresses for each external interface on the ISA Server computer sets the filter to listen on the external interface’s primary IP address. If you have multiple IP addresses bound to the external interface, you can choose the This ISA Server’s external IP address option and type in the IP address to which you want the filter to apply. Make a selection and click Next.

www.syngress.com

274


11. On the Remote Computers page, select the All remote computers option and click Next. 12. Click Finish on the Completing the New IP Packet Wizard page. Now try to connect to the Terminal server from an external network client.You’ll be able to connect directly to the external interface of the ISA server. Some of you might be concerned about allowing a direct connection using a packet filter.You might believe that you will achieve a higher level of security by using a server publishing rule—which is incorrect. Remember that server publishing rules do not expose the application-layer data to the Firewall service, unlike when using Web publishing rules. Since there are no application filters that will examine the RDP connections, a server publishing rule doesn’t necessarily provide a higher level of security The primary advantage of using a server publishing rule to publish Terminal Services on the ISA server is that it allows you to apply a client address set to control inbound access to the rule.While this doesn’t protect the data stream, it’s important that you limit who can connect to the Terminal server. For this reason, we recommend using server publishing rules to publish the Terminal server on the ISA server.

Publishing Terminal Services on Both the ISA Server and Internal Network Many ISA Server administrators need to publish the Terminal server on the ISA Server machine and allow access to Terminal servers on the internal network.There are several methods that you can use to allow access to the Terminal server on the ISA server and to machines on the internal network: ■

Use server publishing rules to publish all Terminal servers.

■

Use packet filters to publish the Terminal server on the ISA server, and server publishing rules to publish the servers on the internal network.

■

Publish the Terminal server on the ISA server using server publishing rules or packet filters, and then access the other Terminal servers on the internal network by running the Terminal Services client inside the Terminal Services session on the ISA server.

Any of these techniques will work. If you have a single IP address bound to the external interface of the ISA server, then you can create only one server publishing rule or packet filter. Other Terminal Services sessions will have to use alternate port numbers, using the methods described earlier in this chapter. For example, suppose you have two Terminal servers on the internal network and you are also running Terminal Services on the ISA server.You want to be able to access www.syngress.com


275

all of these Terminal servers from the Internet. If you need Terminal Services access for only administrative purposes, you can publish the Terminal server on the ISA server with the default port number (TCP 3389) and then use alternate port numbers for the other servers on the internal network. No matter what method you choose, keep in mind that the limiting factor is port contention.You can publish as many Terminal servers as you like, as long as you don’t create a port contention condition on the external interface of the ISA server.

Publishing TSAC Sites The Terminal Services Advanced Client (TSAC) provides a way for your users to access a Terminal server using a Web browser interface.The Web interface allows you to connect to a Terminal server without already having the Terminal Services or Remote Desktop client already installed on the client machine.This allows users who haven’t installed the client software to access the Terminal server. The Terminal Services Advanced Client software must first be installed on a Web server on the internal network.You can install the software on any Web server on your internal or external network (DMZ).There is no relationship between the physical location of the Web server hosting the TSAC site and the terminal server or servers to which users connect. After users connect to the TSAC Web site, they are offered the opportunity to install the TSAC ActiveX control. After installing the ActiveX control, the user enters the name of the Terminal server to which they want to connect.

ISA SERVER ALERT This brings up a common area of confusion for ISA Server administrators. When users enter the name of the Terminal server in the TSAC logon form, they must enter a name or IP address that is valid on the external network. The Terminal Services client connection is established via the IP address on the external interface of the ISA server used by the RDP server publishing rule publishing the Terminal server. Users and administrators often enter the internal name of the Terminal server and discover that the connection fails. You must use a name or IP address that resolves to the public IP address on the external interface of the ISA server that matches the address used in the RDP server publishing rule.

Do the following to publish a TSAC site: 1. Install the TSAC software on the Web server. 2. Publish the TSAC Web server.

www.syngress.com

276


3. Publish the Terminal server(s). 4. Connect to the TSAC Web site and then connect to the Terminal server.

Installing the TSAC Software on the Web Server Perform the following steps to install the TSAC Web software on a server on the internal network: 1. Open Internet Explorer and go to www.microsoft.com/windowsxp/ pro/downloads/rdwebconn.asp. Select the appropriate language for your site and click GO. 2. On the File Download page, select the Save this program to disk option, and click OK. 3. Save the tswebsetup file to the desktop, and click Save in the Save As dialog box. 4. Click Open in the Download Complete dialog box. 5. On the Remote Desktop Web Connection Setup dialog box, click Yes to install the package. 6. Read the license information and then click Yes to agree to the license. 7. A dialog box appears showing the default path in the wwwroot folder where the TSAC Web connection files are stored.You can change the path here. Click OK to continue. 8. An information dialog box appears asking if you want to read the release notes. Click Yes to read the notes.You’ll notice that this is the TSAC Web package that’s included with Windows XP.

Publishing the TSAC Web Server You publish the TSAC Web server in the same way you publish any other Web server. You can even publish the TSAC site as an SSL site to make the connection secure. You’ll want to use SSL if you require authentication to access the TSAC Web site. If you do publish the TSAC Web site as an SSL site, we recommend that you use only basic authentication to allow the widest range of clients to access the site and have fewer compatibility issues.You don’t have to worry about credentials being passed in clear text over the Internet, because SSL encryption hides the username and passwords. In this example, we’ll publish a TSAC site that allows access to domain admins over a plain HTTP connection. Later in this chapter, we’ll review procedures for publishing SSL sites. www.syngress.com


277

The TSAC site can be published using either Web or server publishing rules. In this example, we’ll use Web publishing rules because they allow a higher level of security than server publishing rules do. Perform the following steps to publish the TSAC site: 1. Open the ISA Management console. Expand your server name and then expand the Policy Elements node. Right-click on the Destination Sets node, point to New, and click Set. 2. In the New Destination Set dialog box (Figure 5.9), type TSAC Web in the Name text box.Type in a description—for example, Destination Set for the TSAC Web site—in the Description text box. Click Add. Figure 5.9 Creating the TSAC Destination Set

3. In the Add/Edit Destination dialog box, enter the FQDN that external network users will use to access the TSAC Web site (Figure 5.10).This FQDN must resolve to the IP address you are using for the Incoming Web Requests listener that will accept requests for the TSAC Web site.This is not the name of the server on the internal network. In the Path text box, enter /tsweb*.The Web Proxy service uses this path to redirect the request to the appropriate Web server on the internal network.The wildcard at the end of the path indicates that requests for the tsweb folder and all subfolders of the tsweb folder will be accessible via this set. Be aware that users will need to type in the full path, including /tsweb. ISA Server will not allow you to redirect from one path to another.Whatever path is included in the URL the external users send in the request must be available on the destination TSAC server on the internal network. Click OK. 4. Click OK in the New Destination Set dialog box.

www.syngress.com

278


Figure 5.10 Entering the FQDN and Path for the Destination Set

As is the case for all publishing rules, you must be sure to include an entry in your public DNS that resolves the FQDN used in the destination set. In our current example, we would put an entry for tsweb.internal.net in our public DNS.You should also consider putting the same entry in your private DNS if you want the site accessible to internal and external network clients. If you do, make sure you have configured a split DNS infrastructure.You can get more information on configuring a split DNS infrastructure at www.isaserver.org/pages/article.asp?id=995. Now that the destination set is in place, you can create the Web publishing rule: 1. Open the ISA Management console and expand your server name. Expand the Publishing node and right-click on the Web Publishing Rules node. Point to New and click Rule. 2. On the Welcome to the New Web Publishing Rule Wizard page, type in the name of the rule in the Web Publishing rule name text box. In this example, we’ll call the rule TSAC Web site. Click Next. 3. On the Destination Sets page (Figure 5.11), select the destination set you created for the TSAC Web site. Click Next. Figure 5.11 Selecting the TSAC Site Destination Set

www.syngress.com


4.

279

On the Client Type page, select the client type appropriate for your organization. If you want everyone to access the site, select Any request.You can limit access to specific computers using a client address set by selecting Specific computer (client address sets) and assigning a client address set.This would be most useful if you wanted to restrict access to a particular partner, or limit access to a group of administrators.You can also control access to this site with user/group-based authentication by selecting the Specific users and groups option. Users will need to enter credentials and authenticate with the ISA server before they access the site when you select this option.The users do not authenticate with the TSAC Web server.This allows you to offload authentication processing from the Web server to the ISA server. In this example, we’ll enforce security by limiting access to the rule by specific users and groups. Select the Specific users and groups option and click Next.

5. In the Users and Group dialog box (Figure 5.12), click Add. Select the user or group you want to have access to this Web publishing rule. In this example, we’ll select the Domain Admins group. Click OK and then click Next in the Users and Groups dialog box. Figure 5.12 Configuring Authentication Requirements for the Web Publishing Rule

6. In the Rule Action dialog box, select the Redirect the request to this internal Web server (name or IP address) option.Then, type in the name of the server on the internal network. In this example, we will use the same name the user on the external network uses to access the server.This allows the same name to appear in the Web Proxy logs and makes analysis of the Web Proxy logs much easier, as the redirect is to the same name the user is accessing via the browser. If you use the same domain name for internal and external resources, you can create a split DNS infrastructure. If you do not

www.syngress.com

280


want to, or cannot, create a split DNS infrastructure, you can use a HOSTS file on the ISA server and map the name you use for the redirect to the server on the internal network. For example, we will redirect the request to tsac.internal.net.This is the same name the external users use to access the server and in this example it resolves to 192.168.1.33 on the external interface of the ISA server.When the ISA server redirects the request, it will resolve tsac.internal.net to 10.0.0.2 because we put an entry in the HOSTS file on the ISA server to map tsac.internal.net to the internal IP address for the server. When you do it this way, you don’t have to worry about sending the original host header to the server, because the host header won’t be changed! Click Next to continue. 7. Click Finish on the final page of the wizard to complete the rule. When users access the published TSAC Web site, they’ll be asked for credentials.

Publishing the Terminal Server The next step is to publish the Terminal server. Remember that if you are running Terminal Services on the ISA server, you need to either disable Terminal Services, or configure the Terminal server to listen only on the internal interface. If you don’t, you’ll end up with port contention after creating the server publishing rule. Perform the following steps to publish a Terminal server: 1. Open the ISA Management console. Expand your server name and then expand the Policy Elements node. 2. Right-click on the Protocol Definitions node, point to New and click Definition. 3. On the Welcome to the New Protocol Definition Wizard page, type RDP Server for the Protocol Definition name and click Next. 4. On the Primary Connection Information page, type 3389 for the Port number and change the Direction to Inbound. Click Next. 5. The RDP does not use secondary connections, so select No and click Next. 6. Click Finish on the Complete the New Protocol Definition Wizard page. 7. Expand the Publishing node in the left pane of the ISA Management console. Right-click on Server Publishing Rules, point to New and click Rule. 8. On the Welcome to the New Server Publishing Rule Wizard page, type TSAC Terminal Server in the Server publishing rule name text box and click Next.

www.syngress.com


281

9. On the Address Mapping page, type in the IP address of the Terminal server on the internal network in the IP address of internal server text box. Click Browse and select the IP address on the external interface of the ISA server that you want it to listen on for Terminal Services requests. Note that the external IP address does not have to be the same as the one you used for your Incoming Web Requests listener, and the internal server does not have to be the same server as the Web server publishing the TSAC Web site.The TSAC Web site connection and the Terminal Services client connection are two completely different sessions. Click Next. 10. On the Protocol Settings page, select the RDP Server protocol definition. Note that protocol definitions with a primary connection set as inbound are shown here. No protocol definitions with a primary connection as outbound will show up. Click Next. 11. On the Client Type page, decide whether you want to allow all external hosts to connect to the Terminal server, or if you want to limit access to hosts contained in a client address set. For security reasons, you should limit which hosts can connect to the Terminal server via the RDP server publishing rule. Note that in order to control what computer can access the server publishing rule, ,you’ll have to enable packet filtering. Packet filtering is enabled by default, but you should double check to ensure that it hasn’t been disabled. Select the Client address sets specified below option and click Next. 12. On the Client Sets page, click Add. Select the client address set you created for the Terminal Services clients and click Add. If you haven’t created a client address set for users who need access to the Terminal server, you’ll need to back out of the Server Publishing Rule Wizard and create the client address set. If the Terminal server you’re publishing will be accessed by users with dynamic addresses assigned to them, you will not be able to use client address sets for access control.The client address set will appear in the Include these sets frame. Click OK. 13. Click Next on the Client Sets page. 14. Click Finish on the Completing the New Server Publishing Rule Wizard page.

Connecting to the TSAC Web Site and the Terminal Server You can now connect to the TSAC Site and Terminal Server using Internet Explorer. Go to an external network client and perform the following steps: www.syngress.com

282


1. On the external network client, open Internet Explorer.Type the FQDN and path to the Terminal Services Web site. In our example, we’ll type http://tsac.internal.net. 2. You will need to authenticate against the ISA server to access the TSAC Web site.We configured the Web publishing rule so that only authenticated users can access the TSAC Web. Enter your credentials into the log on dialog box (Figure 5.13), and click OK. Figure 5.13 Entering Credentials to Access the TSAC Web Site

3. After you successfully authenticate, the TSAC Web page appears and then the Security Warning dialog box pops up asking if you want to install the Remote Desktop ActiveX Control (figure 5.14). Note that if the Web browser is configured to block ActiveX controls, the TSAC client software will not work. Click Yes to install the client software. Figure 5.14 The Security Warning Dialog Box

4. The client software installs, but it won’t give you any indication of when installation was complete. Give it a few seconds to finish installation, and then type in an FQDN that resolves to the IP address on the external interface of the ISA server you used in the TSAC Web server publishing rule.You can also enter the public IP address. If the external IP address you used in the server publishing rule is the same IP address used by the Incoming Web Requests listener for the Web publishing rule used to access the TSAC Web site, users can www.syngress.com


283

type in the same FQDN they used to access the Web site in the Server text box. Select the size of the display and click Connect (Figure 5.15). Figure 5.15 The Remote Desktop Web Connection Page

5. Once you connect, a Terminal Service session runs within the browser window. If you connected using the Full Screen option, you’ll see something like what appears in Figure 5.16. Figure 5.17 shows the Terminal Services session as it appears in the browser window. Figure 5.16 The TSAC Terminal Services Session Running in Full Screen Mode

www.syngress.com

284


Figure 5.17 The Terminal Services Session as It Appears in the Browser

That’s all there is to it! Some things to keep in mind when publishing TSAC sites: ■

You can publish multiple Terminal servers and allow users to access all of them from the same TSAC Web page.

■

If you want to publish multiple Terminal servers, you will need a separate IP address for each. Each Terminal Services publishing rule uses one IP address.

■

The Terminal server does not need to be on the same machine as the TSAC Web site.

■

The name or IP address the user enters on the TSAC Web page is the name or IP address used to connect to the external IP address on the ISA server used in the Terminal server’s server publishing rule(s).

■

Make sure you avoid port contention on the external interface of the ISA server. Either disable Terminal Services on the ISA server or configure it to listen only on the internal interface.

Publishing TSAC Sites on an Alternate Port As you learned earlier in this chapter, it might be a good security measure to publish the Terminal server on an alternate port. In the same way, it might be a good security move to publish the Terminal servers that users access via the TSAC Web site on alternate ports.

www.syngress.com


285

The problem is that if you publish the Terminal server on an alternate port, you cannot enter the port number in the Server text box on the TSAC Web page. For example, you might think that if you enter tsac.internal.net:12345 into the Server text box, the RDP request would be directed to TCP port 12345. Unfortunately, this is not the case.The TSAC RDP client ActiveX control will sends requests to TCP port 3389, which is the default RDP server port number. There is a hack you can use if you don’t use the latest TSAC Web software.This requires you to copy the TSWeb files from a Windows XP computer that is preWindows XP Service Pack 1. After you copy those files to the Windows 2000 Terminal Server, you can then make a change to the connect.asp file in the TSWeb folder.This change allows the TSAC Web client ActiveX control to send requests to the alternate port number. While this does work, you might run into major problems if you implement this solution. Microsoft issued a Security Alert regarding a buffer overflow problem with the old TSAC Web client ActiveX control.The fix was to install the patch noted in MS02046 (www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ MS02-046.asp). After installing the patch, users could no longer connect to the old TSAC Web site.You have to upgrade to the current TSAC Web site software to allow the post-fix clients to connect. After you upgrade the TSAC Web server files, your alternate port settings disappear and you cannot regain them. Until this situation is changed, using an alternate port to connect to a Terminal server via the TSAC Web site is a moot point.We’ll keep you updated on this situation if it changes. Make sure to check www.isaserver.org/shinder on a regular basis to read up on ISA Server updates.

Publishing FTP Servers on the Internal Network We get many questions at ISAServer.org regarding FTP server publishing. FTP server publishing is done the same way as other forms of server publishing.There is one important difference between publishing FTP servers and publishing another protocol, such as SMTP.That is that in order to fully support the FTP protocol, the FTP server publishing rules must be able to leverage the FTP protocol definitions created by the ISA server’s FTP access application filter. SMTP is a simple protocol that only requires access to a single TCP port. PORT mode FTP, however, is a complex protocol, where the FTP server must be able to create new outbound connections to the FTP client. Information about the new connection must be tracked by the firewall, and the only way the ISA server can track these secondary connections is with the help of the FTP access application filter. The FTP access application filter monitors communication between the publishing FTP server and the FTP client on the Internet.When the FTP client on the Internet www.syngress.com

286


sends a PORT command to the publishing FTP server, the ISA server intercepts this information and manages opening and closing the appropriate ports. However, in order to do its job correctly, the ISA server needs to use the FTP server protocol definitions created by the application filter.This protocol definition “hooks into” the FTP access application filter and allows the rule to leverage the intelligence built into the filter. Perform the following steps to publish an FTP server on the internal network: 1. Open the ISA Management console. Expand your server name and then expand the Publishing node. Right-click the Server Publishing node, point to New and click Rule. 2. On the Welcome to the New Server Publishing Rule Wizard page, type in a name for the rule in the Server publishing rule name text box. Click Next. 3. On the Address Mapping page (Figure 5.18), type in the IP address of the internal network FTP server in the IP address of the internal server text box.Type the IP address on the external interface of the ISA server that you want to listen for the FTP requests in the External IP address on ISA Server text box. Click Next. Figure 5.18 The Address Mapping Page

4. On the Protocol Settings page, select the FTP Server protocol in the Apply the rule to this protocol drop-down list box. Click Next. 5. On the Client Type page, select either Any request or Specific computers depending on your requirement. Click Next. 6. Click Finish on the Complete the New Server Publishing Rule Wizard. 7. The FTP server needs access to all sites because it needs to make a new outbound connection to the FTP clients sending the inbound request. Create a client address set that contains the IP address of the FTP server, and then www.syngress.com


287

create a site and content rule that allows the FTP server access to all sites and content. 8. Make sure the FTP server is configured as a SecureNAT client.The most common reason for the publishing rule to fail is that the administrator forgot to configure the server as a SecureNAT client. You will be able to connect to the FTP server after you complete the FTP server publishing rule.The publishing server supports both PORT and PASV mode connections because the FTP Server protocol definition plugs into the FTP access application filter. Go to the Protocol Definitions node in the ISA Management console and you’ll see that the FTP Server protocol definition is defined by an Application Filter. If you disable the FTP Access application filter, these FTP protocol definitions won’t work. It’s difficult to make a mistake when publishing FTP sites. However, there do appear to be problems with publishing FTP sites on secondary IP addresses on the external interface of the ISA server. For example, if you have two IP addresses bound to the external interface of the ISA server, and you publish an FTP site on the internal network using a secondary IP address bound to the external interface, the publishing rule might not work. However, this problem was corrected with ISA Server Service Pack 1, and you should not have this issue after installing the service pack. If you have problems publishing FTP sites on secondary addresses, make sure that ISA Server Service Pack 1 is installed. If it isn’t, reinstall the service pack.

ISA SERVER ALERT Although not directly connected to FTP server publishing, there is a problem with PASV mode FTP access from internal network clients when you have multiple IP addresses bound to the external interface of the ISA server. There is an issue with PASV FTP downloads when using Internet Explorer from SecureNAT clients, when the ISA server has multiple addresses bound to the external interface. The workaround for this problem is to disable IP routing in the ISA Server Management console and enable the Routing and Remote Access Service (RRAS). This issue should be addressed with ISA Server Service Pack 2.

Publishing FTP Servers on Alternate Ports Publishing an FTP server on the default port (TCP 21) is easy because the FTP access application filter does the footwork for you. However, when you want to publish an FTP site on an alternate port, the FTP access application filter isn’t going to help you www.syngress.com

288


at all.You need to use the Firewall client on the publishing FTP server to make it work.The publishing server needs to be a Firewall client so that the Firewall client software can work with the firewall service to manage the connections.When the FTP access application filter manages the connections, the client can be a SecureNAT client. The problem is that the FTP access application filter only supports standard FTP port numbers. Do the following to publish an FTP server on an alternate port: 1. Disable the FTP access application filter. 2. Change the listening port on the internal FTP server. 3. Install the Firewall client on the FTP server. 4. Place a wspcfg.ini file in the appropriate folder. 5. Use the credtool.exe file to provide credentials to the Firewall service. 6. Create an “All Open” protocol rule and site and content rule that can be used by the account. The only reason we can see for publishing FTP sites on alternate ports is for “security through obscurity.”This keeps out the weakest of hackers, but a simple port scan by a more sophisticated hacker will allow him to access your FTP site through the alternate port. Another reason to publish an FTP site on an alternate port is to violate the terms of service on your Internet account that prevents you from publishing servers.

Disable the FTP Access Application Filter First, disable the FTP access application filter: 1. Open the ISA Management console, expand your server or array name, and then expand the Extensions node in the left pane of the console. 2. Click on the Application Filters node in the left pane of the console. 3. In the right pane of the console, right-click the Ftp Access Filter entry and click Disable. Choose the option to restart the Firewall Service and click OK. It might take a few moments for the Firewall service to restart.That’s not a problem because you have a few more things to do before publishing starts to work.

Change the FTP Site’s Listening Port The next step is to change the port number the FTP site listens on. 1. On the FTP server, open the Internet Information Services console from the Administrative Tools menu. 2. Expand your server name and right-click on Default FTP Site. Click the Properties command. www.syngress.com


289

3. On the FTP Site tab (Figure 5.19), type the alternate port number you want to use for the site in the TCP Port text box. In this example, we’ll use port number 12345. Click Apply and then click OK. Figure 5.19 Change the FTP Site Listening Port

4. Stop and restart the FTP service by clicking on the Stop and Start control buttons on the Internet Information Services button bar. At this point, the FTP server listens on TCP port 12345.You can confirm this by opening a command prompt on the FTP server and doing a netstat –na | find “:12345”.

Install the Firewall Client Proxy Server 2.0 used the WinSock Proxy client. Since ISA Server is new, they decided to rename the WinSock Proxy client and call it the Firewall client.The WinSock Proxy client and the Firewall client are interchangeable, and you can use either to access both an ISA server and a Proxy Server 2.0 machine. 1. Log on as an Administrator at the FTP server. 2. Click Start and then click the Run command. 3. At the Run dialog box, type \\\mspclnt\setup.exe. Be sure to enter the appropriate name for your ISA server. Click OK. 4. Follow the instructions to install the Firewall client. 5. After installing the Firewall client, restart the FTP server. You don’t have to restart the FTP server after the Firewall client software is installed, but we always feel better when we do.

www.syngress.com

290


Place a wspcfg.ini File in the Appropriate Folder You must create a wspcfg.ini file if you want to bind the appropriate ports on the external interface of the ISA server. Creating Firewall client configuration files is somewhat of a black art. If you have a hard time understanding the entries in these Firewall client configuration files, check out Jim Harrison’s article on the subject. Jim has gone a long way at providing insight into exactly how these Firewall client configuration files work. Jim’s fantastic article on this subject at www.isaserver.org/pages/article.asp?id=236. 1. Open the Windows Explorer and navigate to \WINNT\System32\inetsrv folder. 2. Right-click on an empty area in the right pane of the Explorer, point to New and click Text Document. 3. Double-click on the New Text Document.txt file. 4. Type into Notepad the text appearing in Figure 5.20. Replace the 12345 entry with the alternate port number you want to use. Figure 5.20 Creating the wspcfg.ini File

5. Save the file with the name wspcfg.ini as seen in Figure 5.21. It’s important that you put the quotes around the name. If you don’t, Notepad will append the “.txt” file extension to the filename. Click Save. Figure 5.21 Saving the wspcfg.ini File

www.syngress.com


291

Use the credtool.exe Utility to Send Credentials If you’re using outbound access controls based on user/group membership, you need a way to send credentials to the ISA Server Firewall Service.This is an issue because a server is usually not going to have a logged-on user.You need a way for the FTP service (inetinfo.exe) to send credentials to the ISA server without a logged-on user.You could use client address sets to do this, but the credtool method is a bit cleaner, since you’re going to have to create an “All Open” protocol rule to make this work. First, create an account with a complex password that can be used by the FTP server to authenticate against the ISA server. After you create the account using the Active Directory Users and Computer console, open a command prompt and enter the following information: C:>\Program Files\Microsoft Firewall Client\credtool.exe –w –n inetinfo –c ftpservice INTERNAL mypassword

Make sure you replace ftpservice with the name of an account you created for the FTP service to use. Replace the INTERNAL entry with the NetBIOS name of your Active Directory domain. Replace mypassword with the password you gave to the FTP service’s domain account. If you entered everything correctly, you should see something like what you see in Figure 5.22. Figure 5.22 Using the CREDTOOL

Create an “All Open” Protocol Rule The FTP service’s user account must have access to all protocols and all sites and content. For the site and content rule, you can use the built-in default. However, if you www.syngress.com

292


disable or change the default rule, make sure the account you created for the FTP service on the publishing server has access to all sites and content.This is just part of how the FTP protocol works.This allows outbound access to all outbound port numbers to the FTP service when creating secondary connections. 1. Open the ISA Management console, expand your server or array name, and expand the Access Policy node. 2. Right-click on Protocol Rules, point to New and click Rule. 3. On the first page of the wizard, type in the name of the rule—we usually call it All Open. Click Next. 4. Set the Rule Action as Allow and click Next. 5. Set the Protocols for All IP traffic and click Next. 6. Set the Schedule for Always and click Next. 7. For the client type, select the Specific users and groups and click Next. 8. In the Users and Groups page, click Add. 9. Select your domain name in the Look in drop-down list box.Then, doubleclick on the username in the list box (Figure 5.23). Click OK, and then click Next. Figure 5.23 Adding the User Account

10. Click Finish on the last page of the wizard. That’s it! Restart the FTP server and let’s have some fun.

Testing the Configuration After restarting the FTP server, go to the ISA server, open a command prompt, and run a netstat –na | find “:12345”.You should see something like Figure 5.24. www.syngress.com


293

Figure 5.24 The FTP Server Listening on the Alternate Port

Now we know that the FTP server was able to bind TCP 12345 on the ISA server. It looks like it has bound that port on all interfaces.This is the socket pooling issue raising its head again.This isn’t a problem, since the FTP server is a unihomed server. Note that this does not pose a problem, because we’re not creating a server publishing rule. If we needed to create a server publishing rule, we would end up with a port contention problem. Go to an external network client and open an FTP session using the Windows 2000 command-line ftp application.You should be able to connect using PORT mode and get a directory listing (Figure 5.25). Figure 5.25 Testing the FTP Server

www.syngress.com

294


How about some big fun? Configure Internet Explorer to use PASV mode. In IE 6.0, you have to configure the browser’s Advanced Properties to use PASV mode (Figure 5.26). Figure 5.26 Configure Internet Explorer 6.0 to Use PASV Mode

Now enter the FTP site information into the address bar (Figure 5.27), and you should be able to access the site using PASV. Figure 5.27 Connecting to the FTP Using PASV Mode

Tips on Configuring FTP Publishing Publishing an FTP server on an alternate port might sound easy. It is in a way, but nothing comes both fast and easy in this business.When testing your configuration, you might want to reset the communication between the FTP server and the ISA server if you find you’re having problems.You don’t need to restart the FTP server to reset the Firewall client connection.Try this: 1. Stop the Firewall service 2. Restart the Firewall service www.syngress.com


295

3. Stop the FTP service on the FTP server 4. Restart the FTP service on the FTP server Confirm that the FTP server is communicating with the ISA server by using the ISA Management console’s Sessions node (Figure 5.28). Figure 5.28 Confirming the FTP Server’s Link with the ISA Server

You should see SYSTEM as the account name and the name of the computer in the Firewall Session entry. Note that the User Name isn’t correct.The User Name is listed as SYSTEM instead of the actual user name you configured in the CREDTOOL. However, when you see that SYSTEM is connected to the ISA server, the FTP server publishing rule using the Firewall client and the wspcfg.ini file is working.

Publishing FTP Servers Co-Located on the ISA Server Cash-strapped organizations often need to run server services on the ISA server itself. As you know, this isn’t the optimal way to make services available to Internet users because you expose the ISA server machine to exploits carried out against services running on the ISA server computer. However, if you have just a single server to do all the work, then you must put your public services on the ISA server. FTP is probably the least secure of all Internet protocols, and it’s the server that we would least like to put on the ISA server. However, if you want to run an FTP server on the ISA server, you can publish it as you do any other service on the ISA server, by using packet filters or server publishing rules. www.syngress.com

296


Packet filters open the required port directly to the Internet, while server publishing rules allow you to leverage the FTP access application filter to publish the FTP site. Let’s go over the packet filter method first, and then discuss the Server publishing method.

Method One: Creating Packet Filters Packet filtering should always be enabled.The only time where packet filtering might be disabled is when the ISA server is acting as a unihomed Web caching server on the internal network, or when the ISA server is on the edge of a departmental LAN that connects to a trusted corporate backbone. Packet filtering is the cornerstone of ISA Server’s firewall security. If you have an interface directly exposed to the Internet, you must have packet filtering enabled. You can create packet filters to allow external network users access to an FTP server located on the ISA server itself.This method doesn’t require server publishing rules.The packet filters open ports required for PORT and PASV mode FTP clients. To create the packet filters: 1. Open the ISA Management console. Expand your server and then expand Access Policies. Right-click IP Packet Filters, click New, and then click Filter. 2. In the Welcome page of the wizard, name the filter FTP Port 21 and click Next. 3. On the Filter Mode page, select the Allow packet transmission option and click Next. 4. On the Filter Type page, select the Custom option and click Next. 5. On the Filter Settings page, match the settings as shown in Figure 5.29.The IP Protocol is set for TCP.The Direction is Inbound.The Local Port is Fixed Port, and the Port number is 21.The Remote Port is All ports. Click Next. Figure 5.29 Configuring FTP Packet Filters

www.syngress.com


297

6. On the Local Computer page, select either the Default IP addresses for each external interface on the ISA Server computer option, or the This ISA Server’s external IP address option, depending on whether you have more than one IP address bound to the external interface of the ISA server. Click Next. 7. On the Remote Computers page, select the All remote computers option if you want all computers to be able to access the FTP server, or select the Only this remote computer option if you want only a single external computer to access the FTP server. Click Next. 8. Confirm your settings on the final page of the wizard. If everything looks good, click Finish. 9. Repeat the process. However, for step 1 call it FTP Port 20, and for step 5, you should make the selections as shown in Figure 5.30.The Direction is Outbound and the Local Port is 20. Figure 5.30 Configuring the FTP Server Packet Filter

These packet filters only support PORT mode FTP clients.The reason is that PASV mode requires that the FTP client be able to connect to any ephemeral port on the ISA server.This would obviate your packet-filtering security mechanism. PASV mode FTP servers managed with packet filters are a special problem and they should be located only on DMZ segments, where the low security based on packet filtering is acceptable. To see how what happens with PASV Mode packet filters, perform the following steps to create packet filters to support PASV Mode clients: 1. Open the ISA Management console, expand your server name, and expand the Access Policies node. Right-click on IP Packet Filters, point to New and click Filter.

www.syngress.com

298


2. On the Welcome to the New IP Packet Filter Wizard page, type in PASV Command Channel in the IP packet filter name text box. Click Next. 3. On the Filter Mode page, select Allow packet transmission and check Next. 4. On the Filter Type page, click the Custom option and click Next. 5. On the Filter Settings page, the IP Protocol is set for TCP.The Direction is Inbound.The Local Port is Fixed Port and the Port number is 21.The Remote Port is All ports. Click Next. 6. On the Local Computer page, select the appropriate entry. In this example, we’ll select Default IP addresses for each external interface on the ISA Server computer, and click Next. 7. On the Remote Computers page, select All remote computers and click Next. 8. Review your settings and click Finish on the Completing the New IP Packet Filter Wizard page.This completes the packet filter for the FTP command channel. 9. You now need a packet filter to support the data connection. PASV mode clients must establish a second connection to the FTP server on a high port number, and the FTP client must be able to receive the data on a high port. Right-click on the IP Packet Filters node, point to New and click Filter. 10. On the Welcome to the New IP Packet Filter Wizard page, type PASV Data Channel in the IP packet filter name text box and click Next. 11. On the Filter Mode page, select the Allow packet transmission option and click Next. 12. On the Filter Type page, select the Custom option and click Next. 13. On the Filter Settings page (Figure 5.31), make the IP protocol TCP.The Direction is Inbound.The Local port is set for Dynamic and the Remote port is set to All ports. Click Next. 14. On the Local Computer page, select the Default IP addresses option and click Next. 15. On the Remote Computers page, select the All remote computers option and click Next. 16. Review your settings and click Finish on the New IP Packet Filter Wizard page.

www.syngress.com


299

Figure 5.31 The PASV Mode Data Channel Packet Filter

The PASV Mode data channel filter leaves the ISA Server wide open.You’re allowing inbound access to all high-number ports and allowing the ISA server to accept those requests to high-number ports from all port numbers.This is what we’re referring to when we say that the FTP protocol is inherently unsecure. If you must run an FTP server on the ISA server, you should limit access to PORT mode FTP clients only.

Method Two: Server and Web Publishing Rules The second method you can use to publish an FTP server is server publishing or Web publishing rules.The nice thing about doing it this way is that you can have PASV mode clients connect to the FTP server; the FTP access application filter takes care of connection management. Using a server publishing rule that leverages the FTP access application filter allows you to avoid creating wide-open packet filters that put your ISA server at significant risk.

Step 1: Disable Socket Pooling for the FTP Service First you need to disable FTP service socket pooling.The FTP service listens on all IP addresses when socket pooling is enabled, even if you configured the service to listen on a single IP address in the Internet Information Service console.While socket pooling is a good thing on a unihomed server on the internal network, it’s a very bad thing on a multihomed firewall. Perform these steps to disable socket pooling for the FTP service: 1. Open a command prompt and navigate to the \Inetpub\Adminscripts\ folder. 2. Type net stop msftpsvc and press Enter. 3. Type in the following command and press Enter: cscript adsutil.vbs set msftpsvc /disablesocketpooling true

www.syngress.com

300


You should see what appears in Figure 5.32. Figure 5.32 Disabling FTP Service Socket Pooling

4. At the command prompt, type net start msftpsvc and press Enter. 5. Now let’s run netstat –na again.You should see what appears in Figure 5.33. Figure 5.33 The FTP Service Listens on a Dedicated Address

6. Notice that TCP port 21 is now listening on 10.0.0.1 and not on 0.0.0.0. No more socket pooling for Port 21! We’re almost ready to publish the FTP service using a server publishing rule and pointing to the internal IP address of the ISA server (which in this case is 10.0.0.1).

Step 2: Configure the FTP Service to Listen Only on the Internal Interface The default setting for the FTP service is to listen on all IP addresses, even after socket pooling is disabled.You need to go into the Internet Information Services console and configure the service to listen on the internal IP address only.You use this interface in your server publishing rule. www.syngress.com


301

1. Open the Internet Information Services console from the Administrative Tools menu. 2. Right-click on the default FTP Site and click Properties. 3. In the Default FTP Site Properties dialog box, you will see what appears in Figure 5.34. Actually, you won’t see what appears until you click the Down arrow in the TCP Port drop-down list box. Note that there are two IP addresses on this particular computer, one for the internal and one for the external interface.We’ll select 10.0.0.1 to have the FTP service listen on that IP address only. After making the selection, click Apply and then click OK. Figure 5.34 The FTP Service Listens on a Dedicated Address

4. After making these changes, stop the FTP service and restart it.

Step 3: Disabling the FTP Port Attack Setting Some FTP server implementations allow a PORT command to open a connection between the FTP server and an arbitrary port on another machine.This allows the attacker to establish connections to arbitrary ports on machines other than the actual source machine. By default, IIS 5.0 prevents this from happening and blocks connections from machines other than the client that initiated the connection. However, since the ISA server needs to act on behalf of the source host, we have to disable this mechanism. Disabling this IIS mechanism does not open the server to attack, because the ISA server publishing rule protects the server. For more information on the “bounce” attack, check out www.cert.org/advisories/ CA-1997-27.html.The link at the CERT site also contains more detailed information on how IIS blocks this type of attack.

www.syngress.com

302


We need to disable the Port Attack protection provided by the IIS to make the FTP server publishing rule work. Perform the following steps to disable the Port Attack setting: 1. Open Regedt32 and drill down to the following key (Figure 5.35): HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msftpsvc\ Parameters\

Note that the default setting is 0. Figure 5.35 Disabling the EnablePortAttack Entry

2. Change the EnablePortAttack value to 1. 3. Close Regedt32 and restart the FTP service.

Step 4: Create the Publishing Rule The last step is creating the server publishing rule.You can use either the Web Publishing Wizard or the Server Publishing Wizard.The advantage of the Web Publishing Wizard is that you can publish multiple FTP servers using a single IP address on the external interface of the ISA server. If you use the Server Publishing Wizard, you can only publish a single FTP server (using TCP Port 21) per IP address.We’ll look at how to use the Web Publishing Wizard to securely publish an FTP site later in this chapter. In this example, we’ll use the Server Publishing Wizard.

www.syngress.com


303

1. Open the ISA Management console, expand your server, and then expand the Publishing node. Right-click on Server Publishing Rules, point to New, and then click Rule. 2. On the Welcome page, type a name for the FTP server publishing rule and then click Next. 3. On the Address Mapping page, type in the IP address of the internal interface of the ISA server in the IP address of internal server text box, and the IP address of the external interface in the External IP address on ISA Server text box, as shown in Figure 5.36.Then, click Next. Figure 5.36 The Address Mapping Page

4. On the Protocol Settings page, select the FTP Server protocol. Click Next. 5. On the Client Type page, select either the Any request or the Specific computers option, depending on whether you want to limit access to a specific set of computers. In this example, we’ll choose the Any request option. Click Next. 6. On the last page of the wizard, confirm your settings and click Finish.

ISA SERVER DEFCON1 There is an interesting limitation you’ll notice when publishing an FTP server on the ISA server. Server publishing rules are often used instead of Web publishing rules in order to preserve the original IP address of the client making the request in the FTP log. When you publish the FTP server located on the ISA server using server publishing rules, you’ll always see the source IP address as 127.0.0.1. There is no way to change this behavior. If you need the source IP address in the FTP service logs, you’ll have to use packet filters to publish the FTP server.

www.syngress.com

304


Your FTP server is now ready to accept connections. If things don’t work, check the status of the FTP access application filter.This filter is enabled by default. However, you might have disabled it and forgot to re-enable it. If it is disabled, enable it.The FTP access application filter is required to publish an FTP server.

Using Web Publishing Rules to Allow Secure FTP Access One limitation to FTP service publishing is that you must use basic authentication. There is no option to allow integrated or certificate authentication with the FTP site. Another limitation is that you can’t secure the information contained in the data stream.The information transferred from the FTP server to the FTP client is sent in the clear.While there is an implementation of FTP referred to as “secure FTP,” it requires third-party software and is very difficult to make work across a firewall. You can get around the FTP server’s security limitations by using Web publishing rules to publish FTP servers. ISA Server allows you to publish FTP servers on the internal network using Web publishing rules and protocol redirection.The incoming requests are made to the Web Proxy service as HTTP requests, and are then forwarded to the published server as FTP requests.The Web Proxy service receives the information from the FTP server and returns the data via HTTP to the requesting host. The Incoming Web Requests listener accepts basic, integrated, and digest authentication.You can also require SSL for the connection between the client and ISA Server. When the external network client makes the request to the FTP server via HTTP, you can require integrated authentication and use SSL to protect the data moving between the client and server. Alternatively, you can use basic authentication and increase compatibility.You remain secure as long as the basic authentication credentials are protected by an SSL tunnel. You need to address the following issues when using Web publishing rules to securely publish an FTP server on the internal network: ■

Configure the Incoming Web Requests listener to support your preferred authentication method

■

Configure the Incoming Web Requests listener to support SSL connections

■

Create the destination set for the FTP server

■

Create the Web publishing rule

Configuring the Incoming Web Requests Listener Web publishing rules depend on an Incoming Web Requests listener.The Web Proxy service accepts incoming requests for Web publishing rules on the port on the external www.syngress.com


305

interface of the ISA server used by the Incoming Web Requests listener.The default setting for the Incoming Web Requests listener is TCP port 80. The first thing you need to do is configure the Incoming Web Requests listener to support the type of authentication you require, and enable the SSL port on the listener. Perform the following steps to configure the Incoming Web Requests listener: 1. Open the ISA Management console and right-click on your server name. Click the Properties command. 2. In the server Properties dialog box, click on the Incoming Web Requests tab. Select the Configure listeners individually per IP address option. Click Add. 3. In the Add/Edit Listeners dialog box (Figure 5.37), select your server name in the Server drop-down list box. Select an external IP address in the IP Address drop-down list box.Type a name for the listener in the Display Name text box. In the Authentication frame, you have a choice of authentication protocols. Put a check mark in the check box for the protocol you want to support. If you choose to support basic or digest authentication, make sure you click the Select domain button and enter the default domain.This greatly simplifies things for your users who might not know what domain they belong to. Just make sure that the default domain is your user domain and your users will never need to enter a domain name. If your user domain is a trusted domain, then check out Microsoft KB article Q319367 “How to Automatically Authenticate Users Against Trusted Domains.”You also enter the certificate information used by this listener if you want to enable SSL on this specific listener. Each Incoming Web Requests listener supports one certificate. We will cover details of SSL communications later in this chapter. Click OK. Figure 5.37 Configuring Authentication Methods on the Web Requests Listener

www.syngress.com

306


4. On the Server Properties dialog box, click on the Incoming Web Requests tab (Figure 5.38) and put a check mark in the Enable SSL listeners check box.This causes the Incoming Web Requests listener to start listening for SSL requests on TCP port 443. Note that you might run into an issue with port contention if the W3SVC is enabled on the ISA server and you have assigned a certificate to the default Web site and configured it to use TCP port 443 to accept SSL connections.To prevent socket pooling for these SSL connections, you will need to disable socket pooling for “securebindings.”We’ll cover this issue later in this chapter. Click Apply.You’ll see the ISA Server Warning dialog box. Select the option that works best for you, and click OK. Figure 5.38 Configuring an SSL Listener

Creating the Destination Set for the FTP Site As is true for all Web publishing rules, you need to create a destination set to use in the Web publishing rule. Perform the following steps to create the destination set: 1. Open the ISA Management console, expand your server name. and then expand the Policy Elements node. Right-click on Destination Sets, point to New, and click Set. 2. In the New Destination Set dialog box, type in a name for the set in the Name text box.Type in a description for the set and then click Add. 3. Select the Destination option button and type in the FQDN external users type into their browser to access the FTP site. Keep in mind that external users access the FTP site using HTTP, so they will not use an FTP client application to access the FTP site.You do not need to enter a path. Click OK. 4. Click OK in the New Destination Set dialog box. www.syngress.com


307

Publishing the FTP Site with a Web Publishing Rule The Web publishing rule uses the destination set you configured for the FTP site.We will first go through the Web Publishing Wizard to create the rule, and then we’ll go through the Rule’s Properties dialog box to fine-tune the redirection. 1. In the ISA Management console, expand your server name and then expand the Publishing node. Right-click on Web Publishing Rules, point to New, and click Rule. 2. On the Welcome to the New Web Publishing Rule Wizard page, type in the name for the rule. In this example, we’ll call it FTP Server. Click Next. 3. On the Destination Sets page, select the Specified Destination Set option from the drop-down list box. Select the name of the destination set you created for the FTP server publishing rule in the Name drop-down list box. Click Next. 4. On the Client Type page, select the option that applies to the clients you want to support. In this example, we want to securely publish the FTP site, so we’ll select the Specific users and group option. Click Next. 5. On the Users and Group page, click Add. In the Select Users or Groups dialog box, select the users or groups that you want to allow access to the site. Click OK. Click Next in the Users and Groups dialog box. 6. On the Rule Action page (Figure 5.39), select the Redirect the request to this internal Web server (name or IP address) option.Type in the IP address of the internal Web server. If you want to improve the relevance of your log file’s information, you should create an entry in your internal DNS or on a HOSTS file on the ISA server.This entry resolves the name external users use to access the site to the IP address of the internal FTP server. For example, if external users type in ftp.internal.net to access the external IP address of the ISA server, create a HOSTS file entry on the ISA server that matches ftp.internal.net to the FTP server’s internal IP address. Note that in this dialog box you have the option to redirect the request to an alternate port.This is very handy if you’re publishing multiple FTP servers on the same machine, and you want to use the same IP address on the internal network for all your FTP sites. Just assign each FTP site on the internal server a different port number. Click Next. 7. Review your settings and click Finish on the Completing the New Web Publishing Rule Wizard page.

www.syngress.com

308


Figure 5.39 Configuring the Redirect on the Rule Action Page

8. Double-click on the Web publishing rule you just created. Click on the Bridging tab in the rule’s Properties dialog box. In the Redirect HTTP requests as frame, select the FTP requests option.This will allow the ISA server to redirect the HTTP requests it receives that matches the destination set used by this rule to be forwarded as FTP requests to the internal network FTP server. Click Apply and then click OK. Now, go to an external network client, open Internet Explorer, and type in the URL to access your published FTP site.You’ll be welcomed by a dialog box where you can enter your credentials (Figure 5.40). Figure 5.40 Logging on to the FTP Site

Enter your credentials, click OK, and you get into the FTP site (Figure 5.41) Not the most exciting FTP site to hit the Internet, but it does demonstrate that you can access the FTP site files via HTTP. Note that the Web Proxy service supports only FTP downloads.You will not be able to upload files to the FTP site when you publish the site using a Web publishing rule. Later in this chapter, we’ll go over how to attach a certificate to the Incoming Web Requests listener and secure the data stream using SSL.

www.syngress.com


309

Figure 5.41 The Published FTP Site

Publishing HTTP and HTTPS (SSL) Servers with Server Publishing Rules One of the main failings of Web publishing rules is that the source IP address is changed to the IP address of the internal interface of the ISA server when the Web Proxy service forwards the request to the publishing server on the internal network. This causes a problem if you need the requesting host’s original IP address recorded in Web or FTP server’s log files.You can solve this problem by using server publishing rules instead of Web publishing rules. You can publish Web servers with server publishing rules.While you won’t have the features provided by the Web Proxy service, you can still publish TCP port 80 like any other port.You can also publish SSL sites on the internal network using server publishing rules. When you use server publishing rules, you can only publish a service one time per IP address. If you choose to publish Web sites using server publishing rules, you will need an IP address on the external interface for each site.The same rule applies to SSL sites. The procedure for using server publishing rules to publish Web sites includes: ■

Configuring the Incoming Web Requests listener to prevent port contention

■

Creating an HTTP server protocol definition (an HTTPS server protocol definition is included with the default ISA Server installation)

■

Creating the server publishing rule to publish the Web site

www.syngress.com

310


Configuring the Incoming Web Requests Listener to Prevent Port Contention You can use a server publishing rule to publish Web Servers on the internal network via TCP port 80, but you have to avoid port contention on the external interface. Running the IIS W3SVC on the ISA server can cause port contention on the external interface if you don’t disable socket pooling.The Incoming Web Requests listener can also cause port contention if it’s listening on the same port number and IP address you want to use for a server publishing rule. Take a look at the Incoming Web Requests listener interface (Figure 5.42).You have two choices: Use the same listener configuration for all IP addresses and Configure listener individually per IP address. If you choose Use the same listener configuration for all IP addresses, the Incoming Web Requests listener listens on TCP port 80 on all addresses bound to the external interface of the ISA server. Figure 5.42 The Incoming Web Requests Listener Interface

Select the Use the same listener configuration for all IP addresses option, and then run netstat –na | find “:80” at the command prompt.You’ll see something like what appears in Figure 5.43. Notice that 192.168.1.33, 192.168.1.34, and 192.168.1.35 are all listening on TCP port 80.These three IP addresses represent the IP addresses bound to the external interface of the ISA server. Socket pooling has been disabled; that’s why you don’t see the machine listening on 0.0.0.0 port 80. There’s no problem allowing the listener to listen on all IP address bounds to the external interface if you’re not using server publishing rules to publish Web sites. www.syngress.com


311

However, if you want to use server publishing rules to publish Web sites, you’ll need to choose the Configure listeners individually per IP address option.When you choose this option, only the IP addresses you explicitly configure as listeners will listen on TCP 80 on the external interface. All other IP addresses will be available for publishing TCP port 80 using server publishing rules. Figure 5.43 TCP Port 80 Listening on All External IP Addresses

You will run into problems if you have only a single IP address bound to the external interface of the ISA server. If the Incoming Web Requests listener is enabled, it will use the only IP address on the external interface of the ISA server to listen on TCP port 80.You won’t be able to create a server publishing rule for a Web site because if you do, you’ll end up with port contention. One option you have is to change the port number that the Incoming Web Requests listener uses. If you change the listener port to TCP port 8888, then TCP port 80 will be free to use for the server publishing rule.The drawback to this approach is that external network users will need to be told what port number you’re using for the listener so that they can enter it in their requests. Another option is to disable all listeners. If you select the Configure listeners individually per IP address option and remove all listeners using the Remove button (or just don’t add any, since by default there are no listeners), then the Incoming Web Request listener won’t listen on any IP addresses. No matter what decision you make, remember that the goal is to prevent port contention on the external interface of the ISA server.

www.syngress.com

312


Create an HTTP Server Protocol Definition ISA Server comes preloaded with many protocol definitions that you can use to create protocol rules.These definitions include those that allow inbound and outbound access. Protocol definitions that have their primary connection set as inbound can be used in server publishing rules.There is a built-in protocol definition for HTTPS server publishing, but there isn’t one for HTTP server publishing. Microsoft didn’t include this protocol definition because they expected you to use Web publishing rules to publish Web sites. You need to create your own HTTP server protocol definition. Perform the following steps to create the HTTP server protocol definition: 1. Expand you server name and then expand the Policy Elements node. Rightclick on Protocol Definitions, point to New, and click Definition. 2. On the Welcome to the New Protocol Definition Wizard page, type in the name of the protocol definition in the Protocol definition name text box. In this example, we’ll call it HTTP (Server). Click Next. 3. On the Primary Connection Information page, type 80 in the Port number text box. Leave the Protocol type as TCP and change the Direction to Inbound. Click Next. 4. Select No on the Secondary Connections page, and click Next. 5. Review your selections and then click Finish on the Completing the New Protocol Definition Wizard page.

Create the HTTP Server Publishing Rule You can now create the server publishing rule to publish the Web site now that the Incoming Web Requests listener is configured and you have a protocol definition to support Web publishing using a server publishing rule. 1. Open the ISA Management console, expand your server name, and then expand the Publishing node. Right-click on Server Publishing Rules, point to New, and click Rule. 2. On the Welcome to the New Server Publishing Rule Wizard page, type in the name of the rule in the Server publishing rule name text box. In this example, we’ll call it Web Server. Click Next. 3. On the Address Mapping page, type in the IP address of the internal network server in the IP address of internal server text box. Click Browse and select the IP address on the external interface of the ISA server that you want to accept connection to the Web server. Click Next. www.syngress.com


313

4. On the Protocol Settings page, select the HTTP (Server) protocol definition in the Apply the rule to this protocol drop-down list box. Click Next. 5. On the client type page, select the client type appropriate for your environment. In this example, we’ll select the Any request option. Click Next. 6. Review your settings and click Finish on the Complete the New Server Publishing Rule Wizard page. Now, go to an external network client and connect to the Web site.The server publishing rule should start working immediately. If it doesn’t, try restarting the Firewall service. If doing so doesn’t fix the problem, check the Event Viewer.The Event Viewer reports problems with server publishing rules. The most common reason for a server publishing rule to fail is port contention on the external interface. Always double check that the IIS W3SVC isn’t trying to use the same port, and that you have configured the Incoming Web Requests listener in a way to avoid port contention.

Publishing pcAnywhere on the Internal Network You can publish pcAnywhere hosts on the internal network using server publishing rules.We’ve noticed a lot of questions and problems with pcAnywhere publishing on the www.isaserver.org Web boards and mailing list. Most of the time, the problems are easy to correct.You just need to follow the instructions in this section. The procedure for publishing a pcAnywhere host on the internal network includes: ■

Creating protocol definitions used by pcAnywhere

■

Creating publishing rules used by pcAnywhere

■

Configuring the pcAnywhere client and server

Let’s go through the process of publishing a pcAnywhere server on the internal network, and then we’ll discuss areas where you might have problems and how to solve those problems. Keep in mind that when we speak of a “pcAnywhere server,” we’re talking about a machine that’s set up to take calls.You’ll be able to connect to the machine from the Internet when we successfully publish the pcAnywhere server.

Creating the pcAnywhere Protocol Definitions pcAnywhere versions 9.x and 10.x use the following protocols for server publishing: ■

TCP port 5631 inbound

■

UDP port 5631 receive send

www.syngress.com

314


TCP port 5632 inbound

■

UDP port 5632 receive send

These protocol definitions all have their primary connections set to inbound. Note that the UDP protocols use “receive” to indicate a primary inbound connection. Perform the following steps to create the pcAnywhere server protocol definitions: 1. Open the ISA Management console, expand your server name, and then expand the Policy Elements node. Right-click on the Protocol Definitions node, point to New, and click Definition. 2. On the Welcome to the New Protocol Definition page, type pcAnywhere 1 in the Protocol definition name text box. Click Next. 3. On the Primary Connection Information page, type 5631 in the Port number text box. Set the Protocol type to TCP and the Direction as Inbound. Click Next. 4. On the Secondary Connections page, select No and click Next. 5. On the last page of the wizard, review your settings and click Finish. 6. Repeat steps 1 through 5. Name the rule pcAnywhere 2. On the Primary Connection Information page, type 5631 in the Port number text box. Set the Protocol Type to UDP and the Direction as Receive/Send. 7. Repeat steps 1 through 5. Name the rule pcAnywhere 3. On the Primary Connection Information page, type 5632 in the Port number text box. Set the Protocol Type to TCP and the Direction as Inbound. 8. Repeat steps 1 through 5. Name the rule pcAnywhere 4. On the Primary Connection Information page, type 5632 in the Port number text box. Set the Protocol Type to UDP and the Direction as Receive/Send.

Creating the pcAnywhere Server Publishing Rules You can now use the pcAnywhere protocol definitions to create the pcAnywhere server publishing rules.You will need four rules, one for each pcAnywhere protocol Definition. Perform the following steps to create the pcAnywhere server publishing rules: 1. Open the ISA Server Management console, expand your server name, and then expand the Publishing node. Right-click on the Server Publishing Rules node, point to New, and click Rule. 2. On the Welcome to the New Server Publishing Rule Wizard page, type pcAnywhere 1 in the Server publishing rule name text box. If you plan to publish multiple pcAnywhere servers on the internal network, you might www.syngress.com


315

want to append the name or IP address of the host on the internal network. Note that the pcAnywhere host on the internal network needs to have a static IP address. Server publishing rules do not support using computer names for redirecting requests to internal network servers. Click Next. 3. On the Address Mapping page, type in the IP address of the internal network pcAnywhere server in the IP address of internal server text box. Click Browse and select the IP address on the external interface of the ISA server that you want to accept calls for the pcAnywhere server on the internal network. Click Next. 4. On the Protocol Settings page, select the pcAnywhere 1 protocol definition in the Apply the rule to this protocol drop-down list box. Click Next. 5. On the Client Type page, select the option that best fits your environment. Keep in mind that if they successfully authenticate, external users will have full access to the pcAnywhere server on the internal network.You should consider using a client address set to control inbound access to this server publishing rule. Note that you can’t limit access to server publishing rules using users and groups. Only Web publishing rules can leverage users and groups. In this example, we’ll use the Any request option and click Next. 6. Review your settings and click Finish. 7. Repeat steps 1 through 6. Name the rule pcAnywhere 2. On the Protocol Settings page, select the pcAnywhere 2 protocol definition. 8. Repeat steps 1 through 6. Name the rule pcAnywhere 3. On the Protocol Settings page, select the pcAnywhere 3 protocol definition. 9. Repeat steps 1 through 6. Name the rule pcAnywhere 4. On the Protocol Settings page, select the pcAnywhere 4 protocol definition. You should be able to connect to the internal network pcAnywhere server soon after creating the last server publishing rule.You can force the new rules to be active by restarting the Firewall service. We’ve tested this configuration using both pcAnywhere and Windows authentication and they both work.You can also use compatibility mode and the default (accelerator enabled) mode. Performance is quite good, but it depends on the speed of the link. File transfer and chat functions also work between the external client and the internal network pcAnywhere server. If you have problems connecting to the pcAnywhere server on the internal network, consider the following:

www.syngress.com

316


Publishing pcAnywhere servers on the internal network requires you to configure the pcAnywhere host on the internal network. If the pcAnywhere host on the internal network isn’t answering, make sure the machine on the internal network is set to host mode.

■

Make sure you’ve configured the pcAnywhere server on the internal network as a SecureNAT client.This is the most common reason for server publishing rule failures.

■

You need one IP address on the external interface of the ISA server for each pcAnywhere server on the internal network.You cannot publish multiple pcAnywhere servers on the internal network with a single IP address on the external interface of the ISA server.

■

Recheck your pcAnywhere protocol definitions. It’s very easy to make a mistake when typing in the port numbers. Make sure the direction of each protocol definition is correctly configured.

■

Recheck your pcAnywhere server publishing rules.You have to create four server publishing rules, and it’s very easy to select the wrong protocol definition when configuring the server publishing rules.

If you have a problem with your pcAnywhere server publishing rules, check for these issues and you’ll likely find the cause of the problem.

Web Publishing Web publishing rules allow you to take advantage of the Web Proxy service’s ability to look at application-layer information in HTTP requests to make decisions on how to handle packets. At the beginning of this chapter, we discussed many features provided by Web publishing rules that aren’t available with server publishing rules.Web publishing rules are the preferred method of publishing HTTP and FTP content on the internal network because they provide a higher level of security. Several things need to be configured before you create a web publishing rule.These include: ■

The Incoming Web Requests listener

■

Destination sets

■

Public DNS entries

■

Private DNS entries

www.syngress.com


317

Incoming Web Request Listeners You must configure an Incoming Web Requests listener before a Web publishing rule can work.While you can create a Web publishing rule without configuring an Incoming Web Requests listener, the rule won’t accept requests.You can configure listeners separately, or you can apply the same configuration to all listeners. Each Incoming Web Request listener listens on a specific IP address on the external interface of the ISA server. By default, there are no incoming Web Requests listeners. As you learned earlier in the chapter, you have the choice to configure all IP addresses on the external interface of the ISA server to use the same settings, or you can configure listeners separately. There are some situations where you must configure listeners separately: ■

Only one certificate can be bound to a particular listener. If you need to support multiple certificates, you will need to create multiple listeners.

■

If you want to support different authentication methods for different publishing rules, you will need to create separate listeners.

■

If you want to use server publishing rules to publish some Web sites, and Web publishing rules to publish other Web sites, you’ll need to create separate listeners

Keep in mind that when you create Web publishing rules, you are not asked what listener you want the rule to use.The listener used by a particular Web publishing rule is determined by the FQDN used in the destination set.When a user types in the URL to access a published Web site, the FQDN in the request resolves to the IP address of a specific Incoming Web Requests listener.The listener accepts the request, and then the Web Proxy service checks for rules containing a destination set entry matching the request. The second most common reason why Web publishing rules will not work is that the Incoming Web Requests listener(s) have not been configured properly.

Destination Sets The most common reason for Web publishing rule failure is that the destination set used in the Web publishing rule is configured incorrectly.The Web publishing rule uses the entries in the destination set and compares them against the URL in the incoming request.The Web Proxy service passes the URL information for the incoming request to the Web publishing rules, and if one of the rules uses a destination set containing matches for the incoming request, the Web publishing rule is activated.

www.syngress.com

318


Destination sets for Web publishing rules need to contain the FQDN (and perhaps that path) that the users on the external network use to access your published Web site. For example, if the user types in http://www.mywebsite.com to access your publishing server, then the destination set must contain an entry for www.mywebsite.com. It’s very common for ISA Server administrators to include the private name of the publishing server in the destination set. For example, suppose the external user needs to type in http://www.mywebsite.com to access the external IP address on the ISA server you’re using for the Incoming Web Requests listener.The name of the server on the internal network is web1.internal.net.The ISA Server administrator enters web1.internal.net into the destination set and uses the destination set in the Web publishing rule.When the incoming request for www.mywebsite.com comes into the Incoming Web Requests listener, the Web Proxy service won’t find a match because the destination set used doesn’t contain www.mywebsite.com; it contains web1.internal.net. You need to create destination sets before you create Web publishing rules.You’ll find when you go through the Web Publishing Wizard that you are not allowed to create a destination set “on the fly.”This would be a fine addition to the next version of ISA Server, and we hope to see this change. Remember that a destination set can contain multiple entries. For example, suppose you run a Web server on the internal network and it houses multiple Web sites. All the sites listen on the same socket (IP address and port number).You configure the Web server to route the requests to the appropriate site using host headers.You can put all the sites in the same destination set and create a single Web publishing rule that forwards requests to all these sites to the same IP address and port number. Just configure the Web publishing rule to send the original host header, and the same header contained in the original request (the one sent by the user) will be sent to the publishing server on the internal network.The publishing server then forwards the request to the appropriate Web site based on host header information.

Public DNS Entries External network users must use FQDNs to access your published Web sites. Destination sets used by the Web publishing rules have FQDNs and sometimes path statements in them. External users won’t be able to access your site if your servers aren’t registered in the public DNS. You might be thinking, “I’ll just put IP addresses in my destination set; then I won’t have to worry about entries in the public DNS.”While you can put IP addresses in the destination set and avoid placing entries in the public DNS, we highly advise against doing so.You lose a great deal of security when you publish using IP addresses, because many Internet worms take advantage of this configuration.

www.syngress.com


319

For example, if you published by IP address, your servers would not have been protected against the Code Red Worm and many of its variants.Those of us who use only FQDNs in our destination sets never had to worry about Code Red because ISA Server protected us via Web publishing rules and FQDNs in the destination sets.

ISA SERVER DEFCON1 Always use FQDNs in your destination sets. Microsoft designed Web publishing rules with the idea that you would use FQDNs in your destination sets. They do not recommend, and do not support, using IP addresses in the destination sets used in Web publishing rules. In addition to the security issues with IP addresses in destination sets, there is a problem with mixing FQDNs and IP addresses in the same destination set. You can avoid this problem by never using IP addresses in your destination sets. You can use a dynamic DNS service such as www.tzo.com if you have a dynamic IP address assigned to your external interface.

The public DNS server can be on your internal network, on your DMZ segment, or be hosted by your ISP or other third parties. It doesn’t matter where the DNS records are located; it just matters that they are available to external network users. Make sure there is a DNS Host (A) record allowing external network users to resolve the name of each server you publish with Web publishing rules, and that the DNS Host (A) entry matches the name included in the destination set used by the Web publishing rule.

Private DNS Entries Internal network users often need to access the same servers that external network users access.While external network users need to access your sites via ISA Server and Web publishing rules, the internal network users should never “loop back” through the external interface of the ISA server. Web Proxy clients allow the Web Proxy service to resolve names for them. If you configure the ISA server to use a DNS server that resolves the FQDN of the server to the external interface of the ISA server, the client ends up looping back through the external interface.You can get around this problem by configuring the ISA server to use a DNS server on the internal network.This internal network DNS server contains the private IP addresses of the servers you’re publishing instead of the public IP addresses. For example, if you’re publishing a server that external network users access via the URL http://www.mystuff.com, you want the DNS server that the ISA server uses to resolve www.mystuff.com to the internal IP address of the server on the internal network.This means that you need to create two DNS zones for the same domain name:

www.syngress.com

320


one zone used by external network users, and a second zone for internal network users. The zone used by internal network users allows internal network clients to access the server through its internal network address. This works great for SecureNAT and Firewall clients; SecureNAT clients directly connect to the server on the internal network, and the Firewall clients see the destination IP address as being on the LAT and send the request directly to the Web server on the internal network.Web Proxy clients don’t use the LAT.You have to use other methods to prevent the Web Proxy clients from looping back through the ISA server to access internal network resources.

ISA SERVER ALERT The Local Domain Table (LDT) is used to control how clients resolve names contained in the table. Firewall and Web Proxy clients typically allow the ISA server to resolve names on their behalf. The client resolves the name instead of the ISA server if the resource is located on the domain in the LDT. It’s important that you configure all internal network clients with the address of an internal network DNS server that can resolve addresses of internal network servers.

One thing you need to do is configure the LDT.The LDT can be used by Web Proxy clients to allow them to resolve names locally instead of allowing the ISA server to resolve the name. Local name resolution only takes place for those servers or domains contained in the LDT.The ability to allow Web Proxy clients to resolve names locally isn’t as important as the ability to configure the Web Proxy client to use direct access for domains on the LDT. Figure 5.44 shows how you configure Web Proxy clients to use direct access to access resources located in domains in the LDT. Figure 5.44 Configuring Direct Access to Internal Site for Web Proxy Clients

www.syngress.com


321

Direct access means that the client bypasses the Web Proxy service to access resources configured for direct access. Since the resources are on the internal network, the machine will be able to directly access these resources. While we’re on the topic of direct access, note that when you configure external domains for direct access, the Web Proxy client will try to use the Firewall client or SecureNAT client configuration to access the resource. It will not use the Web Proxy client configuration; sites configured for direct access bypass the Web Proxy service.

Terminating an SSL Connection at the ISA Server You can publish SSL sites using Web publishing rules.The ISA server terminates the SSL connection at the Incoming Web Requests listener when you use Web publishing rules to publish SSL sites.The ISA server impersonates the secure server on the internal network. The first thing you need to do is get a certificate for the site when you run secure Web sites.You can obtain a Web site certificate from commercial entities such as Verisign and Thawte, or you can use the Microsoft Certificate Server included with Windows 2000 and Windows 2003 Servers. If you want to run a public site, you should use a commercial certificate. Commercial certificates are much easier to work with on public sites because most machines already include the major commercial sites’ enterprise root certificates in their Enterprise Trust List.You should use the Windows 2000 Certificate Server if the secure site is for your own users only. The ISA server needs to be able to impersonate the Web site on the internal network.The ISA server is able to impersonate the secure site on the internal network by presenting the Web site’s certificate to external network clients. In order for the ISA Server to do so, you will need to install the secure site’s certificate into the ISA server’s certificate store.You can attach the certificate to an Incoming Web Requests listener once you install the certificate in the machine’s certificate store. Installing the Web site certificate into the ISA server’s certificate store is very easy to do. However, there seems to be a lot of misunderstanding on how to bring a certificate server online and how to request and assign certificates.To help you implement a simple certificate infrastructure for your published Web sites, we’ll go over how to install a stand-alone root certificate server, an enterprise root certificate server, and how to request a certificate for your Web site from each of these certificate servers.Then we’ll go over how to export the Web site’s certificate and how to import the root server’s certificate into the enterprise trust list of the Web clients that access your Web site.

www.syngress.com

322


Creating a Stand-Alone Root Certificate Server A stand-alone root certificate server is a good choice when you need to assign certificates to machines that are not members of the internal network domain. One of the big advantages of the stand-alone root certificate server is there are a number of certificate templates available via the Web-based enrollment site that are not available when you roll out an enterprise root certificate server. Another reason to implement a standalone certificate server is that you don’t have an Active Directory domain in place. Perform the following steps to install the stand-alone root certificate server: 1. Click Start, point to Settings, and click on Control Panel. 2. In the Control Panel, open the Add/Remove Programs applet. 3. In the Add/Remove Programs applet, click Add/Remove Windows Components in the left pane of the dialog box. 4. In the Windows Components Wizard dialog box, put a check mark in the Certificate Services checkbox. Click Yes in the dialog box that explains that you cannot rename the computer, or join or remove it from a domain, after installing certificate services. Click Next in the Windows Components dialog box. 5. On the Certification Authority Type page (Figure 5.45), select the Standalone root CA option.You do not need to select the Advanced options check box unless you want to use a custom Cryptographic Service Provider (CSP) and specific settings to be used in generating a key pair, or if you want to use an existing key pair.We will not cover those options in this exercise. Click Next. Figure 5.45 Setting the Certification Authority Type

6. On the CA Identifying Information page (Figure 5.46), type in the information requested for each field.The only field required is the CA name. It’s www.syngress.com


323

considered good practice to use the computer name (NetBIOS name) of the server in the CA name field. However, if you want to do certificate mappings and matching based on fields, you should enter the correct information in all fields. In our examples, we won’t be doing any certificate mapping. However, keep in mind that if you want to use client certificates in SSL bridging scenarios, you will need to perform certificate mapping. After entering the information on the CA Identifying Information page, click Next. Figure 5.46 The CA Identifying Information Page

7. On the Data Storage Location page, select the locations where you want to store the Certificate database and Certificate database log.You also have the option to store configuration information in a shared folder. In this example, we’ll use the default locations. Click Next. Click OK in the dialog box warning you that the IIS services must be stopped before continuing. 8. The Certificate Services files are installed.You might be asked for the Windows 2000 CD during the installation, so make sure you have it handy or have the installation files on a network share. 9. Click Finish on the Completing the Windows Components Wizard page.

Requesting a Web Site Certificate from a Stand-Alone Root Certificate Server The Web site can now request a certificate from the stand-alone root certificate server. The Certificate Request Wizard on the Web server won’t be able to directly communicate with the certificate server, so you’ll have to create a certificate request file and then use the Web-based certificate enrollment system to send your certificate request. Perform the following steps to begin the certificate request for your Web site:

www.syngress.com

324


1. Click Start and point to Programs. Point to Administrative Tools and click on Internet Services Manager. 2. Expand your server name in the Internet Information Services dialog box. Right-click on the Web site and click the Properties command. 3. In the Web site’s Properties dialog box, click on the Directory Security tab. In the Secure communications frame, click Server Certificate. 4. Click Next on the Welcome to the Web Server Certificate Wizard page. 5. On the Server Certificate page, select the Create a new certificate option and click Next. 6. On the Delayed or Immediate Request page, select the Prepare the request now, but send it later option.This might be the only option available if there are no enterprise root certificate servers in your organization. Click Next. 7. On the Name and Security Settings page (Figure 5.47), give the certificate a friendly name.The friendly name doesn’t matter in terms of the functionality of the certificate, but it does help you identify what the certificate is used for. Select a Bit length for the certificate.The more bits, the lower the performance.The required number of bits depends on the level of security you desire balanced by the required performance levels. Click Next. Figure 5.47 The Name and Security Settings Page

8. On the Organization Information page, enter your Organization and Organizational unit information.This information is not required. Click Next. 9. On the Your Site’s Common Name page (Figure 5.48), type in the FQDN that users on the external network use to access your published Web server.

www.syngress.com


325

This is an extremely important entry.The common name must be the same as the one you want external users to use to access the site.This is the same name you include in the destination set in the Web publishing rule you use to publish the site. Click Next. Figure 5.48 The Site’s Common Name Page

10. On the Geographical Information page, enter the State/province and City/locality information.This information isn’t required, but you should enter the information just in case you want to leverage this information for certificate mapping in the future. Click Next. 11. On the Certificate Request File Name page, note the default name and location of the certificate request file.You can use this default setting (c:\certreq.txt) in the majority of cases. Make a change if you need to, and click Next. 12. On the Request File Summary page (Figure 5.49), review the settings and click Next. Figure 5.49 The Request File Summary Page

www.syngress.com

326


13. Click Finish on the Completing the Web Server Certificate Wizard page. Click OK in the Web site Properties dialog box. The next step is to take the contents of the certreq.txt file and paste them into the Web enrollment form provided by the stand-alone certificate server. Perform the following steps to obtain the Web server certificate: 1. Open the certreq.txt file you created when you ran the Web server Certificate Wizard. Select the certificate request information that is highlighted in Figure 5.50. Right-click the highlighted area and click the copy command to copy it to the clipboard. Note that selecting the information the way we did in Figure 5.50 works with the Windows 2000/2003 Certificate Server. If you were to send information to a third-party certificate authority, you should send the entire contents of the file, including the BEGIN and END entries at the beginning and end of the certificate request. Figure 5.50 Selecting the Certificate Request Information

2. Open Internet Explorer and type in the URL to the stand-alone certificate server Web site.The URL is http:///certsrv. In our example, the URL is http://webserver/certsrv. 3. On the Welcome page (Figure 5.51), select the Request a certificate option and click Next. 4. On the Choose Request Type page, select the Advanced Request option and click Next. 5. On the Advanced Certificate Requests page (Figure 5.52), select the Submit a certificate request using a base64 encoded PKCS #10 file or a renewal request using a base64 encoded PKCS #7 file option. Click Next.

www.syngress.com


327

Figure 5.51 The Certificate Server Web Site Welcome Page

Figure 5.52 The Advanced Certificate Requests Page

6. On the Submit A Saved Request page (Figure 5.53), paste the certificate request information in the text box. Click Submit. 7. Go to the stand-alone certificate server machine. Click Start and point to Programs. Point to Administrative Tools and click Certification Authority.

www.syngress.com

328


Figure 5.53 The Submit A Saved Request Page

8. In the Certification Authority console (Figure 5.54), expand your server name and click on the Pending Requests node. In the right pane, right-click on the submitted request, point to All Tasks, and click Issue. Figure 5.54 Issuing the Web Site Certificate

9. Return to the Web server and open Internet Explorer.Type in the URL for your stand-alone certificate server’s Web enrollment page. Click on the Check on a pending certificate option. Click Next.

www.syngress.com


329

10. On the Check On A Pending Certificate Request page (Figure 5.55), select the request that appears on the page and click Next. Figure 5.55 The Check On A Pending Certificate Request Page

11. In the Certificate Issued page (Figure 5.56), click the Download CA certificate link to download the CA certificate. Click the Download CA certification path link to download the certification path. Save each of the certificates to the desktop so that you can find them easily. Figure 5.56 Downloading and Installing the Certificate

12. Close Internet Explorer. www.syngress.com

330


The final step is to install the Web server certificate: 1. Open the Internet Information Services console, right-click the Web site, and click Properties. 2. In the Web site’s Properties dialog box, click on the Directory Security tab. In the Secure Communications frame, click Server Certificate. 3. On the Welcome to the Web Server Certificate Wizard page, read the Status of your Web Server information.You’ll see that you have a pending request. Click Next. 4. On the Pending Certificate Request page (Figure 5.57), select the Process the request and install the certificate option. Click Next. Figure 5.57 Processing the Pending Request

5. On the Process a Pending Request page, click Browse and locate the certificate you saved to your desktop.You should see the certnew.cer certificate. Select that one and click Open. Click Next. 6. On the Certificate Summary page (Figure 5.58), review the settings and click Next. Figure 5.58 Reviewing the Settings

www.syngress.com


331

7. Click Finish on the Completing the Web Server Certificate Wizard page. The Web server certificate is now installed on the Web server. Later we’ll see how to export the Web site’s certificate and import the certificate into the ISA server’s machine store.

Creating an Enterprise Root Certificate Server You can create an enterprise root certificate server if you have an Active Directory domain.The advantage of using an enterprise root certificate server is that when your Web server belongs to the same domain as the certificate server, it can send the certificate request directly to the certificate server.You don’t have to save the certificate request to a text file and submit it via the Web interface. Installing the enterprise root certificate server works just about the same as installing the stand-alone certificate server. Perform the following steps to install an enterprise root certificate server: 1. Open the Control Panel and double-click on the Add/Remove Programs applet. 2. Click Add/Remove Windows Components on the left side of the Add/Remove Programs window. 3. Select the Certificate Service check box in the Windows Components window. Click Yes in the dialog box warning you that you can’t rename the server or leave/join a domain. Click Next. 4. Select the Enterprise root CA option and click Next. 5. Fill in the fields in the CA Identifying Information page. Although the only required field is the CA name, you should fill in each text box. Click Next. 6. On the Data Storage Location page, choose where you want to store the Certificate database and Certificate database log. In this example, we’ll select the default locations and click Next. Click OK in the dialog box warning you that the IIS services must be stopped. 7. Click Finish on the last page of the wizard.

Requesting a Web Site Certificate from a Enterprise Root Certificate Server Requesting a certificate from an enterprise root CA is much easier than from a standalone CA. If the Web server belongs to the same domain as the enterprise root CA, information about the CA is stored in the Active Directory, and the Web server will be able to find the CA and request the certificate directly from the enterprise root CA. www.syngress.com

332


Perform the following steps to have the Web site request a certificate from the enterprise root CA: 1. Open the Internet Information Services console and expand your server name. Right-click on your Web site and click the Properties command. 2. In the Web site Properties dialog box, click on the Directory Security tab. Click Server Certificate in the Secure communications frame. 3. Click Next in the Welcome to the Web Server Certificate Wizard page. 4. Select the Create a new certificate on the Server Certificate page. 5. Select the Send the request immediately to an online certification authority on the Delayed or Immediate Request page (Figure 5.59). Click Next. 6. On the Name and Security Settings page, type a friendly name for the Figure 5.59 Sending the Certificate Request Directly to the Certificate Server

certificate in the Name text box. Select a bit length appropriate for the level of security required for your site. Click Next. 7. On the Organization Information page, type in the name of your organization and organizational unit in the Organization and Organizational unit text boxes. Click Next. 8. On the Your Site’s Common Name page, type in the FQDN external users use to access the site.This is the name you will use in the destination set in the Web publishing rule you’ll use to publish the site. Click Next. 9. On the Geographical Information page, type in the State/province and City/locality. Click Next.

www.syngress.com


333

10. On the Choose a Certification Authority page (Figure 5.60), click the Down arrow in the Certification authorities drop-down list box and select the enterprise CA from which you want to obtain the certificate. If you have a single enterprise CA, that name will appear automatically. Click Next. Figure 5.60 Choosing a Certification Authority

11. Review the information on the Certificate Request Submission page and click Next. 12. Click Finish on the Completing the Web Server Certificate Wizard page, and click Finish. The certificate is now installed on the Web server.

Exporting the Web Site Certificate and Importing the Certificate into the ISA Server Certificate Store You need to install the Web site certificate on the ISA server so that the ISA server can impersonate the secure Web site.The Web site’s certificate is installed into the ISA server’s machine certificate store.You can attach the certificate to an Incoming Web Requests listener once the certificate is in the ISA server’s machine store. Getting the certificate into the ISA server’s machine store is a two-step process: first, export the Web site certificate from the Web server, and then import the exported certificate into the ISA server’s machine certificate store. Perform the following steps to export the Web site’s certificate: 1. Open the Internet Services Manager from the Administrative Tools menu. 2. In the Internet Information Services console, right-click on the Web site that contains the certificate you want to export, and then click Properties. 3. In the Web site’s Properties dialog box, click on the Directory Security tab.

www.syngress.com

334


4. On the Directory Security tab, click View Certificate. Click on the Details tab. Click Copy to File.This opens the Certificate Export Wizard. 5. On the Welcome to the Certificate Export Wizard page, read the description of the wizard and what it does, and then click Next. 6. On the Export Private Key page, select the Yes, export the private key option, and click Next. 7. On the Export File Format page, remove the check mark from the Enable strong protection option. If you leave this option checked, you will have to enter information to confirm the certificate usage. Since the Web Proxy service needs to use the certificate in the background, you need to remove the strong protection option. Click Next. 8. On the Password page, type in a password to secure the certificate, and then confirm the password. Don’t forget the password! You’ll be asked for it when you import the certificate into the ISA server’s certificate store. Click Next. 9. On the File to Export page, type in a name for the certificate, such as c:\webservercert in the File name text box.The wizard automatically adds the correct file extension (.pfx). Click Next. 10. On the Completing the Certificate Export Wizard page, confirm that the information is correct and then click Finish. If there are no problems, you’ll see a dialog box informing you that the certificate export was successful. Click OK to dispatch the dialog box. 11. Close the Certificate dialog box and click Cancel in the Web server Properties dialog box. Now we’re ready to import the certificate into the ISA server’s machine store: 1. Copy the exported certificate to the ISA server. 2. Click Start and then click the Run command.Type mmc in the Open text box and click OK. 3. Click the Console menu and then click the Add/Remove Snap-in command. 4. On the Stand-alone tab, click Add in the Add/Remove Snap-in dialog box. 5. In the Add Stand-alone Snap-in dialog box, select the Certificates entry and then click Add. 6. On the Certificates snap-in dialog box, select the Computer account option. It’s important that you select the Computer account option because you want the certificate in the machine’s certificate store.The most common www.syngress.com


335

error ISA Server administrators make is to select the wrong option and import the certificate into the user account’s certificate store. Select the Computer account option and click Next. 7. On the Select Computer page, select the Local computer: (the computer this console is running on) option and click Finish. 8. Click Close in the Add Stand-alone Snap-in dialog box, and then click OK in the Add/Remove Snap-in dialog box. 9. Expand the Certificates (Local Computers) node and then right-click on the Personal node. Point to All Tasks and then click on the Import command. 10. On the Welcome to the Certificate Import Wizard, read the description of what the wizard does and click Next. 11. On the File to Import page, click Browse to find the Web server certificate that you copied to the ISA server. Click Next after selecting the certificate. 12. On the Password page, type in the Password you assigned to the certificate. Put a check mark in the Mark the private key as exportable.This will make your life a bit easier if you need to export the key and use it on another machine. Click Next. 13. On the Certificate Store page (Figure 5.61), select the Place all the certificates in the following store option.The Certificate store should read as Personal. Click Next. Figure 5.61 The Certificate Store Page

14. Read the settings on the Completing the Certificate Import Wizard page and then click Finish. If all goes well, you’ll see a dialog box confirming that the import was successful. Click OK to dispatch the dialog box.

www.syngress.com

336


15. Refresh the display.You should now see the certificate in the list of certificates in the machine’s certificate store (Figure 5.62). Figure 5.62 Certificates Contained in the ISA Server’s Machine Store

16. Minimize the Certificates console and open the ISA Management console. Right-click on your server name and click Properties. 17. On the server’s Properties dialog box, click on the Incoming Web Requests tab. On the Incoming Web Requests tab, select the Configure listeners individually per IP address option, and then click Add. 18. On the Add/Edit Listeners dialog box (figure 5.63), select your server name in the Server drop-down list box. Select an IP address on the external interface of the ISA Server in the IP Address drop-down list box.Type in a short name for the listener in the Display Name text box. Put a check mark in the Use a server certificate to authenticate to web clients check box. 19. On the Add/Edit Listeners dialog box, click Select. In the Select Certificate dialog box (figure 5.64), select the Web server certificate and click OK.The certificate will show up in the Add/Edit Listeners dialog box. Click OK in the Add/Edit Listeners dialog box. 20. Click Apply in the server Properties dialog box. A warning dialog box appears and informs you that the Web proxy service will need to be restarted. Select the option that works best for you, and click OK.

www.syngress.com


337

Figure 5.63 Selecting the Web Site Server Certificate

Figure 5.64 Selecting the Web Site Server Certificate

Now with the certificate attached to the Incoming Web Request listener, you are in the position to securely publish the Web site.You can publish the Web site so that the SSL connection terminates at the ISA Server’s external interface, or you can protect the information using SSL from the client to the internal Web server by forcing an SSL connection between the ISA server and the internal Web site.This is called SSL bridging, which we discuss in the next section.

Bridging SSL Connections ISA Server supports SSL bridging, and can bridge incoming SSL requests in two ways: ■

The incoming SSL request can be bridged as an HTTP request.

■

The incoming SSL request can be bridged as an SSL request.

When ISA Server bridges an SSL request as an HTTP request, the SSL connection is terminated at the Incoming Web Requests listener.The ISA server receives SSL packets, decrypts the packets, and forwards them to the Web server on the internal network as HTTP. SSL protects data between the client and the external interface of the www.syngress.com

338


ISA server; the data is sent “in the clear” between the internal interface of the ISA server and the Web server on the internal network. You might think its safe to send the data between the internal interface of the ISA server and the internal network Web server unencrypted if you trust the internal network. However, if you don’t completely trust the transit network between the ISA server and the Web server, you should protect that data as well. You can protect data moving between the ISA server and the publishing Web server by bridging SSL requests as SSL requests. In this scenario, the Internet client establishes an SSL link with the ISA server’s Incoming Web Requests listener.The data is decrypted by the ISA server after it is received by the listener.Then, the ISA server creates a second SSL connection between the internal interface of the ISA server and the publishing Web server.The data is re-encrypted and sent to the Web server over the secure SSL link. In the following sections, we’ll look at how to bridge the SSL connection as HTTP, and then how to bridge the connection as SSL.

Bridging SSL Connections as HTTP You’re ready to create a Web publishing rule that bridges an SSL connection as HTTP when the Web server’s certificate is bound to the incoming Web Requests listener. Now all that’s left to do is create the Web publishing rule: 1. Open the ISA Management console, expand your server name, and then expand the Policy Elements node. Right-click on Destination Sets, point to New and click Set. 2. Type a name for the set in the Name text box.Type a description for it in the Description text box. Click Add. 3. In the Add/Edit Destination text box, select the Destination option and type in the FQDN for the Web site in the text box. Remember that this is the FQDN the external network users use to access your site.This FQDN must also match the name on the Web site certificate you bound to the Incoming Web Requests listener. Click OK.You’ll see the completed destination set information in Figure 5.65. Click OK to complete the set. Now that the destination set is completed, you’re ready to create the Web publishing rule.To do so, perform the following steps: 1. Expand the Publishing node and right-click on the Web Publishing Rule node. Point to New and point to Rule.

www.syngress.com


339

Figure 5.65 A Completed Destination Set

2. On the Welcome to the New Web Publishing Rule Wizard page, type in a name for the publishing rule in the Web publishing rule name text box. Click Next. 3. On the Destination Sets page, select the Specified destination set option in the Apply this rule to drop-down list box. Select the name of your destination set in the Name drop-down list box. Click Next. 4. On the Client Type page, select the Any request option. Click Next. 5. On the Rule Action page, select the Redirect the request to this internal Web server (name or IP address) option (Figure 5.66). Enter either the IP address or the name of the server on the internal network.We recommend that you create a split DNS infrastructure, or put a HOSTS file entry for the FQDN used in the destination set. Enter that FQDN in the redirect. Using the FQDN in the redirect will make your log files cleaner and prevent the dreaded 14120 error from littering your application log in the Event Viewer.You can choose to send the original host header if you like; it won’t matter if you’re using the same name in the redirect as that contained in the original host header. Click Next. Figure 5.66 The Rule Action Page

www.syngress.com

340


6. Review the settings on the Completing the New Web Publishing Rule Wizard page, and then click Finish. 7. In the right pane of the console, right-click on the Web publishing rule you just created and click Properties. Click on the Bridging tab. In the Redirect HTTP requests as frame, make sure the HTTP requests option is selected. Of course, this selection won’t matter, because we’re going to force SSL connections in this rule. In the Redirect SSL requests as frame, select the HTTP requests (terminate the secure channel at the proxy) option.This allows you to bridge incoming SSL requests as HTTP requests. Put a check mark in the Require secure channel (SSL) for published site check box.This check box forces users to use SSL to connect to the Web site.You can select the Require 128-bit encryption option if your clients support it. Click Apply and then click OK. Go to an external network client and make the connection. If the external network client has a certificate from your CA, and the CA that issued the Web site certificate is in your enterprise trust list, you won’t see anything unusual and you’ll make the connection with the ISA server without incident.You won’t see any warning dialog boxes regarding the nature of the certificate. You’ll see what appears in Figure 5.67 if the client doesn’t have the certificate authority that issued the Web server’s certificate in its enterprise trust list.The error indicates that you don’t trust the CA that issued the Web site’s certificate.This is most commonly seen when you “roll your own” certificate server solution.You can avoid this by assigning user or machine certificates. In the process of obtaining the certificate from the certificate server, the CA you receive the certificate from will be placed in the Trusted Root Certificate Authorities list. If you don’t want to assign certificates to the users or machines, you can copy the certificate server’s certificate into your clients’ Trusted Root Authorities list manually. Figure 5.67 Security Alert Dialog Box Warning of an Untrusted Root Authority

www.syngress.com


341

Another problem you might have is with the name of the certificate. In Figure 5.68, note that everything is okay except that The name on the security certificate does not match the name of the site.This is probably one of the most common errors we encounter when troubleshooting SSL Web publishing rules.You’ll see this if the name on the certificate is not the same as the FQDN used by users to access the Web site.The only fix for this problem is to obtain a new certificate that has a name that matches the FQDN used to access the site.This is why it’s so important that you make the proper entry for the “common name” of the Web site when you make the Web site’s certificate requests. Figure 5.68 Security Alert Dialog Box Warning of a Certificate Mismatch

Bridging SSL Connections as SSL What if you need to protect the data end to end? You might not trust your internal network, so you need to protect the data on the Internet and you need to protect it from the internal interface of the ISA server to the Web site on the internal network. This might be the case when the internal network is actually a private address DMZ segment. In this scenario, the Web publishing rule is configured in very much the same way, except for the choice in the SSL bridging frame. You also have to be mindful of how the Web site is configured, because if it is configured incorrectly, the ISA server will not be able to bridge the request.To successfully bridge SSL connections as SSL connections, you need to do the following: ■

Prepare the Web site for SSL

■

Configure the Web publishing rule

Let’s first look at how to prepare the Web site. If you’re already expert at configuring SSL Web sites, you can skip to the section on how to configure the Web publishing rule. In this example, we’ll assume that you’ve already bound a certificate to the Web site and exported that certificate and bound it to the external interface of the ISA server.

www.syngress.com

342


1. From the Administrative Tools menu, click on the Internet Services Manager link. 2. In the Internet Information Services console, right-click on the Web site you’re publishing and click the Properties command. 3. In the Web site’s Properties dialog box, click on the Directory Security tab. 4. On the Directory Security tab, click Edit.This brings up the Secure Communications dialog box (Figure 5.69). Put a check mark in the Require secure channel (SSL) check box.This requires the ISA server to establish an SSL connection with the Web site. Put a check mark in the Require 128-bit encryption check box if you want to force strong encryption (the ISA server will support it).You can also force the ISA server to use a client certificate to authenticate with the Web site, although this is not required. If you want to force the use of a client certificate, select the Require client certificates option. If you want the option to use a certificate, but allow non-client certificate connections too, select the Accept client certificates option.This option will allows you to use other means of authentication, (other than client certificates).We won’t cover client certificate mapping for Web sites in this chapter, but check www.isaserver.org/shinder for an article on how to do this. For the greatest flexibility, select the Accept client certificates option. Click OK. Figure 5.69 Forcing a Secure Channel to the Web Site

5. Click Apply and then click OK in the Web site Properties dialog box. Click Stop in the MMC button bar, and then click Start in the button bar. If you want to use client certificates to authenticate against the Web server, you’ll need to assign a certificate to the Web Proxy service.The Web Proxy Service will act as the client of the internal network Web server.The funny thing about assigning a

www.syngress.com


343

certificate to the Web Proxy service is that the service can’t directly request a client certificate.What you can do is use the machine certificate by copying it to the Web Proxy service’s machine store. Perform the following steps to assign the machine’s certificate to the Web Proxy service: 1. Click Start and then click Run. In the Run dialog box, type mmc and click OK. 2. In the console window, click the Console menu and click the Add/Remove Snap-in command. In the Add/Remove Snap-in dialog box, click Add. 3. In the Add Stand-alone Snap-in dialog box, select the Certificates entry and click Add. On the Certificates snap-in dialog box, click the Service account option and click Next. 4. On the Select Computer page, select the Local computer option and click Next. 5. On the Select a service account to manage on the local computer page, select the Microsoft Web Proxy entry and click Finish. 6. We need to add a second instance of the Certificates snap-in. Select the Certificates entry and click Add. On the Certificates snap-in page, select the Computer account option and click Next. 7. On the Select Computer page, select the Local Computer option and click Finish. 8. Click Close in the Add Stand-alone Snap-in dialog box. Click OK in the Add/Remove Snap-in dialog box. 9. Expand both of the Certificates nodes in the left pane of the console. Expand the Personal node for both the Local Computer and the W3Proxy services, as shown in Figure 5.70. 10. Click on the Local Computer\Personal\Certificates node. In the right pane of the console, you’ll see the computer certificate. Right-click on your computer certificate and click the Copy command. 11. Click on the Microsoft Web Proxy Service\W3Proxy\Personal\ Certificates node. Click in the right pane of the console. Next, right-click on the right pane of the console and click the Paste command.This pastes the computer certificate into the Web Proxy service’s personal store.

www.syngress.com

344


Figure 5.70 The Web Proxy Service Certificate List

The Web Proxy service now has a certificate it can present to the internal Web server in the event that you configure the Web server on the internal network to require client certificate authentication. The last step is to configure the Web publishing rule to support SSL-to-SSL bridging: 1. In the ISA Management console, expand your server name and then expand the Publishing node. Right-click on the Web Publishing Rules node, point to New, and click New. 2. Type in a name for the rule on the Welcome to the New Web Publishing Rule Wizard page and click Next. 3. On the Destination Sets page, select the Specified destination set option and then select the destination set for your site. Click Next. 4. On the Client Type page, select Any request and click Next. 5. On the Rule Action page, select the Redirect the request to this internal Web server (name or IP address) option, as shown in Figure 5.71.Type in the name of the site, which is the same name on the site certificate and the same name used in the destination set. 6. Click Finish on the last page of the wizard. 7. In the right pane of the ISA Management console, double-click on the new rule. Click on the Bridging tab.

www.syngress.com


345

Figure 5.71 Configuring the Rule Action

8. In the Redirect SSL requests as frame, select the SSL requests (establish a new secure channel to this site) option. Select the Require secure channel (SSL) for published site check box. If you want the ISA server to use a client certificate to authenticate with the Web server, select the Use a certificate to authentication to the SSL Web Server check box. Click Select. You’ll be presented with the Select Certificate dialog box (Figure 5.72).The certificates you see listed in this dialog box are those included in the Web Proxy service’s personal certificate store. Select the certificate and click OK. Figure 5.72 Assigning a Client Certificate for the SSL Bridge

9. The name of the client certificate will appear in the rule’s Properties dialog box. Click Apply and then click OK. Note that you do not need to perform certificate mapping for this to work.You do not need to create a one-to-one or many-to-one certificate mapping; the Web Proxy service will be able present the ISA server’s machine certificate in order to authenticate to the Web site automatically. Go to an external network client and connect to the published Web site.You’ll be able to connect just as you did when you create the SSL-to-HTTP bridging. If

www.syngress.com

346


everything is configured correctly, you won’t see any warning dialog boxes and you’ll have direct access to the site. Just for fun, you might want to confirm that the ISA server is indeed sending a client certificate to authenticate with the Web site. If so, do the following: 1. Configure the Web site to require certificate authentication. Next, go to a client on the internal network that doesn’t have a user certificate installed. What we want to determine is whether the Web site will accept requests from browsers without a certificate. 2. Type http://IPADDRESS of the Web site that requires certificate authentication.The Security Warning dialog box should appear, telling you that the name on the certificate doesn’t match the request (see Figure 5.73).This is expected, since the Web site’s certificate has the FQDN of the site, not its IP address. Click Yes to get past that dialog box. Figure 5.73 Security Alert Dialog Box Warning of a Name Mismatch

3. Internet Explorer pops up a Client Authentication dialog box because the Web site is configured to require client certificates for authentication (Figure 5.74). If your browser had a certificate configured on it, you would see the name of the certificate in this dialog box. Click OK to close the Client Authentication dialog box. Figure 5.74 The Client Authentication Dialog Box

www.syngress.com


347

4. After closing the authentication dialog box, you’ll see the The page requires a client certificate Web page (Figure 5.75). HTTP error 403.7 indicates that you need a client certificate to access the site and that you did not present a certificate and therefore are denied access. Figure 5.75 Error Page Indicating that a Client Certificate Is Required

Secure FTP Connections Using SSL Secure publishing of FTP requires you use Web publishing rules.You can only use the basic authentication protocol when you publish an FTP site using a server publishing rule. In addition, you can’t protect the data using the FTP protocol. The solution is to publish the FTP site using a Web publishing rule.You can configure the Web publishing rule to require an SSL connection and then redirect the SSL link as an FTP request.The FTP server on the internal network receives the request from the ISA server and returns the FTP data to the internal interface of the ISA server.The ISA server encrypts the data and returns it to the client. Note that the client must use a Web browser and the HTTPS protocol to access the secure FTP site via the Incoming Web Requests listener. We have already reviewed most of the procedures required to make secure FTP server publishing work: ■

Bind a certificate to the Incoming Web Requests listener that matches the name users use to access the site.

■

Configure the Web publishing rule to redirect SSL requests as FTP requests.

www.syngress.com

348


Train the users to use HTTPS to access the site, or create a Web page that redirects FTP downloads to HTTPS requests.

You saw how to bind the certificate to the external interface earlier in this chapter. For more information on how to bind certificates to the Incoming Web Requests listener, review the section on SSL bridging. Creating a Web publishing rule to forward SSL requests as FTP requests is very similar to the rules you created in the SSL bridging scenarios covered earlier.The only difference is the setting on the Bridging tab of the rule (Figure 5.76).You need to enable the Require secure channel (SSL) for published site check box, and you can choose the Require 128-bit encryption check box if your clients support this option. Note that the client certificate check box is disabled and the Select button is grayed out.The reason for this is that you can’t use certificates to authenticate with an FTP site. Figure 5.76 Redirecting SSL Requests as FTP Requests

The browser will show a list of files on the FTP site when you connect to the site (Figure 5.77). Notice that you have to use HTTPS in the URL; when the connection is established, a “lock” icon appears in the status bar of the browser. Figure 5.77 Connecting to the FTP Site

www.syngress.com


349

Publishing a Certificate Server You might want to publish your certificate server.This is a good idea for two reasons: ■

External network clients can access the certificate server’s Web enrollment site from the Internet.

■

The certificate revocation list is available to Web clients.

You might want to publish the certificate server if you want users to access the Web enrollment site to obtain a client certificate from the certificate server.The user must be a member of the domain to request a user certificate from an enterprise certificate server. If the request is made to a stand-alone root certificate server, the user will have to wait for you to approve the certificate request (this is the default setting). Another reason why you might want to publish the certificate server is to make the certificate revocation list (CRL) available to external network users. One reason for poor SSL performance is that the client can’t access the CRL.You can fix this problem by publishing the CRL. Perform the following steps to make the CRL available to external network clients: 1. Open the Internet Services Manager from the Administrative Tools menu. 2. In the Internet Information Services console, expand the Default Web site node and right-click on the CertEnroll virtual directory. Click Properties. 3. Click on the Virtual Directory tab and put a check mark in the Directory browsing check box. Click Apply and then click OK. 4. Now let’s check what the default URL is for the CRL. On the certificate server, click Start and then click Run.Type mmc in the Open text box and click OK. In the console, click on the Console menu and click the Add/ Remove Snap-in command. 5. In the Add/Remove Snap-in dialog box, click Add. In the Add Standalone Snap-in dialog box, click the Certificates entry and click Add. On the Certificates snap-in page, select the Computer account option and click Next. 6. On the Select Computer page, select the Local computer option and click Finish. Click Close in the Add Stand-alone Snap-in dialog box. Click OK in the Add/Remove Snap-in dialog box. 7. In the left pane of the console, expand the Certificates node and then expand the Personal node (Figure 5.78). Click on the Certificates node. In the right pane of the console, double-click on the certificate that lists for Intended Purposes. www.syngress.com

350


Figure 5.78 The Certificates List

8. In the Certificate dialog box, click on the Details tab. Scroll through the list of fields and find the CRL Distribution Points entry (Figure 5.79).This is the URL you need to make available to external network users. In this example, the URL is http://clientdc.internal.net/CertEnroll/enterprisecert.crl.The FQDN in this URL must be accessible to external network clients; therefore, you need to enter this information into the public DNS. Close the Certificate dialog box. Figure 5.79 CRL Distribution Point Information

www.syngress.com


351

9. Go to the ISA Server machine. Create a destination set for the FQDN listed in the CRL.You also must create an entry in the public DNS that resolves the FQDN listed in the CRL to the external IP address of the ISA server used by the Incoming Web Requests listener. If you want to further limit access, you can enter the path /CertEnroll to the destination set. 10. Create a Web publishing rule to publish the CRL using the destination set you created in step 9. 11. You also need to make the certificate chain information available to the external network clients.The certificate chain is contained in the same folder as the CRL, so you shouldn’t have to create a separate Web publishing rule to support this. You biggest challenge in publishing the CRL and the certificate chain information (contained in the root certificate) is to match the URL information in the certificate to that which is accessible to external network clients.You will need to create a split DNS infrastructure if the certificate server is an enterprise root or enterprise subordinate server. If the certificate server is a stand-alone root, you will have problems if only the NetBIOS name is contained in the URL. You can add CRL Distribution Point and Authority Information Access (used to confirm the certificate chain) URLs in the Certificate Authority console.

www.syngress.com

352


Summary In this chapter, we discussed a number of ways to use Web and server publishing rules. Both Web and server publishing rules allow you to make resources on the internal network available to clients on the Internet.Web and server publishing rules can be used to publish resources on the internal network, on a traditional DMZ, or on a private address LAT-based DMZ segment. Server publishing rules allow you to publish almost any protocol.This is the primary advantage of server publishing over Web publishing.The server publishing rule essentially performs a reverse NAT function.The ISA server does not replace the source IP address on the packet unless you implement the changes noted in Microsoft KB article Q311777. An important consideration when implementing server publishing rules is that you need to avoid port contention on the external interface. No two services can listen on the same port on the same IP address on the external interface of the ISA server. For this reason, you typically need to disable the IIS services on the ISA server. You can also use server publishing rules to publish Web sites.The most common reason for doing this is so that the original client IP address appears in the Web server’s log files. Web publishing rules allow you to publish Web and FTP sites.Web publishing rules are handled by the Web Proxy service.The Web Proxy service is able to examine the application-layer data and make decisions on how to handle requests based on information such as the destination URL.Web publishing rules also allow you to perform port and protocol redirection. Protocol redirection allows you to bridge HTTP requests as SSL or FTP requests. Port redirection allows you to accept requests on the port number on the external interface and then forward them to another port on an internal network Web server.The main drawback of Web publishing rules is that the client’s source IP address is always changed to the internal IP address on the ISA server.

Defensive Tactics Fast Track Disabling Socket Pooling ; Socket pooling allows a service to listen on all interfaces and IP addresses. ; You should always disable socket pooling on the ISA server if you plan to run

IIS services on the ISA server. ; After disabling socket pooling, you must manually configure IIS services to

listen only on the internal interface.

www.syngress.com


353

; If you do not plan to use server publishing rules to publish IIS services on the

ISA server, you do not need to disable socket pooling. Socket pooling works well when publishing services using packet filters. ; You must use an admin script to disable socket pooling for the FTP and

W3SVC services.You must use the MDUTIL utility to disable socket pooling for the SMTP, NNTP, POP3, and IMAP3 services. ; You do not need to disable socket pooling on internal network servers that

you’re publishing using server or Web publishing rules. Socket pooling is only an issue for multihomed security devices that have at least one connection to a trusted network and at least one connection to an untrusted network.

Server Publishing ; Server publishing rules perform a reverse NAT function. ; Server publishing rules can expose communications to application filters so

that application-layer data can be examined. ; The main advantage of using server publishing rules over packet filters is that

you can use application filters to protect the published server. ; You must disable socket pooling for IIS services that you want to publish on

the ISA server. ; Server publishing rules do not require destination sets. ; Server publishing rules cannot perform port or protocol redirection; packets

are forwarded to the same port on which they are received. ; A server publishing rule cannot use a socket that’s already in use by a server

publishing rule or network service. ; You can publish HTTP and HTTPS sites using server publishing rules;

however, you must make changes to the Incoming Web Requests listener to prevent port contention.

Web Publishing ; Web publishing rules leverage the intelligence built into the Web Proxy

service to examine HTTP application-layer information. ; Web publishing rules allow you to redirect HTTP requests as FTP or SSL

requests.

www.syngress.com

354


; You need to create destination sets before you create Web publishing rules. ; Never use IP addresses in your destination sets; always use IP addresses. Using

IP addresses in destination sets can create a severe security risk if used in Web publishing rules. ; You can bind a Web server certificate to an Incoming Web Requests listener;

this allows the Web server to impersonate a Web site on the internal network. ; The Web Proxy service can protect data using SSL end to end; the first tunnel

terminates at the Incoming Web Requests listener, and the second tunnel terminates at the Web server. ; You can access internal FTP sites in a secure fashion by using Web publishing

rules; the Web Proxy service is able to redirect SSL requests as FTP requests.


Q: What type of authentication should I use for my published Web sites? Should I force users to authenticate at the Incoming Web Requests listener and internal network Web server?

A: You can use any type of authentication you like with an internal network Web site that you’re publishing with Web publishing rules. It’s important that you only require authentication at one location.You should not require authentication at the Incoming Web Requests listener and the internal Web site. ISA Server will not support this type of double authentication.The only time you can authenticate at the Incoming Web Requests listener and the internal network Web server is when you authenticate with the Incoming Web Requests listener using a client certificate. If you authenticate with the Incoming Web Requests listener using a client certificate, then you can use another form of authentication to authenticate with the internal network Web server. In general, we prefer authenticating with the Incoming Web Requests listener, as this offloads the authentication processing off the internal network server and places it on the ISA server.

www.syngress.com


355

Q: I want to publish my FTP using a Web publishing rule, but it doesn’t work. I went through the wizard and left it to use the default FTP port.What is causing the rule to fail?

A: The FTP Web publishing rule might fail for a number of reasons.The most common reason is that you forgot to configure the rule to redirect the Incoming HTTP requests as FTP requests. Note that when you create the Web publishing rule, you aren’t given the option to change the redirection.You must create the rule, and then open the Properties dialog box and click on the Bridging tab of the rule to change the redirection behavior. Select the option to redirect HTTP as FTP. Now your Web publishing rules will allow external network users to use HTTP requests to access your FTP site.

Q: I have a DNS server on the internal network that I want to publish to the Internet. I host my own domains, and I told my registrar to use the external IP addresses on my ISA server for my authoritative DNS. However, the rules are not working! What might be the problem?

A: The most common reason for DNS server publishing failures is that you’re running a DNS server on the ISA server. Make sure that you remove the DNS server from the ISA server if you’re not going to use the ISA server as a DNS server. If you need to use the ISA server as a DNS server, you have to configure the DNS server to listen only on the internal interface.You’ll have port contention on the external interface if the DNS server on the ISA server is left in its default configuration.

Q: My Web and FTP sites are published using Web publishing rules. I’ve disabled IIS on the ISA server and can access the sites on the internal network.The problem is that external network clients can’t connect to my sites.They keep getting an error stating that the site cannot be found. I don’t see anything wrong in my Event Logs or in the ISA Management console.What do you think the problem might be?

A: Have you registered your sites in a public DNS? If you don’t publish your own DNS server, you need to make sure that your public domains are entered on a publicly accessible DNS server.You can publish servers all you want, but if external network users cannot resolve the FQDN for your site, they won’t be able to access it. If you host your own DNS servers, make sure that you configured the IP addresses in the DNS server publishing rules to be used as your authoritative name servers. If you recently made the change, it could be that you haven’t waited long enough. Give it a couple of days and try testing your name resolution again.

www.syngress.com

356


Q: My users keep forgetting to enter HTTPS when accessing our secure Web site. Is there a way to avoid using HTTPS?

A: It will take some time, but your users will slowly become accustomed to typing HTTPS. Explain to them that they are capable of putting an “s” at the end of the protocol and that you’re confident of their abilities to do so. Make yourself available to users for technical and emotional support. Many of them will become frustrated because they forgot to add the “s” at the end of the protocol and they’ll beg you to do something about it. It’s important that you listen to their concerns and let them vent. Don’t enable the users or let them become codependent by creating a Web page with a redirect. Keep reminding the users that they can do it, and it’s just a matter of practice.

Q: I’ve exported my certificate and put it on the ISA server, but the ISA server is not accepting SSL connections! I need this to work.What do you think the problem is?

A: What certificate did you export? Remember that the ISA server needs to impersonate the Web server on the internal network. For it to do so, you need to assign a certificate to the Web site, and then export that certificate.Then, import the certificate into the ISA server’s machine certificate store.You can attach the certificate to the Incoming Web Requests listener after it’s imported into the ISA server’s machine certificate store. Keep in mind that this certificate can’t be used as a client certificate.You will need to obtain a client certificate if you want the ISA server to use a client certificate to authenticate with an internal network Web server.

www.syngress.com

Chapter 6

Defense Plan 5: Protecting Mail Services


Configuring Mail Services on the ISA Server Computer

■

Configuring Mail Services on the Internal Network

■

GFI’s Mail Security and Mail Essentials for SMTP Servers


357

358

Chapter 6 • Defense Plan 5: Protecting Mail Services

Introduction In the last chapter, we covered a number of scenarios where you could securely publish servers on the internal network using server and Web publishing rules. In this chapter, we’re going to focus on a single type of server: the mail server. In particular, we’ll cover how to publish the IIS SMTP server and Microsoft Exchange 2000 Server.We won’t discuss the specifics of publishing Exchange 5.5, but the general principles remain the same. Mail services publishing is the most popular type of server publishing. Both small and large organizations prefer to have a higher level of control over their mail services than any other type of service.Why? Because most businesses are highly dependent on their mail services, they can little afford the foibles and inconsistent levels of service provided by third parties. If mail services go down, they might take the business with them! The good news is that ISA Server makes publishing mail services very simple. If you have your own third-party SMTP/POP3 mail server, you can use the Microsoft IIS SMTP service for a mail relay, and you can even leverage the IIS SMTP service and the ISA Server Message Screener to protect your third-party SMTP/POP3 mail server from spam. If you run Windows 2003, you already have a POP3 server available to you. Just put an IIS SMTP service in front of your Windows 2003 SMTP/POP3 server and you’ll be protected against attackers and spam. Even more impressive than support for simple IIS SMTP services is ISA Server’s capability to make Exchange 2000 Services available to Internet users.You can publish all the Exchange Server’s mail services, or just certain ones. ISA Server integrates with Exchange 2000 by making it easy to securely publish Exchange RPC and Outlook Web Access. No other firewall on the market provides the level of integration and compatibility with Microsoft Exchange 2000. This chapter is broken down into two main sections: publishing mail services on the ISA server, and publishing mail services on a computer somewhere on the internal network. If you’re not publishing mail services on the ISA server, you might want to skip down to the publishing services on the internal network section. However, we advise against this, as we’ll be going over many important principles early in the chapter that you’ll want to understand before trying to publish services on the internal network. If you have a single Windows 2000 server and need to publish everything on it, then you’ll want to focus on the installing mail services on the ISA server section. Again, we recommend that you read the entire chapter, as we’ll be including helpful tips and tricks throughout! We’ll start with configuring and publishing mail services on the ISA server, and then move to the higher security option of putting them on the internal network. Pay very close attention to the steps outlined in the following sections. Many details must be covered. Missing even one step could prevent something from working and it will

www.syngress.com

Defense Plan 5: Protecting Mail Services • Chapter 6

359

be very difficult to troubleshoot the problem. Be patient, be careful, and you won’t find yourself reformatting and reinstalling because of an obscure misconfiguration issue.

ISA SERVER ALERT Small Business Server 2000 (SBS) isn’t explicitly covered in this book because of time and size considerations. Although we can’t cover the specifics of SBS, the good news is that the same principles that we apply on the publishing mail services on the ISA server section apply to SBS. The major difference is we don’t cover any of the SBS built-in wizards to accomplish the configuration. If you want to run ISA Server and Exchange on the same computer, you’ll have to carry out the manual configuration steps detailed in this chapter.

Configuring Mail Services on the ISA Server Computer We get a tremendous number of questions on ISAServer.org and in the Microsoft newsgroups regarding how to configure and publish mail services on the ISA server. In the vast majority of cases we’re not able to give any detailed level of information because of the number of factors you have to take into consideration when running mail services on the ISA server.We’re usually able to throw out a quick tip, but not much more. At the time of this writing, there is little or no documentation on the specific procedures you must carry out to install mail services on the ISA server.There is isolated information “here and there,” but nothing you can really use to create an integrated and working solution.This chapter solves this problem by giving you complete, step-by-step working examples of how to carry out mail services publishing on the ISA server.You’ll also learn about some common, and obscure, issues that might cause your mail services to perform poorly. In this section we’ll cover the following topics: ■

Publishing the IIS SMTP Service on the ISA server

■

Configuring the Message Screener on the ISA server

■

Publishing Exchange Server services on the ISA server

■

Publishing Outlook Web Access on the ISA server

If you’ve been wondering about the secrets of mail services publishing on the ISA server, then move ahead and see that veil of secrecy removed!

www.syngress.com

360


Publishing the IIS SMTP Service on the ISA Server Many ISA Server administrators would like to take advantage of the IIS SMTP service on the ISA server for a number of reasons: ■

You want to use the IIS SMTP service as a plain mail relay

■

You want to use the IIS SMTP service as a mail and spam-whacking relay using the ISA Server Message Screener

■

You are running Web sites on the ISA server that depend on a local SMTP service

■

You want to use the SMTP service on the ISA server to stop outgoing mail from containing attachments or keywords by using the SMTP Message Screener

■

You want to use the SMTP service on the ISA server as your smart host to take the burden of name resolution off your internal network mail server

Should you publish the SMTP service on the ISA server? Again, it depends on the level of security you require.There is no problem with putting the SMTP services on the ISA server if you have light security requirements,.You might want to consider removing all extraneous services from the ISA server if you have high security requirements.

Configuring the SMTP Service Let’s go through the steps required for configuring the SMTP services on the ISA server. In this scenario, ISA Server is already installed on the computer.The machine is a member of the internal network domain and it sits at the edge of the network. No WINS or DNS services are installed on the machine. It will function as an SMTP relay for the Exchange 2000 server setting on the internal network. Perform the following steps to configure the IIS SMTP service on the ISA server: 1. Open a command prompt and type netstat –na | find “:25”. If socket pooling for the SMTP service is enabled, you’ll see an entry for TCP 0.0.0.0:25.You’ll have to disable socket pooling before you can publish the SMTP server (Figure 6.1). Figure 6.1 Checking for SMTP Service Socket Pooling

www.syngress.com


361

2. There are two ways TO disable socket pooling on the ISA server.You can use the mdutil utility or the metaedit utility.The mdutil utility can be found at the www.isaserver.org site or at our FTP site at ftp.tacteam.net/isaserver.The metaedit utility can be found at the Microsoft Web site (Q232068).The metaedit utility provides a nice GUI interface, and the Q article gives detailed instructions on how to use the metaedit program.We’ll go over using the mdutil utility is this section because we have the most experience with this utility and know that it works flawlessly. 3. Stop the SMTP service. At the command prompt, type net stop smtpsvc and press Enter. 4. Download the mdutil utility and place it in the root of the C: drive (actually, you can put it anywhere you want; we are placing it in the root of C: to make this example easier to follow).Type the following command at the command prompt: mdutil set -path smtpsvc/1 -value 1 -dtype 1 -prop 1029 -attrib 1

Now press Enter.The /1 indicates that socket pooling is disabled for the first virtual SMTP server. In this example, we’re only covering a single virtual server. If you plan to run multiple virtual SMTP servers, you’ll need to repeat the command with the /2, /3, and so on. 5. From the Administrative Tools menu, open the Internet Services Manager. Expand your server name. Right-click on the Default SMTP Virtual Server (Stopped) entry and click Properties. 6. On the General tab, click the Down arrow in the IP address drop-down list box and select the address on the internal interface. Place a check mark in the Enable logging check box. If you select the W3C Extended Log File Format open, then click Properties and click on the Extended Properties tab.We recommend selecting all options for the highest level of logging, because SMTP security issues tend to be quite common. Make sure you have plenty of disk space on the drive on which you’re storing the log files, and that you archive those log files on a regular basis.You can configure where the log files are stored by clicking on the General Properties tab and changing the Log file directory entry. Leave the Log Files dialog box and click on the Access tab. 7. On the Access tab, click on Authentication in the Access control frame. You want to allow for anonymous access because this machine is acting as an SMTP relay. Internet SMTP servers will not be able to forward mail to your SMTP relay if you force authentication.You can force TLS encryption www.syngress.com

362


between an external SMTP client and the SMTP service by binding a certificate to the SMTP service and forcing TLS.This will not work in our current scenario, because the SMTP relay must be able to accept mail from all hosts, and most of those hosts don’t support TLS sessions.The Connection control button allows you to control which hosts are able to connect to the SMTP service. Again, because this machine is configured as an SMTP relay, you can’t set IP address restrictions; you want all SMTP servers on the Internet to be able to forward mail to your SMTP service. However, you do not want all servers on the Internet to use your SMTP server as an open relay. Click Relay in the Relay restrictions frame to begin solving this problem. 8. It’s very important to tightly restrict which domains can be relayed through your SMTP service.You will be quickly blacklisted if you run an open mail relay. Unlike services such as SpamCop, legitimate RealTime Black Hole Lists (RBLs) search for open mail relays. Spammers can hijack an open mail relay and forward literally GBs of spam. Select the Only the list below option in the Relay Restrictions dialog box.The default setting has no entries in the list. Leave it this way so that no one is able to use the SMTP server as a generic mail relay server. If you want to use the SMTP server as a generic outbound mail relay, you can add the IP address of your internal network’s mail server to the list of addresses that can relay through the default SMTP virtual server. Click Add to add the internal network mail server. In the Computer dialog box, select the Single computer option and add the IP address of your internal network’s mail server. Click OK.You’ll see that the computer is Granted permission to relay through the SMTP server (Figure 6.2). Note that the Allow all computers which successfully authenticate to relay, regardless of the list above option is checked.This isn’t much use to us in our SMTP relay configuration we’re using here. Click OK to complete the Relay Restrictions. Figure 6.2 Allowing the Internal Network Mail Server to Relay through the SMTP Service on the ISA Server

www.syngress.com


363

9. Click on the Messages tab. Note the defaults enforced by the SMTP server. We’ve received many questions regarding the SMTP server “blocking” messages that were too large, or that some user’s mail didn’t go out on a timely basis.The most likely reason for the problem is related to the setting in this dialog box. Review the options on this tab and make sure they fit your organizational requirements. 10. Click on the Delivery tab. Set the retry intervals for something that works best for you.We like to set a long expiration timeout, just in case something goes wrong with our SMTP server on the internal network; that way, we don’t have to worry about lost mail because it’s being held at the SMTP relay. Set the expiration timeout to 7 days.We also change the Subsequent retry interval (minutes) to 60.We don’t see the need to wait six hours after the third retry. Click Advanced. In the Advanced Delivery dialog box (Figure 6.3), make sure that Fully-qualified domain name entry is resolvable by external network SMTP servers if you plan to use this server as an outbound SMTP mail relay. Many administrators perform reverse lookups at their SMTP servers, and if the name here doesn’t match the reverse lookup on the primary IP address on the external interface of the ISA server, your mail might be dropped.The Smart host entry allows the SMTP server to forward mail to another mail server with the goal of offloading MX domain name resolution.You might want to configure your ISP’s mail server here if you have a reliable ISP that knows how to maintain quality mail servers,.You can use an FQDN or IP address in the Smart host text box. If you use an FQDN, make sure that the ISA server can resolve the name by using the nslookup command. If you use an IP address, make sure you use straight brackets [ ] around the IP address.We don’t recommend using the Attempt direct delivery before sending to smart host and Perform reverse DNS lookup on incoming messages options. Click OK to save the settings in the Advanced Delivery dialog box. Figure 6.3 Configuring Advanced Delivery Options

www.syngress.com

364


11. Click Apply and then click OK in the SMTP server’s Properties dialog box. 12. Now you need to configure a remote domain for your own mail domain.The only mail you want to accept for inbound relay is mail destined for users in the mail domains under your administrative control.You allow this type of selective relay by using remote domains. Expand the Default SMTP Virtual Server node and right-click on the Domains node. Point to New and click Domain. 13. On the Welcome to the New SMTP Domain Wizard page, select the Remote option and click Next. 14. On the Select Domain Name page, type in the name of the domain for which you want to receive mail. For example, if you’re responsible for mail for the internal.net domain, type internal.net in the Name text box. Click Finish. 15. Double-click on the internal.net remote domain entry in the right pane of the console. In the Properties dialog box, put a check mark in Allow incoming mail to be relayed to this domain check box. Select the Forward all mail to smart host and put in the IP address (surrounded by straight brackets) of your internal network SMTP server in the text box. Click Apply and then click OK. Note that relay for incoming mail is handled by the Remote Domain configuration. Outgoing mail relay is handled by the Relay configuration dialog box for the default SMTP virtual server. If you want the internal mail server to use the SMTP service on the ISA server as a relay, you need to allow the internal server to be able to relay to all mail domains. 16. Now restart the SMTP service. At the command prompt, type net start smtpsvc and press Enter. After the SMTP service starts, type the command netstat –na | find “:25” and press Enter .You should find that the SMTP service is now listening on the internal interface only.

Configuring the SMTP Server Publishing Rule Now that SMTP services socket pooling is disabled, let’s create the SMTP server publishing rule. 1. Open the ISA Management console, expand your server name, and then expand the Publishing node. Right-click on Server Publishing Rules, point to New, and click Rule. 2. Give the rule a name on the Welcome to the New Server Publishing Rule Wizard page, and click Next.

www.syngress.com


365

3. On the Address Mapping page, type in the IP address of the internal interface of the ISA server that the SMTP service is listening on in the IP address of internal server text box. Click Browse and select the IP address on the external interface on which the SMTP service should receive messages. Note that if you also use this server for outbound relay, that this internal IP address is not used as the source IP address for outbound messages.The primary IP address on the external interface of the ISA server is used for the source IP address for outbound messages. Click Next. 4. On the Protocol Settings page, click the Down arrow for the Apply the rule to this protocol drop-down list box and click the SMTP Server protocol. Click Next. 5. On the Client Type page, select the Any request option and click Next. 6. Review your settings and click Finish on the complete the New Server Publishing Rule Wizard page. Now try sending a message from a mail client on the external network to the ISA server. Make sure that you send it to a user who belongs to one of your remote domains.The ISA server publishing rule will pass the message from the external interface to the SMTP server on the internal network.The SMTP service forwards the message to the smart host you configured in the Remote Domain Properties dialog box, which in most cases is your Exchange server (although it can also be a third-party SMTP server or even another SMTP relay). It’s important to note that relay works differently for incoming and outgoing messages. Although the SMTP service doesn’t really know which messages are incoming and outgoing, it does evaluate messages in terms of their relay requirements. If the message is destined for one of your remote domains, the Remote Domain configuration determines how the message is handled. If the message is destined for a domain other than one of your remote domains, then the message is handled by the Relay properties configured for the virtual server. For example, in the previous example we configured a remote domain for internal.net and set the smart host for the internal mail server.We also configured the default SMTP virtual server to deny mail relay for all hosts except the SMTP server on the internal network. If a message is sent from any host but the SMTP server on the internal network to a domain that is not one of your remote domains, it will be dropped.The only exception is when that message comes from the IP address of the internal server that we configured to allow relay.This prevents spammers from abusing your mail server.

www.syngress.com

366


Something you need to be aware of is how the publishing rule affects the SMTP headers on the incoming messages. Look at the following example: Received: from ISA1.internal.net ([10.0.0.1]) by CLIENTDC.internal.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 12 Oct 2002 14:22:40 -0500 Received: from EXTCLIENT ([127.0.0.1]) by ISA1.internal.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 12 Oct 2002 14:22:40 -0500 Message-ID: From: "Bob" <[email protected]> To: <[email protected]> Subject: test Date: Sat, 12 Oct 2002 14:22:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C271FA.CBE1C9D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Return-Path: [email protected] X-OriginalArrivalTime: 12 Oct 2002 19:22:40.0116 (UTC) FILETIME=[BAFA7340 :01C27224]

Notice that the line for Received: shows the name of the external SMTP client sending the message and the IP address 127.0.0.1.This will always be the case when you use server publishing rules to publish services on the ISA server.The incoming message will appear to be from the loopback address instead of the actual host’s IP address.We can confirm this by looking at the SMTP service log file on the ISA server: #Software: Microsoft Internet Information Services 5.0 #Version: 1.0 #Date: 2002-10-12 22:36:18 #Fields: time c-ip cs-method cs-uri-stem sc-status 22:36:18 127.0.0.1 HELO - 250 22:36:18 127.0.0.1 MAIL - 250 22:36:18 127.0.0.1 RCPT - 250 22:36:18 127.0.0.1 DATA - 250

www.syngress.com


367

22:36:18 127.0.0.1 QUIT - 0 22:36:18 - - - 0 22:36:18 CLIENTDC.internal.net EHLO - 0 22:36:18 CLIENTDC.internal.net - - 0 22:36:18 CLIENTDC.internal.net MAIL - 0 22:36:18 CLIENTDC.internal.net - - 0 22:36:18 CLIENTDC.internal.net RCPT - 0 22:36:18 CLIENTDC.internal.net - - 0 22:36:18 CLIENTDC.internal.net BDAT - 0 22:36:18 CLIENTDC.internal.net - - 0 22:36:18 CLIENTDC.internal.net QUIT - 0 22:36:18 CLIENTDC.internal.net - - 0

This makes forensic analysis of e-mail headers problematic because you never get the source IP addresses for incoming messages.There is no workaround for this problem other than putting the SMTP relay on an internal network client or using packet filters to publish the SMTP service.This is just one of the many reasons why we don’t recommend putting network services on the ISA server.

Message Screener on the ISA Server The ISA Server Message Screener works together with the SMTP filter and allows you to: ■

Block mail from specific e-mail domains

■

Block mail from specific e-mail addresses

■

Block mail containing specific text strings in the e-mail header or body

■

Block mail containing specific attachments

There is nothing to prevent you from running the Message Screener on the ISA server. However, it’s very important to configure the SMTP server carefully, as you could end up with an open relay that any spammer could take advantage of. If you configure the SMTP service and publish it in the way we recommended in the previous section, you’ll be in good shape. One of the advantages of installing the SMTP Message Screener on the ISA server is that you don’t have to configure permissions that allow the Message Screener to contact the ISA server using the SMTPCred tool, and you don’t need to configure DCOM permissions. It’s okay if you aren’t familiar with the SMTPCred tool and DCOM permissions.; you’ll learn about them later in the chapter.

www.syngress.com

368


The SMTP Message Screener was automatically installed if you did a full installation of ISA Server. If you didn’t, it might not have been installed If you’re not sure, check the Registry to see if the service is installed (Figure 6.4). Open the Registry Editor and look for: HKEY_CLASSES_ROOT\CLSID\{4F2AC0A5-300F-4DE9-821F-4D5706DC5B32}

Figure 6.4 Checking Registry Entries for the SMTP Message Screener

The Message Screener is installed on the ISA server if you see the Registry key. If you don’t, you’ll need to install the Message Screener.You can do this by running the Add/Remove Programs applet from the Control Panel. The Message Screener can be used to screen both inbound and outbound messages. Most organizations are more interested in controlling inbound SMTP messages. If that describes your organization, all you need to do is configure the remote domains for your organization on the SMTP server and configure those domains to relay to your internal network’s mail server. You’ll need to configure the Default SMTP Virtual Server in the Internet Services Manager to allow only the internal mail server to relay if you also want to screen outgoing SMTP messages.You saw how to configure the relay to allow only the internal server to relay in the previous section. Configure the SMTP Message Screener after you have the SMTP service configured. Perform the following steps to configure the SMTP Message Screener: 1. The Message Screener depends on the SMTP Filter.You need to enable the SMTP Filter because, by default, the SMTP filter is disabled. Open the ISA

www.syngress.com


369

Management console, expand your server name, and then expand the Extensions node. Right-click on the SMTP Filter entry and click Enable. The ISA Server Warning dialog box appears telling you that it needs to restart the Firewall service. Select the Save the changes and restart the service(s) option and click OK. 2. Double-click on the SMTP Filter. Click on the SMTP Commands tab (Figure 6.5).This part of the SMTP filter does not depend on the Message Screener.What you see here is a list of SMTP commands and the maximum length allowed for each.The goal of this list is to prevent SMTP command buffer overflow exploits.There is a small problem with some of the commands, such as the NOOP command.The size is set to 6 by default.This can cause you to get a number of spurious SMTP Filter Event warnings in your Event Viewer. Click on the NOOP command and then click Edit. Change the value to 1024 and click OK. Figure 6.5 The SMTP Commands Tab

3. Click on the Keywords tab. Here you can create a list of keywords for the Message Screener to check. Make sure that the Enable keyword rule check box is checked. Click Add.Type in a keyword in the Keyword text box (Figure 6.6). In the Apply action if keyword is found in frame, select the option for where you want the Message Screener to check for keywords. It takes more processor cycles to check for the keyword in the Message header or body than it takes to just check the Message body.The least number of processor cycles are required to check just the Message header. Click the Down arrow in the Action drop-down list box. If you select the Delete message option, the message will be deleted. If you select the Hold Message option, the message will be saved to the \Inetpub\mailroot\Badmail folder and you can view the www.syngress.com

370


message later by opening it from that folder. If you select the Forward message to option, you can enter an e-mail address to which the message can be forwarded. If you choose to forward the mail, make sure that you forward it to an SMTP server that the ISA server can reach.The easiest way to do this is to forward it to an SMTP server on the internal network. Make sure that the ISA server can resolve the MX record for mail domain in the e-mail address.You will need to create a packet filter allowing outbound access to TCP port 25 from any local port on the ISA server if you forward messages to an external SMTP server. After making your selections, click OK. Figure 6.6 Adding a Keyword to the Message Screener

4. Click on the Users/Domains tab (Figure 6.7). Here you can block messages based on user account name or an entire SMTP domain name.Type in an e-mail address in the Sender’s name text box and click Add.Type in an e-mail domain name in the Domain text box and click Add. Click Apply, and all mail from these users and/or mail domains will be blocked by the Message Screener. Figure 6.7 Blocking Messages Based on an E-Mail Address or Domain Name

www.syngress.com


371

5. Click on the Attachments tab (Figure 6.8). Here you can configure a list of attachments that you want the Message Screener to block. If you select the Attachment name option, you must enter the exact name of the attachment. For example, a common attachment name is joke.exe. If you enter joke.exe, the Message Screener will block messages with that attachment. If you select the Attachment extension option, you enter the name of the file extension you want blocked. For example, if you want to block all executable files, enter the .exe extension in the text box. Note that there’s no option allowing you to block all attachments. If you want to block attachments over a certain size, select the Attachment size limit option and then the size in bytes. For example, if you want to limit attachments to less than 1MB, type 1024000. Click OK and the Message Screener will block the attachments you’ve configured in this dialog box. Click Apply to set the rule. Figure 6.8 Blocking E-Mail Attachments

6. Click OK to close the SMTP Filter Properties dialog box. Be patient when configuring the Message Screener rules. Many times, we’ve thought that the Message Screener wasn’t doing its job because we began testing the rule too quickly. It might take a few minutes for the rule to take effect. However, if you configured the rule correctly, they will work.

Publishing Exchange Server on the ISA Server Many people want to place their Exchange 2000 server on the ISA server.We generally recommend against this because each service you place on the ISA server provides a portal of attack for Internet criminals. However, some of you don’t have the resources to purchase multiple Windows 2000 servers, which would allow you to put the Exchange server on a machine other than the ISA server.

www.syngress.com

372


You’ll encounter a number of challenges when making an Exchange 2000 server work on the ISA server computer. First, you have to make the ISA server a domain controller because Exchange 2000 requires Active Directory. If you only have one Windows 2000 Server machine, that machine will also have to be a domain controller. You have to be very careful on how you configure DNS on the machine when you can make the ISA server a domain controller. If DNS is not configured correctly, the machine won’t work properly as an ISA server, domain controller, or mail server. The second major challenge is socket pooling.You have to disable socket pooling for all of the Exchange Services if you want to use server publishing rules to publish the Exchange Server services. Socket pooling causes a service to listen on all interfaces and IP addresses, which can cause port contention when creating server publishing rules. There are two ways to get around this problem: you can disable socket pooling for the services, or you can use packet filters to make the services available to Internet users. Packet filters are the easiest way to “publish” Exchange services on the ISA server. This is why the Secure SMTP Server Publishing Wizard creates packet filters instead of server publishing rules.The problem with publishing services with packet filters is that you can’t leverage any application filters to protect the Exchange 2000 mail services.

ISA SERVER ALERT You can’t publish Exchange RPC services when the Exchange server is on the ISA server. You can’t use server publishing rules because there’s no way to disable socket pooling for RPC endpoint mapper (TCP port 135). You can’t use packet filters because you would need to statically open the entire high port range (1024–65535) to allow the dynamic port assignment to the clients. You will have to put the Exchange server on the internal network, not on the ISA server, if you want to publish Exchange RPC services and allow external Outlook MAPI clients to connect to it.

To publish Exchange 2000 services on the ISA server: 1. Install Windows 2000. 2. Configure DNS. 3. Make the server a domain controller. 4. Install ISA Server. 5. Install Exchange Server 2000. 6. Disable socket pooling. 7. Configure server publishing rules for the services you want to publish.

www.syngress.com


373

8. Optional: Obtain certificates for services you want to publish, and create server publishing rules for these secure services. Let’s look at these steps in detail. Make sure you follow them closely and understand why we’re performing each step. Doing so will help you troubleshoot problems if and when they occur.

ISA SERVER ALERT The procedures we cover in this chapter apply to stand-alone versions of ISA Server, Windows 2000, and Exchange 2000 Server. You might be forced to use certain wizards to install services if you have Small Business Server. However, the same principles apply to all Windows 2000, ISA, and Exchange 2000 Server installations. The only difference is that some of the steps you take to get to the same result might differ. You will be able to replicate the steps described here if you avoid the wizards and install the services and server separately.

Installing Windows 2000 The first step is to install Windows 2000.You might want to consider reinstalling if you already have Windows 2000 installed. A clean installation prevents problems that might occur on a machine that’s already been installed and has a variety of known and unknown configuration changes made to it. Requirements for installing Windows 2000 and ISA Server for a DC are: ■

Windows 2000 Server, Advanced Server, or Datacenter Server.

■

A generous amount of RAM.To support all these services, we recommend at least 1GB of RAM, and more would be better.

■

Make sure that all network interface cards (NICs) you plan to use are already installed and plugged into a hub or switch. Domain controllers will run into problems if you multihome them after you run dcpromo.

■

Do not plug the external interface into the Internet during installation. Many ISA Server administrators have been successfully hacked either during installation or after installation but before ISA Server is installed.

Keep in mind that you should use hardware that’s on the hardware compatibility list (HCL), or that at least has Windows 2000 drivers. Let’s get started installing Windows 2000. 1. Boot the CD. Format the partitions if you need to and do all the other steps required during the text mode phase.There are no special installation www.syngress.com

374


requirements to make a DC work during the text mode phase of the installation. If you want to fine-tune your ISA Server configuration, check out the Syngress title Configuring ISA Server 2000: Building Firewalls for Windows 2000 (ISBN 1-928994-29-6). 2. Reboot into GUI mode. On the Regional Settings page, make any required changes and click Next. 3. On the Personalize Your Software page, enter your Name and Organization and click Next. 4. Type in your key on the Your Product Key page and click Next. 5. On the Licensing Mode page, select the appropriate licensing mode for your server and click Next. 6. On the Computer Name and Administrator password page, enter the computer (NetBIOS) name for your computer and a complex password for the Administrator account.You might want to rename the Administrator account after installation is complete. If you do, make sure to do it immediately after installation.You might run into problems with ISA Server or Exchange Server if you rename the Administrator account after installing those services. Click Next. 7. On the Windows Components page, double-click on the Internet Information Services entry. If you need to support FTP and NNTP, make the appropriate selections on the Internet Information Services (IIS) page. We recommend that you minimize the number of IIS servers running on the ISA server, but since this is your only Windows 2000 server, you’ll need to put all the services you require on this machine. Click OK on the Internet Information Services page after making your selections. 8. Back in the Windows 2000 Components page, double-click on the Management and Monitoring Tools node. Select the Network Monitor Tools option. Click OK in the Management and Monitoring Tools dialog box. 9. Double-click on the Networking Services entry. At the very least, you need to install DNS and WINS. Scroll through the list of networking services and make those selections.Then, click OK in the Network Services dialog box. 10. Double-click on the Terminal Services option. Select the Client Creator Files option if you need to install the client. Click OK in the Terminal Services dialog box. Click Next on the Windows 2000 Components page.

www.syngress.com


375

ISA SERVER DEFCON1 If you install WINS, you must disable NetBIOS on the external interface of the ISA/DC computer. If you don’t disable NetBIOS, the external IP address of the ISA/DC will be registered for all sorts of things that you don’t want registered in WINS. Don’t disable NetBIOS until you’re finished with everything. Before disabling NetBIOS, check out the entries in the WINS database for the external IP address of the ISA/DC computer, and delete any you find. Make sure that you don’t enter a WINS address in the TCP/IP Properties of the external interface. If you do install a WINS server on the ISA server, make sure you delete any entries in the WINS database that match the IP address of the ISA server’s external interface. It is imperative that no external IP addresses are in the WINS database when you run dcpromo and afterward. Note that WINS is not required, but it is helpful for administrators who are still learning the details of DNS.

11. On the Date and Time Settings page, set the correct date, time, and time zone. Click Next. 12. On the Terminal Services Setup page, select the Remote administration mode option and click Next. 13. On the Networking Settings page, select the Custom Settings option. Click Next. 14. On the Networking Components page, you are presented with the Configuration Settings dialog box for the external interface of the ISA server. We refer to this adapter as the external interface because this interface should be listed as second on the list of adapters in the Advanced network adapter settings. If you don’t want this to be the external interface, you’ll have to manually change the adapter’s priority after completing the installation. Remove the check marks for Client for Microsoft Networks and File and Printer Sharing. Double-click on the Internet Protocol (TCP/IP) entry. In the Internet Protocols (TCP/IP) Properties dialog box, and type in the IP addressing information appropriate for your external interface. Make sure that you enter your ISP’s DNS server address in the Preferred DNS server text box if you don’t want to configure your own DNS server to resolve Internet host names.We’ll go through DNS server configuration later in this section; if you will be using your DNS server to resolve Internet host names, you need to enter the internal IP address of the ISA/DC/Exchange server in this text box. The Default gateway will either be assigned by your ISP or will be the LAN interface of the upstream Internet connection device. Click Advanced. Click

www.syngress.com

376


the DNS tab. Remove the check mark from the Append parent suffixes of the primary DNS suffix check box.There is no reason for your external interface to resolve queries. In addition, remove the check mark in the Register this connection’s addresses in DNS check box.You do not want this interface to register with the DNS server installed on this computer. Click OK.You’ll get an informational message telling you that your WINS address is empty. Click Yes. Click OK to close the Internet Protocol (TCP/IP) Properties dialog box. Click Next in the Network Components page.

ISA SERVER ALERT After Windows 2000 installation is complete, you should rename the interfaces to make them easier to work with. Give them names like InternalNIC and ExternalNIC. Do not use names like internal and external, because the name internal is also used by the RRAS console to represent an interface created and used by RRAS only. Although this won’t matter too much because the RRAS services “internal” interface is disabled after you install ISA Server, it could cause some confusion.

15. Here you see the Networking Components page for the internal interface of the ISA/DC/Exchange computer. Double-click on the Internet Protocol (TCP/IP) entry. Enter the internal IP address and subnet mask. Make sure you make the Preferred DNS server the IP address of the internal interface.This is vitally important because this machine is the DNS server for your Active Directory domain and you want clients to identify the domain controller using the internal IP address. Click Advanced. Click on the WINS tab. Click Add and add the IP address of the internal interface of this ISA/DC/Exchange computer.You want this IP address to register with WINS. You do not want the external interface to register with WINS. Click OK in the Advanced TCP/IP Settings dialog box after you have added the WINS server address. Click OK in the Internet Protocol (TCP/IP) Properties dialog box. Click Next on the Networking Components page. 16. On the Workgroup or Computer Domain page, don’t change the defaults; there isn’t a domain yet for it to join. Click Next. 17. The Installation Wizard now installs and configures your selected services. Click Finish to restart the computer when the wizard tells you to do so.

www.syngress.com


377

ISA SERVER DEFCON1 You should disable NetBIOS on the external interface of the DC/ISA Server computer to prevent problems with the Browser service and prevent browser announcements from trying to go out the external interface. All they’ll do is fill up your logs because later you will enable packet filtering to block NetBIOS communications on the external interface. Leave this to the very last step— disable NetBIOS after you’ve installed Service Pack 3.

18. After the system restarts, confirm that the NIC binding order is correct.You want the internal interface to be at the top of the list, and the external interface to be under the internal interface. Right-click My Network Places and click the Properties command. In the Network and dial-up Connections window, click on the Advanced menu. Click on the Advanced Settings command. In the Connections frame, make sure that the internal interface is at the top o the list and that the (Remote Access connections) option is at the bottom. 19. After confirming that the interface order is correct, immediately install Service Pack 3.

Configuring DNS Server Forward and Reverse Lookup Zones Configuring the DNS server properly before you run DCPROMO is important because you want the Active Directory to dynamically register Active Directory related resource records into the DNS. Many ISA Server admins unwittingly sabotage themselves because they’ve promoted the machine to a domain controller before configuring DNS. Configure DNS server for yourself before you promote the machine to a domain controller.This allows you to avoid many problems related to the Active Directory DNS Configuration Wizard. Perform the following steps to configure your DNS server: 1. Click Start, point to Administrative Tools, and click on DNS. 2. Expand all the nodes in the left pane, and then right-click on Forward Lookup Zone. Point to View and click Advanced. 3. Right-click on Reverse Look Zone and click New Zone. Click Next on the Welcome page.

www.syngress.com

378


4. On the Zone Type page, select the Standard Primary option and click Next. 5. On the Reverse Lookup Zone page, type in the network ID for the segment connected to the internal interface of this DC/ISA Server computer.You might have to create additional reverse lookup zones if you have multiple network IDs on your internal network, but you need at least this first network to get started.You want to be able to create a Pointer resource record for the internal IP address of this ISA/DC computer. Click Next. 6. On the Zone file page, accept the default name for the DNS zone file and click Next. 7. On the Completing the New Zone Wizard page, click Finish. 8. In the left pane of the console, right-click on the reverse lookup zone you just created and click Properties. 9. In the reverse lookup zone Properties dialog box, click on the General tab. Click the Down arrow in the Allow dynamic updates drop-down list box. Select the Yes option. Click Apply and then click OK. The next step is to configure the forward lookup zone: 1. Right-click on the Forward Lookup Zone node and click New Zone. Click Next on the Welcome page. 2. On the Zone Type page, select Standard Primary and click Next. 3. On the Zone Name page (Figure 6.9), type in the name you want to use for your Active Directory domain. In this example, our internal network’s domain name is internal.net, so we’ll type in internal.net in the Name text box. Click Next. Figure 6.9 Entering Your Active Directory Domain Name

www.syngress.com


379

4. On the Zone File page, accept the default name for the DNS zone file and click Next. 5. Click Finish on the Completing the New Zone Wizard page. 6. Right-click on the zone you just created and click the New Host command. 7. In the New Host dialog box, type in the host name of this computer, the IP address of the internal interface, and select the Create associated pointer (PTR) record. Click Add Host. An information message appears telling you the record was created. Click OK. Click Done in the New Host dialog box. 8. Check both the forward and reverse lookup zones to confirm that the records were created for this computer. Click Refresh if you don’t see the records. Make sure the Host (A) and Pointer (PTR) records are there before you promote the machine to a domain controller.The domain controller needs these records to properly populate the DNS with Active Directory related entries. Now let’s configure the DNS server and the forward lookup zone properties: 1. Right-click on your DNS server name in the left pane of the DNS console and click Properties. 2. In the server Properties dialog box, click the Interfaces tab. Click the Only the following IP addresses option. Click on the external IP address of this computer and click Remove. Click Apply.The goal here is to remove the external IP address from the list to prevent the DNS server from listening on the external IP address.You want the DNS server to listen only on the internal IP address of this computer. 3. Click the Root Hints tab and confirm that the Root Hints file has been primed.You should see addresses and names for the Internet root servers there. 4. At this point, we won’t get into forwarders, we’ll let the DNS server perform itself. Click OK. 5. Right-click on the forward lookup zone you just created for your domain and click Properties. 6. Click on the General tab. Change the setting for Allow Dynamic Updates to Yes. 7. Click the WINS tab. On the WINS tab, select the Use WINS forward lookup.Type in the IP address of the internal interface of this computer and click Add.

www.syngress.com

380


8. Click the Zone Transfers tab. Remove the check mark from the Allow zone transfers check box.There is no reason to allow zone transfers, because this is the only domain controller and authoritative DNS server in your domain. 9. Click the Name Servers tab. If the IP address of this server is listed as unknown, select your computer name and click Edit. Click Browse in the Edit Record dialog box. Double-click on your computer name, double-click on Forward Lookup Zones, and then double-click on your forward lookup zone. Double-click on your computer name. Click OK and then click Apply. Click OK to close the Properties dialog box. 10. Right-click the server name in the left pane of the console, point to Tasks, and click on the Restart command. Close the DNS console after restarting the DNS server service.

Promoting the Machine to a Domain Controller Now you’re ready to promote the machine to a domain controller.This should go smoothly if the interfaces are configured correctly and you have the DNS server set up right. If you run into problems, first make sure that DNS is configured correctly. If it looks right to you, check the interface configuration. Make sure that the IP addressing information is correct and that the interface order has the internal interface on top. 1. Click Start and click the Run command. 2. In the Run dialog box, type dcpromo in the Open text box. Click OK. 3. Click Next on the Welcome page. 4. Select the Domain Controller for a new domain option and click Next. 5. Select Create a new domain tree and click Next. 6. Select Create a new forest of domain trees and click Next. 7. In the New Domain Name text box, type in the full domain name. For example, if your domain name is internal.net, type internal.net in the text box. Remember that this is the same domain name that you just configured on your DNS server. Click Next. 8. On the NetBIOS Domain Name page, go with the default. Note that if you made your domain name too long, the NetBIOS name might be truncated. If so, you should change your domain name to one with 15 characters or less.This character limit only applies to the leftmost label and not to the top-level domain. Click Next.

www.syngress.com


381

9. On the Database and Log Locations page, make any required changes. In most circumstances, you won’t need to make any changes. Click Next. 10. On the Shared System Volume page, make any required changes. In most circumstances, there’s no reason to make any changes here. Click Next. 11. You might see an information dialog box informing you that the wizard can’t contact a server authoritative for the Active Directory domain.That’s okay. Click OK to continue. 12. On the Configure DNS page, select the No, I will install and configure DNS myself. Don’t allow the Active Directory DNS Wizard to configure the DNS .You don’t need the wizard to do this for you because you’ve already created the zone. Click Next. 13. Select the appropriate permissions for your environment. Since this is the only domain controller and Windows 2000 server on your network, you should select the Permissions compatible only with Windows 2000 Servers option and click Next. 14. Enter your Directory Services Restore Mode password and confirm. Click Next. 15. Review your settings to make sure everything is correct, and then click Next. 16. It should take less than five minutes to complete the Active Directory configuration if everything is configured correctly,. If the DNS zone wasn’t configured correctly or if the interface IP addressing information wasn’t entered correctly, it can take a very long time for Active Directory to be configured. When Active Directory creation and configuration is complete. click Finish on the Completing the Active Directory Installation Wizard page. 17. In the Active Directory Installation Wizard dialog box, click Restart Now. 18. It might take awhile before you can log on to the server after the restart because it’s populating the DNS server zone file with Active Directory related records and doing some last-minute configuration and cleanup tasks. Log on to the domain when the logon dialog box becomes available. 19. Wait about five minutes, and then open the DNS console. Expand the forward lookup zone for your domain and you should see the Active Directory related records. If you see the external IP address listed with a Host (A) address record, remove it. Right-click on the record with the external IP address on it, and click the Delete command.

www.syngress.com

382


20. Right-click on your forward look zone for your domain and click Properties. Click on the General tab. Change the Allow dynamic updates setting to No. Click Apply and then click OK.This prevents the external interface from registering with the DNS. It’s interesting that even when you configure the external interface to not register with the DNS, it continues to do so anyway. Disabling dynamic updates should not pose a problem for a small network that has a single Windows 2000 server and domain controller. You will need to manually enter the names of your internal network clients in the DNS because dynamic update is now disabled.

ISA SERVER DEFCON1 While disabling dynamic updates causes few problems for small networks with a single domain controller, it can be a problem on larger networks. Dynamic DNS (DDNS) is a powerful tool and it allows DNS to pick up where WINS left off. Multihomed domain controllers cause quite a few problems related to name resolution and DDNS. There are several Microsoft Q articles you should refer to if you must enable DDNS, The first is Q292822, which deals with name resolution issues on Windows 2000 domain controllers with DDNS and RRAS installed (which is what your ISA server will be if you allow inbound VPN connections). Q289735 deals with similar issues and contains a Registry entry to prevent VPN clients from shutting down Internet access for your internal network users.

At this point, consider if you want to use a forwarder to resolve Internet host names. As mentioned earlier, you don’t need to use a forwarder; the DNS server can use the Root Hints file and perform recursion.You might want to consider using your ISP’s DNS server as a forwarder if you have a good ISP that maintains its DNS servers. Perform the following steps if you have a lot of confidence in your ISP’s DNS servers: 1. Right-click on your server name and click Properties. 2. In the server Properties dialog box, click the Forwarders tab. 3. On the Forwarders tab, select the Enable forwarders option.Type in the IP address(es) of your ISP’s DNS server(s) and click Add. Place a check mark in the Do not use recursion check box—this improves performance significantly. Click Apply and then click OK. 4. Right-click on your server name, point to All Tasks, and then click the Restart command.This will restart the DNS server service and force the DNS server to use the forwarder. www.syngress.com


383

You should test the DNS server now that it’s configured to use a forwarder.The tests should include queries for local and Internet domains. Perform the following steps to complete the tests: 1. In the DNS console, right-click on your server name and click Properties. 2. In the server Properties dialog box, click on the Monitoring tab. 3. On the Monitoring tab, place a check mark in the A simple query against a DNS server check box.Then, click Test Now.You should see a PASS entry in the Simple Query column.This indicates that the DNS server was able to query itself and resolve a name in one of its authoritative domains. In this case, the domain for which this DNS server is authoritative is your Active Directory domain. 4. Remove the check mark from the A simple query against this DNS server check box. Place a check mark in the A recursive query to other DNS servers check box. Click Test Now.You should see a PASS in the Recursive Query column.This indicates that the DNS server was able to accept a recursive query and respond with a definitive answer. In this case, the query was for a domain for which this DNS was not authoritative.

Installing ISA Server The next step is to install the ISA Server software.We’re often asked whether you should install the ISA Server or the Exchange Server first. From our experience, it doesn’t seem to make much difference. Some people say that you should install Microsoft Server applications in the order in which they were released. If that were true, then you should install Exchange 2000 first and then ISA Server 2000. However, Service Pack 3 for Exchange came out after Service Pack 1 for ISA Server. There aren’t any special steps required when installing ISA Server on the domain controller. However, we’ll go through the procedure just to be thorough. 1. Put the ISA Server CD into the tray and when the autoplay dialog box appears, click the Install ISA Server button. 2. On the Welcome page, click Continue. 3. On the CD Key page, type in your CD Key and click OK. Click OK on the Product ID page. 4. Click I Agree on the license agreement page. 5. Click Full Installation on the setup page.We’ll install everything.You don’t have to use all of the services, and you can disable them if you like.When you

www.syngress.com

384


do a full installation you won’t have to come back and do a reinstall to get the new services installed. 6. Since we haven’t initialized the Active Directory, we can’t join an array. If you’re running SBS, you probably have a single server, so this isn’t an issue. In this example, we’ll run a stand-alone ISA server. Click Yes in the dialog box informing you that it can’t find the schema changes. 7. On the mode page, select the Integrated mode option and click Continue. 8. Click OK in the dialog box informing you that IIS services will be stopped. Note that the dialog box says that you will need to uninstall IIS or reconfigure the WWW service so it does not use TCP port 80.The reason for this is that the Outgoing Web Requests listener uses TCP port 8080 on the internal interface, and Autodiscovery information is published on TCP port 80 (also on the internal interface).You don’t have to worry about ISA Server using TCP port 80 on the internal interface if you won’t be publishing Autodiscovery information. However, the Incoming Web Requests listener will use TCP port 80 if you decide to configure Web publishing rules.We’ll go into more detail on this issue when we configure IIS to publish Outlook Web Access. 9. On the cache size page, set your cache size and click Set. Remember, the cache needs to be placed on an NTFS drive. Optimal cache size varies.We generally start with 100MB and add 10MB per user. Click OK after setting the cache size. 10. On the LAT configuration page, click the Construct Table button. Note how we’ve configured the options in the Local Address Table dialog box (Figure 6.10). Remove the check mark from the Add the following private ranges check box. Place a check mark in the Add address ranges based on the Windows 2000 Routing Table check box and then put a check mark in the check box for the NIC connected to the internal network. Click OK. Click OK in the dialog box that warns you that your LAT is based on the routing table. Click OK, and then click OK again. 11. Setup continues.When it’s finished, click OK to open the ISA Management console. Click OK again to finish. 12. Right-click on the Servers and Arrays node, point to View, and click on the Advanced command.The advanced view gives you a cleaner interface and makes it much easier to work with the ISA Server console. 13. Install ISA Server Service Pack 1 or later as soon as you complete the basic ISA Server installation. Restart the server after installing the ISA Server Service Pack. www.syngress.com


385

Figure 6.10 Configuring the LAT

Packet filtering is enabled by default.You don’t need to worry about DNS query problems because there is a preconfigured DNS packet filter.You can run the DNS query tests again to confirm that the DNS server is still working.

Installing Exchange Server The next step is to install Exchange Server 2000. It might be possible to install Exchange Server 5.5 on the ISA server, but there is no documentation on this issue and we’ve never been called upon to do this type of installation. A compelling reason to use Exchange Server 2000 instead of Exchange 5.5 is that Microsoft plans to stop supporting Exchange 5.5 in the near future.This probably explains why there is no documentation on how to make Exchange 5.5 work on an ISA server machine. The good news is that installing Exchange 2000 on the ISA server is very easy. It’s even easier when the Exchange server is installed on the only domain controller in the domain.You should refer to a good Exchange server book for documentation on how to install and configure Exchange 2000 if you have other Exchange servers or domain controllers in your organization.We won’t go into the details on more advanced installation considerations in this discussion because we assume that you are installing Exchange on the ISA server because you don’t have any other Windows 2000 servers on the network. . Perform the following steps to install Exchange 2000 on the ISA server/domain controller: 1. Put the Exchange 2000 server CD into the tray. In the Setup dialog box, click the Exchange Server Setup icon. 2. Click Next on the Welcome to the Microsoft Exchange 2000 Installation Wizard page. 3. Select the I agree option on the End-User License Agreement page. Click Next. www.syngress.com

386


4. Enter your CD key in the CD key text boxes. Click Next. 5. On the Component Selection page, set the Action to Typical for the Microsoft Exchange 2000 component. If you need other services, you can install them later. Use the Change Folder icon to install the Exchange Server services and message store to another drive. Make your selections and click Next. 6. On the Installation Type page and select the Create a new Exchange Organization option. Click Next. 7. On the Organization Name page, enter an organization name for your Exchange server organization. In this example, we have only one server, so we’ll keep the default name, First Organization. Click Next. 8. Select I agree that I have read and agree to be bound by the license agreement for this product and click Next. 9. Review your choices on the Component Summary page and click Next. This begins the very long Exchange Server installation process. Once the installation finishes, click Finish. 10. Click the Exit link on the Exchange 2000 installation page. Restart the server. 11. After the server restarts, install Exchange Server Service Pack 3. Restart the server after the service pack is installed.

Disabling Socket Pooling for the Exchange Services As you’ve certainly realized by this time, socket pooling is the bane of the ISA Server administrator’s existence.This is especially true when you want to install Exchange 2000 on the ISA Server computer and publish the Exchange 2000 Server services.The good news is that although it takes a little work, you can disable socket pooling for almost all of the Exchange 2000 services. You will need the mdutil utility to disable socket pooling. If you don’t have it, you can download from our FTP site at ftp.tacteam.net/isaserver. After you download the utility, move it to the root directory of the C: drive (it doesn’t have to be placed there, it’s just a convenient place to put it). Perform the following steps to disable socket pooling for all of the Exchange Server services that we’ll be publishing: 1. Stop the mail services before disabling socket pooling. Open a command prompt and run the following commands: net stop w3svc net stop msftpsvc

www.syngress.com


387

net stop smtpsvc net stop nntpsvc net stop pop3svc net stop imap4svc

2. We can get to the work of disabling socket pooling now that the mail services are stopped. As you learned earlier, there are two methods used to disable socket pooling: scripts and the mdutil utility.To stop the WWW service, open a command prompt and go to the \Inetpub\AdminScripts directory. Once in that directory, run the following command: cscript adsutil.vbs set w3svc/disablesocketpooling true

3. To disable the FTP service, run the following command: cscript adsutil.vbs set msftpsvc/disablesocketpooling true

4. While still in the command prompt window, change the focus to the C: drive. Then, run the following commands: mdutil set -path smtpsvc/1 -value 1 -dtype 1 -prop 1029 -attrib 1

mdutil set -path nntpsvc/1 -value 1 -dtype 1 -prop 1029 -attrib 1

mdutil set -path pop3svc/1 -value 1 -dtype 1 -prop 1029 -attrib 1

mdutil set -path imap4svc/1 -value 1 -dtype 1 -prop 1029 -attrib 1

5. The last service you need to disable socket pooling for is secure Web services (SSL listener). Go to the \Inetpub\Adminscripts folder and run the following command: adsutil set w3svc/1/securebindings ""

6. You will see a dialog box that says This script does not work with WScript. Click OK.The next dialog box asks if you want to register CScript as your default host for VBscript. Click Yes. Click OK on the Successfully registered CScript dialog box. Now run the adsutil set w3svc/1/ securebindings “” script again. The services continue to run on all interfaces and all IP addresses, even though we have disabled socket pooling.The reason is that the services’ default configuration is to

www.syngress.com

388


listen on all interfaces.We need to change those default settings by going into the Internet Services Manager and the Exchange System Manager. Perform the following steps to configure the listeners for the WWW and FTP services: 1. Open the Internet Services Manager from the Administrative Tools menu. 2. Right-click on the Default FTP Site entry in the left pane of the console and click Properties. 3. In the Default FTP Site Properties dialog box, change the IP Address from (All Unassigned) to the IP address on the internal interface of the ISA server. Click Apply and then click OK. 4. Right-click on the Default Web Site entry in the left pane of the console and click the Properties command. 5. On the Web Site tab, change the IP address from (All Unassigned) to the IP address on the internal interface of the ISA server. Click Apply and then click OK. 6. Click the Administration Web Site entry in the left pane of the console and click the Properties command. 7. On the Web Site tab, change the IP Address from (All Unassigned) to the internal IP address on the ISA server. Click Apply and then click OK. That takes care of the FTP and Web sites. If you want to run other Web sites, make sure that when you create the new Web site that it listens only on the internal interface of the ISA server. We also need to configure the NNTP, SMTP, POP3, and IMAP4 services.These services are configured in the Exchange System Manager. Remember that you won’t be able to publish Exchange RPC services because you can’t disable socket pooling for the RPC endpoint mapper. Perform the following steps to configure the remainder of the Exchange services: 1. Click Start and point to the Programs menu. Point to the Microsoft Exchange menu and click the System Manager command. 2. In the Exchange System Manager, expand the Servers node, then expand the server name, and then expand the Protocols node. Expand the IMAP4 node and then right-click on the Default IMAP4 Virtual Server entry and click the Properties command. 3. In the Default IMAP4 Virtual Server Properties dialog box, change the IP Address from (All Unassigned) to the IP address of the internal interface of the ISA server. Click Apply and then click OK. www.syngress.com


389

4. Expand the NNTP node in the left pane of the console. Right-click on the Default NNTP Virtual Server entry and click Properties. 5. In the Default NNTP Virtual Server Properties dialog box, change the IP address from (All Unassigned) to the IP address on the internal interface of the ISA server. Click Apply and then click OK. 6. Expand the POP3 node and right-click on the Default POP3 Virtual Server entry. Click the Properties command. 7. Change the IP address from (All Unassigned) to the internal IP address on the ISA server. Click Apply and then click OK. 8. Expand the SMTP node and right-click on the Default SMTP Virtual Server entry. Click the Properties command. 9. IN the Default SMTP Virtual Server Properties dialog box, change the IP address from (All Unassigned) to the internal IP address on the ISA server. Click Apply and then click OK. All the services are now configured to listen only on the internal interface. Let’s restart all the services from the command prompt.While in the command prompt, run each of the following commands: Net start w3svc Net start msftpsvc Net start nntpsvc Net start smtpsvc Net start pop3svc Net start imap4svc

To confirm that the services are listening only on the internal interface, run the following commands: Netstat –na | find ":21" Netstat –na | find ":25" Netstat –na | find ":80" Netstat –na | find ":110" Netstat –na | find ":119" Netstat –na | find "143"

You should find that the services are listening only on the internal interface.

www.syngress.com

390


Configure Server Publishing Rules to Publish the Exchange Services With socket pooling disabled and the services configured to listen only on the internal interface, you’re now ready to create the server publishing rules.The following services on the ISA server are candidates for publishing: ■

FTP server

■

Web server

■

POP3 server

■

SMTP server

■

NNTP server

■

IMAP4 server

We won’t cover FTP server publishing, since that has nothing to do with Exchange mail services.We’ll cover Web server publishing in the section on Outlook Web Access. That leaves POP3, SMTP, NNTP, and IMAP4 publishing. Let’s go through the procedure for publishing each of these services.

SMTP Server Publishing Rule Publishing the Exchange 2000 SMTP server works the same as publishing the IIS 5.0 SMTP server discussed earlier in this chapter.You need to configure remote domains for the mail domains under your administrative control, and you need to configure the relay characteristics so that you’re not running an open relay. Make sure you review the material on publishing the IIS 5.0 SMTP earlier in this chapter before publishing the Exchange 2000 SMTP service. Perform the following steps to publish the Exchange 2000 SMTP service: 1. Open the ISA Management console, expand your server name, and then expand the Publishing node. Right-click on Server Publishing Rules, point to New and click Rule. 2. On the Welcome to the New Server Publishing Rule Wizard page, type in a name for the rule. Click Next. 3. On the Address Mapping page, type in the IP address of the internal interface of the ISA server in the IP address of internal server text box. Click Browse and select the external IP address on the ISA server on which you want to accept SMTP requests. Click Next. 4. On the Protocol Settings page, select the SMTP Server protocol definition and click Next. www.syngress.com


391

5. On the Client Type page, select the client type you want to support.The typical selection is Any request, since anonymous SMTP servers on the Internet will need to forward mail to your mail domains. Make your selection and click Next. 6. Review you settings on the Complete the New Server Publishing Rule Wizard page and click Finish. We always like to do a quick check on our server publishing rules by using telnet from an external network client. If you have a Windows 2000 client on the external network, open a command prompt and type telnet 25.You should see something like what appears in Figure 6.11.Type help to see the list of commands supported by the SMTP server, and type quit to exit the telnet session. Figure 6.11 Telnet to the Publishing SMTP Server

POP3 Server Publishing Rule The POP3 server publishing rule allows external network users access to the Exchange 2000 server’s POP3 Server component .This is useful when external users need to get e-mail from their message store and they don’t have access to an Outlook MAPI connection. Users can configure Outlook 2000/XP, Outlook Express, or any other e-mail client to access POP mail services on the Exchange 2000 server. There are some disadvantages to using POP3 to receive e-mail.The POP3 client will pull all mail out of the Inbox store if the POP3 client isn’t configured to leave the mail on the server.We’ve seen many occasions where the user was shocked when he returned to the office and found that there was no mail in his inbox after opening www.syngress.com

392


Outlook 2000/XP. Another consideration is that username and password information is passed as clear text.You can fix this problem by requiring SSL to connect to the POP3 server. Perform the following steps to publish the POP3 server: 1. Open the ISA Management console, expand your server name, and then expand the Publishing node. Right-click on Server Publishing Rules, point to New, and click Rule. 2. On the Welcome to the New Server Publishing Rule Wizard page, type in a name for the rule. Click Next. 3. On the Address Mapping page, type in the IP address of the internal interface of the ISA server in the IP address of internal server text box. Click Browse and select the external IP address on the ISA server on which you want to accept POP3 requests. Click Next. 4. On the Protocol Settings page, select the POP3 Server protocol definition and click Next. 5. On the Client Type page, select the client type you want to support.The typical selection is Any request, since you usually can’t tell where the external users are located in advance. Make your selection and click Next. 6. Review your settings on the Complete the New Server Publishing Rule Wizard page and click Finish. Use telnet to check that the server publishing rule worked.

NNTP Server Publishing Rule The Exchange NNTP server can be used to host your organization’s newsgroups. While the NNTP service provided by Exchange 2000 isn’t a full-featured NNTP server, it does provide an excellent platform for sharing information in a threaded environment. Newsgroups are fast and they’re easy to search.While many sites now offer newsgroup-like features in a Web-based format, they’ll never be as fast or as efficient as the traditional News server. Perform the following steps to publish the NNTP service: 1. Open the ISA Management console, expand your server name, and then expand the Publishing node. Right-click on Server Publishing Rules, point to New, and click Rule. 2. On the Welcome to the New Server Publishing Rule Wizard page, type in a name for the rule. Click Next.

www.syngress.com


393

3. On the Address Mapping page, type in the IP address of the internal interface of the ISA server in the IP address of internal server text box. Click Browse and select the external IP address on the ISA server on which you want to accept NNTP requests. Click Next. 4. On the Protocol Settings page, select the NNTP Server protocol definition and click Next. 5. On the Client Type page, select the client type you want to support.The typical selection is Any request, since you probably don’t know the IP addresses of your NNTP clients. Make your selection and click Next. 6. Review your settings on the Complete the New Server Publishing Rule Wizard page and click Finish. Use telnet to confirm that the server publishing rule worked.

IMAP4 Server Publishing Rule The IMAP4 service allows you to connect IMAP4 clients to the Exchange 2000 message store. IMAP4 clients can download a list of mail headers without downloading the entire e-mail message.This is an ideal solution for users with low bandwidth connections. Another advantage of IMAP is that if you use Outlook 2000/XP to create subfolders off the main Inbox folder, you can use the IMAP4 protocol to access information in those folders.This is a great advantage over POP3 access because POP3 clients can only download mail contained in the Inbox; POP3 clients cannot download mail contained in subfolders under the main Inbox folder. If you use filtering rules to move mail automatically from the Inbox to subfolders, the POP3 client will not be able to retrieve sorted mail. Outlook Express provides basic IMAP4 support. Perform the following steps to publish the IMAP4 service: 1. Open the ISA Management console, expand your server name, and then expand the Publishing node. Right-click on Server Publishing Rules, point to New, and click Rule. 2. On the Welcome to the New Server Publishing Rule Wizard page, type in a name for the rule. Click Next. 3. On the Address Mapping page, type in the IP address of the internal interface of the ISA server in the IP address of internal server text box. Click Browse and select the external IP address on the ISA server on which you want to accept IMAP4 requests. Click Next. 4. On the Protocol Settings page, select the IMAP4 Server protocol definition and click Next.

www.syngress.com

394


5. On the Client Type page, select the client type you want to support.The typical selection is Any request, since it’s unlikely that you’ll know the IP addresses of your IMAP4 clients in advance. Make your selection and click Next. 6. Review your settings on the Complete the New Server Publishing Rule Wizard page and click Finish. Use telnet to confirm that the server publishing rule worked.

Secure Services Publishing The publishing rules we created so far work fine, but they all suffer from the same major drawback: all information is sent “in the clear.”When users access NNTP, IMAP4, SMTP, and POP3 resources, anyone with a packet sniffer will be able to see the contents of the communications.You won’t want to allow this if you keep secure information on your Exchange server. You can solve this problem by allowing only secure communications with the POP3, NNTP, and IMAP4 services.You could even configure SMTP access to be secure, but if you’re publishing your SMTP server to allow Internet SMTP servers to send mail for your mail domains, you won’t be able to enforce secure communications. Internet mail servers aren’t configured to enforce secure communications, so any attempt to secure SMTP communications at the mail server level will fail for anonymously accessible SMTP servers. However, if you create a second SMTP virtual server for your employees to send mail to, you can enforce secure communications on that server.You can enforce secure communications with the SMTP server when you have administrative control over the users. We’ll assume that you’ve secured your perimeter, so you don’t have to worry about someone planting a packet sniffer there.What about your remote users? Suppose your salespeople call the mail server to retrieve mail via POP3 or SMTP from a hotel room that has broadband access. Or maybe they need to obtain private company information from your NNTP server.While your own perimeter might be secure, you have no assurances that the networks external users are connecting from are secure. You’ll need to assign certificates to the services you want to make secure.You can create your own certificates or use a third-party certificate provider. Since the services are meant for your own employees and not for Internet users at large, in most cases you’ll want to create your own certificates. You can install the Microsoft Certificate Server in enterprise or stand-alone mode. One of the advantages of enterprise mode is you can use the MMC to obtain certificates from the certificate server.The disadvantage is that not all certificate templates are available via the Web-based enrollment site.The stand-alone Certificate Server supports all templates, but you can’t use the MMC to obtain certificates. For detailed and

www.syngress.com


395

comprehensive discussions of Microsoft Certificate Server, check out Chapters 12 and 13 in this book. We are assuming that you have a single Windows 2000 server, since you’re installing Exchange 2000 on the ISA server. In this case, you’ll need to install the certificate server on the ISA/Exchange server. Perform the following steps to install the enterprise root certificate server on the ISA server computer: 1. Open the Add/Remove Programs applet from the Control Panel. 2. In the Add/Remove Programs window, click Add/Remove Windows Components. 3. In the Windows Components dialog box, put a check mark in the Certificate Services check box. Click Yes in the dialog box that informs you that you can’t change the name of the server while certificate services is installed. Click Next. 4. In the Terminal Services setup dialog box, select the Remote Administration mode option and click Next. 5. On the Certification Authority Type page, select the Enterprise root CA option and click Next. 6. On the CA Identifying Information page (Figure 6.12), enter the information required for each field.While only the CA name field is required, you should enter valid information in each field just in case you want to perform certificate mapping based on this certificate in the future. Click Next. Figure 6.12 The CA Identifying Information Page

7. On the Data Storage Location page, leave the default settings as they are unless you have a compelling reason to change them. One reason to do so would be that your C: drive is lacking in space. Click Next to continue. Click OK in the dialog box informing you that IIS must be stopped. www.syngress.com

396


8. You might be asked for the Windows 2000 CD. Put the CD into the drive and follow the installer’s instructions. 9. Click Finish on the Completing the Windows Components Wizard page. Restart the server after installing certificate services.

Assign Certificates to the Exchange Services You can enforce secure communications with the SMTP, POP3,Web, and IMAP4 services.You can’t enforce secure communications with the FTP service using server publishing rules (although you can do so using Web publishing rules and then using protocol redirection within those rules).You’ll need to assign certificates to each of the services to allow secure links with the external clients. The Web server is assigned a certificate via the Internet Information Services console.The remainder of the services are assigned certificates via the Exchange Management console. Let’s start with assigning a certificate to the Web site.You’ll use this Web site certificate later when configuring secure access to the Outlook Web Access (OWA) site. 1. Open the Internet Services Manager from the Administrative Tools menu. 2. In the Internet Information Services console, expand your server name. Right-click on Default Web Site and click Properties. 3. On the Default Web Site Properties dialog box, click on the Directory Security tab. In the Secure Communications frame, click Server Certificate. 4. Read the text on the Welcome to the Web Server Certificate Wizard page and click Next. 5. On the Server Certificate page, select the Create a new certificate option and click Next. 6. On the Delayed or Immediate Request page, select the Send the request immediately to an online certification authority option and click Next. You have the option to send the request immediately to an online certificate authority because you have an enterprise root certificate server in your domain.You would not have this option if your only certificate server were a stand-alone certificate server. 7. On the Name and Security Settings page, type in a “friendly” name for the Web site certificate in the Name text box.The default name is good to use, and it will set this certificate apart from other Web sites you configure on this server.The bit length is set to 512 by default. Leave the default unless you have reasons to enforce a higher level of encryption. Click Next. www.syngress.com


397

8. On the Organization Information page, type in your Organization name and Organizational unit name in the Organization and Organizational Unit test boxes. 9. On the Your Site’s Common Name dialog box, type in the name that external users will use to access your Web site. As you saw in the last chapter, if you don’t type in the exact name, error dialog boxes will appear when clients attempt to access the site.Type in the name for your Web site and click Next. 10. On the Geographical Information page, select your Country/Region, and then type in your State/province and City/locally in the text boxes. Click Next. 11. Your certificate authority will appear in the drop-down list box on the Choose a Certification Authority page. Click Next. 12. Review the settings on the Certificate Request Submission page and click Next. 13. Read the text on the Completing the Web Server Certificate Wizard page and click Finish. 14. When you return to the Default Web Site Properties dialog box, you’ll see that the View Certificate and Edit buttons are available.This confirms that the certificate has been assigned to the Web site. Click OK to close the dialog box. The remainder of the services are assigned certificates via the Exchange System Manager. Assign certificates for the IMAP4, NNTP, POP3, and SMTP services here. Perform the following steps to install a certificate on to the IMAP4 service: 1. Open the Exchange System Manager. Expand your server name and then expand the IMAP4 node. Right-click on the Default IMAP4 Virtual Server and click Properties. 2. On the Default IMAP4 Virtual Server Properties dialog box, click on the Access tab. On the Access tab, click Certificate in the Secure communication frame. Read the text on the Welcome to the Web Server Certificate Wizard frame and click Next. 3. On the Server Certificate dialog box, select the create a new certificate option.You have the option to assign an existing certificate, but you have more options available to you if you assign each service a separate certificate. There’s no negative effect on the clients, since they’ll all have the same certificate authority in their trust list. Click Next.

www.syngress.com

398


4. On the Delayed or Immediate Request page, select the Send the request immediately to an online certificate authority option and click Next. 5. On the Name and Security Settings page, enter a friendly name for the IMAP4 server certificate or accept the default settings.The default setting should work fine if you’re running a single IMAP4 server on this machine. Click Next. 6. On the Organization Information page, the settings that you entered during the Web site certificate enrollment is already entered.You can keep this information unless you have a reason to do otherwise. Click Next. 7. On the Your Site’s Common Name page, type in the name of the site. For example, here we’ll use the name imap4.internal.net. After entering the name of the site, click Next.The site’s name is important.You need to configure the IMAP4 clients to use the common name of the IMAP4 server and not the IP address.You will see an error on the IMAP4 client if you configure the client to use the IP address of the server in the Client Configuration dialog box.You need to use an FQDN that is the same as the common name you enter on this page. 8. On the Geographical Information page, the information you entered during Web site enrollment is already entered.You can use this information unless you have a reason not to. Click Next. 9. Your certificate server appears on the Choose a Certificate Authority page. Click Next. 10. Review the settings on the Certificate Request Submission page, and click Next. 11. Click Finish on the Completing the Web Certificate Wizard page. 12. Click OK in the Default IMAP4 Virtual Server dialog box. Repeat these steps to obtain certificates for the default NNTP, POP3, and SMTP virtual servers. While you can obtain a certificate for the default SMTP virtual server, you should not use the certificate for that server if it is being used to accept incoming messages from public SMTP servers. However, you might want to use an SMTP service certificate if you want to create a second SMTP virtual server on the Exchange server for your external users to use for their outbound mail server. All of these Exchange service certificates are stored in the ISA/Exchange server’s machine certificate store.You can open a Certificates MMC for the local machine store and you’ll see all of the Exchange service certificates there.

www.syngress.com


399

Creating Server Publishing Rules for Secure Communications with Exchange Services You can configure secure communications with the Exchange services after the certificates are installed.The default settings on the services allow both secure and nonsecured communications.You can configure the services to force SSL connections. It’s good to force secure communications at the server; if you don’t, you’re leaving it up to the clients to force the secure channel. You can force a secure channel for the POP3, SMTP, and IMAP4 services.The NNTP service allows secure communications, but you cannot force a secure channel at the server.You have to depend on the client to use a secure channel. Perform the following steps to force a secure channel with the Exchange POP3 server: 1. Open the Exchange System Manager. Expand the Servers node, and then expand your server name. Expand the Protocols node, and then expand the POP3 node. Right-click on the Default POP3 Virtual Server node and click Properties. 2. In the Default POP3 Virtual Server Properties dialog box, click on the Access tab. On the Access tab, click Communication in the Secure communication frame. 3. In the Security dialog box (Figure 6.13), put a check mark in the Require secure channel check box. Put a check mark in the Require 128-bit encryption check box if your clients support 128-bit encryption. Click OK. Figure 6.13 Forcing a Secure Channel to the POP3 Service

4. Click Apply and then click OK in the Default POP3 Virtual Server Properties dialog box. Follow the same procedure for the default IMAP4 and SMTP virtual servers.You don’t have the option to force a secure channel with the NNTP server. However, you can create a server publishing rule that only allows access via the secure channel. If users try to connect to the server via an open channel (i.e., non-SSL), the connection attempt will fail because there won’t be a server publishing rule to support it. . www.syngress.com

400


ISA SERVER DEFCON1 Secure SMTP server publishing does not require a separate server publishing rule. If you have a regular SMTP server publishing rule enabled, external network clients will be able to use that rule for both open and secure SMTP communications. The Exchange 2000 SMTP service employs an “in-band” security subsystem, allowing it to service SSL connections at the default SMTP service port, TCP 25. All other Exchange services (HTTP, POP3, NNTP, and IMAP4) require a dedicated port for SSL communications. Create only secure server publishing rules for those protocols you want to use secure communications only. For example, if you want to allow only secure POP3 access, do not create a server publishing rule that allows non-secure POP3 access.

Configure Services “Publishing” with Packet Filters You can also publish Exchange Server services on the ISA server by using packet filters instead of server publishing rules.The advantage of using packet filters is that you don’t have to disable socket pooling; the only requirement is a simple packet filter.The disadvantage of packet filters is that you can’t leverage features provided by application filters.This lessens the security provided by publishing servers, since the ISA server does not examine the incoming packets for anything more than source and destination IP address and port number. Create the packet filters listed in Table 6.1 on the ISA/Exchange server to support Exchange Server services publishing if you want to avoid creating server publishing rules. Table 6.1 Packet Filters for Exchange Services Publishing Protocol

IP Protocol

NNTP TCP IMAP4 TCP SMTP TCP POP3 TCP Secure NNTP TCP Secure POP3 TCP Secure IMAP TCP

www.syngress.com

Protocol Number

Direction

Local Port Number

Local Port

6 6 6 6 6 6 6

Inbound Inbound Inbound Inbound Inbound Inbound Inbound

119 143 25 110 563 995 993

Fixed Fixed Fixed Fixed Fixed Fixed Fixed

Remote Port Port Port Port Port Port Port Port

All All All All All All All

ports ports ports ports ports ports ports


401

Although you can use packet filters, we recommend that you use the server publishing rule method. Server publishing rules work, and they provide a higher level of security—and isn’t a higher level of security the reason why you purchased ISA Server?

ISA SERVER ALERT You don’t have manually create all of these packet filters. The Secure Mail Publishing Wizard will automatically create all of these packet filters for you. You need to tell the wizard that the server is on the ISA server. The server creates packet filters instead of server publishing rules when it knows that the Exchange server is on the ISA server.

Publishing Outlook Web Access on the ISA Server If there’s one issue that generates the most questions regarding ISA Server configuration, it’s how to configure Outlook Web Access (OWA) to work on the ISA server.The fact is that it’s not that hard to get OWA to work; the problem is that there are many details you have to take care of in order to make it work correctly. Many of the problems people had with OWA on the ISA server were related to issues with the Exchange server prior to Exchange Service Pack 3. Once you install Exchange Service Pack 3, the procedure is straightforward. You need to address the following issues when publishing OWA: ■

Assign a certificate to the Web site

■

Configure the SSL listening port on the default Web site

■

Configure authentication properties on the OWA folders

■

Force a secure channel on the OWA folders

■

Create the OWA Web publishing rule that forces a secure connection

■

Configure user rights on the domain controller

We already assigned a certificate to the Web site when we ran the Web Publishing Wizard for the default Web site. Let’s look at the rest of the OWA Web publishing details now.

Configure the SSL Listening Port on the Default Web Site The default Web site has a certificate.The problem is you won’t be able to use that certificate for secure communications until you configure the Web site with a port number www.syngress.com

402


to listen for secure requests. Perform the following steps to create the secure services listening port: 1. Click on the Internet Services Manager link on the Administrative Tools menu. 2. In the Internet Information Services console, expand your server name and then right-click on the Default Web Site. Click on the Properties command. 3. In the Default Web Site Properties dialog box, type 443 in the SSL Port text box. Click Apply and then click OK. Now run a netstat –na | find “:443” from the command prompt.You should see that only the internal interface is listening on TCP port 443.The incoming Web Requests listener will need to use TCP 443 on the external interface.

Configure Authentication Methods on the OWA Folders You can use either basic or integrated authentication to authenticate against the OWA Web site.The problem with integrated authentication is that Internet Explorer 5.0x cannot use integrated authentication when accessing Web sites through the ISA server, and there are various problems with pre-SP1 versions of Internet Explorer 6.0.There might be reasons why your organization wants to run Internet Explorer 5.0x and preService Pack 1 Internet Explorer 6.0.You could go ahead and upgrade all the browsers in your organization to Internet Explorer 6.0 Service Pack 1, or you can forego integrated authentication and use basic authentication instead. The primary concern with basic authentication is that username and password information is sent in the clear.We can get around that problem by using secure SSL links.The secure channel is created before any credentials are sent over the wire when you force SSL connections to the OWA site,.This obviates the security weakness inherent in using basic authentication over a public network. Perform the following steps to configure authentication for the OWA sites: 1. Return to the Internet Information Services console. Make sure that your server name and the Default Web Site are expanded.The first thing you might notice is that several of the folders have red STOP signs on them. For some reason, the Exchange virtual folders don’t initialize properly during system startup.We’ll leave that to the Exchange gurus to explain why this happens, but all we’re concerned with is getting them to work. Click Stop in the MMC button bar and then click Start. Now, click Refresh.You will see the STOP signs change into virtual directory icons.

www.syngress.com


403

2. Right-click on the Exchweb virtual directory and click the Properties command. Click Edit in the Anonymous access and authentication control frame. Remove the check mark from the Anonymous access check box. Remove the check mark from the Integrated Windows authentication check box. Place a check mark in the Basic authentication (password is sent in clear text) check box. Click Yes in the dialog box explaining that usernames and passwords are passed in clear text if you don’t use SSL. Click Edit. In the Basic Authentication Domain dialog box, click Browse. In the Browse for Folder dialog box, expand the Entire Network entry. Expand the Microsoft Windows Network icon. Click on the Domain name for your domain and click OK. Click OK in the Basic Authentication Domain dialog box. Click OK in the Authentication Methods dialog box. 3. Click Apply in the Exchweb Properties dialog box. In the Inheritance Overrides dialog box, click Select All and click OK. Click OK in the Exchweb Properties dialog box. Perform steps 2 and 3 for the following virtual directories: ■

Public

■

Exchange

■

Exadmin

A very common problem is the inability to change passwords via the OWA browser interface, the reason being that this feature is not enabled by default when you install Exchange 2000. In order to change passwords, you need to create a virtual directory for the IISADMPWD physical directory. Another requirement is that all communications with the IISADMPWD virtual directory must be via SSL.We’ll take care of those issues by forcing the Web Proxy service to use SSL to connect to all virtual folders. Perform the following steps to create the virtual directory: 1. Right-click on the Default Web Site. Point to New and click on Virtual Directory. 2. Click Next on the Welcome to the Virtual Directory Creation Wizard page. 3. On the Virtual Directory Alias page, type IISADMPWD in the Alias text box. Click Next. 4. On the Web Site Content Directory page, type in the path DRIVE:\ SYSTEMROOT\system32\inetsrv\iisadmpwd. Replace DRIVE with the drive your system root directory is located on, and replace SYSTEMROOT

www.syngress.com

404


with the name of the root directory for your system files.The default for Windows 2000 is WINNT. Click Next. 5. On the Access Permissions page, select the following check boxes: Read, Run scripts (such as ASP), and Execute (such as ISAPI applications or CGI). Click Next. 6. Click Finish on the You have successfully completed the Virtual Directory Creation Wizard page. 7. Change the authentication method for this virtual directory to match the permissions you set on the other OWA directories.

Force a Secure Channel to the OWA Folders You don’t have to force a secure channel to all of the OWA Web folders.The only folder requiring a secure channel from the Web Proxy service to the Web site is the IISADMPWD virtual directory. Access to the other OWA directories can be bridged as HTTP.The steps are the same for each virtual directory. Perform the following steps to force a secure channel to the IISADMPWD virtual directory: 1. Right-click on the IISADMPWD folder and click Properties. 2. Click on the Directory Security tab in the IISADMPWD Properties dialog box. 3. Click Edit in the Secure Communications frame. 4. In the Secure Communications dialog box, place a check mark in the Require secure channel (SSL) check box. 5. Click OK in the Secure Communications dialog box. Click Apply and then click OK in the IISADMPWD dialog box. You can use the same procedure to enforce secure communications with other OWA virtual directories.You might want to do this when the OWA site is on the internal network and you don’t completely trust your internal network.We’ll cover that scenario later in this chapter.

Configuring the Incoming Web Requests Listener and the Web Publishing Rule We want to use an SSL link to the Incoming Web Requests listener on the external interface of the ISA server in order to ensure a high level of security,.The first thing you need to do is bind the Web server certificate to the Incoming Web Requests www.syngress.com


405

listener.This allows the listener to impersonate the Web site and create a secure channel with the browser client. Perform the following steps to create the Incoming Web Requests listener and bind the certificate to the listener: 1. Open the ISA Management console, right-click your server name, and click the Properties command. 2. On the server Properties dialog box, click on the Incoming Web Requests listener tab. Select the Configure listeners individually per IP address option. Click Add. 3. In the Add/Edit Listeners dialog box, select your server name in the Server drop-down list box. Select the external IP address on the ISA server in the IP Address drop-down list box. Put a check mark in the Use a server certificate to authenticate to web clients check box. Click Select.You’ll see a number of certificates in the Select Certificate dialog box if you obtained certificates for several of the Exchange mail services. Select the certificate that you created for the Web site and click OK. 4. Click OK in the Add/Edit Listeners dialog box. 5. Put a check mark in the Enable SSL listeners check box. Click OK in the SSL Listeners dialog box. Click Apply in the server Properties dialog box. Select the Save the changes and restart the services(s) option and click OK. Click OK in the server Properties dialog box. Open a command prompt, run an netstat –na | find “:443”, and you’ll find that now both internal and external IP addresses are listening on TCP port 443 (Figure 6.14). Note that this is not the same as socket pooling. Different sockets are being used by the listener and the Web site. You can create the secure Web Publishing Rule now that the Incoming Web Requests listener is configured.The first decision you have to make before creating the rule is what type of destination set you want to use.The easiest approach is to create a destination set for the FQDN of the server and apply this destination set to the OWA Web publishing rule.This destination set does not use paths. A destination set without any paths works fine if you don’t plan on publishing any other Web sites on the same server. However, if you want to make other content available on the same server, and you do not want to require an SSL connection to that content, then this approach won’t work. In that scenario, you’ll have to create a destination set for OWA that contains only the OWA directories.

www.syngress.com

406


Figure 6.14 Internal and External IP Addresses Listen for Secure Communications

If you want to create a destination set that applies only to the OWA directories, the destination set includes your FQDN and the following paths: ■

/exchweb/*

■

/exchange/*

■

/public/*

■

/iisadmpwd*

■

/_AuthChangeUrl*

The /_AuthChangeUrl* entry allows you to change your password via the OWA interface. Note that there is no slash at the end of the path, as there are a number of characters after this string.This isn’t a virtual directory, so don’t worry about trying to find it. It is something that appears in the Web Proxy logs, so you need to allow access to it. If you just include the /_AuthChangeUrl* entry with an asterisk, it will allow us to access files used for OWA online password changes. Perform the following steps to create the destination set: 1. In the ISA Management console, expand your server name, and then expand the Policy Elements node. Right-click on Destination Sets, point to New, and click Set. 2. On the New Destination Set dialog box, type OWA for the name of the destination set. Click Add.

www.syngress.com


407

3. In the Add/Edit Destination dialog box, select the Destination option. Type in the FQDN for your site in the text box. In the Path text box, type /exchweb*. 4. Click OK in the Add/Edit Destination dialog box. Repeat steps 3 and 4 four more times, adding the /exchange*, /public*, /iisadmpwd*, and /_AuthChangeUrl* paths. 5. Click OK in the New Destination Set dialog box. You can create Web publishing rules now that you have the destination set: 1. In the ISA Management console, expand your server name, and then expand the Publishing Rule node. Right-click on Web Publishing Rules, point to New, and click Rule. 2. On the Welcome to the New Web Publishing Rule Wizard page, type in the name of the rule and click Next. 3. On the Destination Sets page, select the Specified destination set option from the Apply this rule to drop-down list box, and then select your OWA destination set from the Name drop-down list box. Click Next. 4. On the Client Type page select Any request. Users will authenticate with the Web site, so you don’t need to authenticate against the Incoming Web Requests listener as well. In fact, it will not work if you try to authenticate with both the Incoming Web Requests listener and the Web site. Click Next. 5. On the Rule Action page, select the Redirect the request to this internal Web server (name or IP address) option.Type in name of the Web site in the text box.You must use the same name the user uses to access the site. If you have your DNS servers set up to handle this FQDN, you can allow the ISA server to resolve the name. If you don’t, you must put the FQDN for the site in the HOSTS file and match it up with the IP address of the internal interface of the ISA server. For example, in this rule, the external user types in the FQDN www.internal.net.We’ll also put www.internal.net in the text box for the redirection.Then we’ll create a HOSTS file entry for www.internal.net that resolves to the internal IP address of the ISA server. Select the original host header check box. Click Next. 6. Click OK on the last page of the wizard. 7. Double-click on the Web publishing rule you created. In the rule’s Properties dialog box, click on the Bridging tab. On the Bridging tab, put a check mark in the Require secure channel (SSL) for published site check box.

www.syngress.com

408


Put a check mark in the Require 128-bit encryption check box if all of your clients support 128-bit encryption,. Click Apply and then click OK. 8. One last quick step: go back to the Internet Information Services console and restart the default Web site.

Configuring User Rights on the Domain Controller You might wonder why we need to cover the issue of user rights in a discussion of OWA. Can’t all users access the OWA machine? In most cases, you don’t have to address this issue because the users can access OWA as soon as you complete the Web publishing rules.We run into problems when the OWA machine is also a domain controller. Not all users are allowed to log on to a domain controller. A user should have the “log on locally” right to access resources on a Web site. Usually, the IUSR_MACHINE account has the “log on locally” right required to access any Web site.The problem is that you’re not depending on the IUSR account; your users need to log on with their own user accounts.The default domain controller security policy does not allow all users to log on locally. If the OWA user can’t log on locally, he will not be able to access the OWA site on the ISA Server machine.

ISA SERVER DEFCON1 There is conflicting documentation regarding whether the “log on locally” right is required to access Exchange 2000 OWA sites. Article Q319888 “Access Is Denied Error Message Logging On to OWA” indicates that you must assign users who intend to connect to OWA sites the “log on locally” right. However, Q311422 “Log On Locally Right Not Required for Exchange 2000 OWA” says that you only need to allow users the “access this computer from the network” right. There are some variables that Q311422 doesn’t take into account, so we recommend allowing OWA users the “log on locally” right. It is important to point out that it is not good general security practice to allow non-administrative users the “log on locally” right to the domain controller. However, in our “all but the kitchen sink on the ISA server” scenario, we have to deal with a number of security compromises.

You can fix the problem by changing the domain controller security policy. It’s usually not a good idea to allow everyone to log on to a domain controller. Under normal circumstances, only administrators should be able to log on locally to a domain controller.When OWA is installed on the DC, you don’t have a choice; the users must be able to log on locally.You can give all domain users permissions to log on locally, or

www.syngress.com


409

you can create a separate group of users who need access to OWA, and grant that group the right to log on locally. Perform the following steps to grant the “log on locally” right: 1. From the Administrative Tools menu, open the Active Directory Users and Computers console. 2. In the Active Directory Users and Computers console, expand you domain name, and then right-click on the Domain Controllers node. Click the Properties command. 3. In the Domain Controllers Properties dialog box, Click on the Group Policy tab. On the Group Policy tab, click on the Default Domain Controllers Policy and click Edit. 4. In the Group Policy dialog box, expand the Computer Configuration node and then expand the Windows Settings node. Expand the Security Settings node and then expand the Local Policies node. Click on the User Rights Assignment node. 5. In the right pane of the User Rights Assignment node, find the Log on Locally right. Double-click on Log on Locally. In the Security Policy Setting dialog box, click Add.Type in the Group name in the Add user or group dialog box, or click Browse to find the user or group. Once the user or group is entered, click OK in the Add user or group dialog box. Click OK in the Security Policy Setting dialog box. 6. Close the Group Policy window. Click OK in the Domain Controllers Properties dialog box. Close the Active Directory Users and Computers window. 7. Open a command prompt window. At the command prompt, type secedit /refreshpolicy machine_policy and press Enter.You’ll see a message telling you that there will be a slight delay before machine security policy is updated. At the command prompt, type secedit /refreshpolicy user_policy and press Enter.This will update user policy. 8. Close the command prompt window. That’s it! Your configuration is now complete.The next step is to see if it works.

Connecting to the OWA Site The moment of truth is when you test the OWA site. It’s so easy to miss just a single step.You’re never sure if every configuration step has been done correctly. However, if you followed each step, and understood the reason for carrying out each step, chances are that everything will work nicely. www.syngress.com

410


One thing you can do to speed up your OWA connections from Internet Explorer is to install a client certificate on the OWA client machines.This adds your CA to the Trusted Root Authorities on the client.This speeds up certificate processing quite a bit. You will also avoid an error dialog box on connecting, saying that your computer doesn’t trust the CA that granted the server certificate. Open Internet Explorer and type in the URL https://FQDN/exchange and press Enter. It will take a few moments to establish the link.Type in your username and password. Note that you do not need to type in a domain name when you log in because you’ve configured a default domain name in the OWA folder’s Authentication Properties dialog boxes.You should not be presented with a second or third dialog box; if you configured everything correctly, you will see only one. If you received a Certificate Warning dialog box, it’s probably because the name on the certificate doesn’t match the FQDN you used to access the Web site.The other reason why you might get a Certificate Error dialog box is that your machine doesn’t trust your certificate server’s root authority. Just install a client certificate on the client and you’ll fix that problem right away. Your OWA connection should not be slow if you have a decent speed link. If you’re using a client with a 56K modem, performance will not be good, no matter what you do. If you find you have to wait several minutes to get a connection, or if the connection does not work at all, make sure that you have disabled integrated authentication on all of the OWA folders. If you’re using the wrong version of Internet Explorer, you’ll waste a lot of time trying to negotiate integrated authentication, and that won’t work! You only need to support basic authentication as long as SSL is working correctly. OWA users can change their passwords using the OWA interface; however, they must have permission to do so. If the user account properties do not allow the user to change his password, he will not be able to change his password via the OWA interface. Remember that you must also configure the /IISADMPWD directory to force SSL on connections to it by the Web Proxy service.

Troubleshooting Notes on Publishing OWA on the ISA Server Are you having problems with your OWA configuration? There are so many steps, so many details, it’s easy to miss a click here or there. Here’s a list of things you should check for if you’re having problems getting OWA to work: ■

Make sure that your OWA folders are using basic authentication only. Sometimes the permissions on the folders change when you restart the server. If you restart the server, recheck all of your OWA folders and make sure only basic authentication is enabled.

www.syngress.com

Defense Plan 5: Protecting Mail Services • Chapter 6 ■

Install client certificates on your OWA clients.This is not required, but it will speed up communications a lot during the SSL negotiation phase.

■

Make sure you configure a default domain in the Authentication Properties dialog box for each OWA folder.

■

Remember to configure an SSL listener on the default Web site; IIS does not automatically enter the port for you.

■

Make sure you configure an Incoming Web Requests listener and bind the Web site certificate to the listener; make sure that you haven’t mistakenly used the ISA server’s machine certificate.

■

If you don’t need to publish Web sites outside of the OWA site, you should just use the FQDN in the OWA destination set.

411

Message Screener on the ISA Server and Exchange Server You can install the SMTP Message Screener on the ISA/Exchange/DC machine and filter both incoming and outgoing messages.The installation and configuration routine is almost the same as when you install the Message Screener on the ISA server using just the IIS 5.0 SMTP service (without Exchange Server installed).The primary difference is how messages arrive and are processed by the SMTP service. When the Exchange server isn’t installed, the IIS 5.0 SMTP service acts only as an intermediary relay server in the SMTP communication.The IIS 5.0 SMTP service always forwards the message to another SMTP server.This isn’t the case when you install Exchange on the ISA server.While it’s true that the Exchange server uses the IIS 5.0 SMTP service to send and receive SMTP messages, the situation is different because the Exchange server is the endpoint of the SMTP communications for incoming SMTP message.The Exchange SMTP server doesn’t forward the message to another SMTP server. The difference is subtle, but it does have practical importance. For example, if you use an SMTP client (remember that other SMTP can be SMTP clients) to send messages to the Exchange server’s SMTP service, the messages will be exposed to the Message Screener.Therefore, if an SMTP server on the external network or Outlook Express on the external network tries to send an SMTP message to the Exchange server’s SMTP service, the message would be exposed to the SMTP Message Screener and be filtered according to the rules you’ve configured for the Message Screener. However, not all Exchange clients use SMTP to send messages to the Exchange server. Outlook 2000/XP uses MAPI to communicate with the Exchange server.When

www.syngress.com

412


the Outlook 2000/XP client sends a message to the Exchange server, the message is not exposed to the SMTP Message Screener because SMTP was not used to send the message. What if the message the Outlook user sent to the Exchange server is destined for an e-mail address on the Internet? For example, we’re using Outlook XP to connect to our Exchange 2000 server.We send an e-mail message to [email protected] Exchange server must use SMTP to send an outbound message to the SMTP server responsible for isaserver.org mail.You would expect that the outgoing messages would be exposed to the SMTP Message Screener on the way out. The fact is that the messages are only sometimes exposed to the Message Screener when they leave the Exchange SMTP service. During our testing, it turned out that only the keyword rule on top of the list was triggered, and even then it didn’t appear to be a consistent finding. It’s clear that the SMTP message filter was not designed to be used in this way. The solution to this problem is to create a second SMTP virtual server on the Exchange server machine. After you create the second virtual SMTP virtual server, configure the default SMTP virtual server to relay to the new virtual SMTP virtual server. When the message is relayed to the second SMTP virtual server, it is formatted as an SMTP message and exposes the message to the SMTP Message Screener. At this point, the outgoing messages will be filtered according to the rules you configured in the SMTP Application Filter dialog box. The configuration is somewhat complex, but doable.You need to perform the following steps: 1. Disable the SMTP service. 2. Disable the ISA Server services. 3. Configure the new SMTP virtual server. 4. Configure the default SMTP virtual server to use the new SMTP virtual server as its smart host. 5. Restart the ISA Server services. 6. Restart the SMTP service. Let’s look at the details of this configuration.

Disable the SMTP Service Perform the following steps to disable the SMTP service: 1. Open a command prompt, type net stop smtpsvc, and press Enter. 2. At the command prompt, type netstat –na | find “:25” and press Enter. You should see no data returned after issuing the command. www.syngress.com


413

Disable the ISA Server Services Perform the following steps to disable the ISA Server services: 1. Make sure that the ISA server is disconnected from the Internet before disabling the ISA Server services.Your machine is unprotected during this period and is open to Internet criminals while the ISA Server services are disabled. 2. At the command prompt, type net stop mspfltex and press Enter.The command will return information regarding the services that will be stopped. Press Y and press Enter. 3. At the command prompt, type net stop ipnat and press Enter.The command will return information telling you that the IPNAT service will be disabled. Press Y and press Enter.

Configure the New SMTP Virtual Server Now that the ISA Server and SMTP services are disabled, the next step is to create the new SMTP virtual server. Perform the following steps to create the new SMTP virtual server: 1. You will need to add a second IP address on the internal interface of the ISA server.You will then bind the second SMTP virtual server to this second IP address. Right-click on the My Network Places icon on the desktop and click Properties. 2. In the Network and Dial-up Connections dialog box, right-click on your internal interface and click Properties. 3. In the internal interface’s Properties dialog box, click on the Internet Protocol (TCP/IP) entry, and click Properties. 4. In the Internet Protocol (TCP/IP) Properties dialog box, click Advanced. 5. In the Advanced TCP/IP Settings dialog box, click Add. In the TCP/IP Address dialog box, type in a valid IP address for your internal network in the IP address text box.Type in a valid subnet mask in the Subnet mask text box. Click Add. 6. Click OK in the Advanced TCP/IP Settings dialog box. Click OK in the Internet Protocol (TCP/IP) Properties dialog box. Click OK in the internal interface’s Properties dialog box. 7. Open the Exchange System Manager. Expand your organization name, and then expand the Servers node. Expand your server name and then expand the Protocols node. Expand the SMTP node. www.syngress.com

414


8. You should see a red “x” on the Default SMTP virtual server entry, which is there because you disabled the SMTP service. If you don’t see the red “x”, click Refresh in the MMC button bar. Right-click on the SMTP node, point to New, and click SMTP Virtual Server. 9. On the Welcome to the New SMTP Virtual Server Wizard page, type in a name for the SMTP virtual server. In this example we’ll call it Relay. Click Next. 10. On the Select IP Address page, click the Down arrow on the drop-down list box and select the new internal IP address you previously configured. Click Finish. 11. The Relay virtual server will have a question mark on its icon.This will go away after you restart the SMTP service on the ISA/Exchange server. Rightclick on the new virtual SMTP server’s icon and click Properties. 12. Click on the Access tab. In the Relay restrictions frame, click Relay. In the Relay Restrictions dialog box, select the All except the list below option. The reason why you want to select this option is that this virtual SMTP server is used by internal network clients to send outgoing mail. If you don’t allow this virtual server to relay to all domains, then outgoing mail to the Internet won’t be relayed, and the mail won’t be forwarded. External SMTP clients and servers won’t be able to use this server as an open relay, because this server is not published via server publishing rules and therefore isn’t directly available to external network hosts. Click OK in the Relay Restrictions dialog box. 13. Click on the Delivery tab. On the Delivery tab, click Advanced. In the Advanced Delivery dialog box, type in the IP address (surround by straight brackets) or the FQDN of your ISP’s SMTP server in the Smart host text box.You should use your ISP’s SMTP server because your machine is already overloaded running Exchange and ISA Server.There’s no reason to add the burden of name resolution to your machine. Let your ISP’s SMTP server handle name resolution by configuring it to be your Smart host. Enter the information and click OK. 14. Click Apply and then click OK in the SMTP virtual server’s Properties dialog box. 15. Now we need to configure the Default SMTP Virtual Server. Right-click on the Default SMTP Virtual Server and click the Properties command. 16. In the Default SMTP Virtual Server Properties dialog box, click on the Delivery tab. On the Delivery tab, click Advanced. In the Advanced Delivery dialog box, type in the IP address of your new SMTP virtual server www.syngress.com


415

in the Smart host text box. Make sure that the IP address is surrounded by straight brackets! Click OK in the Advanced Delivery dialog box. 17. Click Apply and then click OK in the Default SMTP Virtual Server Properties dialog box.

Restart the ISA Server Services Perform the following steps to restart the ISA Server services: 1. Open a command prompt. At the command prompt, type net start IPNAT and press Enter.You will see that the IP Network Address Translator service was started successfully. 2. At the command prompt, type net start mspfltex and press Enter.You will either see the service start successfully, or you will see that the service has already been started. 3. At the command prompt, type net start isactrl and press Enter.You will either see that that the service was started successfully, or that the service has already been started. 4. Open the ISA Management console, expand your server name, and then expand the Monitoring node. Click on the Services node, right-click on the Web Proxy, Firewall, and Scheduled Content Download services, and click Start on each to start the services.

Restart the SMTP Service Perform the following steps to restart the SMTP service: 1. At the command prompt, type net start smtpsvc and press Enter. 2. At the command prompt, type in the following command: mdutil set -path smtpsvc/2 -value 1 -dtype 1 -prop 1029 -attrib 1

3. The mdutil command had to be entered a second time in order to disable socket pooling for the second SMTP virtual server. 4. Return to the Exchange System Manager. Stop and start the Default SMTP Virtual Server and the new SMTP virtual server. Use the Stop and Start buttons in the MMC console.

www.syngress.com

416


Notes on the SMTP Message Screener on the Exchange Server Configuration Getting the SMTP Message Screener to work on the Exchange server takes a lot of steps, but it does work, and it works nicely with your Outlook 2000/XP clients on the internal network as well.We think you’ll be very pleased with the results. There are a couple of issues of which you do need to be aware. At the time of this writing, the SMTP application filter has a couple of flaws in it. First, you cannot send an AUTH command to the SMTP service through the SMTP application filter.This prevents users from authenticating with your SMTP service.This can and does pose a real problem for organizations that want to make their SMTP servers available to external users, but also want to prevent their servers from becoming open relays. For example, the way we have the Exchange SMTP server set up now allows external users to send e-mail to users configured on the Exchange server. However, if the external user wants to send mail to a user outside of your Exchange organization, it won’t work because the SMTP service needs to be able to relay the SMTP message to another SMTP server to deliver the message.You do not want to open your published SMTP server as an open relay, so there is no way around this problem if the user must send SMTP messages to the published Exchange SMTP server and the SMTP application filter is enabled (which it must be if you want the SMTP Message Screener to work properly).The only way around this is to send mail via another protocol.You can use OWA to send mail to outside mail domains, but you won’t be able to use applications such as Outlook Express to send SMTP messages to outside domains.You could also use Exchange RPC publishing rules to solve this problem too, but these rules do not work when the Exchange server is on the ISA server. The good news is that it’s likely that the SMTP application filter will be fixed by the time you read this book. Make sure to check our news page at www.isaserver.org/ shinder for details on an updated SMTP application filter. The other problem with the SMTP application filter is that it does not support the STARTTLS command.This command is sent by SMTP clients when they negotiate a secure SSL connection with the SMTP server.This is an issue if you want to publish an SMTP server for external network users to use to send mail to a published SMTP server. Again, an updated SMTP application filter might be available by the time you read this book, so be sure to check www.isaserver.org/shinder early and often! Finally, we encourage you to be patient with your configuration.There are a great number of steps to perform.There’s a good chance that things won’t work if you miss any of the details of the configuration.We know that this can become extremely frustrating! However, if you persevere and check and recheck your configuration, we can assure you that it works consistently and reliably.

www.syngress.com


417

Configuring Mail Services on the Internal Network Configuring Mail services Exchange Server publishing configuration on the internal network is much easier than trying to get it to work on the ISA server. Many of the same principles we applied when publishing the Exchange server on the ISA server will work when publishing an Exchange server that sit on the internal network. In this section, we’ll cover the steps required to publish an Exchange server on the internal network.You’ll find that almost all of the details are the same as those when you publish the Exchange server on the ISA server, except that you won’t run into so many problematic IIS, ISA, and Exchange Server interactions.There is one major difference between publishing an Exchange server on the internal network and publishing an Exchange server on the ISA server: you can use Exchange RPC publishing rules to allow external network clients to connect to the Exchange server on the internal network. In the section, we’ll cover the following topics: ■

Publishing Exchange Server services

■

Exchange RPC publishing rules

■

Publishing Outlook Web access

■

Using the Message Screener on the Exchange server and configuring the Message Screener on an SMTP relay

■

Using GFI Software’s MailSecurity instead of or in addition to the SMTP Message Screener

Publishing Exchange Server on the Internal Network In the first half of this chapter, we went through the procedures required to publish Exchange Server services on the ISA server. Here we will look at how to publish Exchange Server services when the Exchange server is on the internal network.There are ways to publish Exchange Server services: you can manually create server publishing rules, or use the Secure Server Publishing Wizard. We wanted you to get a better understand of how publishing rules work by walking you through manually creating publishing rules in the first part of this chapter,. You can accomplish the same tasks, and get them done faster, by leveraging the automation provided by the Secure Mail Server Publishing Wizard.The Secure Mail Server Publishing Wizard is an ideal way to publish an internal Exchange server.

www.syngress.com

418


The Secure Mail Server Publishing Wizard automatically creates the NNTP, SMTP, POP3, IMAP4, and RPC publishing rules for you. It will also enable the SMTP filter on the ISA server so that you can screen messages on the ISA server before they reach the Exchange server on the internal network. Note that while the wizard will enable the SMTP filter for you, you must install the Message Screener if you want the Message Screener to run on the ISA server.The Message Screener on the ISA server would work together with an SMTP relay on the ISA server when you have an Exchange server on the internal network. The first step is to install the Exchange server on the internal network.You can install Exchange on a domain controller, or you can install it on a member server in your domain. If you install the Exchange Server on a member server, make sure you install the Exchange System Manager on the domain controller so that you get the Exchange 2000 related tabs and features included in your Active Directory Users and Computers console. In this discussion, we will assume that the Exchange server is on the domain controller.There are no differences in the configuration when the Exchange server is on a domain controller or a member server, except for the “log on locally” requirement for OWA, so you don’t have to do anything different in terms of publishing rules or ISA Server configuration. Just remember that if you do put the Exchange server on the ISA server, you will need to change the “log on locally” user right if you want to publish its OWA site. Perform the following steps to publish Exchange Server services on the internal network using the Secure Mail Server Publishing Wizard: 1. First, you have to disable socket pooling on the ISA server, or disable the IIS services on the ISA server. Follow the instructions provided earlier in the chapter on how to disable IIS services or disable socket pooling. If you do disable socket pooling, make sure that you configure IIS services to listen only on the internal interface, and then restart the IIS services. 2. Open the ISA Management console, expand your server name, and then expand the Publishing node. Right-click on Server Publishing Rules node and click on the Secure Mail Server command. 3. Click Next on the Welcome to the Mail Server Security Wizard page. 4. Select the protocols you want to publish on the Mail Services Selection page (Figure 6.15).The Default Authentication column creates publishing rules that do not support secure SSL connections.The SSL Authentication column creates server publishing rules that support secure SSL connections. Note that when you select the Incoming SMTP option, it enables the Apply content filtering dialog box. If you have already enabled the SMTP www.syngress.com


419

filter, this dialog will be checked, but grayed out. In this example, we’ll select all of the options except the Apply content filtering and Incoming Microsoft Exchange/Outlook options.We’ll cover secure Exchange RPC publishing and using the SMTP Message Screener later in this chapter. Make your selections and click Next to continue. Figure 6.15 The Mail Service Selection Page

5. On the ISA Server’s External IP Address page, click Browse and select the IP address on the external interface of the ISA server you want to listen to incoming messages for your internal Exchange server. Click Next. 6. On the Internal Mail Server page, type in the IP address of the internal network Exchange server in the At this IP address text box. Note that if you select the On the local host option, the wizard will create packet filters instead of publishing rules.This is why we did not use the Secure Mail Server Publishing Wizard when configuring Exchange services publishing on the ISA server. Click Next to continue. 7. Click Finish on the Completing the Mail Server Security Wizard page. Click on the Server Publishing Rules node and you’ll see a number of server publishing rules created by the wizard. Click on the Protocol Rules node and you’ll see that an SMTP and SMTPS protocol rule has been created for the SMTP server so that it can communicate with external network SMTP servers 8. The wizard works almost perfectly except for one problem.Your SMTP server will probably need to resolve MX domain names using DNS queries. If you use an internal DNS server for MX domain name resolution, you don’t have to create a DNS protocol rule for the Exchange server. If you want the Exchange server to resolve MX domain name records, then you should create a DNS Query and a DNS Zone Transfer protocol rule that allows the Exchange server to resolve Internet mail domain names. www.syngress.com

420


The non-SSL publishing rules work right away.You’ll need to follow the instructions provided earlier in this chapter regarding certificate assignment and secure connection configuration for the Exchange services if you want to users to connect to the Exchange server using secure SSL connections.

Exchange RPC Publishing You have the option to publish Exchange RPC services when the Exchange server is on the internal network.This is one of the most compelling reasons for getting the Exchange server off the ISA server and onto an internal network server. Why would you want to create an Exchange RPC server publishing rule? Here are some advantages: ■

The RPC link can be secure.

■

Data encryption can be enabled between the Outlook client and the Exchange server.

■

Exchange RPC server publishing is easy.

■

External client access is limited to mail services only.The client has no access to any other services on the network.

■

Users continue to use their familiar Outlook 2000/XP client.

There is an impression that RPC connections are not secure.While in many circumstances this might be the case, it is not true when you use the Exchange RPC filter to publish Exchange servers.The RPC filter handles connections between the Internet Outlook client and the internal Exchange server; it creates dynamic packet filters that can be used only by specific Outlook clients that establish the connection. Only Exchange RPC UUIDs are available, so you don’t have to worry about other RPC services being exposed to the Internet. You can configure Outlook to encrypt data over the RPC link. If you do a Network Monitor trace, you’ll find that even when the data isn’t encrypted, there is nothing meaningful in the ASCII decode (in Network Monitor).You are assured a very high level of security for data transferred between the Outlook client and the internal Exchange server when you add data encryption to the connection. Exchange RPC publishing is easy. A single server publishing rule allows your Outlook MAPI clients to access the internal Exchange server.There are no special configuration requirements on the Exchange server, and when the network infrastructure is configured correctly, no configuration changes are required on the Outlook client. The only other way to connect your external Outlook MAPI clients to an internal network Exchange server is to allow them to establish a virtual private networking

www.syngress.com


421

(VPN) link into the internal network.While this option is a viable one for your network administrators and other trusted accounts, you do not necessarily want all of your users (which might include contractors and temps) to have free reign over the corporate network from remote locations.VPN connections are wholly inappropriate for Exchange hosting scenarios. Exchange RPC server publishing gets around this problem by allowing users access only to the Exchange server and nothing more. End users balk when they have to switch applications to get the same job done. This is especially the case with mail client software. If you have standardized users on Outlook 2000/XP, those users want to use Outlook while at home or on the road. Exchange RPC publishing allows them to use the same familiar interface they use at work, at home, or on the road.

How Exchange RPC Publishing Works The typical “on the road” Outlook client first establishes a connection to the Internet through a local ISP.The client might also be on a remote network and connects to the Exchange server via a NAT server on the remote network.When the user opens Outlook, the following communications take place: 1. Outlook establishes a connection to TCP port 135 on the external interface of the ISA server. 2. The ISA server’s Exchange RPC filter intercepts the request and forwards the request to the internal network Exchange server.The internal network Exchange server responds to the request by sending a port number on which the Outlook client can send its messages.The Exchange RPC filter on the ISA server intercepts this response and opens a dynamic packet filter on its external interface.The dynamic packet filter assigns a port on the external interface of the ISA server on which only this particular Outlook client can communicate. Any other Internet host will not be able to use that port for inbound access.The ISA server maps this port on its external interface to the port number the Exchange server expects to receive messages from the Internet Outlook client. In addition, when the Outlook client logs on, it registers a port on which it can receive new mail notification messages from the Exchange server.The ISA server RPC filter also registers this port number, creates a dynamic packet filter, and passes the new mail notification messages from the Exchange server to the Internet Outlook client. 3. The ISA server forwards the response from the Exchange server.The Outlook client receives the port number on the external interface of the ISA server to which it can send its messages to the Exchange server.

www.syngress.com

422


4. The Outlook client establishes a connection to the mapped port on the external interface of the ISA server and through that port connects to the internal network Exchange server. Figure 6.16 depicts this sequence of events. Figure 6.16 Establishing an Exchange RPC Connection Firewall Connection established to ISA TCP 135

Firewall

Request forwarded to Exchange. Exchange responds with port for client to use Firewall

ISA RPC filter notes the port assigned by Exchange and creates a dynamic packet filter for a port on the external interface of the ISA Server; returns the response port information to the Outlook client

Firewall

The Outlook client establishes a connection to the port created by the dynamic packet filter. The ISA Server RPC filter has mapped the port to the port expected by the Exchange Server

www.syngress.com


423

Preparing the Infrastructure for Exchange RPC Publishing You need to take care of a few things before your RPC server publishing rule works correctly: ■

Creating the supporting DNS infrastructure

■

Creating the DNS and SMTP protocol rules

■

Configuring the Authentication method

■

Supporting clients behind NAT servers/ISA servers

Creating the Supporting DNS Infrastructure DNS issues crop up constantly on the ISAserver.org message boards and newsgroups. If your DNS infrastructure isn’t in place and working properly, the ISA Server rules won’t do what you want them to do. If your DNS infrastructure is already set up and working, great! If it’s not, you need to come to terms with it and get it fixed. The ideal DNS configuration is referred to as a “split DNS.” In the split DNS configuration, you maintain two separate zones, one for internal network clients to use and one for external network clients to use.These two zones service the same domains, but the resource records on the internal DNS server have the private IP addresses for your network clients, and the external DNS server has the public IP address for your published network resources.

ISA SERVER ALERT Note that when we use the terms internal and external DNS server, we’re not referring to the physical location of these DNS servers. The internal and external DNS server can be located on the internal network. The external DNS server on the internal network is published using a server publishing rule, allowing external network clients to resolve your public domain resources to the external interface of the ISA server. The internal network DNS is always on the internal network because only internal network clients use this server.

For example, a common problem is that users can access the published Web server www.domain.com from external network hosts, but can’t access the site when they’re on

the internal network.The problem is that internal network clients are trying to connect to the published server via the external interface of the ISA server because internal network clients are using the same host records as the external network clients for name resolution.When you create an internal DNS server that internal network clients use, the www.syngress.com

424


internal network clients receive the private IP address of the published server and therefore connect directly to the server. Now, in regard to our Exchange RPC publishing situation, you need to make sure that the host name of the internal network Exchange server is the same as the host name used to access the server from the Internet.This requirement makes the split DNS configuration even more important, since the split DNS allows the transition between the internal and external network to be transparent to the users. For example, if the server name is exchange.domain.com on the internal network, you need to ensure that exchange.domain.com is also accessible from the external network.You can accomplish this with a split DNS configuration by creating a Host (A) record on your external DNS server for exchange.domain.com to point to the external interface address on the ISA server that you are using in the Exchange RPC publishing rule. The reason why you must configure the Host (A) record is that the name of the Exchange server is returned to the Outlook client when it makes the RPC connection. The Outlook client needs to be able to communicate with the name received from the Exchange server, which is the Exchange server’s NetBIOS name. Note that only the host name portion of the FQDN will appear in the Outlook configuration dialog box after the name is resolved. For example, when you configure Outlook to use the Exchange server, you type in the name of the Exchange server as exchange.domain.com.When the client successfully connects to the internal network Exchange server via the RPC publishing rule, the name in the configuration dialog box will change to EXCHANGE. If your organization does not use the same naming conventions for internally and externally accessible resources, you can still access the Exchange server via the RPC publishing rule. In this case, all you need to do is create a HOSTS file entry with the NetBIOS name of the computer.You do not need to include the FQDN of the Exchange server in the HOSTS file; just the NetBIOS name is required to make it work.

ISA SERVER DEFCON1 It is a best practice to use the same name for both the computer DNS host name and NetBIOS name. We have not tested the configuration with a disjoint NetBIOS and DNS host name configuration, so we cannot guarantee that it will work if you maintain a disjoint NetBIOS/DNS namespace.

Creating the DNS and SMTP Protocol Rules The Exchange server needs to forward mail it receives from the Outlook client to SMTP servers on the Internet.You need to create two protocol rules:

www.syngress.com

Defense Plan 5: Protecting Mail Services • Chapter 6 ■

A DNS Query and DNS Zone Transfer protocol rule

■

An SMTP protocol rule

425

The DNS Query and Zone Transfer protocol rules allow the Exchange IIS SMTP service to resolve the MX domain name records for the outgoing mail.You can configure the protocol rule to allow only the Exchange server access, or you can configure it to allow all machines on the network to use it. Access control on the DNS Zone Transfer protocol rule depends on which machine is resolving the MX domain names. You might want to forward the queries to an internal DNS server and let it take care of name resolution. Make sure you create a client address set for the servers that you want to have access to this DNS protocol rule.The servers, whether Exchange or DNS servers, will not have logged-on users, or will not have the Firewall client installed on them.The only way to allow outbound access control for SecureNAT clients is via client address sets. Create a client address set for all servers that need access to the rule, and assign the client address set to the rule. The SMTP protocol rule is required for the Exchange server to send out mail to external mail domains. Access controls on the SMTP protocol rule depend on what machine actually sends mail to external SMTP servers. Allow only the Exchange server access to the SMTP protocol rule if the Exchange server sends mail directly to Internet SMTP servers. Allow the SMTP relay access to the SMTP protocol rule if you use an SMTP relay server for outbound mail. If you are using a mail relay, make sure that the SMTP relay server has access to the DNS protocol rule as well.The exception would be when you are allowing an internal DNS server to resolve Internet mail domains for the relay.

Configuring the Authentication Method When Outlook logs on to the Exchange server, the Exchange server instructs the Outlook client to authenticate with an Active Directory domain controller.The problem is you do not want to open the ports responsible for authentication through the ISA server.To get around this problem, you can configure the Exchange server to perform authentication on the behalf of the Outlook client. To configure the Exchange server to proxy authentication requests for the Outlook client, navigate to the following Registry key: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

Add the following:

www.syngress.com

426

Chapter 6 • Defense Plan 5: Protecting Mail Services ■

Value No RFR Service

■

Type REG_DWORD

■

Data 1

Note that the value does have spaces in it. At first we thought that this might have been a typo, but we confirmed that the spaces should be included. After adding the value, restart the Exchange server. Note that you do not need to add this value if the Exchange server is also a domain controller.

Clients Behind NAT Servers/ISA Servers If the Outlook client is behind a NAT server or an ISA server, it will not be able to receive new mail notification requests.The reason is that these new mail notification requests are not part of the existing RPC connection between Outlook and the Exchange server.The NAT server and ISA server drop the packet because the new mail notification message is seen as an unsolicited inbound request. This doesn’t mean that you won’t ever get any new mail. If you send mail to the Exchange server, a new mail notification message is sent through the active RPC channel between the Outlook client and the Exchange server when the message is sent. However, RPC wasn’t designed for use over the Internet. If there is an error in any of the RPC packets carrying the new mail notification, the notification message will not go through.You can get around this by forcing synchronization with the F9 key in Outlook 2000, or set up the Exchange account to carry out an automatic send/receive every few minutes in Outlook 2002.The exception to this is when you encrypt the data connection between Outlook and the Exchange server. In that case, e-mail notification never works, and you have to click on a folder to initiate the connection. The good news is that everything else works fine when Outlook is behind the NAT server. If you use the Windows 2000 RRAS NAT, no further configuration is required for the NAT routing protocol. If there is an ISA server in front of the Outlook client, you will need to configure an RPC protocol definition and configure the client as a Firewall client.You must use the Firewall client configuration because SecureNAT clients do not support secondary connections. You need to create the following protocol definition (Figure 6.17): ■

Primary connection TCP 135 Outbound

■

Secondary connections TCP 1025-65534 Outbound

The initial connection takes place on TCP 135.The remote ISA server (the one publishing the Exchange server) sends back to the local ISA server (the one in front of the Outlook client) the port number on which the Outlook client needs for subsequent requests. Since this new outgoing connection is part of the original RPC conversation, a www.syngress.com


427

secondary connection to an ephemeral (high number) port is required outbound from the local ISA server to the remote ISA server. Once you create the RPC protocol definition, create a protocol rule using this protocol definition. Figure 6.17 Outbound RPC Protocol Definition

Creating the Exchange RPC Server Publishing Rule The Exchange RPC server publishing rule uses a protocol definition provided by the RPC application filter. If you disable the application filter, you lose the protocol definition. Do the following to create the server publishing rule: 1. In the ISA Management Console, expand your server or array name, and then expand the Publishing node. 2. Right-click on the Server Publishing Rules node, point to New, and then click on Rule. 3. On the Welcome page, type in a name for the rule and click Next. 4. On the Address Mapping page, type in the IP address of the internal Exchange server and the IP address on the external interface you want external network clients to use to access the Exchange server. Click Next. 5. On the Protocol Settings page, select the Exchange RPC Server rule and click Next. 6. On the Client Type page, select Any Request and click Next. (It’s unlikely you’ll be able to identify a client address set to assign the external Outlook clients). 7. On the final page of the wizard, click Finish.

www.syngress.com

428


The rule will take effect soon after you click Finish. If you want the rule to apply right away, restart the Firewall service.

ISA SERVER ALERT Configuring the Outlook client is beyond the scope of this book, and the procedures vary depending on the version of Outlook you’re configuring. Both Outlook 2000 and Outlook 2002 (XP) can use the Exchange RPC publishing rule to access the Exchange server on the internal network. It is important to note that you can force the client to use an encrypted RPC connection when connecting to the ISA server. There is one drawback to using an encrypted channel: you will never receive notifications of new e-mail. In fact, you won’t receive notification of new e-mail even if you schedule an automatic Send/Receive or press F9, depending on the version of Outlook. To receive new e-mail notification messages, you must click on an existing message or folder to initiate a connection with the Exchange server . If you are using Outlook 2000, do not install Office Service Pack 2. There appears to be an undocumented issue preventing Outlook 2000 SP2 clients from connecting to an Exchange 2000 server published using the RPC server publishing rule. This problem appears to be specific to the server publishing rule, because if you bring the client onto the internal network, you can log on to the Exchange server without problems.

Publishing Outlook Web Access on the Internal Network Exchange Server The same procedures used to publish OWA on the ISA server are used when you publish OWA on the internal network Exchange server.The only difference is you don’t need to worry about disabling socket pooling on the ISA server, because you’ll choose to disable the IIS W3SVC on the ISA server for security purposes. As a review, here are the basic procedures required to publish the OWA site on the internal network Exchange server: 1. Configure the OWA Web site on the Exchange server: Configure folder permissions, obtain and assigning a certificate for the Web site, configure a port for SSL connections on the default Web site, and configure the sites to require an SSL connection. 2. Configure the Incoming Web Requests listener on the ISA server: Create the individual listener, export the OWA Web site certificate and import it into the ISA Server’s machine certificate store, and bind the certificate to the Incoming Web Requests listener. www.syngress.com


429

3. Create the Web publishing rule: Create the destination set used for the OWA Web publishing rule, create the Web publishing rule, and configure the rule to bridge SSL connections as SSL. 4. Configure the OWA client Web browser: Improve performance for the OWA client by installing a client certificate on all browser clients. For details of this configuration, check the relevant sections on how to publish OWA on the ISA server.The only difference is that you use the internal IP address of the Exchange server rather than the IP address of the internal interface of the ISA server for the redirect.

ISA SERVER ALERT There is a good chance that by the time you read this book, Microsoft will have released the ISA Server Feature Pack. One of the features included in the major update to ISA Server is an Outlook Web Access Publishing Wizard. The wizard will greatly simplify publishing of OWA sites. However, like all wizards, it will have its limitations. Check www.isaserver.org/shinder for updates on this feature of the ISA Server Feature Pack and other important ISA Server news and articles.

Message Screener on the Internal Network Exchange Server You can install the Message Screener on the internal network Exchange server.The difference between the installations is that when the Message Screener is on the ISA server, the entire ISA Server software package is installed on the ISA/Exchange Server computer. In contrast to the “all but the kitchen sink” approach we covered earlier, when the Exchange server is on a dedicated server, all you need to install is the SMTP Message Screener.You don’t need to install any other component of the ISA Server software. Run the ISA Server installation program as you usually would to install only the Message Screener component on the internal network Exchange server. Select the Custom installation option and then deselect the ISA Services and Administration tools options in the Custom Installation dialog box (Figure 6.18). Select the Add-in services option and click Change Option. Remove the Install H.323 Gatekeeper Service option (Figure 6.19).The only component you want is the Message Screener. Make sure that the Message Screener option is selected and complete the installation on the Exchange server computer.You won’t see any new configuration interfaces or Start menu items related to the Message Screener www.syngress.com

430


on the Exchange server. Configuration of the Message Screener is done via the SMTP filter on the ISA server. Figure 6.18 The Custom Installation Dialog Box

Figure 6.19 Selecting the Message Screener

The next step is to configure credentials that the Message Screener software will use to communicate with the SMTP application filter on the ISA server. Credentials are configured using the SMTPCRED tool, which is installed in the Program Files\Microsoft ISA Server folder on the Exchange server’s hard disk after running the Message Screener installation. Open the SMTPCRED tool by double-clicking on it. In the Message Screener Credentials dialog box (Figure 6.20), enter your ISA server name, the Username of the person who installed the ISA server, the Domain to which that user account belongs, and the Password of that user. Note that you do not need to use the credentials of the user who installed the ISA server, but it does streamline the process and reduces troubleshooting issues encountered with the Message Screener by an order of magnitude. Click OK after entering the information.

www.syngress.com


431

Figure 6.20 The SMTPCRED Tool

The last thing is to configure DCOM permissions.The Message Screener communicates with the SMTP application filter via DCOM.While this isn’t an issue when the ISA server and the Exchange server are on the same machine, it does become an issue when they are on different machines. Perform the following steps to configure the DCOM permissions: 1. Click Start, click Run, type dcomcnfg.exe in the Open text box, and then click OK. 2. Click the Applications tab, click the VendorData class entry, and then click Properties (Figure 6.21). Figure 6.21 The DCOM Configuration Properties Dialog Box

3. On the VendorData Class Properties dialog box, click on the Security tab (Figure 6.22). Select the Use custom access permissions option. In addition, select the Use custom launch permissions option. Finally, select the Use custom configuration permissions option. www.syngress.com

432


Figure 6.22 The VendorData Class Properties Dialog Box

4. For each option, click Edit.You will see the Registry Value Permissions dialog box. For each configuration permission, add the Everyone group by clicking Add and then selecting the Everyone group (Figure 6.23). Click OK, and then click OK again. Figure 6.23 Adding the Everyone Group

5. Restart both the ISA server and the Exchange server.We suggest restarting the ISA server first. The remainder of the configuration is the same as when you run the Message Screener on the ISA/Exchange server computer.You will be able to screen for incoming and outgoing messages, but you will have the same limitations regarding Outlook MAPI clients sending SMTP messages to the Internet.The solution is the same: create a second virtual SMTP server and have the default SMTP virtual server forward mail to the second SMTP virtual server.The Internet-bound messages sent by Outlook clients will be exposed to the SMTP Message Screener when they are forwarded to the second SMTP virtual server.

www.syngress.com


433

GFI’s Mail Security and Mail Essentials for SMTP Servers It’s estimated that spam makes up as much as 20 percent of the total traffic moving through the Internet. Spam clogs e-mail boxes, and contains viruses, worms, and offensive language. Spam fills the massive disks on today’s mail servers and is a public nuisance. Spam can negatively impact your personal and professional life: just think about how many times you’ve accidentally ignored an important message because it got lost in a sea of spam in your inbox. We don’t have to convince you that something needs to be done about spam. Many network administrators use Real Time Black Hole Lists (RBLs) to automate spam blocking on their networks.The problem with RBLs is they are maintained by third parties. If there is one thing we learned during the dot com bomb, it’s that inappropriate trust in third parties can put your business in jeopardy. There are several types of RBLs. Legitimate RBLs look for open mail relays on the Internet and blacklist the IP addresses of the open relays.The blacklisting is based on the assumption that eventually, a spammer will find the open relay and use it to send spam.The problem with this approach is that the open relay will be blacklisted even if no spam has ever been sent through it. It’s sort of like the police taking you into custody for a shooting because you have two hands, one of which might have held a gun. The other type of RBL is based on user reports. One user of the service reports that he received mail that he thinks is spam.That user tells three of his friends to make the same report. BANG! The domain from which the alleged spam is sent is blocked by the RBL. Suppose you send someone an e-mail message inviting him to your birthday party. He didn’t ask for that message, so he reports you as a spammer, and he gets three of his antisocial friends to send in the same report. A couple of days later, you find that some people aren’t getting mail from you.Why? Your domain or account has been blocked by the RBLs that blindly trust user reports. This type of spam blocking has to be the most egregious form of censorship we’ve seen in decades. Everyone hates spam, we really hate spam, but we hate the idea of a third party censoring what should be sent to our network.That’s our job, our responsibility, and our mail. It’s not the job of some anonymous RBL to decide what’s legit.. The SMTP Message Screener goes a long way to solving the spam problem.You can block mail based on text strings.The problem is that you don’t have much flexibility with the SMTP Message Screener. For example, you can’t: ■

Easily save the keyword entries in the Message Screener

■

Check for e-mail viruses using the Message Screener

■

Check for viruses in e-mail attachments using the Message Screener www.syngress.com

434

Chapter 6 • Defense Plan 5: Protecting Mail Services ■

Import a list of keywords from a text file into the Message Screener

■

Check for non-virus-related e-mail exploits with the Message Screener

■

Check for whole words in the Message Screener (you can only check for text strings)

■

Creating conditional content checking rules for e-mail

It’s our opinion that the only valid way to control spam is by using a keyword method.We’ve found that the most effective way to prevent spam from getting to user mailboxes is to create a list of keywords that don’t apply to the legitimate business or personal communications. Using this method, you can control over 99 percent of the spam entering your network. While the ISA Server SMTP Message Screener is better than nothing, we’ve found that the best tool for this job is GFI Software’s MailSecurity.We use MailSecurity to block spam in both small and large organizations. MailSecurity is easy to set up, and you can import your spam filter list easily form a text file. It also detects e-mail viruses and attachments, and auto-updates its virus definition list on a daily basis.

MailSecurity Versions There are two versions of MailSecurity. One plugs into your Exchange 2000 server and inspects the contents of the message store.The other version is for SMTP mail gateways and inspects mail as it moves through the gateway.The main advantage of the Exchange Server version is that it can inspect mail sent between internal users.The main advantage of the SMTP relay version is that it has more information about each e-mail and can decide better what mail is considered inbound and outbound. MailSecurity can be configured to inspect only inbound, only outbound, or both inbound and outbound e-mail. We typically install an SMTP relay on all networks that have an Exchange 2000 server. For that reason we consider the SMTP gateway version the best choice. Note that you can use both versions.You can install the SMTP gateway version on your SMTP relay, and you can install the Exchange Server 2000 version on your Exchange server and you don’t have to buy any more licenses for filtering based on keyword, user, or domain.You do need to pay extra for a maintenance contract and automatic antivirus updates.

Installing MailSecurity for SMTP Gateways Installing MailSecurity for SMTP gateways is straightforward. Download the installation file from www.gfi.com/mailsecurity/index.html and run the mailsecurity.exe installation package.The Welcome to the GFI MailSecurity for Exchange/SMTP Installation Wizard page pops up (Figure 6.24). Click Next to continue.

www.syngress.com


435

Figure 6.24 The Welcome Page

The License Agreement page appears. Select the I accept the license agreement option and click Next. On the User Information page, put in your name, company name, and serial number (if you have one; otherwise, use Evaluation as your key). Click Next. On the Administrator Email page (Figure 6.25), enter the MailSecurity administrator e-mail address. Notification messages can be sent to the administrator e-mail account you enter here.You can add more administrators or change the one you enter here later. Click Next. Figure 6.25 The Administrator Email Dialog Box

On the Destination Folder page, select the location of the program files and click Next.This brings you to the Mail Server page shown in Figure 6.26. If your SMTP relay is on a DMZ segment, put in the IP address on the external interface of the ISA server used by the SMTP server publishing rule that’s publishing the internal network Exchange server. If the SMTP relay is on your internal network, put in the IP address of your Exchange server.The default port TCP 25 will work in the majority of cases. However, www.syngress.com

436


if you want MailSecurity to send to an alternate port, just type the alternate port number in the on port text box.The setup program will create a remote domain in the IIS SMTP service for the domain you enter in the Local domain text box. If you are managing multiple mail domains, you should manually create those remote domains after the installation is complete. Click Next to continue. Figure 6.26 The Mail Server Information Page

Tell MailSecurity the type of mail server you’re running MailSecurity on in the next Mail Server page shown in Figure 6.27. In this example, we’re installing MailSecurity on an SMTP relay, so the second option is correct. Click Next to continue, and click Next one more time to start installing the application. Click Finish when you get notification that the application has been installed successfully. Figure 6.27 Choosing the Mail Server Type

Open the Internet Information Services console after you’re finished installing MailSecurity. Expand the Default SMTP Virtual Server node and click on the Domains node.You’ll see that a new remote domain was created and configured to use your internal mail server as a smart host. If you configure MailSecurity on a DMZ

www.syngress.com


437

SMTP relay, you’ll see the IP address used on the external interface of the ISA server in your SMTP server publishing rule. If you host multiple mail domains, create a remote domain for each domain you host and have them use your mail server as a smart host. Make sure that your server is not configured as an open relay by setting the appropriate relay settings on the Default SMTP Virtual Server (Figure 6.28). Figure 6.28 Remote Domain Configuration

Configuring MailSecurity Click Start, click Programs, and then click GFI MailSecurity. Click on MailSecurity Configuration to get started. Figure 6.29 shows all the features in an MMC console. Figure 6.29 MailSecurity Configuration

Click on the Content Checking node in the left pane, and then double-click on the Default Content Checking Rule.This is where you create your e-mail content www.syngress.com

438


checking rules.You can create rules that look for a particular keyword, or you can create rules based on keywords with conditions. In Figure 6.30, you’ll see some keyword rules that have conditions. For example, we want to block all mail that has the keywords “special offer.” However, we don’t want to block special offers from GFI. Notice that you have the option to check inbound and outbound mails.You can also block PGP encrypted mail.This will prevent mail encrypted with PGP from bypassing your content checking rules.This is a valuable feature, as users might try to use PGP to send out proprietary information about corporate projects. For example, you might be working on a project and use an internal code name for that project. No one on the outside should know the project or its code name. If users sent mail encrypted by PGP, they would get around your keyword filters.You can also check the attachment content.This prevents attachments with forbidden content from reaching users’ mailboxes. Figure 6.30 Configuring Keywords

You can monitor incoming mail in real time and see what mail was allowed and which ones where caught by the content checking rules.The GFI Monitor (Figure 6.31) shows you mail as it’s being processed. The Moderator Client (Figure 6.32) allows you to see the actual messages caught by the content checking rules.When you double-click on the blocked message, you’ll see the reason why the message was caught, some details about the message, and files associated with the message.You can right-click on the content file and open the message. Plain text messages are saved as text files, and HTML messages are saved as HTML files. The HTML files are safe to open because dangerous scripts and viruses are removed. Click on the Attachment Checking node in the left pane, and then double-click on the Default Attachment Checking Rule (Figure 6.33) in the right pane.This option allows you to block attachments for inbound or outbound mail (or both).

www.syngress.com


439

There’s a built-in list of attachments that can be blocked, and you can easily add your own custom attachments. Figure 6.31 GFI Monitor Displaying Actions in Real Time

Figure 6.32 The Moderator Client

Figure 6.33 Attachment Checking Options

Now for the best feature of MailSecurity: the virus scanning engines. MailSecurity allows you to scan mail for viruses using multiple scanning engines. If one of the virus scanning engines doesn’t catch a virus, it’ll try again with another scan engine.This www.syngress.com

440


provides a high level of security for both incoming and outgoing e-mail.This redundant virus scanning method unique to MailSecurity. Notice that you have the option to scan inbound mail, outbound mail, or both.You also can block Word documents that have macros.Word macro viruses are a big problem, so blocking them can go a long way toward protecting your users from Word macro exploits. In Figure 6.34, you see the options for automatically downloading and installing virus definition updates. Figure 6.34 The Virus Checking Engines

The system automatically downloads virus definitions, and we’ve never had a problem getting them to download from behind the ISA server.The system uses FTP to download the updates, so you need to create an FTP protocol rule to allow the mail server to download the updates. If you run MailSecurity on the ISA server, you’ll need to create packet filters to allow for PORT mode FTP communications between the ISA server and the GFI FTP server (Figure 6.35). Figure 6.35 Configuring FTP Virus Definitions Download Options

www.syngress.com


441

Click on the E-mail Exploit Engine node in the left pane of the console. In the right pane (Figure 6.36), you’ll see an impressive list of e-mail exploits MailSecurity checks for.The e-mail exploit engine is disabled by default, so you have to right-click the node in the left pane of the console and click Enable.We don’t see any reason not to run the e-mail exploit engine, so we recommend that you always enable it and allow MailSecurity to check for all of the included exploits. If for some reason you need to disable checking for a particular exploit, you can right-click it and click Disable. Figure 6.36 Checking for E-Mail Exploits

Some e-mails are so obviously spam that you don’t need to ever look at them.This type of blatant spam can be deleted without you ever needing to review it in the Moderator Client console.The Anti-spam feature allows you to enter keywords that are never included in legitimate e-mails. As with the content checking feature mentioned earlier, you can have MailSecurity check the mail body or subject line for these uniquely inappropriate or offensive keywords.When a message matches the keywords in the Anti-Spam dialog box, the mail can be deleted immediately or put in a folder for later checking (Figure 6.37). For both content checking and anti-spam rules, you can choose what action to take on the e-mail (Figure 6.38). For the content checking option, you can quarantine the mail, delete it, or move it to a particular folder for evidence collection.You also have the option to notify users that they sent or received a forbidden mail.You can also inform the user’s manager.The manager is defined in the user account properties in the Active Directory. We have found the performance of MailSecurity acceptable. If you have a large number of rules and enable all the virus engines and exploit checking, it might take a few seconds to evaluate a single e-mail. If you have a busy mail server, you’ll want to make sure to load it up with RAM and a fast processor. However, if you don’t require instantaneous delivery of e-mail from the relay to the main mail server, you’re in good

www.syngress.com

442


shape.The engine doesn’t choke or die when it’s busy, it just slows. However, all the mail gets checked and cleaned before making its way to your server. Figure 6.37 Whacking Spam with the Anti-Spam Feature

Figure 6.38 Deciding What Action to Take with Filtered Mail

You need to put together a list of keywords that are specific for your organization in order to see the best results with your e-mail checking rules.This can take a week or two. One thing that we find useful is to create a Hotmail account and then subscribe that Hotmail account to a number of different Web sites.You can also post messages to USENET message boards and put that account in the return address.This will get the account quickly subscribed to a large number of spammer lists.You can use the spam sent to your Hotmail inbox for ideas on what keywords to put into the MailSecurity keyword database. If you want to get a head start on your list, check out our list of keywords, which we update weekly, at ftp.tacteam.net/isaserver/spamlist.tx_.

www.syngress.com


443

Summary In this chapter, we reviewed the techniques used to publish SMTP and Exchange mail services. In the first part, you learned how to publish SMTP and Exchange mail services on the ISA server. Publishing Exchange 2000 services on the ISA server has been a long misunderstood subject that has never, until the publication of this book, been adequately explained to the public.There are a number of procedures you must go through in order to prevent conflict so you’ll be able to get all the services to work together and publish the Exchange services among the Exchange services, the ISA server, and the Internet Information server. We also covered how to publish Exchange mail services on the internal network. The procedures are very similar and in many ways much easier because you don’t need to run IIS services on the ISA server.You can also leverage the automation provided by the Secure Mail Services Wizard to make your server publishing rules and protocol rules. Publishing mail services on the internal network is the preferred configuration because you don’t have to worry about weaknesses in any of the Exchange services compromising your firewall.

Defensive Tactics Fast Track Configuring Mail Services on the ISA Server Computer ; You need to disable IIS services, or disable socket pooling when running

Exchange server on the ISA server. ; You must configure any running IIS services to listen only on the internal

interface after socket pooling is disabled. ; Exchange 2000 mail services also use socket pooling.You must disable socket

pooling for the Exchange mail services and configure them to listen only on the internal interface before publishing them. ; Exchange mail services can be published in the clear, without protection by

SSL, or you can publish secure services by assigning a certificate to the service and configuring the client to use SSL. ISA Server allows you to create secure server publishing rules that allow only secure service access. ; You cannot publish Exchange RPC services on the ISA server because you

can’t disable socket pooling on the ISA server and you would have to disable packet filtering.You must always enable packet filtering if the external interface of the ISA server is connected to an untrusted network.

www.syngress.com

444


; You can publish OWA on the ISA server.The best way to do so is to use basic

authentication only and require secure SSL connections to the OWA services.

Configuring Mail Services on the Internal Network ; Publishing Exchange mail services on the internal network requires almost the

exact procedures as when you publish the services on the ISA server.The only material difference is that you should disable IIS services on the ISA server because all services can be placed on the internal network. ; When publishing Exchange services on the internal network, you might want

to allow the SMTP service to run on the ISA server.That way, you can allow the SMTP service on the ISA server to act as a mail relay and Message Screener ; One of the major advantages of putting the Exchange server on the internal

network is that you can publish Exchange RPC services.The Exchange RPC services publish rule allows you to connect Outlook clients on an external network to the Exchange message store.

GFI’s Mail Security and Mail Essentials for SMTP Servers ; Many third-party RBLs depend on user reports to determine what mail

domains are considered spam.This RBLs are rife with abuse and shouldn’t be considered reliable. ; The best way to control spam is to use keywords. It doesn’t take very long to

develop a keyword list that’s appropriate for your organization. Keyword list control allows you to prevent spam from entering your internal network, and you do not need to depend on unreliable and often biased RBLs. ; While the SMTP Message Screener allows you to control spam by using

keyword lists, it doesn’t provide much flexibility. GFI’s MailSecurity allows you to create conditional word lists, and can be configured to search for whole words instead of plain text strings.

www.syngress.com


445


Q: I’m trying to get the Message Screener to work on the ISA server. I’m using Outlook on the internal network and Exchange on the ISA server, and the outgoing mail isn’t being filtered.What do you think the problem is?

A: The Outlook clients on the internal network don’t send messages to the Exchange server using SMTP.Therefore, the messages aren’t formatted as SMTP and aren’t exposed to the SMTP service and Message Screener.You would expect that the messages would be exposed to the Message Screener on the way out, but this isn’t reliable.You will need to create a second SMTP virtual server and have the first SMTP virtual server forward mail to the second. At this point, the messages are formatted as SMTP and are fully exposed to the SMTP Message Screener. It takes a little work, but the messages will be filtered reliably.

Q: I’m trying to run OWA on the ISA Server machine, but I keep getting errors regarding port 80 already being in use.What do you think is using port 80 on my machine?

A: There are several places where port 80 can come into play. Make sure that you aren’t advertising Autodiscovery information on the internal interface on port 80. Another place where port 80 might cause problems is with the IIS W3SVC. Make sure that you disable socket pooling on the WWW service and configure the service to listen only on the internal interface.

Q: I’m not able to change my password in OWA.What’s the secret? A: You need to create the IISADMPWD virtual directory and then create an entry in your OWA destination set for the _AuthLogin* string.You must also force connections to the IISADMPWD virtual directory to use SSL.This can be configured at the virtual directory in the Internet Information Services console.

Q: I keep getting certificate errors when I connect Internet Explorer to my OWA site. How can I fix this?

www.syngress.com

446


A: The most common reason for this is that the name on the Web site certificate is not the same as the name used to access the site. Remember that you do not use the ISA Server’s machine certificate on the Incoming Web Requests listener.You need to obtain a certificate for your Web site, and then export the certificate. Copy the exported certificate to the ISA server and then attach the Web site certificate to the Incoming Web Requests listener.This is how the ISA server is able to impersonate the secure Web server on the internal network.

Q: Its takes a long time to authenticate with the OWA site, and then the entire OWA page doesn’t appear. Is there a way to make this faster and more reliable?

A: You are probably having issues with authentication protocol negotiation.The default setting on the OWA directories is to negotiate both integrated and basic authentication.The problem is that there are multiple issues with versions of Internet Explorer and OWA using integrated authentication.The easiest way to fix this problem is to configure the sites to accept only basic authentication and use SSL to protect the credentials.The other option is to allow both basic and integrated authentication, and then upgrade all your clients to Internet Explorer 6.0 SP1 or higher.

Q: I’m getting mail to leave my network, but it stays in the queue when trying to send it outbound.What’s the problem and how do I fix?

A: There are two common reasons for mail not being able to leave the Exchange server. The first is that the Exchange server can’t resolve the destination mail domain. Make sure that either the Exchange server or the DNS server on the internal network can resolve remote mail domains.You’ll need to create DNS query and DNS zone transfer protocol rules to allow either the DNS server on your internal network or the Exchange server to resolve these domain names.The other reason for mail sitting in the Exchange server queue is that there isn’t an SMTP protocol rule in place that allows the Exchange server to send outgoing mail.

www.syngress.com

Chapter 7

Understanding Windows Default Access Control Settings


Overview of Security Groups and Access Control

■

Configuring Security during Windows 2000 Setup

■

Default File System and Registry Permissions

■

Default User Rights

■

Default Group Membership


448

Chapter 7 • Understanding Windows Default Access Control Settings

Introduction When Microsoft released Windows NT, the goal was to provide an operating system suitable for the business environment. As such, NT included features that were not present in Microsoft’s consumer operating systems (the Windows 9x/ME line). One feature was added security; unlike previous Microsoft operating systems, NT supported mandatory logon and file level permissions. Windows 2000 took security several steps further, providing for file encryption (EFS), IP Security (IPSec) support, Kerberos authentication, and more.Weaknesses in NT’s security were evaluated and addressed. In this book, we cover many of Windows 2000’s built-in security features.While Windows 2000 includes enhanced security capabilities on many fronts, and while default settings have been tightened up in regard to some security issues, it is important to know where you’re starting from when you set out to fine-tune the security level of your Windows 2000 computers.When it comes to security, there is no “one size fits all” solution; different organizations have different security needs.This chapter discusses the Windows default security settings.We will provide you with information on what you can expect “out of the box” in regard to Windows’ access controls, and how you can tweak these default settings to fit your specific situation. One of the weaknesses in Windows NT 4.0 is inherent in the default access permissions assigned to the built-in groups for the file system and the Registry.Windows 2000 addresses that weakness by refining the permissions granted to these groups. In the next section, we will discuss the default permissions assigned to Windows 2000’s built-in groups.

Overview of Security Groups and Access Control Windows 2000 Server can be configured as either a member server or a stand-alone server when it is first installed on a clean system (that is, a computer without an operating system already installed, as opposed to upgrading a Windows NT server to Windows 2000). If the server participates in a domain, it is a member server; if it is in a workgroup, it is a stand-alone server. Active Directory is not automatically installed during a fresh installation of a system, because the setup program does not know whether you want the device to be a member server or a domain controller (DC). Unlike with Windows NT, you do not select the role during the installation process. If you want a Windows 2000 server to be a domain controller, you must run the dcpromo.exe program after installation is completed to “promote” it to DC status.

www.syngress.com

Understanding Windows Default Access Control Settings • Chapter 7

449

NOTE If you upgrade a Windows NT domain controller to Windows 2000, you will be prompted during the upgrade process to run dcpromo in order to make the new Windows 2000 server an Active Directory domain controller.

However,Windows 2000 Server does automatically create the following groups when it is first installed: ■

Administrators

■

Backup Operators

■

Guests

■

Power Users

■

Replicator

■

Users

These groups are found in the Groups folder under Local Computer Users and Groups in the Computer Management console. Figure 7.1 shows a screenshot of the Local Users and Groups on a typical Windows 2000 server.These same groups, with the exception of Power Users, are also present after a system is promoted to domain controller; however, additional groups are added to the DC as domain local groups.The additional groups are: ■

Account Operators

■

Print Operators

■

Server Operators

These groups, as well as the other five groups that are listed above, are found in the Builtin folder of your directory tree in the Active Directory Users and Computers console.They are known as built-in or default groups. Figure 7.2 demonstrates Active Directory Users and Groups. A major segment of operating system security is defined by the default access permissions granted to three groups: Administrators, Power Users, and Users.Thus, it is important that you understand the default settings for these groups.

www.syngress.com

450


Figure 7.1 Built-In Groups for Windows 2000 Server Installed on a Clean System

Figure 7.2 Built-In Groups for a Windows 2000 Server Domain Controller

The Administrators Group The Administrators group is the most powerful group available on the system. Members of the Administrators group can perform any function available in the operating system, and they are not restricted from access to any file system or Registry object. Best www.syngress.com


451

practices dictate that the number of members of the Administrators group be kept to a minimum precisely because they do have so much power. Ideally, each person in the Administrators group should also have another account that he or she uses for everyday tasks.The account in the Administrators group should be used only when the administrator needs to perform administrative tasks such as: ■

Configuring system parameters such as password policy and audit functions

■

Installing service packs and hotfixes

■

Upgrading the operating system or software

■

Installing hardware drivers

■

Installing or removing system services

BEYOND ISA SERVER Windows 2000 includes the secondary logon service (RUNAS) to allow running programs with different credentials than those of the currently logged-on user. This makes it feasible for administrators to use two user accounts: one account with administrative privileges and the other without administrative privileges. It is no longer necessary, as it was with Windows NT, to log off the regular user account and log back on with the administrative credentials in order to perform administrative tasks. RUNAS is a command-line utility that includes several parameters that allow you to load a specified user profile, use the current network environment instead of the user’s local environment, specify that the user information is for remote access only, or specify a program or command to run using the specified user account. RUNAS runs as a service, and the service must be started to use the RUNAS command. If RUNAS will not work, you should check the status of the service in Computer Management | Services and Applications | Services. Alternately, you can start RUNAS by holding down the Shift key while you right-click on a program from the Programs menu, and selecting Run as… from the right context menu. Note that RUNAS does not work with all programs.

The Users Group The Users group is the most restrictive group available in Windows 2000.The default security settings prevent members of the Users group from modifying machinewide Registry settings, program files, and operating system files (thus, they cannot change operating system settings). Members of the Users group are also prevented from www.syngress.com

452


installing applications that can be run by other members of the Users group. Users can install programs that are capable of being installed for the current user only; some legacy applications (written for earlier versions of Windows) cannot be installed by members of the Users group. By default, users can access the computer from the network or log on locally (unless they are prohibited from doing so by user rights restrictions on their individual accounts or another group of which they are members). Users can also, by default, shut down the computer if it is a workstation, but by default cannot shut down servers (whether or not they are domain controllers).

The Power Users Group The Power Users group in Windows 2000 has more system access than the Users group, but less system access than the Administrators group. Power Users can install applications to a Windows 2000 system as long as the application does not need to install any system services. Only the Administrators group can add system services. Power Users can also modify systemwide settings such as Power Configuration, Shares, Printers, and System Time. However, Power Users cannot access other users’ data that is stored on NTFS partitions unless they have explicitly been given permission to do so. Power Users can create new user accounts, but they cannot modify or delete any account they did not create, nor can they add themselves (or anyone else) to the Administrators group. Power Users can create local groups and add users to or remove users from local groups they have created.The Power Users group, as its name suggests, has a great deal of power on a system, and in Windows 2000, the group is backward compatible with the default security settings for the Users group in Windows NT 4.0. That is, Power Users have all the capabilities that Users had in Windows NT 4.0.

BEYOND ISA SERVER Another new feature that enhances Windows 2000 security is the Restricted Groups list. The built-in default Windows 2000 groups, such as the Power Users and Administrators groups, are automatically on the Restricted Groups list, but you can add other groups if they are considered privileged. If a user account is added to a group on the list, but that account is not listed in the Restricted Groups node for that group, that user’s account will be automatically removed when Group Policy settings are applied. The Restricted Groups feature is generally used for controlling membership in local groups on workstations or member servers, rather than domain groups.

www.syngress.com


453

Configuring Security during Windows 2000 Setup The default security settings for Windows 2000 are put in place during the beginning of the graphical user interface (GUI) mode portion of setup if the installation is a clean install or if it is an upgrade from a Windows 95 or Windows 98 system. However, if the upgrade is being performed on an existing Windows NT system, the existing security settings are not modified. Of course, for file system settings to be applied, you must be using NTFS, not the FAT file system.To see the security settings that are applied during Windows 2000 setup, go to %windir%\Inf and locate these files: ■

defltdc.inf Domain controller security settings

■

defltsv.inf Server security settings

■

defltwk.inf Professional security settings

Each of these files contains all the default security settings that are applied to the system, depending on the type of system that is being installed. Here is a small portion (the top portion) of the security settings from the defltsv.inf file: ; (c) Microsoft Corporation 1997-2000 ; ; Security Configuration Template for Security Configuration Editor ; ; Template Name:

DefltSV.INF

; Template Version: 05.00.DS.0000 ; ; Default Template For Windows NT 5.0 Server. ; This template should NOT be used on Domain Controllers. ; ; Revision History ; 0000 -

Original

[Profile Description] %SCEDefltSVProfileDescription%

[version] signature="$CHICAGO$" revision=1

www.syngress.com

454

Chapter 7 • Understanding Windows Default Access Control Settings DriverVer=11/20/1999,5.00.2186.1

[System Access] ;---------------------------------------------------------------;Account Policies - Password Policy ;---------------------------------------------------------------MinimumPasswordAge = 0 MaximumPasswordAge = 42 MinimumPasswordLength = 0 PasswordComplexity = 0 PasswordHistorySize = 0 RequireLogonToChangePassword = 0 ClearTextPassword = 0

;---------------------------------------------------------------;Account Policies - Lockout Policy ;---------------------------------------------------------------;No Account Lockout LockoutBadCount = 0

;The following are not configured when No Account Lockout ;ResetLockoutCount = 30 ;LockoutDuration = 30

;---------------------------------------------------------------;Local Policies - Security Options ;---------------------------------------------------------------;DC Only ;ForceLogoffWhenHourExpire = 0

;NewAdministatorName = ;NewGuestName = ;SecureSystemPartition

;---------------------------------------------------------------;Event Log - Log Settings ;----------------------------------------------------------------

www.syngress.com


455

;Audit Log Retention Period: ;0 = Overwrite Events As Needed ;1 = Overwrite Events As Specified by Retention Days Entry ;2 = Never Overwrite Events (Clear Log Manually)

[System Log] MaximumLogSize = 512 AuditLogRetentionPeriod = 1 RetentionDays = 7 RestrictGuestAccess = 0

[Security Log] MaximumLogSize = 512 AuditLogRetentionPeriod = 1 RetentionDays = 7 RestrictGuestAccess = 0

[Application Log] MaximumLogSize = 512 AuditLogRetentionPeriod = 1 RetentionDays = 7 RestrictGuestAccess = 0

;---------------------------------------------------------------;Local Policies - Audit Policy ;----------------------------------------------------------------

[Event Audit]

;Auditing is Off by Default AuditSystemEvents = 0 AuditLogonEvents = 0 AuditObjectAccess = 0 AuditPrivilegeUse = 0 AuditPolicyChange = 0 AuditProcessTracking = 0 ;AuditDSAccess = 0

www.syngress.com

456

Chapter 7 • Understanding Windows Default Access Control Settings AuditAccountLogon = 0 CrashOnAuditFull = 0

As you read through the template, you should be able to recognize the different sections and maybe some of the settings within the sections. If you were to look at the entire file, you would find that the bottom section appears to be cryptic.This section contains (among other things) the service configuration, privilege settings, and Registry changes to be made. It is difficult (to say the least!) to understand exactly what changes are being made in this section.The following is a small sample of the lower portion of defltsrv.inf: ;Server Only Services Dfs,2,"D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPLOCRRC;;;PU)(A;;CCDCL CSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A ;;CCLCSWRPWPDTLOCRRC;;;SY)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;W D)" LicenseService,2,"D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPLOCRRC;;;PU )(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWD WO;;;SO)(A;;CCLCSWRPWPDTLOCRRC;;;SY)S:(AU;FA;CCDCLCSWRPWPDTLOCRSD RCWDWO;;;WD)" SMTPSVC,2,"D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPLOCRRC;;;PU)(A;;CC DCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO )(A;;CCLCSWRPWPDTLOCRRC;;;SY)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO; ;;WD)"

;IIS Specific Services - Leave them alone ;IISADMIN,2,"D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPLOCRRC;;;PU)(A;; CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;; SO)(A;;CCLCSWRPWPDTLOCRRC;;;SY)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDW O;;;WD)" ;W3SVC,2,"D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPLOCRRC;;;PU)(A;;CCD CLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO) (A;;CCLCSWRPWPDTLOCRRC;;;SY)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;; ;WD)" ;MSFTPSVC,2,"D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPLOCRRC;;;PU)(A;; CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;; SO)(A;;CCLCSWRPWPDTLOCRRC;;;SY)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDW O;;;WD)"

www.syngress.com


457

[Registry Keys] "MACHINE\Software",2,"D:P(A;CI;GR;;;BU)(A;CI;GRGWSD;;;PU)(A;CI;GA ;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;CO)(A;CI;GRGWSD;;;S-1-5-13)" "MACHINE\Software\Classes",2,"D:P(A;CI;GR;;;BU)(A;CI;GRGWSD;;;PU) (A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;CO)(A;CI;GRGWSD;;;S-1-513)(A;CI;GR;;;WD)" "MACHINE\SOFTWARE\Classes\helpfile",2,"D:P(A;CI;GR;;;BU)(A;CI;GR; ;;PU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;CO)(A;CI;GRGWSD;;;S1-5-13)(A;CI;GR;;;WD)" "MACHINE\SOFTWARE\Classes\.hlp",2,"D:P(A;CI;GR;;;BU)(A;CI;GR;;;PU )(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;CO)(A;CI;GRGWSD;;;S-1-513)(A;CI;GR;;;WD)" "MACHINE\SOFTWARE\Microsoft\Command Processor",2,"D:P(A;CI;GR;;;BU)(A;CI;GR;;;PU)(A;CI;GA;;;BA)(A;CI; GA;;;SY)(A;CI;GA;;;CO)" "MACHINE\SOFTWARE\Microsoft\Cryptography",2,"D:P(A;CI;GR;;;BU)(A; CI;GR;;;PU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;CO)" ;"MACHINE\SOFTWARE\Microsoft\Cryptography\OID",2,"D:P(A;CI;GR;;;B U)(A;CI;GR;;;PU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;CO) ;"MACHINE\SOFTWARE\Microsoft\Cryptography\Providers\Trust",2,"D:P (A;CI;GR;;;BU)(A;CI;GR;;;PU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA; ;;CO)" ;"MACHINE\SOFTWARE\Microsoft\Cryptography\Services",2,"D:P(A;CI;G R;;;BU)(A;CI;GR;;;PU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;CO)"

The default security that is applied during the beginning of the GUI mode of setup is applicable only to the core of the Windows 2000 operating system. In other words, any optional components you decide to install, such as Certificate Server or Internet Information Server, are responsible for configuring the default security settings for their components if the security inherited by default is not sufficient.

Default File System and Registry Permissions Default security settings vary by user. For example, members of the Administrators, System, and Creator Owner groups have full control of the Registry and the file system at the beginning of the GUI mode of setup.

www.syngress.com

458


BEYOND ISA SERVER Windows 2000 includes several special identities that are known by the security subsystem, including: ■ ■ ■ ■ ■

System Creator Owner Everyone Network Interactive

The System special identity represents the local computer’s operating system. The Creator Owner special identity is used on directories. Any users who create files or directories in a directory that has Creator Owner permissions inherit the permissions given to Creator Owner for the files or directories they create. The Everyone, Network, and Interactive groups cannot be modified, nor can you view the members of these groups. Their contents are as follows: ■ ■ ■

The Everyone group contains all current and future users of the network, including guests and members of other domains. The Network group consists of users who are given access to a resource over the network. The Interactive group is the opposite of the Network group; it consists of users who access a resource by logging on to the resource locally.

These groups are available when you assign rights and permissions to resources. Other groups might be available under certain circumstances; for example, if a Windows 2000 server is running Terminal Services in application mode, the Terminal Server Users Group comes into play.

However, the default permissions for Power Users and Users vary greatly from the permissions given to Administrators. Power Users do have permission to modify areas that Users cannot. For example, four areas in which Power Users can use the Modify permission are: ■

HKEY_LOCAL_MACHINE\Software

■

Program files

■

%windir%

■

%windir%\system32

Power Users can modify these four areas so that they can install existing applications. With existing applications, Users might not be able to install the application, because the application might need to write to areas that Users do not have permission to modify. www.syngress.com


459

The Modify permission that Power Users have for %windir% and %windir%\system32 does not apply to files that were installed during the text mode setup of Windows 2000. Power Users have Read-Only access to those files. Users are limited to the areas for which they are explicitly granted Write access. This restriction helps protect the system from tampering.Table 7.1 shows the only areas in which Users have Write permissions by default. For areas not listed in the table, Users have Read-Only permission or no permissions on the rest of the system. Table 7.1 Locations with Default Users’ Write Access Location

Access Permission

HKEY_Current_User

Full Control

%UserProfile%

Full Control

All Users\Documents

Modify

All Users\ Application Data

Modify

%windir%\Temp

Synchronize, Traverse, Add File, Add Subdir

c:\

Not changed during setup

Remarks Users have full control over their sections of the Registry. Users have full control over their Profile directories. Users have Modify permission on the Shared Documents location. Users have Modify permission on the shared application data location. Users have these permissions on the per-machine temp directory so that Profiles do not have to be loaded in order for service-based applications to get the per-User temp directory of an impersonated user. During setup, Windows 2000 does not change the permissions on the root directory, since doing so would affect all objects underneath root, which is not desirable during setup.

The last item in Table 7.1 states that Users might have Write permissions to the root of the hard drive.This is possible because setup does not change the existing permissions for the root when Windows 2000 is installed. If you installed Windows 2000 to an NTFS partition on a clean system, the root is configured with default permissions, and it assigns the Everyone group Full Control.This occurs when the clean system is formatted during setup. It is important that you remember that the Everyone group has Full Control of the root directory, so that you can make the changes necessary for your environment. Table 7.2 compares the default access control settings given to the Users and Power Users groups for objects on the file system.The permissions for directories apply to directories, subdirectories, and files, unless stated otherwise in the Remarks column. www.syngress.com

460


Table 7.2 File System Default Access Control Settings for Users and Power Users

File System Object

Default Users’ Access Control Settings

Default Power Users’ Access Control Settings Remarks

boot.ini ntdetect.com ntldr ntbootdd.sys autoexec.bat config.sys \ProgramFiles %windir%

No Permissions No Permissions No Permissions No Permissions Read & Execute Read & Execute Read & Execute Read & Execute

Read & Read & Read & Read & Modify Modify Modify Modify

%windir%\*.*

Read & Execute

Read & Execute

%windir%\config\*.*

Read & Execute

Read & Execute

%windir%\cursors\*.* Read & Execute

Read & Execute

Execute Execute Execute Execute

N/A N/A N/A N/A N/A N/A N/A Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Permission applies only to files in the %windir% directory, not any other subdirectories. Permission applies only to files in the %windir%\config directory, not any other subdirectories. Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Permission applies only to files in the %windir%\curses directory, not any other subdirectories. Power Users can write new files in this directory, but they Continued

www.syngress.com


461


File System Object

%windir%\Temp

%windir%\repair %windir%\addins


Synchronize, Traverse, Add File, Add Subdir List Read & Execute


Modify

Modify Modify (directories/ subdirectories) Read & Execute (files)

%windir%\ Connection Wizard

Read & Execute

Modify (directories/ subdirectories) Read & Execute (files)

%windir%\fonts\*.*

Read & Execute

Read & Execute

%windir%\help\*.*

Read & Execute

Read & Execute

cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. N/A

N/A Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. Power Users can write new files in this directory, but other Power Users only have Read permissions for those files. Permission applies only to files in the %windir%\fonts directory, not any other subdirectories. Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Permission applies only to files in the %windir%\help directory, not any other subdirectories. Power Users Continued

www.syngress.com

462



File System Object



%windir%\inf\*.*

Read & Execute

Read & Execute

%windir%\java

Read & Execute


%windir%\media\*.*

Read & Execute

Read & Execute

can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Permission applies only to files in the %windir%\inf directory, not any other subdirectories. Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. Permission applies only to files in the %windir%\media directory, not any other subdirectories. Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Continued

www.syngress.com


463


File System Object



%windir%\msagent

Read & Execute


%windir%\security %windir%\speech

Read & Execute Read & Execute

Read & Execute Modify (directories/ subdirectories) Read & Execute (files)

%windir%\system\*.* Read & Execute

Read & Execute

%windir%\twain_32

Read & Execute


%windir%\web

Read & Execute


Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. N/A Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. Permission applies only to files in the %windir%\system directory, not any other subdirectories. Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. Continued

www.syngress.com

464



File System Object



%windir%\system32\ Read & Execute

Modify

%windir%\ system32\*.*

Read & Execute

Read & Execute

%windir%\ system32\config %windir%\ system32\dhcp %windir%\ system32\dllcache %windir%\ system32\drivers %windir%\ system32\catroot

List

List

Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Permission applies only to files in the %windir%\system32 directory, not any other subdirectories. N/A

Read & Execute

Read & Execute

N/A

No Permissions

No Permissions

N/A

Read & Execute

Read & Execute

N/A

Read & Execute


%windir%\ system32\ias

Read & Execute


%windir%\ system32\mui

Read & Execute


Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. Continued

www.syngress.com


465

Table 7.2 File System Default Access Control Settings for Users and Power Users Default Users’ Access Control Settings


Read & Execute

Read & Execute

%windir%\system32\ Read & Execute OS2\DLL\*.*

Read & Execute

%windir%\system32\ Read & Execute RAS\*.*

Read & Execute

File System Object %windir%\ system32\OS2\*.*

Permission applies only to files in the %windir%\system32\OS 2 directory, not any other subdirectories. Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Permission applies only to files in the %windir%\system32\OS 2\DLL directory, not any other subdirectories. Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Permission applies only to files in the %windir%\system32\RA S directory, not any other subdirectories. Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Continued

www.syngress.com

466



File System Object



%windir%\system32\ Read & Execute shellext


%windir%\system32\ Read & Execute viewers\*.*

Read & Execute

%windir%\system32\ Read & Execute wbem


%windir%\system32\ wbem\mof %UserProfile% All Users All Users\Documents All Users\ Application Data

Read & Execute

Modify

Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. Permission applies only to files in the %windir%\system32\vie wers directory, not any other subdirectories. Power Users can write new files in this directory, but they cannot modify files that were installed during setup. All Power Users inherit Modify permission on the newly created files. Power Users can write new files in this directory, but other Power Users have only Read permissions for those files. N/A

Full Control Read Modify Modify

Full Control Modify Modify Modify

N/A N/A N/A N/A

You can view permissions for the file system from Windows Explorer by rightclicking the object, choosing Properties, and then selecting the Security tab, as shown in Figure 7.3. Clicking Advanced displays the Access Control settings for the directory and the level to which the permissions apply, as shown in Figure 7.4. Selecting View/Edit shows the granular permissions available for the selected group, as shown

www.syngress.com


467

in Figure 7.5. Other items available from the Advanced button include the Auditing and Owner tabs. Figure 7.3 Security Permissions for the %Windir%\Repair Directory

Figure 7.4 Access Control Settings for the %Windir%\Repair Directory

NOTE You can use a third-party utility such as DumpSec (formerly known as DumpACL), made by Somarsoft (www.somarsoft.com) to output a report that lists the permissions and audit settings for the file system, Registry, printers, and shares in an easy-to-read format, and also includes user, group, and replication information.

www.syngress.com

468


Figure 7.5 Assigning Granular Permissions for the Power Users Group

Table 7.3 shows the default access control settings for objects in the Registry for Users and Power Users when Windows 2000 is installed to a clean system. Permissions apply to the object and all child objects unless the child object is listed in the table as a separate item. Table 7.3 Registry Default Access Control Settings for Users and Power Users

Registry Object HKEY_LOCAL_MACHINE\Software HKEY_LOCAL_MACHINE\Software\ Classes\helpfile HKEY_LOCAL_MACHINE\Software\ Classes\.hlp HKEY_LOCAL_MACHINE\Software\ Microsoft\Command Processor HKEY_LOCAL_MACHINE\Software\ Microsoft\Cryptography\OID HKEY_LOCAL_MACHINE\Software\Microsoft\ Cryptography\Providers\Trust HKEY_LOCAL_MACHINE\Software\Microsoft\ Cryptography\Services HKEY_LOCAL_MACHINE\Software\Microsoft\ Driver Signing

www.syngress.com


Default Power Users’ Access Control Settings

Read Read

Modify Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read Continued


469

Table 7.3 Registry Default Access Control Settings for Users and Power Users

Registry Object HKEY_LOCAL_MACHINE\Software\Microsoft\ EnterpriseCertificates HKEY_LOCAL_MACHINE\Software\Microsoft\ Non-Driver Signing HKEY_LOCAL_MACHINE\Software\ Microsoft\NetDDE HKEY_LOCAL_MACHINE\Software\ Microsoft\Ole HKEY_LOCAL_MACHINE\Software\ Microsoft\Rpc HKEY_LOCAL_MACHINE\Software\ Microsoft\Secure HKEY_LOCAL_MACHINE\Software\ Microsoft\SystemCertificates HKEY_LOCAL_MACHINE\Software\ Microsoft\Windows\CurrentVersion\RunOnce HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\DiskQuota HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\Drivers32 HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\Font Drivers HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\FontMapper HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\ Image File Execution Options HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\IniFileMapping HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\Perflib HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\SecEdit HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\Time Zones



Read

Read

Read

Read

No permissions

No permissions

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read via the Interactive special identity Read

Read via the Interactive special identity Read

Read

Read Continued

www.syngress.com

470



Registry Object HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\Windows HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\Winlogon HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\AsrCommands HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\Classes HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\Console HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\EFS HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\ProfileList HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\Svchost HKEY_LOCAL_MACHINE\Software\Policies HKEY_LOCAL_MACHINE\System HKEY_LOCAL_MACHINE\System\ CurentControlSet\Control\ SecurePipeServers\winreg HKEY_LOCAL_MACHINE\System\ CurentControlSet\Control\Session Manager\ Executive HKEY_LOCAL_MACHINE\System\ CurentControlSet\Control\ TimeZoneInformation HKEY_LOCAL_MACHINE\System\ CurentControlSet\Control\WMI\Security HKEY_LOCAL_MACHINE\Hardware

HKEY_LOCAL_MACHINE\SAM

HKEY_LOCAL_MACHINE\Security HKEY_USERS\.DEFAULT



Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read

Read Read No permissions

Read Read No permissions

Read

Modify

Read

Modify

No permissions

No permissions

Read via the Everyone special identity Read via the Everyone special identity No permissions Read

Read via the Everyone special identity Read via the Everyone special identity No permissions Read Continued

www.syngress.com


471


Registry Object HKEY_USERS\.DEFAULT\Software\ Microsoft\NetDDE HKEY_CURRENT_CONFIG

HKEY_CURRENT_USER HKEY_CLASSES_ROOT



No permissions

No permissions

Permissions are equal to the permissions on HKEY_LOCAL_ MACHINE\ CurrentControl Set\Hardware Profiles\Current Full Control Permissions are equal to the combination of HKEY_LOCAL_ MACHINE\ Software\Classes and HKEY_ CURRENT_USER\ Software\Classes

Permissions are equal to the permissions on HKEY_LOCAL_ MACHINE\ CurrentControl Set\Hardware Profiles\Current Full Control Permissions are equal to the combination of HKEY_LOCAL_ MACHINE\ Software\Classes and HKEY_ CURRENT_USER\ Software\Classes

You can view security permissions for items in the Registry using regedt32.exe, as shown in Figure 7.6.You cannot use regedit.exe to view security permissions. After you select a Registry key, you can view and/or change the permissions for the key, as shown in Figure 7.7. Figure 7.6 Preparing to View the Security Permissions for HKEY_CURRENT_USER

www.syngress.com

472


Figure 7.7 Security Permissions for the EFS Registry Key

Please be careful when modifying the Registry. One modification to which you should pay special attention is the Replace Permissions on Existing Subkeys check box shown in Figure 7.6. Checking this box propagates all your permissions (correct or not) to all subkeys.You could easily make a mistake and lock down the permissions for an entire Registry key with one click of the mouse.

Default User Rights The default user rights assigned to Windows 2000 vary according to the version used. Table 7.4 shows the default user rights for Windows 2000 Professional and Windows 2000 Server as member/stand-alone server and domain controller. Table 7.4 Default User Rights for Windows 2000

User Right Access this computer from network Act as part of the operating system Add workstations to domain Back up files and directories

Default for Professional

Default for Member Server/ Standalone Server

Administrators, Backup Operators, Power Users, Users, Everyone No one (defined with empty membership list) No one (defined with empty membership list) Administrators, Backup Operators

Administrators, Backup Operators, Power Users, Users, Everyone Defined with an empty membership list Defined with an empty membership list Administrators, Backup Operators

Default for Domain Controller Administrators, Authenticated Users, Everyone Defined with an empty membership list Authenticated Users

Administrators, Backup Operators, Server Operators Continued

www.syngress.com


473

Table 7.4 Default User Rights for Windows 2000

User Right Bypass traverse checking


Administrators, Backup Operators, Power Users, Users, Everyone Administrators, Change system Power Users time Administrators Create a pagefile Defined with an Create a token empty membership object list Create permanent Defined with an empty membership shared objects list Administrators Debug programs Deny access to this Defined with an empty membership computer from list network Defined with an Deny logon as a empty membership batch job list Defined with an Deny logon as a empty membership service list Deny logon locally Defined with an empty membership list Enable computer Defined with an and user accounts empty membership list to be trusted for delegation Administrators Force shutdown from a remote system Generate security Defined with an empty membership audits list Administrators Increase quotas


Default for Domain Controller

Administrators, Backup Operators, Power Users, Users, Everyone Administrators, Power Users Administrators Defined with an empty membership list Defined with an empty membership list Administrators Defined with an empty membership list Defined with an empty membership list Defined with an empty membership list Defined with an empty membership list Defined with an empty membership list

Administrators, Authenticated Users, Everyone

Administrators

Administrators, Server Operators

Defined with an empty membership list Administrators


Administrators, Server Operators Administrators Defined with an empty membership list Defined with an empty membership list Administrators Defined with an empty membership list Defined with an empty membership list Defined with an empty membership list Defined with an empty membership list Administrators

Continued

www.syngress.com

474


Table 7.4 Default User Rights for Windows 2000 Default for Professional


Default for Domain Controller

Administrators

Administrators

Administrators

Administrators

Administrators

Administrators

Defined with an empty membership list Defined with an empty membership list

Defined with an empty membership list System, IUSR_ Computername, IWAM_ Computername

Log on as a service Defined with an empty membership list Administrators, Log on locally Backup Operators, Power Users, Users, Guest (if Guest is enabled) Manage auditing Administrators and security log Administrators Modify firmware environment values Administrators, Profile single Power Users process Administrators Profile system performance Remove computer Administrators, Power Users, Users from docking station Replace a process Defined with an empty membership level token list

Defined with an empty membership list Administrators, Backup Operators, Power Users, Users, Guest (if Guest is enabled) Administrators

Defined with an empty membership list IUSR_ Computername, IWAM_ Computername, DomainName\IUSR_ Computername Defined with an empty membership list Account Operators, Administrators, Backup Operators, Print Operators, Server Operators Administrators

Administrators

Administrators

Administrators, Power Users Administrators

Administrators

Administrators, Power Users, Users

Administrators

Defined with an empty membership list

Defined with an empty membership list

User Right Increase scheduling priority Load and unload device drivers Lock pages in memory Log on as a batch job

Administrators

Continued

www.syngress.com


475

Table 7.4 Default User Rights for Windows 2000

User Right



Restore files and directories

Administrators, Backup Operators

Administrators, Backup Operators

Shut down the system

Administrators, Backup Operators, Power Users, Users

Administrators, Backup Operators, Power Users

Synchronize direc- Defined with an tory service data empty membership list Take ownership of Administrators files or other objects


Default for Domain Controller Administrators, Backup Operators, Server Operators Administrators, Backup Operators, Account Operators, Server Operators, Print Operators Defined with an empty membership list Administrators

Checking or changing the default user rights in Windows 2000 is not a straightforward process, because it is not a choice on the Administrative Tools menu. Exercise 7.1 shows you how to check the user rights on your Windows 2000 Server.

NOTE It is important to consider all of the security implications of modifying the default settings that define which groups have a particular user right. For example, in the NT 4.0 environment, administrators often granted users the right to load and unload device drivers. This made it easier for them to install printers, scanners, and similar needed hardware devices. However, it also allowed users to install unauthorized devices, and even worse, exposed them to the possibility of loading malicious code (viruses and Trojans) written to masquerade as device drivers.

Exercise 7.1 Checking User Rights through the Microsoft Management Console 1. Click Start and choose Run. 2. Type MMC in the dialog box and click OK.This will give you the Console Root window shown in Figure 7.8. www.syngress.com

476


Figure 7.8 The Console Root Window

3. Select Add/Remove Snap-In from the Console menu.You will see the Add/Remove Snap-in window shown in Figure 7.9. Figure 7.9 The Add/Remove Snap-In Window

4. Click Add.

www.syngress.com


477

5. In the Add Standalone Snap-in window, move the scrollbar down and highlight Group Policy, as shown in Figure 7.10. Figure 7.10 Select Group Policy from the Add Standalone Snap-In Window

6. Click Add.This choice will display the Select Group Policy Object window shown in Figure 7.11. Figure 7.11 The Select Group Policy Object Window

7. Click Finish to select the local computer as the Group Policy object.This is the default choice; other choices are available by clicking Browse (if the Windows 2000 server is a domain controller), as shown in Figure 7.12. 8. Click Close to close the Add Standalone Snap-in window (refer back to Figure 7.10).

www.syngress.com

478


Figure 7.12 Group Policy Objects Available to Windows 2000 Server Domain Controllers

9. Click OK to close the Add/Remove Snap-in window (refer back to Figure 7.9). 10. Double-click Local Computer Policy. 11. Double-click Computer Configuration. 12. Double-click Windows Settings. 13. Double-click Security Settings. 14. Double-click Local Policies. 15. Click User Rights Assignment.The default user rights are located in the right pane, as shown in Figure 7.13. Figure 7.13 Default User Rights for the Local Computer Policy

www.syngress.com


479

NOTE The Account Policies, Local Policies, IP Security Policies, and Public Key Policies can also be configured from the Local Security Settings console. To open the Local Security Settings console, click Start and go to Programs | Administrative Tools | Local Security Settings. Sometimes this method is quicker than creating a custom MMC as described previously.

Additional users have rights on various items shown in Figure 7.13 because additional components are installed on the Windows 2000 Server system shown in the figure. Double-clicking any of the user rights brings up a window that displays the users who have those rights, as well as an Add button to add more users to the right. Figure 7.14 shows the Back Up Files and Directories user rights, accessed by double-clicking a user right. After you click Add, you can add users and/or groups to the user rights by clicking Browse to open the Select Users and Groups window shown in Figure 7.15. Figure 7.14 The Back Up Files and Directories User Rights

Default Group Membership The default security settings in Windows 2000 and Windows NT 4.0 differ in the assignment of access control settings.Windows NT 4.0 depends on the Everyone group as the default group for file system access control lists, user rights, and Registry access control lists. All users are automatically members of the Everyone group, and they cannot be removed by the system’s administrator.This restriction causes problems when more granular control is desired; the Everyone group might need to be removed and other groups added for better, stricter control.

www.syngress.com

480


Figure 7.15 Adding Users or Groups to the Back Up Files and Directories User Rights

Windows 2000 operates differently from Windows NT 4.0.The Everyone group is no longer used to assign permissions, except for maintaining backward compatibility with applications that require anonymous Read access. In this case, the Everyone group is used to grant Read access to some file system and Registry objects. Assignment of permissions is accomplished using groups in which the administrator can control the membership.Table 7.5 lists the members of the three user groups. Table 7.5 Default Members for Local Groups

Local Group

Default Professional Members

Default StandAlone Server Members

Administrators

Administrator

Administrator

Power Users Users

Interactive Users Authenticated Users

N/A Authenticated Users

Default Domain Controller Members Administrator, Domain Admins, Enterprise Admins N/A Authenticated Users, Domain Users

Table 7.5 lists the Authenticated Users group.Windows 2000 automatically creates this group during clean installations.The Authenticated Users group is similar to the Everyone group in that the operating system, not the administrator, controls the group members.The difference between the two groups is that the Authenticated Users group does not contain anonymous users, as the Everyone group does. Members are added to or deleted from these three local groups in two ways, depending on whether the Windows 2000 server is stand-alone or a domain controller. www.syngress.com


481

For stand-alone servers, use the Computer Management selection from the Administrative Tools menu. For domain controllers, use the Active Directory Users and Computers selection from Administrative Tools.The windows in the two systems look different from each other after you have drilled down to a particular group. Figure 7.16 shows the General tab for the Administrators group from a Windows 2000 stand-alone server. It is the only tab available. Figure 7.17 shows the Members tab for the Administrators group from a Windows 2000 domain controller. It is one of four available tabs. Figure 7.16 The General Tab for the Administrators Group Properties on a StandAlone Server

Figure 7.17 The Members Tab for the Administrators Group Properties on a Domain Controller

www.syngress.com

482


Summary Windows 2000 has several built-in groups that are created when the operating system is first installed.Three of these groups contribute significantly to the security of Windows 2000, depending on the default access permissions granted to them.The three groups are Administrators, Power Users, and Users. Default permissions vary widely—from Administrators, who have complete control of the entire system, all the way down to Users, who have Read-Only access or no access. Power Users are in the middle of those two extremes.The Power Users group is not a built-in group on domain controllers; it appears only on member and stand-alone servers (as well as Windows 2000 Professional). Windows 2000 has refined the default file system and Registry permissions given to the Users and Power Users groups to enhance operating system security. An administrator can change these settings using the Security tab in Windows Explorer for file system objects and regedt32.exe for Registry objects. Windows 2000 grants default user rights to various groups, depending on which version of the operating system is used. An administrator can change these rights using the Group Policy snap-in for the Microsoft Management Console.The Group Policy snap-in is not available from the Administrative Tools menu by default; you must create a custom MMC. Each built-in group in Windows 2000 may have a default membership assigned to it. For example, the Authenticated Users group is a default group assigned to the Users group. Authenticated Users, which is used in place of the Everyone group, does not include anonymous users, so security for the operating system is enhanced.

Defensive Tactics Fast Track Overview of Security Groups and Access Control ; Windows 2000 Server can be configured as either a member server or a

stand-alone server when it is first installed on a clean system. If the server participates in a domain, it is a member server; if it is in a workgroup, it is a stand-alone server. ; The Administrators group is the most powerful group available on the system.

Members of the Administrators group can perform any function available in the operating system, and they are not restricted from access to any file system or Registry object. ; The Users group is the most restrictive group available in Windows 2000.The

default security settings prevent members of the Users group from modifying www.syngress.com


483

machinewide Registry settings, program files, and operating system files.They cannot change operating system settings and are prevented from installing applications that can be run by other members of the Users group. ; The Power Users group in Windows 2000 has more system access than the

Users group, but less system access than the Administrators group. Power Users can install applications to a Windows 2000 system as long as the application does not need to install any system services.

Configuring Security During Windows 2000 Setup ; Default templates are applied to fresh installs of Window 2000 and upgrade

installs from Windows 9x machines. ; The default templates include defltdc.inf (domain controller), defltsv.inf

(member or stand-alone server), and defltwk.inf (Professional machine). ; The templates are text files that can be edited with any text editor, such as

Notepad.

Default File System and Registry Permissions ; Administrators have full control by default. ; Users is the most restricted of the three groups discussed. ; Power Users is more powerful than Users, but less powerful than

Administrators. ; You configure file system permissions from the Security tab by right-clicking

a file or folder and choosing Properties. ; You configure Registry permissions with Regedt32 by clicking the Security

menu and choosing Permissions.

Default User Rights ; Default users rights can be changed locally on each computer or changed

centrally through Group Policy. ; Local users are managed with Computer Management | Local Users

and Groups. ; Domain users are managed with Active Directory Users and Computers.

www.syngress.com

484


Default Group Membership ; Windows NT 4.0 uses the Everyone group for its default permissions. ; Windows 2000 prefers to use the Authenticated Users groups, but it still

supports the Everyone group for backward compatibility. ; Local groups are managed with Computer Management | Local Users

and Groups. ; Domain groups are managed with Active Directory Users and

Computers.


Q: I installed Windows 2000 Server on my NTFS system, but I do not have the default security settings shown in the tables in this chapter.

A: Default security settings are applied to a system only when Windows 2000 is installed to a clean system.When a system is upgraded to Windows 2000 from Windows NT 4.0, the existing security settings are not modified.

Q: Since the default security permissions have changed for the Users group from Windows NT 4.0 to Windows 2000, how will my existing server-based applications function?

A: It might be necessary to change the environment in which the server-based application runs if it operated as a User in Windows NT 4.0. In Windows 2000, you will need to run the server-based application as a Power User.You might also need to configure your domain to run in Pre-Windows 2000 compatible mode.

Q: Why were the permissions changed for the Users group from those of Windows NT 4.0?

A: The main goal was to strengthen the operating system’s security.Tighter access controls for the Users group prevent members of that group from having access to modify the file system and the Registry, except as shown in Table 7.1. www.syngress.com


485

Q: Since the Users group is so strictly controlled, how are applications installed? A: If the application supports per-user installations, members of the Users group can install it into their User’s Profile directory. If the application does not support peruser installation, the user cannot install it, because Users cannot write to systemwide locations.You could assign or publish the software to users through Group Policy. The applications would then be installed automatically with elevated privileges.

www.syngress.com


Chapter 8

Using the Security Configuration Tool Set


Security Configuration Tool Set

■

Configuring Security

■

Analyzing Security

■

Group Policy Integration


487

488

Chapter 8 • Using the Security Configuration Tool Set

Introduction This chapter introduces the functions and uses of the Windows 2000 Security Configuration Tool Set.The Tool Set is a response to systems administrators’ need for a central, easy-to-use program that will allow configuration of domain, organizational unit, and local security. In Windows NT 4.0, configuration of various security parameters required using multiple tools, such as User Manager, User Manager for Domains, TCP/IP protocol properties, direct registry edits, the RAS administrator, and more.The Tool Set makes it possible to configure and manage these security services from a single, centralized interface. In addition to conveniently bringing together formerly widely disparate programs into a single interface, the Security Configuration and Analysis snap-in allows the administrator to analyze a local machine’s current configuration.This analysis can be performed against security templates so that the network manager can compare the present configuration to a proposed ideal configuration, which can then be applied with a couple of simple clicks of the mouse. The Security Configuration Tool Set comes at an opportune time. Never before has a Microsoft operating system offered the degree of airtight security that Windows 2000 offers. Neither has security been so configurable at such a granular level.The Tool Set allows the administrator to get a handle on the configuration and management of the Windows 2000 security scheme.

Security Configuration Tool Set The Security Configuration Tool Set is a collection of security configuration and management programs included in Windows 2000.The primary goal of each of these components is to make it easier to manage enterprisewide security parameters easier.The administrator can group the Tool Set components together into a single Microsoft Management Console (MMC) and manage security for the entire enterprise from a central location. Each component of the Security Configuration Tool Set is integrated into the security infrastructure of Windows 2000.The new Distributed Security Services model as defined in Windows 2000 requires a central interface to manage an enterprise’s complex security requirements.The Tool Set components interact with Active Directory, Kerberos Authentication mechanisms, and Windows 2000 Public Key Infrastructure.

Security Configuration Tool Set Components The four main components of the Security Configuration Tool Set are:

www.syngress.com

Using the Security Configuration Tool Set • Chapter 8 ■

Security Configuration and Analysis snap-in

■

Security Settings Extension to Group Policy

■

Security Templates snap-in

■

The command line tool, secedit.exe

489

Security Configuration and Analysis Snap-In The Security Configuration and Analysis snap-in is a security tool that allows you to create, test, and apply a variety of security scenarios. From within the Security Configuration and Analysis snap-in, you can create text-based files that contain security settings than can be transported and applied to any Windows 2000 computer.The text files are saved with the .inf extension and can be easily edited with basic text editors such as Notepad.When you manipulate security configuration, you should use the graphical interface to minimize mishaps. Information about various security scenarios is saved to a personal database that the administrator creates for personal use. Use the Security Configuration and Analysis snap-in to import other security configurations that have been saved as security templates.You can create multiple security templates and merge them into a single security database. Each personal database contains a scenario based on the security templates that have been imported into the database. After creating a security scenario, the administrator can test the scenario against the current security configuration on that machine. After the analysis, the Security Configuration and Analysis snap-in will report the current settings that deviate from the scenario stored in the database. An administrator who is pleased with the scenario results can then use a simple point-and-click procedure to update the local machine’s own security configuration to match that of the scenario stored in the database.

Security Setting Extensions to Group Policy You can save a security scenario using the Security Configuration and Analysis snap-in and then apply it to the local computer. An administrator can export security scenarios as text-based template files that can be imported into the group policy of a domain or OU.This strategy provides a tremendous degree of flexibility for the administrator who wants to obtain granular control over an enterprise’s security infrastructure. The ability to save security settings in a template file, which can be saved and backed up, provides a high degree of fault tolerance for the organization’s security plan. If an administrative misadventure causes complex alterations to the domain security policy, the administrator can restore the original security policy by importing and applying a template. www.syngress.com

490


Security Templates Microsoft provides a full set of templates that conform to a number of common security scenarios.These security templates can be broken down into two general categories: Default and Incremental.The Default or Basic templates are applied by the operating system when a clean install has been performed.They are not applied if an upgrade installation has been done.The Incremental templates should be applied after the basic security templates have been applied. The Incremental template types are Compatible (workstations or servers), Secure (workstations, servers, domain controllers), Highly Secure (workstations, servers, domain controllers), Optional Components (workstations, servers), and No Terminal SID.Two templates function as logs.The Initial Domain Controller Configuration and Initial Server or Workstation Configuration templates contain the settings applied during domain controller promotion and the settings applied during installation. If a template ends in SV, it is for a standalone or member server (a nondomain controller). If a template ends in DC, it is for a domain controller.Templates ending in WK are for Professional machines (workstations). For example, the template basicsv.inf is used to restore a standalone server to the default state of a fresh install; basicwk.inf is used to accomplish the same thing for Professional machines.Table 8.1 describes the function of these provided templates. The administrator can save time and effort during an initial rollout by applying these templates to workstations, domain controllers, and member and standalone servers.Then, as time allows, the administrator can customize and fine-tune security settings for local computers, OUs, or an entire domain. Table 8.1 Security Templates Template

Description

Default

These are the deflt*.inf templates. These files are used as the default security for clean installs of Windows 2000. These include the basic*.inf templates. Use these to correct configuration. Basic or Default templates allow the administrator to roll back security to the original installation defaults. These are the equivalent of the deflt*.inf files applied when Windows 2000 is installed. These are the compat*.inf templates. If you do not want your users to have Power User rights, the Compatible configuration alters the default permissions for the Users group so that legacy applications can run properly. Many applications require a user to have an elevated level of permissions in order to run properly. This is not a secure environment.

Basic

Compatible

www.syngress.com

Continued

Using the Security Configuration Tool Set • Chapter 8

491

Table 8.1 Security Templates Template

Description

Secure

These are the secure*.inf templates. The Secure templates increase the level of security for Account Policy, certain Registry keys, and Auditing. Permissions for file system objects are not affected by this configuration. These include the hisec*.inf templates. Highly Secure configurations add security to network communications. IPSec will be configured for these machines and will be required for communications. Down-level clients will not be able to communicate. The DC Security.inf template contains the file and Registry settings initially applied to Windows 2000 domain controllers during promotion. For clean installations, these are the same settings as defltdc.inf. Unlike defltdc.inf, DC Security.inf shows the actual values added instead of using variables. The setup security.inf template contains the security settings applied to Windows 2000 servers and workstations at the time of installation. For clean installations, these are the same settings as defltsv.inf and defltwk.inf. Unlike defltsv.inf and defltwk.inf, setup security.inf shows the actual values added instead of using variables. These are the ocfiles*.inf templates. They improve the local security for optional components. This is the notssid.inf template. It removes the terminal server SID from all registry and file system objects.

Highly Secure

Initial Domain Controller Configuration

Initial Server or Workstation Configuration

Optional Components No Terminal Server SID

The Secedit.exe Command-Line Tool The secedit.exe command-line tool offers much of the functionality of the Security Configuration and Analysis snap-in from the command line.This allows the administrator to script security analyses for many machines across the enterprise and save the results for later analysis. The secedit.exe tool’s reporting capabilities are limited. Although you can perform a security analysis from the command line, you cannot view the results of the analysis with secedit.exe.You must view the analysis results from the graphic Security Configuration and Analysis snap-in interface.

www.syngress.com

492


Security Configurations One limitation of the security templates in Windows 2000 is that you cannot test security configurations defined in the database against current domain or OU security configurations.This functionality will probably be included with future releases. Figure 8.1 shows the Security Configuration and Analysis snap-in together with the Security Templates snap-in, which creates a central security console for managing security policy throughout an organization. Figure 8.1 The Security Configuration and Analysis Snap-In Security Console

Using the provided security templates, the administrator can implement wellthought-out and tested security constructions to a new domain rollout without having to “reinvent the wheel.”The provided security templates can be customized at the network manager’s convenience as time and experience allow.

Security Configuration and Analysis Database The Security Configuration and Analysis snap-in database contains all the existing security properties available for Windows 2000 computers. It does not add any settings or extend the operating system’s security capabilities.The Security Configuration and Analysis snap-in database contains the administrator’s security preferences.The database is populated with entries derived from security templates.You have the choice to import multiple templates and merge the contents of those templates, or you can import templates in their entirety after the previous database entries have been cleared.

www.syngress.com


493

The database is central in the security analysis process.The administrator can initiate a security analysis after configuring the entries in the database to meet the organization’s perceived needs.The security analysis compares the settings in the database with the actual settings implemented on the local computer. Individual security settings will be flagged by an icon that will change, depending on whether the actual security settings are the same or different from those included in the database.You will also be informed if there are settings that have not been configured at all and thus might require your attention. Figure 8.2 shows the results of a security analysis. Prior to the security analysis, the administrator configured the preferred security settings into the database. After the database was populated with an ideal security scenario, it was tested against the current machine settings. A green check mark indicates that the current machine settings are the same as those set in the database; a red X indicates that there is a conflict, and a generic icon indicates that the setting was not defined in the database. Figure 8.2 The Results of a Security Analysis in the Security Configuration and Analysis Snap-In

After the analysis has been performed, the administrator can make changes to the database as desired and rerun the analysis.When the database matches the precise security configuration required, the administrator can then apply the database settings to the local machine’s security policy. The formulation of a well-planned security policy is a time-consuming process.To add a measure of fault tolerance, the database entries can be exported to a text file template, which can be saved for later use on the same machine or applied to another machine, domain, or OU. www.syngress.com

494


The procedure used to export the template to be saved is simple: Simply right-click the Security Configuration and Analysis snap-in node and choose Export Template, as shown in Figure 8.3. Figure 8.3 Exporting the Security Database Entries into a Template

The exported template is saved as an .inf file and can be imported to other computers, domains, and OUs. In this way, the security parameters can be reproduced exactly from one machine to another.

Security Configuration and Analysis Areas The Security Configuration and Analysis snap-in brings together in a single workspace security configuration components that were formerly spread throughout many different programs in NT 4.0.The areas of analysis are shown in Figure 8.4. Figure 8.4 The Areas of Security Configuration and Analysis

www.syngress.com


495

Account Policies The Account Policies node includes those configuration variables that you formerly manipulated in the User Manager for Domains applet in NT 4.0.The two subnodes of the Account Policies node include the Password Policy node and the Account Lockout Policy node. In the Password Policy node, you can set the minimum and maximum password ages and password lengths.The Account Lockout Policy allows you to set lockout durations and reset options.

Local Policies Local policies apply to the local machine. Subnodes of the Local Polices node include Audit Policy, Users Right Policy, and Security Options. Audit and User Rights policies look familiar to users of NT 4.0. The Security Options node offers the administrator many options that formerly were available only by manipulating the Windows NT 4.0 Registry or through the policy editor (poledit). Examples include the ability to set the message text and message title during logon, restricting the use of the floppy disk, and the “Do not display last username at logon” option.

Event Log The Event Log node allows you to configure security settings for the event log.These include maximum log sizes, configuring guest access to the event log, and whether or not the computer should shut down when the security log is full.

Restricted Groups You can centrally control the members of groups. At times, an administrator will add someone temporarily to a group, such as the Backup Operators group, and then neglect to remove that user when the user no longer needs to be a member of that group. These lapses represent a potential hole in network security.You can configure a group membership list in the Restricted Groups node and then configure an approved list of members by reapplying the security template you have created.

System Services You can define the Security parameters of all system services in the database via the System Services Node.You can define whether a service startup should be automatic, manual, or disabled.You also can configure which user accounts have access to each service.

www.syngress.com

496


Registry The Registry node allows you to set access restrictions on individual Registry keys.

File System The File System node allows you to set folder and file permissions.This is a great aid to the administrator who might have been experimenting with access permissions on a large number of files or folders and then later cannot recall the original settings.You can apply a security template to restore all file and folder permissions to their original settings.

Security Configuration Tool Set User Interfaces Two user interfaces are available to configure system security settings: the graphical interfaces and the secedit.exe command-line interface.You should do most of your work from the graphical interface—design your security scenarios, test them against extant security settings, and then apply scenarios stored in the security database after testing. After you customize security scenarios to suit your needs, you can export the scenario to a plan text file, which you can save for later use.You can edit the exported text file by hand using any available text editor. However, Microsoft recommends that users confine themselves to the graphical interface so as to not introduce random elements into the structure of the file and inadvertently corrupt its contents.Your interaction with the Security Tool Set will occur via these interfaces: ■

Security Configuration and Analysis snap-in

■

The secedit.exe command-line tool

■

Security extensions to the Group Policy Editor

Security Configuration and Analysis Snap-In You use the Security Configuration and Analysis snap-in to control local machine security policies.You cannot directly affect domain or OU security policies from the Security Configuration and Analysis snap-in.This somewhat limits the use of the Security Configuration and Analysis snap-in since you cannot use it to test various scenarios against the prevailing domain or OU security configuration. Nonetheless, the Security Configuration and Analysis snap-in remains a powerful tool.To get started, you must first create an MMC that will allow you to work with the Tool Set.To make your Security Configuration Tool Set console: 1. Choose Start | Run, enter mmc into the text box, and click OK.

www.syngress.com


497

2. From the MMC menu, click Add/remove snap-in, and then click the Add button. 3. Select and add: ■

Security Configuration and Analysis

■

Security Templates

■

Group Policy

4. Click Close in the Add Standalone Snap-in window. 5. Click OK in the Add/Remove Snap-in window. 6. Save your MMC by clicking the console drop-down menu and choosing Save As. 7. In the filename box, type Security Tool Set or any other name you want. This will automatically save your MMC into the Administrative Tools folder. You now need to open an existing database or create a new one. It is against these entries in the database that you will test your present security configuration.You can also apply the settings saved in the database to the computer itself, thus updating the local machine’s security configuration, as follows: 1. Right-click Security Configuration and Analysis, and select Open Database (see Figure 8.5). Figure 8.5 The Open Database Dialog Box

2. If there is already an existing database, you can open that one. If no databases are currently defined, you can create a new one by entering the name of the database in the filename box.Then click Open. 3. The Import Template dialog box appears (see Figure 8.6).You need to populate the database with security configuration entries.The templates contain this information. Select the template that contains the information that most

www.syngress.com

498


closely represents the level of security you are interested in (these templates were discussed in Table 8.1), and then click Open. Figure 8.6 The Import Template Dialog Box

4. In the right pane, you will see instructions on how to analyze or configure your computer. Right-click the Security Configuration and Analysis node and select either Configure or Analyze. Be careful; if you select Configure, it will apply the settings that you have imported into the database to the active security configuration of the computer. After the database has been created, you can test your configuration.You have two options.You can merge settings from another template file into your working database, or you can clear the working database so that it will contain only entries from the new template being imported. Merging templates allows the administrator a great deal of flexibility in analysis and in the application of a variety of security scenarios. In order to merge or replace the entries in the database: 1. Right-click Security Configuration and Analysis (as shown in Figure 8.3) and select Import Template.You will see the Import Template dialog box, as shown in Figure 8.6. 2. You have two choices at this point.You may select a template and then click Open. By doing this, you will merge the entries from the template with those already in the database. However, if you would prefer to start with a “clean” database by clearing the entries in the database before you import the new entries, you can select Clear this database before importing by putting a check in the box.Then click Open.

The Secedit.exe Command-Line Interface The secedit.exe command-line interface allows the administrator to: ■

Analyze system security

www.syngress.com

Using the Security Configuration Tool Set • Chapter 8 ■

Configure system security

■

Refresh security settings

■

Export security settings

■

Validate the syntax of a security template

499

Secedit Switches for Security Analysis The analyze switch is used to initiate a security analysis: secedit /analyze

Additional parameters include: /DB filename

This informs secedit.exe as to which database to apply the security analysis results to. /CFG filename

This points to the location of the template that will be imported into the database for analysis. /log logpath

This is the location of the logfile that will be created from the analysis; the default file is used. /verbose

This provides additional screen and log output when analysis is carried out. /quiet

This provides little screen or log output.

Secedit.exe Switches Used to Configure System Security Secedit applies a template by using the configure switch: secedit /configure


This informs secedit.exe as to which database to apply the security analysis results to. /CFG filename

www.syngress.com

500


This points to the location of the template that will be applied to the database. /overwrite

This switch causes the current template in the database to be overwritten rather than appended. /area area1 area2...

This allows you to specify a specific security “area” to be configured.The default is all areas. /log logpath

This is the location of the logfile that will be created with details of the security configuration. /verbose

This provides additional screen and log output. /quiet

This suppresses screen and log output.

Refresh Security Settings This command updates the system security policy after changes have been made: secedit /refreshpolicy

Additional parameters include: machine_policy

This updates the security settings for the local computer. user_policy

This updates the security settings for the currently logged in local user account. /enforce

This refreshes security settings, even if there have been no changes to the group policy object settings.

Export Security Settings Use the export switch to export the template stored in the database to an .inf file: secedit /export

www.syngress.com


501


This informs secedit.exe as to which database to extract the template from. /CFG filename

This is the name and location of the file for the newly exported template. /area area1 area2...

This allows you to specify a specific security “area” to be configured.The default is all areas. /log logpath

This is the location of the logfile that will be created with details of the security configuration. /verbose

This provides additional screen and log output. /quiet

This suppresses screen and log output.

SECURITY ALERT The Security Configuration and Analysis snap-in, Security Templates, the secedit.exe command-line tool, and security extensions to the Group Policy Editor are powerful and efficient tools that allow you to manage and control your organization’s security infrastructure. However, as with all the new tools and capabilities of Windows 2000, you should use appropriate caution before employing these tools in a live environment. Before deployment, be sure to test your security configurations in a lab environment that resembles your live environment as closely as possible. The secedit.exe command-line tool will allow you to schedule regular security audits of local policies on the machines in any domain and OU. By running scripts that call on the secedit.exe program, you can update each computer’s personal database with the results of your security analysis. You can then later use the Security Configuration and Analysis snap-in to analyze the results of your automated analysis. Always watch for the effective policy, because this can differ from the policy that you applied to the local machine. Any existing domain or OU security polices that apply to the machine will overwrite local machine policy.

www.syngress.com

502


There is a workaround for the lack of template-saving functionality in domain and OU security configurations. You can get around this problem if you always change security configuration by using only templates, and then keep track of what templates are applied when. You must not make changes to the security configuration of the computer using any other method. In this way, you can always roll back to a previous configuration.

Configuring Security The administrator can configure the entries in the security database via each of the nodes in the Security Configuration and Analysis and Security Templates snap-ins.You cannot define new security attributes.You can only modify existing Windows 2000 security elements. Microsoft or third parties might include extensions to the security attributes in the future.

Account Policies Account policies define aspects of security relating primarily to passwords.The Password Policy contains entries related to password aging and password length. Account Lockout Policy determines how many failed tries a person gets before the account is locked out. Kerberos Policy applies only to domain logons, since local logons do not use Kerberos. Entries include maximum lifetimes for various tickets, such as user tickets and user renewal. Figure 8.7 shows some entries for the account policy nodes.Table 8.2 lists all options available through the account policies. Figure 8.7 Account Policies

www.syngress.com


503

Table 8.2 Options Available within Account Policies Password Policies Enforce password history

Maximum password age

Minimum password age

Minimum password length

Passwords must meet complexity requirements Store password using reversible encryption for all users in the domain

Remembers users’ passwords. Requires that they cannot use the same password again until it has left the password history. Values range from 0 passwords remembered to 24 passwords remembered. The default is 0 passwords remembered. Defines the maximum amount of time that a user can keep a password without having to change it. Values range from the password never expires to password expires every 1–999 days. The default is 42 days. Defines the minimum amount of time that a user can keep a password without having to change it. Values range from password can be changed immediately to password can be changed after 998 days. The default is 0 days. Defines the minimum number of characters required for a user’s password. Value ranges from no password required to at least 14 characters required. The default is 0 characters. Requires that the user’s password have a mix of uppercase, lowercase, and numbers. Value is either enabled or disabled. The default is disabled. Stores a copy of the user’s password in Active Directory using reversible encryption. This is required for the message the digest authentication method to work. Value is either enabled or disabled. The default is disabled.

Account Lockout Policy Account lockout duration

Account lockout threshold

Reset account lockout counter after

Defines the time in minutes that an account will remain locked out. Value ranges from account is locked out until administrator unlocks it, or from 0 to 99,999 minutes (69 days, 10 hours, and 39 minutes). The default is not defined. Defines how many times a user can enter an incorrect password before the user’s account is locked. Value ranges from the account will not lock out to 999 invalid logon attempts. The default is 5 attempts. Defines how long to keep track of unsuccessful logons. Value ranges from 1 minute to 99,999 minutes. The default is not defined. Continued

www.syngress.com

504


Table 8.2 Options Available within Account Policies Kerberos Policy Enforce user logon restrictions Maximum lifetime for service ticket

Maximum lifetime for user ticket Maximum lifetime for user ticket renewal Maximum tolerance for computer clock synchronization

Value is either enabled or disabled. Default setting is not defined. Defines the maximum amount of time in minutes that a service ticket is valid. Value ranges from tickets don’t expire, or from 1 to 99,999 minutes. The default is 600 minutes (10 hours). Defines the maximum amount of time in hours that a user ticket is valid. Value ranges from tickets don’t expire to 99,999 hours. The default is 10 hours. – Specifies the amount of time in minutes that computers’ clocks can be skewed. Value ranges from 0 minutes to 99,999 minutes. The default is 5 minutes.

Local Policies Local policies include the Audit Policy, User Rights Assignment, and Security Options. Some Audit Policy selections include auditing logon events, use of user privileges, systems events, and object access.The User Rights Assignment node includes the ability to grant or deny user rights such as the right to add workstations to the domain, change the system time, log on locally, and access the computer from the network. The most profound improvements are seen in the Security Options node, where you can make changes that could be made only via direct Registry edits in Windows NT 4.0. Examples of such security options include clearing the pagefile when the system shuts down, message text during logon, number of previous logons kept in cache, and shut down system immediately if unable to log security audits. Figure 8.8 shows some of the entries in the Local Policies node.Table 8.3 lists all options available through the local policies.The improvements in local policy management are numerous with the addition of the configurable objects available in the Security Options node.

www.syngress.com


505

Figure 8.8 Local Policies

Table 8.3 Options Available within Local Policies Audit Policy Option

Description

Audit account logon events Audit Audit Audit

Audit Audit Audit Audit Audit

Audits when an account is authenticated to the database. account management Audits when a user account or group is created, deleted, or modified. directory service access Audits when access is gained to an Active Directory object. logon events Audits when a user logs on or off a local computer and when a user makes a network connection to a machine. object access Audits when files, folders, or printers are accessed. policy change Audits when security options, user rights, or audit policies are modified. privilege use Audits when a user right is utilized. process tracking Audits when an application performs an action. system events Audits when a security-related event occurs, such as rebooting the computer. Continued

www.syngress.com

506


Table 8.3 Options Available within Local Policies Option

Description

User Rights Assignment Access this computer from the network Act as part of the operating system Add workstations to the domain Back up files and directories Bypass traverse checking

Change the system time Create a pagefile Create a token object Create permanent shared objects Debug programs Deny access to this computer from the network Deny logon as a batch job Deny logon on as a service Deny logon locally Enable computer and user accounts to be trusted for delegation Force shutdown from a remote system Generate security audits Increase quotas

Allows a user or group to connect to the computer over the network. Allows a process to gain access to resources under any user identity. Allows user or group to add a computer to the domain. Allows a user or group to bypass file and directory permissions to back up the system. Allows a user or group to pass through directories without having access while navigating an object path in any Windows file system. Allows a user or group to set the time for the computer’s internal clock. Allows a user or group to create and change the size of a pagefile. Allows a process to create a token to get access to any local resources. Allows a process to create a directory object in the object manager. Allows a user or group to attach a debugger to any process. Denies the ability to connect to the computer over the network. Denies the ability to log on using a batch-queue facility. Denies the ability to log on as a service. Denies a user or group the ability to log on to the local machine. Allows a user or group to set the Trusted for Delegation setting on a user or computer object Allows a user or group to shut down a computer remotely. Allows a process to make entries in the security log. Allows a process to increase the processor quota for any processes to which it has write property access. Continued

www.syngress.com


507


Description

Increase scheduling priority

Allows a process to increase the execution priority for any processes to which it has write property access. Allows a user or group to install and uninstall Plug and Play device drivers. Allows a process to keep data in physical memory. Allows a user or group to log on using a batch-queue facility. Allows logging on as a service. Allows a user or group to log on to the local machine. Allows a user or group to configure object access auditing. Allows changing the system environment variables.

Load and Unload device drivers Lock pages in memory Log on as a batch job Log on as a service Log on locally Manage auditing and security log Modify firmware environment values Profile single process

Allows a user or group to use performancemonitoring tools to monitor the performance of nonsystem processes. Profile system performance Allows a user or group to use performance-monitoring tools to monitor the performance of system processes. Remove computer from Allows a user or group to undock a laptop within docking station Windows 2000. Replace a process level token Allows a process to replace the default token associated with a subprocess that has been started. Restore files and directories Allows a user or group to bypass file and directory permissions when restoring backed-up files and directories. Shut down the system Allows a user or group to shut down the local computer. Synchronize directory Allows a process to provide directory synchronization service data services. Take ownership of files Allows a user or group to take ownership of any or other objects securable system object. Security Options Additional restrictions for anonymous connections

Adds restrictions for anonymous connections. Choices include None, Do not allow enumeration of SAM accounts and share, and No access without explicit anonymous permissions. Continued

www.syngress.com

508



Description

Allow server operators to schedule tasks (domain controllers only) Allow system to be shut down without having to log on. Allowed to eject removable media Amount of time required before disconnecting session Audit the access of global system objects Audit use of Backup and Restore privilege Automatically log off users when time expires Automatically log off users when time expires (local) Clear virtual memory pagefile when system shuts down Digitally sign client communications (always)

Gives members of the Server Operators group the right to schedule tasks.

Digitally sign client communications (when possible) Digitally sign server communications (always) Digitally sign server communications (when possible) Disable Ctrl+Alt+Del requirement for logon

Enables the shutdown tab on the Ctrl+Alt+Del logon screen Multivalue Defines how long a user can be connected in an idle state before the user is disconnected. Audits when a system object is accessed. Audits when the Backup and Restore privileges are used. Disconnects users who are connected across the network when their time expires. Disconnects users who are logged in locally when their time expires. Empties the pagefile on shutdown.

Requires the computer to sign its communications when functioning as a client, whether or not the server supports signing. Unsigned communications are not allowed. Configures the computer to request signed communications when functioning as a client to a server that supports signing. Unsigned communications will be allowed, but they are not preferred. Configures the computer to require that all connecting clients sign their communications. Unsigned communications are not allowed. Configures the computer to request that all connecting clients sign their communications. Unsigned communications will be allowed, but they are not preferred. Forces smart card logon. Continued

www.syngress.com


509


Description

Do not display last user name in logon screen LAN Manager Authentication Level Message text for users attempting to log on Message title for users attempting to log on Number of previous logons to cache (in case domain controller is not available) Prevent system maintenance of computer account password Prevent users from installing printer drivers Recovery Console: Allow automatic administrative logon Recovery Console: Allow floppy copy and access to all drives and all folders Rename administrator account Rename guest account

Does not display the name of the last user to log on to the system. Controls the level of authentication supported for down-level clients. The text to be displayed in a window presented to all users logging on. The title of the window presented to all users logging on. Determines how many times users can log on with their cached credentials.

Restrict CD-ROM access to locally logged-on user only Restrict floppy access to locally logged-on user only Secure channel: Digitally encrypt or sign secure channel data (always) Secure channel: Digitally encrypt secure channel data (when possible) Secure channel: Digitally sign secure channel data (when possible)

Prevents the system from changing the computer account password. Keeps users from installing printers. Automatically logs the administrator on with the recovery console administrator account when booting to recovery console. Allows copying from a floppy when booted into recovery console. Also allows access to the entire hard drive in recovery mode. Renames the administrator account to the name specified here. Renames the guest account to the name specified here. Restricts network access to the CD-ROM. Restricts network access to the floppy drive. Requires the machine to encrypt or sign secure channel data. Configures the machine to encrypt secure channel data when communicating with a machine that supports digital encryption. Configures the machine to sign secure channel data when communicating with a machine that supports digital signing. Continued

www.syngress.com

510



Description

Secure channel: Require strong (Windows 2000 or later) session key. Secure system partition (for RISC platforms only) Send unencrypted password to connect to third-party SMB servers Shut down system immediately if unable to log security audits Smart card removal behavior

Requires the use of a Windows 2000 session key

Strengthen default permissions of global system objects (e.g. Symbolic Links) Unsigned driver installation behavior

Unsigned nondriver installation behavior

Secures the system partition. Sends a clear text to password to SMB servers that don’t support SMB signing. Shuts down the computer when the security log becomes full. Determines what will take place when a smart card is removed from the system. Choices include No Action, Lock Workstation, and Force Logoff. Strengthens the default permissions of global system objects.

Controls what happens when the installation of an unsigned driver is attempted. Choices include: Silently succeed, Warn but allow installation, and Do not allow installation. Controls what happens when the installation of an unsigned nondriver is attempted. Choices include: Silently succeed, Warn but allow installation, and Do not allow installation.

Event Log The Event Log node allows you to configure settings specifically for event logs, as shown in Figure 8.9. Event Log Configuration settings allow you to configure the length of time logs are retained as well as the size of the event logs.You can also configure that the system should shut down if the security log becomes full.Table 8.4 lists all options available through the event log policies.

www.syngress.com


511

Figure 8.9 Event Log Configuration Node

Table 8.4 Options Available within Event Log Option

Description

Maximum application log size Maximum security log size Maximum system log size Restrict guest access to application log Restrict guest access to security log Restrict access to system log Retain application log

Controls Controls Controls Prevents log. Prevents

Retain security log

Retain system log

Retention method for application log

how large the application log can grow. how large the security log can grow. how large the system log can grow. guest access from reading the application guest access from reading the security log.

Prevents guest access from reading the system log. Tells the event log not to overwrite events in the application log that are older than the number of days defined here. Tells the event log not to overwrite events in the security log that are older than the number of days defined here. Tells the event log not to overwrite events in the system log that are older than the number of days defined here. Tells the event log what to do when the application log becomes full. Choices include Overwrite events by days, Overwrite events as needed, and Do not overwrite events (clear logs manually). Continued

www.syngress.com

512


Table 8.4 Options Available within Event Log Option

Description

Retention method for security log

Tells the event log what to do when the security log becomes full. Choices include Overwrite events by days, Overwrite events as needed, and Do not overwrite events (clear logs manually). Tells the event log what to do when the system log becomes full. Choices include Overwrite events by days, Overwrite events as needed, and Do not overwrite events (clear logs manually). Instructs the computer to shut down when the security log is filled.

Retention method for system log

Shut down the computer when the security audit log is full

Restricted Groups The Restricted Groups node lends something new to the security configuration options available in Windows 2000.You can define, as part of security policy, the members of a group. At times, the administrator needs to temporarily add users to groups with a higher classification than the users’ typical group membership.This might be the case when an administrator goes on vacation and another member of the team is assigned full administrative rights. However, often the “temporary” promotion ends up being an inadvertently permanent one, and the user remains in the Administrators group. Groups can also become members of other groups when this is not part of the company security plan. By defining Restricted Group membership rules, you can return group membership to that defined by security policy. Figure 8.10 shows the Restricted Groups node entries. Exercise 8.1 walks you through configuring restricted groups.

Exercise 8.1 Configuring Restricted Groups 1. Open your custom MMC containing Security Configuration and Analysis, as shown in Figure 8.10. 2. Navigate to the Restricted Groups section. 3. Right-click Restricted Groups, and choose Add Group from the pop-up menu.You will see the window shown in Figure 8.11. 4. You can type the name of the group that you want to restrict, or click Browse to pick the group from a list. In this case, click Browse.You will see the window shown in Figure 8.12.

www.syngress.com


513

Figure 8.10 The Restricted Groups Node

Figure 8.11 The Add Group Window

Figure 8.12 The Select Groups Window

5. When you’re browsing for a group, it might help to alphabetize the list. By default, the groups are shown in the order in which they appear within Active

www.syngress.com

514


Directory Users and Computers.To alphabetize the list, click the Name bar. Select the group that you want to restrict and click Add.Then click OK.You will now see the window shown in Figure 8.13. Figure 8.13 Configure Membership for Selected Group

6. In the Configure Membership window, you can restrict who can be the members of your restricted group (in our case, the Administrators group) or you can restrict which other groups your restricted group can be a member of. Add your restrictions and click OK to save your changes.

Registry Security Registry keys can be protected by policy.You can define a security policy for a Registry key or value in the database and then customize the propagation of the setting using the Key Properties dialog box. Exercise 8.2 walks you through configuring Registry security.

Exercise 8.2 Configuring Registry Security 1. Open your custom MMC containing Security Configuration and Analysis. 2. Navigate to the Registry section, as shown in Figure 8.14. 3. Right-click Registry and choose Add Key from the pop-up menu.You will see the Select Registry Key window shown in Figure 8.15. 4. Navigate to the key that you want to secure. In this example, we are using the MACHINE\SOFTWARE key. Click OK to continue.

www.syngress.com


515

Figure 8.14 Viewing Registry Security

Figure 8.15 The Select Registry Key Window

5. After clicking OK, you will automatically be given the Database Security window shown in Figure 8.16. Use this window to choose the permissions that will be assigned to the secured Registry key. After customizing the permissions, click OK. 6. Now you will see the window shown in Figure 8.17. Use this window to tell Windows what to do with the permissions you set in Step 5.The choices are: ■

Configure the selected key and propagate inherit permissions to all subkeys.This will set permissions at the selected key and all keys below it, merging these permissions with whatever permissions are already set at each subkey.

www.syngress.com

516

Chapter 8 • Using the Security Configuration Tool Set ■

Configure the selected key and replace all existing permissions on all subkeys with inheritable permissions.This will replace the permissions on each subkey with the permissions set at the selected key.

■

Do not allow permissions on this key to be replaced.

Figure 8.16 Database Security

Figure 8.17 The Template Security Policy Setting Window

7. Choose one of these settings and click OK.

File System Security The File System Security node allows you to configure NTFS permission for all local drives. It is common for a number of administrators to get into Windows Explorer and customize the NTFS permissions on file and folders through the file system. File and folder security should be part of a well-planned and well-implemented security plan. www.syngress.com


517

This security plan can be realized by setting File System Policy in the templates (as shown in Figure 8.15).You can then periodically audit the status of the file system to look for inconsistencies between the plan and the actual state of NTFS permissions in the local environment. Exercise 8.3 walks you through the process of using file system security.

Exercise 8.3 Configuring File System Security 1. Open your custom MMC containing Security Configuration and Analysis. 2. Navigate to the File System section, as shown in Figure 8.18. Figure 8.18 File System Security Settings

3. Right-click File System and choose Add File from the pop-up menu.You will see the Add a File or Folder window shown in Figure 8.19. Figure 8.19 Adding a File or Folder

www.syngress.com

518


4. Navigate to the file or folder that you want to secure. In this example, we are using c:\. Click OK to continue. 5. After you click OK, you will automatically be given the Database Security window shown in Figure 8.20. Use this window to choose the permissions that will be assigned to the secured file or folder. After customizing the permissions, click OK. Figure 8.20 The Database Security Window

6. Now that you have set the permissions, you have to tell Windows how to propagate them. Figure 8.21 shows the Template Security Policy Setting window. Use this window to tell Windows what to do with the permissions you just configured.The choices are: ■

Configure the selected file or folder and propagate inheritable permissions to all subfolders and files.This choice sets permissions at the selected file or folder and all subfolders and files below it, merging these permissions with whatever permissions are already set at each subfolder or file.

■

Configure the selected key and replace all existing permissions on all subfolders and files with inheritable permissions.This choice replaces the permissions on each subfolder and file with the permissions set at the selected file or folder.

■

Do not allow permissions on this file or folder to be replaced.

7. Choose the appropriate setting from these choices, and click OK to save your changes.

www.syngress.com


519

Figure 8.21 The Template Security Policy Setting Window

System Services Security The System Services node allows you to control security and startup policy on all the services defined in the template. Controlling the startup behavior of system services can save the administrator many headaches over time. Consider the situation of users starting up their own RAS services or DHCP services haphazardly.This type of situation creates a large security risk for any network.You can set restrictive networking services startup properties and assign all computers that require certain services to an OU that does have the right to start up particular networking services. Figure 8.22 shows some of the content of the Services node. Exercise 8.4 walks you through configuring System Services Security. Figure 8.22 Content of the Services Node

www.syngress.com

520


Exercise 8.4 Configuring System Services Security 1. Right-click the service that you want to secure and choose Security from the pop-up menu.You will see the Security Policy Setting window shown in Figure 8.23. Figure 8.23 The Security Policy Setting Window

2. In the Security Policy Setting window, check the box next to Define this policy setting. After you choose to define the policy, you will immediately be given the window shown in Figure 8.24. Figure 8.24 Configuring Security for a Service

3. Use the Security for Service window (where service is the name of your selected service) to configure the permissions for the selected service. After you configure the permissions, click OK to return to the Security Policy Setting window shown in Figure 8.23.

www.syngress.com


521

4. Choose the startup mode for your service, and click OK to save your changes.

Analyzing Security One of the most useful features of the Security Configuration and Analysis snap-in is the ability to compare the desired security policies as they are set up in the template with the actual state of the local machine.The administrator is able to glean a tremendous amount of insight regarding the machine’s current security configuration using the Analyze feature of the Security Configuration and Analysis snap-in. Running the analysis is easy. After you import the security settings from the appropriate templates, all you need to do is right-click the Security Configuration and Analysis node and select the Analyze Computer Now option. Exercise 8.5 walks you through the steps.

Exercise 8.5 Analyzing the Local Machine 1. After creating a database and importing a template, right-click Security Configuration and Analysis and choose Analyze Computer Now, as shown in Figure 8.25. Figure 8.25 Analyzing the Computer Now

www.syngress.com

522


2

After you choose Analyze Computer Now, you will be prompted to give a location in which to store the log files, as shown in Figure 8.26. Use the Browse button to set the correct location.The default name for the log file is database_name.log (where database_name is the name of your database). Click OK to continue. Figure 8.26 Setting the Error Log File Path

3

After you click OK, you will be given the Analyzing System Security window shown in Figure 8.27.You can see from this window which component of your system is currently being analyzed. Once this process has finished running, you can see the differences between the template file and your local system. Figure 8.27 Running the Analysis

Account and Local Policies Figure 8.28 shows the results of an analysis on the local audit policy. Icons with a green check mark indicate that the database setting and the machine settings are the same. Icons with a red X indicate that there is a discrepancy between the entry in the database and that of the actual configuration.The generic icon means that no setting for that security parameter was set in the database.

Restricted Group Management Figure 8.29 shows the results of an analysis of the restricted group management policy. The columns in this analysis show an OK status for the Members and Members Of columns.The same icon indicators that apply to this analysis apply to account and local policies.

www.syngress.com


523

Figure 8.28 Results of the Audit Policy Analysis

Figure 8.29 The Restricted Group Management Policy Analysis Results

Registry Security Figure 8.30 shows the results of a Registry policy analysis. After the Registry analysis, you can zoom in on specific keys and values to assess the consistency between the database and the actual Registry security attributes.

File System Security Figure 8.31 shows the results of a file system security analysis.The results of the analysis show whether permissions or audit policies have been set on volumes, folders, or individual files.The same icon schema applies in this instance as in the other analyses. In

www.syngress.com

524


Figure 8.31, the Program Files and WINRC2 folders have permissions and auditing configured.The database settings and the actual settings match in both instances. Figure 8.30 Results of a Registry Policy Analysis

Figure 8.31 The Results of a File System Security Analysis

System Services Security Figure 8.32 shows the results of a system service policy analysis.The results show the status of Startup and Permissions options and their consistency with the database.

Group Policy Integration You can use the features of the Security Configuration Tool Set to configure group policies.This capability is important to the administrator who is interested in config-

www.syngress.com


525

uring the security of an entire domain or OU. By extending the group policy capabilities of the Security Configuration Tool Set to the Group Policy objects of choice, the network manager can speed deployment of uniform policy through many computers in the domain. Figure 8.32 The Results of a System Service Policy Analysis

Security Configuration in Group Policy Objects The Security Configuration Tool Set allows for the configuration of security policy, which is one aspect of group policy. Security policies designed and tested using the Security Configuration and Analysis snap-in can be exported and applied to domains and OUs. A significant limitation at this time is the inability to export security configuration parameters from a domain or OU.This limits the full functionality of the Security Configuration and Analysis snap-in to analyzing security parameters of the local machine only. At this time, you cannot export the domain or OU security policy for analysis. However, you can import a security policy that has been saved as an .inf file.Security policy can be edited in the Group Policy object.

The Security Settings Extension to the Group Policy Editor The Security Configuration and Analysis snap-in allows you to configure local machine policies easily. However, for the configuration of security structure of an entire domain or OU, you need to use the security settings extension to the Group Policy Editor.

www.syngress.com

526


You cannot use the Security Configuration and Analysis snap-in to configure the security settings of a domain or OU.To apply a security configuration to an OU: 1. Open the Active Directory Users and Computers console from the Administrative Tools menu. Right-click an organizational unit and select Properties. 2. The organizational unit’s properties box appears. Click the Group Policy tab (see Figure 8.33). Figure 8.33 The Group Policy Tab in the Organizational Unit’s Properties Sheet

3. Click New.Type a name for the Group Policy object. Make sure that the new object is selected, then click Edit. 4. Expand Computer Configuration, then expand Windows Settings.There are two subnodes of Windows Settings: Scripts and Security Templates. Select the Security Templates node (see Figure 8.34). 5. Right-click the Security Settings node, and select Import Policy. Notice that the policies are template files with the .inf extension.You have the option of merging the template’s entries into the present OU’s security setup, or you can clear the present OU’s security settings and have them replaced by the settings in the imported template. Click Open to enact the new policy. You are not given the option to test the template settings against the present OU’s security configuration.The settings are enabled after you import the policy via the .inf file.

www.syngress.com


527

Figure 8.34 Group Policy Security Settings

Additional Security Policies The following are a few additional security policies of which you should be aware: ■

IPSec policy IPSec security policies can be configured and analyzed in the Security Configuration and Analysis snap-in. For more information on IPSec, see Chapter 10, “Protecting Data in Transit with IPSec.”

■

Public key policies Included in the public key policies are the encrypted data recovery agents, root certificates, and certificate trust lists.These topics are covered in detail in Chapter 12, “Creating a Public Key Infrastructure with Certificate Services,” and Chapter 9, “Defending Your Data with the Encrypting File System.”

www.syngress.com

528


Summary The Security Configuration Tool Set introduces a new and more efficient way to manage security parameters in Windows 2000. Using this new set of configuration and management tools, the administrator can configure and manage the security policies for a single machine or an entire domain or organizational unit. The Tool Set includes the Security Configuration and Analysis snap-in, Security templates, the secedit.exe command-line tool, and the security settings extensions to the Group Policy Editor.Together, you can use these tools to create and configure security policies for local machines, domains, or OUs. The Security Configuration and Analysis snap-in allows the administrator to create a database with security configuration entries.These security configuration entries can be used to test against the existing security configuration of a local machine. After the security analysis is complete, the network manager can save the database entries into a text file with the .inf extension.This text file, which is a template consisting of security configuration entries, can be saved or imported in order to define the security definition of another local machine, a domain, or an OU. The security variables in the database can also be applied to the local machine, replacing the current security configuration.The new configuration is applied after the analysis is complete. Security configurations can be saved as templates, which are text files that contain security configuration information.These templates are imported into the Security Configuration and Analysis snap-in database for analysis and application. The Security Configuration and Analysis snap-in cannot be used to configure or analyze security configurations of a domain or OU. In Windows 2000 there is no way to export extant domain or OU security configurations. However, you can configure the security of a domain or OU via the security settings Group Policy extensions. The secedit.exe command-line tool allows the administrator to script security analyses, security configurations, security updates, and export of templates. Its functionality is almost equal to that of the Security Configuration and Analysis snap-in, except that you must use the graphical interface to review the results of a security analysis performed by secedit.exe. An administrator can use the security settings Group Policy extensions to configure domain or OU security policy. In addition, you can import security templates directly into the domain or OU.You should do this with great caution if you have already customized the security settings for a domain or OU. At present, you cannot export the previous settings into a template that might be restored later. However, if the administrator always reconfigures the security parameters of a domain or OU by using templates, such templates can always be restored in the future.

www.syngress.com


529

Defensive Tactics Fast Track Security Configuration Tool Set ; The main components of the Security Configuration Tool Set are the Security

Configuration and Analysis snap-in, the security settings extension to Group Policy, secedit.exe, and the Security Templates snap-in. ; The Security Configuration and Analysis snap-in creates, configures, and tests

security scenarios.You can create text-based .inf files that contain security settings.You can apply these files to the computer or save them for later use. ; Microsoft provides templates for configuring security. Default and incremental

templates are available. Default templates are applied during a fresh install only. The incremental templates provide additional security above the defaults. ; Secedit.exe allows us to configure security from the command prompt. ; The Security Templates snap-in allows us to view and customize the template

files stored in %windir%\security\templates.

Configuring Security ; Account policies define password policy, account lockout policy, and Kerberos

policy. ; Local policies include the audit policy, user rights assignment, and security

options. ; Event Log Configuration settings allow you to configure the length of time

logs are retained as well as the size of the event logs. ; The Restricted Groups setting configures group membership and group nesting. ; Registry Policy sets permissions on Registry keys. ; The File System Security setting configures NTFS permission for all local

drives. ; The System Services setting controls the startup policy for all local services.

www.syngress.com

530


Analyzing Security ; Compare security policies in the template with the actual state of the local

machine.This practice allows administrators to see the differences before they apply the policy. ; Use Security Configuration and Analysis to view the results of an analysis.

Group Policy Integration ; You can use the features of the Security Configuration Tool Set to configure

group policies. ; Security policy can be edited in the Group Policy object.


Q: Can I use the Security Configuration and Analysis snap-in to analyze the security configuration of a domain or OU?

A: Not at this time.This capability should be added in the future. However, at present, you can test scenarios against the current configuration for the local machine.

Q: I would like to use scripts to analyze a number of computers in my domain.What tool would I use to accomplish this task?

A: The secedit.exe command-line tool allows the administrator to analyze a number of machines by creating scripts that can be automated.You can then view the results of the analysis by opening the database file against which the analysis was run.

Q: Why have the changes I made to the security policy on the local computer not taken effect?

A: Effective policy depends on whether a computer is a member of a domain or an OU. Policy precedence flows in the order in which policies are applied. First the local policy is applied, then site policy is applied, then domain policy is applied, and

www.syngress.com


531

finally OU policy is applied. If there are conflicts among the policies, the last policy applied prevails.

Q: Can I migrate my Windows NT 4.0 policies to Windows 2000? A: No.The NT policies were stored in a .pol file, which included things such as group memberships.There is no way for the Windows 2000 Group Policy Model, which is centered on Active Directory, to interpret the entries in the .pol file. Microsoft recommends configuring the settings in the old .pol files in Active Directory.You can do this easily using the security settings extension to the Group Policy Editor. The Windows NT 4.0 .pol files were created by the System Policy Editor, which used .adm files as templates for the options configured in system policy.These files are compatible with Windows 2000 .adm files. However, you should not import these templates, because you might damage the registries of client machines.This means that after a Registry setting is set using Windows NT 4.0 .adm files, the setting will persist until the specified policy is reversed or the Registry itself is directly edited.

Q: How do I reverse the changes I made after applying a security policy? A: There is no direct mechanism, such as an Undo button, that will allow you to reverse the changes. Before you enact any changes to the local computer policy, back up the present configuration by exporting the current settings to an .inf file. Then you can restore your system to its previous state by importing the .inf file into the database and reapplying the changes.

www.syngress.com


Chapter 9

Defending Your Data with the Encrypting File System


The Role of EFS in a Network Security Plan

■

Using the Encrypting File System

■

User Operations

■

EFS Architecture


533

534

Chapter 9 • Defending Your Data with the Encrypting File System

Introduction Regardless of the efficacy of the barriers that you erect to keep others from accessing or intercepting your sensitive data, you must recognize that your barriers won’t always work. Confidential files sometimes fall into the wrong hands.Thus, you need to take additional steps to ensure that when this happens, unauthorized persons will not be able to read the data even though they have it in their possession.That’s where encryption comes in. Data encryption is a concept that predates computers.The art and science of cryptography involves hiding or changing information to protect it from unauthorized persons.The word comes from the Greek word for hidden, and the ancient Greeks, as well as those in other ancient civilizations, practiced cryptographic techniques when sending important military, political, and personal messages. Encryption “scrambles” data so that it appears to be gibberish to anyone who doesn’t have the means to “unscramble,” or decrypt, it. All computer data is ultimately sent or stored in binary form (as ones and zeroes).To encrypt the binary data, a mathematical procedure called an algorithm (a calculation or formula) is applied, using a variable called the key. Methods used to encrypt data are called ciphers, and the encrypted form of data is called ciphertext. To decrypt data and return it to comprehensible form, the recipient of the data must use the proper key.This might be the same key used to encrypt it (a method called symmetric encryption) or it might be a different, mathematically related key (in a method called asymmetric encryption).

NOTE For a fuller discussion of cryptography and encryption as well as other basic security concepts, see Chapter 7 of Scene of the Cybercrime: Computer Forensics Handbook by Debra Littlejohn Shinder (Syngress Publishing, Inc. ISBN 1931836655 2002).

When we discuss encryption in regard to computer data, we need to make a distinction between two different uses of the technology: ■

Encryption of data as it travels across a network

■

Encryption of data stored on disk

With the Windows 2000 operating system, Microsoft introduced built-in features to accomplish each of these tasks. Support for the Internet standard Internet Protocol Security (IPSec), which we discuss in Chapter 10, provides encryption for data in

www.syngress.com

Defending Your Data with the Encrypting File System • Chapter 9

535

transit. In this chapter, we focus on the encryption of data stored on disk as implemented by Microsoft’s Encryption File System (EFS).

NOTE Prior to the release of Windows 2000, users of Microsoft operating systems had to depend on third-party software to encrypt stored data.

Remember, the fact that you have implemented a firewall—such as ISA Server— and that the Windows NT-based operating systems include mandatory logon and access control for files does not guarantee that your data will be protected from unauthorized eyes. If thieves want to steal your data, they can achieve their goal in many ways.Tools on some other operating systems can access NTFS volumes while bypassing the access control supplied by NTFS. Lack of physical security allows entire portable systems to be stolen easily. In addition, many laptop/notebook computers now come with removable hard drives.This is great for thieves, because they have less contraband to conceal.The laptop itself still appears on the desk, so a thief has more time to exit a building before any alarms go off. A desktop computer’s second hard drive can also be removed and easily spirited away. To keep your data from being viewed and/or modified by an unauthorized user, you should implement file encryption. EFS, which is included in Windows 2000 and improved in Windows XP/.NET, makes this easy. However, in order to take advantage of EFS, you must format the partitions on which the files are stored to NTFS. Furthermore, you should know that even if you use these operating systems and use NTFS, no data is encrypted by default.You must explicitly set the encryption property on the files or folders that you want to protect. In this chapter, we examine the features and architecture of EFS and show you how to use it to provide extra security for your sensitive data.

The Role of EFS in a Network Security Plan A good network security plan is multilayered, just as a good physical security plan includes perimeter control (fencing), external security (guard dogs and security cameras), barriers (locks on doors), internal security (motion detectors and indoor cameras), and object-specific security (safe for valuables). In a network security plan, if your ISA server or other firewall is analogous to a high, strong fence sitting on the perimeter of the network, you might think of file encryption as a “safe” into which you put specific objects (that is files and folders) to protect them in case someone breaks through all the outer obstacles.

www.syngress.com

536


An important part of security planning is determining which assets need the most protection.You’ll want to assess the sensitivity and importance of data on a case-by-case basis to decide which files and folders to encrypt.Why not just encrypt the entire disk and be done with it? Well, that is not the best solution for several reasons: ■

Operating system files that must be accessed to use the system cannot be encrypted.

■

Data that needs to be compressed cannot be encrypted.

■

The encryption/decryption process slows performance somewhat, so taking the performance hit for data that has no need to be encrypted doesn’t make sense.

■

Encrypted files can only be accessed by the person who encrypted them (in Windows 2000) or persons explicitly added to the access list (in Windows XP/.NET). So files that need to be accessible to many people cannot be encrypted in Windows 2000 and can only be encrypted in Windows XP/.NET with a lot of work because you’ll have to add everyone to the access list.

Another consideration is the fact that encrypting data might in some cases be like putting a red flag on it that announces to the world that “this data is sensitive and important!” If only one file on an entire disk is encrypted, that file will instantly become interesting to any intruder. For this reason, encrypting a number of files instead of only one or two is a good idea.That way, highly sensitive files won’t stand out quite so much. Remember that EFS fills only part of a network’s encryption needs. EFS does not encrypt data sent across a network. If you attempt to send an EFS encrypted file across a network, someone who intercepts the packet with a protocol analyzer (called a sniffer) will be able to read the data. EFS is only intended to protect data on a disk.You should use IPSec to encrypt data to be sent across the network. If data is sensitive enough to be protected while it’s stored on disk, it’s sensitive enough to be protected when it’s transmitted on a network.

Using the Encrypting File System The Encrypting File System supported in Windows 2000 and XP/.NET is a security feature built into the NTFS file system. Both public key encryption and secret key encryption (discussed later in this chapter) are implemented within the complete process, so data is encrypted quickly and in such a way that it can stand up against an attack from cryptanalysts (people who specialize in analyzing and “breaking” encryption

www.syngress.com


537

algorithms). U.S. customers who purchase Windows 2000 receive a 56-bit standard DES algorithm for implementation, but U.S. customers can also obtain a 128-bit encryption DES algorithm. Until export approval was received, Microsoft also had a 40-bit DES algorithm for all international customers. An encrypted file can be read by anyone with a private key that can decrypt the File Encryption Key. In the Windows 2000 implementation of EFS, only the user who encrypted a file and a designated recovery agent (usually the network administrator) can decrypt the data.The version of EFS included in Windows XP/.NET adds the capability to share encrypted files with others. The provision of a recovery agent is important in the implementation of EFS in the business environment. If a user leaves a company or if a user’s private key becomes corrupted or is accidentally deleted, the recovery agent can implement data recovery.This might sound like a security weak spot, but data recovery in Windows is not a security weakness. Microsoft has written code to establish an Encrypted Data Recovery Policy (EDRP), which controls who can recover data if the owner’s private key is lost or if an employee leaves the organization. In a workgroup environment,Windows automatically sets up the EDRP on the local machine. In a domain environment, the EDRP is set up in the domain policy by the system administrator, and computers belonging to the domain will receive the EDRP from that location. If a computer is not a member of a Windows 2000 domain and you force an administrative password change on the user account that was used to encrypt the files, those files become unrecoverable. In a domain environment, you have more recovery options for EFS files.

NOTE If you want to store encrypted files on a remote server, the server must be trusted for delegation. You must be a domain administrator to configure the server as trusted for delegation. This is done through the Active Directory Users and Computers (ADUC) console. For detailed instructions, see Microsoft Knowledge Base article Q307877. Also note that you will not be able to access encrypted files from Macintosh clients.

Encryption Fundamentals As mentioned previously, encryption is the process of taking a plaintext file and processing it so that the original data is in a new ciphertext (unreadable) format.Typically the encryption process uses an algorithm and a secret value that is referred to as the key.

www.syngress.com

538


Public Key (Asymmetric) Cryptography Public key cryptography is designed so that each person has two keys—a public key and a private key.The two keys are mathematically related, but the private key cannot be discovered by knowing the public key.Table 9.1 identifies the differences between these two keys in typical use. Table 9.1 Public and Private Keys Key

Description

Use

Private Public

Never made known to anyone but the user. Known worldwide.

Decryption Encryption

Public key cryptography is also known as asymmetric cryptography, because users employ different keys to encrypt and decrypt a file. Public key-based algorithms usually are highly secure, but they are considered slow. Figure 9.1 illustrates the basic processes of public key encryption and decryption. Figure 9.1 Public Key Encryption and Decryption

Plaintext

Plaintext Public Key

Cipher Text

Plaintext

Plaintext

Private Key

BEYOND ISA SERVER Public key pairs can be used as described to provide confidentiality of data. The sender of a message uses the recipient’s public key to encrypt it, then sends it to the recipient who uses his/her own private key to decrypt it. Only the private key that belongs to the same key pair as the recipient’s public key will work. Another use for public key cryptography is to provide authentication of the identity of the sender of a message. For this purpose, the sender encrypts the data with his/her own private key and sends it to the recipient who uses the sender’s public key to decrypt it. Because the public key is available to anyone, there is no confidentiality, but because only the private key associated with the sender’s public key could have been used to encrypt it (otherwise the public key wouldn’t work to decrypt it), the recipient can be assured that the message came from the sender.

www.syngress.com


539

Secret Key (Symmetric) Cryptography Instead of a key pair, symmetric cryptography uses a single, shared secret key.The same key is used for both encrypting and decrypting the data. One popular method of symmetric cryptography is the Data Encryption Standard (DES), which the National Bureau of Standards defined in 1977 for commercial and nonclassified use. Developed by a team of IBM engineers who used their Lucifer cipher and input from the National Security Agency, DES is an encryption algorithm that uses a 56-bit binary number key. Secret key algorithms are implemented quickly. Because the DES algorithm uses a single key for both encrypting and decrypting data, this security mechanism is weaker in its design than asymmetric methods. Symmetric cryptography requires some mechanism for sharing the secret key, and this exposes it to the possibility of interception. Figure 9.2 illustrates the secret key algorithm method. Figure 9.2 Secret Key Algorithm Plaintext

Plaintext

Secret Key

Cipher Text

Cipher Text

Plaintext

Secret Key

One major difference between symmetric and asymmetric algorithms is the number of keys that are used in the process. Public key algorithms use a key pair, but secret key algorithms use a single key.This major difference can clearly be seen in Figures 9.1 and 9.2.What the figures do not show is the difference between the two algorithms in terms of the amount of time needed to fully process the encrypting and decrypting of the file. Because of this speed difference, asymmetric algorithms are most useful for small amounts of data. Symmetric algorithms can be used to efficiently encrypt large amounts of data. Public key encryption is a slower process method than secret key encryption, so each should be implemented appropriately.The two encryption technologies can be used together for the optimum balance between performance and security.

How EFS Works Microsoft implements both secret key encryption, which is a faster and less secure process, and public key encryption, which is a slower but more secure process.When a request to encrypt a file is received by the operating system, the Encrypting File System generates a random number for the file.This random number is known as the file’s File Encryption Key (FEK).With the FEK, a modified DES algorithm, called DESX, is used www.syngress.com

540


to generate the encrypted file and store it on disk.The secret key algorithm is being implemented at this point. Figure 9.3 shows a diagram of the EFS encryption process. Figure 9.3 The EFS Encryption Process

Plaintext

FEK and

Cipher Text

DESX

When a file needs to be decrypted, the FEK is used again. If you store the FEK on disk with the file, you have the FEK available for decryption at any time. Anyone who needs to decrypt the file and who has access to it also has access to the file’s FEK. Keeping sensitive data secure is the most important concern, but convenience is also important. Experience shows that when a security process is inconvenient for users, they are less likely to use it.The FEK is stored on disk and is available whenever it is needed, so the process is convenient and quick, but anyone who can get to the file will have available the one item needed for decrypting the file.This means you must address the security of the FEK itself. Secret key encryption is weak in this aspect, but public key encryption can be used here to good effect.Thus, to tighten the FEK’s security, you can encrypt it also.This is where public key cryptography comes in. When a user encrypts a file, the Encrypting File System uses the user’s public key to encrypt the FEK.This design prevents users from sharing one decryption key. In Windows 2000, multiple users cannot share encrypted files.The public key encryption method is used only on the small FEK, so the system’s performance isn’t impacted.The ciphered FEK is stored with the encrypted file. Only the user, with that user’s private key, can decrypt the ciphered FEK, which is needed to decrypt the actual file. At this point, both the sensitive data and the FEK are secured.The slow method of public key algorithm is not used on the large file.The final design of file encryption for Windows 2000 allows you to get the best from both encryption worlds.

NOTE File encryption keys are stored in the nonpaged memory pool. This means the keys will never be in the paging file, which would create a security risk.

Windows XP/.NET enables support for sharing of EFS encrypted files among multiple users, without sharing of private keys among users.The file must first be encrypted by one user, who can then enable sharing and select the specific users who

www.syngress.com


541

are to have access to the encrypted file. Any user who has an account on the local machine or in the Active Directory and who has a valid EFS certificate can be added. Each authorized user can then decrypt the file using his/her own private key.

NOTE You might be wondering about the security of temporary files that are used by some programs. Because of the way the NTFS file system works, this does not present a security problem. When temp files are created, all of the attributes from the original file (including the encryption attribute, if it is present) are copied to the temp files. This means EFS encrypts the temporary copies as well as the original file.

Now let’s pull all these loose ends together into a clear, precise picture. In the following sections, we look at the “how to” aspects of using EFS to protect your data.

User Operations The Encrypting File System adds more security to the Windows operating system than ever before.This built-in encryption allows any user to protect sensitive data against unauthorized use.This much-needed security feature can be used immediately after the operating system installation.The only requirement for the Encrypting File System is an NTFS partition. No new administrative tasks involving installation and configuration of the Encrypting File System need to be completed in order for it to work.The user operations that use file encryption are: ■

Encrypting a file or folder

■

Accessing an encrypted file

■

Copying an encrypted file

■

Preventing files from being encrypted on a server

■

Moving or renaming an encrypted file

■

Sharing an encrypted file (in Windows XP/.NET)

■

Decrypting a file

■

Using the Cipher Utility (in Windows 2000)

■

Encrypting a directory

■

Employing recovery operations

www.syngress.com

542


Encrypting a File or Folder The Encrypting File System uses a public key pair and a secret key in the encryption and decryption process.When a user attempts to encrypt a file, the EFS must determine first whether a key pair exists for the user or whether one must be created. If a key pair needs to be created, the generation will occur on a domain controller or on the local computer, depending on the environment, unnoticed by the user. Other tasks completed by the Encrypting File System include creating the actual ciphertext file, ciphering the FEK, creating a log, creating a backup file, and deleting the log and backup file used in the encryption process. A great deal of activity takes place in the background, but the user is unaware of it. In order to manage encrypted file resources, you must first identify what data needs to be protected and then use one of two methods to let the operating system know where the Encrypting File System should be implemented.Your choices are: ■

Windows Explorer interface

■

Cipher command line utility

Encrypting a File or Folder on the Local Computer An owner can encrypt any folder or file as long as it is stored on an NTFS partition. The easiest way to maintain encrypted files is to first create an encrypted folder in which you plan to store all sensitive data. Marking a directory for encryption has no effect on the listing of the files in the directory when you use the Explorer interface. You can easily encrypt a folder using the graphical interface.When a folder is created, go to the Advanced Attributes and check Encrypt contents to secure data, as shown in Figure 9.4.This sets the encryption bit on the folder. Figure 9.4 A Directory Marked for Encryption

www.syngress.com


543

After this bit is set, the directory is marked for encryption. Any newly created file or subdirectory stored in the marked directory from this point on will be encrypted automatically.This makes it easy to encrypt files simply by creating them in or moving them to this folder. If the directory is marked for encryption and it already contains files and subdirectories, you will receive a dialog box (as shown in Figure 9.5) that allows you to specify how far down in the directory structure encryption should be set. Figure 9.5 Confirming Attribute Changes

NOTE Microsoft recommends setting the encryption attributes on folders rather than individual files.

You will see the message box shown in Figure 9.6 while encryption takes place.This message box shows the estimated time required to complete the encryption process. Figure 9.6 Applying Attributes

Compressed or system files cannot be encrypted by EFS. Note that EFS encryption is not available until the boot process is completed, which is efficient, considering the complexity of the encryption/decryption process. For this reason, you cannot encrypt the files that are used in the boot process.

www.syngress.com

544


NOTE If you create an encrypted folder and another user creates a document in that folder, it will be encrypted using the creator/owner’s private key. This means you will not be able to access it unless (in Windows XP/.NET) the creator/owner has enabled sharing of the encrypted file and added your account to the user access list.

The Encrypting File System process will fail if you try to encrypt a file that has the system bit set. An attempt to encrypt a system file—that is, a file on which the system attribute is set—produces the message, “An error occurred applying attributes to the file. Access is denied.”The Encrypting File System also will fail if you try to encrypt a file on the root. Encryption can be implemented at both the directory level and the file level.To encrypt a single file on a NTFS partition, follow these steps: 1. In Windows Explorer, select the file you want to encrypt. 2. Right-click to bring up the Context menu, and then select Properties. 3. Click Advanced on the General tab. 4. In the Advanced Attributes dialog box, select the check box Encrypt contents to secure data, then click OK. 5. On the General tab, click OK or Apply to mark the file as encrypted. Later in this chapter, in the section titled “Using the Cipher Utility (in Windows 2000),” we discuss how to use the command line interface to encrypt and decrypt files and directories.

NOTE Never try to encrypt the files the system uses to boot. Microsoft wrote the Encrypting File System code to prevent the accidental encrypting of system files.

Encrypting a File or Folder on a Remote Computer You can encrypt a file or folder on a remote computer that is running NTFS. If the computer is in a domain, however, remote encryption must be enabled by making the remote computer trusted for delegation. Follow these steps to encrypt a file on a remote machine: 1. Connect to the remote computer through a mapped network drive. www.syngress.com


545

2. Select the file or folder you want to encrypt and right-click it. 3. Click Properties in the right context menu. 4. Select the General tab, then click the Advanced button. 5. Check the Encrypt contents to secure data check box. 6. Click OK.

Accessing an Encrypted File Accessing an encrypted file involves no special action by a user.There is no need to explicitly decrypt a file before using it.When the operating system verifies that a user has an acceptable private key, the system automatically decrypts the file so the user can read and/or modify it.The stored file is still encrypted on the disk.When the bytes are moved from the disk into the user’s working set, the bytes go through the decryption process.When the user saves the file back to the disk, the files is encrypted again.The encryption and decryption processes are transparent to users.

NOTE If an unauthorized user attempts to open an encrypted file, he or she will receive a message stating that access is denied. An unauthorized user also will not be able to copy or move an encrypted file to a different location on the disk.

Backing up your encrypted files is important, as with any critical data. In the Windows 2000 and XP/.NET operating systems, just as in earlier versions of Windows NT, a file owner can control access to a file through the use of access permissions. If owners want to remove all access except their own, they can do so by setting NTFS permissions.The fact that only the owner has permission to access a file does not prevent system administrators from backing up the file on a regular basis. Also, any user who belongs to the Backup Operators group has the ability to execute the Backup Utility and back up the file.The Backup Operators group is tied to the Backup Files and Directories user right, which, when it runs the Backup Utility, allows the file to be opened and read.The Backup Files and Directories right contains code that will bypass the normal access control list (ACL). The Encrypting File System also provides backup utilities with the ability to back up and restore files in ciphertext format.The backup process will not be able to decrypt the sensitive information nor will it have to decrypt and encrypt during the backing-up operation.The ADVAPI32.DLL library will provide the EFS APIs necessary for access to the encrypted data.

www.syngress.com

546


When Windows Backup backs up encrypted files, no special configuration is needed. Members of the Backup Operators group will not have a private key to decrypt the files, so there is no risk that they can read the sensitive data that you have encrypted. Encrypted data is backed up during a backup operation as it exists on disk. The Backup Utility reads and records the ciphertext file without decryption.

Copying an Encrypted File The copy command has been extended in Windows 2000 and later operating systems with two new switches to allow you to export or import an encrypted file.When an encrypted file is copied, the encryption attribute always takes precedence. If either the file you want to copy or the destination directory is encrypted, the resulting new file will be encrypted.This differs from copying files in other circumstances, in which a file always inherits the attributes of the target parent directory.Table 9.2 lists various copying situations and the status of the resulting created files. Table 9.2 Copying Encrypted Files Starting Encryption

Copied To

New File Status

Both the directory and file are encrypted Both the directory and file are encrypted The directory is encrypted but the file is not encrypted The directory encrypted but the file is not encrypted Both the directory and file are unencrypted Both the directory and file are unencrypted

A directory that is not encrypted

Encrypted

A directory that is encrypted

Encrypted


Encrypted

A directory that is not encrypted

Unencrypted


Encrypted

A directory that is unencrypted

Unencrypted

NOTE Be aware that if you copy a file that is encrypted on your hard disk to a medium such as a floppy disk, which does not support NTFS (or other media formatted in FAT, such as a FAT partition on your hard disk), the encryption attribute will be lost and the file will be in an unencrypted state on the FATformatted media. This can pose a serious security risk. There is no warning message that the encryption will be lost when you copy the file. The file is decrypted to make the copy, but this is completely transparent to users.

www.syngress.com


547

If you copy an encrypted file to a different computer, you’ll need to export your EFS certificate and private key to the other computer in order to be able to open the file on the other computer.

Preventing Files from Being Encrypted on a Server There might be circumstances in which administrators do not want users to be able to store encrypted files on a file server. A Registry edit can be done on the server to prevent files on the server from being encrypted with EFS.This edit can also prevent encrypted files on a user’s local hard disk from being copied to the server in an encrypted state. If a user copies encrypted files to a server that’s configured to not store encrypted files, the files will be stored as unencrypted files. To edit the Registry so that files can’t be encrypted on a server, perform the following steps: 1. On the Start menu, click Run. 2. In the Run box, type regedit. Click OK. 3. Navigate to the following Registry key: HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\FileSystem 4. Expand this key and locate the NtfsEncryptionService value. 5. Delete this value. You will need to reboot the server before the change takes effect. After you complete the Registry edit, users can only copy their encrypted files to the server in an unencrypted state.

NOTE Microsoft recommends that you always back up the Registry before making changes to it. See article Q256986 in the Microsoft Knowledge Base for information about how to back up, restore, and edit the Registry. Remember that Registry changes take place immediately; that is, there is no way to undo a change after you’ve made it (although many changes won’t actually take effect until you reboot because that’s when the Registry values are loaded by the operating system and/or applications).

Moving or Renaming an Encrypted File Renaming an encrypted file is no different from renaming a compressed file.The operating system changes the filename but makes no modification to any other fields in the www.syngress.com

548


file’s header.The fact that the file is encrypted sets an encryption bit in the file’s header. Renaming changes the file’s name but does not touch the encryption attribute. When an encrypted file is moved, it retains its encrypted status, regardless of the destination folder if on the same Windows 2000 system and an NTFS partition.When an encrypted file is moved on the same partition, there is no difference to the file other than the resident directory of the file.This is because only the pointer to the file is changed; the file and its attributes are completely untouched.When the encrypted file is moved to a different NTFS partition, the file is first decrypted and then encrypted before being stored at the new location.When a file or folder is moved to a partition that is not formatted in NTFS, the file or folder loses all NTFS attributes, including the encryption attribute, and is decrypted. Commonly, users get new workstations due to hardware upgrades, change physical locations in a company, and so forth. In these cases, users’ local files are often transferred to new computers. If encrypted files or folders are moved to a new computer, you must export the user’s keys and EFS certificate from the old computer and import them to the new computer; otherwise, the user won’t be able to access the encrypted files.

Sharing an Encrypted File (in Windows XP/.NET) Users of EFS in Windows 2000 found that the feature had a major drawback in some circumstances—specifically, only the user who encrypted a file could access it; it was not possible to allow others to access an encrypted file without the original user having to decrypt it and share it with others in a decrypted state. A major improvement to EFS in Windows XP/.NET is the ability to share access to encrypted files. In Windows XP/.NET, the original user who encrypts a file can add other user accounts to the list of those who can access the file in its encrypted state.This makes for a higher level of security.

NOTE In addition to the original user who encrypted a file, members of the administrators group can add users to an encrypted file.

To allow others to access an encrypted file, following these steps: 1. In Windows Explorer, right-click the encrypted file that you want to share. 2. Click Properties, select the General tab, and click Advanced. 3. Click Details, then click the Add button. 4. From the list of users, select the user account with which you want to share access. Click OK. www.syngress.com


549

5. Add additional users if you want. 6. Click OK to close each dialog box.

NOTE Adding a user to an encrypted file’s access list allows the user to transparently decrypt the file. A user must also have the proper NTFS permissions to edit or modify the file.

Decrypting a File Users never need to explicitly request that a file be decrypted as long as only that user needs to access the file (in Windows 2000) or as long as other users who are to have access have been added to the file’s properties (in Windows XP/.NET).That does not mean that the decryption process will never occur.The decryption process does occur in two instances: ■

The Encrypting File System goes through the decryption process whenever the file is accessed, but this processing is transparent to the user.

■

Decryption occurs when a file’s owner decides that the added security method is no longer needed and chooses to set the file’s attributes to unencrypted.

When a user wants to read and/or modify the contents of an encrypted file, the operating system decrypts the file as it is moved from the hard drive into physical memory.The file’s decryption for use is completely transparent to the user, and the ciphered or encrypted form of the file is still stored on the hard drive.The user does not have to decrypt the file manually before each use.The user works with encrypted files just as he or she works with normal, unencrypted files. The Encrypting File System must have the user’s private key in order to decrypt the file. If the user does not have a valid private key to the file, the system message “Access is denied” appears, just as when the user does not have the proper permission. Decryption also occurs if and when a user decides that encrypted information is no longer sensitive and therefore does not have to be encrypted.The user can then implement the decryption process at the file or directory level.The user can use the Windows Explorer interface to clear the encryption bit, or the user can use the Cipher Utility and execute the appropriate command.When an individual file is selected for decryption, only that file is affected.When the user requests decryption at the directory level, a dialog box appears asking whether the user wants to decrypt all files and subdirectories found within this directory, as shown in Figure 9.7. www.syngress.com

550


Figure 9.7 The Confirm Attribute Changes Dialog Box

The decryption process at the directory level is exactly like the process for changing permissions at the directory level.To decrypt a file, use these steps: 1. Using Explorer, select the encrypted file that you want to now be stored as an unencrypted file. 2. Right-click to bring up the Context menu, and select Properties. 3. Click Advanced on the General tab. 4. In the Advanced Attributes dialog box, clear the check box to Encrypt contents to secure data. 5. Click OK. 6. On the General tab, click OK or Apply to mark the file as unencrypted.

Using the Cipher Utility Windows 2000 and XP allow users to use file encryption from the command prompt. This can be faster than using the graphical interface when a large number of files are to be encrypted.The command-line utility also provides added functionality (such as the ability to view at one time the encryption status of all files or subdirectories in a specified directory, the ability to force encryption on files that are already encrypted, and so on). The general format of the Cipher Utility is: >cipher

[ /e ]

[ /d ] [ /s [dir]] [ /a ] [ /i ] [ /f ] [ /q ] [filename]

When the cipher command is executed with no switches or filename, the result is a display of the encryption status of the current directory and any files in the directory. This is useful because users might not readily know which files have been encrypted because the process during access is transparent (another way to determine encryption status is to check the properties of each individual file, but that can be cumbersome). Table 9.3 identifies each switch of the cipher command.

www.syngress.com


551

Table 9.3 Cipher Command Switches Switch

Function

/e

Encrypts the specified files. The directory is marked for encryption, so any files or subdirectories created and placed here will be encrypted. Decrypts the specified files. The directory will be cleared of the encryption attribute so that files added here will not be encrypted. Performs the specified operation for files and directories. Performs the specified operation on the files in the specified directory and on all subdirectories. Continues to perform the cipher command, even if errors occur, thereby overriding the default behavior in which the cipher command stops if an error occurs. Forces encryption to occur on all specified files, even those that are already encrypted, thereby overriding the default behavior of not encrypting already encrypted files. Reports only the most essential information.

/d /a /s : /i

/f

/q

The word filename must be replaced with a filename or directory.The filename specification allows for wildcard usage, thus allowing multiple listings to be affected with a single command execution. Figure 9.8 shows a cipher command that was executed with no switches at the root level of the directory structure. Every existing directory is listed, and you can see whether the directory is marked for encryption.The E attribute indicates encryption, so, in this example, you can see that ProjectX is encrypted. U indicates that a directory is unencrypted. Figure 9.8 Executing the Cipher Command with No Switches

Figure 9.9 shows the result of executing the cipher command at the directory level.The directory is marked for encryption, and any new objects stored there will be encrypted. All files and subdirectories are shown, along with their current encryption status. As you might expect, all files in this directory are encrypted. However, a

www.syngress.com

552


directory could be marked for encryption that contains unencrypted files, as discussed in the next section. Figure 9.9 Executing the Cipher Command at the Directory Level

Encrypting a Directory As mentioned earlier in this chapter, the Encrypting File System allows encryption to be set at the directory and file levels.When a directory is selected for encryption, what really happens is that any new object placed in the directory—including files and subdirectories—is encrypted. Any current existing file and subdirectory will not be encrypted unless the owner manually sets the encryption bit on the existing object.The best practice is to create a directory, mark it for encryption, and then store all sensitive data in that directory when you work with the Encrypting File System. When you modify a directory’s attribute to include encryption, the directory itself is not technically encrypted; rather, the directory is marked for encryption.This encryption mark controls all the new objects becoming encrypted. You can also explicitly unencrypt a file in an encrypted directory by unchecking the encryption attribute in its properties or using the cipher command.

Employing Recovery Operations Earlier in the chapter, we mentioned the Encrypted Data Recovery Policy (EDRP). EDRP is part of the local security policy in a workgroup environment or part of the domain security policy for Windows domains.The Security Subsystem in user mode is responsible for enforcing this policy. Users can use file encryption offline, and the Security Subsystem is responsible for caching the Encrypting File System policy, much the way logon information is cached on the local machine. The recovery policy must first be set up by the system administrator.The operating system contains a Recovery Agent Wizard, in which recovery agents are assigned along with their corresponding key pairs.The Microsoft Base Cryptographic Provider is used to create a data recovery file for each recovery agent. The default domain recovery policy is configured so that the domain administrator account is the only recovery agent.We recommend that you change this, for two reasons:

www.syngress.com

Defending Your Data with the Encrypting File System • Chapter 9 ■

No one should be logging on with the Administrator account (it should be renamed and not in use)

■

You need more than one recovery agent for fault tolerance purposes.

553

The upcoming exercises demonstrate the process of adding recovery agents in Windows 2000. Exercise 9.1 walks you through the process of adding a recovery agent for an account that does not already have an EFS recovery certificate. Exercise 9.2 walks you through the process of adding a recovery agent for an account that has an EFS recovery certificate.

Exercise 9.1 Configuring a Recovery Agent without an EFS Certificate 1. Open Active Directory Users and Computers (select Start | Programs | Administrative Tools | Active Directory Users and Computers), as shown in Figure 9.10. Figure 9.10 Active Directory Users and Computers

2. Right-click your domain, and choose Properties.You will see the window shown in Figure 9.11.

www.syngress.com

554


Figure 9.11 The Group Policy Tab of a Domain’s Properties

3. Click the Group Policy tab. 4. Select Default Domain Policy, and click Edit.You will see the window shown in Figure 9.12. Figure 9.12 Encrypted Data Recovery Agents

www.syngress.com


555

5. Expand Computer Configuration. 6. Expand Windows Settings. 7. Expand Security Settings. 8. Expand Public Key Policies. 9. Right-click Encrypted Data Recovery Agents, and choose Create.This step starts the wizard shown in Figure 9.13. Figure 9.13 Welcome to the Certificate Request Wizard

10. Click Next to continue the wizard. 11. Figure 9.14 shows the Certificate Template window.This is where you select the type of certificate that you want. Select EFS Recovery Agent, and click Next.You will see the screen shown in Figure 9.15. Figure 9.14 The Certificate Template Window

www.syngress.com

556


Figure 9.15 The Description Window

12. Enter a name and description for the certificate, and click Next. 13. The Completing the Certificate Request Wizard window displays (see Figure 9.16). Click Finish to complete the request process and start installing the new certificate. Figure 9.16 Completing the Certificate Request Wizard

14. After requesting the certificate and completing the wizard, you will see the message box shown in Figure 9.17. Click View Certificate to look at the new certificate before you install it.

www.syngress.com


557

Figure 9.17 Viewing or Installing a Certificate

15. Figure 9.18 shows the certificate.Verify that it is for File Recovery. Once the user account has a recovery certificate, that user can be added as a recovery agent. Note that the certification authority must be configured to issue recovery agent certificates, and the user must have permission to request the certificate. Figure 9.18 Viewing an EFS Recovery Certificate

16. Click OK to return to the window shown earlier in Figure 9.17. 17. Click Install Certificate.You’ll see the message box shown in Figure 9.19, indicating that the certificate was installed successfully. Figure 9.19 The Certificate Request Successful Message Box

www.syngress.com

558


Exercise 9.2 Adding a Recovery Agent That Has an EFS Recovery Certificate 1. Open Active Directory Users and Computers (select Start | Programs | Administrative Tools | Active Directory Users and Computers), as shown earlier in Figure 9.10. 2. Right-click your domain, and choose Properties, as shown earlier in Figure 9.11. 3. Click the Group Policy tab. 4. Select Default Domain Policy, and click Edit to open the Group Policy Editor, as shown earlier in Figure 9.12. 5. Expand Computer Configuration. 6. Expand Windows Settings. 7. Expand Security Settings. 8. Expand Public Key Policies. 9. Right-click Encrypted Data Recovery Agents, and choose Add.The Add Recovery Agent Wizard shown in Figure 9.20 starts. Figure 9.20 Welcome to the Add Recovery Agent Wizard

10. Click Next to continue the wizard and open the Select Recovery Agents window shown in Figure 9.21.

www.syngress.com


559

Figure 9.21 The Select Recovery Agents Window

11. In the Select Recovery Agents window, click Browse Directory to search Active Directory for recovery agents (see Figure 9.22). Optionally, you could click Browse Folders to search for the certificate of your recovery agent. Figure 9.22 Finding Users to Be Recovery Agents

www.syngress.com

560


12. After choosing Browse Directory, you need to select the users you want to designate as recovery agents.Type the name of the user, and choose Find Now. Alternatively, you can click Find Now without typing a name to see all users, then select the user from the list and click OK to return to the Select Recovery Agents window shown in Figure 9.21. 13. Click Next to continue.You will see the Completing the Add Recovery Agent Wizard window shown in Figure 9.23. Figure 9.23 Completing the Add Recovery Agent Wizard

14. Click Finish to complete the wizard. The recommended steps in the recovery of an encrypted file that an owner cannot manipulate are performed by a recovery agent as follows: 1. Assuming that you are the person who will be doing the recovery—that is, you’re the recovery agent—use a backup utility to restore a copy of the user’s ciphertext file on the computer that has the recovery certificates. 2. Using Explorer, display the encrypted file’s properties. 3. On the General tab, click Advanced. 4. Clear the Encrypt contents to secure date check box, which will use your private key to decrypt the file.The decrypted file should now be backed up and restored to the user. Another method of recovery is to export the recovery agent’s recovery certificate to a disk and then import the disk’s contents onto the machine that has the encrypted file.

www.syngress.com


561

The Windows 2000 operating system also provides a command-line utility, named EfsRecvr, that can be used to recover an encrypted file. If you use the EfsRecvr utility, the same steps should be applied in order to back up the file and restore it on the computer that contains the recovery keys. The EfsRecvr command-line utility uses this general format: EFSRECVR

[ /S [:dir] ]

[ /I ] [ /Q ] [ filename […] ]

Table 9.4 summarizes each of the items in the EfsRecvr command line. Table 9.4 EfsRecvr Command-Line Syntax Item

Function

/S

Recovers the files in the given directory and all subdirectories. The default directory is the current directory. The recovery process will continue, even if an error occurs. The default behavior is to immediately stop the recovery process if an error occurs. Limits the reporting of only essential information needed to load the appropriate keys. Specifies a file, directory, or pattern.

/I /Q Filename

EFS Architecture The Encrypting File System components and the encryption process, along with the Encrypting File System file information and the decryption process, are involved in EFS file encryption. In the following sections, we examine each of the elements that make up the EFS architecture.

EFS Components In order to understand the entire encryption/decryption process, you need to look at the operating system architecture. Like its predecessor,Windows NT, the Windows 2000 OS structure contains both user mode and kernel mode.When Microsoft developed their data encryption process, the designers had to decide in which mode the encryption code should run.This presented some important considerations. For example, if data encryption were left in user mode, temporary files that were not encrypted would be created, which would defeat the security objective. On the other hand, applications still run in user mode, so when a user requests encryption using Explorer or the Cipher Utility, the activity must start here.The solution:When the Encrypting File System is implemented, some of the activity occurs in user mode and some in kernel mode.

www.syngress.com

562


In earlier versions of the Windows NT operating system, the Local Security Authority Subsystem (LSASS) was in user mode.With Windows 2000 and XP, this subsystem takes on additional tasks and includes some additional functions for the Local Security Authority Server in order for the Encrypted File System to work properly.The functions are grouped as EFS functions.The NTFS driver, which was first introduced in Windows NT 3.1, is in kernel mode. Because users can protect sensitive data only on an NTFS partition, this driver has an active role in the overall encryption process. Figure 9.24 shows both old and new components. Figure 9.24 EFS Components LSASS LSASRV User Mode

EFS Fuctions

Microsoft Cryptographic Provider 1.0

Application

Registered Encrypted File Access EFS Callouts Kernel Mode

KSecDD

EFS

NTFS

The key components of the Encrypting File System are: ■

EFS driver EFS is really a device driver that works in conjunction with the NTFS driver, both of which run in kernel mode.The EFS driver runs on top of NTFS in a layered manner.Whenever a user needs encryption or decryption, the EFS driver works with the cryptography services in Windows 2000 user mode.The EFS communicates with the KsecDD (security device driver) to request many of the required key management services.When the file system needs to complete an encryption task (which the NTFS driver itself is incapable of performing), the EFS driver takes on the responsibility.

■

EFS File System Runtime Library (FSRTL) This EFS driver module uses NTFS callouts for tasks such as reading, writing, and opening encrypted files and folders as well as encrypting and decrypting data when it is read from or written to disk. Messages are passed between the EFS driver and the EFS FSRTL via the NTFS file control callouts.

■

KsecDD This device driver takes the EFS request and “talks” with the Security Subsystem on behalf of the EFS driver.The KsecDD acts as a connection between the needed LPC calls and the Local Security Authority Subsystem in user mode.

www.syngress.com

Defending Your Data with the Encrypting File System • Chapter 9 ■

EFS Services These services are stored in the Local Security Authority Server, which is part of the LSASS. In user mode, the Encrypting File System Services interface with the Microsoft Base Cryptographic Provider 1.0 to provide FEKs and to generate the needed data decryption fields and data recovery fields.The Encrypting File System Service is used to obtain and enforce the encryption data recovery process and to locate the user’s key pair when it is needed.

■

Cryptographic Service Provider (CSP) The Cryptographic Service Provider (CSP) provides the key pairs (public and private key) for EFS users and recovery agents. By default, DESX is the encryption algorithm used by EFS.You can configure Windows XP Pro to use 3DES (a significantly stronger algorithm that provides 128 or 168 bit keys) instead.This is done through Group Policy. Microsoft’s base CSP is included with the operating system; Microsoft also provides an enhanced CSP that can be used for EFS encryption.

563

NOTE If you enable 3DES for EFS, all new encryption operations will use it for both EFS and IPSec encryption.

■

CryptoAPI This is the application programming interface that allows developers to add cryptography services to the Win32 applications that they write and is used by EFS for all its cryptographic services. Both symmetric and asymmetric cryptographic operations are supported, including key generation, management and exchange, encryption/decryption, hashing, digital signatures, and signature verification.

BEYOND ISA SERVER When the EFS driver initializes, it registers seven EFS Callback functions with the NTFS driver. These are the current Callback functions: ■

■

EfsOpenFile When an application opens an existing file that has EFS attributes, the NTFS driver invokes the EFS callback function EfsOpenFile. EfsFilePostCreate After an NTFS file has created or opened a file for an application, the NTFS driver needs the EfsFilePostCreate EFS Callback function’s help.

www.syngress.com

564

Chapter 9 • Defending Your Data with the Encrypting File System ■

■ ■

■

EfsFileControl and EfsFsControl When a user modifies a file’s encryption settings, the NTFS driver makes a request for the EFS Callback functions EfsFileControl and EfsFsControl. EfsRead When NTFS retrieves data for an application, it petitions EFS for the function named EfsRead. EfsWrite When the user writes information in an encrypted file, the NTFS driver invokes the EFS Callback function known as EfsWrite, because NTFS cannot encrypt the data itself. EfsFreeContext For the sake of security, which is what encrypting sensitive data is all about, the NTFS driver invokes the EFS Callback function EfsFreeContext when the context data buffer is no longer required.

The Encryption Process Before EFS encryption can be used in Windows, the EFS device driver must be installed.When the EFS driver initializes, it notifies the NTFS driver of its existence, and it also registers seven related functions at that time. In the registration of these functions, the EFS driver seems to be telling the NTFS driver, “Here is a list of tasks I can do for you.” (See the Note for the list of the EFS Callback functions.) When the NTFS driver receives a request for EFS, it looks into the table of EFS Callback functions and invokes the function that the EFS driver must execute.The EFS driver will not communicate directly with the LSASS, which runs in unprotected user mode.The EFS driver sends a request to encrypt or decrypt a file to the LSASS, but an additional driver intercepts this request in kernel mode.The driver used to send the actual LPC message to the Local Security Authority Subsystem, KsecDD, resides in kernel mode.The Local Security Authority Server, which is part of the LSASS, listens for the LPCs.When the LSASRV receives a call from the File Encryption Client DLL (FEClient) to encrypt a file, it invokes the internal function EfsRpcEncryptFileSrv. EfsRpcEncryptFileSrv handles the following tasks in the early stages of a file encryption request: 1. Impersonates the user making the encryption request. 2. Creates a log file that LSASRV uses to keep a record of the encryption process from start to finish. 3. Loads the impersonated user’s profile into the Registry. 4. Makes a call to the internal function EncryptFileSrv. You might be wondering about the first step—impersonating a user. Impersonation occurs for a reason.The LSASS has always used the System account by default. If this www.syngress.com


565

account were used for the encryption process, the System’s private key would be needed to decrypt the file.The Encrypting File System’s objective is to encrypt the file and then require a unique private key belonging to the user for any future usage. By impersonating the user, the proper private key is used to manipulate the file. The log file that is created when an encrypt file request is received is used to record the events in the encrypting process.The log file is on the same drive as the encrypted file in the System Volume Information subdirectory.The name of the log file is EFS0.log. If an EFS0.log file already exists, the name of the new log file is generated by incrementing the numeric value by one digit. This need exists despite the fact that a user’s profile has already been loaded into the Registry because logging on the system is mandatory. In most circumstances, the profile would already be loaded, but software engineers cannot leave anything to chance, especially when dealing with security issues. If the user executed the Run As command included in the Windows 2000 and XP/.NET operating systems, which allows a logged-on user to use a different account (such as an administrator’s account) to perform tasks, the loaded profile would be the result of logging on the system, not the profile of the user making the encryption request. When control is passed to the EncryptFileSrv function, an entirely new list of tasks must be performed. EncryptFileSrv is in user mode, and the EncryptFileSrv function takes on the remaining tasks in the encryption process. Specifically, the EncryptFileSrv function is responsible for the following tasks: 1. Queries the NTFS driver about the data stream being used in the file. 2. Calls the GenerateFEK function. 3. Constructs the EFS information that is stored with the encrypted file. 4. Creates a backup file. 5. Initializes the log file. 6. Sends an encrypted command to the NTFS driver to encrypt the file. In order for the EncryptFileSrv function to generate the FEK, a function called GenerateFek is used. GenerateFek initiates a session with the Microsoft Base Cryptographic Provider and requests to use the RSA encryption algorithm.When GenerateFek has established the session, it calls another function to have the provider generate the FEK. After the FEK is created, the session with the Microsoft Base Cryptographic Provider is closed, and control is returned to the internal EncryptFileSrv function. EncryptFileSrv uses the FEK and the user’s key pair to create the EFS file information. At this point in the encryption process, a key pair is created if the user does not

www.syngress.com

566


have one.The system can easily identify a user’s lack of a key pair by the absence of the CertificateHash value found in the Registry for the current user. After the EFS file information is built, a backup file named EFS0.tmp is created for the original plaintext file.The security descriptor for this backup file is set up so that only the system account will have access to the file. EncryptFileSrv now sends an encrypted control command to the NTFS driver to add the recently constructed EFS file information to the original file.The NTFS driver understands an encrypted command in this way: At boot time, the Encrypting File System receives from the LSASS a session key that is used to decrypt any control command received from user mode.When the NTFS driver receives the encrypted control command, the driver makes a request to the EFS Callback function, EfsFileControl.The EFS driver applies the session key to decrypt the control command and adds the EFS file information to the original file.The EFS driver also creates the $EFS NTFS metadata attribute.This attribute was added to the Windows 2000 operating system, and it contains the EFS file information. After the EFS file information is added to the file, the activity is once again handed back to the EncryptFileSrv internal function, and then EncryptFileSrv performs these tasks: 1. Records in the log file that the backup file was created. 2. Sends another encrypted control command to the NTFS driver to encrypt the file at this time. When the NTFS receives the encrypted control command, it makes a request to the EFS Callback function, EfsWrite. EfsWrite uses the unencrypted FEK to do secret key encryption of the file one sector at a time.The data is encrypted before the NTFS driver writes the data to disk. In the United States, the Encrypting File System uses a 56-bit standard DESX encryption key. When the file is completely written to disk in ciphertext form, EncryptFileSrv is handed control once again.The EncryptFileSrv function completes the encryption process by doing these tasks: 1. Records in the log file that the encryption process was successfully completed without errors. 2. Deletes the backup copy of the original file. 3. Deletes the log file. 4. Passes control back to the user. These concluding tasks draw together the built-in fault-tolerant side of the encryption process. A backup copy of the original file is always available until the encryption www.syngress.com


567

process is completed successfully. If a system crash or other fatal error occurs, the log file indicates where the encryption process stopped, and the original copy of the file can be used to redo the entire process.

The EFS File Information After the FEK has been created, the EFS file information can be constructed.The LSASRV function named EncryptFileSrv has the control of the creation of the EFS file information that is stored with the file.The user’s key pair is needed to supply the necessary information in the encrypted file’s header.The function CryptoAPI is called to get a handle to the needed key pair. If the user does not have a key pair, and if this is the first file to be encrypted, a key pair must be created.The function GenerateUserKey is used to create the key pair and returns the signed certificate for the pair.The generation of the key pair will happen on a domain controller or on the local machine as determined by the computer’s environment.When the signed certificate is received, it is stored in the Registry in the subkey HKEY_CURRENT_USER\Software\Microsoft\ WindowsNT\CurrentVersion\EFS\CurrentKeys\CertificateHash. Now that EncryptFileSrv has the user’s key pair, a function is used to obtain information about the provider that was used to generate the key pair.The user information that is needed at this point is the provider’s name and the container used to store the key pair, which in fact is nothing more than a file specification. An example of a container is as follows: D:\Documents and Settings\Administrator\Application Data\Microsoft\ SystemCertificates\My\Certificates\1612DAFAD20E037F2DBACD4113FC7 55BC23B6711

EFS now uses the function CryptAcquireContext to set up a cryptographic session with the provider, using the provider’s name, the container’s name, and the fact that it desires to use the RSA encryption service of the Windows operating system.The provider’s name must be identified at this point because the operating system allows software vendors to write their own providers and implement them if they want to. RSA is the public key encryption algorithm that was written by Rivest, Shamir, and Adleman. The provider creates 128 bits of random data that will become the file’s FEK, and then a function is called to close the session with the Microsoft Base Cryptographic Provider. Now that EncryptFileSrv has a FEK, the EFS file information can be constructed and stored with the file.The function GetCurrentKey is used to read the Registry information and get a handle to the user’s public key. A Local Security Authority Server function uses the public key to store the EFS information with the file. Figure 9.25 identifies the components that make up the EFS file information.

www.syngress.com

568


Figure 9.25 EFS File Information EFS Information Header

Data Decryption Field (DDF)

Version Checksum DDF Key Entries DDF Key Entry 1 DDF Key Entry 2 DDF Key Entry #

Data Recovery Field (DRF)

DRF Key Fields DRF Key Entry 1

KEY ENTRY User SID Container Name Provider Name EFS Certificate Hash Encrypted FEK

KEY ENTRY User SID Container Name Provider Name EFS Certificate Hash Encrypted FEK

The data decryption field (DDF) contains entries for each user who has access to the encrypted file. Each individual entry is referred to as a DDF key entry.The components of the DDF key entry provide information to represent a user’s public key.The user’s SID is a component of the key entry. Also included in the key entry is the provider name and container name, the public/private key pair certificate hash, and the encrypted FEK. Any collection of multiple key entries in the EFS file information is called a key ring. The EFS file information component of the Encrypting File System is not yet completed. An entry needs to be created that will provide recovery if the user’s private key somehow becomes corrupted.The EFS creates another key ring that contains recovery key entries. All information tied to the recovery process is in the file’s data recovery field (DRF).The information in the DRF entries uses the same format as the DDF entries.The number of entries created here is determined by the recovery agents previously defined using the Recovery Agent Wizard.That means that the Local Security Authority Server will have to read the recovery policy at boot time or when it receives notification of policy changes so that the correct DRF entries can be created. The EFS will use the same provider (typically the Microsoft Base Cryptographic Provider 1.0) to create a DRF entry key for each recovery agent. The EFS adds recovery agent entries to the DRF section of the EFS file information for each recovery key pair on the system.The system administrator can create any number of recovery agents by assigning their accounts access to an EFS recovery key pair.The number of recovery agents should be kept to a minimum for security reasons. www.syngress.com


569

The final step in building all this EFS information is to calculate a checksum value for the DDF and DRF. EFS stores the checksum value with the other header information.This checksum is tied to the decryption process. In order to guarantee that the EFS file information has not been changed, the checksum is used for verification during the decryption process. The information that is saved with the encrypted file as the EFS file information must be always current; otherwise, users who are issued new certificates will be unable to access their protected, encrypted files.To compensate for this, when the key field that can successfully decrypt the FEK is located, a function is used to compare the SID, provider name, container name, and certificate hash value to the properties of the user’s current EFS cryptographic key pair. If any of the information in the key field does not match the current Registry values, the key field is updated in the EFS file information. If the key field needs to be updated, a new key field is created containing the new matching information, and then the old key field is deleted.

The Decryption Process When a user accesses an encrypted file, the decryption process begins. Once again, this lengthy process is transparent to the user.The following discussion is highly technical and discusses what goes on “under the hood” when a file or folder is decrypted. From the user’s point of view, if he or she has authority to access the encrypted file, the file is automatically decrypted and displayed as plaintext when the user opens it (if an unauthorized user attempts to open it, there will be an “Access denied” message). As is the case when any file on an NTFS volume is accessed, the NTFS driver looks at the file’s attributes. If the file is indeed encrypted, the NTFS driver invokes the EFS Callback function, EfsOpenFile, which the Encrypting File System registered at the time it initialized.The task of reading the EFS attribute is now handed over to the EFS driver.The EFS Callback function, EfsOpenFile, then performs the following tasks: 1. Opens the Encrypting File System attribute. 2. Calls the NTFS function NtOfsQueryLength to determine the attribute’s length. 3. Allocates the appropriate amount of buffer space based on the length. 4. Copies the EFS attribute to the buffer. If the Encrypting File System attribute fails to open for any reason, the user receives an error message. If the Encrypting File System attribute successfully opens, the NTFS driver again invokes a registered EFS Callback function, this time named EfsFilePostCreate.

www.syngress.com

570


If all has gone smoothly, EfsFilePostCreate’s job is to make sure that the user requesting to open the file has access to the file’s encrypted data. In order for the user to have access to an encrypted file’s data, the user needs a private key to decrypt the FEK, which in turn is used to decrypt the file itself. The actual decryption of the FEK is handled by the Local Security Authority Server, which resides in user mode.To perform the FEK decryption, the EfsFilePostCreate sends an LPC message to the LSASRV by way of KsecDD.The Microsoft Base Cryptographic Provider is used to encrypt and decrypt.This cryptographic provider functions in user mode and is attached to the Local Security Authority Subsystem. Much as is the case with the encryption process, impersonation must occur in the Local Security Authority Subsystem process when the user opens the file, because the LSASS executes using the System account.This impersonation must be set up before the KsecDD sends the local procedure call (LPC) message to LSASRV and is handled by the EfsFilePostCreate EFS Callback function. When the LSASRV receives the LPC message from KsecDD, a function call is used to load the user’s profile into the Registry if it is not already there. A second function call named DecryptFek is called to perform the actual file decryption. This DecryptFek has some additional tasks to complete before it actually decrypts the file.The DecryptFek must use the Encrypting File System certificate hash, stored as a component of the key entry, to identify the private key to be used. DecryptFek uses the user’s private key to try to decrypt the ciphered FEK in each key entry in both the DDF and the DRF of the EFS file information. When every DDF and DRF entry has been tried with the result that the entry’s FEK cannot be decrypted, the user is denied access to the file, but if a private key can decrypt the FEK, a cryptographic session with the Microsoft Base Cryptographic Provider is established. Similarly to the encryption process, in establishing a session with the Microsoft Base Cryptographic Provider, the container name and the provider name must be known, but this time the information is indicated by the key fields of the EFS file information. After the session with the provider is created, the FEK decryption is completed via the user’s private key. As an added security step, the hashing of the EFS attribute and the decrypted FEK take place and are compared with the checksum value located in the header information. Any different values seen here indicate that the file has been compromised in some way, and an error results. If the file isn’t compromised in any way,Windows establishes another session with the Microsoft Base Cryptographic Provider.This session uses the plaintext FEK and the RSA algorithm to completely decrypt the file.

www.syngress.com


571

Summary In Windows 2000, Microsoft provided users with the ability to encrypt files that contain sensitive information via a feature called the Encrypting File System. In Windows XP/.NET, improvements were made to EFS that added functionality.With EFS, encryption can be set both at the directory level and the file level.This new security feature is efficient in that the encryption/decryption process is totally transparent to users after the files are marked for encryption. Basic file encryption is accomplished using two methods—secrete key and public key. Secret key encryption uses the same key for encrypting and decrypting data (and thus is considered less secure than public key encryption).The secret key algorithm is relatively fast and therefore is appropriate for encrypting large amounts of data. Public key cryptography uses a key pair.The public key is used to encrypt a file, and the private key is used to decrypt the file.This method of encryption provides more security, because only a private key (which is never shared with anyone) can unscramble the ciphertext into plaintext. Slower performance is the price you pay for this higher level of security. Because the process is slow, public key cryptography should only be used on small amounts of data. Windows’s EFS uses both methods of encryption. A file is encrypted using a secret key called the FEK, with the DESX (or in Windows XP, 3DES) algorithm.To further protect the FEK from unauthorized access, the FEK is then encrypted by the owner’s public key. When it comes to the user actually working with sensitive data, no additional configuration steps are needed.When a file or directory is marked for encryption, the whole encrypting/decrypting process is transparent to users. A user can identify for the Windows operating system the files that are to be encrypted through either the Windows Explorer interface or a command-line utility called the Cipher Utility. File encryption does not modify the normal file operations of renaming or moving. When you move an encrypted file on the same partition, the pointer in the directory is changed, but nothing in the encryption fields is modified. A rename operation on an encrypted file changes only the filename, once again modifying no field tied to the encryption process. Encrypted files can be copied or moved only by those with authorization to access the files. The new Cipher Utility allows users to encrypt and decrypt files or directories at the command prompt.The included switches for this utility allow users to indicate whether a requested operation should be performed on all files and subdirectories and whether the operation should continue in the event an error has occurred and to force encryption of already encrypted files.

www.syngress.com

572


The EfsRecvr Utility can be used to recover an encrypted file if the owner’s private key is corrupted or lost.The EfsRecvr utility has switches that are similar to the Cipher Utility in that the recovery agent can indicate how much of the directory structure is to be recovered and whether the process should continue, even if an error occurs. The Encrypting File System follows the Windows NT/2000/XP/.NET operating system architectural model. Some of the encryption activity is handled in protected mode, known as kernel mode, whereas other tasks are performed in user mode. Windows 2000 added in kernel mode the Encrypting File System driver, which, at initialization time, registers seven EFS Callout functions with the NTFS driver.When the NTFS driver needs to do any Encrypting File System operation, the NTFS makes a call to one of the appropriate Callout functions.The other component employed in kernel mode is known as the KsecDD driver.The role of the KsecDD driver in the encryption process is to send the LPC messages from the Encrypting File System driver to the Local Security Authority Subsystem. Windows 2000 also added to the Local Security Authority Subsystem, which runs in user mode, a series of internal functions for encryption/decryption operations. In the encryption process, the internal function EncryptFileSrv plays a major role. Also located in user mode is a cryptographic provider, the Microsoft Base Cryptographic Provider. One major responsibility of this cryptographic provider is to provide the RSA encryption operation after a session has been established. The EFS file information is created by the EncryptFileSrv function call.The information includes a checksum, the data decryption field (DDF), and the data recovery field (DRF).The checksum is used at decryption time to verify the integrity of the EFS File Information.The DDF is a list of owner key entries, and the DRF is a list of recovery agents’ key entries.This EFS file information is used with every occurrence of decryption. The addition of file encryption to Windows provides added security for sensitive data stored on the hard disk and makes it unnecessary for users to seek out third-party solutions when they need to ensure the highest level of protection for their data.

Defensive Tactics Fast Track The Role of EFS in a Network Security Plan ; A good network security plan is multilayered and includes perimeter control,

internal security, and object-specific security. ; File encryption—such as that afforded by EFS—provides security for specific,

valuable/sensitive objects (files or folders). www.syngress.com


573

; An important part of security planning is determining which assets most need

protection.You should assess your data to determine which files and folders should be encrypted.

Using the Encrypting File System ; The Encrypting File System uses both public key encryption and secret key

encryption. ; An encrypted file can be read by anyone with a private key that can decrypt

the File Encryption Key (FEK) used to encrypt the file. ; The default recovery agent in a workgroup environment is the local

administrator.The default recovery agent in a domain environment is the domain administrator.

User Operations ; The user operations that use file encryption are encrypting a file, accessing an

encrypted file, copying an encrypted file, moving an encrypted file, renaming an encrypted file, decrypting a file, encrypting a directory, and recovery operations. ; The only requirement for the Encrypting File System is an NTFS partition.

Accessing an encrypted file requires no special action by the user. ; Renaming an encrypted file changes the file’s name but does not change the

encryption attribute. ; When an encrypted file is moved on the same NTFS partition, it retains its

encrypted status.When an encrypted file is moved to a different NTFS partition, the file is first decrypted and then encrypted. ; Windows 2000 allows users to use file encryption from the command prompt

using the Cipher Utility. ; EFS allows encryption to be set at directory and file levels.

EFS Architecture ; Windows 2000 and XP contain both a user mode and a kernel mode. EFS

activity occurs in each of these modes.

www.syngress.com

574


; In Windows 2000 and XP, the Local Security Authority Subsystem performs

additional functions in order for the Encrypted File System to work properly. The functions are grouped as EFS functions. ; The new EFS components include the EFS driver, EFS Callouts, KsecDD,

EFS Services, and the cryptographic provider.


Q: Do encrypted files have be stored on the local hard drive, which would result in users having to be responsible for backing up their hard drives daily?

A: The Encrypting File System is not limited in design to storage only on the local hard drive.The encrypted file can be stored on any file server located on the network.The EFS is responsible for file encryption and is not assigned the additional task of securing packets on the network.The functionality of packet security on the network is part of Secure Sockets Layer (SSL).You might need to configure a remote server to be trusted for delegation.

Q: Our corporation is an international company. Can I use the 128-bit encryption at some locations and not at others without having encryption problems?

A: By default, EFS provides standard 56-bit encryption to its U.S. customers. For security reasons, they can obtain the 128-bit encryption by ordering the Enhanced CryptoPAK from Microsoft.The files encrypted with the Enhanced CryptoPAK cannot be decrypted, accessed, or recovered on a system that supports 56-bit encryption only.

Q: How would you summarize the basic steps that occur in Windows 2000 or XP when a file is encrypted?

A: The basic steps are: 1. When a user executes an encryption request, the NTFS driver makes a request to the appropriate EFS Callout function. 2. The requester’s user profile is loaded into the Registry if it is not already there.

www.syngress.com


575

3. A log file is created that records events as they occur during the encryption process. 4. The EFS identifies the user’s key pair and then uses the public key to create an entry for the user in the data decryption field. 5. Entries are created in the data recovery field for each recovery agent. 6. A backup file is created and used to guarantee a fault-tolerant Encrypting File System. 7. All entries in the DDF and DRF are added to the file’s header. 8. Encryption of the file occurs. 9. The log file and the backup file are deleted at the end of the encryption process. 10. The requester’s profile is unloaded from the Registry if needed.

Q: How much training is needed for users of sensitive data that requires encryption? A: The Windows Encrypting File System is transparent to users after a file or directory is marked for encryption. Setting the encryption attribute through the graphical interface is a simple matter of checking or unchecking a check box. Minimum training might be needed to introduce the Windows Explorer interface and the new switches for the copy command and to introduce the Cipher Utility.

Q: What happens to data if a system should crash during the encryption process? A: The Encrypting File System is designed to be fault-tolerant.Throughout the entire encryption process, a log file keeps track of certain operations as they are completed. If a system crashes before a file is completely encrypted, the Local Security Authority Server looks for log files at boot time. If the LSASRV locates any Encryption log file, the contents are read. Usually, the LSASRV copies the backup file over the original semi-encrypted file and then deletes the backup and log files. If the LSASRV finds that the original file has not been modified, it deletes the backup and log files.

Q: When does encryption actually occur when reading or writing to an encrypted file? A: The NTFS driver calls the EFS Callback function, EfsRead, when an encrypted file needs to be read.The data is decrypted as the NTFS driver reads it from the hard drive and before it is placed in the file system cache.When an application writes to an encrypted file, the data in the file system cache is in plaintext.When the

www.syngress.com

576


application or the Cache Manager flushes the data to disk, the NTFS driver calls the EFS Callback function, EfsWrite, to encrypt the data.

Q: Can I use compression and encryption at the same time on a file? A: No. Compression and encryption are incompatible.The Windows graphical interface clearly shows that compression and encryption cannot both be enabled at the same time on a file.The interface has check boxes for the compression and encryption attributes. Selecting one check box deselects the other check box.

Q: Can I store an encrypted file in an unencrypted directory? A: A user who is trying to mark a file for encryption in a directory that is not marked for encryption receives a message stating,“You have chosen to encrypt a file that is not in an encrypted directory.The file can become decrypted when it is modified. Because files saved in encrypted directories are encrypted by default it is recommended that you encrypt the file and the parent folder.”The user can then choose whether to encrypt the file and parent folder or to encrypt the file only.

www.syngress.com

Chapter 10

Protecting Data in Transit with IP Security


Network Encroachment Methodologies

■

IPSec Architecture

■

Deploying Windows IP Security


577

578

Chapter 10 • Protecting Data in Transit with IP Security

Introduction In the previous chapter, we discuss how encryption (in the form of EFS) can be used to protect data stored on disk. Equally important to today’s network administrator is the protection of sensitive data as it travels across a network. In the early days of networking, local area networks (LANs) were lone entities.These isolated networks typically ran NetBEUI in small workgroups of fewer than 200 computers and were not connected to any other networks.The major security concerns in an isolated environment typically revolved around employees located at the site.You could focus your security efforts on local access controls, such as locking down disk drives on employee workstations and checking briefcases and handbags for printed materials. Especially sensitive data could be encrypted on the disk. Today’s networks are very different from the isolated NetBEUI networks of yesteryear. Most likely, your network is connected to other networks, including the global Internet, via dedicated leased lines or your organizational remote access server. Some workstations on your LAN might even have their own link to the outside via a modem and phone line. Each of these points of access represents an ever-increasing security risk. In the “olden” days, electronic documents had to be copied to a disk or printed in order to leave the company’s premises; now, transporting data is as easy as sending an e-mail attachment over the Internet.Your organization’s prized database can easily be posted to an electronic newsgroup. Hackers can penetrate the network and gain usernames and passwords that allow them to bypass normal access controls. Innocent experimentation by fledging systems engineers and power users can corrupt or destroy data just as effectively as the actions of the most malignant hackers. Effective network security standards are the sum total of a well-planned and carefully implemented security infrastructure.These measures include hardware security, file and folder access controls, strong passwords, smart cards, social security, physical sequestration of servers, file encryption, and protection of data as it moves across the wire within the organizational intranet and as it moves outside the organization. This chapter focuses on protecting the integrity and confidentiality of information while it is in transit across a network. First, we look at some of the common security risks incurred as data moves across the wires. Next, we discuss the basics of cryptography and how these basic tasks function within the framework of Microsoft’s implementation of the industry-standard Internet Protocol Security (IPSec). Finally, we cover the specifics of implementing IPSec in your network.

www.syngress.com

Protecting Data in Transit with IP Security • Chapter 10

579

Network Encroachment Methodologies Today, the vast majority of networks are connected to the Internet, allowing users to take advantage of fast and efficient world-wide e-mail communication, newsgroups, file transfer, and the tremendous research capabilities offered by the Web. Unfortunately, this connectivity makes the network vulnerable to all the “bad guys” lurking out there, looking to break into systems for fun or profit.Who they are and why they do it is beyond the scope of this book (for a detailed discussion of the psychology behind those who commit such acts, see Chapter 3 of Scene of the Cybercrime: Computer Forensics Handbook by Debra Littlejohn Shinder, published by Syngress Publishing). In this chapter, we confine our discussion to what the “bad guys” do and how you can defend your network against them. Hackers, crackers, and network attackers (including “script kiddies” who have little technical expertise) can use a number of methods to circumvent your network security and gain access to information, including: ■

Snooping

■

Spoofing

■

Password compromise

■

Denial-of-Service attack

■

Man-in-the-middle attack

■

Application-directed attack

■

Compromised key attack

Snooping Most data sent over a network is transmitted in clear text. An individual with a network sniffer—such as the Network Monitor program that comes with Systems Management Server or a third-party program, such as Sniffer Pro—can easily read clear text messages as they traverse a network. This can even be true of sensitive data, such as user account passwords. Some server applications that maintain their own username and password lists allow for this type of critical logon information to cross the network in clear text format.The network snooper, using easily accessible sniffing programs, can plug into an available port in a hub or switch and easily access the information.Then the person using the snooping program can use the stolen credentials to access the network at anytime, posing as an authorized user. Other information that could be intercepted might include credit card numbers, Social Security numbers, contents of personal e-mail messages, and proprietary organizational secrets. www.syngress.com

580


Spoofing The source and destination IP addresses are prerequisites for establishing sessions between computers on a Transmission Control Protocol/Internet Protocol (TCP/IP) based network.The act of IP spoofing involves assuming the identity of a legitimate trusted host computer on a network in order to gain access to computers on the internal network.This is done by forging one’s source IP address. Another term for spoofing is impersonation, because the intruder impersonates a computer with a legitimate IP address. A common spoofing-based attack is the TCP/IP sequence number attack. Further, some software tools are available that allow people without technical skills to easily spoof addresses.

The TCP/IP Sequence Number Attack TCP is responsible for reliability of communications on a TCP/IP-based network.This responsibility includes acknowledgment of information sent to a destination host. In order to track bytes sent over a network, each segment is given a sequence number. A sophisticated attacker can establish the sequencing pattern between two computers because the sequence pattern is not random. First, the attacker must gain access to the network.Then, he or she must connect to a server and analyze the sequence pattern between the server and a legitimate host with which it is communicating at the time.The TCP/IP sequence number attacker then attempts to connect to the server by spoofing (falsely assuming) a legitimate host’s IP address. In order to prevent the legitimate host from responding, the spoofer starts a Denial-of-Service attack on the legitimate host. Because the legitimate host cannot respond, the spoofer waits for the server to send its reply and then responds with the correct sequence number.The server then believes that the spoofing computer is the legitimate host, and the spoofer can begin data transfer.

Spoofing Tools Hackers are all too willing to share their knowledge with others. Many hackers will not only teach hacker “wannabes” how to perform various attacks, but they will even create software tools to perform these tasks so that people with little or no technical expertise can use the same techniques.Those who run these scripts instead of performing the steps manually themselves are known as “script kiddies.” IP spoofing utilities are commonly found on hacker sites. Additionally, many distributed attack tools (those used to launch distributed Denial-of-Service attacks) use source IP address spoofing to hide the origin of an attack.Tools such as Mendax (for Linux), Spoofit, and detailed spoofing guides can be downloaded from the Web or exchanged in hacker newsgroups. Some of these are marketed as legitimate systems

www.syngress.com


581

administration tools designed to test a network’s vulnerability to spoofing, but they can also be used for nefarious purposes.

Password Compromise Users who gain illegitimate access to network passwords can access resources they would not otherwise be able to use. An attacker can gain knowledge of passwords in a number of ways, including: ■

Social engineering The attacker contacts an individual who has access rights to the information of interest. Often using an assumed identity, the attacker makes a request for a password from the individual, using a persuasive story and/or a charming personality to con the victim into revealing the password. Many infamous hackers, such as Kevin Mitnick, have used social engineering to aid in their hacking efforts.

■

Sniffing Many network applications allow a username and password to cross a network in clear text.The attacker can use a network sniffer application (also called a network monitor or protocol analyzer) to intercept the information and look at the data inside the packet.

■

Cracking A cracker uses a number of techniques to gain illegal access to passwords. Examples of cracking techniques include dictionary attacks and brute force attacks. Crackers also rely on the tendency of many users to select easily guessed passwords, such as Social Security numbers, a spouse’s name, or other information that can be obtained through a little investigative research.

Designing & Planning… The Importance of Password Policies A good password policy is the first line of defense in protecting a network from intruders. Careless password practices (choosing common passwords, such as “god” or “love” or a user’s spouse’s name; choosing short, all-alpha, one-case passwords; writing passwords down; or sending passwords across the network in plaintext) are like leaving your car doors unlocked with the key in the ignition. Although some intruders might be targeting a specific system, many others are just “browsing” for a network that’s easy to break into. Lack of a good password policy is an open invitation. Best practices for password creation require that you address the following: Continued

www.syngress.com

582


■

Password length and complexity

■

Who creates the password

■

Forced changing of passwords

A few rules of thumb for creating good password policies include: ■

Passwords should have a minimum of eight characters.

■

Passwords should not be “dictionary” words.

■

Passwords should consist of a mixture of alpha, numeric, and symbol characters.

■

Passwords should be created by their users.

■

Passwords should be easy for users to remember.

■

Passwords should never be written down.

■

Passwords should be changed on a regular basis.

■

Passwords should be changed anytime compromise is suspected.

■

Password change policies should prevent users from making only slight changes when creating new passwords.

In a high security environment, you might need to go beyond the use of just passwords (something you probably already know) in authenticating users to access the network. A multifaceted authentication scheme also requires that users provide something they have (such as smart cards or tokens) and/or something they are, that is, biometric identifiers, such a fingerprints or retinal scans.

If an administrator’s password is compromised, the attacker then has access to all network resources that are protected with access controls.The intruder then has access to the entire user account database and can use this information to access all files and folders, change routing information, and alter information without the knowledge of users who depend on the information.

Denial-of-Service Attacks A common type of network attack is the Denial-of-Service attack. Rather than actually breaking into a network to access its data, this type of attacker attempts to overload a network or server to cause a shutdown, thereby denying network services to legitimate users. A Denial-of-Service can be created in a number of ways. All DoS attack techniques have in common the ability to disrupt normal computer or operating system functioning on a targeted machine.These attacks can flood a network with useless

www.syngress.com


583

packets, corrupt or exhaust memory resources, or exploit a weakness in a network application. Denial-of-Service attacks include: ■

TCP SYN attack

■

SMURF attack

■

Teardrop attack

■

Ping-of-Death

TCP SYN Attacks When computers on a TCP/IP-based network establish a session, they go through a three-way handshake process as follows: 1. The originating client sends a packet with the SYN flag set to On.This host includes a sequence number in the packet.The server uses this sequence number in the next step. 2. The server returns a packet to the originating host with its SYN flag set to On.This packet has a sequence number that is incremented by 1 over the number that was sent by the requesting computer. 3. The client responds to the request with a packet that acknowledges the server’s sequence number by incrementing the sequence number by 1. Whenever a host requests a session with a server, the pair goes through the threeway handshake process.The attacker can take advantage of this process by initiating multiple session requests that originate from bogus-source IP addresses.The server keeps each open request in a queue while it waits for Step 3 to occur. Entries into the queue are typically emptied every 60 seconds. If the attacker is able to keep the queue filled, legitimate connection requests will be denied, so service is denied to legitimate users of e-mail,Web, FTP, and other IP-related services.

SMURF Attacks A SMURF attack attempts to disable a network by flooding it with Internet Control Message Protocol (ICMP) echo requests and echo replies. In a SMURF attack, the attacker spoofs a source IP address and then issues an ICMP echo request to a broadcast address.This action causes all the machines on a segment to reply to the bogus request. If the attacker can maintain this attack for an extended period of time, no useful information can be passed though the network due to the flood of ICMP echo request and reply messages traversing the wire.

www.syngress.com

584


Teardrop Attacks A teardrop attack is executed using a program—such as teardrop.c—that causes fragmentation similar to that seen in a Ping-of-Death attack (which is described next). A teardrop attack takes advantage of a weakness in the reassembly process and can cause a system to hang or crash.

Ping-of-Death The Ping-of-Death exploits features of the ICMP and the mean transfer unit (MTU) sizes of various network architectures.The PING command issues an ICMP echo request and is returned an ICMP echo reply by the destination host.The ICMP echo request message is encapsulated in an IP packet that is limited by 65,535 octets.The MTU defines the maximum size of a unit for a defined network architecture, which varies with the media type. If the size of a packet is larger than the MTU, the packet is fragmented and then reassembled at the destination. It is possible to send a packet with more than the legal number of octets.When packets are fragmented, an offset value is included with the packet.This offset value is used to reassemble fragments at their destination.The attacker could include with the last fragment a legal offset and a larger packet size.This will exceed the legal number of octets in the data portion of the ICMP echo request. When reassembly is attempted, the destination computer could respond by rebooting or crashing.

Man-in-the-Middle Attacks A man-in-the-middle attack occurs when two parties believe that they are communicating only with each other, but in fact there is an intermediary silently listening in on the conversation.The man in the middle can intercede in the conversation by impersonating the identity of either the sender or the receiver. During the attacker’s intercession, he or she can alter or destroy messages during transit. By using a network sniffer, an attacker can record and save messages for later use, allowing the attacker to issue a subsequent replay attack.The man in the middle, having recorded aspects of a conversation, can replay this information in order to get around network authentication mechanisms in the future.This is known as a replay attack.

Application-Directed Attacks Application-directed attacks seek to take advantage of weaknesses inherent in certain network applications. By exploiting weaknesses in network applications, an intruder can: ■

Corrupt or alter important operating system files

■

Change the content of data files

www.syngress.com

Protecting Data in Transit with IP Security • Chapter 10 ■

Cause a network application or an entire operating system to operate abnormally or even crash

■

Disrupt normal security and access controls maintained by the application or operating system

■

Plant a program or programs that can return information to the attacker; Back Orifice is an example of such an application

585

Numerous types of application-directed attacks exist.Web servers are often the targets of such attacks. One example is the Code Red worm that caused considerable damage to numerous systems a few years ago.This worm exploits vulnerabilities in the Internet Information Services (IIS) running on Windows NT 4 and Windows 2000 systems. It can deface Web sites running on your server. It can also install Denial-of-Service tools. After affecting a system, the worm attempts to propagate itself to other unprotected IIS servers. Variants of the Code Red worm have been created as well, each with its own symptoms. Microsoft creates security patches to protect against known application vulnerabilities such as Code Red. Always check the site http://microsoft.com/security for information about the latest attacks and their patches. These application-level attacks provide the most fertile ground for would-be intruders. Many network applications have not completed the degree of security assessment and testing that is required to optimize their immunity to attacks aimed against them.

Compromised Key Attacks A key is a number, or cipher, that can be used in combination with an encryption algorithm to either verify the integrity of a communication or encrypt the contents of a communication.Various types of keys are available. One type is known as a secret key. A sending computer encrypts the contents of a message using a secret key, and the receiving computer decrypts the message with the same secret key. Using this shared secret, two computers can communicate in private. Another type of secret key is the private key.The secret private key can be used to confirm a sender’s identity.This process is known as signing a message. A recipient who receives a message signed by someone’s private key can be confident that the person who claims to have sent the message is indeed that person.The private key is part of a key pair, two mathematically related keys.The other part of the pair is a public key. The private key is kept secret, and the public key is published to the world. If the public key belonging to a certain person can be used to decrypt his or her messages, that affords assurance that the message was encrypted with the related private key, which is known only to the person. As discussed in Chapter 9, key pairs can also be used in the opposite way: A message can be encrypted by a sender using the recipient’s public key, and only www.syngress.com

586


the person who holds the associated private key can decrypt the message, providing confidentiality for the data. An attacker who somehow gains access to secret or private keys can decrypt messages intended for someone else or communicate with an assumed identity using someone else’s private key.When secret or private keys no longer remain secret and private, they are said to be compromised. After keys are compromised they can no longer be used to secure identities and information. Detecting whether a key has been compromised is often a difficult endeavor. Often, the compromise of a key is discovered only after some vital piece of information is found to be no longer secret, as in cases of corporate espionage.

IPSec Architecture IPSec defines a network security architecture that allows secure network transmissions for an enterprise while introducing a minimum of overhead. IPSec allows you to secure packets at the network layer. By performing services at the network layer, IPSec secures information in a manner that is transparent to users and to the protocols that lie above the transport layer. IPSec provides layer 3 protection. The IPSec security architecture exercises an end-to-end security model. Only the endpoints of a communication need to be IPSec aware. Computers and devices that serve as intermediaries of message transfer do not need to be IPSec enabled.This allows a network administrator to implement IPSec for end-to-end security over diverse network infrastructures, including the Internet. Network connectivity devices—such as bridges, switches, and routers—can be oblivious to IPSec without compromising its efficacy.This end-to-end capability can be extended to various communication scenarios, including: ■

Client to client

■

Gateway to gateway

When IPSec is used to protect communications between two clients—for example, on the same LAN—the machines can utilize IPSec in transport mode. In transport mode, both clients must use TCP/IP as their network protocol. In this example, the endpoints of the secure communication are the source machine and the destination host. In contrast, with a gateway-to-gateway solution, information traversing a transit network (such as the Internet) is protected by IPSec. Packets are protected as they leave the exit gateway and then decrypted or authenticated at the destination network’s gateway. In this scenario, the host and destination computers do not have to employ IPSec and can use any LAN protocol supported by IPSec (such as IPX/SPX, AppleTalk, NetBEUI, or TCP/IP).

www.syngress.com


587

When gateways represent the endpoints of secure communication, IPSec works in tunnel mode. In tunnel mode, a tunnel is created between the gateways, and client-toclient communications are encapsulated in the tunnel protocol headers.You can create tunnels using IPSec as the tunneling protocol, or you can combine IPSec with Layer 2 Tunneling Protocol (L2TP). In the latter case, L2TP rather than IPSec creates the tunnel, and IPSec provides the encryption.

Overview of IPSec Cryptographic Services IPSec is able to ensure security of communications by employing a variety of cryptographic techniques. Cryptography encompasses encryption, which is the making and deciphering of hidden or scrambled messages in such a manner that if the message or communication is intercepted, the thief cannot easily ascertain the contents of the message.

NOTE In addition to encryption, another form of cryptography is steganography, which involves hiding or obscuring the very existence of a message, rather than just hiding its contents. Encryption and steganography can be used together for higher security.

A good security system has several component features.The IPSec security architecture is designed to provide the following: ■

Message integrity

■

Message authentication

■

Confidentiality

Message Integrity The term integrity refers to the assurance that the message received is identical to the message that was sent. Integrity is violated if a communication is somehow altered between the sending and receiving computers. Message integrity can be assured via the creation of digital signatures. A digital signature is like an electronic fingerprint.This fingerprint can be a representation of a document’s content. If an intruder were to capture the message in transit and change its contents, the intruder would leave on the message a fingerprint that is different from the original fingerprint.The destination machine would detect that other hands had touched the document and therefore would consider the document’s content invalid.We can use hash functions to create the original fingerprint. www.syngress.com

588


Hashing Messages You can hash a message by running it through a hashing algorithm. A key (a variable called a hash value) is used together with the hashing algorithm to create a hash so that only computers that know the key can create the same hash output of a message.The hashed output is always the same length; the algorithm creates fixed-length outputs from variable-length messages.This hashed output is often referred to as a message digest or a hash signature.You cannot reverse-engineer the digest to get the original message. Each packet must have a different hashed result. For example, if I send you a message that states,“Cash the check,” I will hash the message using a secret key that only you and I know about. After sending “Cash the check” through the hash algorithm using the secret key, we get a message digest of 12345. Now I will send you the message, together with the message digest. In order to make sure that the original message was “Cash the check,” you will send the contents of the message through the same hash algorithm and check the result. If you get 12345, it matches the digest sent to you.You know that indeed “Cash the check” was the original content of the message. If a man in the middle had intercepted the message, he or she might have changed the content of the message to state “Don’t cash the check.”When you received the message, it would read “Don’t cash the check.”You would then run “Don’t cash the check” though the hash algorithm, and the result would be 12389.This result does not match the message digest included with the message.Therefore, you know that the integrity of the message has been violated and should not be considered valid. These message digests are also known as hash message authentication codes (HMACs). To derive an HMAC, Microsoft’s implementation of IPSec uses one of two algorithms: ■

Message Digest 5 (MD5) This algorithm was developed by Ron Rivest of MIT and is defined in RFC 1321. MD5 processes each message in blocks of 512 bits.The message digest ends up being 128 bits.

■

Secure Hash Algorithm (SHA-1) This algorithm also processes messages in blocks of 512 bits. However, the resulting message digest is 160 bits long. This confers a greater degree of security but is a bit more processor intensive and is therefore slower than MD5.

A shared secret key is required to make the hash method work.To ensure the validity of the secret key, you must utilize other technologies, such as a public key infrastructure (as discussed in Chapter 12), which can also take advantage of asymmetric key exchange to provide a higher degree of assurance.

www.syngress.com


589

Message Authentication Authentication is concerned with establishing the identity of a sender or recipient. Integrity concerns itself with making sure that the message has not changed during transit. Authentication focuses on confirming the identities of the conversation participants. It would be of little value to receive a message of uncompromised integrity from an imposter. IPSec uses three methods to carry out message authentication: ■

Preshared key authentication

■

Kerberos authentication

■

Public key certificate-based digital signatures

Preshared Key Authentication Preshared key authentication schemes depend on both members of the communication having preselected a secret key that will be used to identify them to each other. Data leaving the sending computer is encrypted with this agreed-upon key and is decrypted on the other end using the same key. Both members of the communication assume that if the other side has access to this preselected key, both members are who they claim they are.This type of authentication is accomplished in this way: 1. The sending computer can hash of a piece of data (called a challenge) using the shared key and forward this hashed data to the destination computer. 2. The destination computer receives the challenge and performs a hash using the same secret key. It then sends this hashed data back to the first sending computer. 3. If the hashed results are identical, the computers share the same secret key and are thus authenticated. Even though preshared keys are effective in authenticating that each member has access to the same shared secret, this solution is not easily scalable.The shared secret must be manually keyed into the IPSec policy.That is not an issue if the same policy applies to the entire domain tree, but it can become cumbersome when subdomains, organizational units, and individual machines require varying IPSec policies.

Kerberos Authentication The Kerberos authentication method is also based on the shared secret principle. In this case, the shared secret is a hash of the user’s password. For more information about the

www.syngress.com

590


Kerberos authentication protocol, see the section titled “Integrated Authentication” in Chapter 1.

Public Key Certificate-Based Digital Signatures As mentioned earlier in this chapter, a message digest is a hash of a message’s contents. The combination of a key and a hash algorithm is used to create the message digest. A digital signature is an encrypted message digest. A message is authenticated when the digest can first be decrypted, and then the decrypted hash must match the hash derived at the destination host. The sending computer uses its private key to complete this process. Public keybased authentication is based on the principle that each computer or user has a public and private key pair created for it in advance.The public key is freely available to anyone who wants it; the private key is available only to the computer or user that owns it. In order for a public key infrastructure to work, the private key must be kept private. If a private key is compromised, all messages from that computer should be considered suspect and possibly originating from an imposter. A viable public key infrastructure includes these elements: ■

Private keys that are kept absolutely secret

■

Public keys that are freely available to anyone

■

A trusted third party to confirm the authenticity of the public key (to ensure that the public key does indeed belong to the party who claims it)

The trusted third party is known as a certification authority (CA).The CA is required to digitally sign each party’s public key in order to prevent attackers from providing a public key that they claim is that of another person but is in fact not the public key of the person they are impersonating.

NOTE No security method is foolproof, and this includes the use of certification authorities to verify identity. On September 4, 2002, Microsoft announced a certificate validation flaw that can result in spoofing an identity. See Security Bulletin MS02050, Knowledge Base article Q328145 on the Microsoft Web site.

A CA will digitally sign each user’s public key. In this way, if someone sends you his public key, you can be sure that it is his, because a trusted third party has confirmed his identity and signed his public key. Here are two scenarios that illustrate the need for digital certificates and digital signatures: In the first scenario, let’s say your boss wants to

www.syngress.com


591

authenticate your identity using your public key. One way she can do this is by sending you a challenge message, which you encrypt with your private key.You then send it back to her after you have encrypted it. She can then use your public key to decrypt the message. If the message that she decrypts is the same as the message that she sent you, she can confirm that indeed it was you with whom she was communicating. The problem is that she received your public key from you, yourself. How does she know that you, and not someone impersonating you, sent her your public key? You can solve this problem by having a mutually trusted third party digitally sign your public key. Both you and your boss trust that the third party has verified the identity of anyone for whom the third party signs its public key. In the second scenario, let’s say you want to be sure that your boss is who she says she is.You do not have her public key at this point, so you ask her to send it to you. She sends you her signed certificate (the certificate is essentially her public key signed by the trusted third party).You already have the public key of the trusted third party.You use the third party’s public key to verify the signature on the certificate.You know that this verified key is her public key, which she sent you.You can now send a challenge to confirm that you are indeed communicating with your boss and not an imposter.

NOTE You might also want to check the latest Certificate Revocation List (CRL) to ensure that the certificate is still valid and has not been revoked.

Public key authentication is used by IPSec when non-Kerberos-enabled clients need to be authenticated and no preshared key has been established.You must also use public key authentication when you use L2TP tunneling and IPSec.You can also use preshared keys, for example, between a Windows 2000 Routing and Remote Access Server and a third-party firewall product when the two are acting as gateways for a corporate wide area network (WAN).

Confidentiality Neither integrity nor authentication is concerned with protecting the privacy of your information. Confidentiality is a matter of keeping your private information private. In order to ensure confidentiality of IPSec communications, you must encrypt the data using an encryption algorithm.

Data Encryption Standard The encryption algorithm most commonly used with Microsoft’s implementation of IPSec is the Data Encryption Standard (DES) algorithm. DES has long been the U.S. www.syngress.com

592


government standard for encryption.The DES algorithm is an example of a symmetric encryption algorithm. A symmetric encryption algorithm has each side of a communication employ the same secret key for encryption and decryption.This is in contrast to a public key infrastructure, in which two different keys are used.The public key approach is referred to as asymmetric encryption. DES works on 64-bit blocks of data.The DES algorithm converts 64 input bits from the original data into 64 encrypted output bits. DES starts with 64-bit keys, but only 56 bits are actually used in the encryption process.The remaining 8 bits are used for parity. A stronger version of DES is also available for use in Windows 2000/XP IPSec.This version is called 3DES, or Triple DES.Triple DES processes each block three times, which increases the degree of complexity over that of DES.

NOTE Although not used for IPSec at this time, the Advanced Encryption Standard (AES) is the new standard for encryption implemented by the U.S. government. The U.S. government encryption standard is known as the Federal Information Processing Standard, or FIPS. AES uses the Rijndael symmetric encryption algorithm. Effective May 26, 2002, AES became an official government standard.

Cipher Block Chaining Because the blocks of data are encrypted in 64-bit chunks, you must have a way to chain these blocks together.The chaining algorithm defines how the unencrypted text, the secret key, and the encrypted text (also known as ciphertext) will be combined to send to the destination host.These chaining algorithms also solve another problem. If you send the same data twice, both blocks would look the same.This knowledge could be used by a cryptanalyst in trying to figure out the content of a message. In order to prevent each block from looking the same, DES can be combined with cipher block chaining (CBC).This DES-CBC algorithm makes each ciphertext message appear different by using a different initialization vector (IV), which is a random block of encrypted data that begins each chain. In this fashion, you can make each message’s ciphertext appear different, even if you send the exact same message a hundred times.

IPSec Security Services IPSec engages the following two protocols to implement security on an IP network: ■

Authentication header (AH)

■

Encapsulating Security Payload (ESP)

www.syngress.com


593

The Authentication Header The authentication header (AH) ensures data integrity and authentication, and can be used to prevent replay attacks.The AH does not encrypt data and therefore provides no confidentiality.When the AH protocol is applied in transport mode, the AH is inserted between the original IP header and the TCP header, as shown in Figure 10.1.The entire datagram is authenticated using AH. Figure 10.1 The Datagram after Applying the Authentication Header in Transport Mode Transport Mode Original IP Header

AH

TCP

Data

Authenticated

Encapsulating Security Payload The Encapsulating Security Payload (ESP) protocol can provide authentication, integrity, and confidentiality to an IP datagram. Authentication services are available with ESP, but the original IP header prior to application of the ESP header is not authenticated.The ESP header, in transport mode, is placed between the original header and the TCP header, as shown in Figure 10.2. Only the TCP header, data, and ESP trailer are encrypted. If authentication of the original IP header is required, you can combine and use AH and ESP together. Figure 10.2 The Datagram after Applying the Encapsulating Security Payload Header in Transport Mode Transport Mode Original IP Header

ESP Header

TCP

Data

ESP Trailer

ESP Authentication

Encrypted Authenticated

www.syngress.com

594


Figures 10.1 and 10.2 demonstrate packet configurations when AH or ESP is used in transport mode.Transport mode is used when point-to-point communications are taking place between source and destination computers. AH and ESP can be applied at a gateway machine connecting the LAN to a remote network. In this case, tunnel mode is used. In tunnel mode, an additional IP header is added that denotes the destination tunnel endpoint.This tunnel header encapsulates the original IP header, which contains the IP address of the destination computer. Figure 10.3 shows a packet constructed for tunnel mode. Figure 10.3 A Datagram with ESP Header in Tunnel Mode Transport Mode New IP Header

ESP Header

Original IP Header

TCP

Data

ESP Trailer

ESP Authentication

Encrypted Authenticated

Security Associations and IPSec Key Management Procedures Two concepts you need to understand when looking at how IPSec works are security associations and key management. In the following sections, we look at both of these concepts.

Security Associations When two computers establish a connection using IPSec, they must come to an agreement regarding which algorithms and protocols they will use. A single security association (SA) is established for each link a computer maintains with another computer via IPSec. A security association consists of several parts: a destination address, a security protocol, and a security parameters index (SPI), which is a unique identifier. If a file server has several simultaneous sessions with multiple clients, a number of SAs will be defined, one for each connection via IPSec. Each security association has associated with it these parameters: ■

Encryption algorithm (DES or 3DES)

■

Session key (via Internet Key Exchange, or IKE)

■

Authentication algorithm (SHA1 or MD5)

www.syngress.com


595

A security parameters index (SPI) tracks each SA.The SPI is a value that uniquely identifies each SA as separate and distinct from any other IPSec connections current on a particular machine.The index itself is derived from the destination host’s IP address and a randomly assigned number.When a computer communicates with another computer via IPSec, it checks its database for an applicable SA. It then applies the appropriate algorithms, protocols, and keys and inserts the SPI into the IPSec header. An SA is established for outgoing and incoming messages, which means at least two security associations are necessary for each IPSec connection. In addition, a single SA can be applied to either AH or ESP, but not both. If both are used, two more security associations are created—one SA for inbound and one SA for outbound communications.

IPSec Key Management Keys must be exchanged between computers in order to ensure authenticity, integrity, and confidentiality. Key management defines the following: ■

Procedure used to determine how keys are formed

■

Strength of keys

■

How often keys are changed

■

When keys expire

The establishment of a shared secret key is critical to secure communications.You can manually establish a shared secret using the prearranged key method, but this technique does not scale very well due to its inherent lack of flexibility. Automated key management is the preferred method of key exchange. Automated key management uses a combination of the Internet Security Association Key Management Protocol and the Oakley Protocol (ISAKMP/Oakley).This combination of protocols is often referred to collectively as the Internet Key Exchange (IKE).The IKE is responsible for exchanging key material (groups of numbers that will form the basis of new keys), session keys, SA negotiation, and authentication of peers participating in an IPSec interaction. IKE takes place across two phases—Phase 1, in which the two computers agree on mechanisms to establish a secure, authenticated channel; and Phase 2, in which SAs are negotiated for security protocols, using AH, ESP, or both. The first phase establishes what is called the ISAKMP security association (ISAKMP SA), and the second phase establishes the IPSec SA.

Phase 1: Establishing the ISAKMP SA The following processes take place during the ISAKMP SA phase: 1. The computers establish a common encryption algorithm, either DES or 3DES.

www.syngress.com

596


2. A common hash algorithm, either MD5 or SHA1, is agreed upon. 3. An authentication method is established. Depending on policy, this method can be Kerberos, public key encryption, or a prearranged shared secret. 4. A Diffie-Hellman group is agreed upon in order to allow the Oakley protocol to manage the key-exchange process. Diffie-Hellman provides a mechanism for two parties to agree on a shared master key, which is used immediately or can provide keying material for subsequent session key generation. Oakley determines key refresh and regeneration parameters.

Phase 2: Establishing the IPSec SA After a secure channel is established by the creation of the ISAKMP SA, the IPSec SAs are established.The process is similar, except that a separate IPSec SA is created for each protocol (AH or ESP) and for each direction of transmission (inbound and outbound). Each IPSec SA must establish its own encryption algorithm, hash algorithm, and authentication method. One important difference is that each IPSec SA uses a different shared key than that negotiated during the ISAKMP SA. Depending on how the policy is configured, the IPSec SA repeats the Diffie-Hellman exchange or reuses key material derived from the original ISAKMP SA. All data transferred between the two computers takes place in the context of the IPSec SA.

Deploying Windows IP Security Planning takes on special importance when you design a security infrastructure that includes implementation of IPSec within an organization. After the planning phase comes the implementation phase.The Windows graphical interface makes it easy to develop an IPSec policy for any organization. IPSec policy, filters, and filter actions and interoperability with down-level clients and other operating systems are vital parts of implementation.

Evaluating Information The first step in deploying Windows IP Security is to identify your technology assets. You can break down your investment in information technology (IT) resources by enumerating your software, hardware, intellectual property (data), and human assets.What would it cost your organization if those assets were lost or destroyed? What expenditures in time and money would your organization incur if these assets were to fall into the hands of unscrupulous individuals? Developing a security plan starts with the awareness that security represents a balance. Total security means that no one has access to anything. All assets would be protected at www.syngress.com


597

the cost of no one being able to use them. On the opposite end of the spectrum is total openness; no security controls are placed on assets or resources. In that scenario, no one has difficulty obtaining the information or resources he or she needs but your assets have essentially become public domain. In order to implement an effective security policy, you must balance accessibility with security.The more secure the resource, the more difficult it is to access, even for those who are allowed access. Keep this point in mind when you develop a security plan. Use Table 10.1 to categorize your assets. Table 10.1 Categorizing Corporate Assets Type of Asset

Examples

Software

Word processor, spreadsheet, database, operating systems, accounting, inventory, human resource, utilities, diagnostic programs, drivers, communication programs, and enterprise integration systems Workstations, servers, RAM, hard disks, monitors, network interface cards, hubs, switches, bridges, routers, storage area networks, tape devices, modems, ISDN terminal adapters, and printers Customer databases, human resource databases, payroll records, research and development databases and files, project development files, sales information, marketing information, backup tapes, offline storage facilities, floppy disks, removable hard disks, audit logs, information crossing the wire, documentation, and help databases Executives, administrators, developers, marketing staff, sales staff, clerical staff, help desk staff, and hardware technicians

Hardware

Intellectual property (data)

Human

Evaluating the “Enemy” The “enemies” of your security plan are all those who seek to access a resource to which they have no explicit right. Most administrators envision the “black-hat hacker” as the foremost enemy of their information store.This image is not entirely accurate. More likely dangers are: ■

Power users who are interested in “experimenting” to discover what can be done over a network

■

Casual users who stumble upon information that was not secured properly

■

Authorized users who access documents or files that have poorly designed access control, leading to misinformation situations that can create havoc in an organization www.syngress.com

598

Chapter 10 • Protecting Data in Transit with IP Security ■

Disgruntled employees seeking revenge on a current or former employer

■

Greed-driven individuals who sell legitimate access controls to others for a profit

■

Competitors who hire agents to carry out corporate espionage in order to access your proprietary secrets

A common thread is that many of the risks emanate from within an organization. Although shoring up portals to the Internet and other external networks is important, the security analyst’s concern and effort must also be aimed at breaches from within. Keep in mind that someone within an organization can easily plug a notebook computer into an available port at a hub or switch and run sniffing software.These insiders listening on the wire should be of just as much concern as outside intruders.

Determining Required Security Levels As mentioned, a mainstay approach to assessing security levels is to consider what the cost would be if resources were lost, altered, or stolen. Consider how important various resources are to an organization in the short, intermediate, and long term. How much time and money will it cost to return to normal operations if an organization’s assets are compromised? Security-level assessment can be accomplished by assigning an impact level to each item in your list of secure objects. Objects that do not appear to be the focus of security concerns should not be considered to have no impact on your security plan, because unsecured objects can create a backdoor access route to secured objects. Rate your assets as high, medium, or low in terms of their impact on the organization should they be compromised.Table 10.2 provides some examples of how you would categorize security requirements for various types of information. Table 10.2 Categorizing Impact Levels for Various Data Types Type of Information

Impact Level

Corporate accounting data Research data Proprietary or patented information Marketing information Human resource information Prospects database Parking permit database

High High High Medium Medium Low Low

www.syngress.com


599

The security-level assessment is not the sole province of the security analyst.You need to meet with all department managers to assess their views and level of understanding of security issues. Polling nonmanagerial employees is also important in making the security assessment, because employees are often the first ones to be encumbered when they try to access needed information that has been secured.

Building Security Policies with Customized IPSec Consoles IPSec configuration and deployment in a Windows 2000 or .NET network are intimately intertwined with Active Directory and Group Policy.You must create a policy in order to deploy IPSec in your organization. A policy can be applied to a forest, a tree, a domain, an OU, or a single computer. Within the Group Policy console, you can choose from built-in policies or create custom policies to meet your specialized needs.You configure these policies by creating a Microsoft Management Console (MMC) and then using the appropriate MMC plugin. Exercise 10.1 walks you through building an IPSec MMC console.You can also configure a custom IPSec console that is used to configure IPSec policy and monitor significant IPSec-related events.

Exercise 10.1 Building an IPSec MMC Console 1. Create a new console by starting the Run command and typing mmc. Click OK to open an empty console. 2. Click the Console menu, and then click Add/Remove Snap in. Click Add, select Computer Management, and click Add. A dialog box appears that asks which computer the snap-in will manage. Select Local Computer (the computer on which the console is running).Then click Finish. 3. Scroll through the list of available snap-ins, select Group Policy, and then click Add. At this point a wizard appears and queries you on what Group Policy object you want to manage. In this case, confirm that the text box states Local Computer, and click Finish. If you want to define a policy for another Group Policy object, click Browse and select from the list. 4. Scroll through the list of Group Policy objects again, this time looking for Certificates. Select Certificates and click Add. A dialog box appears, asking you for what account you want the snap-in to always manage certificates (see Figure 10.4). Select Computer Account, click Next, and then select Local Computer for the computer that you want the snap-in to manage.Then click Finish.

www.syngress.com

600


Figure 10.4 Adding the Certificate Management Snap-In for the Local Computer

5. Click Close in the Add Standalone Snap-in dialog box and then click OK in the Add/Remove Snap-in dialog box. Expand the first level of each of the snap-ins (see Figure 10.5). Figure 10.5 The Custom IPSec Security Management Console

NOTE In Exercise 10.1, you use the Group Policy snap-in to manage local IPSec policies. The reason this exercise uses this snap-in is so that you will be familiar with configuring Group Policy, which allows you to manage site, domain, and OU Group Policy objects the same way. If you want to manage only IPSec policies, there is an easier way: Use the IP Security Policy Management snap-in. This will take you directly to the IPSec portion of the Group Policy object without having to navigate to the correct location.

www.syngress.com


601

From this custom IPSec Management Console, you will configure and monitor IPSec policies. In this example, IPSec policy is managed for the local machine only.This might be appropriate if you are configuring IPSec policy for a file or application server. If you want to manage policy for an entire domain or OU, you would select the appropriate policy when selecting the Group Policy snap-in configuration.

Flexible Security Policies Now that you have a console configured, you can get to the business of building your IPSec security policy. Because IPSec policies are implemented via Group Policy, you’ll find a great deal of flexibility in the places where they are implemented.You can choose from three built-in IPSec policies or create your own custom policies. To begin, you need to navigate in the console to where the IP security policies are located. Expand the Local Computer policy; expand the Computer Configuration object; expand the Windows Settings object; then click IP Security Policies on Local Machine. In the right pane, you will see listed the three built-in IPSec Policies: ■

Client (Respond Only)

■

Secure Server (Require Security)

■

Server (Request Security)

Your screen should look like the one shown in Figure 10.6. Figure 10.6 The Three Built-In IPSec Policies

www.syngress.com

602


Let’s take a closer look at each of these policies. ■

Client (Respond Only) The Client (Respond Only) policy is used when you require secure IPSec connections only when another computer requests them. For example, this is the case if you are using a machine as a workstation that wants to connect to a file server and the file server requires IPSec security.The workstation with the built-in Client policy enabled will negotiate an IPSec security association. However, this client never requires IPSec security itself; it only uses IPSec to secure communications when requested to do so by another computer.

■

Secure Server (Require Security) The Secure Server (Require Security) policy is used when all communications with a particular server need to be secured. Examples include file servers with highly sensitive information and security gateways at either end of an L2TP/IPSec tunnel.The server with the Secure Server policy always requests a secure channel. Most importantly, connections are denied to computers not able to respond to the request.Thus, a non-IPSec-aware computer will be unable to connect.

■

Server (Request Security) The Server (Request Security) policy is used when you want to request IPSec security for all connections.This policy might be used for a file server that must serve both IPSec aware clients (such as Windows 2000/XP) and non-IPSec-aware clients (such as Windows 9.x and NT). If a connection is established with an IPSec-aware computer, IPSec will be used to secure the session.With non-IPSec-aware computers, unsecured sessions are established.This scheme allows greater flexibility during the transition from mixed Windows networks to native Windows 2000 networks.

Security policies are bidirectional. If your secure server attempts to connect to nonIPSec-aware network servers—such as DNS,WINS, or DHCP servers—the connection will fail. It is imperative that you test all scenarios in a lab that simulates your production network before you implement IPSec policies on your live network. During the testing phase, you must assiduously check the event logs to ascertain what services fail due to IPSec policies.

SECURITY ALERT! Implementing IPSec security affords you a large measure of comfort in knowing that traffic as it traverses the wire is safe from interception and manipulation. However, IPSec can significantly impact network service interoperability. Network servers that run the DHCP, WINS, or DNS services are a point of concern. This is particularly problematic when you run the Secure Server policy on a

www.syngress.com


603

machine providing one of these services. Should you need to do so, be aware that negotiation will fail on non-IPSec-enabled computers. The result of the failed negotiation is that those clients will not be able to use that network service. A special case is when you use DNS names in the IP filter list, and the DNS server you are using is not IPSec aware. The unaware DNS server will not be able to successfully negotiate secure communication, and therefore name resolution attempts will fail, with cascading results. To solve this problem, create a new filter list and rule to exempt traffic from the DNS from IPSec negotiation. When you set the rule, use the Permit option to allow traffic to flow unimpeded. The filter should be for computer-to-computer IP addresses (not network IDs) and for the port number.

Rules An IPSec policy has three main components—IP security rules, IP filter lists, and IP filter actions. Double-click the Server Policy to see the Server (Request Security) Properties dialog box, as is shown in Figure 10.7. Figure 10.7 The Server (Request Security) Properties Dialog Box

Rules are applied to computers that match criteria specified in a filter list. An IP filter list contains source and destination IP addresses.These can be individual host IP addresses or network IDs.When a communication is identified as a participant included in an IP filter list, a particular filter action that is specific for that connection is applied. The All IP Traffic filter list includes all computers that communicate with the server via TCP/IP. Any instructions in the filter action associated with All IP Traffic are applied.

www.syngress.com

604


First, double-click the All IP Traffic filter list.This opens the Edit Rule Properties dialog box for the All IP Traffic filter.You should see a tabbed dialog box consisting of five tabs, as shown in Figure 10.8. Figure 10.8 The All IP Traffic Edit Rule Properties Dialog Box

An option button for the IP filter list is selected and a description is included that explains the purpose of the list. Double-click the All IP Traffic filter list option to see the details of the All IP traffic filter.The name, description, and details of the filter are displayed (see Figure 10.9). Figure 10.9 The IP Filter List Dialog Box

To see more details regarding the addressing, protocol, and description of the filter, click Edit.Then, click Cancel twice to return to the Edit Rules Properties dialog box.

www.syngress.com


605

Filter Actions Filter actions define the type of security and the methods by which security is established.The primary methods are Permit, Block, and Negotiate security.The Permit option blocks negotiation for IP security.This action is appropriate if you never want to secure traffic to which a rule applies.The Block action blocks all traffic from computers specified in the IP filter list.The Negotiate security action allows the computer to use a list of security methods to determine security levels for the communication.The list appears in descending order of preference. If the Negotiate security action is selected, both computers must be able to come to an agreement regarding the security parameters included in the list.The entries are processed sequentially in order of preference. The first common security method is enacted. Click the Filter Action tab, and click Request Security (Optional) to view the options, as shown in Figure 10.10. Figure 10.10 The Request Security (Optional) Properties Dialog Box

Checking the Accept unsecured communication, but always respond using IPSec check box allows unsecured communication initiated by another computer but requires the computers to which this policy applies to always use secure communication when replying or initiating.This is essentially the definition of the secure policy.The Allow unsecured communication with non IPSec-aware computer option allows unsecured communication to or from another computer.This is appropriate if the computers listed in the IP filter lists are not IPSec enabled. However, if negotiations for security fail, this option disables IPSec for all communications to which this rule applies. Perhaps the most important of these options is the Session key Perfect Forward Secrecy option.When you select this option, you ensure that session keys or keying

www.syngress.com

606


material are not reused, and new Diffie-Hellman exchanges will take place after the session key lifetimes have expired. Click Cancel to return to the Edit Rule Properties dialog box. Click the Authentication Methods tab. Here, you can select your preferred authentication method. Kerberos is the default authentication method.You can include other methods in the list, and each will be processed in descending order.You can click Add to include additional authentication methods, as shown in Figure 10.11. Figure 10.11 The Authentication Methods Configuration Tab

Click the Tunnel Setting tab if the endpoint for the filter is a tunnel endpoint. Click the Connection Type tab to apply the rule to all network connections, local area network (LAN), or remote access, as shown in Figure 10.12.

NOTE You cannot delete the built-in policies, although you can edit them. However, it is recommended that you leave the built-in policies as they are and create new policies for custom requirements.

Flexible Negotiation Policies Security method negotiation is required to establish an IPSec connection.You can use the default security policies, or you can create custom policies using a wizard-based approach.To add a new filter action that will be used to create a new security policy, click Add after selecting the Filter Action tab.When the wizard has completed, you can edit the security negotiation method. www.syngress.com


607

Figure 10.12 The Connection Type Tab

When you double-click the Request Security (Optional) filter action, you will see the Request Security (Optional) Properties dialog box. If you select the Negotiate security option and then click Add, you can add a new security method, as shown in Figure 10.13. Figure 10.13 The New Security Method Dialog Box

You can fine-tune your security negotiation method by selecting the Custom (for expert users) option and then clicking Settings. After doing so, you will see the Custom Security Method Settings dialog box, as shown in Figure 10.14.

www.syngress.com

608


Figure 10.14 The Custom Security Method Settings Dialog Box

Here, you can configure whether you want to use AH, ESP, or both. For each option, you can select the integrity algorithm, the encryption algorithm, or both. All algorithms supported by the operating system are included. Session key lifetimes can be customized by entering new key generation intervals, based on the amount of data transferred (in kilobytes) or time span (in seconds).

Filters Rules are applied to source and destination computers or networks based on their IP addresses. Filters specify the source and destination addresses of the IP traffic as well as the protocols that will be affected by the filter.To create a new filter, you can avail yourself of the Filter Wizard.To do this, return to the Edit Rule Properties dialog box, click the IP Filter List tab, and then click Add.This brings up the IP Filter List dialog box, where you enter the Name of the new filter and a description of the filter. Click Add to start the wizard. When the wizard starts, you see the Welcome dialog box. Click the Next button. As shown in Figure 10.15, you choose the source address of the wizard.Your options appear after you click the down arrow on the list box. Note that you can identify the source by individual IP address, all IP addresses, DNS name, or subnet. Click Next to continue. The next dialog box asks for the destination IP address.You are afforded the same options as when you designated the source. Click Next to continue the wizard. At this point, you can select the protocols that will be included in the filter. All protocols are included by default, but you can select from a list of protocols or define your own by selecting Other and entering a protocol number.The IP protocol selection dialog box is shown in Figure 10.16. Click Next, and then click Finish.Your new filter will appear in the IP filter lists included in the IP Filter List tab of the Edit Rule Properties dialog box. www.syngress.com


609

Figure 10.15 Specifying a Source IP Address for a New Filter

Figure 10.16 Selecting a Protocol Included in the New Filter

Creating a Security Policy To illustrate the process of creating a security policy, let’s consider the following scenario:You are the network administrator for a large hospital.The network is subdivided into multiple subnets.The medical records department contains a large amount of data that must be kept secure.The hospital would incur significant legal liability if security were breached. Computers within the medical records department are closely monitored, and therefore the overhead of confidentiality is not required, but authentication and integrity should be applied to intradepartmental communications. The medical records department must regularly send information to the hospital floor.The network infrastructure is more open to attack between the well-guarded medical records department and the less secure, open hospital environment. All computers within the medical records department are located in network ID 192.168.1.0, www.syngress.com

610


and all floor computers that access medical records database information are located on network ID 192.168.2.0.The default Class C subnet mask is used. In order to implement your new security policy, you need to: 1. Create a security policy for the hospital’s domain. In this way, all computers in the domain will inherit the IPSec policy. 2. Computers in the medical records department need to communicate with two sets of computers—machines within their own department and machines on the hospital floor. Characterizing these machines by subnet, you could say that machines on subnet 192.168.2.0 need to communicate with machines on 192.168.1.0, and machines on 192.168.1.0 need to communicate with machines on 192.168.2.0.When selecting the protocols, you select All so that all IP traffic is filtered.Therefore, you need to create two filters so that you can assign different filter actions to each filter. 3. Now you need to create two filter actions (negotiation policy); the first filter action will be applied to intradepartmental communications, in which only authentication and integrity are important, and the second filter action will be applied to extradepartmental communication, where authenticity, integrity, and confidentiality are required.The first filter action might use AH, which provides for authenticity and integrity.The second filter action might use a combination of AH and ESP, to provide the highest level of authentication and integrity while also providing confidentiality. By implementing these combinations of filters and filter rules, you can effectively secure traffic in a customized fashion.You can easily implement this solution by invoking the Security Rule Wizard after you create the new security policy.

Making the Rule The rule you make will create a filter for all communications emanating from 192.168.1.0 that are directed to 192.168.2.0. After the filter is created, you create a filter action. In this case, you need to ensure secure communications, because you are communicating with the unsecured hospital floor.You need to ensure integrity, authentication, and confidentiality.Therefore, you do the following: 1. Click Start | Programs | Administrative Tools | Active Directory Users and Computers. After the Active Directory Users and Computers console is open, right-click the domain name, then click Properties. In the Domain Properties window, click the Group Policy tab. 2. Select Default Domain Policy and click Edit.

www.syngress.com


611

3. This opens the Group Policy Editor. Expand Computer Configuration, expand Windows Settings, expand Security Settings, and then right-click IP Security Policies on Active Directory. Click Create IP Security Policy. 4. A wizard starts, welcoming you. Click Next. 5. You now need to enter the name of the policy, as shown in Figure 10.17. Name it MedRecToFloor, then click Next.You’ll see the window shown in Figure 10.18. Remove the check mark in the Activate the default response rule check box. Click Next. Figure 10.17 Entering an IP Security Policy Name

Figure 10.18 Handling Requests for Secure Communication

6. Now you are at the end of the wizard. Leave the check in the Edit Properties box, and click Finish (see Figure 10.19).

www.syngress.com

612


Figure 10.19 Completing the IP Security Policy Wizard

7. At this point, you have no IP filter lists. Use the Add Wizard to create a new filter list and filter action.Together, they create a filter rule. Make sure that there is a check in the Use Add Wizard check box and click Add, as shown in Figure 10.20. Figure 10.20 The MedRecToFloor IPSec Policy Properties

8. The Security Rule Wizard opens.The first dialog box is a welcome box. Click Next. 9. The next dialog box (see Figure 10.21) asks whether the rule applies to a tunnel endpoint. In this case, it does not, so select This rule does not specify a tunnel. Click Next.

www.syngress.com


613

Figure 10.21 Selecting a Tunnel Endpoint

10. The wizard now asks what network connections this rule should apply to, as shown in Figure 10.22. Select All network connections, then click Next. Figure 10.22 Choosing the Network Type

11. Now decide what default authentication protocol should be used. Select Windows 2000 default (Kerberos V5 protocol), as shown in Figure 10.23. Then click Next. 12. Create the IP filter list by adding a filter for all traffic sent from 192.168.1.0 with the destination of 192.168.2.0. Click Add, as shown in Figure 10.24. 13. You now see the IP Filter List dialog box.Type Secure from MedRec to Floor, and make sure the Use Add Wizard check box is filled, as shown in Figure 10.25.Then click Add.

www.syngress.com

614


Figure 10.23 Select an Authentication Protocol

Figure 10.24 Adding a New Filter List

Figure 10.25 The IP Filter List

www.syngress.com


615

14. The IP Filter Wizard (yes, another wizard!) appears. Click Next to move past the Welcome dialog box. Now you are at the IP Traffic Source dialog box shown in Figure 10.26. Click the down arrow under Source address and select A specific IP Subnet.Type 192.168.1.0 and a subnet mask of 255.255.255.0.Then click Next. Figure 10.26 Choosing the IP Traffic Source

15. Now enter the IP traffic destination shown in Figure 10.27. Under the Destination address click the down arrow and select A specific IP Subnet. Then type the destination subnet 192.168.2.0 with a subnet mask of 255.255.255.0. Click Next. Figure 10.27 Choosing the IP Traffic Destination

16. You want all the protocols to be included in the filter, so select Any (see Figure 10.28) for the protocol type, click Next, and then click Finish to complete the wizard. www.syngress.com

616


Figure 10.28 Choosing the IP Protocol Type

17. This takes you back to the IP Filter List dialog box. Click Edit (see Figure 10.29). Mirrored should be checked. Match packets with the exact opposite source and destination addresses to ensure that machines from the destination subnet are also included in the incoming filter. Click OK to close the dialog box, and then click Close.You are now back to the IP Filter List dialog box in the Security Rule Wizard. Select the Secure from MedRec to Floor filter list and then click Next. Figure 10.29 The Filter Properties Dialog Box

18. At this point, configure a filter action. Select the Require Security option. Make sure there is a check mark in the Use Add Wizard check box, and then click Add, as shown in Figure 10.30.

www.syngress.com


617

Figure 10.30 The Filter Action Dialog Box of the Security Rule Wizard

19. The IP Security Filter Action Wizard starts. Click Next to move past the Welcome dialog box. Here (see Figure 10.31) you are asked for a name; enter SecureMedRec, and click Next. Figure 10.31 Naming the Filter Action

20. The Filter Action General Options dialog box shown in Figure 10.32 asks for a filter action behavior. Select Negotiate security and click Next. 21. You receive a dialog box that asks whether you want to support communications with computers that do not support IPSec. Select the Do not communicate with computers that do not support IPSec option, as shown in Figure 10.33. Click Next.

www.syngress.com

618


Figure 10.32 Setting the Filter Action Behavior

Figure 10.33 Preventing Communication with Non-IPSec Computers

22. Now select the security method for IP traffic.To ensure confidentiality, authentication, and integrity, select Custom (see Figure 10.34) and then click Settings (see Figure 10.35). Select the Data and address integrity without encryption (AH) check box and then click the down arrow and select SHA1. Make sure that there is a check mark in the Data integrity and encryption (ESP) check box, and select MD5 and 3DES. Do not set the session key settings; you will select Perfect Forward Secrecy later. Click OK, then click Next.The final dialog box appears. Ensure that a check mark is in the Edit box, and then click Finish. 23. You are brought to the New Filter Action Properties dialog box. Check Session key Perfect Forward Secrecy, as shown in Figure 10.36. Click OK to return to the Security Rule Wizard, then click Next. www.syngress.com


619

Figure 10.34 Setting IP Traffic Security

Figure 10.35 The Custom Security Method Settings

Figure 10.36 Enabling Perfect Forward Secrecy

www.syngress.com

620


24. This is the last dialog box for the Security Rule Wizard. Click Finish. Click OK to close the New Rule Properties dialog box.You are returned to the MedRecToFloor Properties box. Click the General tab (see Figure 10.37). You can configure how often the Policy Agent checks for policy changes here. Click Advanced to control the Internet Key Exchange Process. Figure 10.37 The General Tab for the IPSec Policy Properties

25. Here, you control the security of the Internet Key Exchange process, as shown in Figure 10.38. Click Methods to configure the security methods that are used to protect identities during the key exchange process, as shown in Figure 10.39. Figure 10.38 The Key Exchange Setting

26. Click OK, click OK again, and then click Close.Your new security policy appears in the console.

www.syngress.com


621

Figure 10.39 The Key Exchange Methods

As you can see, what looks easy on paper can be somewhat daunting when you actually apply the principles! With the rule you created, all traffic leaving 192.168.1.0 to 192.168.2.0 will be secured according to the filter rule you set up. Because it is mirrored, the same rule applies in the other direction. The IP Security Monitor can be used to monitor IPSec status and test the IPSec policies. In Windows 2000, you can start the monitor by typing ipsecmon.exe at the command line; in Windows XP/.NET, you must create a custom MMC and add the IP Security Monitor snap-in. Figure 10.40 shows the IPSec MMC. Figure 10.40 The IPSec Monitor Can be Used to Test IPSec Policies and Gather IPSec Statistics

You can use the IPSec monitor to view statistics regarding the following: ■

Active security associations with other computers (for a log of SAs not currently active, see the Security Log in Event Viewer; SAs are shown as Netlogon events) www.syngress.com

622

Chapter 10 • Protecting Data in Transit with IP Security ■

Number of bytes of data sent using ESP for confidentiality

■

Number of bytes of data received that were sent using ESP

■

Number of bytes sent with authentication

■

Number of packets with invalid security parameters index

■

Number of packets that couldn’t be decrypted

■

Number of packets that couldn’t be authenticated

■

Number of keys sent by ISAKMP to the IPSec driver

■

Number of SAs established during the first phase of ISAKMP

■

Number of SAs established during the second phase of ISAKMP

■

Number of ISAKMP negotiations in which clear text data transfer was negotiated (known as soft associations)

■

Number of failed authentications

Compatibility Notes In order to fully engage the capabilities of the IPSec security architecture, your entire enterprise must use IPSec-aware devices.The only currently released Microsoft operating systems that are IPSec aware at this point are Windows 2000 and XP.Windows .NET will also be IPSec aware. Communications to or from any other version of Windows cannot be secured via IPSec.

NOTE Microsoft released an L2TP/IPSec client for Windows 98, ME, and NT 4, which will allow the use of IPSec encryption in an L2TP virtual private network (VPN), but these operating systems do not support use of IPSec alone to secure network communications. The L2TP/IPSec VPN client can be downloaded from the Microsoft Web site at www.microsoft.com/windows2000/server/evaluation/ news/bulletins/l2tpclient.asp.

www.syngress.com


623

Summary Windows 2000 and its successors provide administrators with a new tool in their defense against security violations. IPSec allows administrators to secure information as it crosses a network. IPSec secures data at the network layer and carries out its activity transparently in the background. Users and applications do not need to be aware of IPSec. IPSec’s implementation at the network layer gives it an advantage over security protocols, such as SSL, for which applications must be specifically written to support. Hallmarks of secure communications ensure authentication, integrity, and confidentiality. Authentication assures a receiver that a message was indeed sent by the individual who claims to have sent it. Data integrity ensures that message content has not been altered during transit. Confidentiality ensures that others cannot read data during transit. Combining all three provides solid end-to-end security between any two communicating hosts. To meet the goals of authentication, integrity, and confidentiality, algorithms are used to represent the original data in a different fashion. Authentication methods available include Kerberos, public key certificates, and preshared keys. Integrity algorithms used by Windows 2000 IPSec include MD5 and SHA1. Confidentiality is ensured by scrambling messages using either DES or 3DES. Algorithms must work with keys in order to carry out their functions. Computers must have access to the same shared secret key when they perform forward and reverse operations using these algorithms. IPSec implements Internet Key Exchange, which is a combination of ISAKMP and the Oakley protocols. Key management techniques ensure that intruders cannot compromise security by accessing a single key. IPSec uses two protocols that add their own headers to IP datagrams.The Authentication Header provides authentication and integrity but not confidentiality.The Encapsulating Security Payload provides authentication, integrity, and confidentiality. The two protocols can be combined to provide a higher degree of security. Each IPSec connection a computer establishes has its own security association.The two types of SA are the ISAKMP SA and the IPSec SA.The ISAKMP SA provides a secure channel for the exchange of keying information to provide a master key, and the IPSec SA defines parameters for each secure IPSec channel between computers. A separate IPSec SA is created for both inbound and outbound connections. Each IPSec SA is individualized by assigning it a security parameters index. Planning security requirements involves taking an inventory of your hardware, software, intellectual property (data), and human resources. After the inventory, you should assess the cost to the organization if any of the assets are lost or compromised. Assign each asset an impact value, and focus security concerns on the basis of the value you assign. Also, keep in mind that your enemy is most likely to be inside your organization.

www.syngress.com

624


Network security enabled by IPSec is policy driven. Policies are integrated into Active Directory on domain machines, or they can be implemented as local machine policies. Each IPSec-aware computer uses a policy agent, which checks for IPSec policy during startup and periodically afterward. IPSec policies are implemented as a series of rules.These rules include IPSec filter lists and IPSec filter actions. If a computer seeks to establish a session with a computer whose IP addressing information matches a number in one of the filter lists, a filter action affiliated with that list is triggered.The creations of IPSec policies, filter lists, and filter rules can be easily accomplished via wizard-driven interfaces.You can create your own policies or use one of the three built-in policies.The built-in policies are the Client, Server, and Secure Server IPSec policies. You need to take compatibility issues into account when you enable IPSec in your organization.Windows 2000 and XP/.NET are the only Microsoft operating systems that are IPSec aware. Connection failures will result if a computer configured with the Secure Server policy interacts with non-IPSec-aware machines. The future of IPSec looks bright.The next generation of the Internet Protocol— IPv6—has built-in support for IPSec. See RFCs 2411 and 2401 for descriptions and specifications for IPSec as an Internet standard.

Defensive Tactics Fast Track Network Encroachment Methodologies ; Snooping involves sniffing a cable and looking for information being sent

across the wire in an attempt to gain someone’s username and password. ; Spoofing involves impersonating another user or computer in an attempt to

gain information with the stolen identity. ; Passwords can be compromised via one of the many password-cracking

utilities on the market, sniffing the cable (snooping), or using social engineering to trick users into giving their passwords. ; Denial-of-Service disrupts the services running on a computer in an attempt

to make the server unavailable to legitimate requests. ; In a man-in-the-middle attack, an intruder sits between a client and a server

and watches the communications from both parties. ; Application-directed attacks try to exploit known vulnerabilities in applications.

www.syngress.com


625

; Compromised key attacks are geared toward obtaining a user’s private key.

After the intruder has the user’s private key, the intruder can use it to impersonate the user.

IPSec Architecture ; IPSec provides packet filtering at the network layer.This makes IPSec

completely transparent to the applications running on the computer. ; IPSec provides integrity, authentication, and confidentiality. ; IPSec has two modes—tunnel mode and transport mode.Transport mode uses

TCP/IP to send IPSec-encrypted information directly between two clients. Tunnel mode allows clients to use protocols other than TCP/IP.The clients send unencrypted information to a tunnel endpoint.The tunnel endpoints use TCP/IP and IPSec to encrypt the client information. ; IPSec uses two protocols—Authentication Header and Encrypted Security

Payload. AH provides data integrity and authentication but not confidentiality. ESP can provide authentication, integrity, and confidentiality but does not encrypt the entire packet. ; IPSec uses a security association between two computers to determine the

algorithms and protocols to be used by each computer.

Deploying Windows IP Security ; IPSec is managed through a custom MMC console containing the IPSec

Security Policy snap-in. ; An IPSec policy has three main components—IP security rules, IP filter lists,

and IP filter actions. ; IP security rules apply to computers that match criteria in the filter list. ; An IP filter list contains source and destination IP addresses. ; IP filter actions determine the level of security (authentication and

encryption) and the method by which security is negotiated.

www.syngress.com

626



Q: What happens if a computer attempts to connect to another computer with the Secure Server IPSec policy and it fails to authenticate?

A: The server will not accept connections from that host for at least one minute and as long as five minutes.This is something to be aware of when you troubleshoot connectivity problems with IPSec-enabled machines.

Q: Can I use Kerberos authentication for my users who are using an L2TP/IPSec tunnel to dial into intranet servers?

A: VPN connections in Windows 2000 are designed to use certificate-based public key authentication, although there is a Registry hack that allows you to use preshared keys for testing purposes. In Windows XP, the interface provides an IPSec settings option that lets you use a preshared key for authentication.

Q: Our internal network uses network address translation (NAT) rather than public IP addresses. Can I use L2TP/IPSec tunnels to allow remote access VPN clients to access my internal resources?

A: No. Because of incompatibilities between NAT and IPSec, you cannot use both at the same time. L2TP over IPSec traffic is not translatable by a NAT because the UDP port number is encrypted.

Q: What is Perfect Forward Secrecy? A: Perfect Forward Secrecy ensures that a key used to protect a transmission, in whichever phase, cannot be used to generate any additional keys. If the key used was derived from specific keying material, that material cannot be used to generate any other keys.This provides a high level of protection. If an intruder is able to access data and obtain a key, that key will not be valid on other packets, making the cracking process very difficult.

Q: Is there a tool included in Windows that I can use to monitor IP traffic for troubleshooting purposes?

A: Yes. From the Run command, type ipsecmon, and click OK.You will be offered a graphical interface to use to monitor IPSec traffic. www.syngress.com

Chapter 11

Authenticating Users with Smart Cards


Understanding Smart Card Technology

■

Smart Card Interoperability

■

Smart Card Components

■

Enhanced Solutions


627

628

Chapter 11 • Authenticating Users with Smart Cards

Introduction As discussed in previous chapters, one of the most important elements of a security plan is the ability to ensure that a communication really comes from the user or computer that purports to have sent it.This validation of identity is called authentication, and developing a foolproof authentication scheme is one of the biggest challenges faced in the corporate networking environment. As part of the effort to solve this problem, many products and technologies have been developed that enhance the security of communications by digitally signing and encrypting them. One of the most popular of these technologies is public/private key technology, which requires each user to have a private key that only that user possesses and for which only that user knows the password, along with a mathematically related public key that is distributed freely to everyone.Working in conjunction with public/private key technology are smart cards. A smart card is a device that is similar in appearance to a credit card, and offers a secure place to physically store and access keys. Further, a smart card provides an added security advantage—a user must have physical possession of the card in order to gain access. Some of the popular uses of smart cards include: ■

Electronic entry to physically restricted areas

■

Secure logons

■

User authentication

■

Secure e-mail

In the future, we can anticipate that the use of smart cards will be expanded to include consolidation of personal information, bank accounts, medical history, and more on a single portable interface the size of a credit card or smaller. Before storing your most personal information on a little plastic card, however, you should know more about smart cards’ reliability and confidentiality. One of the smart card’s goals is to protect information from misuse by third parties.To make this possible, the data is stored on a card that is always in your possession—not stored on your home computer, your office computer, or some computer located on some network. By being in your pocket, the information on the smart card is already more secure than it ordinarily would be. Now consider the process of using your card.You have data on the card so that you can use it somehow. Usually, when you interact with data, it is manipulated on a host PC.This might be fine for some applications, but would you really want your bank information, medical records, private keys, and other secret information to reside on an insecure machine for even a second? Most of us would not.The smart card allows you to store and process information on the card without ever placing it in danger of being

www.syngress.com

Authenticating Users with Smart Cards • Chapter 11

629

compromised. And what happens if you lose your card? As long as you didn’t write your secret personal identification number (PIN) on it, you would be fine. No one can access the information stored on a smart card without a valid PIN. Some cards even support a “three strikes and you’re out” protection scheme, which disables the card if too many incorrect PINs are entered while a user attempts to access the card’s information. Furthermore, because a digital certificate usually identifies a card, canceling your card is as easy as revoking your certificate. Still worried? Recent advancements in technology have brought us even closer to biometrics security, an example of which is an integrated scanner that reads your thumbprint instead of (or in addition to) requiring you to enter a PIN.With biometrics security used in conjunction with a card in a multifaceted authentication scheme, you have an even higher level of security. Smart card technology has roots dating back to 1974, when Roland Moreno was issued the first patents for his chip cards. At the time, the cards were highly advanced and expensive and therefore were not taken seriously by the general public for the first few years. By 1978, chip miniaturization made mass production possible, and it has led to the current popularity of smart cards. France, which was one of the first countries to really embrace this technology, continues to deploy more and more smart cards every year. Since 1985, over 600 million smart cards have been produced in France—110 million of those in 1994 alone.The technology has been around for years, but its main problem in reaching widespread use in other parts of the world involves compatibility issues. Because the cards, readers, and software have been mostly proprietary until recently, companies have been reluctant to deploy systems for fear of being at the mercy of a single vendor. Now, as standards are developed and major players, such as Microsoft, get into the act, smart cards are gaining popularity in the United States and elsewhere.

Understanding Smart Card Technology According to the cover story of Information Security Magazine, March 2002, over 41 million smart cards were made to be used in the United States in 2001 and are being shipped to retail, financial, and government institutions in ever-increasing numbers.The concept of using a smart card is simple—the user inserts the card into (or swipes it through) a reading device, enters a PIN, and is granted access. However, the underlying technology is complex. In the following sections, we take a look at the hardware and software involved, and how smart cards are used for authentication purposes.

“Under the Hood” of the Smart Card Smart cards differ from traditional credit or debit cards in that the latter use a magnetic strip to store information, whereas smart cards have an integrated circuit embedded in the www.syngress.com

630


card (this is the reason they are sometimes also called ICCs, or Integrated Circuit Cards). This chip is a miniature, dedicated computer that runs an operating system designed for this purpose.Windows for Smart Cards (Windows Powered Smart Card 1.1) was developed by Microsoft as a smart card OS platform. Smart cards are getting smarter all the time. Five years ago, the memory capacity of the cards was limited to around 8K.This made them useful for single applications, but difficult to program for multiple uses.Today cards are available with memory capacities ranging from 32K through 128K and can be programmed for multiple functions. Gemplus has developed a smart card prototype that is capable of much larger memory capacities, and, as with other computer products, memory capacity of smart cards from all vendors is sure to increase as time goes on.

Understanding Smart Card Authentication Authentication (validation of identity) along with confidentiality (keeping the contents of messages secure) and integrity (ensuring that data is not changed in transit) is one of the primary components of computer security. Authentication can be accomplished using a few methods, and each method has advantages and disadvantages.

Authentication Methods Identity authentication can be accomplished in three basic ways. All involve having the user provide some information in addition to a user account name that can be used to verify that the user is the legitimate holder of the account.The three methods are: ■

Providing something you know This is the most common method and usually involves entering a password, passphrase, or PIN.The advantage of this method is that it’s convenient for a user, who does not have to carry an identifying item, and this can be a secure method if proper procedures are followed (such as the password is memorized and never written down, never divulged to anyone else, complex and not easily guessed, and changed on a regular basis). Unfortunately, getting all users to comply with password policies can be difficult, and passwords are often compromised through social engineering or brute force attacks.

■

Providing something you are This is biometric security and can be a very secure method because it relies on physiological characteristics of a user, such as a fingerprint, voice analysis, retinal scan, and so forth that cannot be easily faked. However, this method has disadvantages, too.While some believe that this method is foolproof, security specialists have demonstrated that there are ways to defeat biometric security—especially systems based on fingerprints— and because of its reputation as “foolproof,” those who deploy it might be less

www.syngress.com


631

likely to detect when it has been compromised. In addition, many people consider biometrics to be intrusive and are uncomfortable with systems that require it. ■

Providing something you have This is the category into which smart card authentication falls. Because you must have the card in your physical possession, and because smart cards are always used in conjunction with a PIN (something you know), they provide multifaceted security. Cost is generally lower for smart card equipment than for biometric scanners, and users concerned about privacy issues are more amenable to the idea of carrying a card than submitting to a biometric scan.

Advantages of Smart Card Authentication Smart cards integrate nicely into a public key infrastructure (PKI), a public key based organization-wide authentication system that is becoming more and more popular within the corporate environment. Although the data on a smart card can be tampered with, this type of tampering requires skill and equipment that the typical intruder does not have. Because the card is lightweight and conveniently sized to fit into a wallet along with other essential items, it is highly portable and easy for users to carry as a matter of routine so they will have it available when needed. Additionally, because a user must enter a PIN in addition to swiping or inserting the card in a reader, if the card is lost or stolen, it still cannot be easily used by an imposter. Smart cards can even be configured to be used for authentication of both dial-up and virtual private network (VPN) remote access connections.This is done using the Extensible Authentication Protocol (EAP). Support for EAP authentication is included in Windows 2000/XP/.NET.

NOTE While smart cards have traditionally been manufactured as cards the size and shape of credit cards, they can be much smaller. Rainbow Technologies makes a smart card “token” combined with a USB reader that fits on a keychain. For more information, see www.rainbow.com/ikey/ikey1000.html.

Smart Card Interoperability A common problem that hinders the adoption of new computer technologies is the absence of standards and common models of operation.The International Organization for Standardization (ISO) seeks to solve this problem with a myriad of technologies, www.syngress.com

632


including smart cards. Companies such as MasterCard Europe (formerly Europay),Visa, MasterCard, European telecommunications firms, and major international software and hardware companies have built their products based on the ISO standards.

ISO 7816, EMV, and GSM To promote the smart card movement, the ISO took steps to ensure future interoperability among smart cards and readers by establishing the ISO 7816 standard.This standard contains detailed specifications for the devices’ operation at the physical, electrical, and data-link levels. In 1996, Europay, MasterCard, and Visa (collectively known as EMV) defined a standard based on the ISO 7816 recommendations that incorporated new data types and encoding rules developed specifically for the financial industry.The Global System for Mobile Communications (GSM) was developed by the European telecommunications industry, also based on the ISO 7816 specifications.This system allows mobile phone users to be identified and authenticated via a smart card in conjunction with a cellular phone. The ISO 7816, EMV, and GSM specifications were a vast improvement over the previously nonstandard proprietary device models, but there were still no industry standards for interfacing the readers and cards with computer programs. For this reason, little interindustry support was garnered for the cards until the Personal Computer/Smart Card (PC/SC) Workgroup was established.

The PC/SC Workgroup In May 1996, major PC and smart card companies formed the Personal Computer/ Smart Card Workgroup. Participants included Microsoft, Hewlett-Packard, Groupe Bull, Schlumberger, and Siemens Nixdorf.The group’s sole purpose is to resolve the remaining software/hardware interoperability problems that exist with ISO 7816. In December 1997, the group released version 1 of its specifications.

NOTE As of this writing, you can find the PC/SC Version 1 specifications at www.pcscworkgroup.com. All specifications regarding smart cards created by the PC/SC Workgroup are for ICC smart cards.

GlobalPlatform A cross-industry smart card standards group called GlobalPlatform has been formed to provide standards for smart cards that will be able to interoperate on a global basis.

www.syngress.com


633

There are over 50 members of the organization (including all of the major smart card vendors, such as Schlumberger and Gemplus). GlobalPlatform’s standards are based on Java-powered cards.

Microsoft’s Smart Card Support The following points summarize Microsoft’s approach to the problem of smart card interoperability: ■

A standard model enabling smart card readers and smart cards to communicate with PCs

■

Application programming interfaces (APIs) that are device independent and are used for enabling smart card-aware applications

■

Use of familiar tools for software development

■

Integration with Microsoft operating system platforms

A Standard Model for Interfacing Smart Card Readers and Cards with PCs A standard model is a set of specifications that allows software to communicate with any compliant hardware device using a common language. A hardware manufacturer has only to develop drivers that allow the device’s language to be translated into the PC’s language.This process is used by many different devices with many software components in Windows. Figure 11.1 shows how the model works logically. First, the application makes a request to the operating system (for example, “Have the modem dial 555-1234”). Next, the operating system makes a call to the device’s driver.The last step consists of the device driver performing a translation and passing the call to the device for completion. Adherence to the model will permit almost unlimited flexibility in device design while still allowing for complete interoperability.

Device-Independent APIs for Enabling Smart Card-Aware Applications The smart card Software Development Kit (SDK) is included with the Microsoft Platform SDK. Now,Windows programmers have an easy solution for supporting these devices. Because a common model is now defined, developers can create smart card solutions as easily as they create solutions for any other common PC devices.The Platform SDK can be obtained from Microsoft’s MSDN site at www.microsoft.com/ msdownload/platformsdk/sdkupdate.

www.syngress.com

634


Figure 11.1 A Logical Look at an Application Communicating with a Hardware Device

Device

Device Driver

Operation System

Application

For an application developer, three choices are available for accessing the services supported by the smart card—CryptoAPI,Win32 API, and SCard COM.The three access mechanisms vary in ease of use and capabilities.

CryptoAPI CryptoAPI is a set of tools that allows developers to integrate cryptography into their Windows 2000 or XP/.NET programs without having to actually know about the inner workings of the crypto system.With no knowledge of the cryptographic algorithms involved, a developer can create cryptographic-enabled programs that carry out the public key routines on a PC while performing private key operations on the smart card itself.This system helps reduce the security risk of rogue programs examining any computations and isolates private information from system components that do not need to know that information. CryptoAPI is also supported on Windows 9x and NT.

NOTE For more information about CryptoAPI from the developer’s point of view, see Microsoft’s MSDN Web site at http://msdn.microsoft.com/library/default.asp and search for cryptography.

www.syngress.com


635

Win32 APIs Win32 APIs are the most complicated noncryptographic interfaces to use for accessing smart card services, but they also allow developers maximum control available over a card or reader’s services.To use the APIs effectively, you need to have a broad and deep understanding of how Windows operates and how cards and readers function. If a developer needs maximum flexibility and control over how a smart card system works, the Win32 API extensions best fill the bill.

SCard COM SCard COM is a generic, noncryptographic interface implementation for accessing smart card services.The COM components are basic interface elements used to build richer and more functional services for an application.These functions can be implemented in various languages, such as C, C++, Java, and the Microsoft Visual Basic development system. In general, a developer does not need to know the specifics of how a card’s functions operate in order to use COM components.This helps speed development of Windows-based applications, saving time and money and allowing a developer to operate in an already familiar environment. Due to the nature of COM and the isolation of system components (as illustrated earlier in Figure 11.1), using this option also prevents products from becoming obsolete as soon as the technology suffers a minor change.

NOTE The Component Object Model (COM) is a component software model that is part of Microsoft’s component services. COM provides a way for developers to compile programs so that they can communicate with the operating system and applications through a standard set of interfaces. COM was introduced by Microsoft in 1993 (and Distributed COM, or DCOM, in 1996), and most Windows applications utilize COM in some manner.

Integration with Various Microsoft Platforms Microsoft is one of the participants in the PC/SC Workgroup and has accordingly implemented their solutions into its own software.Windows 2000 contains native support for smart card access and Smart Card Interactive Login by certified cards and readers.These certified cards and readers are labeled with the Windows 2000 Compatibility logo. A user can walk up to a computer and log on by inserting a card into a card reader and entering a PIN. Support for smart cards for Windows 95, 98, and NT 4 is also available without the secure logon feature. Internet Explorer 4 and later, as www.syngress.com

636


well as Outlook 98 and later, all support Secure MIME (S/MIME) communications utilizing smart cards. Microsoft’s Smart Cards for Windows, mentioned earlier, is designed to be to smart cards what PalmOS is to a PalmPilot. Smart Cards for Windows is a low-cost, easy-toprogram OS with 8K of ROM. It can run Visual Basic applications and is designed to extend the PC environment into smart card use. In addition to supporting major Visual Studio development tools, Smart Card for Windows is part of the PC/SC program.This means that any card that uses the OS will be readable by any certified Windows card reader. A drawback of Smart Card for Windows is that it currently has no native cryptographic functions.This means that all smart card manufacturers will have to implement their own security algorithms. If you are a developer interested in developing smart card-aware applications, you can still program the software that is resident on the host computer using CryptoAPI,Win32 APIs, or SCard COM.

Smart Card Components The smart card base components are the drivers and utilities that are required for smart card services to function through Windows. As of this writing, version 1 of these components has been released for Microsoft Windows 95, 98, and NT 4.They are available on Microsoft’s Web site at www.microsoft.com/security/tech/smartcards. Smart card support is built into later versions of the operating system (ME, 2000, XP, and .NET).

Service Providers Every card must have at least one service provider installed in order for Windows-based applications to access the card and use its services.The service provider is a subsystem component that provides access to specific smart card services. Depending on the type of card and the issuer, some might have multiple service providers available. In general, the following two types of service providers are available: cryptographic and standard.

Cryptographic Service Providers Acryptographic service provider (CSPs) is the component that actually performs the cryptographic algorithms used for encryption or authentication.The CSP can be either software based—such as the Windows CSP that ships standard with all Windows platforms today—or it can be a hardware solution in which the actual crypto engine resides on the smart card or other piece of hardware attached to a computer. A CSP associated with a smart card is referred to as a smart card cryptographic provider (SCCP), in order to distinguish it from a software-based CSP. Both CSPs and SCCPs expose cryptographic services through CryptoAPI, such as random number generation, key generation, key exchange, bulk encryption, and digital signatures.

www.syngress.com


637

Smart Card Service Providers Smart card service providers (SCSPs) expose the smart card services that are not cryptographic in nature.To do this, they expose interfaces similar to COM components while providing the protocols necessary to invoke the services and making assumptions regarding the context of the services. A smart card can register support for an interface by binding an association to the interface’s globally unique identifier (GUID).This binding between card and interface is done at the time the card is introduced to the system, typically when the SCSP is installed. A card service provider registers its interfaces at the time the card is introduced to the system in order to allow applications to locate smart cards based on a specific interface or GUID. For example, a cash card could make itself available to Windows applications by registering its purse scheme. As part of the Smart Card Base Components 1 release, Microsoft shipped several base-level service providers for performing generic operations on a card.The service providers were implemented as COM objects to allow developers to use them as building blocks to develop higher-level services and applications.

Cards The term smart card has been used to describe a class of credit card-sized devices with varying degrees of capabilities.The three types of smart cards are stored-value cards, contactless cards, and Integrated Circuit Cards.The latter are considered the true “smart” cards.These three types of cards differ substantially from each other and from their visually similar ancestor, the magnetic stripe card that is used for applications such as credit, debit, and automated teller machine (ATM) cards.

Stored-Value Smart Cards Stored-value smart cards are simply cards that hold information on them.These are good for providing access to buildings and computer systems that don’t require that the key be hidden from the host PC. Because the card can’t perform any complex operations, it can’t do such things as key exchange and digital signing.This means that any operations necessary for authentication or encryption have to be done by the host PC connected to the reader.This might or might not present a problem. A stored-value card’s storage capacity varies by manufacturer but generally contains only enough room to store a few digital keys. Before purchasing any smart card, be sure to contact the manufacturer and verify that the card has enough storage capacity to fit your organizational needs.The card can require a user to enter a secret PIN before access to the card is granted.This requirement is also manufacturer-specific and should be considered before you purchase the card.

www.syngress.com

638


Contactless Smart Cards Contactless smart cards perform the same function as stored-value cards but differ in that you do not have to insert them into a reader. Figure 11.2 shows a contactless smart card. An example application is a secure building’s entry. On the door frame would be a sensor slightly larger than the card itself.You would hold your card up next to the sensor, and, within a half second, it would beep and unlock the door.This method sure beats trying to find your keys in the dark! The problem with contactless cards, though, is that if you lose the card, the result is the same as if you lose your door key. Because there’s not always a keypad to enter a PIN, anyone who finds your card can use it to gain access. However, the solution to this problem (canceling a user’s smart card access) is much easier—and less expensive—than changing locks. Figure 11.2 A Contactless Smart Card

ICC Smart Cards ICC smart cards are the truly “smart” smart cards (and the term is often used more narrowly to refer only to these types of cards).They can be contact or contactless cards and can have all the functionality of stored-value cards, with the additional capability of being able to perform more complex operations involved in key exchanging and digital signing.This enables you to send secure e-mail and perform encryption operations without having to temporarily store your private key on a computer. Because the key is retained on the smart card and all the operations performed on your private key are also done on the card, there is no reason to store the key on the local PC.This prevents hackers from obtaining the key and attempting to compromise it; it also protects against rogue applications or other processes monitoring the secure transaction.Your key information is available on a need-to-know basis with regard to which system components have access to it.

www.syngress.com


639

The ICC smart card is the type of card used to devise specifications by the PC/SC Workgroup. Figure 11.3 shows a contact smart card for a digital cellular phone. Figure 11.4 shows the function of each area of the contact pad based on ISO 7816-2. Figure 11.3 A Contact ICC Smart Card

Figure 11.4 Sections of the Contact Pad for a Contact Smart Card Based on the ISO 7816-2 Standard

BEYOND ISA SERVER We have discussed various features of smart cards and seen the strengths of using them, but we have not discussed the cost of implementing a smart card system in your organization. Prices vary based on the quantity purchased, so, in estimating cost, the size of your organization is important, especially if you plan to roll out smart cards and smart card readers to the entire organization. The GemSAFE smart card presents an example of smart card costs. Gemplus (www.gemplus.com) sells the cards in packets of five for $87.50 and in packets of 50 for $837.50. The GemSAFE card supports 128-bit encryption, which is used by the domestic versions of Netscape Navigator and Internet Explorer. Smart card readers vary significantly in price, depending on whether you require internal readers, external readers, or mobile readers. Gemplus sells internal smart card readers for $62 and external smart card readers for $59. If you needed to purchase in quantity, you could arrange better pricing from Gemplus or any other smart card vendor.

www.syngress.com

640


Resource Manager The resource manager is a software component that is responsible for delegating between an application using services provided by the smart card or reader and the device itself. It runs as a trusted service in a single process.When an application needs to use a smart card or reader, the application sends a request to the resource manager, which then makes the request of the device, enabling a virtual connection between the application and the device.This system solves three basic problems in managing multiple readers and cards: ■

It enables the devices to be identified and tracked.

■

It manages the multiple readers and keeps track of their respective resources.

■

It supports a transaction-based method of accessing available services on a given card.This is important because current smart card devices are only single threaded, but some requests could take multiple commands to complete.

Figure 11.5 shows how the interaction process works between an application and a card. Figure 11.5 Interaction between a Smart Card Application and a Smart Card Reader Smart Card-Aware Application

Smart Card Service Providers Smart Card Resource Manager

www.syngress.com

PS/2 Smart Card Reader

Smart Card Reader Driver/Handler PCMCIA Smart Card Reader Smart Card (ICC)

RS-232 Smart Card Reader

Smart Card (ICC)

Smart Card Reader Driver/Handler

Smart Card (ICC)

Smart Card Reader Driver/Handler


641

Transaction-based processing is a key component in the success of messaging between a resource manager and a smart card device. If an application makes a request that consists of three commands that would normally be performed simultaneously, the request is forwarded to the resource manager for processing.When the resource manager receives the request, the request is split into three separate transactions that are completed individually. If any transaction does not fully complete, the request is returned as a failure. If the third transaction fails, the resource manager will undo whatever the first two transactions did. By returning the system to the original state, the resource manager ensures that the affected components are not corrupted.The request from the application is then returned as failed, and the application can determine whether to try again. If it elects to retry, it can do so without worrying about certain items being corrupted because of the previous failure.With transactions, either the whole request completes or the whole request fails.

Enhanced Solutions Now that you have a good idea of how smart cards came to be and how they work, you should understand how they can positively affect your network environment. Smart cards offer solutions to security concerns, such as authenticating that users on a network are who they claim to be, allowing for secure automated logins, and making it possible to send securely encrypted and digitally signed e-mail. In some states, an e-mail message signed with a digital signature is just as legally binding as a signed paper message.

NOTE For information about laws authorizing digital signatures on a state-by-state basis, along with the full text of laws, see the McBride Baker & Coles Legislative Analysis Database for E-Commerce and Digital Signatures at www.mbc.com/ ecommerce/legislative.asp.

Client Authentication Client authentication is the process of verifying an alleged user’s identity. After verification, a secure communications channel—such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS)—can be opened.These secure transport protocols are generally used in conjunction with a public key certificate.The client could be running Microsoft Internet Explorer 4 or later, and the server could be running Microsoft Internet Information Server 4 or later.This is just an example; many solutions are available to establish secure connections.

www.syngress.com

642


A secure session is established by using public key authentication with a key exchange to derive a unique session key that can be used to validate any messages sent over the connection as complete, intact, and confidential. Mapping individual users or groups to certificates with preconfigured access permissions and restrictions can further enhance security. A smart card enhances the security process in two ways. First, it allows a user’s private key to be stored securely on a card and to be accessible only to the holder of a custom PIN. Second, if the card is an ICC card, the actual key exchange can take place on the card, which further isolates the secure components from the insecure components.

Public Key Interactive Logon With Microsoft operating systems prior to Windows 2000, interactive logon entails inputting credentials into a logon screen in the form of a username and password that is then shared with other resources that require validation for access.With public key interactive logon, the process varies significantly.Windows 2000 and XP/.NET support the use of an X.509v3 certificate stored on the smart card alongside the user’s private key. Instead of a username and password, the user inserts his or her smart card and inputs the PIN into the graphical identification and authentication (GINA) system. If the PIN is correct, the user is authenticated to the card (see Figure 11.6). Figure 11.6 Windows 2000 and Smart Card Authentication

A user’s public key certificate is retrieved from a card through a secure process and is verified as a valid certificate issued from a trusted provider. During the authentication process, a challenge is issued to the card based on the public key contained within the certificate. If the card can verify that it is indeed in possession of the private key and can use the private key, the user identity contained within the certificate is used to reference the user object stored in Active Directory and to build an access token for it. The client is then issued a Ticket Granting Ticket (TGT). Public key logon has been integrated with the Microsoft implementation of Kerberos v5. In order to enable Windows 2000’s public key interactive logon feature, you need to first install a smart card reader and enable the card to store certificates.

www.syngress.com


643

Smart Card Reader Installation Smart card readers generally install via an RS-232 connection, a PC card interface, or a universal serial bus (USB).When you purchase a reader, you should look for the Windows Compatible logo. Microsoft has compiled detailed specifications on how to make a reader work optimally with Windows operating systems and grants the logo to compliant products. Please refer to the Windows Hardware Compatibility List (HCL) for the appropriate operating system for a list of currently supported readers.The HCL can be accessed at www.microsoft.com/hcl. Smart card readers should come with manufacturer instructions that describe how to install any necessary cables.To install software support in Windows for smart card readers, follow these steps: 1. Ensure that your computer is powered down. 2. Connect the smart card reader to the computer according to the manufacturer’s instructions. 3. Power up your computer and log on with Administrative privileges. 4. The Hardware Wizard automatically detects the smart card reader if it is Plug and Play compliant. Follow the instructions presented by the wizard. If prompted to do so, insert the manufacturer’s driver disk(s) and/or the Windows 2000 CD. 5. Set the Smart Card service to start automatically. Go to Start | Programs | Administrative Tools | Services, right-click the Smart Card Resource Manager, select Properties, and then choose Automatic from the Startup option. Figure 11.7 shows the service set to run automatically. 6. Click OK and reboot if prompted to do so. If the device is not automatically detected upon startup, it is either not Plug and Play compatible or not installed correctly. Consult the manufacturer’s documentation for further assistance.

www.syngress.com

644


Figure 11.7 Setting the Smart Card Service for Automatic Startup

Now that your reader is installed correctly, you can proceed to configuring the certificate parameters.Table 11.1 lists the smart cards supported by Windows 2000 Plug and Play. Table 11.1 Plug and Play Supported Smart Card Readers in Windows 2000 Smart Card Reader

Manufacturer

Device Driver

220P 3531 GCR410P GPR400 Smart TLP3 SwapSmart SwapSmart

Litronic Rainbow Technologies Gemplus Gemplus Bull CP8 SCM Microsystems SCM Microsystems

lit220p.sys rnbo3531.sys gcr410p.sys gpr400.sys bulltlp3.sys scmstcs.sys pscr.sys

Smart Card Certificate Enrollment Before a user can enroll for either type of smart card certificate supported by Windows (authentication or authentication plus e-mail), the user must have access to the certificate template stored in Microsoft’s Active Directory.This requirement exists because enrollment for smart card access needs to be a controlled procedure similar to the procedure used for obtaining an ID badge at a place of employment. Microsoft recommends www.syngress.com


645

configuring smart card certificates through the smart card enrollment station that is integrated with Certificate Services. When an enterprise certificate authority (CA) is installed, the installation includes the enrollment station.This station allows an administrator to act on behalf of a specific user and request that a certificate be installed on the user’s smart card. Because the cards themselves are partially proprietary, the station cannot offer card customization features such as building a file directory or changing a PIN.To perform these operations, consult the manufacturer’s documentation and software. Before proceeding, make sure you have set up Active Directory and added to it a CA that supports public/private key certificates. An administrator should perform the following procedures: 1. To connect to a CA, open Internet Explorer and type http://<machinename>/certsrv into the Address bar. Be sure to replace <machine-name> with the computer name of the issuing CA. 2. The Microsoft Certificate Service Welcome page appears, as shown in Figure 11.8. Select Request a certificate, and then click Next to continue. Figure 11.8 The Welcome Screen for Microsoft Certificate Services

3. Select Advanced request from the Choose Request Type page shown in Figure 11.9, and click Next. 4. Select Request a certificate for a smart card on behalf of another user using the Smart Card Enrollment Station from the Advanced Certificate Requests page, and click Next as shown in Figure 11.10. www.syngress.com

646


Figure 11.9 Choosing a Request Type

Figure 11.10 Advanced Certificate Requests

5. The first time you use the enrollment station, a digitally signed ActiveX control is downloaded from the CA to the station computer.To use the station, select Yes from the Security Warning dialog box to install the control.

www.syngress.com


647

6. Five items need to be completed on the Smart Card Enrollment Station page before you submit the request: ■

You can choose from several certification templates. For smart card use, you are concerned with only two of these—Smart Card Logon and Smart Card User. Remember that the Smart Card Logon template is for access to public key interactive logon, and the Smart Card User template is for both logon and user authentication through e-mail.

■

Select a certification authority.

■

Select a cryptographic service provider.

■

Select an administrator signing certificate.

■

Select a user by clicking Select User.

7. You are now ready to submit the certificate request, as shown in Figure 11.11. Click Enroll on the Smart Card Enrollment Station page. Figure 11.11 Smart Card Enrollment Station

8. If the card is not already inserted into the reader, you will be requested to insert it. Insert the card and click OK. 9. The request must be digitally signed by the private key that corresponds to the public key included in the certificate request. Because the key is stored on the card, the signature requires that the card owner verify the PIN and prove ownership of both the card and the key.Type the default PIN for the card. You can change the PIN at this point. Instead of clicking OK, click the

www.syngress.com

648


Change button, as shown in Figure 11.12. Enter the new, personalized PIN and click OK. Figure 11.12 Enter or Change a PIN

NOTE Each smart card vendor uses a different default PIN. Consult the documentation or contact the vendor.

10. If the CA successfully processes the certificate request, the station informs you that the smart card is ready.You can now either view the certificate by clicking View Certificate or you can specify a new user by clicking New User.

Smart Card Logon Logging on with a smart card is a relatively simple and straightforward task. At a PC that has smart card logon enabled, perform these steps: 1. You will see a logon screen that states “Insert card or press Ctrl-Alt-Delete to begin,” as shown earlier in Figure 11.6. Insert your card into the smart card reader. 2. The Log On to Windows dialog box prompts you to enter your PIN. Enter it. 3. You are now logged on.To lock a workstation without logging off, press Ctrl-Alt-Delete and select Lock Workstation.To unlock it with a smart card, simply insert your card and enter your PIN.

Secure E-Mail Secure e-mail is one of the most exciting aspects of public key technology. Secure e-mail allows you to finally put that envelope over your letter and superglue it shut, virtually speaking. Secure e-mail works like this:

www.syngress.com


649

1. The sender composes a message in a public key-aware messaging application, such as Microsoft Outlook Express or Microsoft Outlook 98/2000/2002. 2. The sender retrieves the recipient’s public key certificates from a trusted security provider and uses them with his or her own private key to digitally sign and encrypt the message. 3. The message is sent to the recipient over the network. 4. Upon receipt of the message, the recipient uses his or her private key to verify and decrypt the message.This is the only way an encrypted message can be opened other than by forcibly hacking your way into it. 5. The recipient’s private key analyzes the data stored in the message to determine whether it has been tampered with in transit. It also compares the data with the sender’s public key.This allows the recipient to verify the authenticity of the message and to be sure that it was not forged. In a process similar to the one used in the public key interactive logon, the smart card adds the same amount of security to the e-mail process.The key is the sole possessor of the private key and, depending on the card type, the sole processor of any data destined to it, thereby reducing the private key’s exposure to insecure systems. With all this talk of secure e-mail and messaging and encryption, you might be wondering how secure an e-mail message must be to be considered secure.That depends on your definition of the term secure. Not too long ago, 64-bit encryption was thought to be very secure.This security has recently been broken by an organization that enables users worldwide to have access to some computer processor time over the Internet. (For more information, visit hwww.distributed.net.) Using brute-force hacking, a hacker has a possibility of 256 combinations. Now, everyone considers 128-bit to be secure.When you determine an optimal level of security, you must consider the technology factor of today and what it will be 10 years from now. If you encode a 128-bit message that is intercepted, chances are that by the time it is decoded, it will no longer matter. In the case of something more long-term—such as financial records—if you work for an organization that archives its records each year and you encrypt the records with 128-bit protection, it is difficult to plan for a future in which a hacker could get hold of your file with a multigigahertz quadruple-processor computer with a terabyte of RAM.We don’t know where technology is going, so we need to remain constantly alert and plan ahead.

www.syngress.com

650


Summary This chapter introduces the basics of smart card theory and examines the interoperability issues involving smart cards in the present, past, and future with the ISO 7816, EMV, GSA, and PC/SC specifications. Microsoft’s vision of the future of smart cards is evident in its products and services and the methods of implementing card services through CryptoAPI,Win32 API, and SCard COM. Finally, this chapter examines what makes smart cards so practical and realistic for today’s use by reviewing public key interactive logon, client authentication, and secure e-mail, and how to configure Windows 2000 to use smart cards for authentication and secure email. We are at the dawn of a new information-based age.To protect ourselves from the side effects of all this information being transmitted over public networks, we need new ways to secure our data.The smart card will play an important role in further enhancing information security, both now and in the future.

Defensive Tactics Fast Track Understanding Smart Card Technology ; Smart cards contain an integrated circuit embedded in the card (this is the

reason they are sometimes also called ICCs, or Integrated Circuit Cards) that is a miniature, dedicated computer running an operating system designed for this purpose. ; Because you must have the card in your physical possession (something you

have), and because smart cards are always used in conjunction with a PIN (something you know), they provide multifaceted security. ; Smart cards offer many advantages as an authentication method, including

portability, integration into the PKI, tamper-resistance, and greater public acceptance than more intrusive authentication methods, such as biometrics.

Smart Card Interoperability ; The Personal Computer/Smart Card Workgroup resolved the software-

hardware interoperability problems with ISO 7816. ; CryptoAPI allows developers to use cryptography in Windows 2000 without

having to know about its inner workings. CryptoAPI is supported on Windows 9x and NT 4.

www.syngress.com


651

; The Win32 APIs allow you to have maximum control over a card or reader’s

services. ; SCard COM is a generic noncryptographic interface implementation for

accessing smart cards that prevents products from becoming obsolete as technology changes. ; Windows 2000 supports smart card access and Smart Card Interactive Login.

Smart Card Components ; Every card must have at least one service provider installed.The two types of

service providers are cryptographic and standard. ; Cryptographic service providers (CSPs) can be either software based or

hardware based. ; Smart card service providers (SCSPs) expose the noncryptographic services. ; The three types of cards that are referred to as smart cards are stored-value

cards, contactless cards, and Integrated Circuit Cards (ICCs). ; Stored-value smart cards are cards that hold information but cannot perform

complex operations, such as digital signing.These cards must be inserted into a reader to be used. ; Contactless smart cards work the same way as stored-value cards except that

they do not have to be inserted into a reader. ; ICCs can be contact or contactless and can perform complex operations, such

as key exchanging and digital signing.

Enhanced Solutions ; Client authentication is the process of verifying a user’s identity. ; Smart cards enhance security by storing a user’s private key on a card that is

protected with a PIN code and allowing the key exchange to take place on the card. ; You must first install a smart card reader and enable the card to store

certificates before you can enable public key interactive logon. ; You should always check the Windows HCL before purchasing and installing

reader hardware to ensure that your readers are currently supported.

www.syngress.com

652



Q: What is Microsoft’s smart card strategy? A: Microsoft ensures that the Microsoft Windows platform is ready for use by smart cards and readers, thereby allowing developers to create products based on standard APIs and tools.

Q: Will Microsoft support smart card logon on older operating system platforms (Windows 9x and NT)?

A: No. Currently, Microsoft will support smart card logon only in Windows 2000 and XP/.NET.

Q: What are the main differences between CryptoAPI,Win32 API, and SCard COM? A: CryptoAPI is an interface for utilizing cryptographic functions, such as digital signing and encryption. For this reason, it is a regulated export item.The other two interfaces are noncryptographic in nature.Win32 APIs allow a developer rigid control over the operation of smart cards and readers but require a broad understanding of Windows and smart card operations. SCard COM allows a developer to perform basic generic functions without a thorough knowledge of Windows or smart cards.

Q: How does smart card logon work in Windows 2000? A: Windows 2000 uses the PKINIT protocol for public key, which is an extension to Kerberos v5.This allows an authorized user to insert a card in a reader, authenticate to the card, and use a certificate/private key to authenticate to the Microsoft Windows Active Directory. An authenticated user is then provided with a Kerberos ticket, and the user can use the ticket to access resources in the domain.

Q: What brands of smart cards are supported by default in Windows 2000? A: Out of the box,Windows 2000 supports the Gemplus GemSAFE card (www.gemplus.com) and the Schlumberger Cryptoflex card (www.cryptoflex.com).

www.syngress.com


653

Q: I am trying to use my Gemplus GemSAFE card, but I have forgotten the default PIN code.What is it?

A: The default PIN code for GemSAFE cards is 1234. Q: I am trying to use my Schlumberger Cryptoflex card, but I have forgotten the default PIN code.What is it?

A: The default PIN code for Cryptoflex cards is 00000000 (eight zeros). Q: Why is there a default PIN assigned and why would I use it? A: A PIN is required for smart card logon. Smart card vendors thus provide a default PIN to be used in setting up new cards. Administrators can use the default PIN to enter initial data on a bulk basis.The PIN for each card will then be changed to one that is unique to the holder of the card, for security purposes.When the brand new card is inserted into the reader/coupler using the Windows 2000 smart card enrollment station, after the Administrator types in the default PIN, there is a button on the dialog box labeled “Change” that allows you to set a new, personalized PIN for the card.

www.syngress.com


Chapter 12

Creating a Public Key Infrastructure with Certificate Services Defensive Tactics in this Chapter: ■

PKI Concepts

■

Windows 2000 PKI Components

■

Certification Authorities

■

Installing a Windows 2000 PKI

■

Enabling Domain Clients

■

Public Key Security Policy in Windows 2000

■

Applications Overview

■

Preparing to Implement the Windows 2000 PKI

■

Backing Up and Restoring Certificate Services


656

Chapter 12 • Creating a Public Key Infrastructure with Certificate Services

Introduction Almost all organizations today rely on networks to access information.These networks can range from internal networks to the Internet. Access to information is needed, and this access must be configured to provide information to entities that request it. For example, when you need to make a purchase, you can quickly check out vendors’ prices through their Web pages. Likewise, in order to deter the competition from gaining an advantage over your organization, you must establish your own Web pages for advertising and ordering purposes. Furthermore, within an organizational structure, many sites might exist across the country or around the globe. If corporate data is available immediately to employees, much time can be saved. In the corporate world, time savings equates to money savings. But how can you exchange information efficiently and effectively while maintaining the security essential in today’s world? A major problem for any network administrator is how to ensure that those who need access can get it readily and conveniently, while those who should not view specific information are denied access. One of the most important elements of security is to determine “who’s who”—that is, once you’ve taken steps to grant or deny access to specific entities, you need to ensure that those seeking access are who they claim to be. By impersonating an authorized user, an unauthorized user can access information to which he or she has no right. Let’s take a look at how identity verification is handled in the world outside computers. If a customer presents a personal check to pay for merchandise, how does a merchant determine whether the customer is the legitimate owner of the bank account and not someone forging someone else’s name on the check? Generally, the merchant requires some sort of verification of identity, such as a driver’s license or state ID card. These documents are issued by a trusted third party, such as the Department of Motor Vehicles.The idea is that the DMV checked out the person’s identity and would not have issued the document unless the identity was proven, so the merchant can rely on, or trust, the DMV’s judgment in issuing the license. Now, let’s carry the concept over to computer networking. Here, we have trusted third parties called certification authorities (CAs) that issue documents called certificates to validate the identities of people who purchase or use the certificates (the process of verifying identities can be very rigorous or somewhat looser, depending on the CA). Now other users and computers can rely on the certificates, thereby avoiding the process of verifying the identity of everyone who requests access. (Of course, just as it’s possible for a criminal to obtain a false driver’s license or ID card, the certificate system is not foolproof, either, but it does provide an extra measure of security.) A CA can be public, operating on the Internet (analogous to our example of a government-issued ID), or it can be private, set up within an organization (which would be more like the employee ID cards issued by a company). www.syngress.com

Creating a Public Key Infrastructure with Certificate Services • Chapter 12

657

This system is based on the use of public-private key pairs (discussed in Chapters 9 and 10). Public key cryptography provides a high degree of security; the problem is effectively managing the keys and, in this case, the issuance and revocation of the certificates based on them. For example, there must be a way to ensure that public keys are readily available to everyone, a way to distribute the “news” when a certificate is revoked, and so forth.The public key infrastructure (PKI) encompasses the management of digital certificates and public keys. In this chapter, we delve into the concepts of how the public key infrastructure works. Further, we discuss the specifics of setting up and administering a PKI based on the built-in Certificate Services included with Microsoft’s Windows 2000 Server operating systems (at the time of this writing, the next generation of Windows Server— Windows .NET—has not yet been released but also includes CA capability and is configured similarly).

PKI Concepts The rapid growth of Internet use has given rise to new security concerns. Any company that does not configure a strong security infrastructure is literally putting the company at risk. If security is lax, an unscrupulous person could steal data or modify business information in a way that could result in major financial disaster.To protect an organization’s information, the possibility of forged identity or a “middleman” must be eliminated. Cryptographic technologies provide a way to identify both users and servers during network use.

Public Key Cryptography As discussed in previous chapters, encryption is the process of changing a clear text message into an unreadable form to protect sensitive data.The transformation from the scrambled form, known as ciphertext, back to clear text (or plaintext) is called decryption. Cryptography can be dated back to around 2000 B.C. in ancient Egypt.Through time and civilizations, ciphering text played an important role in wars and politics. As modern times provided new communication methods, scrambling information became increasingly more important.World War II brought about the first use of the computer in the cracking of Germany’s Enigma code. In 1952, President Truman created the National Security Agency (NSA) at Fort Meade, Maryland.This agency, which is the center of U.S. cryptographic activity, fulfills the following two important national functions: It protects all military and executive communication from being intercepted, and it intercepts and unscrambles messages sent by other countries.

www.syngress.com

658


Three types of cryptographic functions exist.The hash function uses a mathematical algorithm on data in order to produce a fixed-length result. Hashing is used to encrypt and decrypt digital signatures for authentication.The secret key method of encryption, which involves the use of a single key, is used to encrypt and decrypt the information to provide confidentiality and is sometimes referred to as symmetric key cryptography.This key, of course, must be shared between the sender and recipient. An example of secret key encryption is the decoder ring you may have had as a child. Any person who obtained your decoder ring could read your “secret” information. Basically, two types of symmetric algorithms are available—block and stream. Block symmetric algorithms work by operating on a given length of bits known as blocks. Stream symmetric algorithms operate on a single bit at a time. One well-known block algorithm is Data Encryption Standard (DES).Windows 2000 uses a modified form of DES and performs the operation on 64-bit blocks, using every eighth bit for parity.The resulting ciphertext is the same length as the original cleartext. For export purposes the DES is also available with a 40-bit key. One advantage of secret key encryption is the efficiency with which it takes a large amount of data and encrypts it rapidly. Symmetric algorithms can also be easily implemented at the hardware level.The major disadvantage of secret key encryption is that a single key is used for both encryption and decryption.Thus, there must be a secure way for the two parties to exchange the one secret key. In the 1970s, a more secure encryption method became available through the mathematical implementation of public key encryption. Public key encryption, also referred to as asymmetric cryptography, replaced the one shared key with a mathematically related pair of keys for each user.The pair consists of a public key and a private key.The public key is made available to everyone and is used for the encryption process only. The private key is available only to the owner.The private key cannot be duplicated as a result of the public key being available. Any data that is encrypted by a public key can be decrypted only by using the private key that belongs to the pair. It is also possible for the owner to use a private key to encrypt sensitive information. If data is encrypted by using a private key, the public key in the pair of keys is needed to decrypt the data. This authenticates the sender’s identity. A public key is available to everyone, so a secure key exchange channel isn’t needed. Users who want to communicate retrieve each other’s public keys and use the public key of the intended recipient to encrypt data sent to that recipient. In Microsoft’s implementation of public key cryptography,Windows 2000 stores all public keys in Active Directory and all private keys on the user’s local machine. Figure 12.1 shows the encryption process using a receiver’s public key. In the figure, Bob wants to send Alice a file that is encrypted so only she can access it. Bob encrypts the file with Alice’s public key.The encrypted file is sent to Alice. She uses her private

www.syngress.com


659

key to decrypt the file. As long as Alice’s private key is protected, then the encrypted data is also protected. Figure 12.1 Encrypting Data Using Public Key Encryption

Bob

Retrieves Alice’s Public Key

Domain Controller (Active Directory)

Data Alice’s Public Key

Alice’s Public Key

Encrypted Data

Bob’s Computer

Alice’s Computer Alice’s Private Key

Bob’s Private Key Decrypted Data

Public key cryptography can do everything that secret key cryptography can do, but it does it at a slower pace.To work around public key encryption’s performance problem, designers often incorporate the public key and secret key encryption methods together.The designers of Windows 2000 did just that. Data that requires a fast encryption method is handled by secret key encryption, while the encryption of the secret key itself is handled by public key cryptography.Windows 2000 designers know that public key encryption is slow, but, because the secret key is small, using public key encryption does not have a significant performance impact on the overall process.

Public Key Functionality Public key cryptography brings major security technologies to desktops in the Windows 2000 environment.With Windows 2000, the network provides the capability to allow users to safely do the following: ■

Transmit over insecure channels via IPSec

■

Store sensitive information on commonly used media via Encrypting File System (EFS)

■

Verify a person’s identity for authentication www.syngress.com

660

Chapter 12 • Creating a Public Key Infrastructure with Certificate Services ■

Prove that a message was generated by a particular person

■

Prove that a received message was not tampered with in transit

Algorithms based on public keys can be used for all these purposes.The most popular public key algorithm is the standard RSA, which is named after its three inventors—Rivest, Shamir, and Adleman.The RSA algorithm is based on two prime numbers with more than 200 digits each. A hacker would have to take the ciphertext and the public key and factor the product of the two primes. As computer processing times increase, the RSA remains secure by increasing the key length, unlike the DES algorithm, which has a fixed key length.

BEYOND ISA SERVER No encryption algorithm is actually unbreakable given enough time and processing power to do the job. What makes an algorithm effectively unbreakable is when it is so complex that the time required to break it is impractical. For example, an algorithm that would take the fastest current computer 100 years to crack could be considered effectively unbreakable. Note that technology futurists expect that eventually researchers will develop a working quantum computer, which would be based on physics as they work at the atomic level. These machines would be able to work with units of information called qubits instead of the bits that present digital computers process, because a qubit can exist in multiple states simultaneously (as opposed to the 0 or 1 of a bit). The practical effect is that quantum computers would be incredibly powerful and fast compared to today’s systems. A quantum computer could use a method called quantum superposition to factor extremely large numbers such as 10200 in only a few seconds. Because RSA depends on the immense difficulty and time required to factor huge numbers into their primes, a quantum computer would render it—and other encryption algorithms in use today—useless.

Public key algorithms provide privacy, authentication, and easy key management, but they encrypt and decrypt data slowly because of the intensive computation required. RSA has been evaluated to be anywhere from 10 to 10,000 times slower than DES in some environments, which is a good reason not to use public key algorithms for bulk encryption.

Digital Signatures When information is sent electronically, no human contact is involved.This makes it easier for a person to “forge” someone else’s identity, making it appear that the communication originated from someone other than the actual sender.The receiver wants to www.syngress.com


661

know that the person listed as the sender is really the sender and that the information received has not been modified in any way during transit.That’s where digital signatures come into play. A hash algorithm is implemented to guarantee Windows 2000 users that data is authentic.This hash value encrypted with a private key is called the digital signature. Anyone with access to the corresponding public key can verify the authenticity of a digital signature. Only a person with a private key can generate digital signatures. Any modification makes a digital signature invalid. The purpose of a digital signature is to prevent changes within a document from going unnoticed and also to verify the identity of the person who claims to be the original author.The document itself is not encrypted—there is no confidentiality of the data.The digital signature is just data sent along with the message guaranteed to be untampered with. A change of any size invalidates the digital signature. The concept of validating correspondence predates computers.When King Henry II had to send a message to his troops in a remote location, the letter would be sealed with wax, and, while the wax was still soft, the king would use his ring to make an impression in it. If the seal was never broken during transit, the recipient could be assured that no modification had been made to the original message. An unbroken seal meant that King Henry II had initiated the message, because he was the only person possessing a ring that matched the waxed imprint. Digital signatures work in a similar fashion, in that only the sender’s public key, and no one else’s, can authenticate both the identity of the sender and the content of the document. A digital signature is generated by a message digest, which is a number generated by taking the message and applying a hash algorithm. A message digest is regarded as a digital fingerprint and generally ranges from a 128-bit number to a 256-bit number. A hash function takes variable-length input and produces a fixed-length output.The message is first processed with a hash function to produce a message digest.This value is then signed by the sender’s private key, which produces the actual digital signature.The digital signature is then added to the end of the document and sent to the receiver along with the document. Because the mere presence of a digital signature proves nothing by itself, verification must be mathematically proven. In the verification process, the first step is to use the corresponding public key to decrypt the digital signature.The result produces a 128-bit number.The original message is processed with the same hash function used earlier and will result in a message digest.The two resulting 128-bit numbers are then compared, and if they are identical, the signature is valid. If a single character has been altered, the two 128-bit numbers will be different, indicating that a change has been made to the document. Figure 12.2 illustrates the generation of a digital signature.The original message is processed with a mathematical function to generate a message digest.The sender’s private key is used to encrypt the message digest, and the final result is a digital signature. www.syngress.com

662


Figure 12.2 Generating a Digital Signature Message Message Digest Hash Function + Message

128-Bit Number

Encryption Private Key + Message Digest

Digital Signature

Authentication As shown, public key cryptography can provide authentication instead of privacy. In Windows 2000, a challenge is sent by the receiver of the information.The information is authenticated because only the corresponding private key could have encrypted the information that the public key is successfully decrypting.The challenge can be implemented in one of two ways. In the first authentication method, a challenge to authenticate involves sending an encrypted challenge to the sender of the original message.The challenge is encrypted by the receiver, using the sender’s public key. Only the corresponding private key can successfully decode the challenge.When the challenge is decoded, the sender sends the plaintext back to the receiver.This is the proof for the receiver that the sender is truly the sender. For example, when Alice receives a document from Bob, she wants to authenticate that the sender is really Bob. She sends an encrypted challenge to Bob, using his public key.When he receives the challenge, Bob uses his private key to decrypt the information.The decrypted challenge is then sent back to Alice.When Alice receives the decrypted challenge, she is convinced that the document she received is truly from Bob because no one else would have his private key to decrypt the challenge. The second authentication method uses a challenge that is sent in plaintext.The receiver, after receiving the document, sends a challenge in plaintext to the sender.The sender receives the plaintext challenge and adds some information before adding a digital signature. The digital signature is generated by using a hash function and then encrypting the result with a private key.The challenge and digital signature now are sent back to the receiver.The receiver must use the sender’s public key to verify the digital signature. If the signature is good, the original document and sender have at this point been verified mathematically. Figure 12.3 uses Alice and Bob to demonstrate the plaintext challenge.

www.syngress.com


663

Figure 12.3 Plaintext Authentication Challenge 1. Bob’s document

Bob

2. Alice’s plaintext challenge 3. Bob digitally signs the challenge after adding some information

Alice

4. Alice uses Bob’s public key to verify the digital signature

This type of authentication is referred to as proof of possession. The sender must prove he is who he says he is by possessing the corresponding private key.The challenge process is always started by the receiver of the document.The document itself is never encrypted in this authentication process.

Secret Key Agreement via Public Key You’ll recall that one of the primary drawbacks of symmetric cryptography is the problem of agreeing upon or exchanging shared secret keys.Yet sometimes using this faster encryption method is desirable.The PKI of Windows 2000 provides a way for two parties to agree on a secret key while they use nonsecure communication channels. Each party generates half the shared secret key by generating a random number, which is sent to the other party after being encrypted with the other party’s public key. Each receiving side then decrypts the ciphertext using a private key, which will result in the missing half of the secret key. By combining both random numbers, each party will have an agreed-upon shared secret key, which can then be used for secure communication even though the secret key was first obtained through a nonsecure communication channel.

Bulk Data Encryption without Prior Shared Secrets A major feature of public key technology is that it can encrypt bulk data without generating a shared secret key first.The biggest disadvantage of using asymmetric algorithms for encryption is the slowness of the overall process, which results from the necessary intense computations; the largest disadvantage of using symmetric algorithms for encryption of bulk data is the need for a secure communication channel for exchanging the secret key.The Windows 2000 operating system combines symmetric

www.syngress.com

664


and asymmetric algorithms to benefit from the best of both worlds and provide both high security and high performance. For a large document that must be kept secret, because secret key encryption is the quickest method to use for bulk data, a session key is used to encrypt the document.To protect the session key (which is the secret key needed to decrypt the protected data), the sender quickly encrypts this small item by using the receiver’s public key.This encryption of the session key is handled by asymmetric algorithms, which use intense computation but do not require much time in this case, due to the small size of the session key.The document, along with the encrypted session key, is then sent to the receiver. Only the intended receiver will possess the correct private key to decode the session key, which is needed to decode the actual document.When the session key has been decrypted, it can then be applied to the ciphertext of the bulk data, and then it can transform the bulk data back to plaintext.

Protecting and Trusting Cryptographic Keys As discussed, when secret key cryptography is implemented, both the sender and the receiver share a key, which they must protect and keep private. In some secure fashion, both parties have agreed upon and exchanged this single key, which is used to encrypt and decrypt the data the two parties want to keep secure. In contrast to secret key cryptography, public key cryptography does not protect all the involved keys. In public key cryptography, only the private keys are protected; the public keys are shared by the act of publishing them. Because the public key is not protected, in any PKI, the sender must be provided with a means to ensure that the relationship between the public key and its entity (the person or computer to whom it is purported to belong) is trustworthy. Unlike with secret key cryptography, in which the single key is exchanged by some secure contrived plan, the public key is freely available without passing any security checkpoints.The public key’s availability for public use limits security implementation in protecting it. Because public keys are not surrounded by any security measures, some mechanism is needed to ensure that the public key being used is really the entity’s public key.That’s where digital certificates come in.

Certificates Certificates are used to provide the assurance that the public key being used does in fact belong to the entity that owns the corresponding private key. A certificate is a digitally signed statement by its issuer that affirms the validity of both the public key and the subject’s identity information.The certificate is the user’s guarantee that the public key really belongs to the entity claiming it, and that entity has the corresponding private key.

www.syngress.com


665

The certificate contains the public key itself and a complete set of attributes.These attributes might include information about the holder’s identity, what the holder is allowed to do, and under what circumstances the certificate is valid (including an expiration date).The digital signature of the issuing entity (the CA) ties the attributes and the public key together on the certificate.The issuer’s signature on the certificate is in effect the guarantee of authenticity. Another real-world example of a certificate-like document is a passport. All passports contain a unique key—the registered passport number from the issuing government. Also included on every passport are the passport holder’s full name, date of birth, place of birth, the date of issue, and the expiration date. U.S. passports are issued by the federal government and require a photo identification on the laminated information page. Any country that has agreed to accept these passports trusts that the information on the document is true as long as the passport does not seem to have been illegally altered.This means that countries are relying on the passport’s authenticity, just as the user of a public key relies on the issuer’s certificate.

NOTE The PKI of Windows 2000 supports the International Telecommunication Union (ITU)-T X.509 version 3 standard for certificate creation. This X.509v3 standard defines the format and content of digital certificates. The use of a standard for certificate creation allows the exchange of certificates between vendors and ensures true interoperability.

Certification Authorities Digital certificates provide a way to validate public keys. By definition, the issuer of a Public Key Certificate is known as a certification authority. Certification authorities are responsible for validating the identity of a person or organization and for joining that entity with a key pair.The certification authority stores the public key and maintains the list of certificates that have been issued. Certification authorities vary greatly in scope of authority. At one end of the spectrum are commercial certification authorities—such as VeriSign and GTE CyberTrust— which issue millions of certificates. At the opposite end of the spectrum are departmental certificate authorities within organizations that issue only a small number of certificates. Many certification authorities issue certificates to other certification authorities.Their own certificates are in turn issued and signed by a higher-level certificate authority, which can be inside or outside the organization.This is known as a CA hierarchy. The administrator of each certification authority can decide what attributes will be included in the certificates it creates and also what method of verification it will www.syngress.com

666


implement at the time of creation. Every certification authority has the responsibility to issue a certificate revocation list (CRL) containing any certificate that has been revoked.The CRL is published, so clients can check the list before any authentication request is approved. Figure 12.4 shows the Windows 2000 interface for identifying information that is used by the certification authority in every certificate it creates and also in identifying all certificates that belong to it. Figure 12.4 Certificate Identification Information

Certification Authority Types The certification authority provides the validation of the entity belonging to the public key, so the administrator of a Microsoft network on which internal CAs operate must understand the four types of certification authorities that are included with the Microsoft Certificate Service. The Enterprise Root certification authority is at the top of the PKI in a Windows network. Active Directory is used to verify a certificate requester’s identity. Because it is at the top of the PKI, the Enterprise Root certification authority will sign its own CA certificate and then publish that certificate to every Trusted Root certification authority on the network. An Enterprise Root certification authority can use predefined certificate templates for issuing and requesting certificates.When it uses certificate templates, the Enterprise Root certification authority can verify user credentials during the certificate enrollment. Each template has an access control list that is evaluated at the time the user makes a certificate request in order to determine if the requester is in fact authorized to receive the template. An example of a template is one created for a smart card logon certificate.

www.syngress.com


667

NOTE The Enterprise Root certification authority can be used to issue certificates directly to a user, but it is generally used only to authenticate the Enterprise subordinate certificate authorities. The Enterprise Root certification authority is integrated with Active Directory, which helps simplify the issuing and revoking of certificates.

The Enterprise subordinate certification authorities are available in two types— intermediate or issuing certificate authorities. All certification authorities can issue certificates, but the recommended best practice is to use the issuing certificate subordinate certification authorities to issue certificates.The issuing certificate authorities issue, directly to users, certificates that will support client services, such as smart card logons, the Encrypting File System, and IP security.The intermediate certification authority’s job is not to issue such user certificates but to generate a certificate for issuing certification authority validation and to provide a link in the chain back to the root certification authority. If the Enterprise Root certification authority itself signed its own certificate, the subordinate certification authority gets its certificate from another certification authority.The advantage of this is that if subordinate certificate authority is compromised, its own certificate from the root can be revoked, thus revoking all the certificates it has issued.

BEYOND ISA SERVER For greater security of the root CA, you can keep it offline (disconnected from the network) and secure its signing key using hardware security. You can keep the subordinate CA online all the time, while removing the root CA from the network and securing it. The root would be brought online only to perform tasks related to subordinate CAs and CRLs. This keeps the root CA, which is the most important in the hierarchy because it issues certificates to other CAs, less vulnerable to compromise. Microsoft recommends that root CAs never be used to issue certificates to users or computers. Instead, you should set up a CA hierarchy with at least three levels, as discussed in this chapter (root, intermediate and issuer CAs). For more information about installing a Windows 2000 offline root CA, see the Microsoft Knowledge Base article Q271386 on the Microsoft Web site at www.tut.fi/public/hstya/information/Installing%20a%20Windows%202000% 20Certificate%20Services%20Offline%20Root%20CA.htm.

www.syngress.com

668


Not all Windows 2000 environments use Active Directory, and this generates the need for the other two types of certification authorities.When the network environment does not have Active Directory services or the CA is not a member in a Windows 2000 domain, the certification authorities are referred to as standalone certification authorities.The Standalone Root is at the very top of the certificate structure, but the Standalone subordinate certification authorities can be intermediate or issuing certificate authorities, much as in the Enterprise environment. When the root certification authority is determined, you must decide on the type of certification authority to use as a subordinate.The common practice is to make the subordinate certification authority of the same type as its root certification authority. After you determine the use of the Enterprise or standalone certification authority, you must define each certification authority’s function and role.The administrator defines the primary role of the certification authority and the type of certificate it can issue, and the administrator also specifies the users who can receive each certificate type.

Trust and Validation When a recipient receives a signed message, the signature can be validated through the use of the sender’s public key and a mathematical process.The recipient must be sure that the public key truly belongs to the sender; if Bob was the sender, Alice needs proof that she received Bob’s public key. This is where the certification authority enters the validation process, providing the proof the recipient is looking for in the public key that was used. Recipients will look for a certificate for the sender’s public key in a certification authority they implicitly trust.They need to know that a certificate: ■

Was issued by a trusted issuer

■

Assures a binding relationship between the sender and the sender’s public key

■

Includes a valid signature from its issuer

The recipient uses the public key of the issuing certification authority to verify the certificate.The recipient needs to be sure that the public key of the certification authority used to verify the sender’s public key is not an impersonator.This chain reaction of verifying the verifier continues up the certification authority hierarchical structure. In the final step, a certificate issued to some certification authority that the recipient implicitly trusts is used.This certificate, which does not require authentication, is known as a Trusted Root certificate, because it is at the very top of a hierarchy of key-identity bindings accepted as truthful.When the certification authority hierarchy is created, a parent-child relationship is established. A user who trusts a particular root certificate implicitly trusts all the certificates issued by the root and its subordinate certification authorities. www.syngress.com


669

Figure 12.5 shows the Certificates snap-in of the Microsoft Management Console. The left pane breaks down the user certification authorities into five different groupings.The Trusted Root certification authorities object has been expanded, and the list of Trusted Root certification authorities is displayed in the right pane. From this interface, a user can add or remove a Trusted Root certification authority. Figure 12.5 The Certificates Snap-In of the MMC

Certification authorities form a hierarchy that can be called the trust chain. Each member in the chain has a signed certificate held by a superior authority.The root certification authority is trusted by everyone, and its private key is unknown to anyone. A recipient of a document will go up the chain until a trusted certification authority is located. As a result, each subordinate certification authority’s public key is identified by its issuing superior certification authority. As we discuss later in the chapter, certificates can be revoked when necessary.When this happens, a CA publishes a certificate revocation list, so other entities will know that the certificate can no longer be trusted.

Windows 2000 PKI Components To protect your organization’s network when it is connected to the Internet, you must use cryptographic technologies to create a secure infrastructure. Microsoft built a comprehensive PKI into the Windows 2000 operating system.The PKI is designed to take full advantage of the Windows 2000 security architecture, and, through public key cryptography, digital certificates, and certification authorities, it provides a flexible, secure infrastructure that is easy to use. A PKI is a defined set of operating system and application services that makes the use of public key cryptography a seamless process.The PKI does not in any way replace www.syngress.com

670


or override the domain trust and authorization process based on the domain controller and Kerberos Key Distribution Center, but rather it enhances scalability. Because security is based on key use, a PKI must give the administrator the capability to create and issue new keys as well as the capability to revoke existing keys.The PKI must provide a client with a way to locate and retrieve a needed public key without any additional effort.When these two capabilities are in place, the application programmers can build even more secure applications. The PKI is not a single item; it is a collection of various components that work together to allow public cryptography to occur and at the same time are transparent to clients. Operating systems provide numerous infrastructures, and PKI is one of the infrastructures that is included in the Windows 2000 operating system. Figure 12.6 shows the components of the Windows 2000 PKI.The client machine is the focal point for all other components. In this view, the components are identified but are not reflected on any physical piece of hardware. Figure 12.6 Components of the Windows 2000 PKI Active Directory

Domain Controller/ Kerberos Domain Controller

Domain Logon

Policy Distribution, Certificates Publication

Client Computer

Certificate Services

Certificate Enrollment and Revocation

At the base of the Windows 2000 PKI is the Microsoft Cryptographic API, which provides the two major services for public key security—a certificate management service and a cryptographic service.The certificate management service is responsible for X.509 version 3 digital certificates.The cryptographic service is responsible for key generation, message hashing, digital signatures, and encryption.The Microsoft Cryptographic API makes available any installable cryptographic service providers (CSPs). As Figure 12.7 shows, other services can benefit from using the Microsoft Cryptographic API to provide even more functionality for developers.

www.syngress.com


671

Figure 12.7 Services That Benefit from the Cryptographic API Authenticode

SmartCard Service Secure Channel

CRYPTOAPI Certificate Management Service Cryptographic Service

Certificate Service Exchange KM Encrypting File System

Certificate Service Provider

Certification Authorities As mentioned earlier, the issuer of a Public Key Certificate is called a certification authority. A certification authority is responsible for validating a person’s or other entity’s identity and for associating the person or entity with the key pair it is issued. The user places trust in the certification authority’s ability to distinguish between authorized and unauthorized certificate requests.The certification authority stores and maintains a list of the certificates it has issued. Windows 2000 contains a new version of the Microsoft Certificate Server Service. The original Certificate Server Service appeared in the IIS 4 add-on, which was part of the option pack for the Windows NT 4 operating system. It was through this service that keys and X.509v3 certificates were issued and managed.The Certificate Server Service 1 allowed a user to use an Internet browser to retrieve or request the identification of certification authority certificates. The Certificate Server Service for Windows 2000 includes the capability to do the following: ■

Issue certificates to users, computers, or services

■

Identify the requesting entity

■

Validate certificate requests, as allowed under the Public Key security policy

■

Support a local enterprise’s CAs as well as external CAs

www.syngress.com

672


Certificate Hierarchies As with most hierarchical structures, the PKI hierarchy makes administration easier and improves scalability.The hierarchy can contain one or more well-defined parent-child relationships. Multiple unconnected hierarchies can be implemented in environments that do not require that all certification authorities share one top-level certification authority parent. As mentioned previously, the certification authority at the very top of a certificate hierarchy is referred to as a root certification authority. No one is above the root CA, so nobody can vouch for its authenticity, and the root CA simply signs its own certificate. Because the verifying of its own identity is not really secure for the root certificate authority, a third party is often used to verify a root CA’s certificate; thus, verification of the entire certificate chain is possible. Child CAs are issued certificates from the parent certification authority. Any environment can have more than one Trusted Root certification authority. Figure 12.8 shows one environment that contains 27 Trusted Root certification authorities.The Windows 2000 dialog box not only displays the CAs but can also include the expiration date and the intended purpose for each listed CA. Figure 12.8 Trusted Root Certificate Authorities

When you set up your Windows-based PKI, you must choose a certification authority hierarchical structure to implement. Each model comes with its own advantages and disadvantages.You need to understand each hierarchy in order to plan PKI deployment. The practical reasons for supporting a model containing multiple certification authorities may include the following: ■

Fault Tolerance Multiple certification authorities enable you to turn off a branch without having an impact on the certification authority hierarchy.

www.syngress.com

Creating a Public Key Infrastructure with Certificate Services • Chapter 12 ■

Flexibility The most important certification authority is the root, so you might decide to physically secure the computer and also install some special cryptographic hardware.

■

Geography A large organization might have entities at multiple remote sites. The network connections between the multiple sites might require separate issuing certification authorities.

■

Organizational divisions A large organization might have entities at multiple remote sites.The network connectivity between the multiple sites might require separate issuing certification authorities.

■

Use or Purpose Certificates might be issued for defined purposes, such as smart card logons, and separation provides a basis for administering different policies.

673

Deploying an Enterprise CA The administrator does not have to configure a one-to-one relationship between established Windows domains and certification authorities.The Windows domains might have trust relationships configured in a way that is different from the relationships among the certification authorities.The bottom line is that the trust among domains and the trusts among the certification authorities do not need to be mapped into a one-to-one relationship. Multiple Windows domains can use a single certification authority. Conversely, a single domain can use multiple certification authorities.

NOTE Microsoft recommends that domains be created before the needed certification authorities are set up on a network.

Due to the hierarchical structure, the first certification authority should be the root CA.The very top of the hierarchical structure is the root certification authority, which automatically generates a self-signed CA certificate using its own key pair.The root certification authority also generates CA certificates for any of its subordinate certification authorities. A subordinate CA is a child to a parent CA and can take on one of two roles— intermediate or issuing. A subordinate may be an intermediate certification authority that is not a root but whose only purpose is to create certificates for other certification authorities.The other role of a subordinate CA is as an issuing certification authority, in which case it has the responsibility of issuing end-entity certificates.

www.syngress.com

674


When child certification authorities are installed, a certificate request is generated and is submitted to the parent certification authority, which would be either an intermediate CA or a root CA.The certificate request can be sent automatically to the parent certification authority defined in Active Directory; otherwise, the installer will have to manually get the certificate request to the parent certificate authority.When the certificate request is processed and a certificate is returned to the child CA, it must be installed before the certification authority can become operational. As with many services,Windows 2000 has a wizard to ease the installation of the Certificate Service.The wizard walks you through the entire process, periodically requesting input. Preplanning will, as always, make the installation run more smoothly. Before installing the Certificate Services, the administrator needs to identify what computer should run the service, considering factors such as current workload, physical security, connectivity, load balancing, and available hardware.

NOTE The determination of a certificate name should involve some thought, because all issued certificates are tied to the certification authority name of the issuer. After the certification authority is created, no renaming capability is available. Using the organizational naming convention that is already established for your organization is easiest.

During the Certificate Services installation, a public key pair is generated for the certification authority that is being created.This key pair is unique to the certification authority.The installation process involves Active Directory, in that a CA object and information about the CA configuration are added to Active Directory. If the environment does not include Active Directory service, the administrator has to manually add the CA object and its information.

Trust in Multiple CA Hierarchies The word hierarchy implies more than one level, and, in most environments, the PKI will have more than one certification authority. A PKI based on Windows 2000 must deal with the trust relationships across the multiple certification authorities.The multiple CA hierarchies could be within the organization, or they could be in other organizations that can include commercial certification authorities as well as private CAs. The system administrator has to create and enforce the certification authority-based trust relationships. For each individual Trusted Root certification authority, the administrator has the ability to restrict the use of certificates that are created by the CA. An example would be a Trusted Root certification authority that has been configured to validate only certificates issued by a CA for digital signatures. www.syngress.com


675

Multiple certification authorities outside Windows 2000 sometimes are configured to use cross certificates, which provide a way to create a chain of trust from a single Trusted Root certification authority to numerous other certification authorities.The Windows 2000 environment can process such cross certificates and involve them in making trust decisions, but they are not a necessity in the Microsoft PKI model. Microsoft’s recommended PKI model excludes the use of cross certificates.

Installing a Windows 2000 PKI Microsoft’s PKI model consists of the following components: ■

Active Directory Contains the certificate store for certificates and certificate revocation lists

■

Certificate Services Allows a Windows 2000 Server machine to function as a CA

Before you can install Certificate Services, you must have a properly configured Active Directory environment including DNS (which is required for Active Directory). To install an Enterprise Certification Authority server, you must have administrative rights on the domain controllers, DNS servers, and on the Certification Authority server. Computers cannot be renamed or joined to or removed from a domain after installing Certificate Services. Exercise 12.1 walks you through the process of installing Certificate Services.

Exercise 12.1 Installing Certificate Services 1. Click Start. 2. Go to Settings | Control Panel | Add/Remove Programs. 3. In the Add/Remove Programs dialog box, click Add/Remove Windows Components.The Windows Components Wizard displays, as shown in Figure 12.9. 4. Select the check box next to Certificate Services. 5. Click Next to continue. 6. You are now presented with the message box shown in Figure 12.10, advising that you cannot change the computer’s name or domain membership after Certificate Services is installed. Click Yes to continue. 7. Now you have to choose which type of certification authority to create. Choose the correct role in the wizard (see Figure 12.11), select the Advanced options check box, and click Next to continue. www.syngress.com

676


Figure 12.9 Adding Windows Components

Figure 12.10 Installation Warning Message Box

Figure 12.11 Choosing a Certification Authority Type

8. Selecting the Advanced options check box displays the Public and Private Key Pair screen shown in Figure 12.12, which allows you to select a CSP and settings. 9. Select the CSP and the algorithm to be used. Click Next.

www.syngress.com


677

Figure 12.12 Public and Private Key Pair Settings

10. Figure 12.13 shows the CA Identifying Information screen.You must enter a unique name for your certification authority.This is where you choose how long certificates will be valid (the default is two years). Fill in the needed information, and click Next to continue.The Data Storage Location screen displays as shown in Figure 12.14. Figure 12.13 Certification Authority Identifying Information

11. Enter the location of the certificate database and the certificate database log. The default is %windir%\system32\certlog. For fault tolerance, put the database and the log on separate drives. Click Next to continue. 12. If the Internet Information Services (IIS) is running on your computer, you are presented with the message box shown in Figure 12.15. Click OK to stop IIS from running and continue the installation.The Configuring Components screen displays, as shown in Figure 12.16. www.syngress.com

678


Figure 12.14 Selecting Database Storage

Figure 12.15 Stopping IIS

Figure 12.16 The Configuring Components Screen

13. After setup finishes, the wizard’s final screen displays (see Figure 12.17). Click Finish to accept the changes.

www.syngress.com


679

Figure 12.17 Finishing the Windows Components Wizard

Enabling Domain Clients One of the necessary components for a PKI is the capability to generate and manage keys while making any activity being performed transparent to the user.To meet this requirement, Microsoft has written into the Windows 2000 operating system a set of core services that support development and use of public key-based applications. Through the use of Active Directory, application management within an enterprise is integrated with the domain administration and policy.The core application services of Windows 2000 are designed for interoperability of the public key algorithms across the enterprise.

Generating Keys To use a PKI, the software must be able to generate and manage keys.The design of Windows 2000 allows installable Cryptographic Service Providers that will handle these two major tasks.The CryptoAPI defines standard interfaces that are the same for all CSPs. The way public key pair information is stored depends on the CSP being used.The Microsoft-provided CSP stores key information for a user or computer in an encrypted form. Microsoft’s CSP allows full control over the use and export of public key information. A CRYPT_EXPORTABLE flag must be set before the key is generated in order to allow private key export from the CSP. Microsoft has also included a CRYPT_USER_PROTECT flag that can be used to notify a user when an application tries to use the user’s private key. Other CSPs might implement similar or different control mechanisms.

www.syngress.com

680


Key Recovery Key recovery is compatible with the CryptoAPI architecture of Windows 2000, but it is not a necessary requirement. For key recovery, an entity’s private key must be stored permanently.The storage of private keys guarantees that critical information will always be accessible, even if the information should get corrupted or deleted. On the other hand, a security issue exists in backing up the private keys.The archived private key can be used to impersonate the private key owner.The backed up key should be used only if corruption occurs on your system, rendering the original key unusable. Windows 2000 does provide the capability to back up and restore the key pairs and their certificates through the Certificate Manager snap-in for the MMC.The exporting of a certificate can involve just the certificate or the certificate and its associated key pair. If the associated key pair is exported, the information is encrypted as a PKCS-12 (Public Key Cryptography Standards) message.When restoring certificates and key pairs onto a system, the administrator uses the import function of the Certificate Manager. Exercise 12.2 walks you through the steps of exporting a certificate and its private key.

Exercise 12.2 Exporting a Certificate and a Private Key You must first create a custom console containing the certificate snap-in: 1. Click Start. 2. Click Run. 3. Type MMC in the Open line. 4. Click OK.This opens a blank MMC. 5. You now need to add the Certificate snap-in. Click Console. 6. Choose Add/Remove Snap-in from the pop-up menu. 7. Click Add. 8. Choose Certificates from the list of available snap-ins. 9. Select My User Account. 10. Click Finish. 11. Click Close in the Add Standalone Snap-in dialog box. 12. Click OK on the Add/Remove Snap-in dialog box. Now you can use your custom console to complete this exercise: 13. Expand Certificates – Current User. 14. Expand Personal.

www.syngress.com


681

15. Select Certificates. 16. In the details pane (right side), right-click the certificate that you want to export, and choose All Tasks | Export (see Figure 12.18).This starts the Certificate Export Wizard shown in Figure 12.19. Figure 12.18 The Certificates Snap-In

Figure 12.19 Starting the Certificate Export Wizard

17. Click Next to continue the wizard.

www.syngress.com

682


18. Figure 12.20 shows the Export Private Key screen. Use this screen to choose whether you want to export the certificate and its private key, or just the certificate. Select the radio button labeled Yes, export the private key. Click Next to continue. Next, the Export File Format screen displays, as shown in Figure 12.21. Figure 12.20 Exporting the Private Key

Figure 12.21 Choosing an Export File Format

19. Select the file format that you want to use, and click Next. 20. You are now prompted for a password (as shown in Figure 12.22) to assign to the private key. Enter the password twice, and click Next. 21. You are now asked to specify the name and path of the file you want to export, as shown in Figure 12.23. Enter the name, and click Next to continue. Next, the final wizard screen displays, as shown in Figure 12.24.

www.syngress.com


683

Figure 12.22 Entering a Password

Figure 12.23 Selecting an Export File Name

Figure 12.24 Completing the Certificate Export Wizard

www.syngress.com

684


22. Verify that the information is correct, and click Finish to complete the Certificate Export Wizard. If the operation is successful, you are presented with the message box shown in Figure 12.25. Figure 12.25 The Export Successful Message

23. Click OK.

NOTE Before performing an export operation of a certificate and public key pairs, an administrator should look at the CSP being used. When the Microsoft CSP is used, the exporting of key pairs will occur only if the exportable flag CRYPT_EXPORTABLE was set at the time the key was created. Some third-party CSPs might not support the back up and the restoration of key pairs and their certificates. When this is the case, only a complete system image backup is possible.

Certificate Enrollment Remember, the guarantee that the public key is truly owned by the entity whose name is associated with it lies in the public key-based certificates.The Windows 2000 PKI includes certificate enrollment to the Microsoft Enterprise certification authority or to other third-party CAs. In Windows 2000, you can use automatic certificate settings in the public key policies to automatically enroll certificates for computers that are associated with a particular GPO.The automatic request is then made the next time the computers log onto the network.You must be an administrator to set up automatic certificate requests. It is important to note that automatic certificate request policies in Windows 2000 are only applicable to computer-related certificates, such as computer certificates, IPSec certificates, and Web server certificates (not user-related certificates). One of the enhancements to the Windows XP/.NET PKI is the autoenrollment process, which makes it possible for clients to automatically submit a certificate request to the CA and retrieve and store certificates that have been issued.This new capability allows both users and computers to be automatically enrolled for certificates.To take advantage of autoenrollment, an XP client must be used in a Windows domain running www.syngress.com


685

Windows 2000 or .NET domain controllers, with the .NET schema and Group Policy updates.There must be an enterprise CA running Windows .NET Enterprise Edition.

NOTE For more information about using XP’s autoenrollment feature, including a technical walkthrough of the process, see the article titled Certificate Autoenrollment in Windows XP on the Microsoft Web site at www.microsoft.com/WindowsXP/ pro/techinfo/administration/autoenroll/default.asp.

In both Windows 2000 and XP/.NET, you can use the Certificate Request Wizard (accessed through the Certificates MMC snap-in) or the Certificate Services Web page to request a certificate.

NOTE The Certificate Request Wizard is only available when requesting a certificate from an Enterprise CA. You must use the Certificate Services Web page to request a certificate from a standalone CA.

Exercise 12.3 walks you through requesting a certificate using the Certificate Request Wizard via the Certificates snap-in. Exercise 12.4 walks you through requesting a certificate using the Microsoft’s certificate request Web page.

Exercise 12.3 Requesting a User Certificate Using the Certificate Request Wizard First, create a custom console containing the Certificates snap-in: 1. Click Start. 2. Click Run. 3. Type MMC in the Open line. 4. Click OK.This will open a blank MMC. 5. You now need to add the Certificates snap-in. Click Console. 6. Choose Add/Remove Snap-in from the pop-up menu. 7. Click Add. 8. Choose Certificates from the list of available snap-ins. 9. Select My User Account. www.syngress.com

686


10. Click Finish. 11. Click Close on the Add Standalone Snap-in dialog box. 12. Click OK on the Add/Remove Snap-in dialog box. Now, you can use your custom console to complete this exercise: 13. Expand Certificates – Current User. 14. Expand Personal. 15. Right-click Certificates. 16. Choose All Tasks | Request New Certificate from the pop-up menu (see Figure 12.26).This starts the Certificate Request Wizard shown in Figure 12.27. Figure 12.26 Requesting New Certificates

17. Click Next to continue the wizard. 18. You are now prompted to specify the type of certificate to request, as shown in Figure 12.28. Choose the correct certificate type (Select User for this example), and click Next.The Cryptographic Service Provider screen displays, as shown in Figure 12.29. 19. Choose a CSP, and click Next.

www.syngress.com


687

Figure 12.27 The Certificate Request Wizard

Figure 12.28 Choosing a Certificate Template

Figure 12.29 Choosing a CSP

www.syngress.com

688


20. You must now select a CA from which to request a certificate, as shown in Figure 12.30. Select your CA, and click Next to proceed. Figure 12.30 Selecting a Certification Authority

21. You are now asked to enter a name and description for your certificate, as shown in Figure 12.31. Enter your information, and click Next to continue. Figure 12.31 Entering a Name and Description for a New Certificate

22. Figure 12.32 shows the final screen of the wizard, which summarizes the choices you made. Review the information (you can use the Back button to make changes), and the click Finish to finalize the request. 23. You can now view or install the granted certificate (see Figure 12.33). Click Install Certificate to install the certificate. If installation is successful, the message box shown in Figure 12.34 displays. 24. Click OK. www.syngress.com


689

Figure 12.32 Completing the Certificate Request Wizard

Figure 12.33 Installing a Certificate

Figure 12.34 Notification of Successful Installation

Exercise 12.4 Requesting an EFS Recovery Agent Certificate from the CA Web Page In this exercise, you request a certificate for an Encrypting File System recovery agent, using the Certificate Services Web page. 1. Open your Web browser. 2. In the Address bar, type http://server_name/certsrv (where server_name is the name of your certificate server).The Microsoft Certificate Services page displays, as shown in Figure 12.35. 3. Select Request a certificate, and click Next.This is also where you can check on a previous certificate request or request a CRL.The Choose Request Type page displays, as shown in Figure 12.36.

www.syngress.com

690


Figure 12.35 The Certificate Services Request Page

Figure 12.36 Choosing a Request Type

4. Select Advanced request and click Next. the Advanced Certificate Requests page displays, as shown in Figure 12.37. www.syngress.com


691

Figure 12.37 Advanced Certificate Request

5. Choose Submit a certificate request to this CA using a form.You must next choose a certificate template, as shown in Figure 12.38. Figure 12.38 Choosing a Certificate Template and Key Options

www.syngress.com

692


6. In the Certificate Template drop-down list box, select EFS Recovery Agent. Scroll down to the bottom of the page, and click Submit.You are now issued the certificate, as shown in Figure 12.39. Figure 12.39 Issuing and Installing a Certificate

7. At this point, you need to install your certificate. Click the Install this certificate link.The certificate is installed, and the Certificate Installed page displays, as shown in Figure 12.40.

NOTE How a certificate request is processed depends on the type of CA to which it is submitted. If the CA is a Windows 2000 Enterprise CA, the request will be processed immediately and either granted or denied (if it is granted, it is issued immediately and you can install it). If the CA is a standalone, by default, it is shown as “pending.” The administrator will review the request and approve or reject it. The user who requested the certificate can check the status of a pending request using the Certificate Services Web page.

www.syngress.com


693

Figure 12.40 Certificate Installation Successful

BEYOND ISA SERVER The certificate enrollment used by Microsoft in Windows 2000 is based on the industry standard PKCS-10 and PKCS-7. PKCS-10 is the standard for a certificate request message, and PKCS-7 contains the issued certificate or certificate chain. The Windows 2000 operating system currently supports certificates based on RSA keys and signatures, Diffie-Hellman keys, and Digital Signature Algorithm (DSA) keys and signatures. The Microsoft-supplied enrollment control XENROLL.dll provides support for both PKCS-10 and PKCS-7. The dynamic link library allows enrollment to be Web-based by use of scripts or through interprocess communication mechanisms, such as RPCs and DCOM. Enrollment can be completed through e-mails, an enrollment wizard, or a policy-driven enrollment that occurs as part of the logon process. Enrollment allows the calling application to supply the needed attributes in the PKCS-10 message request. The certificate enrollment provides for the creation of an internal binding between a certificate, key pair container, and CSP. In the future, the certificate enrollment will be implemented under Certificate Request Syntax, which is an IAB protocol that is currently in the draft stage.

www.syngress.com

694


Renewal Much like a credit card, which includes an expiration date, a certificate should be valid only for a specified period of time for security reasons.The certificate renewal is processed more quickly and efficiently than the certificate enrollment because the renewal certificate will contain the same attributes as the existing certificate, so verification is not needed. In Windows 2000, only automatic enrolled certificates support renewal, and the renewed certificate can use the existing public key or a new public key. All other generated certificates are handled through a complete certificate enrollment process, including verification. As with certificate enrollment, the Internet community is working on a mechanism for defining the message protocol for a renewal certificate.

Using Keys and Certificates In the Windows 2000 operating system, the Local Security Authority Subsystem is in the user mode.This security subsystem in Windows 2000 must take on additional functions to support the new security features.The Microsoft CryptoAPI subsystem manages both the CSP and the certificate stores.Within the Windows 2000 PKI, the keys are managed by the CSPs, whereas the certificates are managed by the certificate stores. Certificates and their properties are stored in the certificate stores.These stores are logical stores in that they present a systemwide view of available certificates that might exist on numerous physical stores.The applications can locate and decode the certificates by using the services of the CryptoAPI subsystem. A PKI defines five standard certificate stores: ■

CA Stores issuing and intermediate certification authority certificates to use in the CA hierarchical structure.

■

MY Stores a user’s or computer’s certificates for which the related private key is available.

■

ROOT Stores only the self-signed certification authority certificates for Trusted Root CAs.

■

TRUST Stores the certificate trust lists (CTLs).This is an alternate way to specify a certificate hierarchy.

■

UserDS Stores a logical view of a certificate repository that is located in the Active Directory and is used to simplify access to the certificate stores.

www.syngress.com


695

Roaming The Windows 2000 operating system allows a user with a valid user account to use any available computer in a domain to log onto the network.Thus, administrators need to ensure that a user’s cryptographic keys and certificates are available wherever the logon occurs. A user must be able to use the same public key-based application regardless of the computer he or she uses. The Windows 2000 PKI supports roaming users in two ways.The Microsoft-provided CSP allows roaming profiles to support the roaming use of keys and certificates. As with the Windows NT roaming profile, the process of logging on with a roaming profile is transparent to an end user.The second way to support the use of roaming keys and certificates is through the implementation of hardware authentication devices, such as smart cards, which contain the user’s certificates and private keys.

Revocation Certificates are generally issued with an average lifetime of two or three years. However, there could be many reasons to cease trusting the credentials prior to the expiration date. Any of the following circumstances would warrant the revocation of a certificate: ■

An entity’s private key has been compromised.

■

A project with another organization is completed.

■

An employee has changed status within the company.

■

A department is to cease having access to certain information.

■

The certificate was obtained through forgery.

The Windows 2000 public key functions are based on distributed verification, so revocation of certificates is also handled in a distributed fashion.There is no need to create a central location for revocation information. Microsoft designed Windows 2000 revocation around industry standard certificate revocation lists.The Microsoft Enterprise certification authority publishes the CRLs to Active Directory. From here, the domain clients can obtain the information, cache it to the local machine, and then read it from the cache when certificates are verified.The clients can verify certificates when they use a commercial certification authority or a third-party CA, as long as the published certificate revocation list is available over the network. Exercise 12.5 walks you through revoking a certificate and manually publishing a new CRL.

www.syngress.com

696


Exercise 12.5 Revoking a Certificate and Publishing a CRL 1. Click Start. 2. Go to Programs | Administrative Tools. 3. Open Certification Authority, as shown in Figure 12.41. Figure 12.41 Revoking a Certificate

4. Expand the name of your CA (Company Name CA in this example). 5. Select Issued Certificates. 6. In the details pane (right side), right-click the certificate that you want to revoke, and choose All Tasks | Revoke Certificate from the pop-up menu. 7. You are now asked if you are sure that you want to revoke the selected certificate (see Figure 12.42). If you are sure, pick a reason code, and click Yes to revoke the certificate.The available reason codes are the following: ■

Unspecified

■

Key Compromise

■

CA Compromise

■

Change of Affiliation

www.syngress.com


Superseded

■

Cease of Operation

■

Certificate Hold

697

Figure 12.42 Selecting a Reason for Certificate Revocation

8. To publish a new CRL (as shown in Figure 12.43), right-click Revoked Certificates, and choose All Tasks | Publish from the pop-up menu. If your CRL hasn’t expired, the message box shown in Figure 12.44 displays. Figure 12.43 Publishing a CRL

Figure 12.44 The New CRL Verification Message

9. Click Yes to publish the new CRL. www.syngress.com

698


Trust In a PKI environment, a client must have confidence in the certification authority that states that a public key does in fact belong to a specified entity.Two conditions must be met before a certificate verification is assumed to be valid. First, the entity’s certificate must be shown to be linked to a known Trusted Root certification authority of the client. Second, the intended certificate’s use must be in line with the application. If either of these two conditions is not satisfied, the certificate is assumed to be invalid. Trust relationships that a client has initially available should be automatically propagated as part of an Enterprise policy. As an exception,Windows 2000 allows users to manually install or remove the certificate of the root certification authority they want to trust. A trust created this way affects only the user who creates it. A trust established with a root certification authority can be configured with user restrictions. Exercise 12.6 walks you through the process of trusting a root CA by importing one of its certificates.

Exercise 12.6 Importing a Certificate from a Trusted Root CA You must first create a custom console containing the certificate snap-in. First, create a custom MMC with the Certificates snap-in to manage your user account, following the same steps as in Exercise 12.3. Now, you can use your custom console to complete this exercise: 1. Expand Certificates – Current User. 2. Expand Trusted Root Certification Authorities. 3. Right-click Certificates, and choose All Tasks, then Import from the popup menu (see Figure 12.45).This starts the Certificate Import Wizard, shown in Figure 12.46. 4. Click Next to continue the wizard. 5. You are now asked to select a file to import, as shown in Figure 12.47. Browse to the CA’s certificate, and click Next.The password screen displays, as shown in Figure 12.48. 6. Type the password assigned to the file, and click Next to continue.

www.syngress.com


699

Figure 12.45 Starting the Certificate Import Wizard

Figure 12.46 The Certificate Import Wizard

7. Choose where to place the certificate (see Figure 12.49), and click Next.The final screen displays, similar to the screen shown in Figure 12.50, which summarizes your choices.

www.syngress.com

700


Figure 12.47 Selecting a File to Import

Figure 12.48 Selecting a Password

Figure 12.49 Choosing a Certificate Store

www.syngress.com


701

Figure 12.50 Completing the Certificate Import Wizard

8. Verify that you have made the correct choices, and click Finish to complete the wizard. 9. You are now prompted to add the certificate to the Root Store, as shown in Figure 12.51. Click Yes. If the addition is successful,The notification shown in Figure 12.52 should display. Figure 12.51 Root Certificate Store Verification Message

Figure 12.52 The Successful Import Notification

Public Key Security Policy in Windows 2000 Windows 2000 uses the Kerberos security standard to provide single point logons at the enterprise level. Any policy, including the security policy, can be globally established for

www.syngress.com

702


an entire enterprise, site, domain, or organizational unit.The security policy, once set, affects the groups of users or computers defined on the network. The Public Key security policy is just one element of the overall Windows 2000 security policy and is a component of the PKI.The security policy is enforced globally, but, for ease of administration, it can be centrally defined and managed.

Trusted CA Roots A user with the necessary software can generate a key pair, so the organization needs some means to guarantee that a key is in fact valid for a particular user or entity.The certification authorities are responsible for providing this needed guarantee.The certification authorities can handle this task easily by storing the public key and maintaining a list of issued certificates. Remember that the structure for the certification authorities model has been designed as a hierarchy (see Figure 12.53).The certification authority at the very top of the hierarchy is referred to as a root CA.The child CAs are certified by certificates issued for them by their parent CAs. One advantage of a hierarchical structure over a linear structure is that few trusts are needed with root certification authorities. Figure 12.53 A Certificate Authority’s Hierarchical Structure Root CA

Issuing CA ABC Corp.

Issuing CA XYZ Corp.

The MMC Certificates snap-in is the administrative tool used to specify which certification authority to trust.Through this application,Trusted Root certification authorities are defined so that the proper certification authority is used by the clients to verify certificates. If you create a CA, its certificate should be added so that it is used as a trusted CA.The trust created by default is for only one computer, but, through the Group Policy Editor, the certification authority can be set for global implementation. If you do not want to trust a particular CA, make sure that the CA’s certificate is removed. The hierarchical model allows trust relationships with other organizations to be implemented easily. For example, if ABC Corporation’s CA is a subordinate CA of the public root of which XYZ Corporation’s CA is also a subordinate, the two corporations

www.syngress.com


703

automatically trust each other. Figure 12.53 shows the relationship between two companies and a root CA. The certification authority contains numerous properties that are tied to its use. An administrator can use the MMC Certificates snap-in to specify the certificate policy that will control the generation and use of certificates by a CA, as shown in Figure 12.54. When specified, the properties restrict for what purposes certificates are valid. For example, a user can use a certificate to validate secure e-mail but can not use the certificate’s private key for digital signatures.The following restrictions can be made in any combination: ■

Server authentication

■

Client authentication

■

Code signing

■

E-mail

■

IP Security end system

■

IPSec tunnel

■

IPSec user

■

Timestamping

■

Microsoft Encrypting File System

Figure 12.54 Certificate Authority Properties

www.syngress.com

704


To make the PKI transparent to a user,Windows 2000 had to make it possible to support automatic certificate enrollment, which is controlled by certificate types and autoenrollment objects. Both of these elements are integrated with the Group Policy object, so they can be defined at the site, domain, organizational unit, computer, or user level. Exercise 12.7 walks you through the process of configuring automatic certificate enrollment through a Group Policy object.

Exercise 12.7 Configuring Automatic Certificate Enrollment through Group Policy 1. Click Start. 2. Go to Programs | Administrative Tools. 3. Open Active Directory Users and Computers. 4. Right-click the domain. 5. Choose Properties from the pop-up menu. 6. Click the Group Policy tab. 7. Select the Default Domain Policy Group Policy object. 8. Click Edit.This opens the window shown in Figure 12.55. Figure 12.55 The Group Policy Editor

www.syngress.com


705

9. Expand Computer Configuration. 10. Expand Windows Settings. 11. Expand Security Settings. 12. Expand Public Key Policies. 13. Right-click Automatic Certificate Request Settings as shown in Figure 12.55, and choose New | Automatic Certificate Request.The Automatic Certificate Request Setup Wizard opens. 14. Click Next on the welcome window to continue the wizard, as shown in Figure 12.56. Figure 12.56 Choosing a Certificate Template

15. Choose a certificate template, and click Next to continue.You are now presented with the Certification Authority screen, shown in Figure 12.57. Figure 12.57 Selecting a Certification Authority

www.syngress.com

706


16. Choose the CA that should issue the certificate, and click Next.The completion window displays, as shown in Figure 12.58. Figure 12.58 Completing the Automatic Certificate Request Setup Wizard

17. Click Finish to end the wizard.

Certificate Enrollment and Renewal Certificate types are templates used to define policies that control the generation and use of a certificate. A template is identified by having a common name that usually is associated with the group for which the template was designed, such as a template named Engineers. A template defines components that will be incorporated into a certificate, such as the following: ■

Name requirements

■

Expiration date

■

CSP

■

Public key generation algorithm

The Enterprise Certification Authority includes a set of templates with its policy object.You can change the certificate templates available through the Certification Authority Console, as described in Exercise 12.8.Table 12.1 lists the types of user templates available by default, and Table 12.2 lists the types of computer templates available by default.

www.syngress.com


707

Exercise 12.8 Changing the Templates Available on the Enterprise Certification Authority 1. Click Start. 2. Go to Programs | Administrative Tools. 3. Open Certification Authority. 4. Expand the name of your CA (Company Name CA in this example). 5. Right-click Policy Settings, as shown in Figure 12.59. Figure 12.59 Selecting the Certificates to Issue

6. Choose New | Certificate to Issue from the pop-up menu.The Select Certificate Template dialog box opens, as shown in Figure 12.60. Figure 12.60 Adding New Templates

www.syngress.com

708


7. Select the certificate template you want to be available on your CA, and click OK. Table 12.1 Templates Available for Users Template Name

Purposes

Administrator

Code signing, Microsoft trust list signing, EFS, secure e-mail, client authentication All Client authentication Code signing Microsoft trust list signing Encrypting File System File recovery Certificate request agent Client authentication Client authentication, secure e-mail Encrypting File System, secure e-mail, client authentication Secure e-mail, client authentication Certificate request agent

Certification authority ClientAuth CodeSigning CTLSigning EFS EFSRecovery EnrollmentAgent SmartcardLogon SmartcardUser User UserSignature Exchange enrollment agent (offline request) Exchange user Exchange user signature

Secure e-mail, client authentication Secure e-mail, client authentication

Table 12.2 Templates Available for Machines Certificate Template Name

Certificate Purposes

Certification authority Domain controller IPSECIntermediateOffline IPSECIntermediateOnline MachineEnrollmentAgent Machine OfflineRouter SubCA WebServer Exchange user signature

All Client authentication, server authentication IP Security IP Security Certificate request agent Client authentication, server authentication Client authentication All Server authentication Secure e-mail, client authentication

www.syngress.com


709

Smart Card Logon Smart card logon is controlled by the policy established with the user object.The policy can be set in one of two ways.The smart card logon policy can be set to enforce smart card logon, so password-based logon is not available.This is more secure, but the disadvantage of setting the policy in this fashion is that users must always have their smart card and a computer available with a smart card reader in order to log on.The second way to set the policy for smart card logons is to enable smart card logon, which allows password-based logons to occur on a network.

Applications Overview The PKI gives the Windows 2000 operating system a way to integrate services and tools to manage public key-based applications. As application programmers implement secret key or public key-based security models into their code, organizations gain new security functionality. Some applications already have the public key mechanisms available, because programmers have made use of the PKI.When the PKI has been configured, a PKI-aware application can use the public key cryptography. If the application is correctly written, the encryption process is transparent to users.

Web Security Windows 2000 provides support for both Secure Sockets Layer/Transport Layer Security (SSL/TLS) and Server Gated Cryptography (SGC) to ensure secure Web communications. SGC is an extension to SSL3, which was defined to secure online banking sessions. The TLS can be used to access any kind of Web site. Export restrictions have been relaxed, but both versions are still available.The TLS comes in a 128-bit and 40-bit encryption version.The secure channel is established by the use of certificates and public keys, using the following steps: 1. The client first sends a hello message to the server and then receives the server’s certificate. 2. The server is authenticated by the client, using the certification authority’s public key. 3. After the server is authenticated, the client generates a session key of the appropriate size.The client then secures the session key by encrypting it with the server’s public key. 4. When the server receives the encrypted session key, it uses its private key to decrypt the session key. 5. Now, both the client and the server can securely use the session key to exchange sensitive data. www.syngress.com

710


The SGC process is similar to the TLS process.The first difference is that the server’s certificate must come from an authorized certification authority. SGC resets and then restarts the handshake after the SGC certificate is detected.

NOTE To take advantage of TLS and SGC, both the client and the server must have certificates issued by the same trusted certification authority. Only when the two parties use a common CA can the parties authenticate each other. The certificates exchanged rely on the use of key pair encryption in order to end up with a secret session key.

Web security involves the authentication of both the client and the server. It also involves the encryption of data between two parties to prevent public readability. A client authenticates a server by comparing a certification authority’s public key to the certification authority’s signature on the server’s certificate. A server authenticates a client by using its private key to get to the session key.The session key has been encrypted with the public key, so the only way to decrypt a session key is through the private key that belongs to the same key pair.

Secure E-Mail Secure e-mail has always been part of the Exchange Server product. Exchange Server’s advanced security enables users to keep data private during message transfer through encryption and digital signatures.The Key Management server component stores and manages the security database, and it creates and maintains backups of public and private encryption keys and the certificate revocation list. Exchange Server supports S/MIME mail, which is part of a PKI. To send an encrypted e-mail message, the following steps need to occur: 1. First, the message that contains the sensitive data is composed. 2. The sender obtains the public key of the receiver. 3. A bulk encryption key is generated, and then the sensitive data is encrypted with this key. 4. After the document is in ciphertext, the bulk encryption key is encrypted, using the receiver’s public key.The message is now ready to be delivered. 5. The recipient uses the private key in order to gain access to the bulk encryption key. 6. The recipient then uses the bulk encryption key to return the document to plaintext. www.syngress.com


711

The process of using a digital signature with e-mail assures both the sender and the recipient that the message has not been tampered with in transit.When a user indicates through an e-mail interface that a message should have a digital signature, a private key is used to hash the message and produce a message digest.The document and the message digest are then sent to the recipient.The e-mail interface indicates to the recipient that the message contains a digital signature. In the verification of the digital signature, the sender’s public key is used to decrypt the digital signature.The document is hashed by the generation of a 128-bit number by the recipient. If the decrypted digital signature matches the generated 128-bit number, the recipient knows that the sender is really the person who is indicated on the message and that the body of the message has not been tampered with before the recipient received it.

Digitally Signed Content Microsoft’s PKI includes a code-signing technology, called Authenticode, with Windows 2000. Authenticode ensures the integrity and origin of software distribution by vendors over the Internet.This is, in effect, a digital signature; Authenticode is based on digital signature technology. Authenticode adds a digital signature, a code-signing certificate, and a timestamp in the downloadable software.The software that Authenticode can guarantee includes Java applets, Active X controls, cabinet files, dynamic link libraries, executable files, and catalog files. Authenticode does not stop with the download process; it also verifies downloaded code before you use it on your local computer. Authenticode uses code signing and code verification to perform its tasks. Before developers or vendors can sign code, they need to obtain a code-signing certificate from a certification authority.This is sometimes referred to as obtaining a software publishing certificate.With this code-signing certificate, developers can then use the Authenticode signing functions from the Active X Software Developer’s Kit. A digital signature is created by a hashing algorithm used on the code a developer wants to secure, and a private key is used to sign the hash.The software then builds a signature block that contains the digital signature and the code-signing certificate.The timestamped signature block is then bound to the original software code. At this point, the developer is ready to publish the signed software on a Web site for downloading. Built into Microsoft Internet Explorer is the second part of Authenticode—code verification. Before any signed code can run, it calls up the code verification function to check three important items—signature, publisher’s certificate, and timestamp. A Security Warning dialog box displays the name of the code, name of the organization, date the publisher authenticated the code, and name of the certification authority that issued the code-signing certificate. A user has the ability at this time to decide whether

www.syngress.com

712


to accept or reject the published software. Figure 12.61 shows a Security Warning dialog box received while the Internet Explorer application is used. Figure 12.61 Security Warning Dialog Box

Internet Explorer allows a user to set up a security policy for Authenticode with the following four security levels: High, Medium, Low, and Custom.Table 12.3 defines each security level. Table 12.3 Security Levels Level

Function

High Medium Low Custom

Does not execute damaged code Warns you before running potentially damaged code Always runs code Enables you to choose the security level setting for software codes and security zones

Encrypting File System Windows 2000 and XP Professional enable users to encrypt files that contain sensitive information as long as the files are stored on an NTFS partition.The Encrypting File System can be set at both the directory and file level and is transparent to users when they have indicated that they want encryption to be implemented. Applications have access to encrypted objects in the same fashion as non-encrypted objects. See Chapter 9 for more information about EFS.

Smart-Card Logon Smart card service can be implemented as a component of the PKI in Windows 2000. Generally, a smart card is about the size of a credit card and can store an owner’s certificates and private keys on an erasable programmable ROM, so changes can be made if www.syngress.com


713

necessary.The smart card is usually protected by a password and runs a card operating system that resides in ROM. A smart card requires that a smart card reader be attached to a user’s computer. See Chapter 11 for more information about smart card authentication.

IP Security IP Security (IPSec) is a protocol that implements network encryption at the IP protocol layers. IPSec uses state-of-the-art cryptography techniques and does not require a public key algorithm. A public key algorithm provides the organization with a distributed trust environment that can be scaled to any size.The Internet Engineering Task Force has implemented IPSec devices so that through the use of public key algorithms they can mutually authenticate each other and agree on encrypting keys. See Chapter 10 for more information about IPSec.

Preparing to Implement the Windows 2000 PKI Microsoft Exchange Server is a useful tool for an organization preparing to use Windows 2000’s PKI. Many organizations are already using a PKI. S/MIME is based on a PKI, and it allows Exchange clients to encrypt mail and send digitally signed messages.The Exchange Server product allows the PKI to exist within an entire organization, and it also allows support to exchange keys to entities outside of an organization. If you are just starting to use Exchange Server, Microsoft recommends that you install version 5.5 along with Service Pack 2.The client software in your PKI should be Microsoft Outlook 2000/20002, which supports S/MIME e-mail.The PKI is built around these components: ■

A Key Management server with recovery features

■

S/MIME clients using CryptoAPI

■

LDAP-based Exchange directory services

■

Certificate Server X.509 version 3

Table 12.4 lists the PKI standards that are written into the Windows 2000 operating system.

www.syngress.com

714


Table 12.4 PKI Standards Standard

Defines

Why Included

Secure Sockets Layer—V3 Server Gateway Cryptography

Encryption for Web Sessions Secure session

X.509 version 3

Digital certificates format and content Format and content of certificate revocation lists Format and behavior for public key exchange and distribution Format and behavior for public key exchange and distribution Interface for smart cards on PCs

Security protocol used on the Internet. Export restrictions exist. Used by financial organizations between the United States and other countries for online banking sessions; always uses 128-bit session key. Allows certificate exchange between vendors. Provides revocation information.

Certificate Revocation List v2 PKCS family

PKIX Public Key Exchange PC/SC Personal Computer Smart Card IPSec PKINIT

Encryption for an IP session Logon where Kerberos is used by public key

Requests and certificate movement understood by all vendors. New technology that is replacing PKCS family. Group-defined standards for smart cards and smart card readers on PCs. Encrypts the network connection. Allows certificate on smart card to be used as logon credentials.

These major components are included in Exchange Server 5.5 and 2000, and the Microsoft Outlook 98, 2000, and 2002 clients to protect e-mail messages that contain sensitive information. Microsoft provides a migration path for Exchange users to move to the generalized PKI that Windows 2000 uses. Any new product involves a learning process, so include training time in your implementation plans. System administrators need to understand how keys and certificates are used, so they can take care of the management side of these new items. Doing some research on PKI case studies would also be to system administrators’ advantage; case studies can be very helpful to anyone setting up a PKI for the first time.The latest information, which can be obtained on the Microsoft Web site or from TechNet, should be used in preparation for implementing the Windows 2000 PKI.

www.syngress.com


715

Backing Up and Restoring Certificate Services Microsoft recommends that you back up your entire CA server regularly. By backing up the system state data on your CA, you will automatically get a backup of the certificate store, the Registry, system files, and Active Directory (if your CA is a domain controller). However, sometimes you might want to just back up the Certificate Services portion of your server without doing a full backup of everything else. Exercise 12.9 walks you through the process of backing up Certificate Services. Of course, your backups are only useful if you can restore them—Exercise 12.10 walks you through the process of restoring Certificate Services.

Exercise 12.9 Backing Up Certificate Services 1. Click Start. 2. Go to Programs | Administrative Tools. 3. Open Certification Authority. 4. Right-click the name of your CA as shown in Figure 12.62 (Company Name CA is used in this example). Figure 12.62 Starting the Certification Authority Backup Wizard

www.syngress.com

716


5. Choose All Tasks | Backup CA from the pop-up menu.The Certification Authority Backup Wizard opens, as shown in Figure 12.63. Figure 12.63 The Certification Authority Backup Wizard

6. Click Next to continue the wizard.You are now prompted to select the items to be backed up, as shown in Figure 12.64. Figure 12.64 Selecting the Items to Back Up

7. Choose the items you want to back up and the backup location, and click Next. with Select a Password screen displays, as shown in Figure 12.65. 8. Type a backup password, confirm the password, and click Next. 9. Figure 12.66 shows the Completing the Certification Authority Backup Wizard screen. Click Finish to close the wizard.

www.syngress.com


717

Figure 12.65 Selecting a Password

Figure 12.66 Completing the Certification Authority Backup Wizard

Exercise 12.10 Restoring Certificate Services 1. Click Start. 2. Go to Programs | Administrative Tools. 3. Open Certification Authority. 4. Right-click the name of your CA, as shown back in Figure 12.62 (Company Name CA is used in this example). 5. Choose All Tasks | Restore CA from the pop-up menu.This displays the message box shown in Figure 12.67. 6. Click OK to stop Certificate Services from running and start the wizard, as shown in Figure 12.68. www.syngress.com

718


Figure 12.67 Stopping Certificate Services

Figure 12.68 Starting the Certification Authority Wizard

7. Click Next to continue.The Items to Restore screen displays, as shown in Figure 12.69. Figure 12.69 Selecting Items to Restore

8. Select the items you want to restore and the restore file location, and click Next. 9. You must now enter the password assigned to the restore file, as shown in Figure 12.70. Enter the password, and click Next. www.syngress.com


719

Figure 12.70 Providing the Restore Password

10. Figure 12.71 shows the Completing the Certification Authority Restore Wizard screen. Click Finish to complete the wizard. Figure 12.71 Completing the Certification Authority Restore Wizard

11. You are now prompted to restart Certificate Services, as shown in Figure 12.72. Click Yes to restart the services. Figure 12.72 Starting Certificate Services

www.syngress.com

720


Summary Windows 2000 uses cryptography extensively.Windows 2000 Server provides the components to allow an organization to establish its own public key infrastructure based on asymmetric (public/private key) encryption, digital signatures, and digital certificates. Public key cryptography can provide authentication instead of privacy. Authentication involves the use of a challenge initiated by a receiver of data.The challenge can be sent encrypted or in plaintext. Either way, the result is proof for a receiver that a sender is authentic.This type of authentication is referred to as proof of possession.Windows 2000 also uses public key cryptography for bulk data encryption and exchanging a secret key through a nonsecure communication channel. A digital signature is a hash value encrypted with a private key. By using a corresponding public key, receivers can be guaranteed that a document contains no modifications and that senders are really who they claim to be.With a digital signature, a document itself is not encrypted. Digital signatures involve the creation of a message digest, which is signed by a sender’s private key. A message digest is a 128-bit number generated by hashing the original message. Digital certificates are used to provide assurance that a public key used does in fact belong to the entity that owns the corresponding private key. An issuer of a public key certificate is known as a certification authority.The job of the certification authority is to validate the identity of a person or organization to the public key. The certificate hierarchy consists of multiple certification authorities that have trust relationships established among them.The certificate authority at the very top of the certificate hierarchy is referred to as a root. Nothing is above a root CA, so it signs its own certificate. A subordinate CA can take on the role of an intermediate CA or can be an issuer CA. A subordinate’s certificate is generated by its parent certification authority.The intermediate certification authority’s purpose is to create certificates for other CAs. An issuer certification authority is responsible for issuing certificates to end entities (users or computers). Four types of certification authorities are available with Microsoft Certificates.The four types can be broken down into two major categories—Enterprise and Standalone. Enterprise CAs rely on the Active Directory services of the Windows 2000 operating system. A Standalone CA does not require Active Directory or membership in a Windows 2000 domain.The four types of certification authorities are Enterprise Root, Enterprise Subordinate, Standalone Root, and Standalone Subordinate. The PKI is not a single item but rather a collection of various components working together to allow public cryptography to occur.The main components of the Windows 2000 PKI are the following:

www.syngress.com


Active Directory Policy distribution and certificate publication

■

Certificate Services Certificate creation and revocation

■

Domain controller/Kerberos domain controller Domain logon

■

Client Where most of the activity is initiated

721

The Windows 2000 operating system makes many core application services available to domain clients. For the use of public key encryption, public keys must be generated, and they must be enrolled with a certification authority. If for some reason a key pair gets lost or corrupted, a client must have a means of key recovery. Keys have an expiration date, so an operating system must include a mechanism for necessary renewal. Windows 2000 provides core services for domain clients through the PKI.The generation and use of keys is transparent to users.The PKI is a mechanism for creating, renewing, and revoking keys on an as-needed basis. Generated keys can be automatically enrolled with a certification authority, and, in the event of key corruption, the Windows 2000 PKI makes it possible to recover keys. Because users can log on Windows 2000 with any computer, the PKI enables clients to use their keys from any network location.

Defensive Tactics Fast Track PKI Concepts ; Encryption is the process of changing a plaintext message into an unreadable

form known as ciphertext. Decryption is the process of changing a ciphertext message back to plaintext. ; Secret key encryption is very efficient at quickly encrypting large quantities of

data. Secret key encryption uses is a single key for both encryption and decryption. ; The most popular public key algorithm is the standard RSA, which is named

after its three inventors—Rivest, Shamir, and Adleman. ; Public key algorithms provide better security than secret key encryption, but

they encrypt and decrypt data more slowly. ; Digital signatures prevent changes within a document from going unnoticed.

They also verify a person to be an original author. Digital signatures do not provide document encryption.

www.syngress.com

722


; Digital certificates provide a way to validate public keys.They assure that

public keys belong to the entity that owns the corresponding private key. Certificates provide users with a guarantee between the public key and the entity holding the corresponding private key.The certificate contains the public key and a complete set of attributes. ; The Microsoft Certificate Services includes four types of certification

authorities—Enterprise Root CA, Enterprise subordinate CA, Standalone Root CA, and Standalone subordinate CA. ; The Enterprise Root CA is at the top of the PKI. An Enterprise Root CA

uses predefined certificate templates for issuing and requesting certificates.

Windows 2000 PKI Components ; A PKI is a collection of components that allows public cryptography to occur

transparently to clients. ; The two major services for Window 2000 public key security are the crypto-

graphic service and the certificate management service.The cryptographic service is responsible for key generation, message hashing, digital signatures, and encryption.The certificate management service is responsible for X.509 version 3 digital certificates. ; Because a root certification authority is at the very top of a certificate

hierarchy, it signs its own certificate. For increased security, a third party is often used to verify a root CA’s certificate.

Certificate Authorities ; The issuer of a Public Key Certificate is called the certification authority. A

certification authority is responsible for validating the identity of a person or organization and for associating the entity with the key pair it issued. ; The Certificate Server Service for Windows 2000 includes the capability to do

the following: ■

Issue certificates to users, computers, and services

■

Identify a requesting entity

■

Validate certificate requests, as allowed under the Public Key security policy

■

Support local enterprises CAs as well as external CAs

www.syngress.com


723

Installing a Windows 2000 PKI ; Microsoft’s PKI consists of Active Directory and Certificate Services. ; Active Directory must be properly configured before you can install

Certificate Services. ; Computers cannot be renamed, joined to, or removed from a domain after

installing Certificate Services.

Enabling Domain Clients ; For key recovery, a client’s private key must be stored permanently where it

will always be accessible. ; A certificate should be valid only for a limited time.Windows 2000 supports

renewal only with automatic enrolled certificates. All other certificates must go through a complete certificate enrollment process. ; Certificates and their properties are stored in certificate stores. Active

Directory is the store for an Enterprise CA. ; Windows 2000 supports roaming users by utilizing roaming profiles and

smart cards. ; The Enterprise CA publishes the CRLs to Active Directory where clients can

obtain the information.The CRL is cached to the client’s local machine and then read from the cache when certificates are verified.

Public Key Security Policy in Windows 2000 ; Windows 2000 provides single logons at the enterprise level. ; Certification authorities are responsible for guaranteeing that a key is in fact

valid for a particular user or company.The certification authorities accomplish this by storing the public key and maintaining a list of issued certificates. ; The Microsoft Management Console Certificates snap-in is used to specify

which certification authority to trust. Newly created CAs’ certificates must be added as trusted CAs. ; Certificate templates define policies that control the generation and use of

certificates.

www.syngress.com

724


; Smart card logon is controlled by the policy established with a user object.

Smart card logon can be mandatory or optional.

Applications Overview ; Windows 2000 provides support for both Secure Sockets Layer/Transport

Layer Security and Server Gated Cryptography to ensure secure Web communications. ; You can use the Transport Layer Security with any Web site as long as your

Web browser supports it. ; Exchange Server’s advanced security enables message encryption and digital

signatures.The Key Management server manages the security database. It also creates and maintains backups of public and private encryption keys and the certificate revocation list. ; The Encrypting File System enables users to encrypt files stored on an NTFS

partition. EFS uses both symmetric and asymmetric algorithms in the encryption process.

Preparing to Implement the Windows 2000 PKI ; Microsoft Exchange Server is useful in preparing for Windows 2000’s PKI. It

allows the PKI to exist within an entire organization. It also supports exchanging keys with external entities. ; PKI is built around a Key Management Server with recovery features,

S/MIME clients using CryptoAPI, LDAP-based Exchange directory services, and Certificate Server X.509 version 3. ; You can migrate from an Exchange PKI to the generalized PKI implemented

in Windows 2000.

Backing Up and Restoring Certificate Services ; Microsoft recommends that you back up your entire CA server by backing up

the system state data. ; You can use the Certification Authority console to back up and restore

Certificate Services without backing up the system state data.

www.syngress.com


725


Q: What components are needed to build a complete PKI? A: Five major components are needed to build a PKI. Certification authorities are needed to issue certificates and for certificate revocation lists.The certification publication point, based on directory services, makes certificates and the certificate revocation lists available at any time.The PKI also provides a utility for key and certificate management.The fourth component is the set of well-written PKI-aware applications that make public cryptography transparent to users.The final component in PKI is hardware that supports cryptographic technologies.The hardware ranges from smart cards used to store secure keys to PCI cards that handle on-board encryption/decryption processing.This fifth component of a complete PKI is completely optional.

Q: What are the primary software components of the Windows 2000 PKI? A: The Microsoft Certificate Services make it possible for you to create your own certificate authorities and to issue and manage digital certificates.This means that the Microsoft Certificate Services is your certificate authority and management tool. The Active Directory service is your Certificate Publication Point.The third component is the set of applications that work seamlessly with the Windows 2000 PKI, including Microsoft Internet Explorer and the Internet Information Server as well as applications from many third-party vendors.The final primary component of the Windows 2000 PKI is a component from the Exchange Server software, the Exchange Key Management Service.The optional hardware support in cryptography is available through the use of smart cards. Smart card support is built into Windows 2000.

Q: Are the security features easy to use? A: Microsoft has designed the PKI to be easy to use for everyone, from end users to administrators.The PKI components are included with the Windows 2000 operating system, so there is nothing extra to buy or install. Departments can be set up with their own certification authorities, because the CA software is part of the

www.syngress.com

726


server operating system. Administrators and end users can use familiar tools—such as the Microsoft Management Console and Internet Explorer—to create certificates, view certificates, view other certificates, validate authenticity, and set what certificates are authorized to do. By using Internet Explorer, users can access the Microsoft Certificate Services to request certificates to be created.The Certificate Request Wizard supplies the appropriate fields, and requests are automatically forwarded to the appropriate certification authority.When a certificate is generated, the public key information is automatically stored in Active Directory, and the private information is delivered to the requester.

Q: How does the RSA algorithm really work? A: The RSA algorithm works this way: 1. Take two large prime numbers, p and q. (These must be kept secret.) 2. Find their product ( p × q = n). n is called the modulus.The modulus function consists of the division of one number into another where the result is the whole number integer remainder. 3. Choose a number, e, that is less than n and relatively prime to (p–1)(q–1). 4. Find its inverse: ed=1 mod (p–1)(q–1). 5. The public key is the pair (n,e). 6. The private key is the pair (n,d). Simple RSA encryption could use the equation: c = mê mod n, where e and n are the receiver’s public key.

Simple RSA authentication could use these equations: Sender: S = m ^ d mod n, where S is the digital signature created by the sender’s private key (d and n). Receiver: m = S ^ e mod n, where e and n are the sender’s private key.

www.syngress.com

Chapter 13

Keeping Your IIS Web Servers Safe


Preparing the OS

■

Securing the Internet Information Service

■

Securing Web Sites

■

Authenticating Users


727

728

Chapter 13 • Keeping Your IIS Web Servers Safe

Introduction IIS security is a topic that nearly every Windows administrator will eventually face. For many companies, their IIS server is the one that takes all the beating from hackers.With anonymous visitors from around the world accessing the server, the challenge is to make sure that only designated files and programs can be accessed.The process of securing an IIS server is not difficult, but not consistently following procedure can lead to vulnerability. IIS can be extraordinarily secure, but that largely depends on the commitment of the system administrator.While IIS in its default installation state is completely insecure, most successful attacks are not the fault of IIS. Rather, most attacks occur due to the failure of an administrator to keep a server patched or to implement proper security measures. One of the primary challenges faced by an IIS/ISA Server administrator is balancing security with access.You can make your published Web sites so secure that no hacker or other miscreant will be able to compromise them.The problem is that legitimate users won’t be able to access the sites either! Securing IIS often hobbles functionality. If you have problems with your ISA Server Web Publishing Rules, you should first check that a “security fix” didn’t cause you to DoS your own machine. We always recommend that you test all your ISA Server configurations in the lab before bringing them to the production network.This is especially true for security configurations.You might be aware of the tragic effects applying security templates has on the ISA Server itself.While the ISA Server development team had their collective hearts in the right place when they introduced the Secure Your Server Wizard, the end effect of applying the security templates was to disable a few or many of the ISA Server services. Applying the security configurations recommended in this chapter can have similar untoward effects. Make sure that you test the settings in this chapter in the lab before you make changes on your production machines.

BEST PRACTICES Best practices are a consensus of strategies, tactics, and procedures that prevent specific types of attacks. Normally, a best practice is established through experience, sometimes through hard-learned lessons. When a new vulnerability is discovered, administrators take action to prevent exposure until a patch is available. Sometimes, the action is then recommended as a best practice. This chapter shows how to build a secure IIS server based on best practices and other tested techniques. While some of these measures might seem extreme or unusual, keep in mind that each technique was specifically developed to address a particular vulnerability or class of vulnerabilities.

www.syngress.com

Keeping Your IIS Web Servers Safe • Chapter 13

729

Preparing the OS Because a Web server is such a high-visibility target, extra precautions need to be taken to prepare the OS to run IIS. If possible, IIS should always be installed on a clean Windows 2000 installation. Upgrading another operating system to Windows 2000 is a poor solution and carries over weaknesses from the previous operating systems. A clean OS ensures that your server is free from Trojans or backdoors.

Adding and Removing Components For best results, use an unattend.txt file to build a minimal Windows 2000 installation with few extra components installed. If you are unable to do this, one of the first steps taken should be to add and remove extra system components (with the exception of IIS, which you will add later). If you have already installed IIS, use the Add/Remove Components Control Panel applet to remove it before continuing. A Web server needs very few components to operate. On a typical installation, the only component you should have checked is Terminal Services. If you decide to keep a component installed, only do so if you have a specific purpose to have that component installed.

Preparing the File System One best practice that has shown its importance many times in the past is the concept of having separate NTFS partitions for different types of files. For instance, you can create NTFS partitions as follows: ■

System Partition Contains the operating system and programs

■

Administrative Partition Contains logs, administrative tools, and other sensitive files

■

Data Partition Contains databases or other files related to the Web application

■

Web Partition Contains the contents of the Web application

The primary concern here is that without separate partitions, an attacker can more easily use directory traversal attacks, accessing files that are normally outside the bounds of the Web root but within the same partition. IIS has been victim to a number of these vulnerabilities, although every single one could have been prevented by using a separate partition for the Web root.When using separate partitions, you must ensure that every virtual directory in your Web site is also on the separate partition. Many Web sites that use a separate partition, yet they use the FrontPage Server Extensions located on the system drive.To address this issue, see the “Disabling or Securing the FrontPage www.syngress.com

730


Server Extensions” section later in this chapter for more information about moving the FrontPage Server Extensions. When building partitions, by default,Windows 2000 gives everyone full control over the entire partition. Immediately after creating a partition, you should set ACLs appropriate for the partition. For example, on the Administrative partition, you should only allow Administrators to access the data.To do this: 1. Right-click a drive in Windows Explorer and select Properties from the context menu. 2. Navigate to the Security tab, and remove all entries from the list. 3. Next, click the Add button, and select Administrators from the list. 4. Click the Add button, and click OK to exit the dialog box. 5. Make sure that Administrators have full permissions, as shown in Figure 13.1. Figure 13.1 Permissions for the Administrative Partition

Windows 2000 servers are less vulnerable to attack when administrators take the time to set proper NTFS permissions.While some attacks cannot be blocked with NTFS permissions alone, those attacks can at least be tracked through the use of file auditing.

Installing IIS After your partitions and directories are ready, you can install IIS. Rather than using the Add/Remove Programs applet on the Control Panel, you will create an answer file that allows you to customize how you want IIS installed.

www.syngress.com


731

NOTE While installing IIS from scratch on a new partition is usually best, it is not always a feasible solution. If you are unable to uninstall IIS to move it, you can manually relocate existing Webs by either modifying the path in the Home Directory tab of the Web properties in Internet Service Manager or by modifying the Path key in the metabase using adsutil.vbs as follows: Adsutil.vbs SET W3SVC/1/Root/Path “E:\www”. Note that you will need to modify the Path setting for each Web site you change.

To install IIS with custom options, create a text file named iis.txt with the following contents: [Components] iis_www = on

; World Wide Web Server

iis_common = on

; Common Files

iis_inetmgr = on

; Internet Information Services Snap-in

iis_ftp = off

; File Transfer Protocol (FTP)

ins = off

; NNTP Service

ims = off

; SMTP Service

iis_htmla = off

; Internet Services Manager (HTML)

iis_doc = off

; Documentation

fp_extensions = off

; FrontPage 2000 Server Extensions

iis_htmla = off

; Internet Services Manager (HTML)

fp_vid_deploy = off

; Visual InterDev RAD Remote Deployment Support

[InternetServer] ;PathFTPRoot=E:\FTP PathWWWRoot=E:\WWW

Note that you should adjust the settings in the file to match your particular requirements.The preceding configuration installs a basic WWW server to the e:\www directory. After creating the answer file, you are ready to run Sysocmgr.exe, which is a program that is used to install Windows 2000 components from an answer file. Sysocmgr is a command-line utility.To start Setup, go to the command prompt and type the following command: sysocmgr /I:%windir%\inf\sysoc.inf /w /u:c:\iis.txt

www.syngress.com

732


The preceding command assumes that the name of your answer file is located at c:\iis.txt.The /I part of the command specifies the master INF file that should be used. This command will install IIS without any user interaction. Sysocmgr also supports the following options: ■

/i: Specifies the name and path of the master sysoc.inf file.The installation source path is taken from here.This switch is required.

■

/u: Specifies the name and path of the answer file to be used.

■

/r Suppresses reboot (if reboot is required).

■

/n Forces the sysoc.inf to be treated as new.

■

/f Indicates that all component installation states should be initialized as though their installers had never been run.

■

/c Disallows cancellation during the final installation phase.

■

/x Suppresses the initializing banner.

■

/q For use with /u. Runs the unattended installation with the user interface.

■

/w For use with /u. Prompts the user to reboot when required instead of automatically rebooting.

■

/l Multilanguage-aware installation.

At this point, you will have a new Web site created.

SECURITY ALERT While installing service packs and hot fixes is something you should do on any system, when you install hot fixes on an IIS server is important. Although services packs do not need to be reapplied after adding or removing components, hot fixes do need to be reinstalled. For that reason, you should either apply or reapply any post service pack hot fixes after the server has all components installed, including IIS. Also, you should be aware that many updates are not always checked when using the various updates services or tools that Microsoft or others provide. Some of these updates might include: ■ ■

FrontPage Server Extensions 2000 http://msdn.microsoft.com/ library/en-us/dnservext/html/winfpse.asp FrontPage Server Extensions 2002 http://msdn.microsoft.com/ library/en-us/dnservext/html/fpse02win.asp

www.syngress.com

Keeping Your IIS Web Servers Safe • Chapter 13 ■ ■ ■ ■ ■ ■ ■ ■

733

MDAC, JET, and other database drivers www.microsoft.com/data XML http://msdn.microsoft.com/xml COM+ Search Microsoft’s Knowledge Base (KB) for the latest COM+ rollup package Windows Script Host http://msdn.microsoft.com/scripting Application Center www.microsoft.com/applicationcenter Commerce Server www.microsoft.com/commerceserver Content Management Server www.microsoft.com/cmserver SharePoint Portal Server www.microsoft.com/sharepoint

Remember also that some update tools will check for hot fixes for your products but will not always tell you when newer major versions are available.

Locking Down COM and Database Access Because Web servers often provide access to internal database systems or sensitive data, database and COM components should be properly locked down.This is particularly crucial when COM components or database connections run in the security context of privileged user accounts.While a properly configured firewall will eliminate some of these exposures, some items require additional configuration to be fully secured.

Securing ADO and ODBC Drivers The first step in securing your databases is to install the latest drivers and only keep those DSNs and drivers that you will specifically use. Driver updates often address numerous security issues and should be installed as soon as they have been tested in your environment. A default Windows 2000 installation has a number of default ODBC drivers that you can safely remove if you are not specifically using them. Because there is no way to delete ODBC drivers form the Data Sources (ODBC) Administrative Tool, you must manually remove unused drivers from the HKEY_LOCAL_MACHINE\SOFTWARE\ ODBC\ODBCINST.INI Registry key (see Figure 13.2). Note that subsequent driver updates might automatically restore these entries, so you should check this Registry key after installing updates.

Securing Jet Like ODBC, Jet installs a number of drivers that you probably won’t use.To remove them, delete any unused Jet engines and ISAM formats below the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet Registry key.

www.syngress.com

734


Figure 13.2 Drivers in the ODBCINST.INI Registry Key

Next, if you are using Jet, you should change the sandbox mode to a more secure setting. Sandbox mode prevents users from embedding sensitive commands, such as Shell in SQL queries.The possible sandbox modes are: ■

0 Sandbox mode is disabled.

■

1 Sandbox mode is only used with Access applications.

■

2 Sandbox mode is only used with non-Access applications.

■

3 Sandbox mode is used on all applications.

You should always use setting 3 to get the maximum protection. Set the HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\3.5\engines\ SandboxMode and HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\ engines\SandboxMode Registry keys to the value of 3, as shown in Figure 13.3. Another issue is that, by default, the text ISAM allows you to read and write any text file, potentially allowing an attacker to modify sensitive system files or scripts.To fix this, set the HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\ Engines\Text\DisabledExtensions Registry key to !txt (replacing txt with whatever text extensions you are specifically using). Note that the default value of this settings is !txt,csv,tab,asc,htm,html.

Securing Data Sources Some Windows applications install User, System, or File DSNs without notifying you that they are installed. If these DSNs are not used, you should delete them by opening www.syngress.com


735

the Data Sources (ODBC) Administrative Tool and clicking Remove for each unused driver (see Figure 13.4). Note that these data sources can also be removed by deleting the entries under the HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ ODBCI.INI Registry key. Figure 13.3 Jet Registry Settings

Figure 13.4 Remove Unused ODBC Data Sources

Disabling Remote Data Services (RDS) RDS allows a client to directly interact with an ODBC data source. Because this bypasses any filtering and rules you have implemented in your Web application, making this service available is normally not a good idea. Although RDS is reasonably secure on a default Windows 2000 installation, it can be further locked down by deleting the MSADC virtual directory and removing the following Registry keys:

www.syngress.com

736

Chapter 13 • Keeping Your IIS Web Servers Safe ■

HKLM\SYSTEM\CurrentControlSet\Services \W3SVC\Parameters\ ADCLaunch\RDSServer.DataFactory

■

HKLM\SYSTEM\CurrentControlSet\Services \W3SVC\Parameters\ ADCLaunch\AdvancedDataFactory

■

HKLM\SYSTEM\CurrentControlSet\Services W3SVC\Parameters\ ADCLaunch\VbBusObj.VbBusObjCls

Securing COM Components Some COM components provide features that might present a security risk if called from ASP pages. For example, the FileSystemObject can be used to gain access to any file on the system, given the proper NTFS permissions. Because of that, you should limit which COM components can be called from ASP pages. Remember that because we are talking about being hacked by insiders, one of the insiders could very well be a Web developer that has access to the Web root. It is also possible that an attacker could find a way to somehow upload a malicious ASP script to the Web root. You can secure COM components in many ways. Each way provides varying levels of control. For example, you can: ■

Delete the DLL or OCX file

■

Unregister the component

■

Set access permissions on the DLL or OCX file

■

Set access permissions on class ID information in the Registry

The most effective way to secure a COM component is, obviously, to completely delete the file itself.This absolutely prevents the object from being created, but, if you ever need it, getting it back means copying the file back onto the system. A slightly less extreme approach is to unregister the component using regsvr32.exe.The following command unregisters the Scripting Runtime DLL that includes the FileSystemObject: regsvr32 scrrun.dll /u

Note that the command removes all Registry entries for the DLL, preventing any COM objects in it from being created. However, you might have some administrative scripts that require the FileSystemObject, so you might not want to completely disable it. Another solution is to set NTFS permissions on the DLL or OCX to only allow administrators to read and execute the file.This effectively disables the component from being created by any user who is not an administrator. Another problem is that some DLL files contain several objects. For example, the scrrun.dll file contains the FileSystemObject as well as the Dictionary object. If you www.syngress.com


737

want to have precise control over these individual objects, you can do so by setting permissions on the class ID information located under HKEY_CLASSES_ROOT\CLISD in the Registry.When any COM component is created,Windows must gather information about the component from the Registry. If a particular user is not able to read the Registry key, the component cannot be created. By default, all users are able to read the Registry keys. For example, to secure the FileSystemObject, tighten permissions on the HKCR\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228} Registry key to only allow administrators read access. Note that this will limit who uses the FileSystemObject yet the Dictionary object will still be available to all users. Some components are easier to secure on a file level, while others, depending on how much precise control is required, are better secured through the Registry.Table 13.1 shows a list of potentially dangerous components and their Class IDs.Table 13.2 shows a list of components and their associated DLL or OCX files. Table 13.1 COM Registry Keys COM Object

Registry Key

Scripting.FileSystemObject HKCR\CLSID\{0D43FE01-F093-11CF-894000A0C9054228} WScript.Shell HKCR\CLSID\{72C24DD5-D70A-438B-8A4298424B88AFB8} WScript.Network HKCR\CLSID\{093FF999-1EA0-4079-95259614C3504B74}

Table 13.2 COM File Locations COM Object

Default File Location

Scripting WScript MSADO CDONTS

%SystemRoot%\System32\scrrun.dll %SystemRoot%\System32\wshom.ocx %ProgramFiles%\Common Files\System\ADO\msado15.dll %SystemRoot%\System32\cdonts.dll

In addition to securing components, you might want to also limit NTFS permissions on all COM files located on the system partition.You can produce a list of all COM files by using the following command: C:\>findstr /S /M /D:C:\ “DllRegisterServer” *.ocx *.dll *.exe

www.syngress.com

738


Finally, if you are not using Distributed COM (DCOM) on your server, you should disable it by setting the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\ EnableDCOM key to N.

Hardening TCP/IP Windows 2000 has a number of Registry settings that make a Web server more resilient to Denial of Service (DoS) attack.Table 13.3 shows the Registry values that should be set on a Windows 2000 Web server.

NOTE For more information about TCP/IP Registry parameters, see http://support .microsoft.com/default.aspx?scid=kb;EN-US;q120642. When setting these values, pay particular attention to how you enter EnableICMPRedirect, because many documents (including those from Microsoft) incorrectly use the plural value EnableICMPRedirects.

Table 13.3 TCP/IP Registry Values Registry Key HKLM\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters\SynAttackProtect HKLM\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters\EnablePMTUDiscovery HCLM\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters\NoNameReleaseOnDemand HCLM\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters\EnableDeadGWDetect HCLM\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters\KeepAliveTime HCLM\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters\PerformRouterDiscovery HCLM\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters\EnableICMPRedirect

Type

Value

REG_DWORD

2

REG_DWORD

0

REG_DWORD

1

REG_DWORD

0

REG_DWORD

300,000

REG_DWORD

0

REG_DWORD

0

Securing the Internet Information Service Now that you have a hardened Windows 2000 OS, you can focus on securing IIS itself. In its default state, IIS is vulnerable to a number of attacks. IIS must be hardened before it’s placed into production.To do this, you must complete the following tasks in order: www.syngress.com


739

1. Run the IIS Lockdown tool. 2. Secure Registry settings. 3. Secure WebDAV. 4. Secure FrontPage. 5. Secure default sites. 6. Secure the master WWW properties. 7. Secure sites, files, and directories. This process should be completed in this specified order, because some of the steps build upon the results of previous steps.

Running the IIS Lockdown Wizard Microsoft provides a free tool for securing IIS Web servers, called the IIS Lockdown wizard.The wizard works by using templates to accomplish the basic steps to harden an IIS server.The IIS Lockdown wizard also installs URLScan, which is a tool for blocking certain types of Web requests based on certain HTTP elements. To install the IIS Lockdown wizard, first download the most recent version from http://microsoft.com/technet/security/tools/tools/locktool.asp.When you first run the tool, you will be presented with introduction and license agreements. Click Next until you arrive at the screen shown in Figure 13.5. Figure 13.5 Internet Information Services Lockdown Wizard—Select Server Template

Select an appropriate server template, and check the View template settings box to be able to verify the settings on the next screen. Click Next, and you will see the screen shown in Figure 13.6.

www.syngress.com

740


Figure 13.6 Disable Service Using IIS Lockdown

The screen shown in Figure 13.6 gives you the opportunity to disable the various services of IIS. Any services left unchecked will be disabled, unless the Remove unselected services box is checked, in which case the services will also be uninstalled from the system. Check only the services that you will specifically use and check the Remove unselected services box. After you click Next, you will be warned that you are removing services. Click Yes to display the screen shown in Figure 13.7. Figure 13.7 Script Maps

NOTE If a service is not installed, it will appear grayed out. Consequently, this screen is only useful for removing IIS components, not adding new components. If you want to add an IIS component, use the Add/Remove Programs tool in the Control Panel.

www.syngress.com


741

The screen shown in Figure 13.7 allows you to disable unused ISAPI extension mappings.This step is a crucial part of the security process, because, historically, these ISAPI extensions have been the source of many IIS vulnerabilities. Note that this step not only removes the default extension mapping but also remaps them to a special 404.dll extension that always returns a 404 error.This step helps prevent the extension mappings from returning to their default state. Note that the IIS Lockdown will only replace existing extension mappings. If an extension mapping does not exist, the IIS Lockdown wizard will not create it. Select the script maps you want removed, and click Next to access the screen shown in Figure 13.8. Figure 13.8 Additional Security Settings

The screen shown in Figure 13.8 allows you to delete unused virtual directories, tighten NTFS permissions, and disable WebDAV. Normally, you should check all items unless you have a specific purpose to do otherwise. The first portion of the screen determines which virtual directories the wizard will remove from the default Web site. Note that only the virtual directories will be removed; all physical directories will remain intact. The next step is to restrict NTFS permissions for anonymous IIS users.This is done by creating two new local groups—Web Anonymous Users and Web Applications. All anonymous user accounts are added to these groups.The groups will be denied access to all *.exe and *.com files in the %Windir% directory and its subdirectories. If the Writing to content directories option is checked, anonymous Web users are also denied access any directories published with the WWW service. Finally, this screen allows you to disable Web Distributed Authoring and Versioning (WebDAV) capabilities. By default, IIS accepts any WebDAV authoring commands sent from a client. Users with sufficient permissions can use a WebDAV client to modify

www.syngress.com

742


server content.While WebDAV provides useful remote authoring capabilities, the lack of a granular security feature often makes it a poor solution for a public Web server. The greatest problem with WebDAV is that it significantly increases a server’s exposure to attack by providing a number of new HTTP methods and headers. More HTTP methods and headers means a greater attack surface.

WARNING The current version of IIS Lockdown disables WebDAV by setting NTFS permissions that deny access to httpext.dll. However, this method does not block WebDAV methods such as PUT and DELETE, and denying access to httpext.dll might prevent it from being updated with hot fixes and service packs. Windows Security Rollup 1 (SRP1) introduced a new Registry setting at HKLM\SYSTEM\ CurrentControlSet\Services\W3SVC\Parameters\DisableWebDAV that is now the preferred method for securing WebDAV. Instead of using the IIS Lockdown wizard to secure WebDAV, you might want to leave this item unchecked and manually set this Registry value to 1 after running IIS Lockdown.

The final screen, shown in Figure 13.9, allows you to install the URLScan filter on your Web server. URLScan blocks many malicious Web requests and should always be installed. URLScan is covered in more detail in the “Configuring URLScan” section later in the chapter. Check this box and click Next for the IIS Lockdown wizard to implement the configuration you have selected. Figure 13.9 Install URLScan

When run on a hardened OS, the IIS Lockdown wizard creates an IIS server that is reasonably safe to put on the Internet. But you can take many other steps to further secure IIS. www.syngress.com


743

Securing IIS Global Settings While most IIS configuration settings are stored in the metabase, some global settings are set in the Registry. By default, many of these settings are sufficiently secure. But when auditing a server, be sure the settings are kept at the recommended values.The settings and their recommended values are as follows: ■

■

■

■

AllowSpecialCharsInShell This setting allows or prevents special shell characters from being allowed as parameters for CGI scripts and executables. ■

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\W3SVC\Parameters

■

Type: REG_DWORD

■

Recommended Value: 0 (default)

LogSuccessfulRequests This setting enables or disables IIS logging functions and should always be set to 1. ■


■

Type: REG_DWORD

■


SSIEnableCmdDirective This setting allows or blocks the use of the #exec cmd directive in server-side includes without affecting other server-side include directives. ■


■

Type: REG_DWORD

■


AllowSpecialCharsInShell This setting allows or prevents the special shell characters from being allowed as parameters for CGI scripts and executables. ■


■

Type: REG_DWORD

■


www.syngress.com

744


■

AllowGuestAccess This setting enables or disables guest access to the Web service. If you want to authenticate all users who access the server, such as in an intranet scenario, you can set this value to 0. ■


■

Type: REG_DWORD

■

Recommended Value: Depends on server role

EnableSvcLoc This setting allows or prevents the MMC snap-in from seeing an IIS server. ■


■

Type: REG_DWORD

■

Recommended Value: Depends on server role

Securing the Default and Administration Web Sites When IIS is first installed, two Web sites are created—a default Web site and an administration site. Both of these sites can be a security risk and should be disabled. As you can see in Figure 13.10, the default Web site includes a number of default virtual directories, many of them mapped to the system drive, which is considered a poor practice. Some of these virtual directories expose potentially dangerous features that many sites will not use and some of them are nothing more than samples, which have no place on a production server. Delete any of the following virtual directories if they appear in the default Web site, unless you have a specific purpose for them. If you leave any of them, be sure to limit who can gain access to them: ■

Scripts

■

IISHelp

■

IISSamples

■

Printers

■

IISAdmin

■

IISAdmpwd

■

MSADC

■

PBServer

■

PBSData

www.syngress.com

Keeping Your IIS Web Servers Safe • Chapter 13 ■

RPC

■

CertSrv

■

CertControl

■

CertEnroll

745

As a further precaution, you should completely remove the following directories from the file system: ■

C:\inetpub\scripts

■

C:\winnt\help\iishelp\iis

■

C:\inetpub\iissamples

■

C:\winnt\Web\printers

■

C:\winnt\system32\inetsrv\iisadmin

■

C:\winnt\system32\inetsrv\iisadmpwd

Figure 13.10 Default Web Sites

You should disable the default Web site by setting the IP Restrictions to deny all access from the outside and finally stopping the site. Further measures you can take to secure the site include changing the port to something besides 80, setting the host header to LocalHost, and disabling anonymous access to the site. The Administrative Web site provides sensitive HTML-based IIS administration functions. Although by default, access to this site is limited to LocalHost, if you are not using HTML-based administration, you should completely remove this site. If you are using HTML-based administration, take measures to further secure it by setting more strict IIS and NTFS permissions. www.syngress.com

746


NOTE Why all the trouble disabling the default site when you can just remove it? While removing the site might seem a better strategy, there are valid reasons to keep the site intact. First, many third-party Web applications that install virtual directories will do so by default on the first Web site (W3SCV1), potentially exposing unsecured and/or sample applications. Second, when you remove the default Web site in IIS and there are no other sites configured, the site returns once you reboot. Furthermore, if you delete the site and then create a new one, the new site will, under some conditions, inherit all the settings the old one had. Consequently, you are simply better off leaving the site there, disabling it, and creating your own Web sites starting with W3SVC2. Although the default site is unsafe, by disabling it you can at least contain the exposure.

Disabling Internet Printing Web-based printing is a Windows feature that allows intranet users to access a server’s printers via IIS.While this is convenient, it adds unnecessary exposure to a production Web server. Removing the Printers directory on the default Web site disables Webbased printing, but as soon as you reboot, the Printers virtual directory is replaced.To completely disable Web-based printing, you must set Group Policy to disable Web-based printing.To accomplish the latter, follow these steps: 1. Open the Local Group Policy for the Web server by typing mmc.exe from the Run menu.This gives you a blank console to which you can add the Group Policy snap-in. 2. From the Console Menu, select Add/Remove Snap-in and click Add to bring up a list of available snap-ins. 3. Select Group Policy from the list, and, when prompted, click Finish to accept Local Computer as the Group Policy Object. 4. Back in the MMC console, browse to Local Computer Policy\Computer Configuration\Administrative Templates\Printers and set the Web-based printing policy to Disabled (see Figure 13.11). Note that if you do not want to use Group Policy, this value can be set directly by setting the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\ WindowsNT\Printers\DisableWebPrinting Registry key to 1.

www.syngress.com


747

Figure 13.11 Disable Printing through Group Policy

Disabling or Securing the FrontPage Server Extensions The FrontPage Server Extensions (FPSE) provide convenient remote Web authoring features, but they have a bad reputation for being insecure. But historically, most FrontPage problems have been more an issue of poor configuration than anything else. Although FPSE do increase the attack surface of a Web server, you should know exactly what the risks are so that you can properly secure them if necessary for your environment. The risks of installing the FPSE are: ■

They expose information about a Web server that can be used to facilitate other attacks.

■

They provide an authentication prompt allowing brute force password guessing.

■

They require a virtual directory with execute permissions.

■

They are installed on the system partition with no way to reinstall them on a separate partition.

■

Log files sometimes lack detail and you cannot set where they are stored.

■

The FPSE run in process with IIS (inetinfo.exe), which runs under the SYSTEM account, increasing the risk if a buffer overflow is discovered.

Another risk is that the FPSE security model is another layer atop IIS and NTFS security and can be somewhat confusing. FPSE access is based on the NTFS permissions

www.syngress.com

748


on the root directory of the Web site. A user must have write permissions to author a FrontPage Web and change permissions to administer it. If you must use the FPSE, you should identify a specific set of IP addresses that will be used to author and administer sites. If you can do this, set IP restrictions on each of the _vti virtual directories to limit unauthorized access.You should also enable logging of authoring actions and regularly review and archive the log files located in the _vti_log directory of each FrontPage Web. Moving the FrontPage binaries to a different partition is a bit more difficult.To do this, you must move the contents of the C:\Program Files\Common Files\Microsoft Shared\Web server extensions\40 directory (or C:\Program Files\Common Files\ Microsoft Shared\Web server extensions\50 if using FPSE 2002) to a new location on your Web partition. Next, you must open Regedit.exe and search for all instances of the old path, replacing them with the new path. Finally, you need to use metaedit.exe (available at http://support.microsoft.com/default.aspx?scid=http://download.microsoft .com/download/iis50/Utility/5.0/NT45/EN-US/MtaEdt22.exe) to replace all the old paths in the metabase with the new path. Reboot the server and the process should be complete. Remember that every time you install a hot fix or service pack, you must manually update theses files in their new location. If you want to completely remove the FPSE, you must first open the Internet Services Manager and right-click each Web site, select All Tasks, and then select Remove Server Extensions. Next, remove any _vti or _private directories in any Web sites. Finally, you should remove the FPEXED.dll file from the ISAPI Extensions tab on the master Web site properties. One important point to remember is that you should never install the FPSE on a FAT partition. If you do, anyone will be able to author and administer the FrontPage Web site without having to enter a password.

Configuring URLScan URLScan is installed as part of the IIS Lockdown tool, but is also updated separately. You can download the lastest version of URLScan from http://download.microsoft .com/download/iis50/Update/2.5/NT45/EN-US/URLSCAN.EXE. Run the installation file to update URLScan. After installation, you should edit the URLScan.ini file to customize it for your site. See www.iissecurity.net/archive/urlscan.ini for an example urlscan.ini that we use as the basis for all IIS servers we secure.The upcoming section describes the various URLScan settings.

www.syngress.com


749

The [Options] Section The [Options] section is where you can set many of the primary options that affect how URLScan functions.The settings are: ■

UseAllowVerbs This setting determines whether the [AllowVerbs] section is used, which only accepts the listed HTTP verbs, or the [DenyVerbs] section is used, which accepts all but the listed HTTP verbs. Set this value to 1 to use the [AllowVerbs] section.

■

UseAllowExtensions This setting determines whether the [AllowExtensions] section is used, which only accepts the listed file extensions, or the [DenyExtensions] section is used, which accepts all but the listed file extensions. Set this value to 1 to use the [AllowExtensions] section.

■

NormalizeURLBeforeScan If this value is set to 1, URLScan does its analysis after IIS has decoded and normalized the request URL. If set to 0, URLScan will see the raw URL sent by the client.While this setting is more secure set to 1, it does mean that URLScan might be vulnerable to the same encoding and directory traversal attacks as IIS.

■

VerifyNormalization This setting specifically addresses double encoding attacks by decoding the URL twice, and rejecting it if the two URLs do not match.

■

AllowHighBitCharacters If set to 0, this setting blocks any URLs that contain characters outside the ASCII character set. Set this value to 1 if you must use non-ASCII character sets on your Web site.

■

AllowDotInPath Because URLScan determines a file extension differently than IIS does, it is sometimes possible to fool URLScan into permitting a request for a blocked file extension. For example, if you make a request for /default.asp/nothing.htm, IIS will interpret this as a request for default.asp, with the default.htm portion passed to the PATH_INFO variable.This is the default behavior for scripts and executables. However, because URLScan does not know what IIS will interpret as script or executable, it sees this as a request for nothing.htm. If you have URLScan configured to allow HTM files but block ASP files, this URL will still be allowed.The only exception to this is that URLScan will recognize the first .com, .exe, or .dll extensions it sees in the path. URLScan compensates for this by allowing you to block any request that has more than one period. However, this prevents you from having any directory names with periods. Just remember that if this setting is 0, that file extension blocking will be partly ineffective. www.syngress.com

750


AlternateServerName This setting allows you to change the HTTP Server header in all responses. For example, you could set the Server header to “Apache/1.3.14 (Unix) (Red-Hat/Linux)”. Note that this is an obscurity tactic and may or may not be effective in blocking an attack. Note that this setting will not have any affect if RemoveServerHeader is set to 1.

■

RemoveServerHeader When this setting is set to 1, URLScan will completely remove the HTTP Server header from all outgoing responses. Note that this setting, when enabled, will also remove any Server header set through the AlternateServerName setting. Note also that both this setting and AlternateServerName can interfere with some applications, such as the FrontPage Server Extensions.

■

EnableLogging When this setting is set to 1, a log file named URLScan.log will be created in the same directory as URLScan.dll.The log will contain all rejected URLs along with a reason for being rejected.

■

PerProcessLogging When this setting is set to 1, URLScan will create a separate log file for each process and append the process ID to the log file name.

■

PerDayLogging When this setting is set to 1, URLScan will create a new log file each day.

■

AllowLateScanning This setting allows URLScan to run as a low priority filter, rather than the default setting of high priority.This is required in some cases in which other ISAPI filters modify the URL. For example, the FrontPage Server Extension ISAPI filter FPEXED.DLL might modify the extension for requests to the FrontPage binaries so that requests for shtml.exe become requests for shtml.dll (or vice versa, depending on the FPSE version). Note that if you set this to 1, you must also adjust the filter priority in the master WWW properties.

■

RejectResponseUrl This setting allows you to redirect all rejected URLs to a specific location.The default location is /, which will return a 404 error to the client. Note that this shows up in the IIS logs as a failed request for /, with the original URL logged as the QueryString. One interesting feature with this setting is that you can redirect to an ASP script or an executable, even if you specifically block these extensions with URLScan.

When rejecting a URL, URLScan creates the following server variables that are accessible to your custom reject URL:

www.syngress.com


HTTP_URLSCAN_STATUS_HEADER Reason for rejection

■

HTTP_URLSCAN_ORIGINAL_VERB HTTP verb used in the request

■

HTTP_URLSCAN_ORIGINAL_URL Original URL requested

751

Note that when URLScan rejects a request, it changes the HTTP verb to GET, sets any headers listed in the [DenyHeaders] section to a blank string, sets the content-length header to zero, then sets the URL to that specified with RejectResponseURL, with the original URL as the query string.The request is then sent back to IIS to process. So, for example, suppose the following request is sent: POST /_vti_bin/_vti_aut/author.dll HTTP/1.1 MIME-Version: 1.0 User-Agent: MSFrontPage/4.0 Accept: auth/sicily Content-Length: 22 Content-Type: application/x-www-form-urlencoded X-Vermeer-Content-Type: application/x-www-form-urlencoded Connection: Keep-Alive

method=list+documents

Now if you have your URLScan.ini file configured to reject DLL files and deny X-Vermeer-Content-Type headers, the request will be rewritten to the following: GET

/?~/_vti_bin/_vti_aut/author.dll HTTP/1.1

MIME-Version: 1.0 User-Agent: MSFrontPage/4.0 Accept: auth/sicily Content-Length: 0 Content-Type: application/x-www-form-urlencoded Connection: Keep-Alive

The IIS log file, if recording query strings, will appear as follows: 2002-07-17 01:47:15 127.0.0.1 - W3SVC1 M1 127.0.0.1 80 GET ~/_vti_bin/_vti_aut/author.dll 404

Notice that the requested resource was , the default value for RejectResponseURL. You can also set RejectResponseURL to the special value /~* to cause URLScan to log requests in the URLScan.log file, but still allow the requests to go through.This

www.syngress.com

752


is particularly useful when first installing URLScan to identify any potential problems with the configuration.

UseFastPathReject This setting changes the way URLScan handles rejected requests by having it set the Win32 error code to ERROR_FILE_NOT_FOUND and returning SF_STATUS_REQ_ERROR to IIS.This will cause IIS to immediately reject the request without further processing. Note that doing this will prevent any further processing by ISAPI filters, custom IIS error handling, and recording the request in IIS log files. However, the rejected request will still be recorded in the URLScan.log file.The benefits of this setting are that the IIS logs do not contain all the URLScan rejected URL’s and results in faster processing of rejected URL’s.

[AllowVerbs] Section If UseAllowVerbs is set to 1, only HTTP verbs listed in the [AllowVerbs] section will be allowed.

[DenyVerbs] Section If UseAllowVerbs is set to 0, only HTTP verbs not listed in the [DenyVerbs] section will be allowed.

[AllowExtensions] Section If UseAllowExtensions is set to 1, only requests for the file extensions listed in the [AllowExtensions] section will be allowed.

[DenyExtensions] Section If UseAllowExtensions is set to 0, only requests for the file extensions not listed in the [DenyExtensions] section will be allowed.

[DenyHeaders] Section Any requests containing HTTP headers listed in the [DenyHeaders] section will be rejected.

[DenyUrlSequences] Section Any URLs containing strings in the [DenyUrlSequences] section will be rejected. See the sample urlscan.ini file mentioned earlier for suggested values for this section.

www.syngress.com


753

[RequestLimits] Section The [RequestLimits] section allows you to set maximum lengths for various parts of incoming requests.The following settings are available: ■

MaxAllowedContentLength The maximum value allowed for the Content-Length header.The default value is 30,000,000 bytes (about 30MB). This value can be reduced significantly, especially if you are not allowing uploading files via HTTP.

■

MaxQueryString This setting specifies the maximum length of the query string.The default is 4,096 characters.This value should be reduced to a more realistic setting.

■

MaxURL This setting specifies the maximum URL length allowed.The default value is 260.This value can be reduced to the length of the longest URL on your site.

The [RequestLimits] section can also be used to limit the allowed length of any HTTP header by creating a setting of “Max–” plus the value of the HTTP header. For example, to limit the length of the HTTP Referrer header to 50 characters, create the following setting: Max-Referrer=50

Note that a maximum setting of zero means that URLScan will not enforce maximum lengths.To completely deny a specific header, use the [DenyHeaders] section. See the example urlscan.ini file mentioned earlier for a list of possible HTTP headers.

Securing Web Sites After IIS is secured, you can begin structuring and securing individual Web sites.The site security process should start in the earliest stages of site planning.You should work with developers early to establish a Web structure that will allow you to set the greatest level of security.

Building a Directory Structure As you secure Web sites, the directory structure can have a considerable effect on your security strategy. Start by creating a base directory that will be the root directory for all Web content.This base Web directory is roughly equivalent to the c:\inetpub directory that IIS uses by default. Depending on the complexity and number of sites on the server, your Web root directory structure will vary. One strategy is to create a directory for each organizational unit (company, department, hosting customer, and so forth)

www.syngress.com

754


followed by a directory for each Web site.Within each Web site directory, there should be one directory for site content and at least one other directory for related content that should not be publicly available. See Figure 13.12 for a sample directory structure using this strategy. Figure 13.12 Sample Directory Structure

In Figure 13.12, two departments—Sales and Support—are publishing content on the intranet server. Note the clear division of content, making NTFS permissions easier to sort out. Next, each department has a directory for each Web site. In sales, there are two sites—OrderEntry and Reporting. Below those directories are at least two others— one for the Web content and one for supporting files.This type of structure is important because it causes Web authors to think about which files can be placed outside a Web root. For example,Web authors commonly place files such as MS Access databases or form post results within the Web root. It is also quite common for developers to place backup or testing files in a Web root and later forget to delete them. Other directories you might consider placing here are staging, testing, development, backups, stats, and temp.

Setting Master WWW Properties When you create new Web sites under IIS, they are assigned a default configuration based on the master WWW properties. Because of this, you should make sure that these master settings are as secure as possible. How secure you make these default settings depends on how your Web server is used. One aggressive strategy is to completely remove every permission, disallow anonymous users, disallow any authentication methods, and deny access to any IP address except LocalHost.When a new Web site is created, it is effectively useless and must explicitly be given the settings required to operate.This strategy is extreme but works well when each Web site has very different configurations, or if administrators have bad habits of creating sites and not securing them. However, if each Web site on the server is roughly the same, you might opt for a more conservative approach by giving each site enough permissions to operate, yet still meet the requirements of your organization’s security policy. www.syngress.com


755

To secure the master WWW properties, open the Internet Services Manager administrative tool and right-click the Web server’s system name. Select Properties from the menu, and you will see the dialog box shown in Figure 13.13. From this dialog box, select WWW Service and click Edit. Figure 13.13 Master WWW Properties

The first tab you will encounter on the Master WWW properties dialog box is the Web Site tab shown in Figure 13.14.The only setting on this tab that you might want to change is the Connection Timeout. 900 seconds (15 minutes) is a long wait for a TCP connection to timeout, so you might want to consider using a much lower number here. Also, ensure that Enable Logging is checked and W3C Extended Log File Format is selected. Next, click the Properties button to bring up the Extended Logging Properties dialog box, as shown in Figure 13.15. Figure 13.14 Web Site Properties

www.syngress.com

756


Figure 13.15 Extended Logging Properties—General Properties

On the Extended Logging Properties dialog box, you might want to consider using local time for file naming and rollover. IIS always records log entries in UTC time, which will be determined based on your system clock and time zone settings. However, by using local time for file naming and rollover, the log files themselves will be cut off at midnight local time and a new log file created. From this dialog box, you might want to relocate your log files to a different location.The administrative partition mentioned earlier is a good location for storing IIS log files. The Extended Properties tab (shown in Figure 13.16) allows you to select the type of information you want to record in the log files. From a forensics point of view, every field can provide useful information and you should check everything unless you are particularly short on disk space. Figure 13.16 Extended Logging Properties—Extended Properties

After configuring your logging options, click OK to return to the Master WWW properties dialog box. Change to the ISAPI Filters tab, as shown in Figure 13.17. From the ISAPI Filters tab, you can add and remove ISAPI filters. Any ISAPI filters installed here are globally installed and affect all Web sites on the server.You should www.syngress.com


757

always remove the filters that you are not specifically using.Table 13.4 shows the default ISAPI filters and their functions. Figure 13.17 ISAPI Filters

Table 13.4 ISAPI Filters ISAPI Filter

Function

Sspifilt Compression Md5filt Fpexedll.dll

Secure Sockets Layer (SSL) Server-side HTTP compression Digest Authentication FrontPage Server Extensions legacy client compatibility

On the Home Directory tab, you should uncheck all permissions except Read and be sure that logging visits is enabled, as shown in Figure 13.18. Set Execute Permissions to None. Next, click the Configuration button to open the Application Configuration dialog box. Because application mappings should already have been taken care of by IIS Lockdown, click the App Options tab, as shown in Figure 13.19. On the App Options tab, the most important setting is that you uncheck the Enable parent paths box.This prevents ASP pages from including files from paths outside the Web root. All other settings on this tab depend on your particular application, but you might want to reduce the timeouts if your application will allow. Now, select the App Debugging tab shown in Figure 13.20. On this tab, be sure that both debugging options are unchecked and that Send text error message to client is selected. For the actual text error, you can use the default message or enter a custom message.This step is important because it prevents sending error messages to a client that might contain sensitive information. Click to return to the Master WWW properties dialog box.

www.syngress.com

758


Figure 13.18 Home Directory

Figure 13.19 App Options

Figure 13.20 App Debugging

www.syngress.com


759

The next concern in the Master WWW properties dialog box is the authentication methods used. Select the Directory Security tab shown in Figure 13.21 and click the Edit button in the Anonymous access and authentication control section.This will bring up the Authentication Methods dialog box, shown in Figure 13.22. Figure 13.21 Directory Security

Figure 13.22 Authentication Methods

What you set in the Authentication Methods dialog box depends on the typical role of your IIS server. If you typically provide public Web sites, you should select Anonymous access and disable all other authentication methods. If the server typically servers authenticated users, disable Anonymous access and check only the authentication methods you will be using. See the “Authenticating Users” section later in this chapter for more information about the various authentication methods. At this point, you can click OK and close the Master WWW properties dialog box. However, not all Web properties have been set. Some properties are not available in the Internet Services Manager, so you must set them directly using the adsutil.vbs script located in the AdminScripts directory of your IIS installation. Open a command

www.syngress.com

760


prompt, change to the AdminScripts directory on your system, and enter the following commands: adsutil.vbs SET W3SVC/AllowPathInfoForScriptMappings 0 adsutil.vbs SET W3SVC/AspAllowOutOfProcComponents 0 adsutil.vbs SET W3SVC/AspErrorsToNTLog 1 adsutil.vbs SET W3SVC/AspKeepSessionIDSecure 1 adsutil.vbs SET W3SVC/AspLogErrorRequests 1 adsutil.vbs SET W3SVC/CreateCGIWithNewConsole 0 adsutil.vbs SET W3SVC/Realm "Protected Area" adsutil.vbs SET W3SVC/SSIExecDisable 1 adsutil.vbs SET W3SVC/UseHostName 1

At this point, your Master WWW properties are properly configured, and every new Web site will automatically inherit these default settings.

Securing by Content Type Segmenting your Web content by type is an effective strategy that is easy to neglect. Segmentation facilitates precise control over IIS as well as NTFS permissions.The main reason for content segmentation is that best practices dictate that you always assign the least privilege required for your Web content. However, different types of content have different permission requirements. By grouping content by type, you can ensure that any one directory does not have more permissions than necessary. Further, grouped content is easier to audit and discrepancies can quickly be spotted.

Static Content Static content is the easiest to secure because it not much of a security risk. Static content is any Web content that is sent without any server-side processing.This includes HTML, images, text files, or any other file that does not have an ISAPI extension mapping. To secure static content, simply give Read access with no Execute or Script permissions, as shown in Figure 13.23.

Script Content Script content is any nonexecutable that is processed by the server before sending to the client.This includes ASP, Perl, and PHP scripts.To execute properly, you need to set the Execute Permissions to Scripts only. Note that you do not need any other permissions, including Read, for scripts to work properly.You should never allow Write permissions to a directory with Script permissions.This would allow any anonymous Web user to upload and execute server-side scripts. See Figure 13.24 for a recommended configuration for script content. www.syngress.com


761

Figure 13.23 Static Content Settings

Figure 13.24 Script Content Settings

WARNING When you disable Read access to a virtual directory, you also disable the ability for IIS to locate the default document. When you disable Read access to a scripts directory, you should ensure that all links point to specific scripts in that directory (such as /scripts/default.asp) and not to the directory name itself (such as /scripts/).

Executable Content An executable is any binary file that can be executed by the file system.This includes EXE, COM, and ISAPI DLL files. Executable content poses the greatest risk, because, if a directory allows executables, anyone can run a program in that directory.This is especially a www.syngress.com

762


risk when combined with a vulnerability that allows directory traversal, such as the popular Unicode exploit.This vulnerability allowed anyone to reference a file in a different directory, making IIS believe it was executing a file in the current directory. You should avoid using executable directories if possible, but if you must have executable content, be sure to never allow any other permissions on the same directory. See Figure 13.25 for the recommended settings on an executable directory. Note that when allowing executables to run, you also allow scripts to run. If you want to disable this, you must remap all script extensions for the directory. Figure 13.25 Executable Content Settings

Writeable Directories Write permissions to a virtual directory can be very dangerous and are often used more than necessary.Write permissions mean that anyone can upload files to a Web server. If someone is able to write a file and then execute it, this could quickly lead to a Web server compromise.Very few situations call for a virtual directory to have Write permissions. For example, suppose you have a Web form that POSTs to an ASP page that in turn saves the results to a text file in the same directory. Many administrators mistakenly give Write access to the directory, thinking it is required. But in fact,Write permissions are only required when the client is writing directly to the directory. An ASP page or any other server-side application can write to the file system without IIS allowing Write permissions on the virtual directory. Allowing Write really means you are allowing the HTTP PUT method to be sent by a client, something that the average Web browser is not even capable of performing. An ASP page that uses an ActiveX component to allow uploading or that writes to an IIS directory does not need IIS Write permissions. So, when do you need Write permissions? For most client applications, you will never need it. In fact, the only time you really need Write access is if you are allowing www.syngress.com


763

authors to upload content directly via WebDAV. Remember that IIS Write permissions allow users to directly write to a directory. IIS, ASP code, or CGI executables do not need IIS Write permissions.

Include Files Using shared code libraries is a good programming practice, but many times the libraries are used in an unsecure manner. For example, many programmers give include files the .inc extension.The problem with this is that .inc is not a mapped extension, and anyone requesting these files will be able to view the full source code, which might contain sensitive information you don’t want everyone to see. One interesting aspect of includes is that you can actually make them more secure than any other types of files. Because include files are called from within other ASP scripts, IIS does not need any permissions at all to use them.You can even use IP restrictions on include directories to prevent direct access to them.You can also map all file extensions to 404.dll using the wildcard character.Wildcard mappings cause all extensions to be handled by the same ISAPI extensions. In this case, because no one should ever request an include file directly, you can have all requests to that directory return a 404 error, yet your ASP pages will still be able to properly use include files. Configure wildcard mapping by opening the properties of your includes directory and clicking the Configuration button on the Home Directory tab. Remove all existing script mappings, and click New to display the dialog box shown in Figure 13.26. Figure 13.26 Wildcard Script Mappings

NOTE Some security documents recommend using .asp extensions for include files or mapping .inc to asp.dll. However, because all file extensions are included in the wildcard mapping, if you follow this configuration it does not matter which extension is used.

In the Add/Edit Application Extension Mapping dialog box, click Browse to locate 404.dll that IIS Lockdown installed in the %SystemRoot%\System32\Inetsrv www.syngress.com

764


directory. For the file extension, enter the asterisk character (*). Click OK to save your settings.With this configuration, any files in the directory are protected from direct client access.

The Home Directory The home directory is the root directory of a Web site that is usually the first visited when browsing to a Web site. But for many sites, the home directory is one place where Web developers tend to break the rules of content segregation. It is not uncommon to see a mixture of scripts, images, include files, and static content in the root directory of a Web site.The home directory creates a unique situation that requires special care in securing. Most notable about the home directory is that it is the most likely to take the brunt of attack from worms, vulnerability scanners, and script kiddies.This is simply because every site has to have a home directory. Many Web sites require Script permissions on the home directory, because it contains a default.asp script. Further, many home directories also require Read permissions so that a user can browse to the Web host and be redirected to the default document in the home directory. For example, most users will prefer to type the URL www.example.com rather than www.example.com/default.asp.While combining Script permissions with Read permissions is not necessarily a bad thing, it is not the most preferred strategy either. The best way to secure the home directory is to use it as little as possible. Move as much content as possible out of the home directory and into dedicated directories for that particular type of content. Go ahead and allow Read and Script permissions on the Home Directory tab, as shown in Figure 13.27, but remove Read from the individual scripts in the directory. Figure 13.27 Home Directory Settings

www.syngress.com


765

Another unique aspect of the home directory is that it often contains the Global.asa file, which might contain sensitive information, such as database connection strings. For this reason, Global.asa is an attractive target for attackers. Normally, IIS denies requests for Global.asa, which is accomplished by mapping the .asa extension to asp.dll. However, a vulnerability in asp.dll might someday allow for an attacker to view this file. A better solution is to map ASA files to 404.dll as shown in Figure 13.28. Figure 13.28 Remapping ASA Files

Content segregation is an effective strategy for increasing Web site security. One of the best benefits is that it forces you to think before placing a file on your Web site. Segregation facilitates tight control over Web content.

Authenticating Users Another consideration when segregating content is how to control access to specific files. A user cannot access a Windows 2000 server through any means unless the user has been authorized, even when anonymously browsing an IIS site.The following list shows the supported authentication methods: ■

Anonymous

■

Basic

■

Digest

■

Integrated Windows (NTLM and Kerberos)

■

Client Certificate Mapping

Access control can be set on the site, directory, or file level.To control access to a resource, open the Internet Services Manager, and select the properties for the resource. Select the Directory Security tab, and click the Edit button in the Anonymous access and authentication control section.This will bring up the Authentication Methods dialog box, as shown in Figure 13.29.

www.syngress.com

766


Figure 13.29 Authentication Methods

Using Anonymous Authentication If the Anonymous access box is checked in the Authentication Methods dialog box (see Figure 13.29) and the anonymous user has proper NTFS permissions for the resource, any user connecting to the Web site will have access to the resource. Anonymous authentication is the most commonly used method on the Internet. It is used for public Web sites that have no concern for user-level authentication. Using anonymous access, companies don’t have to maintain user accounts for everyone who will be accessing their sites. Anonymous access works with all browsers and network configurations. While many do not consider anonymous access to be a form of authentication, IIS does run all HTTP and FTP requests in the security context of a Windows 2000 user account named IUSR_computername, in which jomputername is the server’s assigned system name.This user account is a member of the Everyone, Guests, Users, and Authenticated users groups. While anonymous authentication is the easiest method to implement, it provides no true record of who is accessing the intranet site.To record this information, you must consider one of the other authentication methods—basic authentication, digest authentication, integrated Windows authentication, or client certificate mapping.

Using Basic Authentication Basic authentication works by prompting a Web site visitor for a username and password. It is widely used because most browsers and Web servers support it.The benefits are: ■

Works through proxy servers

■

Is compatible with nearly every Internet browser

■

Allows users to access resources that are not located on the IIS server

■

Lets you use NTFS permissions on a user-by-user basis to restrict access; unlike anonymous access, provides each user with a unique username and password

www.syngress.com


767

But, basic authentication also has some drawbacks, including: ■

Information is sent over the network as clear text.The information is encoded with base64 encoding (see RFC 1521 for more information on base64 encoding), but it is sent in an unencrypted format. Any password sent using basic authentication can easily be decoded.

■

By default, users must have the Log On Locally right to use basic authentication.

■

Basic authentication is vulnerable to replay attacks.

When using basic authentication, traffic should always be encrypted. Normally, this would involve using SSL, but, for Intranet traffic, you can also use IPSec to encrypt traffic. Users authenticating with basic authentication must provide a valid username and password.The user account can be a local account or a domain account. By default, the IIS server will look locally or in Active Directory for the user account. If the user account is in a domain other than the local domain, the user must specify the domain name during logon.The syntax for this is domain name\username, where domain name is the name of the user’s domain. Basic authentication can also be configured to use user principal names (UPNs) when using accounts stored in Active Directory.

Using Digest Authentication Digest authentication has many similarities to basic authentication, but it overcomes some of the problems. Digest authentication does not send usernames or passwords over the network. It is more secure than basic authentication, but it requires more planning to make it work. Some of the similarities with basic authentication are: ■

Users must have the Log On Locally right.

■

Both methods work through firewalls.

Like all authentication methods, digest authentication has some drawbacks, including: ■

Users can only access resources on the IIS server.Their credentials can’t be passed to another computer.

■

The IIS server must be a member of a domain.

■

All user accounts must store passwords using reversible encryption.

■

The method works only with Internet Explorer 5 or higher.

■

Digest authentication is vulnerable to replay attacks to a limited extent.

www.syngress.com

768


Digest authentication is secure due to the way it passes authentication information over a network. Usernames and passwords are never sent. Instead, IIS uses a message digest (or hash) to verify a user’s credentials. For digest authentication to work, all user accounts must be stored using reversible encryption in Active Directory, which might be a potential risk. After enabling this setting for a user account, the user’s password must be changed to create the plaintext copy. While digest authentication provides more security than some other authentication methods, the limitations normally outweigh the benefits. One interesting peculiarity with IIS is that when sending authentication headers to a client, it will send the basic authentication header before the digest authentication header. Many Internet browsers will use the first header they encounter and, therefore, opt for the weaker basic authentication.

Using Integrated Windows Authentication Integrated Windows authentication is a secure solution because usernames and passwords aren’t transmitted across the network. Integrated Windows authentication is convenient because, if a user is already logged on the domain and if the user has the correct permissions for the site, the user isn’t prompted for a username and password. Instead, IIS attempts to use the user’s cached credentials for authentication.The cached credentials are hashed and sent to the IIS server for authentication. If the cached credentials do not have the correct permissions, the user is prompted to enter a different username and password. Depending on the client and server configuration, integrated Windows authentication uses either NTLM or Kerberos for authentication.You cannot directly choose which one is used; IIS automatically chooses a method based on the server and client configuration. The Web browser and the IIS server negotiate which one to use through the negotiate authentication header. Both Kerberos and NTLM have advantages and disadvantages. Kerberos is faster and more secure than NTLM. Unlike NTLM, which authenticates only the client, Kerberos authenticates both the client and the server.This helps prevent spoofing. Kerberos also allows users to access remote network resources not located on the IIS server. NTLM restricts users to the information located on the IIS server only. Kerberos is the preferred authentication method for an intranet Web server. However, the following requirements must be met for Kerberos to be used instead of NTLM: ■

Both the client and server must be running Windows 2000 or later.

■

The client must be using Internet Explorer 5 or later.

■

The client and server must be in either the same domain as the IIS server or in a trusted domain.

You should also be aware of the following limitations on integrated Windows authentication:

www.syngress.com


It works only with Internet Explorer 3.01 or later.

■

It does not work through a firewall.The client will use the firewall’s IP address in the integrated Windows hash, which will cause the authentication request to fail.

769

Using Client Certificate Mapping Client certificate mapping is the process of mapping a certificate to a user account. Certificates can be mapped by Active Directory or by IIS. Both of these methods require SSL.Three types of certificate mappings are available: ■

One-to-one mapping

■

Many-to-one mapping

■

User principal name (UPN) mapping

Before we address the differences among these types of certificate mapping, let’s discuss why mapping is beneficial in the first place. Normally, if you want to give a user authenticated access to an intranet, you would either create a user account or allow users to login using their domain accounts. However, creating duplicate accounts is time-consuming, yet by using domain accounts, you must address the concern that domain passwords could become compromised. To provide better security and reduce the administrative workload, you could choose to issue each user a certificate. Certificates can be used to verify a user’s integrity. Using certificates is actually more efficient than using user accounts because certificates can be examined without having to connect to a database. Generally, you will find that it’s safer to distribute certificates than user accounts. Furthermore, guessing or cracking someone’s password is usually easier than forging a certificate. Certificate mapping is the process of linking a certificate to a specific user account. Now, let’s look at the three available types of certificate mapping.

One-to-One Certificate Mapping As the name indicates, one-to-one mappings link one user account to one certificate.The user presents his or her certificate, and Active Directory compares the certificate to that which was assigned to the user. If the certificates match, the user is authenticated to that mapped account. For this system to work, the server must contain a copy of all the client certificates. Generally, one-to-one mappings are used in smaller environments. One of the reasons that you use mapping is to make a network easier to administer. If you use one-to-one mappings in a large environment, you create a large database, because every certificate is mapped to a unique account.

www.syngress.com

770


Many-to-One Certificate Mapping Many-to-one mappings link many certificates to one user account. Many-to-one mappings are processed differently than one-to-one mappings. Because there is not a oneto-one association between user accounts and certificates, the server doesn’t have to maintain a copy of individual user certificates.The server uses rules to verify a client. Rules are configured to look for certain items in the client’s certificate. If those items are correct, the user is mapped to the shared user account. For example, you could set up a rule to check which certificate authority (CA) issued the certificate. If your company’s CA issued the certificate, you would allow the mapping. If the certificate were issued by another CA, the user would be denied access.

User Principal Name Mapping Active Directory is responsible for managing user principal name (UPN) mapping. UPN mapping is really another way to do a one-to-one mapping.The user’s UPN is entered into the certificate by the certificate authority. Active Directory uses this field to locate the correct user account and performs a one-to-one mapping between the certificate and the account.This is the preferable approach for certificate mappings.

Summary While the IIS hardening process might seem tedious, it is necessary to carefully follow the steps outlined here. A well-planned installation and hardening process can make the difference between being secure and being hacked. Supplement these steps with an operational security policy and regular audit process to ensure that your Web server stays as secure as possible. But the process described here is not the end. Securing IIS is an ongoing process.You must keep up with current hot fixes and be aware of new issues. Monitor Web sites, such as Microsoft’s TechNet Security page (www.microsoft.com/technet/security), and subscribe to a mailing list, such as focus-ms (subscribe at http://online.securityfocus.com/ archive). Furthermore, the server must be constantly monitored for changes and other signs of intrusion. Hackers adapt to security measures by evolving their techniques and finding new holes, therefore you must also be ready to adapt. IIS Web servers are prone to attack; they are the Internet battle front. But a server built at every level with security in mind will withstand attack and hold its ground. Follow best practices, implement the procedures described here, and keep up with security, and your server too will stand.

www.syngress.com


771

Defensive Tactics Fast Track Preparing the OS ; Remove unused Windows components and disable unnecessary services. ; Lock down COM and database access by removing unused drivers and

securing sensitive COM components. ; Prevent DoS attacks by hardening the TCP/IP stack.

Securing the Internet Information Service ; Set global IIS Registry settings to the recommended values. ; Lock down the default and administration Web sites. ; Disable Web-based printing. ; Disable or secure the FrontPage Server Extensions. ; Customize your URLScan configuration.

Securing Web Sites ; Build a directory structure that compliments your security strategy. ; Set the Master WWW properties to ensure that new Web sites start off secure. ; Segregate content by type to ensure least privilege for each type.

Authenticating Users ; Select the appropriate authentication methods based on your server and client

configuration. ; Use the strongest authentication method available. ; Use client certificates for more secure authentication.

www.syngress.com

772



Q: I installed URLScan, and now I cannot connect to the Web server via FrontPage. What did I do wrong?

A: To fix this, set the AllowDotInPath setting to 1 in the URLScan.ini file. Q: I just added the SMTP service to my server, do I need to reinstall my service packs and hot fixes?

A: You do not need to reinstall service packs, but any hot fixes installed since the last service pack do need to be reinstalled.

Q: I uninstalled the FrontPage Server Extensions but the files are still there. I tried to manually delete the directory, but I got an Access Denied error. How can I remove these files?

A: The files are locked by the winlogon process due to Windows File Protection (WFP). Do remove the files, reboot the system to Safe Mode and then delete the entire directory.When you reboot to normal mode, the directories will be replaced, but the files themselves will be gone.

Q: When I browse to global.asa using my browser, I see the source code. How can I prevent this?

A: Map the .asa extension to asp.dll or 404.dll. See “The Home Directory” section earlier in this chapter for more information.

Q: My HTML code frequently refers to graphics and other files by using double dots such as /../images/help.gif. Do I need to change all these references if I disable parent paths?

A: Disabling parent paths only prevents HTML and ASP pages from including files from outside the Web root. It has no affect on relative references to files within the Web root; therefore, there is no need to change any of your references or links.

www.syngress.com

Appendix A

Defending Your 802.11 Wireless Network

Defensive Tactics in this Appendix: ■

Understanding Wireless Networks

■

Understanding Wireless Security

■

Using a Layered Approach

■

Summary

773

774

Appendix A • Defending Your 802.11 Wireless Network

Introduction Wireless networks represent one of the more exciting advances in networking technologies in recent years. By freeing network communications from the “tether,” the physical cable that constrains access to the network, wireless technologies can produce large gains in productivity and can lower costs associated with wiring buildings for access to the network. As with any new networking and computer technology, however, wireless networks introduce new security risks and concomitant challenges for the security administrator. When network communications are no longer bounded by wires, anyone can potentially listen to the network, connect to it, and gain access to it. Now, someone sitting in the parking lot outside an office or some other relatively nearby place can potentially gain access to the network. Furthermore, just as wireless networking standards are relatively new and immature, so too are the standards that govern security on wireless networks. In addition, the very newness of wireless networking contributes to widespread ignorance regarding its operation, attendant security risks, and available security measures to counter and reduce those risks. As we pointed out earlier, effective security is the sum total of a well-planned and carefully implemented security infrastructure, which can include the use of smart cards, digital certificates, firewalls, encryption, and other measures. No wireless network, no matter how well secured, can add to the overall security of the network if due care has not been exercised to secure the entire network. In fact, the converse is true: a wireless network adds more security risks and possible threats to the network, and hence makes the confidentiality and integrity of information on the network more vulnerable to compromise.Thus, a wireless network should always be treated as an untrusted network in its implementation in any home or business. The intent of this chapter is to provide information on the operation of wireless networks (in particular, those that use the 802.11 Institute of Electrical and Electronics Engineers (IEEE) standard), the security risks of such networks, and available countermeasures to reduce those risks.The content of this chapter builds on the information presented in other chapters in this book. We first provide an overview of the operation of wireless technology and discuss the various types of wireless networks and the standards that govern them. Next, we look at some of the general security issues associated with wireless networks.We then look at the various countermeasures that can be applied to secure a wireless network through a strategy known as defense in depth. Finally, we offer some advice on common best practices to use when deploying a secure wireless network.

Understanding Wireless Networks Connecting to a wireless network is often transparent to users, and from their perspective is apparently no different from connecting to an Ethernet network, with the

Defending Your 802.11 Wireless Network • Appendix A

exception that no wires are involved.With Windows XP, which supports automatic configuration and seamless roaming from one wireless network to another through its Zero Configuration service, the ease with which users can connect to wireless networks further belies the complexity of the technology involved and differences between the two types of networks. Furthermore, because the experience of using a wireless network is similar to that of using an Ethernet network, there is a tendency to treat both types of networks as if they were the same.They are, in fact, quite different, and an understanding of those differences is critical to deploying an informed and effective implementation of a secure wireless network.

Wireless Communication in a Wireless Network Wireless networks, like their wired counterparts, rely on the manipulation of electrical charge to enable communication between devices. Changes or oscillations in signal strength from 0 to some maximum value (amplitude) and the rate of those oscillations (frequency) are used singly or in combination to encode and decode information.When two devices understand the method(s) used to encode and decode information contained in the changes to the electrical properties of the communications medium, they can communicate with each other. A network adapter is able to decode the changes in the electric current it senses on the wire and convert them to meaningful information (bits) that it can subsequently send to higher levels for processing. Likewise, a network adapter can encode information (bits) by manipulating the properties of the electric current for transmission on the communications medium (the cable, in the case of wired networks).

Radio Frequency Communications The obvious and primary difference between wired and wireless networks is that wireless networks use a special type of electric current, commonly known as radio frequency (RF), which is created by applying alternating current (AC) to an antenna to produce an electromagnetic field (EM).The resulting RF field is used by devices for broadcast and reception. In the case of wireless networks, the medium for communications is the EM field, the region of space that is influenced by the electromagnetic radiation (unlike audio waves, radio waves do not require a medium such as air or water to propagate). As with wired networks, amplitude decreases with distance, resulting in the degradation of signal strength and the ability to communicate. However, the EM field is also dispersed according to the properties of the transmitting antenna and not tightly bounded, as is the case with communication on a wire.The area over which the radio waves propagate from an electromagnetic source is known as the fresnel zone. Like the waves created by throwing a rock into a pool of water, radio waves are affected by the presence of obstructions and might be reflected, refracted, diffracted, or scattered, depending on the properties of the obstruction and its interaction with the radio waves. Reflected radio waves can be a source of interference on wireless networks.The interference created by bounced radio waves is called multipath interference.

775

776


When radio waves are reflected, additional wave fronts are created.These different wave fronts might arrive at the receiver at different times and be in phase or out of phase with the main signal.When the peak of a wave is added to another wave (in phase), the wave is amplified.When the peak of a wave meets a trough (out of phase), the wave is effectively cancelled. Multipath interference can be the source of hard-totroubleshoot problems. In planning for a wireless network, administrators should consider the presence of common sources of multipath interference.These include metal doors, metal roofs, water, metal vertical blinds, and any other source that is highly reflective to radio waves. Antennas might help to compensate for the effects of multipath interference, but these have to be carefully chosen. In fact, many wireless access points (APs) have two antennas for precisely this purpose. However, a single omnidirectional antenna might be of no use at all for this type of interference. Another source of signal loss is the presence of obstacles.While radio waves can travel through physical objects, they will be degraded according to the properties of the object through which they travel. A window, for example, is fairly transparent to radio waves, but can reduce the effective range of a wireless network by 50 to 70 percent, depending on the presence and nature of coatings on the glass. A solid core wall can reduce the effective range of a wireless network by up to 90 percent or greater. EM fields are also prone to interference and signal degradation by the presence of other EM fields. In particular, 802.11 wireless networks are prone to interference produced by cordless phones, microwave ovens, and a wide range of devices that use the same unlicensed Industrial, Scientific and Medical (ISM) or Unlicensed National Information Infrastructure (UNII) bands.To mitigate the effects of interference from these devices and other sources of electromagnetic interference, RF-based wireless networks employ spread spectrum technologies. Spread spectrum provides a way to “share” bandwidth with other devices that might be operating in the same frequency range. Rather than operating on a single, dedicated frequency, as is the case with radio and television broadcasts, wireless networks use a “spectrum” of frequencies for communication.

Spread Spectrum Technology First conceived by Hedy Lamarr and George Antheil (a Hollywood actress and a composer, respectively) in 1940 as a method to secure military communications from jamming and eavesdropping during WWII, spread spectrum technology defines methods for wireless devices to use a number of narrowband frequencies over a range of frequencies simultaneously for communication.The narrowband frequencies used between devices change according to a random-appearing but defined pattern, allowing the use of individual frequencies to contain parts of the transmission. Someone listening to a transmission using spread spectrum would hear only noise, unless his or her device understood in advance what frequencies were used for the transmission and could synchronize with them.The following two methods are used to synchronize wireless devices:

Defending Your 802.11 Wireless Network • Appendix A ■

Frequency hopping spread spectrum (FHSS)

■

Direct sequence spread spectrum (DSSS).

Frequency Hopping Spread Spectrum As the name implies, FHSS works by quickly moving from one frequency to another according to a pseudo-random pattern.The frequency range used by the frequency hop is relatively large (83.5 MHz), providing excellent protection from interference.The amount of time spent on any given frequency is known as dwell time; the amount of time it takes to move from one frequency to another is known as hop time. FHSS devices will begin their transmissions on one frequency and move to other frequencies according to the predefined pseudo-random sequence, and then repeat the sequence after reaching the final frequency in the pattern. Hop time is usually very short (200 to 300 µs) and not significant relative to the dwell time (100 to 200 ms). However, Bluetooth devices use very short dwell times, and the hop times in this case can be significant, resulting in lower throughput. In general, the longer the dwell time, the greater the throughput and the more susceptible the transmission might be to narrowband interference.

NOTE Bluetooth is a short-range, low-power radio technology that uses FHSS in the 2.4 to 2.4835 GHz ISM band. Two common applications of Bluetooth technology are wireless headsets for cell phones and wireless printing from PDAs. However, it has many potential applications, including wireless PC peripherals. Bluetooth was named after King Harald Blaatand (“Bluetooth”), who ruled Denmark from 940 to 981. During his reign, Denmark and Norway were united and Christianity was more firmly established in Scandinavia. Because of the type and significance of Bluetooth’s accomplishments, “Bluetooth” is the name that cell phone manufacture Ericsson chose when it was looking for an inexpensive radio interface between cell phones and PDAs.

The frequency hopping sequence creates the channel, allowing multiple channels to coexist in the same frequency range without interfering with one another. As many as 79 FCC-compliant FHSS devices using the 2.4 GHz ISM band can be collocated with each other. However, the expense of implementing such a large number of systems limits the practical number of collocated devices to well below this number.Wireless networks that use FHSS include HomeRF and Bluetooth, which both operate in the unlicensed 2.4GHz ISM band. FHSS is less subject to EM interference than DSSS is, but usually operates at lower rates of data transmission (usually 1.6 Mbps, but can be as high as 10 Mbps) than networks that use DSSS.

777

778


Direct Sequence Spread Spectrum DSSS works somewhat differently.With DSSS, the data is divided and simultaneously transmitted on as many frequencies as possible within a particular frequency band (the channel). DSSS adds redundant bits of data known as chips to the data to represent binary 0s or 1s.The ratio of chips to data is known as the spreading ratio: the higher the ratio, the more immune to interference the signal is, because if part of the transmission is corrupted, the data can still be recovered from the remaining part of the chipping code.This method provides greater rates of transmission than FHSS does, which uses a limited number of frequencies, but fewer channels in a given frequency range. In addition, it protects against data loss through the redundant, simultaneous transmission of data. However, because DSSS floods the channel it is using, it is also more vulnerable to interference from EM devices operating in the same range. In the 2.4 to 2.4835 GHz frequency range employed by 802.11b, DSSS transmissions can be broadcast in any one of 14 22 MHz-wide channels.The number of center-channel frequencies used by 802.11 DSSS devices depends on the country. For example, North America allows 11 channels operating in the 2.4 to 2.4835 GHz range, Europe allows 13, and Japan allows 1. Because each channel is 22 MHz wide, channels can overlap each other.With the 11 channels available in North America, only a maximum of three channels (1, 6, and 11) can be used concurrently without the use of overlapping frequencies.

Wireless Network Architecture The seven-layer OSI networking model defines the framework for implementing network protocols.Wireless networks operate at the physical and data link layers of the OSI model.The PHY layer is concerned with the physical connections between devices, such as how the medium and low bits (0s and 1s) are encoded and decoded. Both FHSS and DSSS, for example, are implemented at the PHY layer.The data link layer is divided into two sublayers, the Media Access Control (MAC) and Logical Link Control (LLC) layers.The MAC layer responsibilities include: ■

Framing of data

■

Error control

■

Synchronization

■

Collision detection and avoidance

The Ethernet 802.3 standard, which defines the Carrier Sense Multiple Access with Collision Detection (CSMA/CD) method for protecting against data loss as result of data collisions on the cable, is defined at this layer. In contrast to Ethernet 802.3 networks, wireless networks defined by the 802.11 standard do not use CSMA/CD as a method to protect against data loss resulting from collisions. Instead, 802.11 networks use a method known as Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). CSMA/CD works by detecting


whether a collision has occurred on the network and then retransmitting the data if one did. However, this method is not practical for wireless networks because CSMA/ CD relies on the fact that every workstation can hear all the other workstations on the cable segment to determine if there is a collision. In a wireless network, usually only the AP can hear every workstation that is communicating with it (for example, workstations A and B might be able to communicate with the same AP, but they might be too far apart to hear their respective transmissions). Additionally, wireless networks do not use full-duplex communication, which is another way to protect data against corruption and loss as a result of collisions. CSMA/CA solves the problem of potential collisions on the wireless network by taking a more active approach than CSMA/CD, which kicks in only after a collision has been detected. Using CSMA/CA, a wireless workstation will first try to detect if any other device is communicating on the network. If it senses that it is clear to send, it will initiate communication.The receiving device will send an ACK packet to the transmitting device indicating successful reception. If the transmitting device does not receive an ACK, it assumes a collision has occurred and will retransmit the data. However, it should be noted that many collisions can occur, which can be used to compromise the confidentiality of Wired Equivalent Privacy Protocol (WEP) encrypted data. The fact that wireless encryption,WEP, is defined at the MAC layer is particularly noteworthy and has significant consequences for the security of wireless networks.This means that data at the higher levels of the OSI model, in particular TCP/IP data, is also encrypted. Because much of the TCP/IP communications that occur between hosts contain a large amount of frequently repeating and well-known patterns,WEP can be vulnerable to known plaintext attacks, although it does include safeguards against this type of attack. Later this chapter, we will explore in more detail the particular weaknesses of WEP.

Wireless Local Area Networks WLANs are covered by the IEEE 802.11 standards.The purpose of these standards is to provide a wireless equivalent to IEEE 802.3 Ethernet-based networks.The IEEE 802.3 standard defines a method for dealing with collisions (CSMA/CD), speeds of operation (10 Mbps, 100 Mbps, and faster), and cabling types (Category 5 twisted-pair and fiber). The standard ensures the interoperability of various devices, despite different speeds and cabling types. As with the 802.3 standard, the 802.11 standard defines methods for dealing with collision and speeds of operation. However, because of the differences in the media (air as opposed to wires), the devices being used, the potential mobility of users connected to the network, and the possible wireless network topologies, the 802.11 standards differ significantly from the 802.3 standard. As mentioned earlier in this chapter, 802.11 networks use CSMA/CA to deal with potential collisions, instead of the CSMA/CD used by Ethernet networks, because not all stations on a wireless network might be able to hear collisions that occur on the network.

779

780


In addition to providing a solution to the problems created by collisions that occur on a wireless network, the 802.11 standard must deal with other issues specific to the nature of wireless devices and wireless communications in general. For example, wireless devices need to be able to locate other wireless devices, such as APs, and be able to communicate with them.Wireless users are mobile and therefore should be able to move seamlessly from one wireless zone to another. Many wireless-enabled devices, such as laptops and handheld computers, use battery power and should be able to conserve power when they are not actively communicating with the network.Wireless communication over the air needs to be secure to mitigate both passive and active attacks. In the following section, we will briefly review the common IEEE wireless standards and the competing standards from the European Telecommunications Standards Institute (ETSI).

IEEE 802.11 Standards The original 802.11 standard was developed in 1989 and defines the operation of wireless networks operating in the 2.4 GHz range using either DSSS or FHSS at the physical layer of the OSI model.The standard also defines the use of infrared for wireless communication.The intent of the standard is to provide a wireless equivalent for standards, such as 802.3, that are used for wired networks. DSSS devices that follow the 802.11 standard communicate at speeds of 1 and 2 Mbps and generally have a range of around 300 feet. Because of the need for higher rates of data transmission and the need to provide more functionality at the MAC layer, other standards were developed by the 802.11 Task Groups (or in some cases, the 802.11 standards were developed from technologies that preceded them).

IEEE 802.11b The most common standard in use today for wireless networks, the 802.11b standard defines DSSS networks that use the 2.4 GHz ISM band and communicate at speeds of 1, 2, 5.5, and 11 Mbps.The 802.11b standard defines the operation of only DSSS devices and is backward compatible with 802.11 DSSS devices.The standard is also concerned only with the PHY and MAC layers; layer 3 and higher protocols are considered payload.There is only one frame type used by 802.11b networks, and it is significantly different from Ethernet frames.The 802.11b frame type has a maximum length of 2346 bytes, although it is often fragmented at 1518 bytes as it traverses an AP to communicate with Ethernet networks.The frame type provides for three general categories of frames: management frames, control frames, and data. In general, the frame type provides methods for wireless devices to discover, associate (or disassociate), and authenticate with one another; to shift data rates as signals become stronger or weaker; to conserve power by going into sleep mode; to handle collisions and fragmentation; and to enable encryption through WEP.With regard to WEP, we should note that the standard defines the use of only 64-bit (also sometimes referred to as 40-bit to add to


the confusion) encryption, which can cause issues of interoperability between devices from different vendors that use 128-bit or higher encryption.

IEEE 802.11a In spite of its nomenclature, 802.11a is a more recent standard than 802.11b.The standard defines wireless networks that use the 5 GHz Unlicensed National Information Infrastructure (UNII) bands. 802.11a supports much higher rates of data transmission than 802.11b.These rates are 6, 9, 12, 16, 18, 24, 36, 48, and 54 Mbps, although higher rates are possible using proprietary technology and a technique known as rate doubling. Unlike 802.11b, 802.11a does not use spread spectrum and Quadrature Phase Shift Keying (QPSK) as a modulation technique at the physical layer; instead, it uses a modulation technique known as Orthogonal Frequency Division Multiplexing (OFDM).To be 802.11a compliant, devices are only required to support data rates of at least 6, 12, and 24 Mbps—the standard does not require the use of other data rates (caveat emptor). Although identical to 802.11b at the MAC layer, 802.11a is not backward compatible with 802.11b because of the use of a different frequency band and the use of OFDM at the PHY layer, although some vendors are providing solutions to bridge the two standards at the AP. However, both 802.11a and 802.11b devices can be easily collocated because their frequencies will not interfere with each other, providing a technically easy, but relatively expensive, migration to a pure 802.11a network. At the time of writing, 802.11a-compliant devices are becoming more common, and the prices for them are falling quickly. However, even if the prices for 802.11b and 802.11a devices were identical, 802.11a would require more APs and be more expensive than an 802.11b network to achieve the highest possible rates of data transmission because the higher frequency 5GHz waves attenuate more quickly over distance.

IEEE 802.11f The 802.11 standard defines five distribution services to determine where 802.11 frames should be sent: ■

Association

■

Disassociation

■

Reassociation

■

Integration

■

Distribution

When a wireless device is moving among different wireless zones or cells, these distribution services are used to allow the wireless device to roam seamlessly between one AP and another. As the user moves from one wireless cell to another, the signal from the AP in the new cell will become stronger than the signal in the original cell. A handoff will take place so that the wireless device will send frames to the new AP and

781

782


stop sending frames to the original AP, consequently freeing resources on the original AP. However, the 802.11 standard does not specify how multi-cell roaming should be handled, and this could prevent APs from different vendors from interoperating with each other.The 802.11f standard is currently being developed to define an Inter-Access Point protocol to ensure the interoperability of multi-cell roaming among APs from different vendors.

IEEE 802.11g In order to provide both higher data rates (up to 54 Mbps) in the ISM 2.4 GHz bands and backward compatibility with 802.11b, the IEEE 802.11g Task Group members, along with wireless vendors, are working on the specifications of the 802.11g standard. 802.11g has been approved as a standard, but the specifications for the standard are still in draft form at the time of this writing and are due for completion in late 2002.To achieve the higher rates of transmission, 802.11g devices use OFDM, in contrast to QPSK, which is used by 802.11b devices as a modulation technique. However, 802.11g devices are able to automatically switch to QPSK to communicate with 802.11b devices. At the time of this writing, no 802.11g devices are on the market, although Cisco Systems has announced that its 802.11g-compliant Aironet 1200 will be available in 2003. 802.11g appears to have advantages over 802.11a in terms of providing backward compatibility with 802.11b; however, migrating to and coexistence with 802.11b might still prove to be problematic because of interference in the widely used 2.4 GHz band. Because of this, it is unclear whether 802.11g will be a popular alternative to 802.11a to achieve higher rates of transmission on wireless networks.

IEEE 802.11i The intent of the 802.11i standard is to provide a replacement for WEP.The specifications for the standard are still in development. However, it seems certain that the standard will do the following: ■

Replace RC4 with Advanced Encryption Standard (AES)

■

Provide a message integrity check (MIC) to prevent forgery

■

Provide a rapid re-keying mechanism

■

Provide port-based authentication based on IEEE 802.1X.

Ultimately, these changes will be implemented in future wireless products. In the interim and until products that implement the 802.11i standard appear on the market, work is being done to enhance security of wireless products with Temporal Key Integrity Protocol (TKIP) to address the weaknesses of key scheduling in WEP.When and if TKIP becomes available, it should be possible to apply firmware patches to enable it on existing wireless hardware.


European Telecommunication Standards Institute Just as the IEEE produces standards for communication in the United States, the European Telecommunications Standards Institute (ETSI), which has its headquarters in France, produces communications standards for use in Europe.The Broadband Radios Access Networks (BRAN) project within ETSI has developed four standards: ■

HiperLAN High Performance Radio LAN (HiperLAN) provides for data communication of up to 20 Mbps in the 5 GHz frequency range.

■

HiperLAN/2 HiperLAN Type 2 provides higher rates of transmission (up to 54 Mbps) than the original HiperLAN standard. HiperLAN/2 operates in the 5 GHz frequency range and provides a number of enhancements to the original standard.These include support for QoS; convergence layers on top of the PHY and DLC layers to provide multi-network access to ATM, IP, PPP, FireWire, and 3G networks; and DES or 3DES encryption.

■

HiperAccess The HiperAccess standard is intended to provide a competitive, interoperable, and low-cost alternative to wired networks.Work is still progressing on the standard. However, the specifications envision point-to-multipoint systems operating in the 40.5 to 43.5 GHz range to provide broadband multimedia access.

■

HiperLink HiperLink is a planned, future modification of the HiperAccess standard.The intent of the standard is to provide very high-speed transmissions (up to 155 Mbps) over a relatively short range (up to 150 meters, or approximately 492 feet) in the 17 GHz frequency range.

The standards developed by ETSI directly compete with IEEE 802.11 standards, in particular the IEEE 802.11a standard. However, work is progressing on the new IEEE 802.11h standard to provide interoperability with HiperLAN/2 networks.

Wi-Fi Alliance The Wi-Fi Alliance, formerly known as the Wireless Ethernet Compatibility Alliance (WECA), is an organization that tests and certifies wireless devices to ensure their compatibility and interoperability.The membership of the alliance includes a growing list of major wireless vendors, such as Cisco Systems, and has had a major impact on the wireless market. Currently, membership includes over 170 member companies and has certified over 450 devices. It’s now difficult to find 802.11b devices on the market that had not been certified by the Wi-Fi Alliance.The popularity of the Wi-Fi Alliance has significantly diminished the influence of a similar group, the WLAN Interoperability Forum (WLIF). When a wireless device is certified by the Wi-Fi Alliance, it receives the Wi-Fi seal of approval.The presence of the seal ensures interoperability of a wireless device with other Wi-Fi certified devices.The Wi-Fi certification covers only a subset of the features that can be implemented by wireless vendors. For example, the Wi-Fi certification covers only

783

784


the interoperability of 40-bit WEP and not the longer 104-bit WEP. Furthermore, the Wi-Fi certification at the time of this writing currently applies only to 802.11b devices. The lack of Wi-Fi certification for 802.11a devices has no doubt contributed to the fact that not all 802.11a vendors offer the same features and functionality in their products. Implementers of 802.11a must, therefore, take extra care to ensure that the 802.11a products they purchase support desired features and are interoperable with each other. However, on October 9, 2002, the Wi-Fi Alliance announced that it would begin interoperability testing for certification of 802.11a products almost immediately. To address the weaknesses of WEP, the Wi-Fi Alliance announced on October 31, 2002, that it would in 2003 begin interoperability testing on products that implemented a better security solution, known as the Wi-Fi Protected Access (WPA) standard.The WPA standard will be available as a firmware update for many Wi-Fi certified products currently in use.

802.11 Wireless Network Topology and Services Wireless networks are dynamic in nature and allow for the implementation of a number of different topologies.Wireless client devices, by definition, have the potential to be always in motion. Because the destination address of a wireless device does not always correspond to a particular location, mechanisms have to be put in place to ensure that frames can be sent appropriately from one wireless device to another, and that wireless devices can properly locate other wireless devices and then authenticate and associate with one another to establish communication.

Service Sets To provide mobility of wireless devices, the 802.11 standard defines components called sets.The standard defines three topology sets: ■

Basic Service Set (BSS) The BSS comprises one AP connected to the wired LAN and a number of wireless clients that communicate with the AP. This configuration is commonly known as infrastructure mode.When communication needs to take place between wireless end stations, communication between the two devices always takes place through the AP. A BSS will use a unique Service Set Identifier (SSID), which is also sometimes referred to as an Extended Service Set Identifier (ESSID) and is analogous to a network name and is configurable on the AP and wireless client. However, it will also use a BSS Identifier (BSSID), which is the AP’s unique hexadecimal MAC address and should not be confused with the SSID.

■

Independent Basic Service Set (IBSS) The IBSS comprises a number of peer-to-peer wireless stations that communicate with each other.There is no centralized AP in an IBSS topology.This configuration is commonly known as


ad hoc mode. As the name implies, IBSS networks are useful when it is necessary to quickly set up a wireless network with a number of wireless stations. ■

Extended Basic Service Set (EBSS) The EBSS extends wireless networks through the implementation of multiple BSS networks.The BSS networks, commonly known as cells, have their own respective APs, have overlapping coverage, and are connected to each other via a distribution service (DS). Although the DS can be just about any medium used for network communication, it is almost always an Ethernet network.This configuration allows the wireless user to roam seamlessly from one BSS network cell to another. However, to enable the seamless roaming of wireless stations from one cell to another, a number of behind-the-scenes mechanisms must be implemented.

802.11 Services The 802.11 standard defines nine services to support the wireless architecture.These services fall into two categories: station services and distribution services.

Station Services There are four station services: ■

Authentication

■

Deauthentication

■

Data delivery

■

Privacy

Collectively, these services provide similar functionality as Ethernet networks. Authentication is the process of verifying the identity of the client workstation before allowing access to the WLAN (allowing access is called association).When APs and clients are set up in their default configurations, the authentication process is null and any association is allowed. For this reason,WLAN administrators must configure some form of authentication on the wireless devices. A number of types of authentication can be configured. For example, the authentication process can be made against a list of allowable wireless client MAC addresses configured on the AP; this is also known as MAC filtering.That is, in order for the wireless station to have access to the WLAN, it must possess an allowable MAC address (one that has been explicitly specified).This is only one type of authentication that can be implemented.The WLAN administrator can configure other methods of authentication specific to WLANs, such as Open System Authentication and Shared Key Authentication. Open-system authentication requires that the AP and the client both use the same SSID.When this method is used, the SSID acts as a type of password, analogous to an SNMP community name, to allow association with the AP to take place. Using SSIDs

785

786


as the sole means of controlling access to the WLAN is not a good practice. By default, APs broadcast the SSID in beacon frames, allowing eavesdroppers to easily discover it. In fact,Windows XP will automatically detect available SSIDs and display them in the wireless networking interface. Some APs allow the administrator to disable SSID broadcasts.This configuration is referred to as a closed system.

WARNING It is very important for administrators to be aware that the default setup of an 802.11 AP and clients does not require authentication by the clients. Thus, the default setup should never be used on a business network or in any environment where security is desired.

Shared key authentication relies on WEP being implemented on both the client workstation and the AP.When shared key authentication is implemented, the following occurs: 1. The client workstation requests association with the AP. 2. The AP responds with a randomly generated plaintext challenge, which is sent in the clear. 3. The client workstation encrypts the challenge using WEP and sends it to the AP. 4. The AP decrypts the response and allows access if the decrypted challenge matches the original challenge. It might seem that shared key authentication is more secure than open system authentication because of the use of WEP. However, this is not the case. Because the original challenge is sent in plaintext and subsequently encrypted with the WEP key, shared key authentication introduces additional vulnerability to the security of the WEP keys. If a hacker knows the plaintext message and the resulting encrypted version of it, he has a powerful clue for breaking the underlying encryption. Consequently, it might be desirable to use open system authentication rather than shared key authentication in order to provide a greater degree of protection for the WEP keys.

NOTE In addition to the authentication methods described previously, the WLAN administrator can further extend the authentication process by implementing other solutions such as RADIUS authentication to complement and further secure the WLAN authentication process. We discuss RADIUS authentication in further detail later in the chapter.

The remaining station services, deauthentication, data delivery, and privacy, are used to provide further functionality, as follows:


Deauthentication is the process of tearing down an authentication session, thus freeing resources on an AP when, for example, a client goes out of range.

■

The data delivery service ensures that data is sent reliably between wireless devices and employs mechanisms such as CSMA/CA.

■

The privacy service protects the confidentiality of data as it traverses the WLAN.

The privacy service uses RC4 to encrypt data. However, in spite of this level of encryption, the privacy service was never intended to provide complete end-to-end security or to be a sole means of protecting the confidentiality of data.The intent of the now much-maligned privacy service (WEP) was to provide only an equivalent of the privacy of wired networks, which are vulnerable to eavesdropping if someone gains access to the cables and other devices that comprise the physical infrastructure of the wired network.Thus,WEP’s poor reputation is somewhat undeserved and has somewhat unfairly created marketing problems for wireless vendors and proponents of wireless networks.We discuss WEP in more detail later in this chapter.

Distribution Services In addition to the four station services, there are five distribution services: association, reassociation, disassociation, integration, and distribution.Together, these services are responsible for determining where data frames should be sent.These services are also responsible for making the roaming handoffs when client workstations are moving from one cell to another. Once a wireless device is authenticated with the AP, it can then become associated with it. Only when a client has become associated with an AP can it pass data to the AP. In low-power situations or when a client is moving from one cell to another, the re-association service allows the preservation of network session information. For example, if a wireless device moves from one cell to another, the new AP to which the client connects can contact the previous AP and forward any frames that are waiting for it on the previous AP. The distribution service is responsible for determining if frames should be sent to another AP or to the wired network.

Understanding Wireless Security As mentioned earlier in this chapter, wireless networks should always be treated as untrusted networks. Although the convenience they offer might make them desirable, their mere presence within any network infrastructure introduces additional vulnerability to the security of the network as a whole. Simply put, wireless networks are not inherently secure.That said, administrators armed with a good understanding of the operation of wireless networks and how to implement available countermeasures to provide defense in

787

788


depth can make them relatively safe. In this section, we will examine some of the common exploits of wireless networks,WEP, and a variety of methods that can be used as part of a layered approach to provide defense in depth for wireless networks.

Performing a Security Analysis Among security professionals, a common way to identify and evaluate threats to the security of the network is to consider or conceptualize threat as the sum of risk to compromise through an exploitable vulnerability and consequent loss of assets (including intangibles such as privacy) and vulnerability to compromise.

Understanding Threat and Risk A threat can be understood as a type of vector; that is, a force with a particular direction.To make this abstraction more concrete, imagine a dog of unpredictable disposition charging at you.The threat to your personal safety might be mitigated by a number of factors. If the owner of the dog is present to control the dog’s behavior, if the dog is friendly to you, if the dog is constrained by a chain, if you are behind a fence in your own yard, or if you are carrying a big, heavy stick and possess good reflexes, the threat to you would be reduced. However, every close encounter with this particular dog puts you at risk because of its unpredictable disposition.The dog might be friendly to you without the owner present, but if you are within its reach, you are still at risk in its presence. Over time, there is an increased probability or risk that the dog will behave aggressively toward you.You are vulnerable because you cannot outrun the dog. If you are safely behind your own fence or have the means to defend yourself, you become less vulnerable to the dog’s attack. Let’s extend the analogy to the realm of network security. A risk, as we have seen, is something that occurs (and changes) over time. Imagine that you are using WEP as the only means to secure your wireless network.WEP, as we pointed out earlier, is vulnerable to compromise. An exploitable vulnerability creates a potential risk, which increases over time.The longer a malicious wardriver (a hacker who drives around, seeking open wireless networks) is parked outside your office analyzing your network traffic with the intent of breaking the WEP encryption, the greater the risk that your network will be hacked, since the hacker needs to capture and analyze a sufficient amount of traffic to determine the WEP key. However, imagine that your wireless AP is located within a DMZ, and that all communication between the wireless stations and the corporate LAN is tunneled within a VPN. If the hacker compromises WEP, all he will be able to see is VPN-related traffic within the DMZ.While this information might possess some value, the potential loss to the company is minimized by the fact that the hacker can see only a small subset of company-related traffic, and that this traffic is further encrypted. Based on this, we can further refine the definition of risk to include potential loss measured against the vulnerabilities. If there is little to gain by exploiting a particular vulnerability, the risk and the total threat are reduced.


In performing a security analysis of a network, keep these distinctions in mind, especially with regard to the costs of implementing security countermeasures to mitigate threat. For example, the cost of implementing advanced wireless security measures, such as proprietary key-hopping mechanisms, to protect the confidentiality of wireless traffic on a home network might well outweigh the potential risks. However, in a high security environment on a corporate network, the potential loss of assets might justify the investment in higher-cost proprietary devices that provide additional protection.

Identifying Threat and Risk Identifying threat and risk is to some extent a matter of perception. Some home users might not care that others are able to access their home networks through a wireless network. In fact, they might be ideologically motivated to ensure that access to the Internet is widely available to their neighbors through their wireless networks (they might even be financially motivated and charge their neighbors for this access). Of course, if a neighbor is using the wireless network to distribute warez,Trojans, or child pornography, to launch denial of service (DoS) attacks, or to perform other illegal activities, the owner of the unsecured wireless network could be in serious trouble with the ISP or law enforcement agencies, even though technically innocent of any crime or wrongdoing. Consequently, analyzing potential threats will vary depending on the circumstances; specifically, who you are and what you do. In general, however, a security analysis will include the following for consideration: ■

Performing an inventory of assets

■

Identifying methods of access for authorized users

■

Identifying the potential for unauthorized users to gain access to assets

■

Identifying the potential of authorized users to perform unauthorized activities, such as setting up a wireless AP without the knowledge of or clearance from management or the IT department

■

Identifying potential damage resulting from modification and theft of assets

■

Identifying the costs to repair, replace, or track loss

■

Identifying security countermeasures and the cost of implementation of those measures in terms of hardware, procedure, personnel, software, and so on

■

Comparing the costs of securing assets versus controlling the damage of a realized threat

In the following section, we will examine the common threats and risks specific to wireless networks, and common measures to counter those risks.

789

790


Common Exploits of Wireless Networks In general, attacks on wireless networks fall into four basic categories: passive, active, man-in-the middle, and jamming attacks.

Passive Attacks on Wireless Networks A passive attack occurs when someone listens to or eavesdrops on network traffic. Armed with a wireless network adapter that supports promiscuous mode, the eavesdropper can capture network traffic for analysis using easily available tools, such as Network Monitor in Microsoft products, or TCPdump in Linux-based products, or AirSnort (developed for Linux, but Windows drivers can be written). A passive attack on a wireless network might not be malicious in nature. In fact, many in the wardriving community claim that their activities are benign or “educational” in nature.Wireless communication takes place on unlicensed public frequencies—anyone can use these frequencies.This makes protecting a wireless network from passive attacks more difficult.

Detecting and Responding to Wardriving Incidents Passive attacks are, by their very nature, difficult to detect. If an administrator is using DHCP on the wireless network (this is not recommended), he or she might notice that an unauthorized MAC address has acquired an IP address in the DHCP server logs. Then again, he or she might not. Perhaps the administrator notices a suspicious-looking car sporting an antenna out one of its windows. If the car is parked on private property, the driver could be asked to move or possibly charged with trespassing. However, the legal response might be severely limited, depending on the laws in your jurisdiction. Circumstances under which the wardriver is susceptible to being charged with a datarelated crime depends entirely on the country or state in which the activity takes place. For more information about legal aspects of wardriving and other computer-related criminal offenses, see Scene of the Cybercrime: Computer Forensics Handbook published by Syngress (ISBN 1-931836-65-5).

Wardriving Software Most wardriving enthusiasts use a popular freeware program, called Netstumbler, which is available from www.netstumbler.com.The Netstumbler program works primarily with wireless network adapters that use the Hermes chipset, because of its ability to detect multiple APs that are within range and WEP, among other features (a list of supported adapters is available at the Netstumbler Web site).The most common card that uses the Hermes chipset for use with Netstumbler is the ORiNOCO gold card. Another advantage of the ORiNOCO card is that it supports the addition of an external antenna, which can greatly extend the range of a wireless network by many orders of magnitude, depending on the antenna. A disadvantage of the Hermes chipset is that it doesn’t support promiscuous mode, so it cannot be used to sniff network traffic. For that purpose, you need a wireless


network adapter that supports the PRISM2 chipset.The majority of wireless network adapters targeted for the consumer market use this chipset (for example, the Linksys WPC network adapters). Sophisticated wardrivers will arm themselves with both types of cards, one for discovering wireless networks and another for capturing the traffic. Despite the fact that Netstumbler is free, it is a sophisticated and feature-rich product that is excellent for performing wireless site surveys, whether for legitimate purposes or not. It can provide detailed information on the wireless networks it detects, and can be used in combination with a GPS to provide exact details on the latitude and longitude of the detected wireless networks. Figure A.1 shows the interface of a typical Netstumbler session. Figure A.1 Discovering Wireless LANs Using Netstumbler

As you can see in Figure A.1, Netstumbler displays information on the SSID, the channel, and the manufacturer of the wireless AP. A few things are particularly noteworthy about this session.The first is that a couple of APs are still configured with the default SSID supplied by the manufacturer, which should always be changed to a nondefault value upon setup and configuration. Another is that at least one network uses an SSID that might provide a clue about the entity that has implemented it; again, this is not a good practice when configuring SSIDs. Finally, we can see which of these networks have implemented WEP. If the network administrator has been kind enough to provide a clue about the company in the SSID, or is not encrypting traffic with WEP, the potential eavesdropper’s job is much easier. Using a tool such as Netstumbler is only a preliminary step for the attacker. After discovering the SSID and other information, the attacker can connect to the wireless network to sniff and capture network traffic.This network traffic can reveal a lot of information about the network and the company that uses it. For example, looking at the network traffic, the attacker can determine what DNS servers are being used, the default home pages configured on browsers, network names, logon traffic, and so on.The attacker can use this information to determine if the network is of sufficient interest to proceed

791

792


further with other attacks. Furthermore, if the network is using WEP, the attacker can, given enough time, capture a sufficient amount of traffic to crack the encryption. Netstumbler works on networks that are configured as open systems.This means that the wireless network indicates that it exists and will respond with the value of its SSID to other wireless devices when they send out a radio beacon with an “empty set” SSID. This does not mean, however, that the wireless network can be easily compromised, if other security measures have been implemented. We should note that on the wireless side, APs are half-duplex devices and work just like other half-duplex devices, such as hubs and repeaters.This means that a device cannot send and receive at the same time and that access to the hub (AP) is shared. A byproduct of this is that all the devices on the network can potentially see all the traffic from other devices.The only defense against sniffing on a wireless network is to encrypt layer 2 and higher traffic whenever possible through the use of WEP,VPNs, SSL, Secure Shell (SSH), Secure Copy (SCP), and so on. Some of these defensive strategies will be more effective than others, depending on the circumstances.

Active Attacks on Wireless Networks Once an attacker has gained sufficient information from the passive attack, he can then launch an active attack against the network.There are a potentially large number of active attacks that a hacker can launch against a wireless network. For the most part, these attacks are identical to the types of active attacks encountered on wired networks. These include, but are not limited to, unauthorized access, spoofing, DoS, and flooding attacks, as well as the introduction of “malware” (malicious software) and the theft of devices.With the rise in popularity of wireless networks, new variations of traditional attacks specific to wireless networks have emerged, along with specific terms to describe them, such as “drive-by spamming” in which a spammer sends out tens or hundreds of thousands of spam messages using a compromised wireless network. Because of the nature of wireless networks and the weaknesses of WEP, unauthorized access and spoofing are the most common threats to wireless networks. Spoofing occurs when an attacker is able to use an unauthorized station to impersonate an authorized station on a wireless network. A common way to protect a wireless network against unauthorized access is to use MAC filtering to allow only clients that possess valid MAC addresses to access the wireless network.The list of allowable MAC addresses can be configured on the AP or on a RADIUS server with which the AP communicates. Regardless of the technique used to implement MAC filtering, it is relatively easy to change the MAC address of a wireless device through software, to impersonate a valid station. In Windows, this is accomplished with a simple edit of the Registry, in UNIX through a root shell command. MAC addresses are sent in the clear on wireless networks, so it is also relatively easy to discover authorized addresses. WEP can be implemented to provide more protection against authentication spoofing through the use of shared key authentication. However, as discussed earlier,


shared key authentication creates an additional vulnerability. Because it makes visible both a plaintext challenge and the resulting ciphertext version of it, it is possible to use this information to spoof authentication to a closed network. Once the attacker has authenticated and associated with the wireless network, he can then run port scans, use special tools to dump user lists and passwords, impersonate users, connect to shares, and, in general, create havoc on the network through DoS and flooding attacks.These DoS attacks can be traditional in nature, such as a ping flood, SYN, fragment, or distributed DoS (DDoS) attack, or they can be specific to wireless networks through the placement and use of rogue access points to prevent wireless traffic from being forwarded properly (similar to the practice of router spoofing on wired networks).

Man-in-the-Middle Attacks on Wireless Networks Placing a rogue AP within range of wireless stations is a wireless-specific variation of a man-in-the-middle attack. If the attacker knows the SSID in use by the network (which, as we have seen, is easily discoverable) and the rogue AP has enough strength, wireless users will have no way of knowing that they are connecting to an unauthorized AP. Using a rogue AP, an attacker can gain valuable information about the wireless network, such as authentication requests, the secret key in use, and so on. Often, the attacker will set up a laptop with two wireless adapters, in which one card is used by the rogue AP and the other is used to forward requests through a wireless bridge to the legitimate AP.With a sufficiently strong antenna, the rogue AP does not have to be in close proximity to the legitimate AP. For example, the attacker can run the rogue AP from a car or van parked some distance away from the building. However, it is also common to set up hidden rogue APs (under desks, in closets, etc.) close to and within the same physical area as the legitimate AP. Because of their undetectable nature, the only defense against rogue APs is vigilance through frequent site surveys (using tools such as Netstumbler and AiroPeek) and physical security. Frequent site surveys also have the advantage of uncovering the unauthorized APs that company staff members might have set up in their own work areas, thereby compromising the entire network and completely undoing the hard work that went into securing the network in the first place.This is usually done with no malicious intent, but for the convenience of the user, who might want to be able to connect to the network via his or her laptop in meeting rooms or break rooms or other areas that don’t have wired outlets. Even if your company does not use or plan to use a wireless network, you should consider doing regular wireless site surveys to see if someone has violated your company security policy by placing an unauthorized AP on the network, regardless of the intent.

Jamming Attacks on Wireless Networks Jamming is a special type of DoS attack specific to wireless networks. Jamming occurs when spurious RF frequencies interfere with the operation of the wireless network. In

793

794


some cases, the jamming is not malicious and is caused by the presence of other devices, such as cordless phones, that operate in the same frequency as the wireless network. In a case like this, the administrator must devise and implement policies regarding the use of these devices, such a banning the use of Bluetooth devices, or choose wireless hardware that uses different frequencies. Intentional and malicious jamming occurs when an attacker analyzes the spectrum being used by wireless networks and then transmits a powerful signal to interfere with communication on the discovered frequencies. Fortunately, this type of attack is not very common because of the expense of acquiring hardware capable of launching jamming attacks. In addition, jamming a network represents a type of Pyrrhic victory for the attacker—a lot of time and effort expended merely to disable communications for a while.

Using a Layered Approach Imagine, if you will, a castle.To defend the castle, the builders might have created a number of defenses.They might have cleared land for a good distance around the castle, the better to see people approaching.To slow attackers, they might have surrounded the castle with water; constructed a system of obstacles and roads to force specific approaches to it; placed it on top of a hill; constructed thick, high walls; and installed portcullises.The castle itself might be constructed in such a way that to get to the center of it, people have to get past a number a number of interior walls through narrow gates and corridors.The exterior and interior walls of the castle might be high and provide narrow windows for defenders to look down on people approaching the castle or traveling through it.These defenses might have been added and enhanced over a period of years.The advent of technological advances, such as cannons or better trébuchets, might have forced the clearing of more land surrounding the castle to keep potential attackers at a further distance. Depending on the degree of threat and the need for early warning, the ruler might have had to hire more soldiers, sentries, and spies. In short, the builders and defenders of the castle realized that a number of different types of defenses were needed to protect against a number of different types threats to the castle, some of which might have been from nature itself and not from malicious attackers. Further, they also realized that certain types of defenses might have to be repeated a number of times, such as a series of walls and obstacles. Of course, castles fell to attackers. Sometimes they fell because they weren’t adequately provisioned to withstand a long siege, because there weren’t enough defenders, because the defenders did not have adequate training or discipline, because the defenders were unaware of or unprepared for new technological advances, because the attacker’s agents occupied positions of trust within the castle itself, or because technological advances ultimately rendered a castle’s series of physical defenses useless. Neither castles nor secured networks are invulnerable.The builders and defenders of the castle knew, if they were wise, that the castle could potentially fall in spite of its defenses. However, the builders of castles also understood that their only hope of


successful defense depended on creating what is now known in the computer security community as defense in depth.They also understood, if not in these precise terms, that defensive strategies based on defense in depth had to focus on three areas: people, operations, and technology. If there weren’t enough well-trained and informed defenders whose loyalty could be tested and was beyond question, if there weren’t a means of provisioning the castle effectively or keeping apprised of the enemy’s capabilities, or if the walls weren’t constructed strongly enough, any one of these weaknesses could lead to its fall. Wireless networks, as we have learned, are particularly vulnerable to a number of different threats.There is no one countermeasure that can, by itself, supply an adequate degree of assurance for the security of a wireless network in a corporate environment. The best defense for a wireless network begins with a three-pronged approach: ■

Good corporate security policies supported by all levels of management and communicated effectively to staff

■

Well-trained and informed administrators to maintain and enforce security policies through effective procedures

■

The appropriate deployment of technological counter measures

The best technological defense for a wireless network is to use a layered approach: that is, to create a series of barriers to slow attackers and ultimately prevent them from compromising the confidentiality and integrity of the data and to prevent unauthorized users from gaining access to the network. In the following sections, we will explore a number of various technological countermeasures that can be used in combination to create a defensive strategy based on layers of defense.

Understanding and Configuring Service Set Identifiers SSIDs are often thought of as being a type of security mechanism for wireless networks.This is, for the most part, a misconception based on the fact that the SSID acts as a kind of shared password between wireless clients and APs. For a wireless client to communicate with an AP, it must know and be configured with the SSID that is configured on the AP. In this regard, SSIDs resemble SNMP community names. However, by default, most APs are configured as open systems.What this means is that the AP will respond with its SSID when it receives an “empty set” SSID request from a wireless client. Some client software, such as that used by Windows XP, relies on open systems to allow for the automatic configuration and association of the wireless adapter with the AP. Figure A.2 shows what Windows XP displays when it comes within range of wireless networks configured as open systems. As you can see, Netstumbler is not really required to discover wireless networks if you are using Windows XP. One of the design goals of Windows XP was to make wireless networking as seamless and as easy as possible for wireless users and administrators.

795

796


With Windows XP, it is not necessary to preconfigure the wireless interface with the SSID of an open system wireless network.The Zero Configuration Service used for the automatic configuration of wireless interfaces of Windows XP is, in fact, a Site Survey tool like Netstumbler. Figure A.2 Automatic Discovery of Wireless Network SSIDs in Windows XP

Assuming that WEP is not enabled on the wireless network, the user might never encounter this screen. His station will automatically connect him to the network. If the user does encounter this screen, all he has to do at this point is click the Connect button to authenticate and associate with the desired wireless network. Often, when multiple APs are available,Windows XP will automatically connect to the AP with the strongest signal without any action on the part of the user. The situation is different when the AP is configured as a closed system. A closed system means that the AP will not respond to beacon probes for the SSID.Technically, this means that when the wireless client sends an empty set (“0”) in its beacon frame, which is interpreted as the “Any” network, the AP will not respond with its SSID. However, APs will broadcast their SSIDs in beacon frames periodically, unless configured otherwise. A truly closed system is an AP that does not respond to empty set probe requests and periodically transmits its beacon frames. Figure A.3 shows the configuration screen for creating a closed system on the Linksys WAP11. Figure A.3 Disabling SSID Broadcast on WAP11 Access Point

Not all vendors offer this feature on their APs. In fact, this feature is not available with the original firmware for the Linksys WAP11 AP. However, because it was possible to flash the AP with updated firmware, the feature became available in a later firmware


release.To confuse matters further, not all vendors refer to this feature consistently. Some refer to disabling SSID broadcast, and some refer to a “closed network” or a “closed wireless system,” as is the case with the ORiNOCO Access Point 500 shown in Figure A.4. Figure A.4 Disabling SSID Broadcasts on an ORiNOCO 500 Access Point

When you configure your AP as a closed system by disabling SSID broadcasts, you increase the administrative burden for the configuration of wireless interfaces in Windows XP clients.When Windows XP discovers open wireless systems, it will display the SSID to the user, allowing the wireless client to authenticate and associate with the wireless network without prior knowledge of the SSID used by the AP. As shown in Figure A.5, when the AP is configured as a closed system, there is no indication of the presence of available wireless networks in the Wireless Networks tab of the Wireless Network Connection Properties of the wireless NIC, aside from the wireless network to which you are connected. Notice, though, that the SSIDs are displayed only in the Preferred networks dialog box. However, the Preferred networks displays only networks that we have previously connected to or have preconfigured and gives no indication of availability. If more than one of these networks is in range,Windows XP will authenticate and associate with them based on their order in the Preferred networks dialog box and their signal strength. Figure A.5 Wireless Networks Tab Display for Closed Systems

If you already connected to an AP configured as an open system and then subsequently reconfigured the AP as a closed system, you will not have to preconfigure the

797

798


wireless interface with the SSID, because Windows XP will retain this configuration. However, if you have not previously associated with the closed system, you will have to configure the value of SSID manually.To do this, simply click Add under the Preferred networks dialog box in Figure A.5 and then enter the SSID, along with other appropriate values, in the subsequent property page. Regardless of the enhanced security that a closed system can offer for your wireless network, you should treat an SSID as simply a network name and not as a shared-secret password for access to wireless networks. In choosing the SSID network, you should follow a few common-sense principles: ■

Change the default SSID provided by the vendor of the AP.The default SSIDs for many products are well known. For example, the default SSID for Cisco products is tsunami, and for Linksys products it is linksys.

■

Don’t use your company name, address, product names, divisions, or any other potentially identifiable information in the SSID. By providing this information, you let the hacker know immediately whether further interest in the network is warranted.

■

Use relatively long, hard-to-guess names for the SSID.

■

Consider changing SSIDs frequently on a closed system, according to a schedule implied by the necessary level of security you need.You will want to change SSIDs more frequently in a high-security environment than in a lowsecurity environment.

■

Use a closed system configuration on your wireless network.

Wired Equivalent Privacy Protocol (WEP) Although WEP has been much maligned as a security measure for wireless networks, it should nonetheless be implemented on all wireless networks.WEP can be hacked, but doing so requires time and resources. Implementing WEP creates another barrier to unauthorized access to your wireless network. Once a hacker has spent the time acquiring the SSID in use on your closed network, he must now spend time cracking the WEP encryption. At this point, it simply might not be worth the effort for the hacker to continue further. In this section, we provide an overview of WEP and its weaknesses, and then demonstrate how to configure APs and Windows XP clients to use static WEP keys.

Overview of WEP and Its Weaknesses WEP is part of the 802.11 standard defined for wireless networks in 1999. It differs from many other types of encryption employed to secure network communication, in that it is implemented at the MAC sublayer of the data link layer (layer 2) of the OSI model. Security can be implemented at many different layers of the model. IPSec, for


example, is implemented at the network layer (layer 3) of the OSI model; PPTP creates a secure end-to-end tunnel by using network layer (GRE) and transport layer protocols to encapsulate and transport data; HTTP-S and SSH are application-layer (Layer 7) protocols for encrypting data. Because of the complexity of the 802.11 MAC and the amount of processing power it requires, the 802.11 standard made 40-bit WEP an optional implementation only.

Vulnerability to Plaintext Attacks From the outset, knowledgeable people warned that, because of the way in which WEP was implemented, it was vulnerable. In October 2000, Jesse Walker, a member of the 802.11 working group, published his now famous paper,“Unsafe at Any Key Size; An Analysis of WEP Encapsulation.”The paper pointed out a number of serious shortcomings of WEP and recommended that WEP be redesigned. For example,WEP is vulnerable to plaintext attacks because it is implemented at the data link layer, meaning that it encrypts IP datagrams. Each encrypted frame on a wireless network therefore contains a high proportion of well-known TCP/IP information, which can be revealed fairly accurately through traffic analysis, even if the traffic is encrypted. If someone is able to compare the ciphertext (the WEP-encrypted data) with the plaintext equivalent (the raw TCP/IP data), he has a powerful clue for cracking the encryption used on the network. All the hacker has to do is plug the two values, the plaintext and the ciphertext, into the RC4 algorithm used by WEP to uncover the keystream used to encrypt the data.There are a number of ways to speed up the process of acquiring both the plaintext and ciphertext versions: by sending spam into the network, by injecting traffic into the network, by using social engineering to get a wireless user to send the hacker e-mail, and so on.

Vulnerability of the RC4 Algorithm As alluded to in the previous paragraph, another vulnerability of WEP is that it uses a stream cipher called RC4, developed by RSA, to encrypt the data. In 1994, an anonymous user posted the RC4 algorithm to a cipherpunk mailing list, which was subsequently re-posted to a number of Usenet newsgroups the next day with the title “RC4 Algorithm Revealed.” Up until August 2001, it was thought that the underlying algorithm used by RC4 was well designed and robust, so even though the algorithm was no longer a trade secret, it was still thought to be an acceptable cipher to use. However, Scott Fluhrer, Itsik Mantin, and Adi Shamir published a paper entitled, “Weaknesses in the Key Scheduling Algorithm of RC4” that demonstrated that a number of keys used in RC4 were weak and vulnerable to compromise.The paper designed a theoretical attack that could take advantage of these weak keys. Because the algorithm for RC4 is no longer a secret and because there were a number of weak keys used in RC4, it is possible to construct software that is designed to break RC4 encryption relatively quickly using the weak keys in RC4. Not surprisingly, a number of open-source tools have appeared that do precisely this.Two such popular tools for cracking WEP are AirSnort and WepCrack.

799

800


Some vendors, such as Agere (which produces the ORiNOCO product line), responded to the weakness in key scheduling by making a modification to the key scheduling in their products to avoid the use of weak keys, making them resistant to attacks based on weak key scheduling.This feature is known as WEPplus. However, not all vendors have responded similarly.

Stream Cipher Vulnerability WEP uses an RC4 stream cipher. As discussed in Chapter 12, “Creating a Public Key Infrastructure with Certificate Services,” a stream cipher differs from a block cipher such as DES or AES, which performs mathematical functions on blocks of data, in that the data or the message is treated as a stream of bits: to encrypt the data, the stream cipher performs an Exclusive OR (XOR) of the plaintext data against a keystream to create the ciphertext stream. (An XOR is mathematical function used with binary numbers. If the bits are the same, the result of the XOR is “0”; if different, the result of the XOR is “1”.) If the keystream were always the same, it would be a relatively trivial matter to crack the encryption if the attacker had both the plaintext and the ciphertext version of the message (known as a plaintext attack). In order to create keystreams that are statistically random, a key and a pseudorandom number generator (PRNG) are used to create the keystream that is XORed against the plaintext message to generate the ciphertext. In the case of WEP, a number of other elements are involved to encrypt and decrypt messages and can be simply expressed.To encrypt an 802.11 frame, the following process occurs: 1. A CRC, known as an Integrity Checksum Value (ICV), is calculated for the message and appended to the message to produce the plaintext message. 2. RC4 is used to create a pseudorandom keystream as a function of a 24-bit IV and the shared-secret WEP key.The IV and the shared-secret WEP key are used to create the RC4 key schedule. A new IV is used for every frame to be transmitted. 3. The resulting keystream is XORed with the plaintext message to create a ciphertext. 4. The IV is concatenated with the ciphertext in the appropriate field and a bit set to indicate a WEP-encrypted frame. To decrypt the ciphertext, the receiving station checks the bit denoting encryption, extracts the IV from the frame to concatenate it with the shared secret WEP key, creates the keystream using the RC4 key schedule, XORs the ciphertext with keystream to create the plaintext, and then performs an integrity check on the data using the ICV appended to the end of the data. A central problem with WEP is the potential for reuse of the IV. A well-known vulnerability of stream ciphers is the reuse of an IV and key to encrypt two different


messages.When this occurs, the two ciphertext messages can be XORed with each other to cancel out the keystream, resulting in the XOR of the two original plaintexts. If the attacker knows the contents of one of these plaintext messages, he can then easily obtain the plaintext of the other message. Although there are 224 (16,777,216) possible combinations for the IV, this is in fact a relatively small number. On a busy wireless network, the entire range of possible combinations for the IV can be exhausted in a number of hours (remember, each frame or packet uses a different IV). Once an attacker has collected enough frames that use duplicate IVs, he can use this information to derive the shared-secret key. In the absence of other solutions (which are usually proprietary) for automatic key management and out-of-band or encrypted dynamic key distribution, the shared-secret WEP keys have to be manually configured on the APs and wireless client workstations. Moreover, because of the administrative burden of changing the shared-secret key, administrators often do not change it frequently enough. To make matters worse, a hacker does not even need to wait until the 24-bit IV key space is exhausted to find duplicate IVs (remember, these are transmitted in the frame of the message). In fact, it is almost certain that the attacker will encounter a duplicate IV in far fewer frames or discover a number of weak keys.The reason is that upon reinitialization, wireless PC cards will reset the IV to “0”.When the wireless client begins transmitting encrypted frames, it will increment the IV by “1” for each subsequent frame. On a busy network, there are likely to be many instances of wireless PC cards being reinitialized, thereby making the reuse of the low-order IVs a common occurrence. Even if the IVs were randomized, rather than being used in sequence, this would not be an adequate solution because of the birthday paradox.The birthday paradox predicts the counterintuitive fact that within a group as small as 23 people, there is a 50-percent chance that two people share the same birthday. It doesn’t really matter whether the wireless network is using 64- or 128-bit encryption (in reality, these constitute 40- and 104-bit encryption, once the 24 bits for the IV is subtracted). Both use a 24-bit long IV. Given the amount of traffic on a wireless network and the probability of IV collisions within a relatively short period of time, a 24-bit IV is far too short to provide any type of meaningful protection against a determined attacker.

Should You Use WEP? The existence of these vulnerabilities does not mean that you should not use WEP. One of the most serious problems with wireless security is not that WEP is insecure, but that a high percentage of wireless networks discovered by wardrivers are not using WEP at all. In fact, at a minimum, all wireless networks should be configured to use WEP. It is available for free with wireless devices. At the very least,WEP will prevent casual wardrivers from compromising your network, and slow the knowledgeable and determined attackers. In the following section, we will look at how to configure APs and Windows XP wireless clients to use static WEP keys.

801

802


Static WEP Keys on Windows XP and Wi-Fi Compliant Access Points As a minimum requirement, you should configure static WEP keys on your APs and wireless clients. If your hardware is Wi-Fi compliant, you will be able to set a minimum of 64bit encryption (actually a 40-bit key with a 24-bit IV). However, if it is available on your hardware, you should select 128-bit encryption (a 104-bit key with a 24-bit IV). Some vendors are now providing 256-bit WEP. However, this is proprietary technology and because it is not standard, it might not be interoperable between the different vendors.

Configuring WEP Keys on the Linksys WAP11 Most APs will allow you to configure up to four different WEP keys for use on your wireless network. However, generally only one of these WEP keys can be used at one time.The purpose of allowing the configuration of up to four WEP keys is to provide an easy means to roll over keys according to a schedule. Figure A.6 shows you the WEP key configuration property for a Linksys WAP11. Figure A.6 Configuring WEP Keys on a Linksys WAP11

A number of wireless devices, such as the Linksys WAP11 shown in Figure A.6, allow you to use a passphrase to generate the WEP keys.This can help to simplify the process of generating new keys. However, potential attackers might know the algorithm for generating the keys from the passphrase, so you should take care to choose hard-toguess passphrases if you do use this method to generate keys. The Linksys WAP11 allows you to create WEP keys using hexadecimal digits only. Other APs will allow you the choice of creating WEP keys using either ASCII characters or HEX digits.The advantage of using ASCII characters is that there are fewer of them to type in: 13 characters versus 26 hexadecimal digits to create a 104-bit key length.The convenience of using ASCII characters is even more apparent when the wireless client is Windows XP with Service Pack 1 installed. SP1 changes the wireless interface so that you are only able to configure the WEP keys using ASCII characters. If your AP supports only the use of hexadecimal digits for the WEP key, you will have to convert the hexadecimal digits to ASCII characters to configure your Windows XP SP1 clients.


Configuring WEP Keys on the Windows XP Client Once you have configured your AP with the WEP keys, you configure the wireless interface with the WEP key that corresponds to the one WEP key currently being used by the AP. (Remember that both the wireless client and the AP have to use the same WEP key as a type of shared secret. If there is no available mechanism to automate the distribution and configuration of dynamic WEP keys, these must be manually configured.) Windows XP allows you to configure only one WEP key per SSID profile. Figure A.7 shows you the Properties page for configuring WEP keys on Windows XP. Figure A.7 Configuring a Static WEP Key on Windows XP

To configure static WEP keys in Windows XP: 1. Open the Wireless Network Connection Properties page from Network Connections, and click on the Wireless Networks tab. 2. If the wireless network has already been detected, select the appropriate network denoted by the SSID in the Preferred networks dialog box, and click Properties. Otherwise, click Add below the Preferred networks dialog box. 3. In the Wireless Network Properties page, enter the SSID if required and select Data Encryption (WEP enabled). 4. Deselect the box indicating The key is provided for me automatically. (You would only use this if the software and/or hardware allowed for the automatic distribution of dynamic WEP keys; for example, 802.1X authentication using EAP-TLS.) 5. Enter the Network key.The length of the key you enter will determine the Key Length (for example, 5 or 13 ASCII characters), so it is not necessary to indicate the length. 6. Select the Key format, if necessary. 7. Select the Key index that the AP is using.This is an important, if under-documented, point: you must use the same key index on the wireless client adapter as you use on the AP. If you are using the WEP key that corresponds to the first

803

804


key configured on the AP, select “0” as the Key index; select “1” as the key index if you are using the second key configured on the AP; and so on.

Shared Key Authentication In Figure A.7, notice the option to select Network authentication (shared mode). You would select this option if you configured the AP to use shared key authentication. Figure A.8 shows the interface for configuring shared key authentication on the Linksys WAP11 AP. Figure A.8 Configuring Shared Key Authentication on WAP11 Access Point

When shared key authentication is turned on,WEP is used as part of the authentication process that occurs between wireless clients and APs. In order for a client workstation to be authenticated with the AP, it would have to be configured with the correct shared-secret WEP key. On the surface, this would appear to be more secure than open system authentication, which allows any client to connect with either an “empty set” SSID, as in the case of open networks, or the correct SSID, as is the case with closed networks. However, as mentioned earlier, shared key authentication is in fact less secure than open system authentication.The reason for this is that shared key authentication relies on a challenge being sent in the clear from the AP to the wireless client.The challenge is then encrypted using WEP and sent back to the AP. An attacker listening on the network would be able to gather enough information to quite easily spoof authentication with the AP and compromise your WEP key.Therefore, although it might seem counterintuitive to choose not to implement a security measure, it is best to stay with the default open system configuration to maintain a higher level of security for your WEP keys. Because of the security weaknesses associated with shared key authentication, Cisco documentation for the Aironet 1100 series AP recommends against using it. Moreover, at least one vendor, Agere, does not even provide the option for using shared key authentication in their firmware because of the security risks associated with it.


Key Management Notwithstanding the vulnerability of WEP to various cipher attacks, the central problem with static WEP keys is key management. In a corporate network with a large number of wireless clients, rotating static WEP keys frequently enough creates an administrative burden that is often too large to manage effectively.To rotate static keys, administrators would either have to configure each workstation individually when the keys changed, or inform users via some mechanism, such as e-mail, of the new keys. In the first situation, administrators would be tied up with mundane configuration changes and users would be inconvenienced. In the latter situation, security of WEP keys is compromised because large numbers of users would have to know the WEP keys, making the compromise of WEP keys through social engineering an even greater threat. Furthermore, every time an employee leaves or a device is stolen, a new WEP key would have to be configured on the APs and the client workstations immediately. On a large network, this is an administrator’s security nightmare. To respond to this type of situation and ease the administrative burden, some vendors have developed proprietary tools in their software that allow administrators to remotely “push” new static WEP keys out to client workstations without the knowledge or intervention of the end user so that the new key will be available the next time the workstation is reinitialized.

MAC Filtering and Authorization Although not part of the 802.11 standards, MAC filtering is offered by many vendors of wireless networks as an additional security measure. Every network card has, in theory, a unique 12-digit hexadecimal number to identify it.This number is known as the MAC address.The purpose of the MAC address is to make possible communication between network devices at layer 2 of the OSI model.

Resolving IP to MAC Addresses with ARP When one host communicates with another host on the same TCP/IP subnet, the host initiating the communication will, after resolving the host or NetBIOS name to a TCP/IP address, resolve the TCP/IP address of the destination to its MAC address.The resolution of the TCP/IP address to a MAC address is accomplished using the Address Resolution Protocol (ARP). For example, HostA attempts to establish a session with the IP address of HostB. Before HostA can initiate the session, it has to know the MAC address of HostB and will send an ARP broadcast on the subnet requesting the MAC address of the destination IP address of HostB. All the active hosts on the subnet hear the ARP broadcast, but only the host with the proper IP address will reply with its MAC address (if the host is on a different subnet, the ARP broadcast request is for the MAC address of the default gateway). Once HostA has the MAC address of HostB, it will append the MAC address to the Ethernet frame and send this frame to the local subnet to begin the process of establishing

805

806


a session. All hosts on the subnet receive this frame, but only HostB will process the frame up the protocol stack because it is the only host whose MAC address matches the MAC address in the frame.The frame also includes information about the MAC address of HostA, so HostB knows what MAC address to insert in any reply frames.

MAC Filtering The concept behind MAC filtering is to provide a means of restricting communication on the wireless network to wireless network cards that possess a valid (pre-authorized) MAC address.Therefore, even though an attacker might be able to receive a valid IP address configuration from a DHCP server on the wireless network or manually configure a valid IP address configuration, he will not be able to authenticate and associate with the AP without possessing a valid MAC address. At this point, the attacker is shut out from the wireless network. Depending on the AP, the list of pre-authorized MAC addresses can be stored in a table on the AP or on a RADIUS server with which the AP communicates.The only advantage to using RADIUS is that it provides an additional level of security for the table of MAC addresses in the event that the AP is compromised as a result of using a weak management password on the AP. Figure A.9 shows the interface for configuring MAC filtering on a Linksys WAP11. Figure A.9 Configuring MAC Filtering on a Linksys WAP11

Entering a list of valid MAC addresses is straightforward. Simply click Add and enter the MAC address. Alternatively, it is possible to load a list of valid MAC address from a text file.This would be useful if you had a database of hardware inventory containing the MAC addresses of wireless network adapters.You could simply extract the list of MAC addresses from the database into a text file and load it into the AP. While MAC filtering sounds good in theory, it is actually a very weak security measure. MAC addresses are always sent in the clear, even when WEP is enabled.This means that anyone who is sniffing the wireless traffic can learn the MAC addresses that are valid on the network. Even though MAC addresses are burned into the hardware of the network adapter, it is possible through the operating system software to change the MAC addresses used for communication on the network. In Windows operating systems, this is accomplished through a simple edit of the Registry; in Linux operating


systems, it is done through a root command. In other words, it is relatively easy to spoof a valid MAC address. However, implementing MAC filtering will stop the casual wardriver and slow the knowledgeable and determined attacker.Thus, it adds an additional barrier for the protection of your wireless network. Like the use of static WEP keys, MAC filtering creates an administrative burden that might be too difficult to manage effectively in a large network environment. Every time an employee leaves or joins the company or a device is lost or stolen, the MAC authorization table has to be updated. If you already have a good hardware inventory system that records the MAC addresses of your network cards and can export this information to a text file, the administrative burden of MAC filtering is significantly reduced. Even if you have a good hardware inventory system in place, MAC filtering might still be too much of an administrative burden to implement, especially if it requires the addition of administrative staff to manage it. In a case such as this, you will want to consider seriously other solutions, such as 802.1X, that also prevent unauthorized wireless stations from authenticating and associating with the AP.

802.1X RADIUS Authentication To provide better security for wireless LANs, and in particular to improve the security of WEP, a number of existing technologies used on wired networks were adapted for this purpose, including: ■

Remote Authentication and Dial-In User Service (RADIUS), which provides for centralized authentication and accounting

■

802.1X, which provides for a method of port-based authentication to LAN ports in a switched network environment.

These two services are used in combination with other security mechanisms, such as those provided by the Extensible Authentication Protocol (EAP), to further enhance the protection of wireless networks. Like MAC filtering, 802.1X is implemented at layer 2 of the OSI model: it will prevent communication on the network using higher layers of the OSI model if authentication fails at the MAC layer. However, unlike MAC filtering, 802.1X is very secure in that it relies on mechanisms that are much harder to compromise than MAC address filters, which can be easily compromised through spoofed MAC addresses. Although a number of vendors implement their own RADIUS servers and security mechanisms and protocols for securing networks through 802.1X, such as Cisco’s LEAP and Funk Software’s EAP-TTLS (Tunneled TLS), this section will focus on implementing 802.1X on a Microsoft network using Internet Authentication Services (IAS) and Microsoft’s Certificate Services. Keep in mind, however, that wireless security standards are a moving target, and standards other than those discussed here, such as the Protected Extensible Authentication Protocol (PEAP), are being developed and might be available now or in the near future.

807

808


Microsoft RADIUS Servers Microsoft’s IAS provides a standards-based RADIUS server and can be installed as an optional component on Microsoft Windows 2000 and .Net servers. Originally designed to provide a means to centralize the authentication, authorization, and accounting for dial-in users, RADIUS servers are now used to provide these services for other types of network access, including VPNs, port-based authentication on switches, and, importantly, wireless network access. IAS can be deployed within Active Directory to use the Active Directory database to centrally manage the login process for users connecting over a variety of network types. Moreover, multiple RADIUS servers can be installed and configured so that secondary RADIUS servers will automatically be used in case the primary RADIUS server fails, providing fault tolerance for the RADIUS infrastructure. Although RADIUS is not required to support the 802.1X standard, it is a preferred method for providing the authentication and authorization of users and devices attempting to connect to devices that use 802.1X for access control.

The 802.1X Standard The 802.1X standard was developed to provide a means of restricting port-based Ethernet network access to valid users and devices.When a computer attempts to connect to a port on a network device, such as switch, it must be successfully authenticated before it can communicate on the network using the port. In other words, communication on the network is impossible without an initial successful authentication.

802.1X Authentication Ports Two types of ports are defined for 802.1X authentication: authenticator or supplicant.The supplicant is the port requesting network access.The authenticator is the port that allows or denies access for network access. However, the authenticator does not perform the actual authentication of the supplicant requesting access.The authentication of the supplicant is performed by a separate authentication service, located a separate server or built into the device itself, on behalf of the authenticator. If the authenticating server successfully authenticates the supplicant, it will communicate the fact to the authenticator, which will subsequently allow access. An 802.1X-compliant device has two logical ports associated with the physical port: an uncontrolled port and a controlled port. Because the supplicant must initially communicate with the authenticator to make an authentication request, an 802.1X-compliant device will make use of a logical uncontrolled port over which this request can be made. Using the uncontrolled port, the authenticator will forward the authentication request to the authentication service. If the request is successful, the authenticator will allow communication on the LAN via the logical controlled port.


The Extensible Authentication Protocol EAP is used to pass authentication requests between the supplicant and a RADIUS server via the authenticator. EAP provides a way to use different authentication types in addition to the standard authentication mechanisms provided by the Point-to-Point Protocol (PPP). Using EAP, stronger authentication types can be implemented within PPP, such as those that use public keys in conjunction with smart cards. In Windows, there is support for two EAP types: ■

EAP MD-5 CHAP

■

EAP-TLS

EAP MD-5 CHAP allows for authentication based on a username/password combination.There are a number of disadvantages associated with using EAP MD-5 CHAP. First, even though it uses one-way hashes in combination with a challenge/response mechanism, critical information is still sent in the clear, making it vulnerable to compromise. Second, it does not provide mutual authentication between the client and the server; the server merely authenticates the client.Third, it does not provide a mechanism for establishing a secure channel between the client and the server. In a paper published in February 2002 by William A. Arbaugh and Arunesh Mishra entitled “An Initial Security Analysis of the IEEE 802.1x Standard,” the authors state that one-way authentication and other weaknesses made 802.1X vulnerable to man-in-themiddle and session hijacking attacks.Therefore, while it might be possible to use EAP MD-5 CHAP for 802.1X wireless authentication on Windows XP (pre SP1), it is not recommended. EAP-TLS protects against the types of attacks described by this paper. EAP-TLS is a security mechanism based on X.509 digital certificates and is more secure than EAP MD-5 CHAP.The certificates can be stored in the Registry or on devices such as smart cards.When EAP-TLS authentication is used, both the client and server validate one another by exchanging X.509 certificates as part of the authentication process. Additionally, EAP-TLS provides a secure mechanism for the exchange of keys to establish an encrypted channel. Although the use of EAP-TLS is more difficult to configure, in that it requires the implementation of a public key infrastructure (PKI)—not a trivial undertaking—EAP-TLS is recommended for wireless 802.1X authentication.

The 802.1X Authentication Process For 802.1X authentication to work on a wireless network, the AP must be able to securely identify traffic from a particular wireless client.This identification is accomplished using authentication keys that are sent to the AP and the wireless client from the RADIUS server.When a wireless client (802.1X supplicant) comes within range of the AP (802.1X authenticator), the following simplified process occurs: 1. The AP point issues a challenge to the wireless client. 2. The wireless client responds with its identity.

809

810


3. Using the uncontrolled port, the AP forwards the identity to the RADIUS server. 4. The RADIUS server sends a request to the wireless station via the AP, specifying the authentication mechanism to be used (for example, EAP-TLS). 5. The wireless station responds to the RADIUS server with its credentials via the AP. 6. If the credentials pass muster, the RADIUS server sends an encrypted authentication key to the AP. 7. The AP generates a multicast/global authentication key encrypted with a perstation unicast session key, and transmits it to the wireless station. Figure A.10 shows a simplified version of the 802.1X authentication process using EAP-TLS. Figure A.10 802.1X Authentication Process Using EAP-TLS Local Area Network Supplicant (Wireless Client)

Authenticator (Access Point) Controlled Port Uncontrolled Port

Association Request EAP Request (Identity) EAP Response (Identity)

EAP Response (Identity) EAP Request (EAP-TLS)

EAP Request (EAP-TLS) EAP Response (credentials) Success Message

Authenticating Server

EAP Response (credentials) Keys for encryption generated and transmitted to supplicant

Success Message with Authentication Key

Secure Access to LAN via Controlled Port on AP

When the authentication process successfully completes, the wireless station is allowed access to the controlled port of the AP, and communication on the network can occur. Note that much of the security negotiation in the preceding steps occurs on the 802.1X uncontrolled port, which is only used so that the AP can forward traffic associated with the security negotiation between the client and the RADIUS server. EAP-TLS is required for the process to take place. EAP-TLS, unlike EAP MD-5 CHAP, provides a mechanism to allow the secure transmission of the authentication keys from the RADIUS server to the client.


Advantages of EAP-TLS There are a number of significant advantages to using EAP-TLS authentication in conjunction with 802.1X: ■

The use of X.509 digital certificates for authentication and key exchange is very secure.

■

EAP-TLS provides a means to generate and use dynamic one-time-per-user, session-based WEP keys on the wireless network.

■

Neither the user nor the administrator know the WEP keys that are in use.

For these reasons, using EAP-TLS for 802.1X authentication removes much of the vulnerability associated with using WEP and provides a high degree of assurance. In the following section, we will look at how to configure 802.1X using EAP-TLS authentication on a Microsoft-based wireless network. If you are using other operating systems and software, the same general principles will apply. However, you might have additional configuration steps to perform, such as the installation of 802.1X supplicant software on the client.Windows XP provides this software within the operating system.

Configuring 802.1X Using EAP-TLS Before you can configure 802.1X authentication on a wireless network, you must satisfy a number of prerequisites. At a minimum, you need the following: ■

An AP that supports 802.1X authentication.You probably won’t find these devices at your local computer hardware store.These devices are designed for enterprise-class wireless network infrastructures.You will pay an according higher price for these devices. Some devices will allow the use of IPSec between the AP and the wired network.

■

Client software and hardware that supports 802.1X and EAP-TLS authentication and the use of dynamic WEP keys. Fortunately, just about any wireless adapter that allows the use of the Windows XP wireless interface will work. Older wireless network adapters that use their own client software might not work.

■

IAS installed on a Windows 2000 server to provide a primary RADIUS server and, optionally, installed on other servers to provide secondary RADIUS servers for fault tolerance.

■

Active Directory.

■

A PKI using a Microsoft stand-alone or Enterprise Certificate server to support the use of X.509 digital certificates for EAP-TLS. More certificate servers can be deployed in the PKI for additional security. An Enterprise Certificate server can ease the burden of certificate deployment to clients and the

811

812


RADIUS server through auto-enrollment of client computers that are members of the Windows 2000 domain. ■

The most recent service packs and patches installed on the Windows 2000 servers and Windows XP wireless clients.

After configuring a PKI and installing IAS on your Windows 2000 network, there are three general steps to configure 802.1X authentication on your wireless network: 1. Install X.509 digital certificates on the wireless client and IAS servers. 2. Configure IAS logging and policies for 802.1X authentication. 3. Configure the wireless AP for 802.1X authentication. 4. Configure the properties of the client wireless network interface for dynamic WEP key exchange.

Configuring Certificate Services and Installing Certificates on the IAS Server and Wireless Client After deploying Active Directory, the first step in implementing 802.1X is to deploy the PKI and install the appropriate X.509 certificates. Much of the information necessary to configure a PKI is covered in Chapter 12. In brief, you will have to install (at a minimum) a single certificate server, either a stand-alone or enterprise certificate server, to issue certificates.What distinguishes a stand-alone from an enterprise certificate server is whether it will depend on and be integrated with Active Directory: a stand-alone CA does not require Active Directory.This certificate server can be a root CA or a subordinate CA, which ultimately receives its authorization to issue certificates from a root CA higher in the hierarchy, either directly or indirectly through intermediate CAs, according to a certification path. The root CA can be a commercially available CA (public CA) that issues an authorization to a subordinate CA, or one deployed on the Windows 2000 network. In enterprise networks that require a high degree of security, it is not recommended that you use the root CA to issue client certificates; for this purpose, you should use a subordinate CA authorized by the root CA. In very high-security environments, you should use intermediate CAs to authorize the CA that issues client certificates. Furthermore, you should secure the hardware and software of the root and intermediate CAs as much as possible, take them offline, and place them in a secure location.You then bring the root and intermediate CAs online only when you need to perform tasks related to the management of your PKI. In deploying your PKI, keep in mind that client workstations and the IAS servers need to be able to consult a certificate revocation list (CRL) to verify and validate certificates, especially certificates that have become compromised before their expiration date and have been added to a CRL. If a CRL is not available, authorization will fail.


Consequently, a primary design consideration for your PKI is to ensure that the CRLs are highly available. Normally, the CRL is stored on the CA; however, additional distribution points for the CRL can be created to ensure a high degree of availability.The CA maintains a list of these locations and distributes the list in a field of the client certificate. Whether you decide to implement a stand-alone or an enterprise CA to issue certificates, you will need to issue three certificates.You will need a certificate for both the computer and the user account on the wireless client.The computer certificate provides initial access of the computer to the network, and the user certificate provides the wireless access after the user logs in.The RADIUS server also requires a computer certificate. A certificate is required in all of these places because mutual authentication has to take place.The RADIUS server will authenticate the client based on the wireless client’s computer and user certificates, and the wireless client will authenticate the RADIUS server based on the server’s certificate. The certificates on the wireless client and the RADIUS server do not have to be issued by the same CA. However, both the client and the server have to trust each other’s certificates.Within each certificate is information about the certificate path leading up to the root CA. If both the wireless client and the RADIUS server trust the root CA in each other’s certificate, mutual authentication can successfully take place. If you are using a stand-alone CA that is not in the list of Trusted Root Certification Authorities, you will have to add it to the list.You can do this through a Group Policy object, or you can do it manually. For information on how to add CAs to the Trusted Root Certification Authorities container, please see Windows 2000 and Windows XP help files.The container listing this trusted root certificates can be viewed in the Certificates snap-in of the MMC console, as in Figure A.11. Figure A.11 Certificate Snap-In Showing Trusted Root Certification Authorities

Using an enterprise CA will simplify many of the tasks related to certificates that you have to perform. An enterprise CA is automatically listed in the Trusted Root Certification Authorities container. Furthermore, you can use auto-enrollment to issue computer certificates to the wireless client and the IAS server without any intervention

813

814


on the part of the user. Using an enterprise CA and configuring auto-enrollment of computer certificates should be considered a best practice. If you put an enterprise CA into place, you will have to configure an Active Directory Group Policy to issue computer certificates automatically.You should use the Default Domain Policy for the domain in which your CA is located.To configure the Group Policy for auto-enrollment of computer certificates, do the following: 1. Using Active Directory Users and Computers, access the Properties of the Group Policy object for the domain to which the enterprise CA belongs, and click Edit. 2. Go to Computer Settings | Windows Settings | Security Settings | Public Key Policies | Automatic Certificate Request Settings. 3. With the alternate mouse button, click Automatic Certificate Request Settings, then click New, and then click Automatic Certificate Request, as in Figure A.12. Figure A.12 Configuring a Domain Group Policy for Auto-Enrollment

4. Click Next when the wizard appears; click Computer in the Certificate Templates, as shown in Figure A.13, and then click Next. Figure A.13 Choosing a Computer Certificate Template for Auto-Enrollment

5. Click on the enterprise CA, click Next, and then click Finish.


After you have configured a Group Policy for auto-enrollment of computer certificates, you can force a refresh of the Group Policy so that it will take effect immediately, rather than waiting for the next polling interval for Group Policy Changes, which could take as long as 90 minutes.To force Group Policy to take effect immediately on a Windows XP computer, type the command gpupdate /target:computer. Once you have forced a refresh of Group Policy, you can confirm if the computer certificate is successfully installed.To confirm the installation of the computer certificate: 1. From Start | Run, type the command mmc and click OK. 2. In the MMC console menu, click File, and then click Add/Remove Snap-in. 3. In the Add/Remove Snap-in dialog box, click Add.Then, select Certificates from the list of snap-ins and click Add.You will be prompted to choose which certificate store the snap-in will be used to manage. 4. Select computer account when prompted about what certificate the snap-in will be used to manage, and then click Next.You will be prompted to select the computer the snap-in will manage. 5. Select Local computer (the computer this console is running on) and click Finish.Then, click Close and then click OK to close the remaining dialog boxes. 6. You will see a display similar to the one in Figure A.13. Navigate to the Console Root | Certificates (Local Computer) | Personal | Certificates container.The certificate should be installed there. The next step is to install a user certificate on the client workstation and then map the certificate to a user account.There are a number of ways to install a user certificate: through Web enrollment, by requesting the certificate using the Certificates snap-in, by using a CAPICOM script (which can be executed as a login script to facilitate deployment), or by importing a certificate file.The following steps demonstrate how to request the certificate using the Certificates snap-in: 1. Open an MMC console for Certificates – Current User. (To load this snap-in, follow the steps in the preceding procedure; however, at step 5, select My user account.) 2. Navigate to Certificates | Personal and click on the container with the alternate mouse button. Highlight All Tasks and then click on Request New Certificate as shown in Figure A.14.The Certificate Request Wizard appears. 3. Click Next on the Certificate Request Wizard welcome page. 4. On the Certificate Types, select User and click Next as shown in Figure A.15.You can also select the Advanced check box. Doing so will be allow you to select from a number of different Cryptographic Service Providers (CSPs), to choose a key length, to mark the private key as exportable (the

815

816


option might not be available for selection), and to enable strong private key protection.The latter option will cause you to be prompted for a password every time the private key is accessed. Figure A.14 Requesting a User Certificate

Figure A.15 Choosing a Certificate Type

5. Type in a Friendly Name of your choosing and a Description, and then click Next. 6. Review your settings and click Finish. You now should have a user certificate stored on the computer used for wireless access. However, this user certificate will not be usable for 802.1X authentication unless it is mapped to a user account in Active Directory. By default, the certificate should be mapped to the user account.You can verify if it has been mapped by viewing the Properties of the user account in Active Directory Users and Computers.The certificates that are mapped to the user account can be viewed in the Published Certificates tab of the Properties of the user account object. After you configure certificate services and install computer and user certificates on the wireless client and a computer certificate on the RADIUS server, you must configure the RADIUS server for 802.1X authentication.

Configuring IAS Server for 802.1X Authentication If you have configured RRAS for dial-in or VPN access, you will be comfortable with the IAS Server interface. It uses the same interfaces for configuring dial-in conditions


and policies as does RRAS.You can use IAS to centralize dial-in access policies for your entire network, rather than have dial-in access policies defined on each RRAS server. A primary advantage of doing this is easier administration and centralized logging of dial-in access. Installing an IAS server also provides a standards-based RADIUS server that is required for 802.1X authentication. As with configuring RRAS, you will need to add and configure a Remote Access Policy to grant access. A Remote Access Policy grants or denies access to remote users and devices based on matching conditions and a profile. For access to be granted, the conditions you define have to match. For example, the dial-in user might have to belong to the appropriate group, or connect during an allowable period.The profile in the Remote Access Policy defines such things as the authentication type and the encryption type used for the remote access. If the remote client is not capable of using the authentication methods and encryption strength defined in the profile, access is denied. For 802.1X authentication, you will have to configure a Remote Access Policy that contains conditions specific to 802.1X wireless authentication and a Profile that requires the use of the Extensible Authentication Protocol (EAP) and strong encryption. After configuring the Remote Access Policy, you will have to configure the IAS server to act as a RADIUS server for the wireless AP, which is the RADIUS client. Before installing and configuring the IAS server on your Windows 2000 or .NET/ 2003 network, you should consider whether you are installing it on a domain controller or member server (in the same or in a different domain). If you install it on a domain controller, the IAS server will be able to read the account properties in Active Directory. However, if you install IAS on a member server, you will have to perform an additional step to register the IAS server, which will give it access to Active Directory accounts. There are a number of ways you can register the IAS server: ■

The IAS snap-in

■

The Active Directory Users and Computers admin tool

■

The netsh command

Once you have installed and, if necessary, registered the IAS server(s), you can configure the Remote Access Policy. Before configuring a Remote Access Policy, make sure that you apply the latest service pack and confirm that the IAS server has an X.509 computer certificate. In addition, you should create an Active Directory Global or Universal Group that contains your wireless users as members. The Remote Access Policy will need to contain a condition for NAS-PortType that contains values for Wireless-Other and Wireless-IEEE802.11 (these two values are used as logical OR for this condition) and a condition for WindowsGroups=[the group created for wireless users]. Both conditions have to match (logical AND) for access to be granted by the policy.

817

818


The Profile of the Remote Access Policy will need to be configured to use the Extensible Authentication Protocol, and the Smart Card or Other Certificate EAP type. Encryption in the Profile should be configured to force the strongest level of encryption, if supported by the AP. Depending on the AP you are using, you might have to configure vendor specific attributes (VSA) in the Advanced tab of the Profile. If you have to configure a VSA, you will need to contact the vendor of the AP to find out the value that should be used, if you can’t find it in the documentation. To configure the conditions for a Remote Access Policy on the IAS server: 1. From Start | Programs | Administrative Tools, select Internet Authentication Services and open the IAS console. 2. With the alternate mouse button, click on Remote Access Policies, and from the subsequent context menu, click New Remote Access Policy. 3. Enter a friendly name for the policy and click Next. 4. In the Add Remote Access Policy Conditions dialog box, click Add. Then, select NAS-Port-Type in the Select Attribute dialog box and click Add as shown in Figure A.16. Figure A.16 Adding a NAS-Port-Type Condition to Remote Access Policy

5. In the NAS-Port-Type dialog, select Wireless-IEEE 802.11 and Wireless – Other from the left-hand window, and click Add>> to move them to the Selected types window as shown in Figure A.17. Click OK. Figure A.17 Adding Wireless NAS-Port-Type Conditions


6. After configuring the NAS-Port-Type conditions, add a condition for Windows-Groups that contains the group you created for wireless users. Then, click Next. 7. In the subsequent Permissions page for the new policy, click the radio button to Grant remote access permission if user matches conditions. The next step is to configure the Profile to support EAP-TLS and force the strongest level of encryption (128 bit). 8.

Click Edit Profile and click the Authentication tab.

9. Confirm that the check box for Extensible Authentication Protocol is selected and that Smart Card or Other Certificate is listed as the EAP type in the drop-down box. Clear all the other check boxes and click Configure. 10. Select the computer certificate you installed for use by the IAS server, and click OK.The resulting Authentication tab should look like the one in Figure A.18. Figure A.18 Configuring the Dial-In Profile for 802.1X Authentication

11. To force the strongest level of encryption, click the Encryption tab and clear all the check boxes except the one for Strongest. 12. Save the policy by clicking OK and then Finish. 13. Make sure that the policy you created is higher in the list than the default Remote Access Policy.You can delete the default policy if you like. Finally, you need to configure the IAS server for RADIUS authentication.To do this, you need to add a configuration for the RADIUS client, in this case, the AP, to the IAS server: 14. In the IAS console, click the Clients folder with the alternate mouse button and click New Client from the context menu.

819

820


15. Supply a friendly name for the configuration and click Next.The screen shown in Figure A.19 appears. Figure A.19 Adding a RADIUS Client

16. Configure the screen with the Client address (IP or DNS) of the wireless AP, and click the check box indicating that the Client must always send the signature attribute in the request. For the Shared secret, add an alphanumeric password that is at least 22 characters long for higher security. 17. Click Finish. You can change the port numbers for RADIUS accounting and authentication by obtaining the properties of the Internet Authentication Service container in the IAS console.You can also use these property pages to log successful and unsuccessful authentication attempts and to register the server in Active Directory. After installing certificates on the wireless client and IAS server and configuring the IAS server for 802.1X authentication, you will need to configure the AP and the wireless client.The following text shows the typical steps to complete the configuration of your wireless network for 802.1X authentication.

Configuring an Access Point for 802.1X Authentication Generally, only enterprise-class APs support 802.1X authentication; this is not a feature found in devices intended for the SOHO market. Enterprise-class APs are not likely to be found in your local computer store. If you want an AP that supports 802.1X, you should consult the wireless vendors’Web sites for information on the features supported by the APs they manufacture.Vendors that manufacture 802.1X-capable devices include 3Com, Agere, Cisco, and others.The price for devices that support 802.1X authentication usually start at around $500 USD and can cost considerably more, depending on the vendor and the other features supported by the AP. If you already own an enterprise-class AP, such as an ORiNOCO Access Point 500 or Access Point 1000, 802.1X authentication might not be supported in the original firmware but can be added through a firmware update.


Regardless of the device you purchase, an 802.1X-capable AP will be configured similarly.The following text shows the typical configuration of 802.1X authentication on an ORiNOCO Access Point 500 with the most recent firmware update applied to it. The configuration of the AP is straightforward and simple.You will need to configure the following: ■

An encryption key length This can be either 64 or 128 bits (or higher if your hardware and software support longer lengths).

■

An encryption key lifetime When you implement 802.1X using EAPTLS,WEP encryption keys are dynamically generated at intervals you specify. For higher security environments, the encryption key lifetime should be set to 10 minutes or less.

■

An authorization lifetime This is the interval at which the client and server will re-authenticate with one another.This interval should be longer than the interval for the encryption key lifetime, but still relatively short in a high-security environment. A primary advantage here is that if a device is stolen, the certificates it uses can be immediately revoked.The next time it tries to authenticate, the CRL will be checked and authentication will fail.

■

An authorization password This is the shared-secret password you configured for RADIUS client authentication on the IAS server.This password is used to establish communication between the AP and the RADIUS server. Thus, it needs to be protected and be long and complex.This password should be at least 22 characters long and use mixed case, numbers, letters, and other characters.You might want to consider using a random string generation program to create this password for you.

■

An IP address of a primary and, if configured for fault tolerance, a secondary RADIUS server If the AP is in a DMZ and the RADIUS server is behind a firewall, this IP address can be the external IP address of the firewall.

■

A UDP port used for RADIUS authentication The default port for RADIUS is port 1645. However, you can change this port on the IAS server and the AP for an additional degree of security.

Depending on your AP, you might have to go through additional configuration steps. For example, you might have to enable the use of dynamic WEP keys. On the AP 500, this configuration is automatically applied to the AP when you finish configuring the 802.1X settings, as shown in Figure A.20. Consult your AP’s documentation for specific information on configuring it for 802.1X authentication.

821

822


Figure A.20 Configuring an ORiNOCO AP 500 for 802.1X Authentication

Configuring the Wireless Interface on Windows XP for 802.1X Authentication If you have been following the preceding steps in the same order for configuring 802.1X authentication, the final step is to configure the properties of the wireless interface in Windows XP.You will have to ensure that the properties for EAP-TLS authentication and dynamic WEP are configured.To do this, perform the following steps: 1. Obtain the Properties of the wireless interface and click on the Authentication tab. 2. Ensure that the check box for Enable access control for IEEE 802.1X is checked and that Smart Card or other Certificate is selected as the EAP type. 3. Click Properties to view the Smart Card or other Certificate Properties. Ensure that the check box for Validate server certificate is checked. 4. In the Trusted root certificate authority drop-down box, select the root CA of issuer of the server certificate, if it is not already present, and click OK. For additional security, you could select the check box for Connect only if server name ends with and type in the root DNS name; for example, tacteam.net. 5. Obtain the properties of the wireless interface and click on the Wireless Network tab. 6. In the Preferred networks dialog box, confirm that the check box for Use Windows for my wireless network settings is selected, highlight the SSID of the 802.1X-enabled AP, and click Properties. 7. Click the check box for The key is provided from me automatically, and then click OK.


That’s it.You’re finished.The next time you attempt to authenticate and associate with the 802.1X-enabled AP, you might be presented with a prompt asking you to verify the identity of the IAS server certificate. By clicking OK, you will allow the authentication process to complete and you will be allowed secure access to the network. Let’s briefly review the steps to enable 802.1X authentication.We are assuming that you are using Active Directory, already have a PKI in place, can issue certificates from a Microsoft CA, and have installed and registered (if necessary) an IAS server. 1. Issue computer certificate to IAS server. 2. Issue computer certificate to wireless client. 3. Issue user certificate to wireless client user. 4. Create a Remote Access Policy on the IAS server for 802.1X authentication. 5. Configure RADIUS client settings on the IAS server. 6. Configure AP for 802.1X authentication. 7. Configure wireless client network interface for 802.1X authentication. Although this might seem like a lot of work, the enhanced security provided by 802.1X might well justify the expense and effort of setting it up. Furthermore, much of the effort is up front. Since you don’t have to worry about frequently rotating static WEP keys, you will realize significant savings in effort and time later. 802.1X authentication in combination with EAP-TLS is not the final word in wireless security. It mitigates many of the vulnerabilities associated with wireless networks, but other types of attacks might still be possible.

Additional Security Measures for Wireless Networks Although 802.1X authentication provides good security through the use of dynamically generated WEP keys, security administrators might want to add more layers of security. Additional security for wireless networks can be introduced through the design of the network itself. A wireless network should always be treated as an untrusted network.This has implications for the design and topology of the wireless network.

Using a Separate Subnet for Wireless Networks Many wireless networks are set up on the same subnets as the wired network. In addition, to make life easier for administrators and users alike, both wired and wireless clients are often configured as DHCP clients and receive IP address configurations from the same DHCP servers.There is an obvious security problem with this approach.This configuration makes it easy for hackers to acquire valid IP address configurations that are on the same subnet as the corporate networks, which can pose a significant threat to the security of the network. The solution is to place wireless APs on their own separate subnets, creating in effect a type of DMZ for the wireless network.The wireless subnet could be separated

823

824


from the wired network by either a router or a full-featured firewall, such as ISA server. There are a number of advantages to this approach.When the wireless network is placed on a separate subnet, the router can be configured with filters to provide additional security for the wireless network. Furthermore, by using an extended subnet mask on the wireless network, the number of valid IP addresses can be limited to approximately the number of valid wireless clients. Finally, in case of potential attack on the wireless network, you can quickly shut down the router and prevent further access to the wired network until the threat is removed. If you have to support automatic roaming between wireless zones, you will still want to use DHCP on the wireless subnets. However, if you don’t have to support automatic roaming, you might want to consider not using DHCP and manually configure IP addresses on the wireless clients.This will not prevent a hacker from sniffing for valid IP addresses to use on the wireless subnet, but it will provide another barrier for entry and slow the attacker. Additionally, if a hacker manually configures an IP address that is in use by another wireless client, the valid user will receive an IP address conflict message, providing a crude method for detecting unauthorized access attempts.

Using VPNs for Wireless Access to Wired Network In high-security networks, administrators might want to leverage the separate subnet by only allowing access to the wired network through a VPN configured on the router or firewall. For wireless users to gain access to the wired network, they would first have to successfully authenticate and associate with the AP and then create a VPN tunnel for access to the wired network. Some vendors, such as Colubris, offer VPN solutions built into wireless devices.These devices can act as VPN-aware clients that will forward only VPN traffic from the wireless network to the wired network, or they can provide their own VPN server for wireless clients. However, it is not necessary to use a proprietary hardware-based solution. One solution is to use a freeware solution known as Dolphin from www.reefedge.com that turns a PC into an appliance that will encrypt wireless traffic with IPSec. When a VPN is required for access to the corporate network from the wireless network subnet, all traffic between the two networks is encrypted within the VPN tunnel. If you are using static WEP, a VPN will ensure a higher degree of confidentiality for your traffic. Even if the WEP encryption is cracked, the hacker would then have to crack the VPN encryption to see the corporate traffic, which is a much more difficult task. If a wireless laptop is stolen and the theft is unreported, the thief would have to know the user credentials to gain access to the VPN. Of course, this type of configuration is still vulnerable to attack. If, for example, the attacker has somehow acquired usernames and passwords (or the user has saved them in the VPN connection configuration), he or she can still access the wired network through the VPN. Another consideration is the additional overhead of encryption used in the VPN tunnel. If you are also using WEP, the combined loss of bandwidth as a


result of the encryption could easily be noticeable. Again, administrators will have to compare the benefits of implementing a VPN for wireless clients in a DMZ against the cost of deployment in terms of hardware, software, management, loss of bandwidth, and other factors. Setting up this type of configuration can be a relatively complex undertaking, depending on a number of factors. If, for example, you are using 802.1X authentication, you might have to ensure that 802.1X-related traffic can pass between the wireless and wired network without a VPN tunnel. If you are using ISA Server to separate the networks, you would have to publish the RADIUS server on the corporate network to the wireless network.You can find information on setting up ISA Server for this type of configuration throughout this book.

Temporal Key Integrity Protocol As noted earlier, the use of WEP even in combination with 802.1X authentication and EAP-TLS, while providing a much higher standard of security does not mitigate all the potential threats to the confidentiality and integrity of the data. As an interim solution, until the IEEE 802.11i standard is implemented and finalized, many vendors are using or considering using TKIP as a temporary solution to enhance the security of wireless networks.The TKIP standard has not been finalized at the time of this writing, but some vendors are already implementing it (for example, Cisco, which initially developed TKIP as a proprietary technology for use in its products). TKIP can be used with or as an alternative to 802.1X authentication.TKIP comprises a set of algorithms that enhance WEP. It provides more security than WEP by using key mixing, an extended IV, a MIC, and rekeying. A primary advantage of TKIP is that it can be implemented through firmware updates of current devices (another reason why you should only purchase devices capable of firmware updates).TKIP addresses the problem of static WEP keys by frequently changing the temporal key used for the encryption process every 10,000 packets. Additionally, the use of TKIP addresses another vulnerability of static WEP: the use of the same shared key by all the wireless devices.TKIP ensures that each wireless station uses a different key for the encryption process.TKIP accomplishes this by using a 128-bit temporal key that is shared between the wireless workstations and the AP.The temporal key is then combined with the MAC address of each of the wireless devices to provide the encryption key used for RC4 encryption on the wireless network by that device.This also reduces the vulnerability to attacks based the fact that the IV is sent in the clear in standard WEP implementations, by adding another layer of encryption.

Message Integrity Code Another vulnerability of WEP is that it is relatively easy for a knowledgeable and determined attacker to modify (flip) bits in an intercepted message, recalculate the appropriate CRC (also known as the integrity checksum value, or ICV), and then send the

825

826


altered message to the AP. Because the CRC is spoofed, the AP will accept the altered message and reply to it, providing information that the attacker could use to crack the WEP encryption.This form of attack was described in a paper entitled “Intercepting Mobile Communications:The Insecurity of 802.11” by Nikita Borisov, Ian Goldberg, and David Wagner. MIC, which is also part of the TKIP algorithms, provides a much stronger mechanism for checking the message for evidence of tampering by adding a MIC value that is encrypted and sent with the message. Upon receipt, the MIC value is decrypted and compared with the expected value. MIC is, in reality, a form of Message Authentication Code, often referred to as MAC and which is a standard cryptographic term. However, because “MAC” is already used quite frequently with regard to wireless networks in regard to the Media Access Control address, “MIC” is used to differentiate the two.

Wi-Fi Protected Access (WPA) Standard On October 31, 2002, the Wi-Fi Alliance announced that it would begin interoperability testing for a new security solution to replace WEP.This solution, known as WiFi Protected Access (WPA), draws on many of the elements of the forthcoming 802.11i standard and is designed to be compatible with it. For example, the WPA standard will require the use of TKIP.WPA will be available as a software or firmware update on WiFi compatible devices.The WPA standard defines two modes, one for the corporate environment and one for the SOHO environment. For the corporate environment, the WPA standard uses 802.1X and EAP for the authentication mechanism. For the SOHO environment, the WPA-compliant devices run in pre-Shared Key (PSK) mode.When PSK is enabled, users enter a password, referred to as a master key, on the AP and the wireless client. Only devices that have the correct password can connect to the network. Once connected, the master key starts the TKIP process.The fact that the Wi-Fi Alliance is supporting TKIP in the WPA standard is significant and should mean the wide availability of firmware updates providing greater security on 802.11b devices in the near future.

IEEE 802.11i Standard Negative response to the weaknesses of WEP has been vociferous and strong.To address the criticisms leveled at WEP and to provide a stronger standards-based security mechanism that vendors can implement in their products, the IEEE 802.11i Task Group is working on the upcoming 802.11i standard. Although the standard is not finalized, some things about its final form are fairly certain.The standard will take the best of the technology available today for securing wireless networks and combine them into a single, coherent standard.The following are expected to be included in the standard: ■

The 802.11i standard will require the use of 802.1X authentication based on EAP.


The 802.11i standard will also likely require the use of TKIP and MIC.

■

For new devices, the standard will also require the use of Advanced Encryption Standard (AES) as a replacement for the compromised RC4 algorithm.

AES provides much stronger encryption than RC4. However, because of the additional processing power required for AES encryption, the addition of a co-processor will likely be necessary in the hardware of wireless devices.When this technology becomes available in the marketplace, replacing legacy wireless devices could result in a significant expenditure. As with all other security measures, administrators and managers will have to compare the costs of implementation against the threats the implementation will mitigate.

Summary Wireless LANs are attractive to many companies and home users because of the increased productivity that results from the convenience and flexibility of being able to connect to the network without the use of wires.WLANs are especially attractive when they can reduce the costs of having to install cabling to support users on the network. For these and other reasons,WLANs have become very popular in the past few years. However,Wireless LAN technology has often been implemented poorly and without due consideration of the security of the network. For the most part, these poor implementations result from a lack of understanding of the nature of wireless networks and the measures that can be taken to secure them. WLANs are inherently insecure because of their very nature: the fact that they radiate radio signals containing network traffic that can be viewed and potentially compromised by anyone within range of the signal.With the proper antennas, the range of WLANs is much greater than is commonly assumed. Many administrators wrongly believe that their networks are secure because the interference created by walls and other physical obstructions combined with the relative low power of wireless devices will contain the wireless signal sufficiently. Often, this is not the case. There are a number of different types of wireless networks that can be potentially deployed.These include HomeRF, Bluetooth, 802.11b, and 802.11a networks.The most common type of WLAN in use today is based on the IEEE 802.11b standard. WEP is insecure for a number of reasons.The first is that, because it encrypts wellknown and deterministic IP traffic in layer 3, it is vulnerable to plaintext attacks.That is, it is relatively easy for an attacker to figure out what the plaintext traffic is (for example, a DHCP exchange) and compare that with the ciphertext, providing a powerful clue for cracking the encryption. Although WEP is insecure, it does nonetheless potentially provide a good barrier, and its use will slow determined and knowledgeable attackers.WEP should always be

827

828


implemented.The security of WEP is also dependent on how it is implemented. Because the IV keyspace can be exhausted in a relatively short amount of time, static WEP keys should be changed frequently. The best defense for a wireless network involves the use of multiple security mechanisms to provide multiple barriers that will slow attackers, making it easier to detect and respond to attacks.This strategy is known as defense in depth. Securing a wireless network should begin with changing the default configurations of the wireless network devices.These configurations include the default administrative password and the default SSID on the access point (AP). The Service Set Identifier (SSID) is a type of network name, analogous to an SNMP community name or a VLAN ID. In order for the wireless clients to authenticate and associate with an AP, they must use the same SSID as the one in use on the AP. It should be changed to a unique value that does not contain any information that could potentially be used to identify the company or the type of traffic on the network. By default, SSIDs are broadcast in response to beacon probes and can be easily discovered by site survey tools such as Netstumbler and Windows XP. It is possible to turn off SSID on some APs. Disabling SSID broadcasts creates a “closed network.” If possible, SSID broadcasts should be disabled, although this will interfere with Windows XP’s ability to automatically discover wireless networks and associate with them. However, even if SSID broadcasts are turned off, it is still possible to sniff the network traffic and see the SSID in the frames. Wireless clients can connect to APs using either open system or shared key authentication.While shared key authentication provides protection against some denial of service (DoS) attacks, it creates a significant vulnerability for the WEP keys in use on the network and should not be used. MAC filtering is another defensive tactic that can be employed to protect wireless networks from unwanted intrusion. Only the wireless stations with adapters that have valid MAC addresses are allowed to communicate with the AP. However, MAC addresses can be easily spoofed, and maintaining a list of valid MAC addresses might be impractical in a large environment. A much better way to secure WLANs is to use 802.1X. 802.1X was originally developed to provide a method for port-based authentication on wired networks. However, it was found to have significant application in wireless networks.With 802.1X authentication, a supplicant (a wireless workstation) needs to be authenticated by an authenticator (usually a RADIUS server) before access is granted to the network. The authentication process takes place over a logical uncontrolled port that is used only for the authentication process. If the authentication process is successful, access is granted to the network on the logical controlled port.

Index 802.11 wireless standards, 776, 780-782, 808

A access allowing DMZ servers to internal network, 125-126 creating rules for, 48-49 permissions. See permissions policies, 127 access control DMZ segment, 71 on external ISA server (fig.), 128 settings, Registry default, Users and Power Users (table), 468-472 accessing encrypted files, 545 Account Lockout Policy, 502, 503 Account Policies analysis area, 495 configuring, 502-504 Windows 2000, 479 accounts, setting for firewall chaining, 139 Active Directory Application Center 2000, 58 array option support, 39 certificate authorities and, 668 enterprise initialization, 20 installing schema for ISA Server installations, 66 installing Windows 2000 PKI, 675-679 ISA integration with, 4 ISA Server Enterprise Edition and, 10, 27 LATDMZ and, 214 Active Mode FTP, 100-101 Active X Software Developer’s Kit, 711 add-ons, third-party software for ISA Server, 59-60 addresses, resolving IP to MAC with ARP, 805 address mapping, SMTP server, configuring, 96 Administrative Tools, installation, 33

Administrator Group, properties, General and Members tabs (fig.), 481 Administrators group,Windows 2000, 450-451 AH (authentication header), 593 AirSnort, 799 algorithms, 534, 537 allow filters, 6-7 alternating current (AC), radio frequency communication, 775 alternative ports, publishing FTP servers on, 287 analyzing account and local policies, 522 File System security, 523 local machine, 521 Registry security, 523 restricted group policy, 522 scripts with secedit.exe, 530 security, 521-524, 788-789 system Services security, 524 Antheil, George, 776 APIPA (Automatic Private IP Addressing), 181 APIs, ISA Server client equivalences, 43 Application Center 2000, 58 application-directed attacks, 584 application filtering, 8-9 application programming interfaces. See APIs applications, communicating with hardware device (fig.), 635 architecture EFS, 561-564 IPSec, 586 private address back-to-back DMZ for VPN connections (fig.), 177 wireless network, 778-779 array policy option, 37-41 asymmetric cryptography, 538, 658 attachments, e-mail, blocking (fig.), 371 attacks

application-directed, 584 common exploits of wireless networks, 790-794 compromised key, 585-586 DoS, 3, 77, 582-583, 789 man-in-the-middle, 584 Ping-of-Death, 584 plaintext, 799 SMURF, 583 TCP/IP sequence number, 580 TCP SYN, 583 teardrop, 584 Audit Policy, options (table), 505 authentication 802.1x RADIUS, 807 basic and digest, 12-13 client, 641-642 configuring for Exchange RPC publishing, 425 deauthentication, 787 EAP/TLS, 181 and FTP service publishing, 304 IIS user, 765-769 Integrated Windows, 768 ISA Server options, 11 Kerberos. See Kerberos message, 589-590 methods on OWA Web site, 402 NTLM, 14, 768 OWA sites and, 446 plaintext challenge (fig.), 663 preshared key, 589 proof of possession, 663 public key cryptography and, 538, 662-663 shared key, 804 smart cards and, 62, 628, 630-631 and SMTP application filters, 169 Web sites, recommendations for, 354 Windows 2000, 13-14, 448 authentication header (AH), 593 Authenticode, 711-712 Autodiscovery information, 445 automated key management, 595 829

830

Index

Automatic Private IP Addressing (APIPA), 181

B backing up certificate services, 715-716 back-to-back DMZ configurations advantages over single ISA server, 207 allowing inbound VPN connections through, 173-178 private vs. public address, 76, 191, 212 public vs. private address, 212 topology (fig.), 120 Backup Utility, 545 bandwidth allocation, ISA Server control, 5 best practices, 728 biometric security, 630 block filters, 7 blocking e-mail using ISA Server Message Screener, 367-371 spam, 433 Bluetooth technology, 777 brackets, square ([ ]), 95 bridging SSL connections, 337-347 Broadband Radios Access Networks (BRAN) project, 783 browsers, back-to-back ISA/VPN server problems, 191 buffer overflow attacks, 169 bulk data encryption, without prior shared secrets, 663

C Cache Content Configuration page (fig.), 141 Cache Manager, 576 cache mode, installing in, 19-20 Cache Retrieval Configuration page (fig.), 140 CA hierarchy, 665 CARP (Distributed Cache Array Protocol), 58, 143

Carrier Sense Multiple Access with Collusion Detection (CSMA/CD), 778-779 CAs (certificate authorities) capabilities, 671-672 certificate hierarchies, 672-673 certificate request processing, 692 deploying enterprise, 673-674 described, 590, 656 hierarchical structure (fig.), 702 root, greater security, 667 standalone, 668 Trusted Root, 698 trust in multiple hierarchies, 674-675 validating public keys, 665-666 CD key, product license, 26 CERN, standards, 45-46 certificate authorities. See CAs (certificate authorities) certificate enrollment configuring automatic, 704 and renewal, 706 smart card, 644-645 standards, 693 Certificate Export Wizard, 334, 681 certificate hierarchies, 672-673 Certificate Import wizard (fig.), 699 Certificate Manager snap-in for the MMC, 680 certificate mapping, client, 769-769 Certificate Request Syntax (protocol), 693 Certificate Request wizard, 685, 687 Certificate Revocation List (CRL), 591, 666 certificate servers encrypted files, preventing, 547 enterprise root certificate, creating, 330-333 publishing, 349-351 stand-alone root certificate, creating, 322-330 certificate services

backing up, 715-716 restoring, 717-719 certificates described, 664-665 enrollment, 684 identification information (fig.), 666 mismatch warning, 341 renewing, 694 revocation of, 695 templates for types, 706 Trusted Root CAs, 702 Certificates snap-in, 669, 681 Certificate Store page (fig.), 335 certification authorities. See CAs exams, Microsoft’s 60 ISA Server, 60-61 chaining firewalls, 130-132 checklist, pre-installation, 29 child CAs, 672 chip cards, 629 cipher block chaining, 592 cipher command, 551-552 ciphertext, 537, 592, 657 Cipher Utility, 550 circuit filtering, 7-8 Cisco Systems, 783 client authentication, 641-642 client certificate mapping, IIS, 769 client configuration, 21 clients firewall, 21 selecting ISA Server, 42-46 types of, selecting, 68 Code Red worm, 585 COM (Component Object Model), 636, 736-737 commands. See specific command Component Object Model (COM), 636 compression, encryption and, 576 compromised key attacks, 585-586 computers quantum, 660 remote, encrypting files on, 544 Win 3.x, ISA Server and, 22 confidentiality

Index

of information, 3 of messages, 591 and smart card authentication, 630 configurations analyzing domain, OU, 530 back-to-back private address DMZ summary, 191 external ISA server (tables), 159-162, 179-180 group policy objects, 525 security, 492 SMTP relay server (fig.), 163 configuring client types, 68 dial-up connections, 50 DMZ SMTP relay server, 168-173 external ISA servers, 179-182 File System Security, 519-519 firewall chaining, 130-132 hierarchical Web caching, 137-143 internal ISA server, 174-177 LAT, 35-36 MailSecurity, 437-442 private address back-to-back DMZ, 118-191 public address back-to-back DMZ, 192-226 recovery agent without EFS certificate, 553-557 Registry security, 514-516 Restricted Groups, 512-514 RRAS packet filters, 221-223 secure channel between downstream and upstream ISA Server, 146-150 SecureNAT client, 44 security account policies, 502-504 security during Windows 2000 setup, 453-457 System Services security, 520-521 TCP/IP filtering, 215-219 trihomed DMZ, 70-86 URLScan, IIS, 748-753 VPN clients, 182-190

Web Proxy client, 45 connecting OWA site, 409 Connection Availability page (fig.), 184 connections bridging SSL, 337-347 configuring dial-up, 50 establishing Exchange RPC (fig.), 422 finding secure channels with netstat command, 149-150 RPC, security of, 420 connectivity 24/7, 3 DMZ, 115 Internet, and DNS considerations, 24 contactless smart cards, 638 controlling access, limiting protocol (fig.), 134 access to the internal network, 126-135 local machine security policies, 496 copying encrypted files, 546 product licenses, 26 corporate assets, categorizing (table), 597 costs, DSL connections, 24 cracking passwords, 581 creating LATDMZ segment, 213 packet filters, 82 public DNS records for mail domains, 164-165 security policies, 609-622 credentials, forcing authentication in firewall chaining configurations, 142 credtool.ext utility, using, 291-292 CRL (Certificate Revocation List), 591 CRL Distribution Point information (fig.), 350 cryptanalysts, 536 CryptoAPI, 635, 931

831

differences from Win32 API, SCard COM, 652 services that benefit from (fig.), 671 Cryptographic Service Provider (CSP), 637, 684, 931 cryptography See also encryption defined, 534 history of, 657 IPSec services overview, 587-592 secret key, 13 Windows 2000 or XP/.NET, 635 CSP (Cryptographic Service Provider), 637, 684, 931

D data integrity, 3 protecting in transit, 578 security levels of, 598 databases, Security Configuration and Analysis, 492-494 Database Security window (fig.), 518 data decryption field (DDF), 568 Data Encryption Standard (DES), 537, 539, 591 datagrams, authentication header vs. ESP, 593 data recovery field (DRF), 568 DCOM permissions configuration, 431 dcpromo.exe, 448 deauthentication, wireless, 787 decrypting files, 549 decryption described, 657 process, 569-570 defltsv.inf, security settings, 453-457 demilitarized zone, , DMZ Denial-of-Service attacks (DoS), 3, 77, 582-583, 789 deploying,Windows IPSec, 596-622 deployment, testing configuration before, 501

832

Index

DES algorithm, 537, 591, 592 design issues and ISA Server installation, 15-16 network support for ISA Server, 57-60 Destination Address page (fig.), 183, 185 destination sets security issues with, 319 and Web publishing, 317-318 DHCP technologies, 78 dial-up connections configuring, implementing, 50 VPN connections and, 182-186 dial-up networking, logging on via, 190 digest authentication, 12-13, 767-768 digitally signed content, Authenticode, 711-712 digital signatures, 587, 590, 660-662, 641 Direct Hosting, allowing on LATDMZ access, 226 directories, encrypting, 552 direct sequence spread spectrum (DSSS), 778 disabling dynamic updates, 382 FTP port attack setting, 301 IIS services on the ISA server, 264-265 packet filtering, 48 parent paths, 772 SMTP and NNTP service socket pooling, 263-264 socket pooling, 260-261 Web and FTP service socket pooling, 262-263 Distributed Cache Array Protocol (CARP), 58 DMZ configuring private address back-to-back, 118-191 configuring public address back-to-back, 192-204 described, 70 LAT-based, advantages of, 253

managing machines in, 209 private address, segment, 71 private vs. public address, 253 reasons for creating, 254 trihomed, configuring, 70-86 DMZ SMTP mail relay server, publishing, 90-98 DMZ SMTP servers, publishing, 87-90 DNS best configuration for ISA Server, 67 Exchange PRC publishing infrastructure, 423-424 Internet connectivity and, 24 private entries, and Web publishing, 319-321 public entries, and Web publishing, 318 split infrastructure, 67 DNS configurations, split, looping back and, 229 DNS protocol, allowing on LATDMZ access, 226 DNS servers configuring forward and reverse lookup zones, 377-380 disabling recursion on internal network, 176 internal and external, 423 promoting machine to domain controller, 380-382 troubleshooting, 355 domain computers, viewing, 177 domain controllers installing ISA Server on, 41-42 multihoned, name resolution issues, 382 Windows 2000 server as, 448 domain names, blocking e-mail based on, 370 domains analyzing security configuration of, 530 certificate authorities and, 673 mail, creating public DNS records for, 164-165 specifying remote SMTP, 94 Windows 2000, and making server member of array, 37

Windows NT 4.0, installing ISA Server in, 67 DoS attacks, 3, 77, 582-583, 789 drivers, installing for IIS, 733 DSL connections, costs of, 24 DSSS (Direct Sequence Spread Spectrum), 778 DumpSec, DumpACL, 467 dwell time, 777 Dynamic DNS (DDNS), disabling dynamic updates and, 382 dynamic packet filtering, 7 updates, disabling, 382

E EAP (Extensible Authentication Protocol), 631, 809 EAP-TLS authentication, 811 client certificate authentication, 181 editions of ISA Server, 9-11 editors Group Policy Editor, 525 multi-string (fig.), 221 EFS (Encrypting File System) architecture, 561-564 callback functions, 564 components, 561-563 described, 62, 535, 536 encryption process (fig.), 540 fault-tolerance, 575 file information, 567-569 File System Runtime Library (FSRTL), 562 recovery agents, 537, 689 role in network security plan, 535-536 storage strategy, 574 user operations listed, 541 electromagnetic (EM) field, 775 e-mail blocking, 367-371 content screening, 5 forwarding protocol rules, 424 secure, 710 virus scanning engines, 439

Index

EMV (Europay, MasterCard,Visa), 633 Encapsulating Security Payload (ESP), 202, 593 encoding base 64, 12 Encrypted Data Recovery Policy (EDRP), 552 encrypted files, 542-548 encrypting data, 62 data using public key encryption (fig.), 659 directories, 552 files, folders, 542-545 file system, 712 Encrypting File System. See EFS encryption See also cryptography ADVAPI32.DLL library, 545 attributes, applying, 543, 550 bulk data, without prior shared secrets, 663 compressed, system files, 543 compression and, 576 data, standard, 591 decrypting files, 549 decryption described, 569-570 described, 587 EFS process (fig.), 540 Macintosh clients and, 537 private, public keys, 538, 658 security planning and, 535-536 process described, 564-567 recovery operations, 552 RSA, 726 secret key cryptography, 539 temporary files and, 541 Windows 2000, 448, 574-575 Encryption File System. See EFS Enhanced CryptoPAK, 574 Enigma code, 657 enterprise CAs, deploying, 673-674 Enterprise Edition, ISA Server, 10 enterprise initialization, 20, 37-38 management, 5 Enterprise Root certificate authority, 666-667

Ericsson, 777 error logs, file path, 522 errors dreaded 14120, 123 HTTP 403.7, 347 resource allocation, 154 ERRP, 552 ESP (Encapsulating Security Payload), 202, 593 Ethernet 802.3 standard, 778 Europay MasterCard, and Visa (EMV), 633 European Telecommunication Standards Institute (ETSI), 783 Event Log analysis area, 495 node described, 510 options (table), 511-512 exams. See certification Exchange 2000 packet filters and, 88 SMTP server, 91-92 Exchange 2000 server, MailSecurity versions, 434 Exchange 2000 Services, ISA Server support, 358 Exchange mail services, configuring server publishing rules, 390-394 Exchange RPC publishing, 420-428 Exchange Server Message Screener on ISA server and, 411-416 publishing on ISA server, 371-401 publishing OWA on internal network, 428-429 recommended version for public key encryption, 713 troubleshooting mail delivery, 446 Exchange Services assigning certificates to, 396-398 disabling socket pooling, 386-387 secure communications with server publishing rules, 399-400

833

Exchange System Manager, assigning certificates, 397 exporting certificate and private key, 680-684 security templates, 493-494 Web site certificate, 333-337 Extensible Authentication Protocol (EAP), 631, 807, 809 external interface, SecureNAT clients looping back, 229-230 external ISA server allowing RWSP on, 132-135 configuration (table), 120, 159-162, 179-182 controlling access on (fig.), 128 RWSP requests arriving at internal interface of (fig.), 133

F FAT partitions, 546 fault tolerance MX records and, 165 server clustering and, 11 FEK (File Encryption Key), 539 files, encrypted, 542-548 File system analyzing security, 523 encrypting, 712 access control settings, Users and Power Users (table), 460-466 node, analysis area, 496 permissions,Windows 2000, default settings, 457-472 File System Security, 516-519 File Transfer Protocol. See FTP filtering applications, 8-9 layered, 6-9 MAC, 806 TCP/IP, using, 214-219 filters IP, 235-240 IPSec, 608-609

834

Index

packet, included with default ISA Server configuration, 78 SMTP application, 169 Web, 5 Filter Wizard, 608 find command, using with netstat to find secure channels, 149-150 firewall chaining configuring, 130-132 performance benefits of, 142 Firewall client, 42-44 installing, 289 LATDMZ servers, installation, 233 publishing FTP server using (fig.), 234 firewall mode, installing in, 19 firewalls See also security and EFS, 535 Netstumbler, 790, 795 PORT mode FTP, 102-105 fixes, uninstalling, 52 Fluhrer, Scott, 799 folders, encrypting, 542 Foundstone, Inc., 56 FQDNs, 122-123 resolving, 355 Web publishing and, 317, 318, 319 France, smart card use in, 629 frequency hopping spread spectrum, 777 fresnel zone, 775 FrontPage Server Extensions (FPSE), 747-748, 772 FTP (File Transfer Protocol) allowing secure access using Web publishing rules, 304309 challenges of protocol, 102 description of, 100-102 disabling port attack setting, 301 packet filters for, 200 PORT and PASV mode access, 285-287 PORT mode, 129, 192

publishing site with Web publishing rule, 307-309 secure communications, 396 secure connections using SSL, 347-348 Web publishing rule failure, 355 FTP Access application filter, 110 FTP publishing, tips on configuring, 294-295 FTP servers publishing on DMZ segment, 151 publishing on internal network, 285-287 publishing on trihomed DMZ segment, 99-110 publishing using Firewall client (fig.), 234 publishing when co-located on ISA server, 295-304 FTP Services, Network Monitor Trace at (fig.), 231 FTP service socket pooling, disabling (fig.), 262-263 full NAT, 258-259

G Gemplus, 630 GemSAFE cards, 639, 653 Getting Started wizard, 36, 46-51 GFI MailSecurity for Exchange/SMTP Installation Wizard, 434435 GFI’s DownloadSecurity for ISA Server, 60 GINA (graphical identification and authentication), 642 globally unique identifier (GUID), 638 Global System for Mobile Communications (GSM), 633 Gopher protocol, 23 graphical identification and authentication (GINA), 642 group policies, integrating, 238240, 524-527 group policy

configuring automatic certificate enrollment, 704 security settings (fig.), 527 Group Policy Editor, 525 Group Policy Model, 531 groups differences in permissions, 458-472 restricted. See Restricted Groups security. See security groups Windows 2000 default, 449, 479-481 GSM (Global System for Mobile Communications), 633 GTE CyberTrust, 665 GUID (globally unique identifier), 638

H H.323 Gatekeeper, 5, 28, 192 half NAT, 258-259 hardening TCP/IP, 738 hardware corporate asset, 597 ISA Server installation requirements, 16-18 Hardware Compatibility List (HCL), 373, 643 Harrison, Jim, 30, 235 hashing, cryptographic function, 658 hashing messages, 588 hashing user credentials, 12-13 hash message authentication codes (HMACs), 588 HCL (Windows Hardware Compatibility List), 643 Hermes chipset, 790 hierarchical Web caching, 137-143 hierarchies, certificate, 672-673, 702 HMACs, 588 hop time, 777 HOSTS file, 123, 153-154 hot fixes, uninstalling, 52 Hotmail, 442 HTTP bridging SSL connections as, 338-341

Index

protocol, allowing on LATDMZ access, 226 redirector, Firewall clients and (fig.), 135 HTTP servers creating protocol definition, 312 publishing with server publishing rules, 309-313 HTTPS, avoiding using, 356

I ICC smart cards, 638-639 ICCs (Integrated Circuit Cards), 630 ICMP creating global packet for DMZ hosts, 85-86 protocol, packet filter for, 199 unreachable in’ packet filter, 78 ID, DMZ network, 194 identity verification, 656 IEEE 802.11 standards, 780-782 IEEE wireless standards generally, 774 IIS and Code Red, 585 disabling services on ISA server, 264-265 running on ISA Server, 34 security. See IIS security SMTP service, publishing on ISA server, 360-367 stopping services in Internet Information Services console (fig.), 170 IIS Lockdown wizard, 739 IIS security authenticating users, 765-769 best practices, 728 client certificate mapping, 769 digest authentication, 767-768 FrontPage Server Extensions, 747-748 hardening TCP/IP, 738 hot fixes and, 732 installing IIS, 730-733 introduction to, 728 locking down COM, database access, 733-737

Master WWW properties, 754-760 OS preparation, 729-738 restricting NTFS permissions for anonymous users, 741 securing by content type, 760-765 securing COM components, 736 securing data sources, 734-735 securing default and administration Web sites, 744-746 securing global settings, 743-744 securing Internet Information Service, 738-753 securing Web sites, 753-765 service pack, hot fix installations, 732 URLScan, configuring, 748-753 IKE (Internet Key Exchange) protocol, 202, 595 IMAP4 protocol, allowing on LATDMZ access, 226 secure services publishing and, 394 server publishing rule, 393 impersonation, 580 importing certificate from Trusted Root CA, 698 security templates, 498 Inbound TCP 3389, 266 Incoming Web Requests listener interface (fig.), 310 information, confidentiality of, 3, 578 Information Security Magazine, 629 Initial Domain Controller Configuration, 490 initialization, enterprise, 20, 37-38 initialization vector (IV), 592 installation Administration Tools, 33 CD key, product license, 26 with different network configurations, 29 files, 25

835

hot fix uninstalls, 52 modes, 19-20 network and hardware requirements, 16-18 optional services, 28 pre-installation checklist, 29 setting up open access for testing, 47-51 stand-alone configuration, 20, 30-37 installing Exchange Server 2000 on ISA server/domain controller, 385-386 Firewall client, 289 IIS, 730-733 ISA Server, 15-46 ISA Server software, 383-385 lookback adapter, 194 MailSecurity for SMTP gateways, 434-442 Message Screener on internal network Exchange server, 429-432 multiple internal interfaces on ISA Server computer, 212 Service Pack on ISA Server, 51-57 smart card readers, 643-644 SMTP Message Screener, 411 TSAC Web software, 276 URLScan filter, 742 Windows 2000, 373-377, 675-679 WINS server on ISA server, 373 Institute of Electrical and Electronics Engineers. See IEEE Integrated Circuit Cards (ICCs), 630 Integrated Windows authentication, 768 integration, group policy, 524-527 integrity, message, 587 interactive logon, 642 interference, radio, 775-776 Internal and External IP Addresses Listen for Secure Communications (fig.), 406

836

Index

internal interfaces, installing multiple on ISA Server computer, 212 internal ISA server configuring, 124-130, 174-177 external interface configuration, 175 internal interface configuration, 174-175 internal networks allowing outbound and inbound traffic to and from, 126-135 browsing resources with My Network Places, 189-190 configuring mail services on, 417-432 disabling recursion on DNS, 176 LATDMZ, allowing hosts access to, 232 LATDMZ communications and IPSec policy rules, 240-249 preventing traffic between LATbased DMZ segment and, 253 publishing FTP servers on, 285-287 publishing pcAnywhere on, 313-316 publishing Terminal Services on ISA server and, 274-275 VPN connections, testing, 186-188 Web sites, publishing in private address back-to-back DMZ, 154-162 International Organization for Standardization (ISO), 631 Internet Explorer 5.0x, integrated authentication and, 402 certificate errors on connection to OWA site, 445-446 Internet Information Service, , IIS Internet Key Exchange (IKE), 202, 595 Internet Message Control Protocol (ICMP), overview, 85

internet network DNS, 423 Internet printing, IIS installation, disabling, 746-747 Internet Protocol (TCP/IP) Properties dialog box (fig.), 216 intrusion detection feature, 5 IP addresses brackets ([ ]) and, 95 dedicated mandatory when, 25 firewall chaining and, 132 FQDNs and, 122-123 IP filters, 235-240 IP Filter Wizard, 615 IPSec architecture, 586 building security policies with customized consoles, 599 built-in policies (fig.), 601 compatibility issues, 622 cryptographic services overview, 587-592 deploying, 596-622 filter actions, 604-605 filter lists, 604 filters, 608-609 IP security rules, 603 key management, 595-596 policy rules, 238-240 public keys and, 713 security associations and key management procedures, 594-596 security policies, 527 security services, 592-594 tunnel mode, 587 ipsecmon.exe, traffic-monitoring tool, 188-189, 621, 626 IPSec policies using, 235-249 vs. RRAS filters, 254 Windows 2000 default, 189 IP Security. See IPSec IP Security Monitor, starting, 621 IP Security Policies,Windows 2000, 479 IP Security Policy wizard, 241 IP spoofing, 580 IRC, 43

ISA client types (table), 42 ISA Server array policy option, 37-41 book introduction, 2 certification, 60-61 client, selecting, 42-46 configuring two in private address back-to-back DMZ, 118-192 DMZ interface configuration, 73-74 editions, 9-11 Enterprise Edition, 10 external configuration, 120-123, 159-162 getting started with, 46-51 IIS services, disabling, 264-265 installing, 15-46 installing software, 383-385 integrated backup file, 76 internal configuration, 124-130 market for, 61 Message Screener, 367-371 overview, 3-15 private address DMZ connected to external (fig.), 203 production licensing structure (table), 26 public key cryptographic implementation, 658 publishing OWA on, 401-411 publishing Terminal Services on, 271-274 server files disk location, 27 service pack download, installation, 54-57 smart card strategy, 652 smart card support, 634 third-party software add-ons, 59-60 trihomed DMZ configuration, 75 upgrading stand-alone to array member, 37-41 VPN wizards, 173 ISA Server Message Screener, 367-371 ISA Servers, configuring secure channel between, 146-150

Index

ISO (International Organization for Standardization), 631 ISO 7794, smart card standard, 633

J Jet, 733-734

K Kerberos allowing on LATDMZ access, 226 authentication, 13-14, 589 and Integrated Windows authentication, 768 L2TP/IPSec tunnels and, 626 Policy, 502, 504 Key Distribution Center (KDC), 13 key rings, DDF, 568 keys compromised, 586 hash values and, 588 kSECdd device driver, 562

L L2TP/IPSec, 181 allowing inbound connections, public address DMZ, 202-203 compatibility notes, 622 Lamarr, Hedy, 776 languages, selecting for service pack download, 54 laptops, trihomed DMZ configuration, 75 LAT (Local Address Table), 28, 35-36, 124 LAT segments configuring RRAS packet filters, 221-223 ISA server packet routing and, 193 packet routing, 212 LAT-based DMZ, (LATDMZ) advantages of, 253 controlling traffic from, 212 Interface Properties dialog box (fig.), 223 segment (fig.), 213, 224-235

supporting communications, with IPSec policies, 240-249 Layer 2 Tunneling Protocol, L2TP LDAP protocol, allowing on LATDMZ access, 226 LDT (Local Domain Table), 320 licenses ISA server, 26 production, 27 Local Domain Table (LDT), 320 local groups,Windows 2000 server, 449 local policies described, 504 options (table), 505-510 Local Policies node analysis area, 495 Windows 2000, 479 Location Address Table. See LAT (Local Address Table) log files, daily expansion of, 18 logging on Exchange 2000 OWA sites, 408 via dial-up networking, 190 logons RUNAS service, 451 smart card, 648-649, 709 TSAC form, 275 logs error, 522 event. See Event Log Web Proxy, 153 loopback adapter, 194 looping back, through external ISA server to access internal network, 228 loops, proxy chain, 155-157

837

services, configuring on internal network, 417-432 services publishing, introduction to, 358 Mail Service Selection page (fig.), 419 MailSecurity, installing, configuring for SMTP gateways, 434-442 managing machines in the DMZ, 209 man-in-the-middle attacks, 584 Mantin, Itsik, 799 mapping, design for ISA deployment, 15-16 mdutil.exe utility, 263, 361, 386-387 Media Access Control (MAC) layer, wireless architecture, 778 Mendax, 580 message digest, 590, 661 message integrity, IPSec and, 587 messages authentication, 589-590 confidentiality, 591 hashing, 588 Message Screener, 28-29 installing on internal network Exchange server, 429-432 on ISA server, 367-371, 411-416, 445 using to block spam, 433-434 Microsoft, ISA Server. See ISA Server Microsoft 2000 PKI revocation of certificates, 695 roaming, 695 Microsoft Certificate Server, 181, 321, 394 M MAC, filtering and authorization, Microsoft Certificate Services, Welcome screen (fig.), 645 805-807 Microsoft Certified Systems machines, analyzing local, 521 Engineer (MCSE), 60 Macintosh, clients and encryption, Microsoft Lookback Adapter, 194 537 Microsoft Management Console mail (MMC), 599 domains, creating public DNS Microsoft Proxy Server 2.0, 3 records for, 164-165 packet filtering SMTP, 93

838

Index

Microsoft’s Internet Security and Acceleration (ISA) Server. See ISA Server Migrating from Microsoft Proxy Server, 29 Mitnick, Kevin, 581 MMC (Microsoft Management Console), 209, 559 models, Component Object Model (COM), 636 modes, ISA Server installation, 19-20 msisaent.exe, 37 multipath interference, 776 MX records, creating for mail domains, 164-165 My Network Places, browsing internal network resources with, 189-190

N name resolution DMZ segment requirements, 207 on external ISA server, 123 hierarchical Web caching issues, 144-145 issues, DDNS and, 382 Local Domain Table and, 320 NetBIOS, 191 National Security Agency (NSA), 657 NAT (network address translation), 4 full and half, 258-259 and L2TP/IPSec tunnels, 626 NetBIOS disabling to prevent browser problems, 377 protocol, allowing on LATDMZ access, 226 NetLogon, allowing on LATDMZ access, 226 NetMeeting, 5 netstat command, 149-150, 261 Netstumbler firewall, 790, 795 network, design support for ISA Server, 57-60 Network Address Translation (NAT), 4, 626

Network Connection Type page (fig.), 182 Network Connection wizard, 183-184 network encroachment technologies, 579-586 Network Monitor passive attacks on wireless networks, 790 secure channel connection, capturing (fig.), 150 snooping program, 579 Network Monitor Trace at FTP Server (fig.), 231 networks choosing the best clients for, 23-24 data protection across, 578 firewalls. See firewalls untrusted and trusted, 787 virus protection, 67 wireless. See wireless networks New IP Packet Filter welcome page (fig.), 79 New Remote Domain wizard, 172 New Routing Rule wizard, 138 New Server Publishing Rule wizard, 166 nimbda scans, 772 NNTP disabling service socket pooling, 263-264 protocol, allowing on LATDMZ access, 226 secure services publishing and, 394 server publishing rule, 392 NSA (National Security Agency), 657 NT. See Windows NT NTFS EFS and, 535 floppy disks and, 546 NTLM, authentication, 14, 768

O Office Service Pack 2, 428 open access, 47 ORiNOCO gold card, 790

OSI model, wireless networks, 778 outbound HTTP packet filter, 197 outbound SMTP packet filters, 196 Outlook encrypting data over RPC link, 420 Exchange RPC publishing process, 421-422 MAPI clients, server publishing rules and, 420 Outlook 2000, client configuration, 428 Outlook 2000/XP, SMTP Message Screener and, 416 Outlook Web Access (OWA) changing passwords in, 445 port 80 on ISA Server machine, 445 publishing on ISA server, 401-411 servers, security problems, 115 using open access Exchange servers, 208 OWA, 115, 208, 401-411, 445

P packet filtering, 6-7, 48 packet filters all ICMP protocols in both directions, 199 ‘All Open,’ 109, 198 all TCP, UPD protocols outbound (table), 198 Exchange services publishing (table), 400 included with default configuration, 78 needed for SMTP message exchange, 92 nonstateful, 104 outbound HTTP, 197 and ping testing, 79 publishing FTP servers colocated on ISA server, 295-304 publishing Terminal Services on ISA server using, 271-274

Index

RRAS, using, 219-235 rules for, 201 SMTP, 196 using to publish the PORT mode FTP server, 105-107 Password Policy, 502 passwords, 13, 445, 581-582 PASV FTP, 101 PASV mode connections, 129 FT server, publishing using packet filters, 107-108 paths alternate, 257 disabling parent, 772 pcAnywhere, publishing on internal network, 313-316 PC/SC Workgroup, 633 Pentium processors, 17 Perfect Forward Secrecy, 626 performance firewall chaining and, 142 hierarchical Web caching issues, 144-145 permissions DCOM, configuring, 431 group differences, 458-472 for installation, 26 NTFS, restricting for IIS users, 741 passwords. See passwords viewing for file system, 466 Windows 2000 default file system and Registry, 457-472 Windows NT weakness, 448 Personal Computer/Smart Card Workgroup, 633 personal identification number (PIN), 629, 648 Ping-of-Death, 584 ping testing external interface from DMZ host, 116 internal network clients from DMZ host, 116 packet filters and, 79 SecureNAT clients and, 44 trihomed DMZ, 77-86

PIN (personal identification number), 629, 648 PKCS-12 (Public Key Cryptography Standards), 680 PKINIT protocol, 652 plaintext, 537, 657 plaintext attacks, 799 planning ISA Server installation, 15-16 plug and play, supported by smart card readers in Windows 2000, 644 Point-to-Point Protocol (PPP), 809 .pol files, 531 policies configuring to control outbound access in internal ISA server, 127 IPSec, 235-249 password, 581 recovery, 552 tiered, 10 policy, group. See group policies POP3 protocol, allowing on LATDMZ access, 226 secure services publishing and, 394 server publishing rule, 391 port 80, 445 port contention, 259-260 PORT mode FTP firewall, 102-105 publishing using packet filters, 105-107 ports publishing FTP servers on alternate, 287 publishing Terminal Services on alternate, 268 Power Users group assigning granular permissions (fig.), 468 file system default access control settings (table), 460-466 Windows 2000, 460 PPP (Point-to-Point Protocol), 809

839

PPTP (Point-to-Point Tunneling Protocol), 200-202 PPTP VPN servers, 181 pre-installation checklist, 29 preshared key authentication, 589 private address back-to-back DMZ configuring, 118-191 publishing internal network Web sites, 154-162 private address DMZ connected to external ISA Server (fig.), 203 difference from public address, 207 publishing servers on external ISA Server, 203 vs. public address, 253 private key described, 585 encryption, 538 technology, smart cards and, 628 processor, requirements, ISA Server installation, 17 promoting stand-alone server to array member, 37-41 proof of possession, 663 protocols FTP, 100-102 ICMP, 85 limiting access, external ISA server, 134 opening all, 49 pcAnywhere, 313-316 publishing complex, 258 ‘unknown,’ 135 Web Proxy service, 22 proxy chain loops, 155-157 Proxy Server, certification exam, 60 Proxy Server 2.0, 3 public access DMZ inbound VPN access through, 201-202 outbound access for internal network clients through, 195-201

840

Index

public/private key technology, public address back-to-back smart cards and, 628 DMZ, configuring, 192-204 publishing public address DMZ certificate servers, 349-351 advantages of using, 193 CRLs to Active Directory, 695-696 difference from private address, 207 DMZ SMTP mail relay server, 90-98 number required for organizations, 212 DMZ SMTP servers, 87-90 with VPN tunnel to internal Exchange Server on ISA server, ISA server (fig.), 193 371-401 vs. private address, 253 Exchange Server services on internal network, 417-420 public key cryptography FTP servers co-located on ISA See also public key encryption server, 295-304 authentication and, 662-663 FTP site with Web publishing described, 657 rule, 307-309 protecting, trusting keys, 664 IIS SMTP service on ISA public key encryption, 538 server, 360-367 See also public key cryptography internet network Web sites in encrypting data using (fig.), 659 private address back-tohistory of, 658 back DMZ, 154-162 trust and validation, 668-669 OWA on internal network public key infrastructure Exchange server, 428-429 certificate names in, 674 OWA on ISA server, 401-411 components needed to build, pcAnywhere on internal 725 network, 313-316 concepts, 657-669 rules. See publishing rules digital signatures, 660-662 secure server, 5 enabling domain clients, secure services, 394-400 679-701 server, 265-316 generating keys, 679 servers. See publishing servers key recovery, 680 SMTP relay on private address Microsoft, keys and certificate DMZ segment, 162-173 management, 694-695 Terminal Services on both ISA Microsoft. See Microsoft 2000 server and internal PKI network, 274-275 public key functionality, Terminal Services on internal 659-660 network, 266-271 smart card integration into, 631 Terminal Services on the ISA Windows 2000. See Windows server, 271-274 2000 PKI TSAC sites, 275-285 public key interactive logon, 642 TSAC Web server, 276-280 public key policies, 527 Web server on private address Public Key Policies,Windows DMZ segment, 151-154 2000, 479 publishing rules public key security policy, Exchange RPC, 428 Windows 2000, 701-704 HTTP, 232 Public Network page (fig.), 185 SMTP, 164-167 Web, capabilities, 256

publishing servers on private address DMZ on external ISA Server, 203 wspcfg.ini file and, 235

Q quantum computers, 660 qubits, 660

R radio frequency communications (RF), 775 radio signals, interference and, 775-776 RAID, ISA Server files location, 27-28 RADIUS, 802.1X authentication, 807 Rainbow Technologies, smart cards, 631 RAM, ISA Server installation configuration, 18 RBLs (Real Time Black Hole Lists), 433 RC4 stream cipher, 799 RDP Publishing Rule, 268 RDS (Remote Data Services), 735 RealAudio, 43 Real Time Black Hole Lists (RBLs), 433 reconfiguring HTTP Redirector (fig.), 135 recovery agents adding with EFS certificate, 537, 558-561 configuring without EFS certificate, 553-557 requesting certificates from, 689 Recovery Agent wizard, 568 recovery operations configuring recovery agent with EFS recovery certificate, 558-561 configuring recovery agent without EFS certificate, 553-557 generally, 552 redirecting SSL requests as FTP requests (fig.), 348

Index

to alternate paths, 257 Web publishing rules, 153-154 Registry access control settings for Users and Power Users (table), 468-472 changing, backing up, 547 COM keys (table), 737 configuring security, 514, 514-516 Jet settings, 735 SMTP Message Screener, checking entries (fig.), 368 Windows 2000 default permissions, 457-472 Registry, analysis area, 496 Remote Authentication and DialIn User Service. See RADIUS Remote Data Services (RDS), 735 Remote Desktop Web Connection page (fig.), 283 Remote WinSock Protocol (RWSP), allowing on external ISA server, 132-135 renaming ISA Server interfaces, 222 renewing certificates, 694 reporting, secedit.exe capabilities, 491-492 reports, ISA Server generation features, 5 requests Firewall client, 133 RWSP arriving at external ISA server (fig.), 133 slow name resolution, 144-145 www or unqualified names, 146 requirements processor (table), 17 system, 16 Resource Allocation Errors, disabling alert for, 154 resource manager, smart cards and, 640 restoring certificate services, 717-719 Restricted Groups

analyzing policy, 523 list, 452 node 495, 512-513 RF (radio frequency communications), 775 roaming profiles, Microsoft PKI, 695 rollout, using security templates, 490 root certificate server creating enterprise, 330-333 creating stand-alone, 322-330 root certification authorities, 672 Root Hints file, 175 routers firewall chaining and (fig.), 132 trihomed DMZ, 74 Routing and Remote Access Console (fig.), 223 Routing and Remote Access Service. See RRAS routing page backup (fig.), 140 primary (fig.), 139 RPC endpoint mapper, allowing on LATDMZ access, 226 RPC services, Exchange, 420-428 RRAS (Routing and Remote Access Service), 74 allowing inbound VPN connections through backto-back DMZ, 173 configuring with VPN Server wizard, 178 ‘internal’ and reserved words, 376 packet filters, 219-235, 253 RSA algorithm, 726 rules packet filter, 201 server publishing. See server publishing rules Web publishing. See Web publishing rules Web routing, 137 RUNAS logon service, 451

S SBS (Small Business Server 2000), 359

841

SCard COM differences from CrytoAPI, Win32, 652 smart cards and, 636 SCCP (smart card cryptographic provider), 637 Scene of the Cybercrime: Computer Forensics Handbook (Shinder), 534, 579 schemas, Active Directory, 66 Schlumberger Cryptoflex card, 652 SCSPs (smart card service providers), 638 secedit.exe, 491-492 command-line interface, 498-501 scripts, using with, 530 secret key cryptography, protecting, trusting keys, 664 secure e-mail, 710 Secure-HTTP, 15 Secure Mail Publishing Wizard, 401 Secure Mail Server Publishing Wizard, 418 Secure MIME (S/MIME), 637 SecureNAT, 5 client, and ISA Server, 23, 44-45 client configuration, 68 client protocols, 49 clients, looping back and, 229-230 clients and FTP access, 8 firewall client, 21 Secure Network Address Translation. See SecureNAT secure services publishing, 394-400 Secure Socket Layer/Transport Layer Security (SSL/TLS), 709 Secure Sockets Layer. See SSL Secure Your Server Wizard, 728 security analyzing, 521-524 beyond ISA Server, 61-62

842

Index

configuring during Windows 2000 setup, 453-457 destination sets issue, 319 determining required levels, 598 DoS attacks. See DoS attacks file system, Registry permissions, 457-472 File System, 516-519 IIS. See IIS security importance of, 3-4 IPSec. See IPSec main dangers, 597 method negotiation, 606 System special identity, 458 templates, 168 Web server, 62 Windows 2000 computers, 448 wireless network, 62 security analysis, results in Security Configuration and Analysis (fig.), 493 security associations (SAs), 594 Security Configuration and Analysis analysis area, 494-496 database, console, 492-494 security analysis features, 521 security settings extension to Group Policy Editor, 525-527 snap-in, described, 489 user interfaces, 496-498 Security Configuration Tool Set, components of, 488-491 security groups overview of, 448-452 Windows 2000, membership, 479-481 Security Options Local Policies options (table), 507-510 node, improvements in, 505 security planning, evaluating information, 596 security plans EFS role in, 535-536 multilayered, 535 security policies creating, 609-622

flexibility of, 601 reversing changes to, 531 Security Rule Wizard, 614, 616 security scenarios, configuring as text-based template files, 489 security settings default when upgraded vs. clean install, 484 defltsv.inf (excerpt), 453-457 security templates, 490-491, 494 server clustering, and fault tolerance, 11 Server Gated Cryptography (SGC), 709 server logs, nimbda scans, 772 server publishing, 265-316 described, 256 secure, 5 server publishing rules configuring to publish Exchange mail services, 390 creating HTTP server, 312 Exchange RPC publishing, 420, 427-428 Exchange services, secure communications for, 399-400 IMAP4, 393 introduction to, 257-260 NNTP, 392 pcAnywhere, 314-316 POP3, 391 publishing FTP servers, 299 publishing HTTP and HTTPS servers with, 309-313 publishing Web servers with, 309 SMTP, 390 SMTP configuration, 364-367 Server Publishing Wizard, 302 Service Pack 1 (SP1), 51-57, 201 service set identifiers. See SSIDs setup, stand-along configuration, 30-37 SGC (Server Gated Cryptography), 709 Shamir, Adi, 799

shared key authentication, 804 Shinder, Debra Littlejohn, 534, 579 Shinder,Tom, 30, 34 SLL, secure FTP connections using, 347-348 Small Business Server 2000 (SBS), 41, 359 smart card cryptographic provider (SCCP), 637 smart card service providers (SCSPs), 638 smart card tokens, 631 smart cards authentication and, 62, 628, 630-631 certificate enrollment, 644-645 components of, 637-641 contactless, 638 contact pad sections based on ISO 7794-2 (fig.), 639 described, 629-630 ICC, 638-639 interaction between application and reader (fig.), 640 interoperability, 631-637 ISO 7794 standard, 633 logon, 648-649, 709 Microsoft’s strategy, 652 Microsoft support, 634 PIN logon, 653 public key interactive logon, 642 reader installation, 643-644 recent advances in, 628-629 setting service for automatic startup, 644 ‘smart’ described, 638 stored-value, 638 USB connections, 643 vendors and PIN numbers, 648 Windows 2000 PKI component implementation, 712 S/MIME, 637, 710 SMTP application filter, 169 Commands tab (fig.), 369 configuring server publishing rule, 364-367

Index

configuring service on ISA server, 360-364 disabling socket pooling, 263-264 MailSecurity, installing for gateways, 434-442 Message Screener. See Message Screener packet filters, 196 protocol, vs. PORT mode FTP, 285 reinstalling service packs and hot fixes, 772 secure server publishing, 400 secure services publishing and, 394 server publishing rule, 390 SMTPCRED tool, 430 SMTP Message Screener, on ISA server and Exchange server, 411-416 SMTP protocol, allowing on LATDMZ access, 226 SMTP relays, publishing on private address DMZ segment, 162-173 SMTP relay server, configuring DMZ, 163, 168-173 SMTP Server Properties dialog box (fig.), 172 SMTP servers, publishing DMZ, 87-90 SMURF attacks, 583 snap-ins Certificate Manager, 680 Certificates, 669 Group Policy, 600 Security Configuration and Analysis, 489 sniffer, 536 sniffing, password compromise, 581 snooping, 579 socket pooling disabling, 260-261 disabling for Exchange Services, 386 Exchange RPC services and, 372 IIS feature, 272

SMTP service, checking, 360 SOCKS filters, 8 ISA client configuration and, 21 software corporate asset, 597 minimum ISA Server installation requirements, 17-18 Somarsoft, 467 SP1. See Service Pack 1 spam Anti-spam feature of MailSecurity, 441 keyword blocking, 433-434 keyword lists, 442 split DNS configurations, looping back and, 229 DNS infrastructure, 67 spoofing, 580 spread spectrum technology, 776-778 square brackets ([ ]), 95 SSIDs, security and, 795 SSL bridging, 15, 337-347 client certification authentication, 14 configuring listening port on default Web site, 401-402 termination connection at ISA server, 321 troubleshooting connections, 356 SSL listener, configuring, 306 standard model, 634 standards 802.11 wireless, 776, 780-782, 808 CERN, 45-46 certificate enrollment, 693 for new technologies, 631 STARTTLS command, 416 stored-value smart cards, 638 straight brackets ([ ]), 95 stream cipher vulnerability, 800 streaming media, enhanced software for use of, 5

843

stream symmetric algorithms, 658 subnets, and host IDs, 194 symmetric cryptography, 539 symmetric encryption, 592 system files, encryption and, 544 system requirements, ISA Server, 16-17 System Services analyzing security, 524 configuring security, 520-521 node, 495, 519

T TCP ‘All Open’ packet filter (fig.), 109-110 packet filter for, 198 TCP/IP filtering, configuring, 215-219 hardening, 738 sequence number attack, 580 TCP/IP Security, using TCP/IP filtering, 214-219 TCP port 3389, 266, 268, 271 TCP SYN attacks, 583 teardrop attacks, 584 Telnet, 43 failed attempt (fig.), 88 to publishing SMTP server (fig.), 391 templates available for users, machines (tables), 708 certificate types, 706 exporting security, 494 saving security setting in, 489 security, 168, 490-491 Terminal Services managing machines in the DMZ, 209 publishing on both ISA server and internal network, 274-275 publishing on internal network, 266-271 publishing on the ISA server, 271-274 using in private address DMZ, 203

844

Index

Terminal Services Advanced Client (TSAC), 275-285 testing configuration before deployment, 501 FTP servers, 292-294 OWA site, 409 ping. See ping testing TGT (Ticket Granting Ticket), 642 Thawte, 321 Ticket Granting Ticket (TGT), 642, 13 tiered policy, 10 topology, back-to-back DMZ (fig.), 120 trihomed DMZ configuring, 70-86 creating remote domains on SMTP mail relay server, 93 creating server publishing rules, 110 disadvantages of, 115 network layout, 72 ping testing the connections, 77-86 publishing FTP server on, 99-110 troubleshooting connectivity, 115 troubleshooting Exchange server mail delivery, 446 FTP Web publishing rule, 355 IPSec authentication, 626 Message Screen on ISA server, 445 pcAnywhere server connections, 315-316 port contention, 259-260 publishing OWA on ISA server, 410-411 SSL connections, 356 URLScan, 772 Web publishing rules and FTP sites, 355 Truman, President, 657 trust chain, 669 Trusted Root certificate, 668

trusted root certificate authorities, 672-673, 698 trusted third party, 656 TSAC, publishing sites, 275-285

U universal serial bus (USB), smart cards and, 643 ‘unknown’ protocol, 135 Untrusted Root Authority, security warning (fig.), 340 updates, Microsoft, 732-733 upgrading, stand-alone ISA Server to array member, 37-41 UPN (user principal name), 769 URLScan configuring, 748-753 troubleshooting, 772 URLScan filter, installing, 742 USB (universal serial bus), smart cards and, 643 User group,Windows NT, permissions, 484-485 user principal name (UPN) mapping, 769 user rights configuring on domain controller, 408 Windows 2000, default, 472-479 Windows 2000 default, 472-479 User Rights Assignment, Local Policies, options (table), 506-507 users sharing encrypted files, 540 Windows 2000 write access, 459 Users group,Windows 2000, 451-452, 484

V VeriSign, 665, 321 versions, SP1, determining, 53 virtual private network (VPN) connecting Outlook MAPI clients to Exchange server, 420-421 ISA Server integration, 4 viruses network protection from, 67

scanning engines, 439 Word macro, 440 VPN connections, private address back-to-back DMZ architecture for (fig.), 177 cost benefits, 173 passthrough, 174 selecting connection to internal, 190 testing to internal network, 186-188 viewing domain computers, 177 VPN servers configuring, 178-182 configuring clients, 182-190 PPTP, 181 VPN Server wizard, 178 VPNEXTERNAL Port Status dialog box (fig.), 186-188

W Walker, Jesse, 799 wardriving software, 790 warning, Untrusted Root Authority (fig.), 340 Web, socket pooling, 262-263 Web caching advantages of, 141-142 hierarchical, performance issues, 144-145 Web caching, hierarchical, 137-143 WebDAV, IIS Lockdown, disabling, 742 Web Proxy caching, configuring hierarchical, 137 chaining, 137-146 client, and ISA Server, 45 clients authentication, 11 logs, getting meaningful data, 153 Proxy service, 22-23, 316 Web Proxy Service Certificate List (fig.), 344 Web publishing bridging SSL connections, 337-347

Index

creating stand-alone root certificate server, 322-330 destination sets, 317-318 introduction to, 316 private DNS entries, 319-321 public DNS entries, 318 publishing certificate servers, 349-350 rules, capabilities available, 256, 256-260 server publishing rules and, 129 terminating SSL connection at ISA server, 321 Web Publishing Redirection (fig.), 122 Web publishing rules allowing FTP access to publishing server, 232-233 publishing FTP servers, 299 publishing FTP site with, 307-309 publishing FTP using, 355 redirecting, 153-154 using FQDN to prevent 14120 error, 123-124 using to allow secure FTP access, 304-309 Web routing rules, 137 configuring default, 158 proxy chain loop in (fig.), 157 Web security,Windows 2000, 709 Web servers, publishing with server publishing rules, 309 Web sites book’s authors, 115 bounce attacks, 301 CARP and routing concepts, 143 CAs, installing Windows 2000 offline, 667 CryptoAPI, 635 digital signatures, state laws on, 641 Foundstone, Inc., 56 GemSAFE, 639 Gopher protocol issue, 23 internal network. See internal network Web sites ISA Server installation, 29, 30

845

configuring security during ISA servers, configuring as setup, 453-457 domain controllers, 176 default user rights, 472-479 Kerberos authentication, 13 encryption features, 534 log analyzers, 257 file encryption steps, 574-575 MailSecurity for SMTP gateways, 434 group membership, default, 479-481 mdutil.exe utility, 263 IIS, securing, 738-753 Microsoft Certificate Services, 689 IIS. See IIS security Microsoft’s MSDN site, 634 installing, 373-377 PC/SC specifications, 633 installing public key infrastructure, 675-679 publishing FTP servers using wspcfg.ini, 235 IPSec policy, 189 Rainbow Technologies smart migrating from Windows NT, cards, 631 security policies, 531 recommended authentication monitoring L2TP/IPSec type, 354 connections, 188 Remote Desktop Client PKI, using keys and certificates, software download, 268 694-695 securing under IIS, 753-765 PKI components (fig.), 669 security attack information, 585 plug and play supported smart card readers, 644 Service Pack 1, 51 Power Users group, 452 Service Pack releases, 53 public key cryptographic socket pooling, 34 implementation, 658 VPN server configuration, 174 public key infrastructure. See Windows 2000 IPSec policy, Windows 2000 PKI 189 public key policies, automatic Window XP’s autoenrollment certificate settings, 684 feature, 685 renaming interfaces, 376 WepCrack, 799 security features of, 448 WEP (Wired Equivalent Privacy security subsystem, 458 Protocol), 798-805 smart card authentication and WFP (Windows File Protection), (fig.), 642 772 smart cards support, 652 Wi-Fi Alliance, 783 user rights, default, 472-479 Win32, differences from CrytoAPI, SCard COM, Users group, 451-452 652 Windows 2000 PKI Win32 APIs, smart cards and, 636 components, 669-760 Win 3.x computers, 22 digitally signed content, Windows 2000 711-712 Active Directory. See Active preparing to implement, Directory 713-714 Administrators group, 449-450 public key security policy, 701-704 applications and encryption, 709 smart-card logon, 712 authentication, 13-14 software components of, 725 built-in security features, 61 standards written into operating Cipher Utility, 550 system (table), 714

846

Index

Windows 2000 Server, configuring as member or stand-alone, 448 Windows 2003 Terminal services, 268 Windows 9.x, smart card support, 652 Windows File Protection (WFP), 772 Windows Hardware Compatibility List (HCL), 643 Windows Media, 43 Windows .NET ISA Serve and, 58-59 ISA Server installation, 27 Windows NT choosing client types, 68 installing ISA Server on domain, 67 ISA servers on domains in, 208-209 permissions, weakness with, 448 permissions issue, 484 policies, migrating to Windows 2000, 531 security features of, 448 smart card support, 652 Windows XP, discovery of wireless network SSIDs (fig.), 796 Windows XP/.NET EFS encrypted file sharing, 540 PKI autoenrollment process, 684 sharing encrypted files in, 548 Window XP/.NET, encrypted files access, 544 WINS and DMZ segments, 122 and NetBIOS, mail services, 373 WinSock Proxy client, 43, 289

WINS servers, supporting network browsing for VPN clients, 176 Wired Equivalent Privacy Protocol (WEP), 798-805 Wireless Ethernet Compatibility Alliance (WECA), 783 wireless local area networks (WLANs), 779-782 wireless networks 802.11 topology, 776, 780-782, 784-787, 808 active attacks on, 792-793 architecture, 778-779 communication principles, 774-778 configuring 802.1X using EAPTLS, 811-827 dwell and hop time, 777 interference in, 775-776 passive attacks on, 790-792 radio frequency communications, 775 security. See wireless security spread spectrum technology, 776-778 WLANs, standards for, 779-782 wireless security active attacks on, 792-793 configuring 802.1X using EAPTLS, 811-827 exploits of networks, 790-794 jamming attacks, 793-794 layered defense approach, 794826 man-in-the-middle attacks, 793 Microsoft RADIUS servers, 808 passive attacks on, 790-792 performing analysis, 788-789 principles of, 787-788 stream cipher vulnerability, 800

threats, risks, 788-789 wizards Certificate Export, 681, 334 Certificate Import (fig.), 699 Certificate Request, 685 Certificate Request (fig.), 687 Filter, 608 Firewall Client Installation, 56 Getting Started, 31, 46-51 GFI MailSecurity for Exchange/SMTP Installation, 434-435 IIS Lockdown, 739 IP Filter, 613-614 IP Security Policy, 241 ISA Server VPN, 173 Network Connection, 183-184 New Remote Domain, 172 New Routing Rule, 138 New Server Publishing Rule, 166 New SMTP Domain, 94 Recovery Agent, 568 Secure Mail Publishing, 401 Secure Mail Server Publishing, 418 Secure Your Server, 728 Security Rule, 614, 616 Server Publishing, 302 VPN Server, 178 WLAN Interoperability Forum (WLIF), 783 WLANs, 779-782 Word macro viruses, 440 Workstation Configuration templates, 490 wspcfg.ini, 232, 234, 290 WWW service, IIS, and running ISA Server with, 34

SYNGRESS PUBLISHING LICENSE AGREEMENT THIS PRODUCT (THE “PRODUCT”) CONTAINS PROPRIETARY SOFTWARE, DATA AND INFORMATION (INCLUDING DOCUMENTATION) OWNED BY SYNGRESS PUBLISHING, INC. (“SYNGRESS”) AND ITS LICENSORS. YOUR RIGHT TO USE THE PRODUCT IS GOVERNED BY THE TERMS AND CONDITIONS OF THIS AGREEMENT. LICENSE: Throughout this License Agreement,“you” shall mean either the individual or the entity whose agent opens this package.You are granted a limited, non-exclusive and non-transferable license to use the Product subject to the following terms: (i) If you have licensed a single user version of the Product, the Product may only be used on a single computer (i.e., a single CPU). If you licensed and paid the fee applicable to a local area network or wide area network version of the Product, you are subject to the terms of the following subparagraph (ii). (ii) If you have licensed a local area network version, you may use the Product on unlimited workstations located in one single building selected by you that is served by such local area network. If you have licensed a wide area network version, you may use the Product on unlimited workstations located in multiple buildings on the same site selected by you that is served by such wide area network; provided, however, that any building will not be considered located in the same site if it is more than five (5) miles away from any building included in such site. In addition, you may only use a local area or wide area network version of the Product on one single server. If you wish to use the Product on more than one server, you must obtain written authorization from Syngress and pay additional fees. (iii) You may make one copy of the Product for back-up purposes only and you must maintain an accurate record as to the location of the back-up at all times. PROPRIETARY RIGHTS; RESTRICTIONS ON USE AND TRANSFER: All rights (including patent and copyright) in and to the Product are owned by Syngress and its licensors.You are the owner of the enclosed disc on which the Product is recorded.You may not use, copy, decompile, disassemble, reverse engineer, modify, reproduce, create derivative works, transmit, distribute, sublicense, store in a database or retrieval system of any kind, rent or transfer the Product, or any portion thereof, in any form or by any means (including electronically or otherwise) except as expressly provided for in this License Agreement.You must reproduce the copyright notices, trademark notices, legends and logos of Syngress and its licensors that appear on the Product on the back-up copy of the Product which you are permitted to make hereunder. All rights in the Product not expressly granted herein are reserved by Syngress and its licensors. TERM: This License Agreement is effective until terminated. It will terminate if you fail to comply with any term or condition of this License Agreement. Upon termination, you are obligated to return to Syngress the Product together with all copies thereof and to purge and destroy all copies of the Product included in any and all systems, servers and facilities. DISCLAIMER OF WARRANTY: THE PRODUCT AND THE BACK-UP COPY OF THE PRODUCT ARE LICENSED “AS IS”. SYNGRESS, ITS LICENSORS AND THE AUTHORS MAKE NO WARRANTIES, EXPRESS OR IMPLIED, AS TO RESULTS TO BE OBTAINED BY ANY PERSON OR ENTITY FROM USE OF THE PRODUCT AND/OR ANY INFORMATION OR DATA INCLUDED THEREIN. SYNGRESS, ITS LICENSORS AND THE AUTHORS MAKE NO EXPRESS OR IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR USE WITH RESPECT TO THE PRODUCT AND/OR ANY INFORMATION OR DATA INCLUDED THEREIN. IN ADDITION, SYNGRESS, ITS LICENSORS AND THE AUTHORS MAKE NO WARRANTY REGARDING THE ACCURACY, ADEQUACY OR COMPLETENESS OF THE PRODUCT AND/OR ANY INFORMATION OR DATA INCLUDED THEREIN. NEITHER SYNGRESS, ANY OF ITS LICENSORS, NOR THE AUTHORS WARRANT THAT THE FUNCTIONS CONTAINED IN THE PRODUCT WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE PRODUCT WILL BE UNINTERRUPTED OR ERROR FREE.YOU ASSUME THE ENTIRE RISK WITH RESPECT TO THE QUALITY AND PERFORMANCE OF THE PRODUCT. LIMITED WARRANTY FOR DISC: To the original licensee only, Syngress warrants that the enclosed disc on which the Product is recorded is free from defects in materials and workmanship under normal use and service for a period of ninety (90) days from the date of purchase. In the event of a defect in the disc covered by the foregoing warranty, Syngress will replace the disc. LIMITATION OF LIABILITY: NEITHER SYNGRESS, ITS LICENSORS NOR THE AUTHORS SHALL BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, PUNITIVE, CONSEQUENTIAL OR SIMILAR DAMAGES, SUCH AS BUT NOT LIMITED TO, LOSS OF ANTICIPATED PROFITS OR BENEFITS, RESULTING FROM THE USE OR INABILITY TO USE THE PRODUCT EVEN IF ANY OF THEM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.THIS LIMITATION OF LIABILITY SHALL APPLY TO ANY CLAIM OR CAUSE WHATSOEVER WHETHER SUCH CLAIM OR CAUSE ARISES IN CONTRACT, TORT, OR OTHERWISE. Some states do not allow the exclusion or limitation of indirect, special or consequential damages, so the above limitation may not apply to you. U.S. GOVERNMENT RESTRICTED RIGHTS. If the Product is acquired by or for the U.S. Government then it is provided with Restricted Rights. Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in FAR 52.227-19.The contractor/manufacturer is Syngress Publishing, Inc. at 800 Hingham Street, Rockland, MA 02370. GENERAL: This License Agreement constitutes the entire agreement between the parties relating to the Product. The terms of any Purchase Order shall have no effect on the terms of this License Agreement. Failure of Syngress to insist at any time on strict compliance with this License Agreement shall not constitute a waiver of any rights under this License Agreement.This License Agreement shall be construed and governed in accordance with the laws of the Commonwealth of Massachusetts. If any provision of this License Agreement is held to be contrary to law, that provision will be enforced to the maximum extent permissible and the remaining provisions will remain in full force and effect. *If you do not agree, please return this product to the place of purchase for a refund.

847

Dr. Tom Shinder's ISA Server and Beyond with CDROM

ISA Server 2004

Клиенты ISA. Основная конфигурация ISA Server

MCSE: ISA Server 2000 Administration Study Guide: Exam 70 227 with CDROM

MCSE: ISA Server 2000 Administration Study Guide: Exam 70 227 with CDROM

ISA Server 2006 Migration Guide

MCSE: ISA Server 2000 Administration Study Guide: Exam 70 227 with CDROM

ISA Server 2004. В подлиннике

Integrating ISA Server 2006 with Microsoft Exchange 2007

Integrating ISA Server 2006 with Microsoft Exchange 2007

MySQL Bible with CDROM

Photoshop 7 Savvy with CDROM

Flash 5 Cartooning with Cdrom

Mastering PHP 4.1 with CDROM

Hack Proofing XML with CDROM

Microsoft Internet Security and Acceleration (ISA) Server 2004 Unleashed

Hangi İsa

Strategic Management with CDROM (MBA Masterclass Series)

Maya: Secrets of the Pros with CDROM

MCSE 70-227: ISA Server 2000 administration study guide

ISA Server 2004 наиболее полн. рук. в подлиннике

Configuring ISA Server 2000 Building Firewalls for Windows 2000

Configuring ISA Server 2000: Building Firewalls for Windows 2000

Mastering Windows 2000 Programing with Visual C++ with Cdrom

And Now a Few Laughs from Our Sponsor with CDROM

And Now a Few Laughs from Our Sponsor with CDROM

Operations Research: Applications and Algorithms (with CD-ROM and Infotrac) [With CDROM and Infotrac]

Server Data Access With Java and XML

Getting Started with Couchbase Server

Virtualization with VMware ESX Server

Working With Active Server Pages

Dr. Tom Shinder's ISA Server and Beyond with CDROM

ISA Server 2004

Клиенты ISA. Основная конфигурация ISA Server

MCSE: ISA Server 2000 Administration Study Guide: Exam 70 227 with CDROM

MCSE: ISA Server 2000 Administration Study Guide: Exam 70 227 with CDROM

ISA Server 2006 Migration Guide

MCSE: ISA Server 2000 Administration Study Guide: Exam 70 227 with CDROM

ISA Server 2004. В подлиннике

Integrating ISA Server 2006 with Microsoft Exchange 2007

Integrating ISA Server 2006 with Microsoft Exchange 2007

MySQL Bible with CDROM

Photoshop 7 Savvy with CDROM

Flash 5 Cartooning with Cdrom

Mastering PHP 4.1 with CDROM

Hack Proofing XML with CDROM

Microsoft Internet Security and Acceleration (ISA) Server 2004 Unleashed

Hangi İsa

Strategic Management with CDROM (MBA Masterclass Series)

Maya: Secrets of the Pros with CDROM

MCSE 70-227: ISA Server 2000 administration study guide

ISA Server 2004 наиболее полн. рук. в подлиннике

Configuring ISA Server 2000 Building Firewalls for Windows 2000

Configuring ISA Server 2000: Building Firewalls for Windows 2000

Mastering Windows 2000 Programing with Visual C++ with Cdrom

And Now a Few Laughs from Our Sponsor with CDROM

And Now a Few Laughs from Our Sponsor with CDROM

Operations Research: Applications and Algorithms (with CD-ROM and Infotrac) [With CDROM and Infotrac]

Server Data Access With Java and XML

Getting Started with Couchbase Server

Virtualization with VMware ESX Server

Working With Active Server Pages

Recommend Documents