SQL Server Security Audit (Part 1) - Server Level Audit

By : Sadequl Hussain Aug 10, 2009

Although security is a major component of database administration, it is sometimes overlooked in favour of convenience. User accounts are given elevated permissions to save time, patches and hotfixes are not applied timely and best practices are often not followed. Over time, the server becomes vulnerable to potential breaches of security.

As the DBA, you need to know how vulnerable your SQL Servers are before you can start securing them. To get this answer, you will first need to conduct a security audit. This audit should give you a baseline picture and help you find potential loopholes. Once you have the report and management approval, you can start locking down where necessary.

In this series of articles, I will try to provide a guideline for a security audit. This can be discussed under three broad categories, namely Server Level Audit, Database Level Audit, Operating System Level Audit. Accordingly each will be discussed in a separate article.

Server level audit

At this level, you are primarily interested in the properties of the SQL Server itself and its vulnerabilities.

Service pack level

Start by looking at the service pack level of the SQL Server. SQL Server service packs are cumulative and can contain cumulative updates or hot-fixes related to security. If the database server does not have the latest service pack installed, dont automatically assume it is a security threat: in fact there may be a good reason it is not there (perhaps the latest SP causes an application to fail). However you should still need to note this down, and ask questions later.

SQL Server security properties

Your security audit report should include the type of authentication mode used in the SQL Server (Windows or Mixed). You can also note how login attempts are logged and if any other security

specific options have been set (e.g. C2 audit mode). You can find out this information from the Security tab of the SQL Server property window.

Service account
Previous to SQL Server 2005, the account used to run the SQL Service needed administrator privilege in the local machine. This is no longer the case: a SQL service account does not need to be a local administrator anymore. The principle of least privilege dictates that the service account should be just like any other domain account with minimal permissions.

Unfortunately, many organisations still grant the SQL service account local and even domain administrator privileges. If your network is a mixture of 2000 and 2005 (and perhaps 2008), chances are that you will have machines running the newer versions of SQL Server with the old service account that has administrator privilege.

Your security audit should identify the account(s) used for running SQL Server, Agent and other related services like SSIS. You can check with your network administrators to see if the account is a

domain administrator. You should also check the local administrators group to see if the account is a member there (more on it later).

Sysadmin server role

Auditing the sysadmin server role will probably be the most important part of your audit. This is because SQL Server system administrators have almighty rights on the database server. They can add or drop databases, logins, linked servers, jobs or change any server configuration parameter. Unfortunately, there is a tendency in many SQL Server shops to grant unnecessary elevated permissions to individual user accounts. Applications accounts needing only database creation permission at installation time are made sysadmin members instead of being granted dbcreator privilege. Active Directory accounts of people who have left the company are often still found under the sysadmin fixed server role.

For SQL Server 2005 and latter versions, you can execute a script like the following to find out what login accounts are members of this role: SELECT c.name AS Sysadmin_Server_Role_Members FROM sys.server_principals a INNER JOIN sys.server_role_members b ON a.principal_id = b.role_principal_id AND a.type = 'R' AND a.name ='sysadmin' INNER JOIN sys.server_principals c

ON b.member_principal_id = c.principal_id

For SQL 2000, you can execute a command like the following: SELECT loginname AS Sysadmin_Server_Role_Member FROM syslogins

WHERE sysadmin = 1

There are a number of accounts which are members of sysadmin role by default. The sa account is one of them. SQL Service accounts become members of local Windows groups created at installation time. These groups are given sysadmin privilege in turn. Other service or application specific accounts

often need this privilege as part of their operation. However, if you find accounts under this role that should not be there in the first place, make notes.

Server level permission for logins

Instead of making a login a member of a fixed server role like the sysadmin, SQL Server now allows the DBA to assign specific server level rights to it. This allows a more granular control over an individual logins access rights. Examples of such rights are IMPERSONATE, TAKE OWNERSHIP, VIEW DEFINITION, CONTROL, CONNECT, CONTROL SERVER etc. Some of these rights apply at the server level (SERVER scoped), some to endpoints (more on it later) while others to logins.

You can run a simple query like the following to get a list of server level permissions for logins: SELECT a.name AS Login_Name, a.type_desc AS LoginType, b.permission_name AS Permission FROM sys.server_principals a INNER JOIN sys.server_permissions b ON a.principal_id = b.grantee_principal_id WHERE a.type <> 'R' -- Excludes Server Role AND a.name NOT LIKE '##MS_%' -- Excludes system level certificate mapped logins AND a.name <> 'sa' -- Excludes the obvious system administrator AND b.state = 'G' -- Granted

ORDER BY a.name

Login properties

Default database:

When logins are created at the server level, a default database is supposed to be assigned. This is the database the user will automatically connect to once his credentials are verified. If the default database is not specified explicitly, it is mapped to the master database. Since the master database

has a guest account (more about guest accounts later), the user is able to login successfully and find himself in the context of the all-important master database.

In my opinion, this is not an ideal practice as far as security is concerned. A login account whether representing a person or an application - should always have a non-system database assigned to it as the default database. The login can then be mapped to a user account in the default database. To find out which logins have master as the default database, you can execute a query like the following: USE master GO SELECT name as LoginName, type_desc AS LoginType FROM sys.server_principals WHERE type <> 'R' -- Excludes Server Role AND name NOT LIKE '##MS_%' -- Excludes system level certificate mapped logins AND name <> 'sa' -- Excludes the obvious system administrator

AND default_database_name = 'master'

Password policy:

From SQL Server 2005, native SQL Server login accounts can also be subject to Windows password policies such as complexity, length, expiration rules etc. - provided SQL Server is hosted on Windows Server 2003 or latter. This is generally a good idea because it allows you to enforce the same level of password restrictions as it is applied in Windows.

You can check if there are logins in your server that do not have any password policy attached to them. This does not necessarily mean a security violation though; there may be business rules in your organisation that prohibits assigning any password policy to SQL Server native logins. However, if there are no such rules, it is worthwhile to incorporate this check in your audit report. SELECT a.name AS SQL_Server_Login, CASE b.is_policy_checked WHEN 1 THEN 'Password Policy Applied'

ELSE 'Password Policy Not Applied' END AS Password_Policy_Status, CASE b.is_expiration_checked WHEN 1 THEN 'Password Expiration Check Applied' ELSE 'Password Expiration Check Not Applied' END AS Password_Expiration_Check_Status FROM sys.server_principals a INNER JOIN sys.sql_logins b

ON a.principal_id = b.principal_id

Disabled or locked-out logins:

Next, you may want to list the logins that are disabled or locked out. Executing the following query will help you here: SELECT name AS Disabled_LoginName FROM sys.server_principals

WHERE is_disabled = 1

Orphan logins:

Sometimes you may find a users Active Directory account has been deleted but it still exists as a login in your SQL Server. This happens because when the AD account is deleted, it does not automatically drop the associated trusted accounts from the SQL Server(s) in the network. Essentially, one or more database server is then left with an orphan login account. Although as far as the Windows domain controller is concerned, the user or group does not exist, you still need to know if your SQL Server thinks otherwise.

Executing the following query will give you a list of non-existent Windows accounts and groups that were given access to the SQL Server.

EXEC sp_validatelogins

Linked server logins and mapped accounts

Linked servers are widely used in distributed database applications. They provide access to data sources outside SQL Server. An external data source can be another instance of SQL Server or a different vendors product such as Oracle or DB2.

When a SQL Server query accesses external data using a linked server, it generally needs to authenticate itself to the remote data source. The authentication process generally happens in one of two ways: either the query uses an account already defined in the remote database or it can map a local SQL login account to a remote user account.

In the first case, SQL Server directly uses the remote servers account to validate itself. In the latter scenario, a local login maps to (and can impersonate) a user account in the remote database server.

A third way of accessing remote data is to use the account credentials of the user account running the query. Obviously in such cases the user account running the query locally needs to have access to the remote server as well.

You can inspect the security property of each linked server to see how connections are being made.

Alternately, you can run a query: SELECT a.name AS Linked_Server_Name, b.remote_name AS Connecting_as_Remote_User FROM sys.servers a INNER JOIN sys.linked_logins b ON a.server_id = b.server_id

WHERE b.uses_self_credential = 0

As with other findings, document your results. If connections are made through the remote servers system administrator credentials (sa or the SYS user), remember to ask why.

Server credentials
Credentials are created to provide native SQL Server login accounts access to external resources such as the file system or Windows. A credential contains a user name and password and typically corresponds to a Windows user account. When a credential is mapped to a SQL Server login, the login uses the privileges of the credentials underlying Windows account. You can view or create credentials from within SQL Server Management Studio.

Alternately, you can use the sys.credentials catalogue view:

SELECT * FROM sys.credentials

Listing the credentials and what accounts they map to should be part of your audit.

Proxy accounts
A proxy is a layer of abstraction above a credential. In fact credentials are mainly created for proxy accounts. You create a proxy that maps to an existing credential and the credential in turn corresponds to a Windows user account.

Proxies are used by SQL Server jobs. SQL Server jobs run within the Agent service framework and proxies are a way to give a jobs step access to various subsystems outside SQL Server. Examples of such subsystems are the operating system command shell, SSIS packages, Analysis service commands or the replication engine.

When a jobs step runs under the proxy account, the Agent service accesses the external subsystem by impersonating the underlying Windows account.

A proxy can have access to multiple subsystems. However, if a user (for example developers, DBAs) needs to use the proxy, she needs to have access to it. Like credentials, you can create or view proxies for different subsystems from the SQL Server Management Studio.

SQL Agent security

Scheduled jobs are common in most production data processing sites. Typically, these jobs are created by developers and DBAs. While members of the sysadmin server role used to be the only ones who could create and alter jobs, this is no longer the case from version 2005.

Three new roles have been added to the msdb database: SQLAgentUserRole, SQLAgentReaderRole and SQLAgentOperatorRole. Members of these database roles in msdb database have varying levels of access to the job system and can create or modify jobs and schedules. In your security audit, you may want to find out the members of these roles.

If you do not see any user accounts listed under these roles, you can to check the owners of the jobs defined in the SQL Server.

SELECT a.name AS JobName, b.name AS OwnerName FROM msdb.dbo.sysjobs a INNER JOIN sys.server_principals b

ON a.owner_sid = b.sid

Publication access list

If the database server is participating in replication as a publisher, it may be worthwhile to see who has access to its publications. The Publication Access List or PAL is a list of accounts that can connect to a publication and create/synchronise subscriptions against it.

Most of the accounts listed under the PAL should be system or service related. You may want to take note if you see Active Directory user accounts listed here.

Endpoints
The introduction of endpoints was one of the significant upgrades of SQL Server 2005 from its predecessors. Endpoints are like electric wall outlets or telephone cable ports for SQL Server. It is a connection mechanism used by a number of built-in features and technologies such as service broker or database mirroring.

A SQL Server endpoint is basically a port that listens for a particular type of traffic that uses a particular type of protocol. At present, the only two types of protocol supported are TCP and HTTP. The endpoint also will recognise only a definite type of traffic or payload. The payload for the

incoming connection can constitute raw T-SQL commands, SOAP messages (for web service applications), service broker or database mirroring traffic. Some of the endpoints are already present by default like the ones used by Dedicated Administrator Connection or T-SQL commands. Other endpoints - like the ones used for database mirroring - need to be created explicitly.

Endpoints are defined at a server level and like any other server level objects they can be granted permission to. Server level principals can be explicitly granted privilege to connect, take ownership or control endpoints.

If you are curious about non-default endpoints present in the SQL Server and any explicitly granted permission on them, you can run the following query: SELECT a.name AS Endpoint_Name, a.type_desc AS Endpoint_Type, b.name AS EndPoint_Owner, a.protocol_desc AS Endpoint_Protocol, c.permission_name AS Endpoint_Permission, c.state_desc AS Permission_Status, d.name AS Permission_Granted_To FROM sys.endpoints a INNER JOIN sys.server_principals b ON a.principal_id = b.principal_id INNER JOIN sys.server_permissions c ON a.endpoint_id = c.major_id INNER JOIN sys.server_principals d ON c.grantee_principal_id = d.principal_id WHERE a.is_admin_endpoint = 0

AND a.type_desc <> 'TSQL'