This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "OWASP Backend Security Project SQLServer Hardening"
GPederzini (talk | contribs) (→Authentication Mode) |
GPederzini (talk | contribs) (→Authentication Mode) |
||
| Line 45: | Line 45: | ||
=== Authentication Mode === | === Authentication Mode === | ||
| − | Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both ( | + | Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode) |
| + | |||
If there is an homogeneous Windows enviroment, the more secure solution is to enabl the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed in the network, because Windows Authentication uses NTLM or Kerberos Protocols. | If there is an homogeneous Windows enviroment, the more secure solution is to enabl the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed in the network, because Windows Authentication uses NTLM or Kerberos Protocols. | ||
If there is an heterogeneous enviroment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the mixed mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily. | If there is an heterogeneous enviroment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the mixed mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily. | ||
Revision as of 19:47, 23 June 2008
Overview
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.
Description
Installation of the Engine
The prerequisites for the installation are:
- .NET Framework 2.0
- Microsoft SQL Native Client
- Microsoft SQL Server 2005 Setup Support Files.
The installation consist of a large amount of services that are shortly descripted:
- SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
- Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
- Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
- Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
- Client Components (install management tools, development tools and legacy components)
- Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
Services
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:
- Local user that is not a Windows administrator
- Domain user that is not a Windows administrator
- Local Service account
- Network Service account
- Local System account
- Local user that is a Windows administrator
- Domain user that is a Windows administrator
There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
- minimum privileges
- account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service. The Local System account has to many privileges and it's not indicated for a service's account On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.
So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators. For example imagine that are installed the trhee main services:
- Sql Server
- Sql Server Agent
- Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services. In this manner there are exactly two concepts: minimum privileges and account isolation.
Authentication Mode
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)
If there is an homogeneous Windows enviroment, the more secure solution is to enabl the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed in the network, because Windows Authentication uses NTLM or Kerberos Protocols. If there is an heterogeneous enviroment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the mixed mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily.
Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled. So in an enviroment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
- rename "sa" with another name
- use a strong password for the renamed "sa"
