How to Cheat at Securing SQL Server 2005

How to Cheat at Securing SQL Server 2005

First Edition

Mark Horninger Technical Editor

Timothy Blum

K. Brian Kelley

Matt Shepherd

Kevvie Fowler

Raymond Gabriel

Syngress Publishing

Table of Contents

Cover image

Title page

Copyright page

Technical Editor

Contributors

Companion Web Site

Chapter 1: Introduction to SQL Server Security

Introduction

Security: Why Worry About It?

Installing SQL Server

Building Security into Your Application

Managed Code

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 2: Surface Area Reduction

Introduction

SQL Server Surface Area

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 3: Roles

Introduction

Roles

Situational Examples

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 4: Authentication and Granular Access

Introduction

Understanding the SQL Server Authentication Modes

Endpoint Security

Configuring Kerberos Support for Your SQL Server

Auditing Authentication Attempts

Understanding Granular Access

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 5: Schemas

Introduction

Understanding Schemas

Changes Due to the User-Schema Separation

Designing Schemas

Managing Schemas

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 6: Password Policies

Introduction

Password Policies in SQL Server 2005

SQL Server Scenarios

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 7: DDL Triggers

Introduction

DDL Triggers Explained

Implementing DDL Triggers

Managing DDL Triggers

Scenarios for Deploying DDL Triggers

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 8: Data Encryption

Introduction

Data Encryption Explained

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 9: Reporting Services, Analysis Services, and Integration Services

Introduction

General SQL Server Best Security Practices

Securing Reporting Services

Securing Analysis Services

Securing Integration Services

Summary

Solutions Fast Track

Frequently Asked Questions

Appendix A: Group Policies

Group Policies Overview

Software Installation and Maintenance

Summary

Solutions Fast Track

Frequently Asked Questions

Appendix B: Securing Active Directory

Introduction

Designing an Access Control Strategy for Directory Services

Designing the Appropriate Group Strategy for Accessing Resources

Summary

Solutions Fast Track

Frequently Asked Questions

Index

Copyright

Elsevier, Inc., the author(s), and any person or firm involved in the writing, editing, or production (collectively Makers) of this book (the Work) do not guarantee or warrant the results to be obtained from the Work.

There is no guarantee of any kind, expressed or implied, regarding the Work or its contents. The Work is sold AS IS and WITHOUT WARRANTY. You may have other legal rights, which vary from state to state.

In no event will Makers be liable to you for damages, including any loss of profits, lost savings, or other incidental or consequential damages arising out from the Work or its contents. Because some states do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation may not apply to you.

You should always use reasonable care, including backup and other appropriate precautions, when working with computers, networks, data, and files.

Syngress Media®, Syngress®, Career Advancement Through Skill Enhancement®, Ask the Author UPDATE®, and Hack Proofing®, are registered trademarks of Elsevier, Inc. Syngress: The Definition of a Serious Security Library™,Mission Critical™, and The Only Way to Stop a Hacker is to Think Like One™ are trademarks of Elsevier, Inc. Brands and product names mentioned in this book are trademarks or service marks of their respective companies.

PUBLISHED BY

Syngress Publishing, Inc.

Elsevier, Inc.

30 Corporate Drive

Burlington, MA 01803

How to Cheat at Securing SQL Server 2005

Copyright © 2007 by Elsevier, Inc. All rights reserved. Printed in the United States of America. Except as permitted under the Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher, with the exception that the program listings may be entered, stored, and executed in a computer system, but they may not be reproduced for publication.

Printed in the United States of America

1 2 3 4 5 6 7 8 9 0

ISBN 13: 978-1-59749-196-9

For information on rights, translations, and bulk sales, contact Matt Pedersen, Commercial Sales Director; email m.pedersen@elsevier.com.

Technical Editor

Mark Horninger (A +, Net +, Security +, MCSE + I, MCSD, MCAD,MCDBA, MCTS, MCITP, MCPD) is president and founder of Haverford Consultants Inc. (www.haverford-consultants.com), located in the suburbs of Philadelphia, PA. He develops custom applications and system engineering solutions, specializing primarily in Microsoft .Net Technology and Microsoft SQL Server. He was a contributing author to Configuring and Troubleshooting Windows XP Professional; MCSA/MCSE Exam 70-292 Study Guide & DVD Training System: Managing and Maintaining a Windows Server 2003 Environment for an MCSA Certified on Windows 2000; and Designing SQL Server 2000 Databases for .NET Enterprise Servers, all of which were published by Syngress, an imprint of Elsevier Inc. Mark is also an adjunct professor teaching Web design at Kaplan University.

Mark has over 15 years of computer consulting experience and has passed 50 + Microsoft Certification Exams.

He lives with his wife, Debbie, and son, Robby, in the Philadelphia area. Mark would like to thank his wife, Debbie, for her infinite patience, love, and support during this project.

Contributors

Timothy Blum (MCDBA, MCTS, MCITP) is the senior database administrator at HighPoint Solutions, LLC, which provides business and technology solutions to the pharmaceutical and life sciences industry. He currently provides senior-level strategic and technical consulting to HighPoint Solutions’ clients in the northeast region of the U.S. His specialties include Microsoft SQL Server design and implementation, Integration Services, Data Transformation Services, Analysis Services, business intelligence architecture and design, and database tuning. During his 15 years working in the IT industry, Timothy has held positions as a senior SQL Server database administrator, PICK database administrator, Oracle database developer, and a C++, VB, ASP, and UNIX Business Basic programmer for companies such as CEI Network, DDS Ltd, and ECC Management Services.

Kevvie Fowler is the manager of managed security services at Emergis Inc., where he is responsible for the delivery of specialized security and incident response services. Kevvie has more than 10 years of professional information security and IT experience within development, database, and host/network platforms. In 2007, Kevvie was a featured presenter at the Black Hat USA security conference, where he presented his ground-breaking research on SQL Server database forensics. Kevvie is a GIAC Gold Certified Forensic Analyst, and he holds several other certifications, including CISSP, MCTS, MCSD, MCDBA, and MCSE.

Raymond Arthur Gabriel (MCSD, MCAD, MCSD .Net) formed a consulting practice, Integrated MicroSystems Design Corp. (www.imicrodev.net), in 1989 to provide technical consulting services as an application architect and solution developer. He has 20 years of experience in IT, including full life-cycle experience with multitier Windows and Web application development.

Raymond holds an associate’s degree in electronic engineering from the Cleveland Institute of Electronics and is a member of the IEEE. He currently resides in Chester County, PA, with his wife, Sharon, whose support is an eternal source of great encouragement.

K. Brian Kelley (MCSE, GSEC, Security +) is a systems architect for AgFirst Farm Credit Bank. At AgFirst he provides infrastructure and security guidance with respect to Windows-based technologies, including Active Directory, Internet Information Server, and Microsoft SQL Server. Brian, author of Start to Finish Guide to SQL Server Performance Monitoring, is a regular columnist and blogger at SQLServerCentral.com, where he focuses primarily on SQL Server security. He is also a frequent contributor to SQL Server Standard Magazine. Brian’s background includes stints with BellSouth as a systems administrator and with the United States Air Force as a communications/ computer systems officer in a multitude of IT-related roles.

Brian holds bachelor’s degrees from The Citadel, the Military College of South Carolina, and is a member of the Professional Association of SQL Server (PASS), the SQL Server Worldwide Users Group, the Information Systems Audit and Control Association (ISACA), and the Association for Computing Machinery. He is also active in the Midlands PASS chapter, an official PASS chapter for South Carolina. Brian currently resides in Columbia, SC, with his family.

Matt Shepherd (CISSP, MCSE, MCDBA, GCFW, CEH) is a consultant in the Security and Privacy Division at Project Performance Corporation of McLean, VA. Matt uses his experience as a network administrator, IT manager, and security architect to deliver high-quality solutions for Project Performance Corporation’s clients in the public and private sector. Matt holds bachelor’s degrees from St. Mary’s College of Maryland, and he is currently working on his master’s of science in information assurance.

Matt would like to thank his wife, Leena, for her wonderful support during this project and throughout their relationship. He thanks his family for a lifetime of love and support and Olive for making every day special.

Companion Web Site

Much of the code presented throughout this book is available for download from www.syngress.com/solutions. Look for the Syngress icon in the margins indicating which examples are available from the companion Web site.

Chapter 1

Introduction to SQL Server Security

Solutions in this chapter:

■ Security: Why Worry About It?

■ Installing SQL Server

■ Building Security into Your Application

■ Managed Code

☑ Summary

☑ Solutions Fast Track

☑ Frequently Asked Questions

Introduction

This chapter explains why you should be concerned with SQL Server security and introduces some of the more generic ideas, such as the principle of least access. It also covers the concept of planning for security in the design phase, building security into your application from the ground up, as opposed to bolting it on afterward, and installing and configuring SQL Server features. We also discuss the security risks associated with managed code in SQL server. CLR integration is the feature that allows managed code to be run in SQL server.

Multifaceted SQL Server Security

Security in SQL Server 2005 is multifaceted, and it can seem impossibly complicated. SQL Server 2005 security starts at the ground level and builds upon itself. This chapter discusses producing the foundations required to begin thinking in a natively secure manner, upon which the rest of the security principle in this book can be built. This chapter also starts you on the learning curve required to implement SQL Server 2005 security by providing a guide in your journey into SQL Server 2005 security.

Security: Why Worry About It?

In February 2000, the company RealNames informed its customers that its database had been broken into and that information including credit card numbers had been taken. The thought of being the person in charge of security on that database is enough to make anyone break into a cold sweat. How exactly do you go to your boss and tell him that the database that fuels your company and holds your customer’s information has been broken into?

Then there were the W32.CBlade and W32.Digispid worms. These worms attacked SQL Servers using the SA account and a blank password. The fact that either of these two worms could get into systems spoke volumes about the security of the databases they were attacking. The one positive aspect was that when the SQL Slammer worm hit in 2003, IT security professionals had some knowledge of how databases are attacked by worms. Even more fortunate was that even though the Slammer worm was one of the most aggressive worms to date, it was dedicated to creating a denial-of-service (DoS) type attack where the goal was to flood the Internet with traffic, versus a database breach.

In 2001, the World Economic Forum had a database breach. Some of the information from this breach ended up on a Swiss newspaper’s Web site. The data, including Bill Gates’s e-mail address, PepsiCo Beverages CEO Peter Thompson’s credit card number, and Jeff Bezos’s home phone number were taken. Additionally, some 800,000 pages of data from people like Bill Clinton, Vladimir Putin, and Yassir Arafat were accessed using the passwords acquired when the database was breached.

Other companies whose databases were breached were PetCo.com and Guess, both of which fell victim to SQL Injection attacks on their Web sites. The attack on Guess netted the attackers an unknown quantity of credit card numbers. PetCo.com’s Web site was later detected to have the same vulnerability. This vulnerability was detected by someone randomly checking sites for this issue, and would have provided about 500,000 credit card numbers to anyone less honest who discovered this vulnerability.

Information is money. Other than credit card numbers, there are people willing to pay for phone numbers, e-mail addresses, physical addresses, client information, social security information, and just about every other form of client or personal information available. With this as a driving force, people looking to make money, see databases as a bank vault full of money. Just as banks build their buildings with plans on how to secure their vault, you need to protect your information in your databases the same way.

Now that the Sarbanes Oxley (SOX), Gramm-Leach-Biley Act (GLBA), Health Insurance Portability and Privacy Act (HIPAA), Basel II, Code of Federal Regulation (CFR) Part 11, and the Japan Privacy Law (J-SOX) regulations are becoming the model for governments, private companies, and public companies across the globe, more and more companies are being affected even if these regulations do not apply directly to them. These regulations do not state what needs to be done in crystal clear terms. They hold you liable for the security of your information, but leave it up to you on how to interpret what they are saying.

It seems that in all of the preceding cases, there were security precautions that could have been taken to prevent the breaches. In most cases, applying the best practices of securing a SQL Server would prevent breaches from ever happening. It is just a matter of knowing what to secure, which is where this book comes in.

The Principle of Least Access

The principle of least access is a simple way to make databases more secure. Whenever you are presented with a choice of how to configure permissions, choose the method that provides the least access to the database. This goes for everything at every level. If you are asking yourself, Do I need to install this feature? the answer is either a definite yes or a definite no. If you are thinking maybe, possibly, well, we might…, do not install it. If you think that this person might need access to a specific extended stored procedure, then they do get access. This also applies to the level of service accounts that run your SQL services. Start with the most secure setting, and only open it past that point of what you need it to do.

This is now a constant in the world of SQL Server 2005. By default, Microsoft has made things secure for when you start working in SQL Server 2005. But in order for it to work, it means resisting the urge to make sure everything works as it should by turning on everything and giving everyone owner permissions. Yes, it can be annoying when someone keeps coming back to your desk because they need more access to get their job done, but in order to offset this, keep in mind the person in charge of the RealNames database and how his day was when it was announced publicly that the database had been hacked.

Installing SQL Server

Let’s start from the point of installing SQL Server 2005. From the time you put the disk into the machine, think security. At the beginning you will be asked what you want to install. There is the database engine itself, which is only installed when you are going to be immediately housing SQL Server 2005 databases on that server. Next there is the analysis services engine, which is the OLAP/data cubes portion of SQL Server 2005. This should only be installed if you are going to be immediately using OLAP cubes on the server. Additionally, there is Reporting Services, Integration Services, and Notification Services. Reporting Services is SQL Server 2005’s Web-based reporting engine. Integration Services lets you design and deploy SSIS packages, the replacement for DTS. Notification Services provides the engine for keeping people notified. The same principle applies to these—install them only if you are going to use them immediately. Documents and samples is the last optional choice in installing SQL Server 2005, and is also the easiest to decide on whether to install or not. If you are installing on a development box, it is usually a good choice to choose to install both of these. For installation to any other server, never install the Documents and Samples. These are meant for learning, and although they have been reviewed to make sure that they follow Microsoft’s best practices, they provide no benefits when installed to a production environment.

One note at this point has to do with the experience we had installing SQL Server. Many times we have installed SQL Server, adding in extra components because we were told that they would be needed next week, next month, or immediately. Although in every case the person who told us had the best of intentions, about 50 percent of the time they were never used. In the case where they have not been used, you end up having to make sure that they are configured correctly, are patched, and cause general overhead. During a security audit, they have been rightly referred to as a security violation. From this, a policy change has been made that states that no SQL Server 2005 components will be installed until they are required. Once they are no longer required, they are to be completely removed. Keep this in mind as you install components, and try to install them only when you know they will be used.

Best Practices According to Microsoft

■ Install only those components that you will use immediately. Microsoft recommends that you create a list of components that you will be using, and only enable those. If the need arises, you can install the additional components at that time. The components in a SQL Server installation are the Database Engine, Analysis Services Engine, Reporting Services, Integration Services, Notification Services, and Documents and Samples.

■ Enable only the optional features you will use, and review optional feature usage before doing an in-place upgrade and disable unneeded features. Microsoft recommends that you create a list of the optional features that you will use, and only turn those on. If this is an existing SQL Server that is being upgraded, they recommend creating the same list, and disabling any optional features not on the list. These optional features are CLR Integration, OLE Automation, remote use of a dedicated administrator connection, Database Mail and SQL Mail, OpenRowset and OpenDataSource functions, SQL Server Web Assistant, and xp_cmdshell availability.

■ Develop a policy with respect to permitted network connectivity choices and for the usage of optional features. Microsoft recommends defining policies that would be company wide on Connectivity Choices and the use of optional features. They also recommend using SQL Server Surface Area Configuration to standardize this policy and documenting exceptions to the policy on a per-instance basis.

■ Turn off unneeded services by setting the service to either Manual startup or Disabled. Microsoft recommends going into the service management area and setting all services that you will not be using to be disabled or manual. These services include SQL Server Active Directory Helper, SQL Server Agent, SQL Server FullText Search, SQL Server Browser, and SQL Server VSS Writer.

■ Choose the service account with the last privilege possible. Microsoft recommends that the account you choose to run each of the SQL Services as should have the least possible level of privilege. You could use a domain user, local user, network service account, local system account, a local user that is an administrator, or a domain user who is a domain admin.

■ Use a separate specific user account or domain account that has no special privileges for SQL Server Services. Microsoft recommends using a separate account for each SQL Service. This account should be a specific user or domain account rather than a shared account. It is also recommended that this account not be granted any special privileges, but if special privileges are required, manage those through the SQL Server-supplied group account.

■ Always use Windows Authentication Mode if possible. Microsoft recommends using the Windows Authentication versus the Mixed Mode authentication. They recommend the mixed mode Authentication only for legacy application and non-Windows users.

■ Do not expose a server that is running SQL Server to the public Internet. Microsoft recommends that any servers that are running SQL Server not be exposed to the Internet.

Some Independent Advice

Microsoft’s best practices for SQL Server can often seem like a tangled web of rules that would be incredibly expensive and time-consuming to follow. We have found that the best way to handle this is to create your own checklist for your company.

Our list started out as very basic, where the only thing being installed was the Database Engine, and all optional features were turned off. As time went by, our checklist has grown, but it is still fairly basic, because we follow one piece of logic: Nothing gets turned on unless there is a reason for it. If we have a good reason to use a feature, like it saves money and time or offers features that add value, then we’ll take the time to look up what needs to be done to deploy that securely and add it to our checklist. In this manner, we are not attempting to secure everything at once, and our checklist is up-to-date at all times.

If migrating an existing system to SQL Server 2005 from a previous version for the first time, we tend to part ways with Microsoft. We have never successfully been able to create a list of used features for a previous SQL Server instance, without spending huge amounts of time reviewing each line of code in the database and every application that attaches to it to see what is being used. What we recommend is to again create a checklist, turn on only the very basic features, and create a checklist of what you are doing. Then TEST, TEST, TEST! If your older version of SQL had other things turned on or installed that you do not want, you can review whether it is an appropriate use as an additional step, or you can enable and secure them, documenting it in your checklist. When you are done, you will have the beginning of a policy, and your new server configured as you need it.

Features off by Default

In SQL Server 2005, optional features are turned off by default. These features include CLR Integration, OLE Automation system procedures, system procedures for Database Mail and SQL Mail, Ad Hoc Remote Queries, SQL Server Web Assistant, xp_cmdshell availability, and remote use of a dedicated administrator connection (see Figure 1.1).

Figure 1.1 The Surface Area Configuration for Features Screen

In order to enable these, you will need to use either the Surface Area Configuration for Features or the SQL Service Area Configuration command-line interface. However, before enabling any of these features, consider if using these features is the best way of achieving your goals. While each of these tools can be extremely useful, it comes at a cost of reduced security. For example, opening Database Mail or SQL Mail means you must configure not only SQL Server 2005 correctly, but also your e-mail server in order to remain secure. Otherwise, you could become responsible for a part of the SPAM e-mail flood that occurs on a daily basis. It also exposes both your SQL Server and e-mail server to possible attack.

Services off by Default

In SQL Server 2005, during installation, most services are turned off by default. You are provided with the option of turning each one on at installation. After installation, you can also choose to turn services on SQL Server on or off individually. The SQL Server 2005 services that can be turned off are the Database Engine, Analysis Services, Reporting Services, SQL Server Agent, FullText Search, Integration Services, and SQL Browser. It is highly recommended to turn off all of the services that you can. After installation, you can turn them off by going to the Surface Area Configuration Manager for Services and Connections (see Figure 1.2), while during the installation process, leaving the services you do not need unchecked will prevent them from being installed.

Figure 1.2 The Surface Area Configuration Manager for Services and Connections Screen

The best way to determine if you need to have each of these services running is to determine what each service does. If you do not use these features at the present time, it is safe to disable that service.

The database engine itself is the engine that stores SQL Server database files. In most installations this service is being used; however, if you were only using SQL Analysis Services on a server, it would then be safe to disable the Database Engine.

Analysis Services is the OLAP and data mining service used in cubes that make up the base for Business Intelligence applications. If you are not using OLAP cubes or data mining, you can safely disable these services.

Reporting Services is the Web-based application for creating and viewing reports. When using Reporting Services, it uses a SQL Server 2005 database to store its configuration, which requires that the Database Engine be enabled. If you are not utilizing Reporting Services 2005, it is best to disable this service.

The SQL Server agent is used to run jobs inside SQL Server. Two types of jobs are maintenance jobs and custom jobs. Maintenance jobs do things like back up your database at a particular time each day, whereas custom jobs can execute anything from T-SQL statements to things like SSIS packages. If you do not have reoccurring processes that you have scheduled through the SQL Agent, it is safe to disable this service.

The FullText Search service is disabled by default in most installations. The FullText Search is used when you need to go beyond the normal equal or like comparisons to things like finding two words near one another or some sort of fuzzy matching. If you currently do not use these features, FullText Search should be disabled.

Integration Services is the SQL Server 2005 upgrade to Data Transformation Services. It is a platform that allows ETL processes and other more complex processes to be stored as a process and scheduled in SQL Agent or executed manually. If you do not do any ETL processes, you most likely can disable this service.

For SQL Browser, this is required only when you are attempting to connect to named SQL Server instances that use dynamic port assignments. Named instances tend to be used only when you have more than one instance of SQL Server running on a server, or with things like clustering. If you are in charge of installing SQL Server and you have installed only one instance on each server, or if you have installed multiple instances but specified the Transmission Control Protocol/Internet Protocol (TCP/IP) port assignment, it is recommended that you disable the Browser Service.

As an additional note, if you are installing a named instance of SQL Server, it is definitely more secure to use a static TCP/IP port, as this will allow you to use the browser service. Earlier in the chapter, the SQL Slammer Worm was mentioned. The mechanism that was exploited was the SQL Server 2000 browser engine. Although the browser service has been updated for SQL Server 2005, this shows you how an apparently rather safe choice can be used in a malicious way to compromise security on your server.

Additional services can also be turned off using the Service Manager in Windows (see Figure 1.3). These services are the Active Directory Helper and the VSS Writer.

Figure 1.3 The Windows Service Manager Screen

The VSS Writer provides integration into Visual Source safe and was introduced in SQL 2005. It is highly recommended to use the VSS Writer for source control integration; however, if you are not using this, you can safely shut down the service inside the Service Manager and set its startup type to Manual (see Figure 1.4).

Figure 1.4 The Windows Service Manager Service Property Screen

Another service that can be disabled in some companies is the Active Directory Helper. If your company does not use Active Directory, you can safely disable this service.

Once