1

Sécurisation d’une

infrastructure SQL Server (v4.08)

Tutorial conçu et rédigé par Michel de CREVOISIER – Février 2014

2

SOURCES « Best Practices » de sécurité pour SQL Server :

http://download.microsoft.com/download/8/F/A/8FABACD7-803E-40FC-ADF8-355E7D218F4C/SQL_Server_2012_Security_Best_Practice_Whitepaper_Apr2012.docx

http://blogs.msdn.com/b/sqlsecurity/

http://cdn.ttgtmedia.com/ITKE/uploads/blogs.dir/113/files/2009/04/chapter-8-sql-server-2008-management-and-administration.pdf

Sécurité et chiffrement de SQL Server :

http://www.greensql.com/content/10-must-do-sql-server-2012-security-tasks Comptes de service sous SQL Server 2012 :

http://msdn.microsoft.com/en-us/library/ms143504.aspx

ARTICLES RELATIONNES

Vous trouverez également d’autres articles en relation avec SQL Server :

Installation de SQL Server (tuto)

Sécurisation d’un serveur SQL (tuto)

SQL Server pentesting (tuto)

Outils pour SQL Server (tuto)

Installation de Reporting Services en mode natif (tuto)

Installation de Reporting Services en mode SharePoint (tuto)

Comptes et groupes de service (tuto)

3

INDEX

SOURCES .............................................................................................................................................................. 2

INDEX ................................................................................................................................................................... 3

1. Instance SQL ................................................................................................................................................ 4

1.1 Utilisation d’instances nommées ........................................................................................................ 4

1.2 Désactivation du service SQL Server Browser...................................................................................... 4

1.3 Masquage des instances ...................................................................................................................... 5

1.4 Utilisation d’instance statique ............................................................................................................. 5

2. Procédures et accès distant ........................................................................................................................ 6

2.1 Désactivation des procédures ............................................................................................................. 6

2.2 Désactivation des protocoles non-utilisés ........................................................................................... 6

3. Authentification et accès ............................................................................................................................ 8

3.1 Authentification « Windows » ............................................................................................................. 8

3.2 Renommage du compte « SA » ........................................................................................................... 8

3.3 Utilisation de groupes d’administration .............................................................................................. 8

3.4 Suppression du groupe « BUILTIN\Administrators » .......................................................................... 9

3.5 Activation de l’audit des logins ............................................................................................................ 9

4. Comptes de service ................................................................................................................................... 10

4.1 Types de comptes .............................................................................................................................. 10

4.2 Comptes par défaut ........................................................................................................................... 10

4.3 Recommandations ............................................................................................................................. 11

4.4 Changement de compte .................................................................................................................... 11

5. Système ..................................................................................................................................................... 13

5.1 Serveur dédié ..................................................................................................................................... 13

5.2 Installation minimale ......................................................................................................................... 13

5.3 Mises à jour ....................................................................................................................................... 13

5.4 Serveur « Core » ................................................................................................................................ 13

5.5 Pare-feu ............................................................................................................................................. 14

6. Outils de sécurité ...................................................................................................................................... 15

6.1 SQL Server Label Security Toolkit ................................................................................................... 15

6.2 SQL Server 2008-2012 Best Practices Analyser ............................................................................. 15

6.3 Microsoft Baseline Security Analyser ............................................................................................. 16

Conclusion ......................................................................................................................................................... 17

4

1. Instance SQL

1.1 Utilisation d’instances nommées Utilisez une instance nommée au détriment de l’instance par défaut lors de l’installation. En effet, l’instance par défaut est facilement accessible en raison de son nommage par défaut « MSSQLSERVER » et de son écoute sur le port TCP 1433, tous deux bien connus des hackers.

1.2 Désactivation du service SQL Server Browser

Comme expliqué au point 1.3 de mon tuto, le service SQL Server Browser (anciennement SSRP) a été

implémenté afin de répondre aux requêtes des clients en leur retournant le numéro de port associé à l’instance demandée. En écoute sur le port UDP 1434, ce service est une vraie porte ouverte pour les hackers puisqu’il leurs permet de facilement lister les instances hébergées sur le serveur.

Il convient donc de désactiver ce service et d’opter pour une configuration statique (point 1.4). Le

script PowerShell ci-dessous permet d’arrêter et de désactiver le service SQL Browser : Import-Module "SQLPS" -DisableNameChecking #Service $ServicesToDisable="SQLBrowser","SQLSERVERAGENT","MSSQLServerOLAPService " Foreach($service in $ServicesToDisable) { Stop-Service $service Set-Service $service -startuptype disabled }

Connexions entrantes

SQL Server Browser

sur port [1434]

Réponse avec [port] INSTANCE-1

Réponse avec [port] INSTANCE-2

5

1.3 Masquage des instances Si vous persistez à maintenir le service SQL Server Browser activé malgré les recommandations du point précédent, vous pouvez toujours « masquer » vos instances SQL. Pour cela :

Ouvrez SQL Server Configuration Manager

Clic droit sur Protocols for « instance » > Properties > Flags

Définissez ensuite l’option Hide instance à Yes

1.4 Utilisation d’instance statique

Pour les raisons expliquées au point 1.2, configurez votre instance en mode statique et non en mode

dynamique. Pour cela, référez-vous au point 6 de mon tuto sur SQL Server.

Pour passer le port de votre instance en mode statique via PowerShell : Import-Module "SQLPS" -DisableNameChecking #Variables $SQL_instance_port = "10000" $SQL_InstanceName='MSSQLSERVER' $ServerName=gc env:computername #Objects $m = New-Object ('Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer') $ServerName $urn = "ManagedComputer[@Name='$ServerName']/ServerInstance[@Name='$SQL_InstanceName']/ServerProtocol[@Name='Tcp']" $Tcp = $m.GetSmoObject($urn) $Enabled = $Tcp.IsEnabled #Enable TCP/IP if not enabled IF (!$Enabled) {$Tcp.IsEnabled = $true } #Set to listen $m.GetSmoObject($urn + "/IPAddress[@Name='IPAll']").IPAddressProperties[1].Value = $SQL_instance_port $TCP.alter()

6

2. Procédures et accès distant

2.1 Désactivation des procédures Apparu avec SQL Server 2005, Surface Area Configuration Manager était à l’origine présent sous forme de console à part entière et permettait d’administrer de nombreux paramètres de sécurité. Avec l’arrivée de SQL Server 2008, il fut directement intégré au sein d’SQL Server Management Studio. Pour des raisons de sécurité, il convient de désactiver certaines procédures « dangeureuses ». Pour cela :

Clic droit sur votre instance > Facets > Surface Area Configuration

Et désactivez les procédures suivantes :

o XP_CMDSHELL (permet d’exécuter une commande directement dans le système) o XP_SEND_DBMAIL o OPENROWSET o OPENDATASET o OLE AUTOMATION

2.2 Désactivation des protocoles non-utilisés

2.2.1 Protocoles d’accès Désactivez les protocoles activés par défaut à l’exception de TCP/IP. Si vous souhaitez uniquement fournir un accès local aux bases de données, activez le protocole Shared Memory (plus de détails au

point 1.4 de mon tuto sur SQL Server). Pour information, le protocole VIA n’est plus disponible depuis

SQL Server 2012.

7

Le script PowerShell suivant permet de désactiver ces protocoles :

Import-Module "SQLPS" -DisableNameChecking $ServerName=gc env:computername $SQL_InstanceName='MSSQLSERVER' $wmi = new-object ("Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer") $ServerName $wmi.ServerInstances[$SQL_InstanceName].ServerProtocols['Tcp'].IsEnabled = $True #TCP/IP $wmi.ServerInstances[$SQL_InstanceName].ServerProtocols['Tcp'].Alter() | out-null $wmi.ServerInstances[$SQL_InstanceName].ServerProtocols['Np'].IsEnabled = $False #Pipes $wmi.ServerInstances[$SQL_InstanceName].ServerProtocols['Np'].Alter() | out-null $wmi.ServerInstances[$SQL_InstanceName].ServerProtocols['Sm'].IsEnabled = $False #Memory $wmi.ServerInstances[$SQL_InstanceName].ServerProtocols['Sm'].Alter() | out-null

2.2.2 SQL Native client Désactivez les protocoles associés à cet utilitaire si vous n’en avez pas l’utilité. Vous trouverez plus

d’informations à son sujet au point 7.3 de mon tuto sur SQL Server.

Le script PowerShell suivant devrait théoriquement permettre de désactiver ces protocoles, mais il ne fonctionne pas. A toutes fins utiles, je vous le poste quand même : Import-Module "SQLPS" -DisableNameChecking $ServerName=gc env:computername $wmi = new-object ("Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer") $ServerName $wmi.ClientProtocols['Tcp'].IsEnabled = $False $wmi.ClientProtocols['Tcp'].Alter() $wmi.ClientProtocols['Np'].IsEnabled = $False $wmi.ClientProtocols['Np'].Alter() $wmi.ClientProtocols['Sm'].IsEnabled = $False $wmi.ClientProtocols['Sm'].Alter()

Note : testé sous Server 2008 R2 SP1 avec SQL Server 2008 R2 SP2 et Server 2012 avec SQL Server 2012 SP1

8

3. Authentification et accès

3.1 Authentification « Windows » Préférez l’utilisation d’une authentification Kerberos (alias Windows) au détriment d’une authentification Mixte (Windows + SQL). En effet le compte SA, encore une fois bien connu des hackers, peut facilement être compromis s’il ne dispose pas d’un mot de passe complexe. Ce mode d’authentification est défini lors des étapes d’installation mais peut facilement être modifié par la suite.

Note : en authentification SQL, les « credentials » sont envoyées sur le réseau pour l’authentification. Ce mode peut donc être sujet à une attaque de type « Man In the Middle »

3.2 Renommage du compte « SA » En accord avec le point précédent, désactivez le compte SA si vous n’en avez pas l’utilité. S’il vous est absolument nécessaire, renommez-le (uniquement possible depuis SQL Server 2008). Cela compliquera la tâche dans le cas d’une attaque par brutforce. Par ailleurs, il n’est pas recommandé d’utiliser ce compte pour l’administration du serveur SQL.

3.3 Utilisation de groupes d’administration

Il est recommandé d’administrer les accès aux instances SQL au travers de groupes de sécurité et non via des comptes utilisateurs individuels. En attribuant des rôles spécifiques à chaque groupe, vous serez en mesure de mieux administrer les accès tout en conservant une politique de gestion globale des autorisations. Vous pourrez par exemple créer un groupe membre du groupe SYSADMIN afin d’autoriser vos administrateurs à gérer le serveur SQL. Vous pourrez également créer un groupe destiné à vos développeurs, offrant un accès uniquement à certains rôles ou à certaines tables. Le script PowerShell ci-dessous permet d’ajouter un groupe AD avec le rôle SYSADMIN :

9

Import-Module "SQLPS" -DisableNameChecking $SQLAdminGroup="SG_SQL_Admin" $DomainName="lab" # Without .com, .local, ... Invoke-SqlCmd -Query "EXEC sp_addsrvrolemember '$DomainName\$SQLAdminGroup', 'sysadmin'" -ServerInstance "."

3.4 Suppression du groupe « BUILTIN\Administrators » Jusqu’à SQL Server 2005, le groupe BUILTIN\ Administrators possédait le privilège sysadmin. De facto, l’ensemble des administrateurs locaux disposaient des droits complets sur l’ensemble des instances hébergées. Pour supprimer ce privilège, exécutez la commande T-SQL ci-dessous : Use Master IF EXISTS (SELECT * FROM sys.server_principals WHERE name = N’BUILTIN\Administrators’) DROP LOGIN [BUILTIN\Administrators] GO

3.5 Activation de l’audit des logins Activez l’audit des logins « failed » et « successfull » afin d’auditer les comptes s’étant connecté à votre serveur :

10

4. Comptes de service L’utilisation d’un compte permettant l’exécution d’un service SQL doit faire l’objet d’un choix attentif. En effet, plus ce dernier disposera de privilèges élevés, plus le service et donc le serveur seront exposés à des risques de sécurité inutiles. Les lignes qui suivent ont donc pour objectifs de vous présenter les différents comptes utilisables afin de déterminer le plus adapté à votre infrastructure.

4.1 Types de comptes Ces huit types de comptes sont disponibles pour l’exécution des différents services liés à SQL Server:

Compte local : o Local user o Local user (Windows administrator) o Network Service account (NT AUTHORITY\NETWORK SERVICE) o Local System account (NT AUTHORITY\SYSTEM)

Compte utilisateur du domaine : o Domain user o Domain user (Windows administrator)

Comptes de service (cf. mon tuto consacré à ce sujet) : o Managed Service account (MSA) - supporté à partir de SQL Server 2012 o Virtual Service account (VSA)

4.2 Comptes par défaut Les tableaux ci-dessous synthétisent les comptes par défaut utilisés avec SQL Server 2012 :

Component (Stand-alone SQL) Windows Server 2008 Windows Server 2008 R2

Database Engine NETWORK SERVICE Virtual Account (VSA) *

SQL Server Agent NETWORK SERVICE Virtual Account (VSA) *

SSAS NETWORK SERVICE Virtual Account (VSA) *

SSIS NETWORK SERVICE Virtual Account (VSA) *

SSRS NETWORK SERVICE Virtual Account (VSA) *

SQL Server Distributed Replay Controller NETWORK SERVICE Virtual Account (VSA) *

SQL Server Distributed Replay Client NETWORK SERVICE Virtual Account (VSA) *

FD Launcher (Full-text Search) LOCAL SERVICE Virtual Account (VSA)

SQL Server Browser LOCAL SERVICE LOCAL SERVICE

SQL Server VSS Writer LOCAL SYSTEM LOCAL SYSTEM

Component (Failover instance) Windows Server 2008 Windows Server 2008 R2

Database Engine Provide a domain user act. Provide a domain user act.

SQL Server Agent Provide a domain user act. Provide a domain user act.

SSAS Provide a domain user act. Provide a domain user act.

SSIS NETWORK SERVICE Virtual Account

SSRS NETWORK SERVICE Virtual Account

FD Launcher (Full-text Search) LOCAL SERVICE Virtual Account

SQL Server Browser LOCAL SERVICE LOCAL SERVICE

SQL Server VSS Writer LOCAL SYSTEM LOCAL SYSTEM

11

* Si des ressources extérieures au serveur SQL sont nécessaires, Microsoft recommande l’utilisation

d’un MSA (point 4.1)

Ci-dessous, la liste des comptes VSA (6/7) utilisés nativement par SQL Server 2012 sous Server 2012 :

4.3 Recommandations

SQL Server 2012 est la première version à supporter les comptes MSA (point 4.1) pour l’exécution de

ses services. De facto, il convient d’opter pour ce type de compte dès qu’il en est possible, notamment pour l’instance SQL. Si ce choix ne vous est techniquement pas possible, optez pour un VSA ou un compte utilisateur du domaine avec une restriction d’accès au travers de la GPO « Deny log on locally ». Notez par ailleurs que les VSA et MSA ne peuvent pas être utilisés pour des instances en cluster en raison de leurs SID différents. Pour information, il n’est pas recommandé d’utiliser des comptes « built-in » (Local Service, Local System et Network Service) étant donné qu’ils héritent de certains privilèges élevés liés à l’Active Directory :

Le compte Network Service intègre le même niveau d’accès qui est attribué au groupe « Utilisateurs ». Il est autorisé à s’authentifier sur l’ensemble du réseau en utilisant le compte ordinateur et peut de ce fait interagir avec d’autres services sur le réseau

Le compte Local System confère les pleins droits à l’utilisateur sur l’ordinateur local. Il possède le privilège de pouvoir créer ou supprimer ses propres SPNs. En revanche, il ne peut en aucun cas s’accorder de droits sur le réseau

Le compte Local Service possède le même niveau d’accès que les membres du groupe de l’utilisateur. Cet accès limité lui confère une protection contre les violations de service

4.4 Changement de compte

Important : vous devez toujours utilisez la console SQL Server Configuration Manager (ou PowerShell) pour changer un compte ou un mot de passe associé à un service SQL. En effet, en dehors du changement de compte, l’application effectue des modifications supplémentaires telles que la mise à jour du magasin local de sécurité qui protège la « master key » du moteur de la base de données.

12

Le script PowerShell ci-dessous permet de modifier le compte d’exécution d’un service (ici celui de l’instance SQL) en utilisant un compte du domaine (ne fonctionne pas avec un compte MSA): Import-Module "SQLPS" -DisableNameChecking $SQL_InstanceName='MSSQLSERVER' # Use simple '' $SQLSvcAccountPassword = 'Password123' $DomainName="domain" # Without .com, .local, ... $SQLSvcAccountUsername = "$DomainName\sql-account" $service="name='$SQL_InstanceName'" #Getting SQL Service name $svc=gwmi win32_service -filter $service $svc.StopService() | out-null $svc.change($null,$null,$null,$null,$null,$null,$SQLSvcAccountUsername,$SQLSvcAccountPassword,$null,$null,$null) | out-null $svc.StartService() | out-null

13

5. Système

5.1 Serveur dédié Hébergez toujours vos serveurs SQL sur un serveur dédié et non sur un serveur hébergeant d’autres ressources (SSAS, serveur web IIS, logiciels métier, AD …).

5.2 Installation minimale Installez votre instance SQL avec le minimum de fonctionnalités. En règle générale, l’instance ainsi que les outils de management suffisent largement. Cela permet de réduire les fonctionnalités activées tout limitant l’utilisation de ressources inutiles. Par ailleurs, évitez absolument les « installations par défaut ».

5.3 Mises à jour

Maintenez à jour votre système d’exploitation en appliquant les dernières mises à jour et correctifs de sécurité. Appliquez également les Service Pack et Cumulative Update propres à SQL Server.

5.4 Serveur « Core » Une des principales nouveautés de SQL Server 2012 est le support de la version Core sur les systèmes Server 2008 R2 et 2012. L’intérêt d’un tel mode est avant tout de réduire la surface d’exposition de votre serveur afin de restreindre son champ d’attaque. Par la même occasion, cela permet de réduire la consommation de ressources tout en limitant les opérations de maintenance. Notez toutefois que certaines fonctionnalités ne sont pas supportées avec ce mode (détails et installation détaillée ici).

14

5.5 Pare-feu Pour terminer, il convient de créer ses règles de pare-feu en entrée afin de pallier d’éventuelles maladresses :

Configuration dynamique (SQL Browser activé) : bloquez le port TCP 1433

Configuration statique : bloquez le port TCP 1433 et le port UDP 1434. Vous pouvez

également désactiver le service SQL Browser (point 1.2)

Pour créer ces règles en PowerShell sous Windows Server 2012 ou supérieur : #Variables $SQL_path="C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn\sqlservr.exe" #Path for SQL Server 2012 (not 2014) $SQL_instance_port = "11000" #Rules New-NetFirewallRule -DisplayName "SQL instance" -Direction Inbound -LocalPort $SQL_instance_port -Protocol TCP -Action Allow -program $SQL_path -group "SQL Server" | out-null New-NetFirewallRule -DisplayName "Block SQL Browser" -Direction Inbound -LocalPort 1434 -Protocol UDP -Action Block -group "SQL Server" | out-null New-NetFirewallRule -DisplayName "Block Default instance" -Direction Inbound -LocalPort 1433 -Protocol TCP -Action Block -group "SQL Server" | out-null

15

6. Outils de sécurité

6.1 SQL Server Label Security Toolkit Il s’agit d’un outil permettant d’implémenter des règles de type « Row-level security » (RLS) et « Cell-level security » (CLS) basées sur les labels de sécurité. Téléchargement ici.

6.2 SQL Server 2008-2012 Best Practices Analyser

Cet outil requiert l’installation préalable de Microsoft Baseline Configuration Analyser 2.0 (téléchargement). L’outil est disponible ici pour SQL Server 2008 R2 et ici pour SQL Server 2012.

16

Ci-dessous les résultats d’une analyse :

6.3 Microsoft Baseline Security Analyser

Au même titre que Baseline Configuration Analyser, cet outil vous fournira d’autres informations (encore plus pertinentes) liées à la sécurité de votre serveur SQL.

17

Conclusion Grâce à ces recommandations visant à sécuriser vos serveurs SQL, vous êtes maintenant en mesure de réduire leur surface d’exposition de façon à limiter les vecteurs potentiels d’intrusion.

N’hésitez pas à m’envoyer vos commentaires ou retours à l’adresse suivante : m.decrevoisier A-R-0-B-A-5 outlook . com

Soyez-en d’ores et déjà remercié