Configuration du sniffer DataSunrise pour MS SQL Server

La principale caractéristique de Microsoft SQL Server est que son application cliente principale, SQL Server Management Studio, nécessite toujours un chiffrement, même si la case « Encrypt connection » n’est pas cochée.

Cela signifie que, pour tout sniffer, il est impossible d’intercepter le trafic chiffré, sauf si le sniffer dispose de la clé privée du serveur pour sa décryption. Le sniffer DataSunrise peut décrypter le trafic SSL s’il possède la clé privée, nous allons donc nous attarder sur la configuration d’un serveur pour le fonctionnement de DataSunrise en mode sniffer.

Par défaut, le serveur est configuré pour fonctionner avec des clés éphémères — aucune clé ni certificat statique n’y est établi. Le certificat et la clé sont générés pour chaque connexion. Une telle stratégie garantit un niveau de sécurité élevé pour toutes les connexions au serveur. Il est donc clair que le fournisseur de cryptographie intégré de Microsoft, sur les versions les plus récentes de Windows, a augmenté le niveau de priorité de tous ses chiffrements éphémères. Et désormais, il devient plus difficile d’activer des chiffrements plus appropriés pour l’analyse du trafic sans une configuration supplémentaire du serveur.

Certificat

Pour désactiver les chiffrements éphémères et obtenir une clé privée statique, il est nécessaire d’installer un certificat. Cela peut être fait via le SQL Server Configuration Manager (fonctionnalité Protocols for MSSQLSERVER, paramètres SQL Server Network Configuration, onglet Certificate) :

Ici, nous pouvons sélectionner un certificat dans la liste qui est téléchargé depuis le magasin de certificats local de Windows.

Il existe certaines exigences de Microsoft pour la préparation du certificat.

1. Le certificat doit se trouver soit dans le magasin de certificats de l’ordinateur local, soit dans celui de l’utilisateur actuel.
2. L’heure système actuelle doit être postérieure à la date indiquée dans la propriété Valid from du certificat et antérieure à celle indiquée dans la propriété Valid to.
3. Le certificat doit être destiné à l’authentification du serveur. Cela nécessite que la propriété Enhanced Key Usage du certificat spécifie Server Authentication (1.3.6.1.5.5.7.3.1).
4. Le certificat doit être créé en utilisant l’option KeySpec de AT_KEYEXCHANGE.
5. La propriété Subject du certificat doit indiquer que le nom commun (CN) est identique au nom d’hôte ou au nom de domaine complet (FQDN) de l’ordinateur serveur. Si SQL Server fonctionne au sein d’un cluster de basculement, le nom commun doit correspondre au nom d’hôte ou au FQDN du serveur virtuel et les certificats doivent être déployés sur tous les nœuds du cluster de basculement.

Pour créer un certificat conforme à ces conditions, vous pouvez utiliser l’utilitaire Make Cert inclus dans le Windows SDK.

makecert -r -pe -n "CN= HERE24322118" -b 01/09/2016 -e 01/09/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

Dans cet exemple, le certificat « HERE24322118 » sera créé et placé dans le magasin de certificats local. À ce stade, ce certificat peut être sélectionné dans la liste des certificats du SQL Server Configuration Manager. Et après le redémarrage du serveur, il pourra être utilisé pour sécuriser les connexions réseau.

Clé du serveur

L’étape suivante consiste à obtenir la clé du serveur. Pour cela, il est nécessaire de l’exporter à partir d’un magasin de certificats, et d’extraire le fichier key.pem à partir de certname.pfx :

openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes

Key.pem est la clé privée requise par le sniffer.

<>Le serveur est configuré et sa clé privée est obtenue, mais il continue d’utiliser des algorithmes éphémères en raison du fournisseur de cryptographie. Pour désactiver les algorithmes d’échange de clés éphémères, il est nécessaire de se référer au guide Microsoft correspondant ou à son interprétation graphique — IIScrypto.

Ici, vous devez désactiver deux algorithmes d’échange de clés : Diffie-Hellman et ECDH. Les modifications prendront effet après le redémarrage du serveur hôte.

Installation de la clé dans DataSunrise

L’étape finale consiste à installer la clé dans DataSunrise. Pour ce faire, nous ouvrons l’onglet Configurations, sélectionnons la base de données requise, ouvrons la fenêtre Certificates, l’onglet PrivateKey et collons la clé privée copiée à partir du fichier.

La configuration du serveur et du firewall pour l’analyse du trafic SQL Server est terminée. Nous réfléchirons ensuite à comment simplifier et améliorer la protection de votre infrastructure.