Step-by-Step Guide: How to patch SQL Server
So you've decided to secure your SQL Server infrastructure and you don't know where to start. This first guide in a two-part series on SQL Server patch deployment will help you track down those pesky servers before getting them properly patched.
So you've decided to secure your SQL Server infrastructure and you don't know where to start. This first guide...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
in a two-part series on SQL Server patch deployment will help you track down those pesky servers before getting them properly patched.
More on SQL Server migration and related topics
Learn how SQL Server Upgrade Assistant can simplify transitions
Find out if SQL Server Express is right for you
Get an idea of what features to expect from SQL Server 2014
SQL Servers represent a significant security challenge for a number of reasons. Primarily, they are ubiquitous. Hundreds of software packages use SQL Server as a data store as do a large number of commercial websites. In addition, since SQL Server 2000 can have multiple instances on a single machine that must each be patched separately, developers generally have at least one instance for their local builds or sample applications. SQL Server has features not rolled into Microsoft's Windows Update or Windows Update Services Tools and thus the servers rarely receive the patching attention they deserve. And finally, SQL Servers usually run with a very high level of privilege (LocalSystem) despite the fact that SQL Server 2000 defaults to the designation of a domain user account.
Most people run SQL Server as a LocalSystem account, and there are several reasons: They never took the time to ask their administrator for a domain user account for SQL Server; they don't know that a local user account will also work in most cases; and using LocalSystem is so much more convenient since no account creation is needed at all. In the world of users (and, sadly, some systems administrators and developers), convenience has long trumped security.
The first thing we need to do in order to patch our SQL Servers is to get our infrastructure identified and assessed so we can prepare a plan to patch them.
![]()
HOW TO PATCH SQL SERVER, PART 1
![]()
Home: Introduction
Step 1: Map your network
Step 2: Perform an active scan
Step 3: Check for SQL registrations
Step 4: Probe remote services
Step 5: Probe for SSNetlib.dll versions
Step 6: Directly request version information
Go to: How to patch SQL Servers, part 2
ABOUT THE AUTHOR:
Chip Andrews is the director of research and development for Special Ops Security Inc. and the founder of the SQLSecurity.com Web site, which focuses on Microsoft SQL Server security topics and issues. He is also the author of SQL Server Security.