Konfiguration des DataSunrise-Sniffers für MS SQL Server

Das wesentliche Merkmal von Microsoft SQL Server besteht darin, dass seine Hauptclient-Anwendung, SQL Server Management Studio, stets Verschlüsselung benötigt, selbst wenn das Kontrollkästchen „Verschlüsselte Verbindung“ nicht aktiviert ist.

Dies bedeutet für jeden Sniffer, dass es unmöglich ist, verschlüsselten Datenverkehr abzuhören – andernfalls würde der Sniffer einen privaten Serverschlüssel zur Entschlüsselung benötigen. Der DataSunrise-Sniffer kann SSL-Verkehr entschlüsseln, sofern er den privaten Schlüssel besitzt. Daher werden wir uns der Konfiguration eines Servers für den Betrieb von DataSunrise im Sniffer-Modus widmen.

Standardmäßig ist der Server so konfiguriert, dass er mit flüchtigen Schlüsseln arbeitet – es sind keine statischen Schlüssel oder Zertifikate für ihn festgelegt. Das Zertifikat sowie der Schlüssel werden bei jeder Verbindung neu generiert. Eine derartige Strategie garantiert ein hohes Maß an Sicherheit aller Serververbindungen. Es ist also klar, dass der integrierte Microsoft-Kryptoanbieter in den neuesten Windows-Versionen die Prioritätsstufe all seiner flüchtigen Chiffren erhöht hat. Dadurch wird es nun schwieriger, Chiffren zu aktivieren, die für das Sniffing geeigneter sind, ohne zusätzliche Serverkonfiguration.

Zertifikat

Um flüchtige Chiffren zu deaktivieren und einen statischen privaten Schlüssel zu erhalten, muss ein Zertifikat installiert werden. Dies kann über den SQL Server Configuration Manager durchgeführt werden (Protokolle für die MSSQLSERVER-Funktionen, Einstellungen der SQL Server-Netzwerkkonfiguration, Registerkarte Zertifikat):

Hier können wir ein Zertifikat aus der Liste auswählen, das aus dem lokalen Windows-Zertifikatspeicher hochgeladen wurde.

Es gibt einige Microsoft-Anforderungen für die Erstellung des Zertifikats.

1. Das Zertifikat muss entweder im Zertifikatspeicher des lokalen Computers oder im Zertifikatspeicher des aktuellen Benutzers hinterlegt sein.
2. Die aktuelle Systemzeit muss nach dem „Gültig ab“-Datum des Zertifikats und vor dem „Gültig bis“-Datum liegen.
3. Das Zertifikat muss für die Serverauthentifizierung vorgesehen sein. Dies erfordert, dass die Eigenschaft „Erweiterte Schlüsselverwendung“ des Zertifikats die Serverauthentifizierung (1.3.6.1.5.5.7.3.1) angibt.
4. Das Zertifikat muss unter Verwendung der KeySpec-Option AT_KEYEXCHANGE erstellt werden.
5. Die Subject-Eigenschaft des Zertifikats muss anzeigen, dass der Common Name (CN) mit dem Hostnamen oder dem vollqualifizierten Domänennamen (FQDN) des Servercomputers übereinstimmt. Wenn SQL Server in einem Failover-Cluster betrieben wird, muss der Common Name mit dem Hostnamen oder FQDN des virtuellen Servers übereinstimmen, und die Zertifikate müssen auf allen Knoten im Failover-Cluster bereitgestellt werden.

Um ein Zertifikat zu erstellen, das diesen Bedingungen entspricht, können Sie das im Windows SDK enthaltene MakeCert-Dienstprogramm verwenden.

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

In diesem Beispiel wird ein Zertifikat „HERE24322118“ erstellt und im lokalen Zertifikatspeicher abgelegt. In diesem Stadium kann dieses Zertifikat aus der Zertifikatsliste des SQL Server Configuration Managers ausgewählt werden, und nach einem Neustart des Servers zur Sicherung der Netzwerkverbindungen verwendet werden.

Serverschlüssel

Der nächste Schritt besteht darin, den Serverschlüssel zu erhalten. Hierzu muss er aus dem Zertifikatspeicher exportiert und key.pem aus certname.pfx extrahiert werden:

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

Key.pem ist der private Schlüssel, den der Sniffer benötigt.

<>Der Server ist konfiguriert und sein privater Schlüssel wurde extrahiert, aber er verwendet weiterhin flüchtige Algorithmen aufgrund des Kryptoproviders. Um die flüchtigen Schlüsselaustauschalgorithmen zu deaktivieren, muss auf die entsprechende Microsoft-Anleitung oder deren grafische Benutzeroberfläche – IIScrypto – verwiesen werden.

Hier müssen zwei Schlüsselaustauschalgorithmen deaktiviert werden: Diffie-Hellman und ECDH. Die Änderungen treten nach einem Neustart des Hostservers in Kraft.

Schlüsselinstallation in DataSunrise

Der letzte Schritt besteht darin, den Schlüssel in DataSunrise zu installieren. Dazu öffnen wir den Reiter „Konfigurationen“, wählen die erforderliche Datenbank aus, öffnen das Zertifikatsfenster, wechseln zur Registerkarte „Privater Schlüssel“ und fügen den aus der Datei kopierten privaten Schlüssel ein.

Die Konfiguration des Servers und der Firewall für das SQL Server-Sniffing ist abgeschlossen. Und wir werden darüber nachdenken, wie wir den Schutz Ihrer Infrastruktur einfacher und besser gestalten können.