<<

™ Resource Kit

Mitch Tulloch, Tony Northrup, Jerry Honeycutt with the MSWinVista Team

To learn more about this book, visit Learning at http://www.microsoft.com/MSPress/books/9536.aspx

9780735622838 Publication Date: April 2007

Table of Contents

Acknowledgments ...... xxvii System Requirements ...... xxix Introduction ...... xxxi Part I Overview 1 Overview of Windows Vista Improvements ...... 3 What’s New ...... 3 User Interactions ...... 5 Performance ...... 13 Mobility ...... 16 Tablet PC ...... 20 Deployment ...... 22 Reliability and Supportability ...... 23 Troubleshooting ...... 28 Architecture Improvements ...... 30 Windows Vista Editions ...... 32 Windows Vista Starter ...... 34 Windows Vista Home Basic ...... 35 Windows Vista Home Premium ...... 35 Windows Vista Business ...... 35 Windows Vista Enterprise ...... 36 Windows Vista Ultimate ...... 36 Choosing Hardware ...... 37 Windows Vista Logos ...... 37 Hardware Requirements ...... 38 Summary ...... 38 Additional Resources ...... 39 2 Security in Windows Vista ...... 41 Addressing Specific Security Concerns with Windows Vista ...... 41 Wireless Networks ...... 42 Help Desk Calls Related to ...... 42 Data Theft ...... 47 New and Improved Windows Vista Security Features ...... 50 (UAC) ...... 50 Windows Defender ...... 54 Windows ...... 55

What do you think of this book? We want to hear from you!

Microsoft is interested in hearing your feedback so we can continually improve our books and learning resources for you. To participate in a brief online survey, please visit:

www.microsoft.com/learning/booksurvey/

v vi Table of Contents

Internet Explorer Security Features ...... 58 BitLocker ...... 60 Encrypting (EFS) ...... 63 Auditing Enhancements ...... 64 Smart Card Improvements ...... 65 Credential Manager Enhancements ...... 66 Architectural and Internal Windows Vista Security Improvements ...... 66 Code Integrity (CI) ...... 67 Windows Resource Protection (WRP) ...... 68 ...... 70 Required Driver Signing ...... 71 Hardening ...... 71 Authorization Manager ...... 73 Network Access Protection Client ...... 74 Web Services for Management ...... 74 Crypto Next Generation (CNG) Services ...... 74 Data Execution Prevention (DEP) ...... 75 Address Space Layout Randomization (ASLR) ...... 76 New Logon Architecture ...... 76 Rights Management Services (RMS) ...... 77 Multiple Local Objects ...... 78 Summary ...... 78 Additional Resources ...... 79 Part II Deployment 3 Deployment Platform ...... 83 Tools Introduction ...... 83 Windows Vista Deployment Terminology ...... 85 Platform Components ...... 87 Windows Imaging ...... 88 Answer Files ...... 89 Windows SIM ...... 90 Windows Setup ...... 91 ...... 91 Windows PE ...... 92 Other Tools ...... 93 Windows DS ...... 94 ImageX ...... 95 Basic Deployment Process ...... 96 BDD 2007 Deployment Process ...... 97 Summary ...... 102 Additional Resources ...... 102 4 Planning Deployment ...... 105 Using BDD 2007 for Deployment Planning ...... 105 Planning Guide ...... 107 Feature Team Guides ...... 112 Solution Framework ...... 114 Job Aids ...... 114 Table of Contents vii

Planning Low-Volume Deployment ...... 115 Scope and Objectives ...... 116 Current Environment ...... 116 Configuration Plan ...... 117 Testing and Piloting ...... 117 Rolling Out ...... 118 Windows Vista Requirements ...... 119 Hardware Requirements ...... 119 Upgrade Paths ...... 119 Preparing for Development ...... 120 Application Compatibility ...... 120 Application Management ...... 122 Computer Imaging System ...... 123 Deployment ...... 124 Infrastructure Remediation ...... 125 Operations Readiness ...... 125 Security ...... 126 User State Migration ...... 126 Installing BDD 2007 ...... 127 Program Folders ...... 129 Distribution Share ...... 129 Starting Deployment Workbench ...... 130 Updating BDD 2007 Components ...... 130 Summary ...... 132 Additional Resources ...... 132 5 Automating Installation ...... 133 Deployment Scenarios ...... 133 Upgrade Computer Scenario ...... 134 New Computer Scenario ...... 135 Replace Computer Scenario ...... 135 Understanding Setup ...... 136 Preinstallation Phase ...... 137 Online Configuration Phase ...... 138 Windows Welcome Phase ...... 139 Preparing the Environment ...... 141 Planning Installation ...... 141 Configuring the Technician Computer ...... 143 Using Windows SIM ...... 145 Building Distribution Shares ...... 147 Creating an Answer File ...... 150 Adding Files to Answer Files ...... 153 Converting Windows XP Answer Files ...... 155 Unattend.txt ...... 155 Sysprep.inf ...... 156 WinBOM.ini ...... 156 OEMInfo.ini ...... 156 Oobeinfo.ini ...... 156 viii Table of Contents

Choosing Installation Methods ...... 157 Staging Distribution Shares ...... 157 Using Windows DS ...... 157 Using SMS OSD and BDD ...... 157 Summary ...... 157 Additional Resources ...... 158 6 Developing Disk Images ...... 159 Getting Started ...... 160 Prerequisite Skills ...... 161 Lab Requirements ...... 161 Capturing Images with BDD 2007 ...... 164 Navigating Deployment Workbench ...... 165 Configuring the Lab Distribution Share ...... 166 Adding Windows Vista ...... 167 Adding Applications ...... 169 Adding Packages ...... 175 Adding Out-of-Box Drivers ...... 177 Creating Image Builds ...... 179 Editing a Build’s Task Sequence ...... 183 Configuring Group and Task Properties ...... 186 Configuring the Options Tab ...... 186 Creating the Lab Deployment Point ...... 191 Configuring the Deployment Point ...... 193 Updating the Deployment Point ...... 197 Capturing a Disk Image for LTI ...... 197 Capturing a Disk Image for ZTI ...... 199 Creating an Image Capture CD ...... 199 Preparing the Image for Capture ...... 199 Capturing the Image ...... 201 Manually Preparing Images ...... 201 Customizing BDD 2007 ...... 203 Summary ...... 203 Additional Resources ...... 204 7 Migrating User State Data ...... 207 Evaluating Migration Technologies ...... 208 ...... 208 User State Migration Tool ...... 208 Microsoft IntelliMirror ...... 209 Using Windows Easy Transfer ...... 209 Planning User State Migration Using USMT ...... 210 Choosing Subject Matter Experts ...... 211 Identifying User State Data ...... 212 Prioritizing Migration Tasks ...... 213 Choosing a Data Store Location ...... 214 Automating USMT ...... 215 Installing USMT ...... 216 Local Installation ...... 217 Table of Contents ix

Network Staging ...... 218 BDD 2007 ...... 218 SMS 2003 OSD ...... 218 Understanding USMT Components ...... 218 Scanstate.exe ...... 219 Loadstate.exe ...... 220 XML Migration Files ...... 220 Developing Migration Files ...... 221 Customizing USMT ...... 221 Control File Syntax ...... 221 Deploying Migration Files ...... 222 Using USMT in BDD 2007 ...... 222 Downloading USMT Components ...... 223 Specifying the Data Store Location ...... 224 Adding Custom Migration Files ...... 226 Summary ...... 227 Additional Resources ...... 227 8 Deploying Applications ...... 229 Preparing the Lab ...... 230 Planning Deployment ...... 231 Priorities ...... 232 Categories ...... 233 Installation Methods ...... 234 Subject Matter Experts ...... 235 Configurations ...... 236 Mitigating Compatibility Issues ...... 236 Choosing a Deployment Strategy ...... 239 Thick Images ...... 240 Thin Images ...... 241 Hybrid Images ...... 243 Automating Installation ...... 243 ...... 244 FLEXnet InstallShield ...... 246 Legacy InstallShield ...... 246 Legacy InstallShield PackageForTheWeb ...... 247 Legacy Wise Installation System ...... 247 ...... 248 Repackaging Legacy Applications ...... 248 The Repackaging Process ...... 249 Repackaging Tools ...... 249 Injecting in a Disk Image ...... 250 Adding Applications ...... 251 Creating Dependencies ...... 253 Installing Applications ...... 254 Installing from an Answer File ...... 256 Adding Applications in Audit Mode ...... 257 Summary ...... 258 Additional Resources ...... 258 x Table of Contents

9 Preparing Windows PE ...... 261 Exploring Windows PE ...... 262 Capabilities ...... 263 Limitations ...... 265 New Features ...... 266 Setting up the Environment ...... 267 Installing the Windows AIK ...... 267 Configuring the Build Environment ...... 268 Removing the Build Environment ...... 269 Working with Windows PE ...... 270 Applying Windows PE ...... 270 Adding Optional Components ...... 270 Copying Applications ...... 273 Adding Device Drivers ...... 273 Installing Updates ...... 273 Prepping the Image ...... 273 Capturing the Image ...... 274 Creating Bootable Media ...... 275 Customizing Windows PE ...... 278 Automating Windows PE ...... 280 Automating with Unattend.xml ...... 280 Adding Images to Windows DS ...... 280 Using Windows PE with BDD ...... 281 Summary ...... 283 Additional Resources ...... 284 10 Deploying with Windows DS ...... 285 Introducing Windows DS ...... 286 Service Architecture ...... 286 Operating Modes ...... 291 Planning for Windows DS ...... 293 Requirements ...... 293 Client Requirements ...... 294 DHCP Requirements ...... 295 Routing Requirements ...... 296 Capacity Requirements ...... 296 Installing Windows DS ...... 297 2003 ...... 297 Windows Server Code Name “Longhorn” ...... 298 Configuring Windows DS ...... 299 Preparing Discover Images ...... 301 Importing Images ...... 302 Importing Boot Images ...... 303 Importing Install Images ...... 303 Managing Image Security ...... 304 Installing Windows Vista ...... 307 Capturing Custom Images ...... 308 Using Windows DS with BDD 2007 ...... 309 Table of Contents xi

Summary ...... 311 Additional Resources ...... 311 11 Using Volume Activation ...... 313 Introduction ...... 313 Volume Activation ...... 314 Activation Options ...... 315 Activation Terminology ...... 319 Planning an Activation Infrastructure ...... 320 Analyzing Activation Options ...... 321 Mapping Computers to Activation Options ...... 322 Implementing OEM Activation ...... 322 Installing Volume-Licensed Images on OEM Systems ...... 323 OEM Imaging of Volume Editions ...... 324 Implementing MAK Activation ...... 324 Obtaining MAKs ...... 324 Managing MAKs ...... 324 Obtaining Additional MAK Activations ...... 325 Assigning MAKs to Windows Vista Systems ...... 325 Volume Activation Management Tool ...... 327 Implementing KMS Activation ...... 328 Installing a KMS Computer ...... 329 Installing KMS Client Computers ...... 332 KMS Integration with the Deployment Workbench ...... 333 KMS Reporting ...... 333 Configuring KMS Activation ...... 334 Using Slmgr.vbs to Configure KMS ...... 334 Using Registry Entries to Configure KMS ...... 335 KMS Computer Configuration...... 335 KMS Client Configuration ...... 336 Using WMI to Configure KMS ...... 336 Activation in BDD 2007 ...... 337 Using the Windows Deployment Wizard ...... 338 Automating the Windows Deployment Wizard ...... 339 Troubleshooting Volume Activation ...... 339 Common Problems ...... 339 Event Log Entries ...... 341 Resolving RFM ...... 341 Summary ...... 344 Additional Resources ...... 345 12 Deploying with BDD 2007 ...... 347 Introducing BDD 2007 Deployment ...... 348 Deployment Scenarios ...... 348 Comparing LTI and ZTI ...... 348 Preparing the Distribution Share ...... 349 Creating the Additional Deployment Points ...... 350 Preparing Windows PE for ZTI ...... 355 To Prepare the Windows PE Images ...... 355 Customizing Windows PE ...... 356 xii Table of Contents

Providing Access to Windows PE Image ...... 359 Importing Windows PE in to SMS 2003 OSD ...... 360 Creating the SMS 2003 OSD Image Installation CD ...... 360 Preparing Windows DS ...... 361 Selecting an Operational Mode ...... 362 Adding Images to Windows DS ...... 362 Pre-staging Destination Computers ...... 363 Configuring Resource Access ...... 364 Creating Shared Folders ...... 364 Configuring Share Permissions ...... 364 Configuring Other Resources ...... 365 Configuring ZTI Package Selection ...... 367 Configuring SMS 2003 for ZTI ...... 368 Configuring the ZTI Image ...... 368 Creating a ZTI User State Migration Package ...... 372 Customizing BDD 2007 Deployment ...... 374 Configuring Multiple Computers ...... 374 Configuring Individual Computers ...... 377 Customizing CustomSettings.ini ...... 378 Customizing BootStrap.ini ...... 379 Using the BDD 2007 Database ...... 380 Configuring for Common Scenarios ...... 385 Typical for LTI ...... 385 Typical Settings for ZTI ...... 387 Automated Settings for LTI ...... 388 Performing LTI Deployments ...... 391 Performing ZTI Deployments ...... 401 Summary ...... 402 Additional Resources ...... 402 Part III Desktop Management 13 Managing the Desktop Environment ...... 407 Understanding Group Policy in Windows Vista ...... 407 Group Policy Issues on Earlier Versions of Windows ...... 408 New Group Policy Features in Windows Vista ...... 410 New Group Policy Settings in Windows Vista ...... 411 Understanding ADMX Template Files ...... 417 Understanding Multiple Local Group Policy ...... 422 Managing Windows Vista Computers Using Group Policy ...... 424 Configuring the Central Store ...... 424 Creating and Editing GPOs ...... 426 Using ADMX Migrator ...... 430 Configuring Group Policy Processing ...... 432 Using Advanced Group Policy Management ...... 432 Troubleshooting Group Policy ...... 433 Using ...... 433 Enabling Debug Logging ...... 435 Using GPLogView ...... 435 Table of Contents xiii

Summary ...... 437 Additional Resources ...... 437 14 Managing Users and User Data ...... 439 Understanding User Profiles in Windows Vista ...... 439 Types of User Profiles ...... 439 User Profile Namespace ...... 441 Application Compatibility Issues ...... 446 Implementing Corporate Roaming ...... 450 Understanding Roaming User Profiles and ...... 450 Implementing Folder Redirection ...... 454 Implementing Roaming User Profiles ...... 466 Working with Offline Files ...... 475 How Offline Files Works in Windows Vista ...... 477 Managing Offline Files ...... 479 Summary ...... 483 Additional Resources ...... 483 15 Managing Disks and File Systems ...... 485 Overview of Partitioning Disks ...... 486 How to Choose Between MBR or GPT ...... 486 Converting from MBR to GPT Disks ...... 487 GPT Partitions ...... 488 Choosing Basic or Dynamic Disks ...... 489 Working with Volumes ...... 489 How to Create a Simple Volume ...... 489 How to Create a Spanned Volume ...... 490 How to Create a Striped Volume ...... 491 How to Resize a Volume ...... 492 How to Delete a Volume ...... 493 File System Fragmentation ...... 494 ...... 496 How File Backups Work ...... 498 File and Folder Backup Structure ...... 499 How Complete PC Backups Work ...... 501 How to Start a Complete PC Backup from the Command Line ...... 501 How to Restore a Complete PC Backup ...... 502 Complete PC Backup Structure ...... 505 Best Practices for Computer Backups ...... 505 How to Manage Backup Using Group Policy Settings ...... 506 Previous Versions and Shadow Copies ...... 508 Windows ReadyBoost ...... 513 BitLocker Drive Encryption ...... 516 How BitLocker Encrypts Data ...... 516 How BitLocker Protects Data ...... 517 BitLocker Phases ...... 520 BitLocker Requirements ...... 522 How to Configure BitLocker Partitions ...... 523 How to Enable the Use of BitLocker on Computers Without TPM ...... 523 How to Enable BitLocker Encryption ...... 524 xiv Table of Contents

How to Manage BitLocker Keys on a Local Computer ...... 527 How to Manage BitLocker from the Command Line ...... 527 How to Recover Data Protected by BitLocker ...... 529 How to Disable or Remove BitLocker Drive Encryption ...... 530 How to Permanently Decommission a BitLocker Drive ...... 531 How to Prepare for BitLocker ...... 532 How to Manage BitLocker with Group Policy ...... 532 The Costs of BitLocker ...... 533 ...... 534 How to Export Personal Certificates ...... 534 How to Import Personal Certificates ...... 535 How to Grant Users Access to an Encrypted File ...... 535 Symbolic Links ...... 536 How to Create Symbolic Links ...... 537 How to Create Relative or Absolute Symbolic Links ...... 538 How to Create Symbolic Links to Shared Folders ...... 539 How to Use Hard Links ...... 541 Disk Quotas ...... 541 How to Configure Disk Quotas on a Single Computer ...... 542 How to Configure Disk Quotas from a Command Prompt ...... 543 How to Configure Disk Quotas by Using Group Policy Settings ...... 544 Summary ...... 545 Additional Resources ...... 545 16 Managing Devices and Services ...... 547 Managing Devices ...... 547 Changes to Device Management in Windows Vista ...... 547 Understanding Device Installation in Windows Vista ...... 549 Managing Devices Using Group Policy ...... 558 Troubleshooting Device Installation ...... 568 Understanding Power Management ...... 574 Configuring Power Management Settings ...... 576 Understanding Services ...... 586 Changes to Services in Windows Vista ...... 587 Managing Services ...... 589 Summary ...... 593 Additional Resources ...... 593 17 Managing Sharing ...... 595 Managing File Sharing ...... 595 Understanding Local Sharing ...... 596 Understanding Network Sharing ...... 600 Implementing File Sharing ...... 607 Managing File Sharing Using Group Policy ...... 624 Creating and Managing Shares Using the Net Commands ...... 624 Creating and Managing Shares Using Scripts ...... 626 Troubleshooting File Sharing ...... 632 Best Practices for Implementing File Sharing in a Workgroup Environment ...... 634 Table of Contents xv

Best Practices for Implementing File Sharing in a Domain Environment ...... 635 Managing Media Sharing ...... 636 Media Sharing and ...... 638 Media Sharing and Windows Firewall in Windows XP ...... 639 Limitations of Media Sharing ...... 640 Media Sharing and Network Categories ...... 641 Using Media Sharing ...... 642 Managing Media Sharing with Group Policy ...... 645 Troubleshooting Media Sharing ...... 646 Best Practices for Media Sharing ...... 647 Summary ...... 647 Additional Resources ...... 647 18 Managing ...... 649 Understanding How Meeting Space Works ...... 650 Meeting Space and Microsoft P2P Collaboration Services ...... 650 Meeting Space and IPv6 ...... 651 Meeting Space and the Peer Name Resolution Protocol (PNRP) ...... 653 Meeting Space and Near Me ...... 654 Meeting Space Services ...... 655 Meeting Space and Windows Firewall ...... 655 Meeting Space and Security ...... 657 How a Meeting Works ...... 659 Limitations of Meeting Space ...... 660 Deploying and Managing Meeting Space ...... 662 Managing Meeting Space in a Workgroup Environment ...... 662 Managing Meeting Space in a Domain Environment ...... 662 Managing Meeting Space in an Ad-Hoc Wireless Environment ...... 664 Using Meeting Space ...... 664 Setting Up Meeting Space ...... 665 Configuring People Near Me ...... 667 Starting a New Meeting ...... 670 Joining a Meeting ...... 670 Inviting Others to Your Meeting ...... 672 Collaborating Within a Meeting ...... 673 Troubleshooting Meeting Space ...... 673 Summary ...... 674 Additional Resources ...... 674 19 Managing Printing ...... 677 Enhancements to Printing in Windows Vista ...... 677 Understanding Printing in Windows Vista ...... 679 Understanding the XML Paper Specification ...... 679 Understanding the Windows Vista Print Subsystem ...... 680 Understanding Print Management ...... 683 Enhancements to Print Management in Windows Vista ...... 683 The Print Management Console ...... 684 Adding and Removing Print Servers ...... 686 Adding Printers Using the Network Printer Installation Wizard ...... 687 xvi Table of Contents

Creating and Using Printer Filters ...... 688 Managing Printers Using Print Management ...... 690 Configuring Properties of Printers ...... 690 Publishing Printers in Active Directory ...... 691 Managing Printer Drivers ...... 692 Exporting and Importing Print Server Configurations ...... 694 Performing Bulk Actions Using Print Management ...... 695 Client-Side Management of Printers ...... 696 Installing Printers Using the Printers CPL ...... 697 Searching for Printers ...... 698 Installing Printers Using Point and Print ...... 700 Using Printers Explorer ...... 701 Using the Color Management CPL ...... 701 Managing Client-Side Printer Experience Using Group Policy ...... 702 Configuring the Add Printer Wizard ...... 702 Disable Client-Side Printer Rendering ...... 704 Configuring Package Point and Print Restrictions ...... 705 Deploying Printers Using Group Policy ...... 707 Preparing to Deploy Printers ...... 707 Deploying a Printer Connection ...... 708 Limitations of Deploying Printers Using Group Policy ...... 710 Assigning Printers Based on Location ...... 710 Migrating Print Servers ...... 712 Migrate Print Servers Using Print Management ...... 712 Migrating Print Servers Using Printbrm.exe ...... 714 Monitoring and Troubleshooting Printers ...... 714 Configuring E- Notifications ...... 715 Configuring Print Server Notifications ...... 715 Configuring Script Actions ...... 716 Configuring Detailed Event Logging ...... 716 Summary ...... 717 Additional Resources ...... 717 20 Managing Search ...... 719 Search and Indexing Enhancements in Windows Vista ...... 719 Issues in Previous Windows Platforms ...... 719 Design Goals and New Features ...... 720 How Search and Indexing Works in Windows Vista ...... 721 Understanding Search Engine Terminology ...... 722 Engine Processes ...... 723 Windows Search Engine Architecture ...... 726 Understanding the Catalog ...... 727 Understanding the Indexing Process ...... 732 Understanding Remote Search ...... 740 Managing Indexing ...... 741 Configuring the Catalog ...... 741 Configuring Offline Files Indexing ...... 743 Configuring Indexing of Encrypted Files ...... 744 Configuring Indexing of Similar Words ...... 744 Table of Contents xvii

Other Configuration Options ...... 745 Using Search ...... 746 Configuring Search Using Folder Options ...... 746 Search Integration in the Shell ...... 748 Using Instant Search ...... 748 Using the Search Explorer ...... 750 Other Search and Organization Features ...... 753 Troubleshooting Search ...... 753 Summary ...... 754 Additional Resources ...... 754 21 Managing ...... 757 Non-Security Internet Explorer Improvements ...... 757 User Interface Changes ...... 757 Tabbed Browsing ...... 758 Search Bar ...... 758 RSS Feeds ...... 760 Improved Standards Support ...... 761 Expanded Group Policy Settings ...... 762 Internet Explorer 7 Security Features ...... 762 Defending Against Malware ...... 765 Protecting Against Data Theft ...... 774 Security Zones ...... 784 Managing Internet Explorer with Group Policy ...... 788 Using the Internet Explorer Administration Kit ...... 791 Troubleshooting Internet Explorer Problems ...... 792 Internet Explorer Does Not Start ...... 793 An Add-on Does Not Work Properly ...... 793 Some Webpages Do Not Display Properly ...... 794 An Unwanted Toolbar Appears ...... 796 The Home Page or Other Settings Have Changed ...... 796 Summary ...... 797 Additional Resources ...... 797

Part IV Desktop Maintenance 22 Maintaining Desktop Health ...... 801 Monitoring Reliability and Performance ...... 801 Component Binaries ...... 802 Opening the Reliability and ...... 802 Using Resource Overview ...... 803 Using Performance Monitor ...... 806 Using Reliability Monitor ...... 824 Understanding Windows Eventing ...... 831 Overview of Windows Eventing ...... 831 Windows Eventing Capabilities ...... 832 Event Viewer User Interface ...... 838 Understanding the Windows System Assessment Tool ...... 851 Overview of WinSAT ...... 851 xviii Table of Contents

How Performs Composition ...... 855 Troubleshooting Aero Glass ...... 857 Overriding Windows Vista Automatic Detection Mechanisms ...... 858 Using Performance Information And Tools ...... 860 Accessing Performance Information And Tools ...... 860 Configuring Performance Information And Tools Using Group Policy ...... 862 Understanding Each Section of the Tool ...... 862 Understanding ...... 865 Overview of Windows Error Reporting ...... 866 Error Reporting Cycle ...... 867 Report Data Overview ...... 868 Conceptual Components ...... 869 Architecture of Windows Error Reporting ...... 873 Configuring Windows Error Reporting ...... 875 Using the Problem Reports And Solutions ...... 879 Using Task Scheduler ...... 884 Task Scheduler Enhancements and Improvements ...... 884 Operational Overview ...... 886 Task Scheduler Architecture ...... 886 Task Scheduler Security ...... 888 AT and Task Scheduler v1.0 Compatibility Modes ...... 889 Task Scheduler User Interface ...... 890 Creating New Tasks ...... 891 Managing Tasks ...... 901 Using the SchTasks.exe Command ...... 903 Scheduled Tasks Events ...... 906 Troubleshooting Task Scheduler ...... 906 Interpreting Result and Return Codes ...... 908 Summary ...... 909 Additional Resources ...... 909 23 Supporting Users Using Remote Assistance ...... 911 Understanding Remote Assistance ...... 911 Improvements to Remote Assistance in Windows Vista ...... 912 How Remote Assistance Works ...... 913 Using Remote Assistance in the Enterprise ...... 922 Interoperability with Remote Assistance in Windows XP ...... 924 Implementing and Managing Remote Assistance ...... 925 Initiating Remote Assistance Sessions ...... 925 Scenario 1: Offering Remote Assistance Using DCOM ...... 927 Scenario 2: Soliciting Remote Assistance by Creating RA Tickets and Saving Them on Monitored Network Shares ...... 929 Managing Remote Assistance Using Group Policy ...... 933 Additional Registry Settings for Configuring Remote Assistance ...... 936 Summary ...... 941 Additional Resources ...... 942 Table of Contents xix

24 Managing Software Updates ...... 943 Update Improvements to Windows Vista ...... 944 Methods for Deploying Updates ...... 946 Client ...... 946 Windows Server Update Services ...... 947 Systems Management Server ...... 949 Manually Installing, Scripting, and Removing Updates ...... 950 Overview of Windows Vista Update Files ...... 950 How to Script Update Installations ...... 951 How to Remove Updates ...... 951 Deploying Updates to New Computers ...... 952 Managing BITS ...... 956 BITS Behavior ...... 956 BITS Group Policy Settings ...... 957 The BITSAdmin.exe Tool ...... 959 Windows Update Group Policy Settings ...... 963 Configuring Windows Update to Use a Proxy Server ...... 965 Tools for Auditing Software Updates ...... 966 The MBSA Console ...... 966 MBSACLI ...... 968 SMS ...... 970 Troubleshooting the Windows Update Client ...... 970 The Process of Updating Network Software ...... 973 Assembling the Update Team ...... 973 Inventorying Software ...... 974 Creating an Update Process ...... 976 How Microsoft Distributes Updates ...... 981 Security Updates ...... 982 Update Rollups ...... 983 Service Packs ...... 983 Microsoft Product Life Cycles ...... 985 Summary ...... 985 Additional Resources ...... 986 25 Managing Client Protection ...... 987 Understanding the Risk of Malware ...... 987 User Account Control ...... 988 UAC for Standard Users ...... 991 UAC for Administrators ...... 992 UAC User Interface ...... 993 How Windows Vista Determines Whether an Application Needs Administrative Privileges ...... 995 UAC Virtualization ...... 998 UAC and Startup Programs ...... 999 Compatibility Problems with UAC ...... 999 How to Configure User Account Control ...... 1002 How to Configure Auditing for Privilege Elevation ...... 1007 Other UAC Event Logs ...... 1008 Best Practices for Using UAC ...... 1008 xx Table of Contents

Using Windows Defender ...... 1009 Understanding Windows Defender ...... 1010 Windows Defender Alert Levels ...... 1013 Understanding Microsoft SpyNet ...... 1014 Configuring Windows Defender Using Group Policy ...... 1015 Configuring Windows Defender on a Single Computer ...... 1017 Windows Defender Tools ...... 1017 How to Determine if a Computer Is Infected with ...... 1019 Best Practices for Using Windows Defender ...... 1020 How to Troubleshoot Problems with Unwanted Software ...... 1021 Client Security ...... 1022 Summary ...... 1024 Additional Resources ...... 1025

Part V Networking 26 Configuring Windows Networking ...... 1029 Usability Improvements ...... 1029 Network And Sharing Center ...... 1030 Network Explorer ...... 1032 Network Map ...... 1035 Networking Icons in the System Tray ...... 1036 The Set Up A Connection Or Network Wizard ...... 1037 Manageability Improvements ...... 1037 Network Access Protection (NAP) ...... 1038 Network Location Types ...... 1039 Policy-based QoS ...... 1041 Windows Firewall and IPsec ...... 1044 Windows Connect Now ...... 1044 Core Networking Improvements ...... 1045 Efficient Networking ...... 1046 Improved Reliability ...... 1050 IPv6 Support ...... 1051 802.1X Network Authentication ...... 1053 (SMB) 2.0 ...... 1056 Strong Host Model ...... 1056 Wireless Networking ...... 1057 Improved ...... 1059 Network Awareness ...... 1059 Improved Peer Networking ...... 1060 EAPHost Architecture ...... 1062 Layered Service Provider (LSP) ...... 1063 Windows Sockets Direct Path for System Area Networks ...... 1064 How to Configure Wireless Settings ...... 1065 Manually Configuring Wireless Settings ...... 1065 Using Group Policy to Configure Wireless Settings ...... 1067 Configuring Wireless Settings from the Command Line or a Script ...... 1069 How to Configure TCP/IP ...... 1071 DHCP ...... 1071 Table of Contents xxi

Manually Configuring IP Addresses ...... 1074 Command Line and Scripts ...... 1075 How to Connect to Active Directory Domains ...... 1078 Summary ...... 1079 Additional Resources ...... 1080 27 Configuring Windows Firewall and IPsec ...... 1083 Understanding Windows Firewall ...... 1083 Understanding the Windows Filtering Platform ...... 1085 Understanding Windows Service Hardening ...... 1087 Understanding Windows Firewall Profiles ...... 1090 Understanding Windows Firewall Policy Storage and Rule Merge Logic ...... 1093 Understanding Windows Firewall Rules ...... 1094 Understanding IPsec Integration ...... 1115 Understanding Windows Firewall Logging and Auditing ...... 1128 Managing Windows Firewall ...... 1131 Managing Windows Firewall Using the Windows Firewall With Advanced Security Snap-in ...... 1133 Managing Windows Firewall Using Group Policy ...... 1137 Managing Windows Firewall Using ...... 1140 Managing Windows Firewall Using Scripts ...... 1140 Common Management Tasks ...... 1142 Summary ...... 1145 Additional Resources ...... 1145 28 Connecting Remote Users and Networks ...... 1147 Understanding Connection Types ...... 1147 Outgoing Connection Types ...... 1148 Incoming Connection Types ...... 1149 Deprecated Connection Types ...... 1149 Configuring Virtual Private Network Connections ...... 1150 Supported Tunneling Protocols ...... 1150 Enhancements to VPN Security in Windows Vista ...... 1150 VPN Connection Negotiation Process ...... 1155 Creating and Configuring VPN Connections ...... 1156 Configuring Dial-up Connections ...... 1170 Creating a Dial-up Connection ...... 1171 Configuring a Dial-up Connection ...... 1172 Advanced Connection Settings ...... 1173 Configuring Incoming Connections ...... 1173 Managing Connections Using Group Policy ...... 1175 Using Remote Desktop ...... 1178 Understanding Remote Desktop ...... 1178 Steps for Using Remote Desktop ...... 1182 Enabling Remote Desktop and Authorizing Users on a Single Computer ...... 1182 Enabling Remote Desktop using Group Policy ...... 1185 Configuring and Deploying Remote Desktop Connection ...... 1185 xxii Table of Contents

Establishing a Remote Desktop Session ...... 1193 Improving Remote Desktop Performance ...... 1193 Troubleshooting Remote Desktop ...... 1194 Summary ...... 1195 Additional Resources ...... 1195 29 Deploying IPv6 ...... 1197 Understanding IPv6 ...... 1197 Understanding IPv6 Terminology ...... 1198 Understanding IPv6 Addressing ...... 1199 Understanding ICMPv6 Messages ...... 1204 Understanding Neighbor Discovery ...... 1204 Understanding Address Autoconfiguration ...... 1206 Understanding Name Resolution ...... 1208 IPv6 Enhancements in Windows Vista ...... 1211 Configuring and Troubleshooting IPv6 in Windows Vista ...... 1214 Displaying IPv6 Address Settings ...... 1214 Configuring IPv6 in Windows Vista Using the User Interface ...... 1218 Configuring IPv6 in Windows Vista Using Netsh ...... 1219 Other IPv6 Configuration Tasks ...... 1220 Troubleshooting IPv6 Connectivity ...... 1224 Planning for IPv6 Migration ...... 1226 Understanding ISATAP ...... 1227 Migrating an Intranet to IPv6 ...... 1228 Summary ...... 1231 Additional Resources ...... 1231

Part VI Troubleshooting 30 Configuring Startup and Troubleshooting Startup Issues ...... 1235 What’s New with Windows Vista Startup ...... 1235 Boot Configuration Data ...... 1236 System Recovery ...... 1239 Windows Boot Performance Diagnostics ...... 1240 Understanding the Startup Process ...... 1241 Power-on Self Test Phase ...... 1242 Initial Startup Phase ...... 1242 Windows Boot Manager Phase ...... 1245 Windows Boot Loader Phase ...... 1246 Kernel Loading Phase ...... 1247 Logon Phase ...... 1251 Important Startup Files ...... 1253 How to Configure Startup Settings ...... 1254 How to Use the Startup And Recovery Dialog Box ...... 1254 How to Use the System Configuration Tool ...... 1254 How to Use BCDEdit ...... 1256 How to Remove the Windows Vista Boot Loader ...... 1261 The Process of Troubleshooting Startup ...... 1262 Startup Troubleshooting Before the Progress Bar Appears ...... 1262 Table of Contents xxiii

Startup Troubleshooting After the Progress Bar Appears ...... 1272 Troubleshooting Startup Problems After Logon ...... 1284 Summary ...... 1288 Additional Resources ...... 1289 31 Troubleshooting Hardware, Driver, and Disk Issues ...... 1291 Windows Vista Improvements for Hardware and Driver Troubleshooting ...... 1291 Windows Memory Diagnostics ...... 1292 Disk Failure Diagnostics ...... 1292 Self-Healing NTFS ...... 1293 Reliability Monitor ...... 1294 Improved Driver Reliability ...... 1294 Improved Error Reporting ...... 1295 The Process of Troubleshooting Hardware Issues ...... 1295 How to Troubleshoot Problems That Prevent Windows from Starting ...... 1295 How to Troubleshooting Problems Installing New Hardware ...... 1295 How to Troubleshooting Problems with Existing Hardware ...... 1296 How to Troubleshoot Unpredictable Symptoms ...... 1298 How to Diagnose Hardware Problems ...... 1299 How to Use to Identify Failed Devices ...... 1299 How to Check the Physical Setup of Your Computer ...... 1300 How to Check the Configuration of Your Hardware ...... 1301 How to Verify That System Firmware and Peripheral Firmware Are Up to Date ...... 1302 How to Test Your Hardware by Running Diagnostic Tools ...... 1302 How to Simplify Your Hardware Configuration ...... 1303 How to Diagnose Disk-Related Problems ...... 1304 How to Use Built-in Diagnostics ...... 1305 How to Use Problem Reports and Solutions ...... 1305 How to Use Reliability Monitor ...... 1305 How to Use Event Viewer ...... 1306 How to Use Data Collector Sets ...... 1306 How to Use Windows Memory Diagnostics ...... 1307 How to Troubleshoot Disk Problems ...... 1315 How to Prepare for Disk Failures ...... 1315 How to Use Chkdsk ...... 1316 How to Use the Wizard ...... 1322 How to Disable Non-volatile Caching ...... 1322 How to Troubleshoot Driver Problems ...... 1323 How to Find Updated Drivers ...... 1323 How to Roll Back Drivers ...... 1324 How to Use the ...... 1324 How to Use the File Signature Verification ...... 1326 How to Use Device Manager to View and Change Resource Usage ...... 1327 How to Use ...... 1328 How to Troubleshoot USB Problems ...... 1329 How to Troubleshoot Bluetooth Problems ...... 1333 Summary ...... 1334 Additional Resources ...... 1334 xxiv Table of Contents

32 Troubleshooting Network Issues ...... 1337 Tools for Troubleshooting ...... 1337 Arp ...... 1340 Event Viewer ...... 1341 Ipconfig ...... 1342 Nblookup ...... 1343 Nbtstat ...... 1344 Net ...... 1346 Netstat ...... 1348 Network Monitor ...... 1349 Nslookup ...... 1351 PathPing ...... 1354 Performance Monitor ...... 1357 Ping ...... 1360 Portqry ...... 1361 Reliability and Performance ...... 1363 ...... 1365 Route ...... 1366 ...... 1368 Telnet Client ...... 1370 Test TCP ...... 1372 Windows Network Diagnostics ...... 1374 The Process of Troubleshooting Network Problems ...... 1374 How to Troubleshoot Network Connectivity Problems ...... 1376 How to Troubleshoot Application Connectivity Problems ...... 1381 How to Troubleshoot Name-Resolution Problems ...... 1384 How to Troubleshoot Performance Problems and Intermittent Connectivity Issues ...... 1388 How to Troubleshoot Joining or Logging on to a Domain ...... 1391 How to Troubleshoot Network Discovery ...... 1394 How to Troubleshoot File and Printer Sharing ...... 1395 How to Troubleshoot Wireless Networks ...... 1397 How to Troubleshoot Firewall Problems ...... 1399 Summary ...... 1401 Additional Resources ...... 1401 33 Troubleshooting Stop Messages ...... 1403 Stop Message Overview ...... 1403 Identifying the Stop Error ...... 1404 Finding Troubleshooting Information ...... 1404 Stop Messages ...... 1405 Types of Stop Errors ...... 1408 Memory Dump Files ...... 1408 Configuring Small Memory Dump Files ...... 1410 Configuring Kernel Memory Dump Files ...... 1411 Configuring Complete Memory Dump Files ...... 1412 How to Manually Initiate a Stop Error and Create a Dump File ...... 1413 Using Memory Dump Files to Analyze Stop Errors ...... 1413 Table of Contents xxv

Being Prepared for Stop Errors ...... 1419 Prevent System Restarts After a Stop Error ...... 1419 Record and Save Stop Message Information ...... 1420 Check Software Disk Space Requirements ...... 1421 Install a Kernel Debugger and Symbol Files ...... 1421 Common Stop Messages ...... 1421 Stop 0x0A or IRQL_NOT_LESS_OR_EQUAL ...... 1421 Stop 0x1E or KMODE_EXCEPTION_NOT_HANDLED ...... 1423 Stop 0x24 or NTFS_FILE_SYSTEM ...... 1425 Stop 0x2E or DATA_BUS_ERROR ...... 1426 Stop 0x3F or NO_MORE_SYSTEM_PTES ...... 1427 Stop 0x50 or PAGE_FAULT_IN_NONPAGED_AREA ...... 1428 Stop 0x77 or KERNEL_STACK_INPAGE_ERROR ...... 1429 Stop 0x7A or KERNEL_DATA_INPAGE_ERROR ...... 1430 Stop 0x7B or INACCESSIBLE_BOOT_DEVICE ...... 1432 Stop 0x7F or UNEXPECTED_KERNEL_MODE_TRAP ...... 1434 Stop 0x9F or DRIVER_POWER_STATE_FAILURE ...... 1436 Stop 0xBE or ATTEMPTED_WRITE_TO_READONLY_MEMORY ...... 1437 Stop 0xC2 or BAD_POOL_CALLER ...... 1437 Stop 0xCE or DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS ...... 1439 Stop 0xD1 or DRIVER_IRQL_NOT_LESS_OR_EQUAL ...... 1440 Stop 0xD8 or DRIVER_USED_EXCESSIVE_PTES ...... 1440 Stop 0xEA or THREAD_STUCK_IN_DEVICE_DRIVER ...... 1441 Stop 0xED or UNMOUNTABLE_BOOT_VOLUME ...... 1441 Stop 0xFE or BUGCODE_USB_DRIVER ...... 1442 Stop 0xC000021A or STATUS_SYSTEM_PROCESS_TERMINATED ...... 1443 Stop 0xC0000221 or STATUS_IMAGE_CHECKSUM_MISMATCH ...... 1444 Hardware Malfunction Messages ...... 1445 Stop Message Checklist ...... 1445 Check Your Software ...... 1446 Check Your Hardware ...... 1448 Summary ...... 1450 Additional Resources ...... 1450 Part VII Appendices A Appendix A ...... 1453 B Appendix B ...... 1461 C Appendix C ...... 1471

Glossary ...... 1481

Index ...... 1499

What do you think of this book? We want to hear from you!

Microsoft is interested in hearing your feedback so we can continually improve our books and learning resources for you. To participate in a brief online survey, please visit:

www.microsoft.com/learning/booksurvey/ Chapter 27 Configuring Windows Firewall and IPsec

In this chapter: Understanding Windows Firewall ...... 1083 Managing Windows Firewall ...... 1131 Summary ...... 1145 Additional Resources ...... 1145

Windows Vista includes a stateful, authenticating Windows Firewall that provides more gran- ular firewall rules, can block both incoming and outgoing traffic, fully supports IPv6, uses location-aware profiles, enforces network service hardening, and provides integrated Internet Protocol security (IPsec) protection. This chapter examines how to configure and manage Windows Firewall and how to configure and manage IPsec protection using the new Win- dows Firewall With Advanced Security snap-in, Group Policy, and new netsh command con- texts included with Windows Vista. The chapter also describes how the new Windows Firewall simplifies the implementation of server and domain isolation scenarios and Network Access Protection (NAP) using IPsec.

Understanding Windows Firewall Windows Firewall in Windows Vista is a significant advance over Windows Firewall in Win- dows XP Service Pack 2. Table 27-1 illustrates a feature comparison between these two fire- walls.

Table 27-1 Feature Comparison Between Windows Firewall in Windows Vista and Windows XP SP2 Feature XP SP2 Windows Vista Filtering direction Inbound only Both inbound and outbound Default filtering Block (fixed) Configurable actions for inbound and outbound action traffic Protocols supported TCP, UDP, ICMP (partial) Any IANA IP protocols

1083 1084 Part V: Networking

Table 27-1 Feature Comparison Between Windows Firewall in Windows Vista and Windows XP SP2 Feature XP SP2 Windows Vista Types of rules Filter by port, application, Filter by any combination or permutation of the or ICMP type following: protocol, local or remote port (TCP and UDP only), ICMPv4/v6 Type and code, local or remote IP addresses, interface type, programs, services, and IPsec metadata Possible rule actions Allow only Allow, block, bypass Group Policy Provided by ADM files Provided by a custom Group Policy extension support snap-in that is the same as the snap-in used to configure local policy Remote N/A Using MMC snap-in, netsh, and application pro- management gramming interfaces (APIs) User interface and Control panel tool (CPL) MMC snap-in, CPL, and netsh tools and netsh APIs Public COM APIs Enhanced public COM APIs

Other enhancements include:

■ Integration with Internet Protocol Security (IPsec). This provides IPsec-aware firewall rules and simplifies the task of using IPsec to implement network protection strategies such as server and domain isolation and Network Access Protection (NAP). ■ An expanded set of firewall profiles. These take advantage of Windows Vista’s Network Location Awareness (NLA) feature to allow Windows Firewall to reconfigure itself depending on the categorization of connected networks it senses on the computer’s net- work interfaces. ■ Full support for IPv6.

Note While Windows Firewall CPL in Windows XP lets you allow exceptions by selecting a check box, technically an unchecked rule in the CPL results in a block rule.

Understanding the new features of Windows Vista’s Windows Firewall requires an under- standing of the underlying Windows Filtering Platform upon which Windows Firewall is based. It also requires an understanding of how Windows Service Hardening is implemented in Windows Vista to protect built-in network services. Chapter 27: Configuring Windows Firewall and IPsec 1085

Note While Windows Vista’s Windows Firewall supports stateful packet inspection, it does not support application-layer pluggable filters. This means. for example, that Windows Firewall cannot perform stateful inspection of HTTP traffic and can therefore not directly prevent root kit–based malware from being installed on a Windows Vista computer. Instead, other Windows Vista features provide malware protection, including User Access Control (UAC) and Windows Defender. For more information on protecting Windows Vista computers from malware, see Chapter 25, “Managing Client Protection.”

Multiple Firewalls Windows XP Service Pack 2 actually has three different firewalling (or network traffic fil- tering) technologies that you can separately configure, and which have zero interaction with each other:

■ Windows Firewall that was first introduced in Service Pack 2 ■ TCP/IP Filtering, which is accessed from the Options tab of the Advanced TCP/IP Properties sheet for the network connection ■ IPsec rules and filters, which you can create using the IPsec Security Policy Man- agement MMC snap-in

On top of this confusion, Service Pack 1 had a fourth network traffic filtering technology that you could use: the Routing and Remote Access Service (RRAS), which supported basic firewall and packet filtering. The problem, of course, is that when more than one of these firewalls is configured on a computer, one firewall can block traffic that another allows. As a result, network services might not work as expected, and verifying the configuration of each of these firewalls can make trouble- shooting a nightmare.

With Windows Vista however, IPsec filtering has been integrated with Windows Fire- wall; TCP/IP Filtering on the Options tab has been removed. This means that Windows Vista users have only one place to configure for both traffic filtering and network protec- tion, and the result is easier management and simplified troubleshooting.

Understanding the Windows Filtering Platform The Windows Filtering Platform (WFP) is an architectural component of Windows Vista that allows access to TCP/IP packets as they are being processed by Windows Vista’s Next Gener- ation TCP/IP Stack. WFP is a collection of public APIs that provide hooks into the networking stack and the underlying filtering logic upon which Windows Firewall is built. Independent software vendors (ISVs) can use WFP to develop third-party firewalls, network diagnostic software, , and other types of network applications. Using these APIs, a 1086 Part V: Networking

WFP-aware filtering application can access a packet at anywhere in the processing path to view or modify its contents (Figure 27-1).

Legacy Windows ISV IPsec Firewall Appa Policy Service

IKE/AuthIP

Base Filter Engine Local Policy and Settings Store User mode

Kernel mode

TLI Layer (TD1 & ALE ) IPsec Callout Steam Layer (HTTP/Sockets) Generic Filter Engine Transport Layer (TCP/UDP) 3rd Party Callouts for AV, IDS, NAT, Network etc. IPsec Layer Framer (IPv4/v6)

Figure 27-1 Simplified architecture of the new Windows Filtering Platform.

Note Third-party vendors and network application developers should utilize the WFP APIs only for filtering applications or security applications.

The main components of the WFP are:

■ Base Filter Engine (BFE) This component runs in user mode and receives filtering requests made by Windows Firewall, third-party applications, and the downlevel IPsec policy service. The BFE then plumbs the filters created by these requests into the kernel mode Generic Filter Engine. The BFE (bfe.dll) runs within a generic svchost.exe process. ■ Generic Filter Engine This component receives the filters plumbed from the BFE and stores them so that the different layers of the TCP/IP stack can access them. As the stack processes a packet, each layer the packet encounters calls the GFE to determine whether Chapter 27: Configuring Windows Firewall and IPsec 1087

the packet should be passed or dropped. The GFE also calls the various callout modules (defined next) to determine whether the packet should be passed or dropped. (Some callouts may perform an identical function, especially if multiple third-party firewalls are running concurrently.) The GFE (wfp.lib) is part of the kernel-mode Next Generation TCP/IP Stack (NetioTcpip.sys). ■ Callout Modules These components are used for performing deep inspection or data modification of packets being processed by the pack. Callout modules store additional filtering criteria that the GFE uses to determine whether a packet should be passed or dropped.

Note The BFE can support multiple clients simultaneously. This means that a third-party, WFP-aware application can interact with and even override Windows Firewall if so designed.

The APIs of the BFE are all publicly documented so that ISVs can create applications that hook into the advanced filtering capabilities of the Next Generation TCP/IP Stack in Win- dows Vista and Windows Server Code Name “Longhorn.” Some of the filtering features of the WFP are implemented using callouts, but most filtering is performed using static filters cre- ated by the BFE as it interacts with the Windows Firewall user interface and third-party appli- cations. These public APIs replace the downlevel COM APIs used by Windows Firewall in Windows XP Service Pack 2. The new public APIs are scriptable, but they have some limita- tions. For instance, they have no IPsec integration and do not allow discrimination between IPv4 and IPv6.

For more information about the Windows Filtering Platform, see http://msdn2.microsoft.com /en-us/library/aa366510.aspx on MSDN. You can find the Windows Filtering Platform API ref- erence at http://windowssdk.msdn.microsoft.com/en-us/library/aa364947.aspx.

Understanding Windows Service Hardening Windows Service Hardening (WSH) is a new feature of Windows Vista and Windows Server Code Name “Longhorn” that is designed to protect critical network services running on a sys- tem. If a service is compromised, WSH reduces the potential damage that can occur by reduc- ing the attack surface that could be potentially exploited by some forms of malicious code. Since network services (both those built into the operating system and those installed by third-party applications) are by their nature exposed to the network (which itself is usually connected to the Internet), they provide a vector by which attackers can try to compromise a system. WSH implements the following protection improvements over previous versions of :

■ Configuring services to run whenever possible within the lower-privileged LocalService or NetworkService context instead of the LocalSystem context favored by many services in previous versions of Windows. 1088 Part V: Networking

■ Implementing a new type of per-service security identifier (Service SID) that extends the Windows access control model to services and the system resources they access. When the service starts by the SCM, the SID is added to secondary SIDs list of the process token if the service opted for doing this. ■ Applying a write-restricted to the process for each service so that any attempt to access a system resource that does not have an explicit allow ACE for the Ser- vice SID will fail. ■ Tightening control over the generic svchost.exe grouping and distribution of services. ■ Reducing the number of privileges assigned to services to only those needed by the service.

Understanding Service SIDs

Service SIDs are of the form S-1-5-80-{SHA1 hash of short service name} and complement the existing set of user, group, machine, and special SIDs used by previous versions of Windows. Service SIDs are secondary SIDs that are added to the SIDs list of the service process token when the starts the service. The primary SID for a service is the built- in identity (LocalService, NetworkService, or LocalSystem) under which the service runs.

To have a Service SID added to its token, the service must first opt in to doing so. Opt in is nor- mally done by the operating system or application when the service is started. Administrators can manually opt in user-mode services by using the sc sidtype command, which can config- ure the Service SID as either UNRESTRICTED or RESTRICTED. For example, sc sidtype service_name restricted will add the Service SID for the service to its service process token and also make it a write-restricted token. This means, for example, that any registry key used by the service must be explicitly ACLed to allow the service to access it. For more information, type sc sidtype ? at a command prompt. To query the sidtype of a service, you can use the sc qssidtype command.

Some services in Windows Vista ship out of box as UNRESTRICTED, and most services will fail to start if changed to RESTRICTED. Third-party applications, such as antivirus software, can be designed to opt in to having Service SIDs and can be designed to run either RESTRICTED or UNRESTRICTED. If the local administrator changes an existing service SID type from UNDEFINED to UNRESTRICTED, she gets the service having SID type with prob- ably zero regression or issues with this service. (A SID type of UNRESTRICTED is sufficient for network traffic filtering.)

Note The service SIDs of all the configured services per process are always present in the process. Only the running services have their SIDs enabled; the SIDS of non-running services are there, but in a disabled state. However, for Windows Vista the filtering platform considers all SIDs to be activated, regardless of whether the service is in a disabled state. Chapter 27: Configuring Windows Firewall and IPsec 1089

Windows Firewall and Windows Service Hardening

You can use Service SIDs to restrict ways that services can interact with system objects, the file system, the registry, and events. For example, by ACLing the firewall driver object using Win- dows Firewall’s Service SID, this driver will only accept communication from the Windows Firewall service.

WSH also protects services by using rules similar to those used by Windows Firewall. These rules are called service restriction rules and are built into Windows Vista and can specify things such as which ports the service should listen on or which ports the service should send data over. An example of a built-in WSH rule might be “The DNS client service should send data only over port UDP/53 and should never listen on any port.” These rules add additional pro- tection to network services because network objects such as ports do not support ACLs. ISVs can extend this protection to third-party services they develop by using the public COM APIs for WSH, found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ics/ics/ inetfwservicerestriction.asp. However, WSH rules don’t actually allow traffic (assuming Win- dows Firewall is on); instead, they restrict the traffic that can be allowed to/from a service, regardless of the administrator-created firewall rules.

WSH rules are also merged into the filtering process performed when Windows Firewall decides whether to pass or drop a packet. In other words, Windows Firewall can detect when a service restriction rule is blocking traffic and drop packets accordingly, even if no corre- sponding firewall rule in the Windows Firewall With Advanced Security user interface applies to the traffic. For more information on how service restriction rules merge with Windows Fire- wall rules, see the section titled “Understanding Windows Firewall Policy Storage and Rule Merge Logic” later in this chapter.

Note An assumption behind WSH is that the services being protected are running under either the NetworkService or LocalService accounts. Services running under the LocalSystem account are omnipotent: They can turn off Windows Firewall or mock its rules on the fly and are therefore not protected.

Direct from the Source: Windows Firewall Stealth Windows Firewall comes with an always-on, non-configurable stealth feature. The pur- pose of this feature is to prevent fingerprinting attacks that remotely attempt to figure out which ports are open on the computer, which services are running, the patch state of the computer, and so on.

When a remote computer tries to connect to a non-listening TCP port (a TCP port that is not used on the local computer), the TCP/IP stack sends back a special TCP packet called TCP RESET (RST). However, if an application is listening on that port but a fire- wall is blocking it from receiving traffic, the remote computer will simply time out. This 1090 Part V: Networking

is a common technique to fingerprint the computer and see which ports are unused and which are used but blocked by the firewall. With the stealth feature of Windows Fire- wall, all TCP RST outbound packets are blocked so that the remote computer will time out when it connects to a port that is not allowed through the firewall, regardless of whether this port is in use.

For UDP ports and non-TCP/UDP sockets, a similar mechanism is used. Unlike TCP, these are not session-based protocols, so when a remote computer tries to connect to a non-listening UDP port (or a non-TCP/UDP socket) the stack replies back with an ICMP packet saying “nobody’s home.” For IPv4 traffic, the response is ICMPv4 (protocol 1)/ type 3/code 3 (Destination Unreachable/Port Unreachable) or ICMPv4 (protocol 1)/ type 3/code 2 (Destination Unreachable/Protocol Unreachable). For IPv6 UDP traffic, the response is ICMPv6 (protocol 58)/type 1.

With the stealth feature on, Windows Firewall blocks these outbound responses so that the remote computer can’t tell the difference between a non-listening UDP port (or non- TCP/UDP socket) and one that is listening but is blocked by the firewall.

Eran Yariv Windows Firewall and IPsec Management Development Lead

Understanding Windows Firewall Profiles The previous version of Windows Firewall in Windows XP Service Pack 2 use two kinds of profiles, only one of which can be active at any given time:

■ Domain profile This profile is active whenever a domain DNS suffix is present. The domain profile is usually configured to be the less restrictive profile. For example, the domain profile may have a rule enabled that allows incoming remote management traf- fic from a network management application such as Microsoft Operations Manager (MOM). ■ Standard profile This profile is active in all other circumstances. For instance, if the computer belongs to a workgroup instead of a domain, the standard profile will be active. Or, if the computer belongs to a domain, is multihomed, and has authenticated over its LAN interface—but it is also connected to an unmanaged wireless LAN using a Wi-Fi interface—the standard profile will again be active. Administrators usually config- ure the standard profile to be the most restrictive profile (though both profiles are the same out of the box). For example, when a laptop is disconnected from the corporate network and taken to a coffee shop where a wireless hotspot is present, the standard profile can provide greater protection for the computer if configured accordingly. The computer’s direct connection with the Internet makes this added protection necessary.

With Windows Vista, the number of profiles used by Windows Firewall has been expanded to three profiles, and the active profile at any given time is determined as follows: Chapter 27: Configuring Windows Firewall and IPsec 1091

■ Domain profile This profile is active only when the computer can authenticate with a domain controller on all active network interfaces (LAN, wireless, VPN, and so on). The domain profile may be more or less restrictive than the other two profiles depending on the management needs and security policy of the network. ■ Private profile This profile is active whenever the network type for all network active network connections on the computer are identified as Private networks. When a com- puter that is not joined to a domain connects to a new network for the first time, the user is presented with a choice of Home, Work, or Public for the type of network she is con- necting to. If the user selects Home or Work, the network type for the connection is set to Private; otherwise, the network type for the connection is set to Public. The private profile is generally less restrictive than the public profile because the computer is usu- ally on a home or SOHO network where it may be connected to the Internet using a NAT or other gateway device with its own built-in firewall. For example, the Windows Firewall rules for Network Discovery are allowed by default in the private profile so that users on a home or SOHO network can easily find each other’s computers on the net- work for file sharing and other purposes. The rules for Remote Assistance are likewise allowed by default in the private profile. ■ Public profile This profile is active in all other circumstances. For example, if a corpo- rate laptop is taken to a coffee shop where a wireless hot spot is present, the public pro- file will be active on the computer. The public profile is generally more restrictive than the private profile because the computer usually has a direct connection to the Internet in a location that isn’t secure. For example, the firewall rule group for Network Discov- ery is disabled by default in the public profile so that laptop users in a public place can avoid being discoverable by other computers connected to the same wireless access point. The rule group for Remote Assistance is likewise disabled by default in the public profile. (Traffic for these features not actually blocked explicitly—the firewall rule action is not Block. Instead, the rules in the rule group for Network Discovery and Remote Assistance are disabled, which has the effect of blocking the traffic. All traffic is blocked by default because rule groups are simply disabled.)

Note Public is the default network categorization, and classification as Public Location/ Other or bypassing the categorization dialog will result in the network being classified as pub- lic. For more information on network types (categories) in Windows Vista, see Chapter 26, “Configuring Windows Networking.”

Using the following algorithm offers another way to understand which Windows Firewall profile is active in Windows Vista at any given time:

1. If all active network interfaces can be securely authenticated with the domain, the pro- file is Domain. 1092 Part V: Networking

2. Otherwise, if all active network interfaces are either private or cannot be securely authenticated with the domain, the profile is Private. 3. Otherwise, the profile is Public.

Note Windows Firewall profiles also apply to Bluetooth interfaces if they are present on the computer—all network interfaces visible at the NDIS layer are also visible to Windows Firewall. If USB Remote NDIS (RNDIS) devices/networks identify themselves as terminated networks at driver install time they will not be categorized or affect the categorization algorithm. Instead, they are simply omitted. However, Windows Firewall still enforces its rules on their interfaces.

Windows Vista selects the active profile at any given time by using a feature called Network Location Awareness (NLA). NLA is a set of network APIs that sense the state of each con- nected network on the computer. NLA queries each network that the computer is connected to in order to determine three things:

■ The connectivity state of the network. For example, a network may be disconnected, connected to the local network only, or connected to the local network—and through it connected to the Internet. ■ The network connections or interfaces used to connect to the network. For example, a multihomed computer may have both network connections authenticating to the domain, or one domain-authenticated connection and one unsecured connection. ■ The network location type or category of the network. Network location types in Win- dows Vista can be Public, Private, or Domain.

NLA enables Windows Firewall to seamlessly switch between profiles as needed. For exam- ple, when a laptop on a corporate network is placed in standby mode, undocked from the net- work, and taken to a public hotspot off premises, NLA determines the network change that takes place when the computer resumes from standby and then switches the active profile for Windows Firewall from domain to public.

How It Works: Network Location Awareness The Network Location Awareness service (NLASVC) monitors the local computer for changes in its connectivity to connected networks. When a Windows Vista computer connects to a new network for the first time, the Network List Service assigns a globally unique identifier (GUID) to the new network. If the Network Location Awareness ser- vice later detects a change in network connectivity on the computer, the NLA service notifies the Network List Service, which then notifies Windows Firewall to indicate whether the active profile should be changed. If such a change is required, it generally occurs within 200 milliseconds. Chapter 27: Configuring Windows Firewall and IPsec 1093

Note Windows Firewall profiles are global and not per-interface. Only one profile can be active at any given time, even on multihomed computers with more than one network inter- face or type of interface.

For information on how to configure Windows Firewall profiles, see the section titled “Under- standing Windows Firewall Profiles” later in this chapter.

Understanding Windows Firewall Policy Storage and Rule Merge Logic Windows Firewall profiles contain the policy information (rules) that governs how Windows Firewall works on the computer. This policy information consists of inbound and outbound rules for normal traffic and connection security rules for IPsec traffic, together with Windows Firewall global settings. Profiles and their policy information are stored in several places:

■ Local Policy Store When a user with administrative privileges configures Windows Firewall settings on a computer, the resulting policy information is stored within the Windows Firewall local policy store. This store is found within the local registry hive on the computer. ■ Group Policy Object (GPO) In a domain environment, you can configure and maintain Windows Firewall settings in GPOs, which are stored in the SYSVOL share on domain controllers. ■ Group Policy Resultant Set of Policy (GP_RSoP) In a domain environment, GP_RSoP represents the cache of policies obtained from all domain controllers on which GPOs are linked to the organizational unit (OU) to which the computer belongs. This cache of policies is stored in the registry on the computers targeted by the GPOs.

In addition to these policy stores, Windows Firewall uses an additional policy store when determining whether to block or allow traffic. This additional store is where Windows Service Hardening (WSH) maintains its static and configurable service restriction rules; it is also located in the registry.

The Windows Firewall rule merging logic works like this:

1. Windows Firewall settings (firewall rules, connection security rules, and settings) are merged from the computer’s local store and the GP_RSoP store. In case of conflicts, the GP_RSoP store always wins. 2. Simultaneously, WSH rules act like a parallel firewall working side by side with Windows Firewall. The effect of this is always local and has no relationship with Group Policy. 3. The resulting Windows Firewall settings are then compared with the WSH rules with “block wins” as the final deciding factor. 1094 Part V: Networking

How It Works: Local Policy Store vs. LGPO The local policy store sits in the registry and contains the out-of-box settings and the policy dictated by the local admins. It’s there all the time, whether or not the computer is domain-joined. To manage the local settings, you can use netsh, scripts/COM APIs, the Windows Firewall Control Panel applet, or the MMC snap-in (from the Administra- tive Tools folder).

The Local-GPO store is a domain-only concept. Basically, when your computer joins a domain, it is subject to policy coming from multiple GPOs in a hierarchy. At the bottom of the hierarchy is one or more local GPOs that are stored on the local computer (in the registry) and affect only the local computer. By default, local GPOs are empty of any pol- icy. To manage the local GPO, you can use netsh (and point it to a GPO on the local host) or run gpedit.msc and drill down to the “Windows Firewall with Advanced Secu- rity” node. You can find more information at http://msdn.microsoft.com/library/en-us/ policy/policy/group_policy_hierarchy.asp.

Eran Yariv Windows Firewall and IPsec Management Development Lead

Understanding Windows Firewall Rules Windows Firewall includes three kinds of rules that you can configure:

■ Inbound rules These rules filter inbound traffic to the host and can either block or allow traffic based on specified conditions. ■ Outbound rules These rules filter outbound traffic from the host and can either block or allow traffic based on specified conditions. ■ Connection Security rules These rules can use IPsec to authenticate, sign (validate against tampering) and, optionally, encrypt traffic for different network protection scenarios.

Note For more information about connection security rules, see the section titled “Under- standing Connection Security Rules” later in this chapter.

How It Works: Firewall Rules vs. Connection Security Rules Firewall rules (also called inbound/outbound rules or block/allow rules) have similari- ties and differences with connection security rules. You can create and maintain both types of rules using the Windows Firewall With Advanced Security snap-in or Group Policy. However, while firewall rules are configured on the local computer and act uni- Chapter 27: Configuring Windows Firewall and IPsec 1095

laterally (independent of the remote computer), connection security rules must be con- figured on both the local and remote computer for IPsec to secure network traffic between them. Although firewall rules allow or prevent traffic from entering or leaving the local computer, they do not secure this traffic—you must create connection security rules to do this. And though creating a connection rule creates the potential to secure network traffic entering or leaving the local computer, it does not allow or prevent traffic from entering or leaving this computer—you must create firewall rules to do this.

In addition to these three basic rule types, Windows Firewall supports the following addi- tional types of rules:

■ Windows Service Hardening rules These outbound and inbound rules are available out- of-box (OOB) to protect the different network services in Windows Vista and the appli- cations that use them. WSH rules are configurable for third-party service providers. The biggest difference between Windows Firewall (inbound/outbound) rules and WSH rules is: ❑ Windows Firewall rules are created and managed by the computer or domain administrators to enforce a policy. ❑ WSH rules, on the other hand, are created and managed by Microsoft and ISVs, who install services on the computer with the purpose of sand-boxing their services so that they cannot be used as a stepping stone for network attacks. WSH rules are not visible to or managed by computer or Group Policy administrators.

■ Authenticated Bypass rules These inbound rules have been configured so that any traf- fic that specifically matches this rule will override any other rules that explicitly block this traffic. In other words, enabling authenticated bypass on an inbound rule means that the connection is allowed even if another rule is attempting to block the connec- tion. Authenticated bypass is not available for outbound rules and can be used to enable authenticated (IPsec) traffic to bypass Windows Firewall while blocking unauthenti- cated traffic with the same criteria. You can also use authenticated bypass to enable net- work scanners and intrusion-detection systems to run on Windows Vista and not have Windows Firewall block their functionality. A remote user (or more typically a group of domain users) and/or remote machine is a mandatory condition field in authenticated bypass rules. If this condition is not speci- fied, you end up with a regular allow rule (not an allow by-pass rule) that has some IPsec-related conditions in it. For allow by-pass rules, however, you must specify a remote machine or remote user. Note that only users and computer objects in the same Active Directory forest can be permitted. Authenticated bypass rules don’t work in work- group or untrusted environments. 1096 Part V: Networking

■ Default rules These are rules that specify the default behavior when traffic does not match any other type of rule. The default rules for all three profiles (domain, private, and public) are: ■ Block all inbound connections that do not match any other inbound rules. ■ Allow all outbound connections that do not match any other outbound rules.

The default rules for inbound and outbound connections can also be modified as follows:

■ The default rule for inbound traffic can be: ❑ Block (the default) ❑ Block All Connections ❑ Allow

Note From a practical standpoint, the default rule Block All Connections for inbound traffic means “shields up” or “ignore all allow and allow-bypass rules.”

■ The default rule for outbound traffic can be: ❑ Allow (the default) ❑ Block

Rules and Conditions

Windows Firewall can filter traffic based on a number of different conditions, as described in Table 27-2. (The generalized Windows Firewall rule is the logical AND of all these conditions.)

Table 27-2 Filtering Conditions for Windows Firewall Inbound/Outbound Rules Condition Possible values Protocol Any IANA IP protocol number TCP or UDP ICMPv4 or ICMPv6 Other protocols including IGMP, HOPOPT, GRE, IPv6-NoNxt, IPv6-Opts, VRRP, PGM, L2TP, IPv6-Route, IPv6-Frag Local port (for TCP and UDP only) All Ports Specific ports (comma-separated list) Dynamic RPC RPC Endpoint Mapper Edge Traversal Chapter 27: Configuring Windows Firewall and IPsec 1097

Table 27-2 Filtering Conditions for Windows Firewall Inbound/Outbound Rules Condition Possible values Remote port (for TCP and UDP All ports only) Specific ports (comma-separated list) ICMP Type Code (for ICMPv4 and All ICMP Types ICMPv6 Specific types of ICMP traffic Local IP address scope A specific IPv4 or IPv6 address or list of addresses A range of IPv4 or IPv6 addresses of list of ranges An entire IPv4 or IPv6 subnet or list of subnets Remote IP address scope A specific IPv4 or IPv6 address or list of addresses A range of IPv4 or IPv6 addresses or list of ranges An entire IPv4 or IPv6 subnet or list of subnets A predefined set of computers—including local subnet, de- fault gateway, DNS servers, WINS servers, or DNS servers—or a list of such items Interface type All interface types Local area network Remote access Wireless Programs All programs System, a special keyword that if used will restrict traffic to the System Process (This is useful for scoping traffic to any kernel mode driver such as http.sys, smb.sys, and so on.) Specify path and .exe name to program executable Services Apply to all programs and services Apply to services only Apply to a specified service or to a service with the specified short name

Note Windows Firewall rules can allow or block services regardless of where their executa- bles are located on the computer. Services can be specified by their service name, even if the service is implemented as a DLL. Programs are identified by specifying the application path. (Specifying DLLs is not supported.)

Note When creating and configuring rules in Windows Firewall, use scope wherever possi- ble. For example, if you do network backup and need to allow incoming connections from the backup service, configure the scope so that Windows Firewall only allows connections from the backup server’s IP address or network. Similarly, refine the scope for network management and remote administration tools to just those networks that require it. 1098 Part V: Networking

How It Works: Predefined Local Port Types There are three special, predefined local ports: Dynamic RPC, RPC Endpoint Mapper, and Edge Traversal:

■ Dynamic RPC This port is utilized by applications and services that receive dynamic RPC traffic over TCP. Applications or services that receive RPC traffic over named pipes do not use this port. ■ RPC Endpoint Mapper This port is used only with the RPCSS service. It allows traffic to the endpoint mapper. ■ Edge Traversal This port is only used with the iphlpsvc (Teredo) service. It allows the traffic that is to be decapsulated by the Teredo service on a dynamic port.

In addition to the conditions described in Table 27-2, if a rule is configured to allow secure connections only and a corresponding connection security rule (IPsec rule) exists for the users or computers specified in the rule, additional rule conditions are available for configu- ration, as shown in Table 27-3. Because of these additional configuration options, which inte- grate IPsec functionality with firewall rules, you can think of Windows Firewall rules in Windows Vista as “IPsec-aware” rules.

Table 27-3 Filtering Conditions for Windows Firewall Inbound/Outbound Rules When Allow Only Secure Connections Is Enabled for the Rule Condition Possible values Require encryption Optionally select or leave unselected Allow only connections from specified computers Select from Active Directory Allow only connections from specified users Select from Active Directory

Note An additional condition is the option to locally restrict rules to specific interfaces (not interface types). This is a local-only option available only via the APIs.

How It Works: Windows Firewall and Traditional Firewalls Windows Vista’s Windows Firewall is similar to traditional network firewalls in that you can create highly granular rules that filter traffic based on specified conditions. You can think of the collection of Windows Firewall rules as a database, with rules representing the different rows and conditions representing the columns. Once created, these rules can be either enabled or disabled depending on the requirements of the network.

A significant difference between Windows Firewall and traditional network firewalls, however, is that traditional firewalls allow you to create an ordered list of rules that are Chapter 27: Configuring Windows Firewall and IPsec 1099

then processed in order until a match occurs to allow or block traffic. Windows Firewall does not apply rule ordering in the way that traditional firewalls do.

In addition, Windows Firewall in Windows Vista is an authenticating firewall that inte- grates IPsec protection with traditional inbound/outbound filtering by enabling you to create connection security rules that authenticate and, optionally, encrypt traffic.

Examples of Rules

The kinds of firewall rules that you can configure using Windows Firewall in Windows Vista include:

■ Allow Microsoft Internet Explorer to send outbound traffic over TCP port 80. ■ Allow a specified application to receive inbound UDP traffic if it arrives over any wireless network interface. ■ Block the generic svchost.exe process that hosts the MPSSVC service for all inbound traffic from a specified remote address. ■ Allow the SSDP service to listen for inbound traffic from a specific interface, such as Local Area Connection 2.

For more information on configuring firewall rules, see the section titled “Managing Windows Firewall” in this chapter.

Direct from the Source: Using RPC with Windows Firewall RPC (Remote Procedure Call) is a common method for applications to receive traffic from the network, process it, and respond. RPC is very common in servers, whose role in part is to provide a service over the network for clients. Some primary examples are the Microsoft Exchange Server, Microsoft ISA server (for remote administration pur- poses), the Windows Fax service, and so on. RPC is even used in various scenarios for client computers. For example the Windows Firewall Remote Management feature, when enabled, works by having the PolicyAgent service use an RPC over TCP (RPC/ TCP) interface to answer remote management requests and proxy it locally to the Win- dows Firewall service. The purpose of this proxy approach is to keep the Windows Fire- wall service from directly accessing the network so that it can keep running in a secure, can’t-touch-the-network account.

RPC can use multiple transports to communicate over the network. The most common ones are RPC over named pipes (RPC/NP) and RPC over TCP/IP (RPC/TCP). RPC/NP is a less-recommended transport because it lacks features such as mutual authentication and requires the server side to open up for SMB traffic, which has such additional side effects as allowing file and printer share over the network. If a service is using RPC/NP 1100 Part V: Networking

to provide its interfaces to the network, you need to enable the built-in File and Printer Sharing group of rules for traffic to be allowed inbound.

There are two methods for RPC/TCP:

■ A fixed TCP port In this case, the port is usually known in advance to both the RPC server and client(s). The clients simply connect to the server using TCP with that port number. If you have an RCP server that uses RPC/TCP with a fixed port, all you need to do to allow traffic is add an “allow” firewall rule to that application/ service for that specific local TCP port. Using a fixed TCP port is not recom- mended because it lacks the flexibility of avoiding port collisions with other net- working applications. As a result, it’s a less common method for RPC/TCP; only a few services actually use it (such as the RPCSS service). ■ A dynamic TCP port In this case, the actual port that the RPC server uses to expose its RPC/TCP interface is determined at run time from a pool of available ports. Because the RPC clients can’t tell in advance which TCP port they need to connect to, they need to use a mediator in the form of the RPC end-point mapper. The process works like this: 1. Application App1 (the RPC server) starts running and registers its RPC inter- face with the RPC subsystem for dynamic RPC/TCP. 2. The RPC sub-system assigns a dynamic TCP port (denote port X) to that application and starts listening on port X from the process context of appli- cation App1. 3. The RPCSS service, which acts as an end-point mapper, listens for RPC end- point mapping requests on a fixed port: TCP/135. 4. The RPC client, from another computer, connects to TCP/135 and talks to the RPCSS service (the end-point mapper). 5. The RPC client asks for a specific RPC interface. The end-point-mapper, being part of the RPC subsystem, knows about steps (a) and (b) above and replies with port X. 6. The RPC client connects to port TCP/X and starts the interface activation with the RPC server.

As you can see, two firewall rules are necessary to enable dynamic RPC/TCP: ■ Allow the RPCSS service to receive traffic over TCP/135 for end-point mapping purposes. ■ Allow application App1 to receive traffic over TCP/X. Chapter 27: Configuring Windows Firewall and IPsec 1101

Two problems come to mind:

1. You want to enable the RPCSS service inbound traffic only if there are RPC servers registered on the computer. If there are none, TCP/135 should not be open in the firewall—this might expose the computer to unnecessary attacks. 2. You can’t tell in advance what port X is, and you can’t create a firewall rule to allow it.

To address the first problem, Windows Firewall uses a special local port keyword called RPC endpoint mapper. You can use this local port keyword when creating the “Allow the RPCSS service to receive traffic over TCP/135 for end-point mapping purposes” rule, replacing TCP/135 with the RPC endpoint mapper keyword. The Windows Firewall ser- vice keeps a special and secure interface with the RPCSS service. The RPCSS service noti- fies the Windows Firewall service whenever RPC servers are registered, and the Firewall Service dynamically replaces the keyword with the actual port value (in this case, TCP/ 135, but it could also be TCP/593 for RPC/HTTP cases). If no RPC servers are registered with the RPC subsystem, the Windows Firewall service does not open port TCP/135.

To address the second problem, Windows Firewall uses a special local port keyword called Dynamic RPC. When this keyword is used, Windows Firewall makes sure that the socket receiving the TCP traffic (port X in this example) was actually acquired by the RPC subsystem and is used for RPC purposes. Instead of a firewall rule that says “Allow application App1 to receive TCP traffic over any port,” you use the Dynamic RPC local port keyword to create this rule: Allow application App1 to receive TCP traffic for RPC purposes only.

Eran Yariv Windows Firewall and IPsec Management Development Lead

Rules Processing

When Windows Firewall inspects traffic to determine whether it should be allowed or blocked, the decision is made by ordered processing of rules by their action. Rules with the same action are bucketed together and have no specific ordering among themselves.

Windows Firewall rules processing works as follows:

1. Allow-bypass rules (rules that have IPsec conditions in them) 2. Block rules 3. Allow rules 4. The default inbound/outbound rules 1102 Part V: Networking

Note that the preceding description of rules processing applies only to block/allow rules and not to connection-security rules.

Note Block rules are evaluated before allow rules and therefore take precedence. However, you can use authenticated bypass to override block rules, as discussed in the next section.

For more information on how to configure Windows Firewall using Group Policy, see the sec- tion titled “Managing Windows Firewall Using Group Policy” later in this chapter.

Rule Groups

Windows Vista's Windows Firewall With Advanced Security console groups rules together into sets of rules called rule groups. A rule group is a collection of inbound/outbound rules that enable a particular experience or feature in Windows Vista. For example, the Remote Assistance rule group is a set of rules that enables the Remote Assistance feature to function. By enabling the rules within a specific rule group, the experience associated with that rule group can work transparently with respect to the Windows Firewall.

Rule groups are a management/UI concept only and they have no effect on the policy enforce- ment engine or on the processing of rules. Rule groups are there simply to support the notion of pre-canned rules which are pre-tested with a lot of built-in experiences, and the user just needs to click a check box in the firewall’s Control Panel applet to enable that experience. Rule group enablement and querying is also available through netsh and the APIs.

Table 27-4 describes all rule groups that are available in Windows Vista. While a particular rule group might be available for a certain SKU, it won't be displayed in the Windows Firewall With Advanced Security console if the specific Windows role or component associated with that rule group is not installed.

Table 27-4 Rule Groups Available in Windows Firewall Based on SKU Rule group Description SKU BITS Peercaching This feature allows Background Intelligent All SKUs Transfer Service (BITS) clients that are in the same subnet to locate and share files that are stored in the BITS cache. (Uses WSDAPI and RPC) Connect to a This feature enables users to connect to pro- Home Premium, Business, Network Projector jectors over wired or wireless networks to Enterprise and Ultimate only project presentations. (Uses WSDAPI) Core Networking The firewall rules that are part of Core Net- All SKUs working are required for reliable IPv4 and IPv6 connectivity. Chapter 27: Configuring Windows Firewall and IPsec 1103

Table 27-4 Rule Groups Available in Windows Firewall Based on SKU Rule group Description SKU Distributed This feature coordinates transactions that up- All SKUs Transaction date transaction-protected resources, such as Coordinator databases, message queues and file systems. File and Printer This feature is used for sharing local files and All SKUs Sharing printers with other users on the network. (Uses NetBIOS, SMB and RPC) Key Management This feature is used for machine counting Business, Enterprise and Service and license compliance in enterprise Ultimate only environments. This group exists only on Business SKUs. iSCSI Service This feature is used for connecting to iSCSI All SKUs target servers and devices. Media Center This feature allows Media Center Extenders to Home Premium and Extenders communicate with a computer running Win- Ultimate only dows Media Center. (Uses SSDP and qWave) Network Discovery This feature allows this computer to discover All SKUs other devices and be discovered by other de- vices on the network. (Uses Function Discovery Host and Publication Services, UPnP, SSDP, NetBIOS and LLMNR) Performance Logs This feature allows remote management of All SKUs and Alerts the Performance Logs and Alerts service. (Uses RPC) Remote This feature allows remotely manageable All SKUs Administration services to receive RPC traffic. (Uses Named Pipes and RPC) Remote Assistance This feature allows users of this computer to All SKUs request remote assistance from other users on the network. (Uses UPnP, SSDP and Teredo) Remote Desktop This feature is used for accessing the desktop Business, Enterprise and from a remote system. Ultimate only Remote Event Log This feature allows remote viewing and All SKUs Management management of the local event log. (Uses Named Pipes and RPC) Remote Scheduled This feature allows remote management of All SKUs Tasks Management the local task scheduling service. (Uses RPC) Remote Service This feature allows remote management of All SKUs Management local services. (Uses Named Pipes and RPC) Remote Volume This feature provides remote software and All SKUs Management hardware disk volume management. (Uses RPC) Routing and Remote This feature is used to allow incoming VPN All SKUs Access and RAS connections. 1104 Part V: Networking

Table 27-4 Rule Groups Available in Windows Firewall Based on SKU Rule group Description SKU SNMP Trap Receives trap messages generated by local or All SKUs remote Simple Network Management Proto- col (SNMP) agents and forwards the messages to SNMP management programs running on this computer. If this service is stopped, SNMP-based programs on this computer will not receive SNMP trap messages. If this service is disabled, any services that explicitly depend on it will fail to start. Windows This feature allows other computers to find All SKUs except Starter Collaboration and communicate with your computer using Computer Name the Peer Name Resolution Protocol. (Uses Registration Service SSDP and PNRP) Windows Firewall This feature allows remote management of All SKUs Remote the local Windows Firewall. (Uses RPC) Management Windows This feature allows remote management of All SKUs Management Windows by exposing a set of manageable Instrumentation components in a set of classes defined by the (WMI) Common Information Model (CIM) of the distributed management task force. (Uses DCOM) Windows Media This feature allows users to receive streaming Home Basic and Premium, Player media over UDP. Business, Enterprise and Ultimate Windows Media This feature enables users to share media over Home Basic and Premium, Player Network a network. (Uses UPnP, SSDP and qWave) Business, Enterprise and Sharing Service Ultimate Windows Meeting This feature is used for collaborating over a All SKUs except Starter Space network to share documents, programs or your desktop with other people. (Uses DFSR and P2P) Windows Peer to This feature is required to enable various peer- All SKUs except Starter Peer Collaboration to-peer programs and technologies. (Uses Foundation SSDP and PNRP) Windows Remote This feature allows remote management of All SKUs Management the system via WS-Management, a web services-based protocol for remote manage- ment of operating systems and devices. Wireless Portable This feature allows the transfer of media from Home Basic and Premium, Devices your network enabled camera or media device Business, Enterprise and to your computer using the Media Transfer Ultimate Protocol (MTP). (Uses UPnP and SSDP) ActiveSync Windows Mobile-based device connectivity Optional component Chapter 27: Configuring Windows Firewall and IPsec 1105

Table 27-4 Rule Groups Available in Windows Firewall Based on SKU Rule group Description SKU Digital Cable This feature allows device discovery and video Optional component Receiver Device streaming from the cable receiver device to the PC. (Uses UPnP and SSDP) Internet Connection This feature allows this computer to share its Optional component Sharing internet connection with other computers on a private network. (Uses UPnP and SSDP) SNMP Service This feature allows Simple Network Manage- Optional component ment Protocol (SNMP) traffic to be sent and received by this computer. TCP/IP Print Server Opens the default port used by the Line Print- Optional component er Daemon protocol. Telnet Server This feature allows remote telnet clients to Optional component connect to this computer. Telnet Server This feature allows the local telnet server to be Optional component Remote remotely managed. (Uses DCOM and RPC) Administration World Wide Web Enables / Disables firewall rules for World Optional component Services (HTTP) Wide Web Services HTTP Secure World Wide Enables / Disables firewall rules for Secure Optional component Web Services World Wide Web Services HTTPS (HTTPS) FTP Server Enables / Disables firewall rules for FTP Server Optional component Services for NFS, Rules to allow inbound and outbound UDP Optional component Client for NFS and TCP traffic for Services for NFS, Client for NFS

Note In order to remotely manage Windows XP SP2 computers that have Windows Firewall enabled, an exception for remote administration needed to be opened in the firewall on these machines. This could be done by enabling the “Windows Firewall: Allow remote administration exception” Group Policy setting for Windows XP SP2 machines in the targeted OU. Windows Vista computers that have Windows Firewall enabled, however, can be managed remotely without the need of first opening an exception to allow for remote administration. If you are managing Group Policy from a Windows Vista computer in a mixed Windows Vista/Windows XP SP2 environment, you can enable the Remote Administration exception on targeted Win- dows XP SP2 computers by enabling the rules in the Remote Administration rule group using Windows Firewall with Advanced Security.

Rule groups as viewed within the Windows Firewall With Advanced Security snap-in corre- spond closely to exceptions on the Exceptions tab of the Windows Firewall CPL properties in Control Panel. For example, the Windows Firewall CPL exception named Remote Desktop corresponds to the Remote Desktop rule group in Table 27-4 above, and enabling this excep- tion in the Windows Firewall CPL enables the rules in this rule group in the Windows Fire- 1106 Part V: Networking

wall With Advanced Security snap-in (but only for the current firewall profile). For more information on configuring rules using the Windows Firewall With Advanced Security snap- in, see the section titled “Managing Windows Firewall Using the Windows Firewall With Advanced Security Snap-In” in this chapter.

Note For simplicity, the Windows Firewall CPL only applies to the current profile. Enabling an exception using this CPL will only enable it for the current profile. If rule X is marked for the public and private profile, the current profile is public, and the user checks rule X in the CPL, the CPL will split that rule into rule X (public) which is active and rule X (private, with the same name and conditions) which is inactive.

Not all rule groups have both inbound and outbound rules. For example, rule groups for remote management such as Remote Administration and Remote Event Log Management do not have outbound rules since remote management depends on the computer being managed being able to listen for traffic initiated by a central management station. Table 27-5 lists the available rule groups and whether they have inbound rules only, outbound rules only, or rules for both inbound and outbound traffic.

Table 27-5 Rule Groups and Whether They Have Inbound Rules, Outbound Rules, or Both Rule group Inbound rules Outbound rules BITS Peercaching ✔✔ Connect to a Network Projector ✔✔ Core Networking ✔✔ Distributed Transaction Coordinator ✔✔ File and Printer Sharing ✔✔ iSCSI Service ✔✔ Media Center Extenders ✔✔ Network Discovery ✔✔ Performance Logs and Alerts ✔ Remote Administration ✔ Remote Assistance ✔✔ Remote Desktop ✔ Remote Event Log Management ✔ Remote Scheduled Tasks Management ✔ Remote Service Management ✔ Remote Volume Management ✔ Routing and Remote Access ✔✔ SNMP Trap Service ✔ Windows Collaboration Computer Name ✔✔ Registration Service Chapter 27: Configuring Windows Firewall and IPsec 1107

Table 27-5 Rule Groups and Whether They Have Inbound Rules, Outbound Rules, or Both Rule group Inbound rules Outbound rules Windows Firewall Remote Management ✔ Windows Management Instrumentation (WMI) ✔✔ ✔✔ Windows Media Player Network Sharing Service ✔✔ Windows Meeting Space ✔✔ Windows Peer to Peer Collaboration Foundation ✔✔ Windows Remote Management ✔ Wireless Portable Devices ✔✔ Rule Groups Enabled By Default

In a default install of Windows Vista, most rule groups are disabled in most profiles to reduce the attack surface. However, you can develop custom installation images that enable selected rule groups by default. For more information on building custom images of Windows Vista see Part 1 of this book, “Deployment.”

Table 27-6 lists the rule groups that are enabled by default for each profile. Users who are local administrators on their computers can enable additional rule groups, provided that Group Policy does not prevent them from doing so.

Table 27-6 Rule Groups Enabled by Default for Each Profile Rule group Domain Private Public Core Networking Yes Yes, except for Group Yes, except for Group Policy Policy Network Discovery No Yes No Remote Assistance Yes Yes No All other rule groups No No No

Core Networking Rules

Core Networking Rules is the only rule group that is enabled by default in all three profiles. These rules are designed to allow reliable communications using IPv4 and IPv6 and should generally not be modified or disabled. Core Networking Rules includes inbound/outbound rules for the following networking capabilities:

■ DHCP Rules for allowing stateful auto-configuration using DHCP messages. ■ DNS Rules to allow DNS traffic. ■ Group Policy Rules to allow Group Policy updates to occur on the computer. This is enabled for only the Domain profile. 1108 Part V: Networking

■ ICMPv4 Rules to allow destination unreachable and fragmentation needed error messages. ■ ICMPv6 Rules for allowing router advertisements, router solicitation messages, neigh- bor discovery advertisements, neighbor discovery solicitation messages, multicast lis- tener query messages, multicast listener report messages, multicast listener done messages, and various ICMPv6 error messages including destination unreachable, packet too big, time exceeded, and parameter problem. ■ IGMP Multicast Rules to allow IGMP messages to enable the computer to create, join or leave a multicast group. ■ ISATAP/6to4 Tunneling Rules to allow traffic for ISATAP and 6to4 tunneling. ■ Teredo (IPv6 Edge Traversal) Rules for allowing Teredo edge traversal across a NAT.

Note The rules for enabling Group Policy processing and outbound DNS traffic that are part of Core Networking Rules are available and enabled only in the domain profile. These rules were designed so that if an administrator decides to push a policy via Group Policy that changes the default outbound action from Allow to Block, the computer will still be able to get Group Policy. and every single system will not need to be manually reconfigured afterward. In other words, these rules are a safety mechanism to prevent admins from being unable to push further policies. All other rules in the Core Networking Rules rule group are available and enabled in all three profiles: domain, private, and public.

Direct from the Source: Loose-Source-Mapping vs. Strict-Source-Mapping for Firewall Filtering and Its Use for DNS Lookups In the TCP protocol, a session is established between two communicating computers. A third computer cannot ‘join’ an existing session. In UDP and portless protocols there is no session semantics. Once an outbound packet is sent, the firewall engine is creating a virtual session allowing inbound responses for that packet within a timeout (60 seconds).

In Windows XP and Windows Server 2003, Windows Firewall was using what is called as a Loose-Source-Mapping (LSM) policy. LSM means that inbound non-TCP responses need only match the protocol and ports of the outbound request to be allowed in. Prac- tically in LSM you can send an outbound UDP request (e.g. for DNS lookups sent to your primary DNS server) and receive the UDP response from another server (e.g. one of your secondary DNS servers) and that response would be allowed by the Firewall.

In Windows Vista, Windows Firewall moved to a Strict-Source-Mapping policy (SSM). In SSM, the remote IP address is also matched in the non-TCP responses and if it’s not the same the request was sent to, the inbound packet gets dropped. This change was done to increase the security of multiple protocols and reduce the chances of several spoofing and poisoning attacks. Chapter 27: Configuring Windows Firewall and IPsec 1109

The only exception to the SSM policy in Windows Vista is for DNS lookups. One of the core networking outbound firewall rules (“CoreNet-DNS-Out-UDP”) is set up in a spe- cial way to allow the UDP responses to arrive from any IP address (apply the LSM policy model for that rule). This special way to configure outbound rules for LSM/SSM is cur- rently not exposed in Windows Firewall in Vista and might be exposed in future ver- sions of the operating system.

The DNS client service also applies some special restrictions which are new to Windows Vista. It ignores DNS responses from remote IP addresses which are not in the DNS servers list.

Eran Yariv Windows Firewall and IPsec Management Development Lead

Tables 27-7 through 27-14 provide a detailed look at the rules that make up the Core Net- working Rules rule group. Some notes concerning these tables are:

■ The scope for all of these rules is any local or remote IP address. ■ The program or service associated with each rule is System unless otherwise specified. ■ These are all Allow rules (no Block rules). ■ Override is No for all inbound rules. ■ Local and remote port is Any unless otherwise specified.

Table 27-7 Core Networking Rules for DHCP Protocol / Protocol / Rule name Rule description local port remote port Direction Core Networking – Dynamic Allows DHCP messages UDP/67 UDP/68 Inbound Host Configuration Protocol for stateful auto- (DHCP-In) configuration Core Networking – Dynamic Allows DHCP messages UDP/68 UDP/67 Outbound Host Configuration Protocol for stateful auto- (DHCP-Out) configuration

Table 27-8 Core Networking Rules for DNS Protocol / Binary Rule name Rule description remote port Direction (service) Core Networking – DNS Outbound rule to allow UDP/53 Outbound svchost.exe (UDP-Out) DNS requests [UDP 53] (dnscache) 1110 Part V: Networking

Table 27-9 Core Networking Rules for Group Policy Protocol / Binary Rule name Rule description remote port Direction (service) Core Networking – Outbound rule to allow TCP/445 Outbound System Group Policy SMB traffic for Group Policy (NP-Out) updates [TCP 445] Core Networking – Outbound rule to allow TCP/* Outbound svchost.exe Group Policy remote RPC traffic for (TCP-Out) Group Policy updates Core Networking – Outbound rule to allow TCP/* Outbound lsass.exe Group Policy remote LSASS traffic for (LSASS-Out) Group Policy updates [TCP]

Table 27-10 Core Networking Rules for ICMPv4 ICMP Rule name Rule description type/code Direction Core Networking – Destination Unreachable error messages 3:4 Inbound Destination Unreachable are sent from any node that a packet Fragmentation Needed traverses that is unable to forward the (ICMPv4-In) packet for any reason except congestion.

Table 27-11 Core Networking Rules for ICMPv6 ICMP Rule name Rule description type/code Direction Core Networking - Destination Unreachable error messages 1:* Inbound Destination Unreachable are sent from any node that a packet (ICMPv6-In) traverses that is unable to forward the packet for any reason except congestion. Core Networking - Packet Packet Too Big error messages are sent 2:* Inbound Too Big (ICMPv6-In) from any node that a packet traverses that is unable to forward the packet because the packet is too large for the next link. Core Networking - Packet Packet Too Big error messages are sent 2:* Outbound Too Big (ICMPv6-Out) from any node that a packet traverses that is unable to forward the packet because the packet is too large for the next link. Core Networking - Time Time Exceeded error messages are 3:* Inbound Exceeded (ICMPv6-In) generated from any node that a packet traverses if the Hop Limit value is decremented to zero at any point on the path. Core Networking - Time Time Exceeded error messages are 3:* Outbound Exceeded (ICMPv6-Out) generated from any node that a packet traverses if the Hop Limit value is decremented to zero at any point on the path. Chapter 27: Configuring Windows Firewall and IPsec 1111

Table 27-11 Core Networking Rules for ICMPv6 ICMP Rule name Rule description type/code Direction Core Networking - Parameter Problem error messages are 4:* Inbound Parameter Problem sent by nodes as a result of incorrectly (ICMPv6-In) generated packets. Core Networking - Parameter Problem error messages are 4:* Outbound Parameter Problem sent by nodes as a result of incorrectly (ICMPv6-Out) generated packets. Core Networking – Router Solicitation messages are sent by 133:* Outbound Router Solicitation nodes seeking routers to provide stateless (ICMPv6-Out) auto-configuration. Core Networking - Router Advertisement messages are sent 134:* Inbound Router Advertisement by routers to other nodes for stateless (ICMPv6-In) auto-configuration. Core Networking - Router Advertisement messages are sent 134:* Outbound Router Advertisement by routers to other nodes for stateless (ICMPv6-Out) auto-configuration. Core Networking - Neighbor Discovery Solicitation messages 135:* Inbound Neighbor Discovery are sent by nodes to discover the link-lay- Solicitation (ICMPv6-In) er address of another on-link IPv6 node. Core Networking - Neighbor Discovery Solicitation messages 135:* Outbound Neighbor Discovery are sent by nodes to discover the link-lay- Solicitation (ICMPv6-Out) er address of another on-link IPv6 node. Core Networking - Neighbor Discovery Advertisement 136:* Inbound Neighbor Discovery messages are sent by nodes to notify Advertisement other nodes of link-layer address changes (ICMPv6-In) or in response to a Neighbor Discovery Solicitation request. Core Networking - Neighbor Discovery Advertisement 136:* Outbound Neighbor Discovery messages are sent by nodes to notify Advertisement other nodes of link-layer address changes (ICMPv6-Out) or in response to a Neighbor Discovery Solicitation request. Core Networking – An IPv6 multicast-capable router uses the 130:* Inbound Multicast Listener Query Multicast Listener Query message to que- (ICMPv6-In) ry a link for multicast group membership. Core Networking - An IPv6 multicast-capable router uses the 130:* Outbound Multicast Listener Query Multicast Listener Query message to que- (ICMPv6-Out) ry a link for multicast group membership. Core Networking - The Multicast Listener Report message 131:* Inbound Multicast Listener Report is used by a listening node to either (ICMPv6-In) immediately report its interest in receiving multicast traffic at a specific multicast address or in response to a Multicast Listener Query. 1112 Part V: Networking

Table 27-11 Core Networking Rules for ICMPv6 ICMP Rule name Rule description type/code Direction Core Networking - The Multicast Listener Report message 131:* Outbound Multicast Listener Report is used by a listening node to either (ICMPv6-Out) immediately report its interest in receiving multicast traffic at a specific multicast address or in response to a Multicast Listener Query. Core Networking - Multicast Listener Report v2 message 143:* Inbound Multicast Listener Report is used by a listening node to either v2 (ICMPv6-In) immediately report its interest in receiving multicast traffic at a specific multicast address or in response to a Multicast Listener Query. Core Networking - Multicast Listener Report v2 message 143:* Outbound Multicast Listener Report is used by a listening node to either v2 (ICMPv6-Out) immediately report its interest in receiving multicast traffic at a specific multicast address or in response to a Multicast Listener Query. Core Networking - Multicast Listener Done messages inform 132:* Inbound Multicast Listener Done local routers that no members remain for (ICMPv6-In) a specific multicast address on the subnet. Core Networking - Multicast Listener Done messages inform 132:* Outbound Multicast Listener Done local routers that no members remain for (ICMPv6-Out) a specific multicast address on the subnet.

Table 27-12 Core Networking Rules for IGMP Multicast Rule name Rule description Protocol Direction Networking – Internet IGMP messages are sent and received by 2 Inbound Group Management nodes to create, join, and depart multicast Protocol (IGMP-In) groups. Networking – Internet IGMP messages are sent and received by 2Outbound Group Management nodes to create, join, and depart multicast Protocol (IGMP-Out) groups.

Table 27-13 Core Networking Rules for ISATAP/6to4 Tunneling Rule name Rule description Protocol Direction Core Networking – Inbound rule required to permit IPv6 traffic 41 Inbound IPv6 (IPv6-In) for ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) and 6to4 tunneling services Core Networking – Inbound rule required to permit IPv6 traffic for 41 Outbound IPv6 (IPv6-Out) ISATAP and 6to4 tunneling services Chapter 27: Configuring Windows Firewall and IPsec 1113

Table 27-14 Core Networking Rules for Teredo (Edge Traversal) Protocol / Binary Rule name Rule description local port Direction (service) Core Networking – Inbound UDP rule to allow UDP/$TEREDO Inbound svchost.exe Teredo (UDP-In) Teredo edge traversal, a (iphlpsvc) technology that provides ad- dress assignment and auto- matic tunneling for unicast IPv6 traffic when an IPv6/ IPv4 host is located behind an IPv4 network address translator Core Networking – Inbound UDP rule to allow UDP Outbound svchost.exe Teredo (UDP-Out) Teredo edge traversal, a (iphlpsvc) technology that provides ad- dress assignment and auto- matic tunneling for unicast IPv6 traffic when an IPv6/ IPv4 host is located behind an IPv4 network address translator.

Note For detailed information concerning rules for other rule groups, open the Windows Firewall With Advanced Security snap-in and filter to display the rules for that rule group.

Windows Firewall and the Startup Process

When a Windows Vista computer starts up, boot-time filters are applied to all network inter- faces to reduce the attack surface prior to the Windows Firewall service (MpsSvc) starting. The boot-time filters:

■ Block all unsolicited inbound traffic to the computer. ■ Allow all inbound DHCP traffic. (The ports are restricted as shown in Table 27-7.) ■ Allow inbound ICMPv6 Type 135:* Neighbor Discovery traffic. ■ Allow all outbound traffic. ■ Block outbound TCP Resets. ■ Block outbound ICMPv6 Type 1:3 and ICMPv4 Type 3:3 Destination Unreachable / Port Unreachable error messages.

Once the BFE has initialized, Windows switches to using persistent filters until MpsSvc starts. These persistent filters are identical in policy to the boot-time filters. Once MpsSvc starts, Windows Firewall policy is processed and applied to the computer. For more information on persistent filters, see the sidebar titled “Windows Firewall and Boot-Time Filtering” that fol- lows. 1114 Part V: Networking

Direct from the Source: Windows Firewall and Boot-Time Filtering A new Windows Vista platform service called Windows Filtering Platform (WFP) per- forms Windows Firewall’s filtering. Firewall rules and settings are implemented via three types of WFP filter:

■ Boot-time filters These filters are in effect from the time the TCP/IP stack starts until the BFE service starts. Once the BFE starts, these filters are removed. ■ Persistent filters These filters are stored persistently in the BFE service (in the reg- istry) and applied while the BFE is running. ■ Dynamic filters These filters are not persistent and are associated with an active API session. Once the session ends, these filters are automatically removed.

This is what happens during Windows Vista startup:

1. The computer starts up. There’s no networking yet. 2. The TCP/IP stack starts up and starts the WFP driver (netio.sys). 3. Networking starts and the WFP boot-time filters are in effect. 4. The BFE service starts: Persistent filters replace the boot-time filters. 5. The Firewall Service starts, adding the current policy rules and settings (as filters) based on the current profile.

The boot-time filters (step 3) and the persistent filters (step 4) are identical and contain the following:

■ Block all unsolicited inbound traffic. ■ Allow inbound loopback traffic. ■ Allow inbound ICMPv6 neighbor discovery (AKA neighbor solicitation), which is used for mapping IPv6 addresses to the MAC address (equivalent of ARP in IPv4).

These filters are present at all times and are of low priority. Higher-priority filters mask out these filters when Windows Firewall policy is in effect (step 5). When Windows Firewall is disabled, the WFP boot-time and persistent filters are removed. If Windows Firewall is enabled but the Windows Firewall service is stopped or killed, the dynamic filters are automatically removed and you end up with the persistent filters, which in effect block all inbound traffic.

Eran Yariv Windows Firewall and IPsec Management Development Lead Chapter 27: Configuring Windows Firewall and IPsec 1115

Upgrading Windows Firewall

When a Windows XP Service Pack 2 computer is upgraded to Windows Vista, all existing Windows Firewall settings are preserved. For more information on performing upgrades, see Part 1 of this book, “Deployment.”

Note Windows PE 2.0—a bootable deployment tool that you can use for installation and troubleshooting purposes—includes full Windows Firewall functionality.

Understanding IPsec Integration A major enhancement of Windows Firewall in Windows Vista is the integration of IPsec pro- tection with firewall filtering. In addition, processing and creating IPsec policy Windows Vista has been updated to reduce the number of rules necessary to create a practical IPsec policy. These policy-engine enhancements include simplified policy, AuthIP, new crypto algorithms, and other features described in the following sections.

Note Both the IPsec service (PolicyAgent) and the Windows Firewall service (MpsSvc) are based upon and supported by the Windows Filtering Platform.

In the previous Windows XP Service Pack 2 client platform (and in Windows Server 2003 Ser- vice Pack 1), configuring firewall settings and creating IPsec filters are done entirely indepen- dently of each other. This approach caused several issues:

■ Conflicting filtering settings could be configured for Windows Firewall and IPsec, resulting in traffic being blocked when it should be allowed. In addition, the fact that fil- tering was configured in several places using different tools made troubleshooting such conflicts challenging. ■ Using IPsec to protect internal server-to-server traffic and isolate servers from rogue cli- ents involved creating and maintaining dozens or even hundreds of IPsec filters or rules. Additionally, using IPsec to protect client-to-domain controller traffic was almost impos- sible to configure and maintain because of bootstrap issues, among others. As a result, until today many enterprises have been reluctant to use IPsec internally to enhance the protection of their corporate networks because of the complexity, time, and labor involved.

In Windows Vista, however, updates to the IPsec policy integration and the integration of IPsec into Windows Firewall greatly simplify the creation and maintenance of IPsec filters and rules for implementing IPsec policy on the computer for different network protection scenar- ios. Instead of creating IPsec filters and rules using the IPsec Security Policy Management snap-in, the administrator can now create connection security rules using the Windows Fire- 1116 Part V: Networking

wall With Advanced Security snap-in (the same tool used to create Windows Firewall rules) to configure IPsec policy protection on the computer. The Windows Firewall With Advanced Security snap-in thus becomes the central tool for managing both firewall rules and IPsec pol- icy on the computer.

Note The IPsec Security Policy Management snap-in is still included with Windows Vista for compatibility with downlevel Windows IPsec implementations.

New IPsec Features in Windows Vista

In addition to the new user interface for managing IPsec policy, which lets you easily create connection security rules, Windows Vista IPsec enhancements include:

■ New encryption and data integrity algorithms, credential types, and authentication methods. ■ AuthIP, an enhanced version of the Internet Key Exchange (IKE) protocol used for nego- tiating security associations to secure Authentication Header (AH) and Encapsulating Security Payload (ESP) traffic. ■ Negotiation Discovery, a new method of determining whether a peer is configured for IPsec protection. When configured to use IPsec, a Windows Vista client sends simulta- neous outbound packets e.g. one IKE negotiation packet, one unsecured packet when initiating a connection and through this process is able to discovery whether or not a peer is able to negotiate the use of IPsec security. This allows administrators to deploy more simplified IPsec policies which ease administrative overhead and reduce policy complexity. ■ Support for NIST Common Criteria (CC) compliance by enabling Windows Firewall to log audit events to the Security event log in addition to the default firewall log. ■ Domain IPsec policy is now fully integrated with Group Policy and is stored in policy (.pol) files in Sysvol instead of in the IPsec container in Active Directory. This makes it easier to manage firewall (block/allow) rules and IPsec filters and rules in a domain environment using Group Policy. Also, IPsec policy inherits from the dynamic per-pro- file approach of Windows Firewall. In other words, you can have different IPsec policies for each of the three profiles.

Most of these features are discussed further in the following sections. For information con- cerning general IPsec concepts and how to implement IPsec on different Windows platforms, see http://www.microsoft.com/technet/itsolutions/network/ipsec/default.mspx on Microsoft TechNet. Chapter 27: Configuring Windows Firewall and IPsec 1117

New Cryptographic Algorithms for IPsec Key Exchange, Data Integrity, and Encryption

Support for the following cryptographic algorithms has been added in Windows Vista:

■ AES-128 encryption ■ AES-192 encryption ■ AES-256 encryption both in main mode and quick mode ■ ECC-256 and ECC-384 for Diffie-Hellman in main mode

Tables 27-15 and 27-16 summarize the encryption and data integrity algorithms supported for IPsec in Windows Vista, listed in order of decreasing cryptographic strength.

Table 27-15 Encryption Algorithms Supported for IPsec in Windows Vista Algorithm Description AES-256 Provides the strongest security Highest level of resource usage Compatible with Windows Vista or later only AES-192 Less security and resource usage than AES-256 Compatible with Windows Vista or later only AES-128 Less security and resource usage than AES-192 Compatible with Windows Vista or later only 3DES Less secure than AES-128 but stronger than DES Supported by IPsec in Windows XP and Windows Server 2003 DES Least secure method and provided for backward compatibility reasons only (not recommended)

Table 27-16 Data Integrity Algorithms Supported for IPsec in Windows Vista Algorithm Description SHA1 Supported by IPsec in Windows Vista and also in Windows XP and Windows Server 2003 Stronger than MD5 and uses slightly more resources MD5 Least secure method and provided for backward compatibility only (not recommended)

When negotiating IPsec Key Exchange (also known as Main Mode) in Windows Vista, the fol- lowing encryption and data integrity algorithms are tried in the following order under the default IPsec configuration:

1. AES-128 for encryption and SHA1 for data integrity 2. 3DES for encryption and SHA1 for data integrity 1118 Part V: Networking

By comparison, when negotiating IPsec Key Exchange on the downlevel Windows XP and Windows Server 2003 platforms, the following algorithms are tried in order under the default IPsec configuration:

1. 3DES for encryption and SHA1 for data integrity 2. 3DES for encryption and MD5 for data integrity 3. DES for encryption and SHA1 for data integrity 4. DES for encryption and MD5 for data integrity

Note The new defaults in Windows Vista for Key Exchange (Main Mode) negotiation are backward-compatible with the old defaults on downlevel Windows platforms. Only the default crypto sets have been changed in Windows Vista; the algorithms specified in the defaults are used only if you create a connection security rule.

The following methods of data protection (also know as Quick Mode) are tried in order by Windows Vista to secure network traffic using IPsec:

■ Order of methods tried when data integrity only is configured (no encryption): 1. ESP using SHA1 for integrity 2. AH using SHA1 for integrity ■ Order of methods tried when both data integrity and encryption are configured: 1. ESP using SHA1 for integrity and AES-128 for encryption 2. ESP using SHA1 for integrity and 3DES for encryption By comparison, the following data protection methods are tried in turn by Windows XP and Windows Server 2003 to secure network traffic using IPsec:

1. ESP using SHA1 for integrity and 3DES for encryption 2. ESP using MD5 for integrity and 3DES for encryption 3. ESP using SHA1 for integrity and DES for encryption 4. ESP using MD5 for integrity and DES for encryption 5. AH using SHA1 for integrity only 6. AH using MD5 for integrity only

Note The new defaults in Windows Vista for data protection (Quick Mode) negotiation are backward-compatible with the old defaults on downlevel Windows platforms. Only the default crypto sets have been changed in Windows Vista. Chapter 27: Configuring Windows Firewall and IPsec 1119

Table 27-17 summarizes the key exchange algorithms that IPsec can use in Windows Vista, listed in order of decreasing cryptographic strength.

Table 27-17 Key Exchange Algorithms Available in Windows Vista Algorithm Description Elliptic Curve Diffie-Hellman P-384 Provides the strongest security Highest level of resource usage Compatible with Windows Vista or later only Elliptic Curve Diffie-Hellman P-256 Less security and resource usage than P-384 Compatible with Windows Vista or later only Diffie-Hellman Group 14 Stronger than the Group 2 used in Windows XP and Windows Server 2003 Diffie-Hellman Group 2 Supported by IPsec in Windows Vista and also in Windows XP and Windows Server 2003 Diffie-Hellman Group 1 Provided for backward compatibility only

New Credential Types for IPsec Authentication

In addition to the default Computer ( v5 or NTLMv2), Computer (Certificate), and preshared key credential types used for IPsec authentication in previous versions of Windows, support for the following credential types has been added in Windows Vista:

■ User (Kerberos v5) Uses Kerberos v5 to authenticate a user account found in Active Directory. ■ Computer and User (Kerberos v5) Uses Kerberos v5 to authenticate both a user account and a computer account found in Active Directory. ■ User (NTLMv2) Uses NTLMv2 to authenticate a user account found in Active Directory if Kerberos cannot be used. ■ User (Certificate) Uses a certificate from a trusted Certificate Authority (CA) to authen- ticate a user account. ■ Computer (Health Certificate) Uses a NAP health certificate from a trusted CA to authenticate a computer account.

Note Computer and User (Kerberos v5) is actually not a separate credential type, but a com- bination of Computer (Kerberos v5), which is supported by IPsec on the downlevel Windows XP and Windows Server 2003 platforms, and User (Kerberos v5), which is new to Windows Vista. In fact, in Windows Vista you can specify any supported IPsec credential types in a com- bination of up to two credentials, as explained later in the chapter. This chaining of credentials is another key IPsec feature new to Windows Vista. 1120 Part V: Networking

Note If you plan to use certificates for IPsec authentication, see Knowledge Base article KB922706 at http://support.microsoft.com/default.aspx/kb/922706 for information about how to use Windows Server 2003 Certificate Services web enrollment pages together with Microsoft Windows Vista.

In Windows Vista, IPsec authentication can take place in two steps:

■ First Authentication This is performed during the Main Mode phase of IPsec negotia- tion and authenticates the computer. First Authentication is optional: You can opt out of it in scenarios that require only user authentication. (Opting out of Second Authentica- tion either causes user authentication to be performed using anonymous credentials or else no authentication is performed at all, depending upon how you configure Extended Mode policy.) ■ Second Authentication This is performed using AuthIP during the Extended Mode of the Main Mode phase of IPsec negotiation and authenticates the user. Second Authenti- cation is also optional; you can opt out of it in scenarios that require only computer authentication. (Opting out of Second Authentication causes user authentication to be performed using anonymous credentials.) For information about AuthIP, see the section titled “Understanding AuthIP” later in this chapter.

Note Opting out of both First Authentication and Second Authentication is allowed but not recommended because it is equivalent to disabling IPsec authentication entirely.

Tables 27-18 and 27-19 summarize the different authentication methods available for First Authentication and Second Authentication. If more than one authentication method is config- ured, they are each tried in turn until either one succeeds or they all fail.

Table 27-18 Authentication Methods Available for First Authentication Method Description Computer (Kerberos v5) Uses a computer account in Active Directory to authenticate the com- puter using Kerberos. This is the default method used for First Authen- tication. Both peers must either belong to the same Active Directory domain or to separate domains that trust one another. Computer (NTLMv2) Uses a computer account for a standalone computer or a computer belonging to a downlevel to authenticate the com- puter using NTLMv2. Computer (Certificate) Uses a computer certificate from a specified CA to authenticate the computer. This method is useful if the computers are not in a domain or are in separate domains that do not trust one another. Computer certificates can optionally be mapped to computer accounts in Active Directory, and they can also optionally be required to be NAP health certificates. Chapter 27: Configuring Windows Firewall and IPsec 1121

Table 27-18 Authentication Methods Available for First Authentication Method Description Preshared key Uses a secret preshared key to authenticate the computer. This method requires manual configuration of the key and is therefore not recom- mended in an enterprise environment because too much administra- tive overhead is involved, the key is stored in plaintext, and using a preshared key for First Authentication means that Second Authentica- tion cannot be used.

Table 27-19 Authentication Methods Available for Second Authentication Method Description User (Kerberos v5) Uses a computer account in Active Directory to authenticate the user using Kerberos. This is the default method used for Second Authenti- cation. Both peers must either belong to the same Active Directory do- main or to separate domains that trust one another. By default, the Second Authentication is not specified. User (NTLMv2) Uses a user account for a standalone computer or a computer belong- ing to a downlevel Windows domain to authenticate the user using NTLMv2. User (Certificate) Uses a user certificate from a specified CA to authenticate the user. This method is useful if the users are not in a domain or are in separate do- mains that do not trust one another. User certificates can optionally be mapped to user accounts in Active Directory. Computer (Health Uses a computer certificate from a specified CA to authenticate the Certificate) computer. This method is useful if the computers are not in a domain or are in separate domains that do not trust one another. Computer certificates must be NAP health certificates and can optionally be mapped to computer accounts in Active Directory.

The default configuration for IPsec authentication in Windows Vista is:

■ First Authentication Computer (Kerberos v5) ■ Second Authentication Not configured

Note If you use a preshared key for First Authentication, you cannot specify a Second Authentication method.

Five predefined combinations of authentication methods are available from the Windows Firewall With Advanced Security snap-in. To display these options, follow these steps:

1. Open the Windows Firewall With Advanced Security snap-in using an account that has administrator credentials on the computer. Right-click the root node and select Properties. 1122 Part V: Networking

2. Select the IPsec Settings tab and click Customize to open the Customize IPsec Settings dialog.

Table 27-20 summarizes the First Authentication and Second Authentication settings for each of these five predefined combinations of authentication methods.

Table 27-20 Predefined IPsec Authentication Methods and Their Corresponding First Authentication and Second Authentication Settings Predefined authenti- cation method First authentication settings Second authentication settings Default Computer (Kerberos v5) None Computer and User Computer (Kerberos v5) User (Kerberos v5) (Kerberos v5) Computer (Kerberos Computer (Kerberos v5) None v5) User (Kerberos v5) Optional User (Kerberos v5) Computer Certificate Computer (Certificate) None From This Certification Authority Advanced Configurable Configurable Chapter 27: Configuring Windows Firewall and IPsec 1123

Note When you create connection security rules, don’t be confused by the first and third authentication methods shown in Table 27-20. Think of the Default option as being “not con- figured” in Group Policy. This “not configured” option allows you to configure it at one level of Group Policy and have it fall through the hierarchy with the highest-precedence GPO settings winning. If you have no GPO policy and you haven’t configured theses settings, the service default settings kick in, which are Computer (Kerberos).

Understanding AuthIP

Authenticated Internet Protocol (AuthIP) is a new key exchangekeying protocol that extends the Internet Key Exchange (IKE) protocol used by IPsec to negotiate security associations for the purpose of protecting AH and ESP traffic. AuthIP is an extension of the current version of IKE (IKEv1) and provides additional features for transport mode to make it more efficient and robust. While an AuthIP key exchange is similar in operation to an exchange using IKE, AuthIP was designed to simplify key exchange by reducing option complexity and the num- ber of round trips required.

AuthIP works by performing mutual authentication between two peers, establishing a security association that you can use to establish the security associations for both ESP and AH traffic. AuthIP operates as a request/response protocol in which the initiating peer sends a message to the responding peer and the responding peer then returns a message to the initiating peer. AuthIP is primarily used to negotiate ESP transport-mode traffic between two peers but can also be used to protect AH traffic. (AuthIP is currently not able to support VPN scenarios.)

Note The essential difference between IKE and AuthIP is that IKE only supports one authen- tication while AuthIP supports two. If you specify the second authentication and don’t specify it as optional, the exchange will be done with AuthIP. This means that AuthIP is not downlevel- compatible.

IKEv1 and AuthIP negotiate authentication differently:

■ IKEv1 negotiation If peers have multiple authentication methods in common, they negotiate the use of one of these common methods. If authentication using this method fails, IKE negotiation fails and no other other common authentication method is attempted. ■ AuthIP negotiation If peers have multiple authentication methods in common, they negotiate the use of one of these common methods. If authentication using this method fails, AuthIP removes this negotiation method from its list of negotiation methods and attempts negotiation using another method common to both peers. This process repeats until either all negotiation methods have failed or authentication has succeeded using one of the common methods. 1124 Part V: Networking

The traditional IKEv1 key exchange makes use of two different exchange modes:

■ Main Mode (MM) Used for establishing the base security associations (SAs) for the key exchange, for authenticating the peers involved, and for all subsequent traffic flows. MM generally authenticates machine credentials of the peers involved. ■ Quick Mode (QM) Used for establishing SAs for protecting individual traffic flows by providing data integrity and optional encryption of the flows. (QM is not used for authentication purposes.)

AuthIP adds a third mode to these two: User Mode (UM), which can optionally be used to authenticate user credentials of the peers involved and is the basis for the Second Authentica- tion phase of IPsec authentication in Windows Vista described earlier in this chapter. This means that in Windows Vista, IPsec authentication generally takes one of the following two forms:

MM + QM

MM + UM + QM

The first form involves MM once to establish the base SA, and involves QM multiple times— once for each data-protection SA established. UM is not configured in this approach. The sec- ond form involves MM once followed by UM once (to establish the base SA) and then QM multiple times.

Note The existing IKE protocol is currently under revision by the IETF. While the planned IKEv2 protocol improves on many of the IPsec VPN usage issues associated with IKEv1, the plans for IKEv2 do not currently address deficiencies in how transport mode operates during IPsec key exchange.

Understanding Negotiation Discovery

Negotiation discovery is an enhancement to IPsec in Windows Vista that allows one peer (the initiator) to dynamically determine whether it needs to use IPsec to protect a TCP connection when no prior SA exists with the peer (the responder). Previous versions of Windows use a different method, known as default responder, in which the initiator sends its request in the clear; if the responder does require IPsec, the responder must accept the inbound packet unsecured. Otherwise, traffic continues in the clear between the peers. Unfortunately, this “fallback to clear” approach, which allows outbound traffic to flow even if IKE authentication fails, often takes too long (three seconds by default) and introduces unacceptable delays in establishing IPsec communication between peers, especially when multiple delays are incurred because communication with multiple domain controllers is required.

Negotiating discovery resolves the delay problem by having the initiator simultaneously start a TCP session with the responder and begin negotiating an IKE session. As a result, negotia- Chapter 27: Configuring Windows Firewall and IPsec 1125 tion discovery guarantees that client-initiated traffic will succeed without the three-second delay imposed by fallback to clear. The delay occurs in downlevel IPsec implementations when the responder does not require IPsec to accept inbound network connections. If the responder does require IPsec to accept inbound connections, IKE/AuthIP will be used to negotiate an SA with the initiator; the only delay experienced for secure traffic is the normal delay of the IKE negotiation process. This means that in Windows Vista, the fallback to clear time-out value is virtually eliminated because Windows Vista simultaneously sends two out- bound packets (one IKE negotiation packet and one unsecured packet) when trying to estab- lish a connection with a host that may require IPsec protection.

Note If credential and policy mismatch failures occur, IPsec in Windows Vista can use fall- back to clear and reduce the fallback delay from 3 seconds to 500 milliseconds. You can also enable this functionality in Windows XP and Windows Server 2003 by installing an update available from the Microsoft Download Center. For more information, see Knowledge Base article KB914841 at http://support.microsoft.com/kb/914841.

Understanding Connection Security Rules

Connection security rules let you use IPsec to authenticate and optionally encrypt traffic for different network-protection scenarios, including server isolation, secure server-to-server communications, domain isolation, and Network Access Protection (NAP) scenarios. Con- nection security rules can filter traffic based on a number of different conditions, as described in Table 27-21. (The generalized connection security rule is the logical AND of all these conditions.)

Table 27-21 Filtering Conditions for Windows Firewall Connection Security Rules Condition Possible values Endpoints A specific IPv4 or IPv6 address or a list of addresses. A range of IPv4 or IPv6 addresses or a list of ranges. An entire IPv4 or IPv6 subnet or a list of subnets. A predefined set of computers, including: local subnet, default gateway, DNS servers, WINS servers, or DNS servers—or a list of such items. Interface type All interface types. Local area network. Remote access. Wireless. Authentication Request for both inbound and outbound connections. Require for inbound connections and request for outbound connections. Require for both inbound and outbound connections. No authentication (effectively disables security for the rule). 1126 Part V: Networking

Table 27-21 Filtering Conditions for Windows Firewall Connection Security Rules Condition Possible values Authentication Method Default. Computer and User (Kerberos v5). Computer (Kerberos v5). User (Kerberos v5). Computer Certificate (with option to only accept Health certificates). Advanced (see Tables 27-18 and 27-19). Tunnel endpoints A specific IPv4 or IPv6 address. A range of IPv4 or IPv6 addresses. An entire IPv4 or IPv6 subnet. A predefined set of computers, including local subnet, default gateway, DNS servers, WINS servers, or DNS servers. IPv4 or IPv6 address of local and remote tunnel computers (closest computers to tunnel endpoints 1 and 2 respectively). Must be a single IPv4 or IPv6 address. The local and remote tunnel endpoints need to match in IP version. (In other words, you can’t have one that is IPv4 and one that is IPv6.) Authentication exemption (This A specific IPv4 or IPv6 address. isn’t actually a property on a A range of IPv4 or IPv6 addresses. connection security rule—it’s a connection security rule config- An entire IPv4 or IPv6 subnet. ured with these as endpoints and A predefined set of computers, including local subnet, default authentication requirements of gateway, DNS servers, WINS servers, or DNS servers, “no authentication.” See Authentication Exemption in Table 27-22 for more information.)

Note You can configure connection rules on a per-profile basis.

Types of Connection Security Rules

Table 27-22 summarizes the types of connection rules you can create and the conditions that you can configure for each type of rule.

Table 27-22 Connection Security Rules and Their Configurable Conditions Type Description Conditions Isolation Restricts connections to the computer based on Authentication authentication credentials such as membership in a Authentication method domain or health status of the computer. You can use isolation rules to implement a server or domain isolation strategy on your network. Chapter 27: Configuring Windows Firewall and IPsec 1127

Table 27-22 Connection Security Rules and Their Configurable Conditions Type Description Conditions Authentication Prevents the computer from authenticating con- Exempt computers exemption nections from specified computers. This is typically used in conjunction with an isolation rule. For ex- ample, if you want to isolate all computers on your domain, but you know that a specific computer with a non-Windows operating system needs ac- cess, you can exempt this computer from the re- quirements by specifying its IPv4 or IPv6 address. Server-to-server Enables the computer to authenticate connections Endpoints with specified computers. You can use server-to- Authentication server rules to protect connections between critical servers on your network. Authentication method Tunnel Enables authenticated connections between gate- Tunnel endpoints way computers. You can use tunnel rules to protect Authentication method a connection between two security gateways across the Internet. Custom Enables creation of custom connection security Endpoints rules. Use this type of rule when none of the default Authentication rule types can meet the protection needs of your network. Authentication method Implementing IPsec Protection Strategies

Windows Vista’s connection security rules greatly simplify implementing different kinds of IPsec protection strategies on your corporate network. These network protection strategies are of three basic types:

■ Server and domain isolation ■ Network Access Protection

Server and Domain Isolation Server and Domain Isolation are strategies that logically iso- late server and domain resources to create secure logical networks within your physical net- work. These logical networks consist of computers that have common requirements for secure communication. They are used to limit access to server and domain resources to com- puters that are properly authenticated and authorized, and to prevent unauthorized (rogue) computers from inappropriately gaining access to these resources. The two types of isolation scenarios are:

■ Server Isolation In this type of scenario, selected servers or server applications have IPsec policy configured so that they will only accept authenticated and secured commu- nications from other computers on the network. An example of a server isolation sce- nario would be configuring IPsec policy so that only users in the Finance Department can access the finance database, or only users in Human Resources can access HR serv- ers. Server isolation thus provides protection to critical servers and network traffic between them. 1128 Part V: Networking

■ Domain Isolation In this type of scenario, domain controllers and domain-member computers (both client computers and member servers) have IPsec policy configured so that they will only accept authenticated and secured communications from other domain-member computers on the network. Domain isolation protects traffic sent between domain members and prevents non-domain–joined computers from communi- cating with domain controllers or domain-member computers. Domain isolation thus prevents rogue computers from accessing domain resources or intercepting network traffic between domain computers.

While you can use or later to implement Server and Domain Isolation on Active Directory networks, IPsec in Windows Vista and Windows Server Code Name “Long- horn” simplifies the task of implementing these strategies. For more information on how Server and Domain Isolation works and how to implement it in various scenarios, see http:// www.microsoft.com/sdisolation on Microsoft TechNet and the “Additional Resources” section at the end of this chapter.

Network Access Protection Network Access Protection (NAP) is a strategy that helps pro- tect network resources by forcing computers connecting to the network to comply with pre- defined computer health requirements. These health requirements can include policies such as ensuring that the connecting computers have the necessary software patches, the latest antivirus signatures, the necessary certificates, and so on. If a computer attempting to connect to the network does not comply with all health requirements, the NAP enforcement mecha- nism can either prevent the computer from establishing a connection to the network until it becomes compliant, or it can force compliance by downloading and installing the appropriate updates, signatures, and so on to the computer. NAP does not prevent malicious users or rogue computers from accessing domain resources, but it does help maintain your network’s overall integrity by maintaining the health of computers on your network.

The NAP policy enforcement platform is built into the Windows Vista and Windows Server Code Name “Longhorn” operating systems. A Network Access Protection Client will also be released for Windows XP at the same time that Windows Server Code Name “Longhorn” is released. For more information on how NAP works and how to implement it in various sce- narios, see http://www.microsoft.com/technet/itsolutions/network/nap/default.mspx on Microsoft TechNet and the “Additional Resources” section at the end of this chapter.

Understanding Windows Firewall Logging and Auditing Windows Firewall in Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 log firewall activity in two locations:

■ %windir%\Pfirewall.log This is a flat text file that you can use for logging successful connections and dropped packets. By default, no information is written to this log unless you enable logging of passed or dropped packets. Information is written to this log file using the W3C Extended File format; you can analyze it using tools such as Log- Chapter 27: Configuring Windows Firewall and IPsec 1129

parser. For more information on Logparser and to download this tool, see http://www.microsoft.com/technet/scriptcenter/tools/logparser/. ■ Security event log By default, the only events relating to Windows Firewall that are written to this log are policy-change events: starting or stopping the Windows Firewall service, creating or modifying a rule, changing the operation mode between standard and domain, processing Windows Firewall Group Policy settings, and several other actions.

The difficulty with separating packet logging events from policy events is twofold:

■ Troubleshooting Windows Firewall connectivity issues is more difficult. ■ Windows Firewall is not compliant with the Common Criteria.

The Common Criteria mandates that all security auditing be comprehensive in nature and contain all security-oriented events. Common Criteria also mandates that the system fail if auditing cannot be performed (for example, if the audit log becomes full), a condition known as CrashOnAuditFail. The downlevel Pfirewall.log does not satisfy these two criteria, but the Windows Security event log is compliant with the Common Criteria. As a result, in Windows Vista all logging of both filtering and policy is done to the Security event log, which makes complying with Common Criteria requirements easier for enterprises in the government, healthcare, and financial industry sectors.

However, for administrators who still want to use the Pfirewall.log for logging passed and/or blocked traffic, Windows Vista still provides the Pfirewall.log, although it is now stored in a new location: %windir%\system32\LogFiles\Firewall\Pfirewall.log. The default size limit of this log file 4096 kilobytes (the same as in Windows XP) and by default the system logs nei- ther successful connections nor dropped packets To configure the Pfirewall.log in Windows XP, you use the Advanced tab of the Windows Firewall CPL properties in Control Panel. To configure Pfirewall.log in Windows Vista, you must instead use the Windows Firewall With Advanced Security snap-in (or its associated Group Policy user interface) as in the following steps:

1. Open the Windows Firewall With Advanced Security using an account that has admin- istrator credentials on the computer. Right-click the root node and select Properties. 2. Choose a profile (domain, private, or public) and click Customize under Logging and configure Pfirewall.log settings as desired.

Caution If you are using Group Policy to configure a new location for the Pfirewall.log, make sure that the Windows Firewall service account (this is LocalService by default) has at least Write permissions on the destination folder, otherwise logging will fail. 1130 Part V: Networking

You can also use the netsh command to display the Pfirewall.log logging settings for the domain Windows Firewall profile. Open a command prompt with administrator credentials and type netsh advfirewall show domainprofile. You can also use netsh to configure Pfire- wall.log logging settings for the domain profile by using netsh advfirewall set domainpro- file. For example, to enable logging of dropped packets, type netsh advfirewall set domainprofile logging droppedconnections enable at a command prompt. For more infor- mation, type netsh advfirewall set ? at a command prompt. The section titled “Common Management Tasks” later in this chapter includes more examples of how to use netsh to man- age Windows Firewall.

The main location for logging Windows Firewall activity in Windows Vista is now the Win- dows Security event log. In addition to logging the firewall policy–change events that are logged in Windows XP (with some changes in event categories and event IDs), Windows Vista can audit other global Windows Firewall activity, including:

■ IPsec filter-level policy changes, which are logged under the Policy Change event category ■ IPsec Main Mode and Quick Mode authentication events, which are logged under the Logon/Logoff event categories ■ IPsec driver events, which are logged under the System event category Windows Vista can also log policy check events such as: ■ Connection creation events ■ Connection deletion events ■ Packet dropped events

These events are logged under the Object Access event category.

By default, these policy check events are not logged in the Security event log unless an admin- istrator enables this auditing functionality because of the performance hit that the system can incur. To enable detailed auditing of Windows Firewall activity, you can use the Auditpol.exe from an elevated command prompt opened with administrative credentials. For example, to display the current audit settings for all categories and subcategories, type auditpol /get /cat- egory:* at a command prompt. To display all audit subcategories for which you can enable auditing, type auditpol /list /subcategory:* at a command prompt. To enable auditing of dropped packets to the Security log, you can enable the Filtering Platform Packet Drop sub- category under the Object Access category by typing auditpol /set /subcategory:"Filtering Platform Packet Drop" /failure:enable at a command prompt. For more information, type auditpol /? at a command prompt.

Note For information about using Group Policy to configure detailed security auditing for Windows Vista client computers in a Windows Server 2003 or Windows 2000 domain, see Microsoft Knowledge Base article 921469 found at http://support.microsoft.com/kb/921469/. Chapter 27: Configuring Windows Firewall and IPsec 1131 Managing Windows Firewall Windows Vista has new and enhanced tools for managing Windows Firewall that make it eas- ier for administrators to manage desktop firewall configuration across an enterprise. These tools include:

■ The new Windows Firewall With Advanced Security snap-in for the MMC console ■ The new Windows Firewall With Advanced Security node in Group Policy ■ The new advfirewall context of the netsh command ■ New COM APIs for programmatically managing Windows Firewall

Note The Windows Firewall tool in Control Panel is mainly for use by home users who need to enable/disable Windows Firewall or create exceptions to enable third-party applications on their computers to work.

How It Works: Windows Firewall Remote Management The Windows Firewall service runs in a special process called SvcHost.exe (Service Host) which hosts two more built-in Windows Vista services. This instance of SvcHost.exe runs in the context of a LocalService account, which basically means two things:

1. The LocalService account is yet another (built-in) user and has no special admin- istrative rights or privileges. 2. If this process tries to communicate over the network, it will show up as anony- mous to the other side.

In addition, this specific SvcHost.exe instance runs in a service group called “LocalServi- ceNoNetwork” which, by means of Windows Service Hardening rules and privilege strip- ping, prohibits this process from sending or receiving any network traffic. These facts, together with the fact that the service has a write-restricted token, make it a super-tight service from a security point of view. If it cannot talk to the network, it cannot affect administrative settings, and it cannot write anywhere unless explicitly authorized to do so. These are all traits that you want to have on a firewall service, because the service con- trols your system’s network and you want it to have the smallest attack vector possible. Now you need to support a configurable remote management feature for this service.

The attributes of this remote management feature are:

■ The feature is off by default and the administrator can toggle it on and off at will. ■ When the feature is turned off, the super-strict service restrictions mentioned pre- viously must be in place. (The service cannot talk to the network.) 1132 Part V: Networking

■ When the feature is turned on, only administrators can remotely connect and manage the firewall settings. For local configuration, administrators and network operators can view and manage the firewall’s policy and authenticated users can only view it. ■ Support RPC mutual authentication so that the remote management clients know they are really talking to the right computer and service.

It’s pretty clear that satisfying the requirements of this feature can potentially undo many of the hardening efforts described in the first paragraph of this sidebar. The solu- tion is to use a different service as a proxy. That other service should be able to authen- ticate on the network but should not be an omnipotent LocalSystem service—a NetworkService account is what we need. The PolicyAgent service was picked as the proxy service because it is auto-start by default and runs under a NetworkService account. Here is how it works:

1. The administrator enables the disabled-by-default built-in group of Windows Fire- wall rules called “Windows Firewall Remote Management.” 2. The PolicyAgent service detects this change and dynamically registers with the RPC subsystem. It exposes an RPC/TCP interface supporting mutual authentica- tion with data encryption on the wire and tamper-proofing. Similarly, when the administrator disables this group of rules, the RPC interface closes. 3. A remote management client connects over RPC/TCP to the interface exposed by the PolicyAgent service. This is either a redirected Windows Firewall with Advanced Security MMC snap-in or a redirected ‘advfirewall’ netsh extension. 4. The PolicyAgent service checks the authentication of the remote client and verifies that it is a member of the Administrators group. 5. For each management activity (an RPC interface call), the PolicyAgent imperson- ates the remote client and performs an identical local interface call to the Win- dows Firewall service.

This achieves the following benefits:

■ The Windows Firewall service can stay locked down and hardened even in the presence of a remote management feature. ■ A different access level is used for remote management (administrators only) ver- sus local management. (Administrators and network operators can view and man- age the firewall’s policy and authenticated users can only view it.) ■ By impersonating the remote caller in the PolicyAgent service, auditing the user who made a policy change is preserved. Chapter 27: Configuring Windows Firewall and IPsec 1133

■ If the remote management proxy service (PolicyAgent) is somehow attacked and breached, it still affect Windows Firewall settings because it does not have admin- istrative privileges.

The key points to remember are:

■ To enable Windows Firewall remote management, all you have to do is enable the Windows Firewall group of rules called “Windows Firewall Remote Manage- ment.” ■ The PolicyAgent service serves two purposes: down-level IPsec policy management and remote firewall management proxy. ■ Disabling the PolicyAgent service because you don’t need down-level IPsec sup- port also means that you lose the remote firewall management features.

Eran Yariv Windows Firewall and IPsec Management Development Lead

Managing Windows Firewall Using the Windows Firewall With Advanced Security Snap-in You can use the new Windows Firewall With Advanced Security snap-in to manage nearly all aspects of Windows Firewall on either the local computer or on a remote computer, including block/allow rules, connection security rules, and monitoring. (Some aspects of Windows Fire- wall can only be managed through netsh.) You can only use this snap-in for managing Win- dows Firewall on Windows Vista and Windows Server Code Name “Longhorn” computers. You cannot use it to manage Windows Firewall on Windows XP Service Pack 2 or Windows Server 2003 Service Pack 1 computers. To manage Windows Firewall on downlevel Windows platforms, use either the Windows Firewall CPL (for local management) or the Computer Configuration\Administrative Templates\Network\Network Connections\Windows Fire- wall policy settings in Group Policy (for remote management).

To use the Windows Firewall With Advanced Security snap-in to manage Windows Firewall on the local computer, follow these steps:

1. Click Start, click Control Panel, click System And Maintenance, and then click Adminis- trative Tools. 2. Click Windows Firewall With Advanced Security.msc.

To use the snap-in to manage Windows Firewall on a remote computer, follow these steps:

1. Make sure that you are logged on to your administrative workstation using an account that is a member of the Administrators group on the remote computer. A domain user account that belongs to the Domain Admins group will provide these privileges. 1134 Part V: Networking

2. Enable remote management of Window Firewall on the remote computer. You can do this in several ways: ❑ While logged on to the remote computer, use the Windows Firewall CPL on the remote computer to enable the Windows Firewall Remote Management rules. (This the Windows Firewall remote management rules only for the current fire- wall profile.) ❑ Use the Windows Firewall With Advanced Security snap-in on the remote com- puter to enable all rules for the active profile that belong to the Windows Firewall Remote Management rule group. ❑ Open a command prompt using administrator credentials and type netsh advfire- wall firewall set rule group="Windows Firewall Remote Management" enable=yes. (You can only use the netsh advfirewall set rule command to enable or disable a rule group for all firewall profiles.) ❑ Use Group Policy to open the Windows Firewall Remote Management rule group on the remote computer. (See later in this section to learn how to do this.) 3. On the management workstation, click Start, type mmc, and then press Enter. 4. In the new MMC console that opens, click File and then click Add/Remove Snap In. 5. Select the Windows Firewall With Advanced Security snap-in and click Add. 6. Select the Another Computer option in the Select Computer dialog box, and click Browse to find the remote computer in Active Directory. When the remote computer name has been populated into the Another Computer field, click Finish and then click OK.

Figure 27-2 shows the general layout of the Windows Firewall With Advanced Security snap- in with its different sections and nodes. Chapter 27: Configuring Windows Firewall and IPsec 1135

Figure 27-2 Layout of the Windows Firewall With Advanced Security snap-in.

Table 27-23 summarizes the management tasks that you can perform using the nodes in the left-hand pane of the console:

Table 27-23 Management Tasks for Each Node in the Windows Firewall With Advanced Security Snap-in Node Tasks Root node Import/export Windows Firewall policy. Enable/disable Windows Firewall for the selected profile. Display or modify the default behavior for inbound or outbound connections that don’t match a rule for the selected profile. Enable/disable Windows Firewall notifications for the selected profile. Enable/disable unicast respond to broadcast or multicast traffic for the selected profile. Configure Windows Firewall log settings for the selected profile. Configure IPsec defaults for key exchange, data protection, and authentication methods. Enable/disable exemption of ICMP traffic from IPsec. 1136 Part V: Networking

Table 27-23 Management Tasks for Each Node in the Windows Firewall With Advanced Security Snap-in Node Tasks Inbound Rules Enable or disable an inbound rule. Create a new inbound rule or delete an existing rule. Display or edit properties of existing inbound rules. Display all inbound rules belonging to the same profile, rule group, or state. Export a list of inbound rules. Outbound Rules Enable or disable an outbound rule. Create a new outbound rule or delete an existing rule. Display or edit properties of existing outbound rules. Display all outbound rules belonging to the same profile, rule group, or state. Export a list of outbound rules. Connection Security Rules Enable or disable a connection security rule. Create a new connection security rule or delete an existing rule. Display or edit properties of existing connection security rules. Display all connection security rules belonging to the same profile or state. Export a list of connection security rules. Monitoring Display Windows Firewall’s current profile state and settings. Monitoring\Firewall Display inbound/outbound rules that are currently applied and their properties. Monitoring\Connection Display connection security rules that are currently active and their Security Rules properties. Monitoring\Security Export a list of active security associations (SAs). Associations Monitoring\Security Display Main Mode SAs that are currently active and their endpoints Associations\Main Mode and settings. Monitoring\Security Display Quick Mode SAs that are currently active and their endpoints Associations\Quick Mode and settings.

Note Note that the Monitoring\Firewall node displays rules that are currently applied, not rules that are enabled. It is possible to have an enabled local rule that isn’t being applied because Group Policy doesn’t allow local rule merge. Chapter 27: Configuring Windows Firewall and IPsec 1137

How It Works: Monitoring Windows Firewall In addition to the Monitoring node of the new Windows Firewall With Advanced Secu- rity snap-in, the IPsec Security Monitor snap-in remains available in Windows Vista for monitoring active IPsec policy and security associations (SAs). You can use both moni- toring snap-ins to view the active SAs, but the new one (Windows Firewall With Advanced Security) displays more information. When using these tools, keep the follow- ing points in mind:

■ Although it’s true that SAs show up in both places, you should generally use the tool that corresponds to policy creation: Windows Firewall With Advanced Secu- rity’s Monitor node if you are using Windows Firewall With Advanced Security to create the policy, or IP Security Monitor if you use IP Security Policies to create the policy. The policy from one snap-in will not show up in the monitor for the other snap-in. ■ You cannot apply Windows Firewall with Advanced Security policy down-level—it is for Windows Vista and later only.

Managing Windows Firewall Using Group Policy The user interface for managing Windows Firewall using Group Policy is basically the same as the Windows Firewall With Advanced Security snap-in with the exception of the Monitoring node and its subnodes, which are available only from the snap-in when managing a single local or remote computer. Figure 27-3 shows a Group Policy Object (GPO) opened from a Windows Vista administrative workstation using the Group Policy Object Editor snap-in. 1138 Part V: Networking

Figure 27-3 Windows Firewall policy settings displayed for a GPO using the Group Policy Object Editor.

You can find the policy settings for Windows Vista's version of Windows Firewall in the fol- lowing location:

Computer Configuration\Windows Settings\Security Settings\Windows Firewall With Advanced Security\Windows Firewall With Advanced Security

For more information on how to use Group Policy to manage desktop computers running Windows Vista, see Chapter 13, “Managing the Desktop Environment.”

Note You cannot use Resultant Set of Policy (RSoP) to remotely report Windows Firewall policy settings that have been applied to a Windows Vista computer using Group Policy. Instead, use the Windows Firewall With Advanced Security to view the resultant policy settings on a selected remote computer.

Direct from the Source: Managing Windows Firewall and IPsec in Mixed Environments Windows Vista introduces a lot of new and exciting functionality in Windows Firewall. However, policy created by the new management console, Windows Firewall with Advanced Security is not understood by earlier versions of Windows. Chapter 27: Configuring Windows Firewall and IPsec 1139

Using WMI filtering to selectively apply policy to a Group Policy object (GPO) allows you to manage this mixed environment. Through Group Policy Management Console (GPMC), create two GPOs. Use a WMI query to target one of the GPOs to only comput- ers running a version of Windows prior to Windows Vista. In this GPO, create a firewall policy using the Windows Firewall Administrative Template (located under Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall). Target the second GPO to Windows Vista and later computers. Configure the firewall policy for this GPO using the Windows Firewall with Advanced Security snap-in (located under Computer Configuration\Windows Settings\Security Settings\Win- dows Firewall with Advanced Security).

There are several reasons why we recommend that you take the split GPO approach to firewall management even though Windows Vista understands the Windows Firewall Administrative Template policy. First, by using the Windows Firewall with Advanced Security snap-in for policy configuration instead, you can take advantage of the flexibil- ity and granularity of the new functionality, allowing for rules that are scoped much more than they could be when you use the Windows Firewall Administrative Template. Additionally, Windows Firewall with Advanced Security ships with a number of rule groups that are already configured to provide features and experiences in Windows Vista the network access they need. Trying to translate these rules into the Windows Firewall Administrative Template is in some cases not possible and in other cases would result in a rule that exposes much more attach surface than the Windows Vista equiva- lent rule. Finally, earlier versions of Windows Vista may be running different programs or updated versions of the programs for Windows Vista may have different networking requirements, so this split helps ensure that each computer gets only the rules it needs.

For IPsec management, you have a couple of options. If you are not using the new IPsec features in Windows Vista, such as new authentication types or cryptographic option, and would prefer to manage a single IPsec policy for all your client computers, regard- less of operating system, create a single GPO for your clients and configure the policy using the IP Security Policies snap-in (located under Computer Configurations\Win- dows Settings\Security Settings). To take advantage of the new IPsec features, use the GPO that you created for Windows Vista computers as described previously and config- ure your IPsec policy using the connection security rules in the Windows Firewall with Advanced Security snap-in. With this approach, be sure to use settings for authentica- tion, key exchange, and data protection contain at least one suite that is compatible with IPsec in earlier versions of Windows.

For more information on WMI filtering through GPMC, see http:// technet2.microsoft.com/WindowsServer/en/library/6237b9b2-4a21-425e-8976- 2065d28b31471033.mspx?mfr=true.

Sarah Wahlert, Networking Core 1140 Part V: Networking Managing Windows Firewall Using netsh You can manage Windows Firewall from the command line using the new advfirewall context of the netsh command. To enter the advfirewall context, open a command prompt using administrative credentials and run the command netsh. Within netsh run advfirewall to enter thatn context. When you are within this context, you can use any of the commands for that context (see Table 27-24) and for the available subcontexts (see Table 27-25).

Table 27-24 Commands Available in the netsh advfirewall Context Command Description Import Imports Windows Firewall policy from the specified file. Export Exports current Windows Firewall policy to the specified file. Show Displays global settings and the properties for the specified profile or for all profiles Set Sets global or per-profile settings. Use set file to copy the console output to a file; use set machine to set the current computer on which to operate. Reset Restores the Windows Firewall configuration to its out-of-box policy. Help or ? Displays a list of available commands.

Table 27-25 Subcontexts Available in the netsh advfirewall Context Subcontext Description firewall Lets you display and configure inbound and outbound firewall rules. Consec Lets you display and configure connection security rules. Monitor Lets you display monitoring settings.

Note To view the available commands for any subcontext, enter that subcontext and type ? at the command prompt.

Managing Windows Firewall Using Scripts You can also programmatically manage Windows Firewall using scripts. The new COM APIs for managing Windows Firewall in Windows Vista and Windows Server Code Name “Long- horn” are described in the Windows SDK at http://windowssdk.msdn.microsoft.com/en-us /library/aa366459.aspx. MSDN also has samples of how to use the new API to manage Windows Firewall using VBScripts; you can find these samples at http://windowssdk.msdn. microsoft.com/en-us/library/aa366418.aspx. Finally, the companion CD for this book also contains scripts that you can use to manage certain aspects of Windows Firewall; see the section titled “On the Companion DVD” at the end of this chapter for more information. Chapter 27: Configuring Windows Firewall and IPsec 1141

Direct from the Source: How Do Windows Firewall Notifications Work? Windows Firewall notifications is not a security feature. It is a connectivity feature that helps users realize that the applications they are running are actually blocked from receiving inbound traffic. This feature is enabled by default in Windows Vista and dis- abled by default on Windows Server Code Name “Longhorn.” This feature can be tog- gled per firewall profile using the Windows Firewall Control Panel applet, The Windows Firewall with Advanced Security MMC snap-in, the ‘advfirewall’ netsh extension, or using scripts/programmatically through COM APIs (see the INetFwPolicy2 documenta- tion).

The notifications mechanism works using the following logic:

1. An application either starts listening on a TCP socket or binds to a non-wildcard port on a UDP socket. Since UDP does not have the equivalent of a TCP listen operation, binding to a non-wildcard (i.e., a specific) port number is used as a heu- ristics that the applications is about to receive traffic on that port. 2. The TCP-listen or UDP-bind operation succeeds. 3. If the application is not interactive (does not have the interactive logon SID) or is a service (either has the Service logon SID or runs as LocalSystem) then nothing happens. This is done since services and other non interactive applications are usually not associated with an active console and displaying a notification in that case is futile. 4. If there’s an active inbound firewall rule to allow this application or port, by means of any combination of rule conditions, the application will successfully receive traffic and no user notification is displayed. 5. Else if there’s an active inbound firewall rule to block this application or port, by means of any combination of rule conditions, the application will not receive any traffic and no user notification is displayed. The application does not receive any error indication. It simply does not receive inbound traffic to its socket, as if the remote side did not transmit anything. 6. Else start the notification process as follows: a. A new local active inbound firewall rule is added to explicitly block this application for TCP and UDP traffic. This is done to make sure the notifica- tion is displayed only once per application. Further listen/bind attempts from this application will hit condition (4) above and no further notifica- tions will be displayed. b. The firewall service displays a notification dialog to the user 1142 Part V: Networking

c. If the user clicks the ‘Keep blocking’ button, there’s no change in the policy and the dialog is discarded d. If the user clicks the ‘Unblock’ button, the new firewall rule is modified from ‘block’ to ‘allow’ and the dialog is discarded Eran Yariv Windows Firewall and IPsec Management Development Lead

Common Management Tasks The following common management tasks for administering Windows Firewall on Windows Vista computers are illustrated using Windows Firewall With Advanced Security UI (snap-in or Group Policy) and the netsh command. For information about troubleshooting connectiv- ity problems that might be caused by a firewall, refer to Chapter 32, “Troubleshooting Net- work Issues.”

Restore OOB Defaults

To restore the out-of-box default configuration of Windows Firewall, do the following:

■ From the UI Right-click the root node and select Restore Defaults.

Caution Performing this action from Group Policy Object Editor will also delete all firewall rules and connection security rules that were previously created for the selected Group Policy Object.

■ Using netsh netsh advfirewall reset

Caution Restoring the defaults on a Windows Vista client computer will prevent Windows Firewall on the computer from being remotely managed unless you reopen the Windows Fire- wall Remote Management rules.

To back up the current firewall configuration before restoring OOB settings, you can type netsh advfirewall reset export filename=path\filename at a command prompt.

Copy Configuration To Another Computer

In an unmanaged environment, you can copy the Windows Firewall configuration from one Windows Vista computer to other computers by exporting policy from the first computer and importing it into the others. Chapter 27: Configuring Windows Firewall and IPsec 1143

■ From the UI Right-click the root node, select Export Policy, and specify a location for storing the Windows Firewall Policy (*.wfw) file. Copy the file to a network share or USB key. On the target computers, right-click the root node, select Import Policy, and select the previously exported policy file. ■ Using netsh netsh advfirewall export path\filename followed by netsh advfirewall import path\filename

Enable/Disable a Rule Group

Enabling a rule group is equivalent to opening an exception in the Windows Firewall CPL. This may be necessary to enable some Windows Vista experiences to work properly or when third-party applications require additional firewall configuration to function.

■ From the UI Right-click Inbound Rules and select Filter By Group to display all inbound rules for the rule group. Right-click each rule in the group that belongs to the active profile and then select Enable. (Multiple selection of rules is not supported.) Repeat for Outbound Rules if the rule group has outbound rules in it.

Note Enabling a rule group is easier using the Windows Firewall CPL—just open the corre- sponding exception. Note that doing this enables rules only in the group that belong to the active profile.

■ Using netsh netsh advfirewall firewall set rule group="name_of_rule_group" enable=yes

Note Using netsh to enable a rule group enables rules within the group for all profiles, not just the active profile. Enabling a rule group using netsh also enables both inbound and out- bound rules within the group.

To disable a rule group using netsh, use enable=no instead.

Create a New Firewall Rule

Third-party applications may require the configuration of additional firewall rules. The follow- ing shows two ways to block outbound traffic on TCP port 80:

■ From the UI Right-click either Inbound Rules or Outbound Rules (depending on the type of rule you need to create) and select New Rule. Proceed through the New Inbound (or Outbound) Rule Wizard to configure the rule conditions. The new rule is automati- cally enabled when you finish creating it. For example, to add an outbound rule to block traffic on port 80, select Port, select TCP, type 80 and then select Block. 1144 Part V: Networking

■ Using netsh netsh advfirewall firewall add rule name="allow80" protocol=TCP dir=out remoteport=80 action=block

Note For more help, type netsh advfirewall firewall ?

Create a New Connection Security Rule

You can use connection security rules to protect network traffic using IPsec.

■ From the UI Right-click Connection Security Rules and select New Rule. Proceed through the New Connection Security Rule Wizard to configure the IPsec settings for the rule. For example, to create a connection security rule for domain isolation using the default Computer (Kerberos v5) authentication method, select Isolation, select Require Authentication For Inbound Connections And Request Authentication For Outbound Connections, and then select Default. ■ Using netsh netsh advfirewall consec add rule name="isolation" endpoint1=any endpoint2=any action=requireinrequestout

Note For more help, type netsh advfirewall consec ?

Turn Off Windows Firewall

Windows Firewall can run concurrently with other firewalls on the computer. Generally, if you install a third-party firewall on Windows Vista, this third-party firewall will use the APIs to automatically disable Windows Firewall. However, if necessary you can manually turn off Windows Firewall. For example, to disable Windows Firewall on a Windows Vista where the current network category is Private:

■ From the UI Right-click the root node, select Properties, select the tab for the active pro- file, and then change Firewall State from On to Off. ■ Using netsh netsh advfirewall set privateprofile state off

Caution Do not try to disable Windows Firewall by stopping the Windows Firewall service (MspSvc); this service is also required for Windows Service Hardening to function properly. Chapter 27: Configuring Windows Firewall and IPsec 1145 Summary The Windows Firewall in Windows Vista has been enhanced in several ways with more granular fire- wall rules, the ability to block both incoming and outgoing traffic, full support for IPv6, location-aware firewall profiles, network service hardening, and integrated IPsec protection. Using Group Policy, the netsh command, and scripts, administrators can easily manage the configuration of Windows Firewall on Windows Vista client computers across an enterprise.

Additional Resources The following resources contain additional information and tools related to this chapter.

■ For information on Windows Firewall, see http://www.microsoft.com/windowsfirewall. ■ For information about IPsec on Microsoft Windows platforms, see http://www.microsoft.com/ipsec. ■ For information on server and domain isolation, see http://www.microsoft.com /sdisolation. ■ For information on NAP in Windows Vista and Windows Server Code Name “Long- horn,” see http://www.microsoft.com/nap. ■ Download the Windows Firewall Profile gadget from http://gallery.microsoft.com /results.aspx?s=firewall&l=1. This Sidebar gadget displays the current profile of Windows Firewall (domain, private, or public) so you can tell at a glance which firewall policy is currently enforced. ■ Update for Windows Server 2003 (KB914841), available from the Microsoft Download Center at http://www.microsoft.com/downloads/details.aspx?FamilyID=c44dfda8-48ae- 4868-89a6-67f7612adfb1&DisplayLang=en. ■ Update for Windows XP (KB914841), available from the Microsoft Download Center at http://www.microsoft.com/downloads/details.aspx?FamilyID=057de6fb-8e16-42bd-ba8f- 7c90d3bcb64f&DisplayLang=en. ■ Update for Windows XP x64 Edition (KB914841), available from the Microsoft Down- load Center at http://www.microsoft.com/downloads/details.aspx?FamilyID=24f25384- 544c-4d14-8470-07613a46df01&DisplayLang=en.

On the Companion DVD ■ EnableRemoteAdmin.vbs ■ DisableRemoteAdmin.vbs ■ TurnOnWindowsFirewall.vbs ■ TurnOffWindowsFIrewall.vbs 1146 Part V: Networking

■ EnablePortException.vbs ■ DisablePortException.vbs ■ ResetFirewallToDefaults.vbs ■ DisplayFirewallStatus.vbs ■ ViewFireWallLogging.vbs