Wie Sie Ihre SQL Server-Datenbank mit DataSunrise vor MITM-Angriffen schützen
1 Was ist MITM?
Wenn ein Client über einen gesicherten Kanal zu einem Server verbindet, besteht das Risiko, dass sich eine dritte Partei zwischen sie schaltet und die Möglichkeit hat, den Verkehr abzuhören und zu stören. Netzwerkangriffe, die mit solch einer dritten Partei durchgeführt werden, werden als Man-in-the-Middle (MITM) Angriffe bezeichnet. Es gibt viele Möglichkeiten, einen solchen Angriff durchzuführen, aber das grundlegende Prinzip ist es, den Client heimlich mit dem Server des Angreifers zu verbinden.
2 Wie kann man sich vor MITM schützen?
Die wichtigste Methode zur Abwehr von MITM-Angriffen besteht in der Analyse der Netzwerkinfrastruktur zum Zeitpunkt der Verbindung zum Server und der Erkennung von verdächtigen Parametern, die für eine Verbindung zu einem bestimmten Server nicht typisch sind. Wenn das SSL-Protokoll zum Schutz verwendet wird, kann ein Client das Zertifikat des Servers während des Handshakes überprüfen. Ein Zertifikat kann viele Parameter enthalten, die während der Authentifizierung zwischen dem Client und dem Server ausgetauscht werden. Die gängige Praxis für SSL ist es, eine Verbindung sofort zu beenden, wenn eine Partei einen Parameter (Verzeichnisname, DNS, E-Mail, GUID, IP, UPN, URL und andere) akzeptiert, der nicht relevant für die Parameter seiner Umgebung ist. Eine solche Zertifikatsprüfung kann jedoch keine vollständige Sicherheit garantieren, da die Infrastruktur des Clients zum Zeitpunkt des Angriffs erheblich geändert werden kann, um die Prüfung zu bestehen. Daher werden oft zusätzliche Methoden zur Zertifikatsvalidierung verwendet. Eine solche Methode ist die Signatur des Zertifikats durch eine vertrauenswürdige Instanz. Es wird angenommen, dass eine solche Signatur nicht gefälscht werden kann und jeder Client ihre Authentizität überprüfen kann. Daher wird jedes Zertifikat, das von einer speziellen Instanz signiert wurde, als mehr oder weniger sicher angesehen, abhängig von der Autorität des Ausstellers.
3 Schutz vor MITM in MS SQL Server
Zertifikatsprüfung ist in MS SQL optional, aber standardmäßig aktiviert. Zwei wichtige Parameter, die an einer Zertifikatsprüfung teilnehmen, sind das Ablaufdatum des Zertifikats und der Name des Hosts, für den das Zertifikat ausgestellt wird (Common Name). Wenn ein Zertifikat abgelaufen ist oder nicht für den Host eines Servers ausgestellt wurde, mit dem eine Verbindung hergestellt wird, wird die Verbindung sofort mit Benachrichtigung des Benutzers beendet. Wenn eine Zertifizierungsstelle an einer zusätzlichen Zertifikatsprüfung beteiligt ist, wird der Client dessen Signatur überprüfen. In solchen Fällen sollte es ein Stammzertifikat dieser Instanz im Zertifikatspeicher geben. Viele moderne Betriebssysteme umfassen vorgebaute Sets von Stammzertifikaten der vertrauenswürdigsten Stellen, daher wäre es klug, eine Zertifizierungsstelle aus dieser Liste auszuwählen, wenn ein Unternehmenszertifikat signiert wird.
In modernem SSMS gibt es ein zusätzliches Kontrollkästchen “Serverzertifikat vertrauen” auf der Serververbindungsseite. Es wird verwendet, um das Zertifikat des Servers zu überprüfen. Wenn eine Verbindung zu einem Server über ODBC hergestellt wird, gibt es in der Verbindungszeichenfolge einen zusätzlichen Parameter “TrustServerCertificate”. Der Wert “ja” deaktiviert die Prüfung und “nein” aktiviert sie.
4 Zertifikate bei DataSunrise
DataSunrises Proxy ist vertrauenswürdig, aber dennoch eine dritte Partei der Verbindung, weshalb alle Client-Schutzmaßnahmen gegen MITM zum Zeitpunkt der Verbindung mit einem solchen Proxy aktiviert werden.
In DataSunrise arbeitet jede Datenbankinstanz mit einem Satz privater Schlüssel und einem Zertifikat. Aus Sicht des Clients gehört dieser Satz zum Server, aber im Allgemeinen sind diese Schlüssel in keiner Weise mit dem Endserver verbunden, der DataSunrises Proxy bedient. Es ist dieses Zertifikat, das ein Client überprüfen wird, wenn der Schutz vor MITM aktiviert ist.
5 Mögliche DataSunrise-Konfigurationen einschließlich des Schutzes vor MITM
Um ein ähnliches Schutzniveau für direkte Verbindungen und Proxy-Verbindungen zu gewährleisten, ist es erforderlich, DataSunrises und Clients Hosts korrekt zu konfigurieren. Es könnten mehrere Konfigurationsoptionen geben.
Eine Standardsatz von Schlüsseln und ein Zertifikat bieten minimalen Schutz. Es ist nicht garantiert, dass das Standardzertifikat dem CN=DataSunrise Database Security Suite Hostnamen entspricht. Deshalb sollten Sie als erstes zur Absicherung einer Verbindung einen neuen Schlüsselsatz und ein neues Zertifikat erzeugen.
Ein grundlegender Schlüsselsatz und ein Zertifikat sind in die proxy.pem Datei enthalten. Diese Datei sollte ersetzt werden.
5.1 Allgemeiner Fall
Dies ist der einfachste Fall, wenn ein Administrator nur über eine Instanz von DataSunrise verfügt, und einen MS SQL Server. Und es gibt eine begrenzte, etablierte Anzahl von Clients, die Zugang zu den gegebenen Servern über DataSunrise erhalten können. Dieser Fall beinhaltet zwei Optionen:
5.1.1 Erzeugung von proxy.pem (selbstsigniertes Zertifikat)
Dies ist die einfachste Methode zur Generierung neuer Schlüssel. Erstelle eine proxy.cfg Datei (“commonName” sollte den aktuellen Namen des DataSunrise-Hosts enthalten):
[req]
distinguished_name = req_distinguished_name
prompt = no
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = Sunrise
organizationalUnitName = IT
commonName = wmserver.db.local
emailAddress = [email protected] Führen Sie die folgende .bat-Datei im Ordner aus, in dem sich die Proxy.config-Datei befindet:
SET RANDFILE=random
SET PASS=R0T3qSW2s0459koH54
openssl genrsa -des3 -passout pass:%PASS% -out key.pem 2048
openssl rsa -passin pass:%PASS% -in key.pem -out key.pem
openssl req -config proxy.cfg -new -key key.pem -out certificate.req
openssl req -sha384 -x509 -config proxy.cfg -days 365 -key key.pem -in certificate.req -out certificate.cer
openssl ecparam -genkey -name secp256r1 -out ec.pem
openssl dhparam -out dh.pem 1024
COPY certificate.cer+key.pem+dh.pem+ec.pem proxy.pem /b
DEL random certificate.req key.pem dh.pem ec.pem Nach Ausführung des Skripts sollten wir eine Proxy.pem-Datei mit einem 2048-Bit RSA-Schlüssel, einem 1024-Bit DH-Schlüssel, EC-Parametern mit “secp256r1”-Kurve und einem für 365 Tage ausgestellten Zertifikat mit “sha384”-Signieralgorithmus erhalten.
Zusätzlich sollte eine Zertifikat.cer Datei erzeugt werden, die in den vertrauenswürdigen Zertifikatsspeicher des Clients installiert werden sollte.
5.1.2 Installation eines Zertifikates und Proxy-Schlüssel über die Benutzeroberfläche
Wenn ein Benutzer bereits einen Satz von Schlüsseln und ein Zertifikat hat, könnten diese über die DataSunrise Web-Benutzeroberfläche installiert werden.
Um Schlüssel und ein Zertifikat für einen Proxy zu setzen, führen Sie das Folgende aus:
- Erstellen Sie eine SSL Key Gruppe mit dem Typ Clientseite.
- Füllen Sie diese Gruppe mit allen notwendigen Parametern in Base64-Kodierung: ein Zertifikat, einen privaten Schlüssel, DH-Parameter, EC-Parameter
- Verbinden Sie diese Gruppe mit einer Instanz, indem Sie sie aus der Schlüsselgruppenliste auswählen
Die beiden Optionen (5.1.1 und 5.1.2) erfordern, dass Sie den Kern von DataSunrise neu starten, nachdem Sie die Schlüssel ersetzt haben, und ein für DataSunrise erstelltes Zertifikat in einem vertrauenswürdigen Zertifikatspeicher auf der Client-Seite installieren.
5.2 Mehrere DataSunrise-Instanzen
Die nächste Konfiguration ist für mehrere Instanzen von DataSunrise. Wenn Sie die oben beschriebenen Tipps des allgemeinen Falles verwenden, wäre es notwendig, ein ganzes Set von Zertifikaten auf der Client-Seite zu installieren und deren Anwendbarkeit im Auge zu behalten. Um mögliche Fehler zu vermeiden, können Sie alle Zertifikate mit einer einzigen Zertifizierungsstelle signieren. Es gibt auch hier zwei Möglichkeiten.
5.2.1 Ihre eigene Zertifizierungsstelle
Diese Option betrifft die Erstellung Ihrer eigenen Zertifizierungsstelle ohne zusätzliche Abhängigkeiten vom Betriebssystem. Die Autorität eines solchen Zertifikatausstellers wäre minimal.
Bereiten Sie die Infrastruktur vor:
mkdir db
mkdir db\new
mkdir db\private
echo. 2>db\index
echo 01> ./db/serial
echo unique_subject = no> ./db/index.attr Füllen Sie die Datei ca.cfg aus:
[req]
distinguished_name = req_distinguished_name
prompt = no
RANDFILE = ./db/private/.rand
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = DataSunrise
organizationalUnitName = IT
commonName = DataSunrise
emailAddress = [email protected] Füllen Sie die Datei proxy.cfg aus:
[req]
distinguished_name = req_distinguished_name
prompt = no
RANDFILE = ./db/private/.rand
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = Sunrise
organizationalUnitName = IT
commonName = wmserver.db.local
emailAddress = [email protected]
[ca]
default_ca = CA_default
[CA_default]
dir = ./db # top dir
database = $dir/index # index file.
new_certs_dir = $dir/new # new certs dir
certificate = $dir/ca.cer # The CA cert
serial = $dir/serial # serial no file
private_key = $dir/private/ca.pem # CA private key
RANDFILE = $dir/private/.rand # random number file
default_days = 365 # how long to certify for
default_crl_days = 30 # how long before next CRL
default_md = sha384
policy = policy_any # default policy
email_in_dn = no # Don't add the email into cert DN
name_opt = ca_default # Subject name display option
cert_opt = ca_default # Certificate display option
#copy_extensions = none # Don't copy extensions from request
[policy_any]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional Generieren Sie ein Root-Zertifikat ./db/ca.cer und ein Schlüssel ./db/private/ca.pem. Dieses Zertifikat (sein Schlüssel) wird verwendet, um alle zukünftigen Zertifikate zu signieren. Daher sollte ./db/ca.cer in einen vertrauenswürdigen Zertifikatsspeicher aller Clients installiert werden, die DataSunrise Zertifikate überprüfen:
./db/private/ca.pem:
SET RANDFILE=.\db\private\.rand
SET PASS=TxK7T88C27
openssl genrsa -des3 -passout pass:%PASS% -out .\db\private\ca.pem 2048
openssl rsa -passin pass:%PASS% -in .\db\private\ca.pem -out .\db\private\ca.pem
openssl req -new -x509 -days 3650 -key .\db\private\ca.pem -out .\db\ca.cer -config ca.cfg
openssl x509 -noout -text -in .\db\ca.cer Generieren und signieren von proxy.pem:
SET RANDFILE=.\db\private\.rand
SET /P serial=<.\db\serial
SET PASS=RTqSWs0koH
openssl genrsa -des3 -passout pass:%PASS% -out .\db\private\%serial%.pem 2048
openssl rsa -passin pass:%PASS% -in .\db\private\%serial%.pem -out .\db\private\%serial%.pem
openssl req -new -key .\db\private\%serial%.pem -nodes -config proxy.cfg -out .\db\private\%serial%.req
openssl ca -batch -config proxy.cfg -infiles .\db\private\%serial%.req
openssl ecparam -genkey -name secp256r1 -out .\db\private\%serial%.ec.pem
openssl dhparam -out .\db\private\%serial%.dh.pem 1024
COPY .\db\new\%serial%.pem+key.pem+.\db\new\%serial%.dh.pem+.\db\new\%serial%.ec.pem proxy.pem /b
MOVE .\db\new\%serial%.pem .\db\new\%serial%.cer Erstellte Zertifikate werden im Ordner db\new\ gespeichert
Generierte Schlüssel und gepackte pfxs (Schlüssel und Zertifikat) werden im Ordner db\private\ gespeichert
Beispiel. Ein Satz Schlüssel Nummer “01”:
db\new\01.cer — Neues Zertifikat db\private\01.pem — Neuer privater RSA-Schlüssel db\private\01.dh.pem — Neue DH-Parameter db\private\01.ec.pem — Neue Parameter und EC-Schlüssel
Bei jeder Generierung von proxy.pem wird ein neuer Satz Schlüssel erstellt. Es wird einem neu generierten proxy.pem entsprechen. Nach dem Ersetzen von proxy.pem in DataSunrise ist es notwendig, den Kern neu zu starten, damit die Änderungen in Kraft treten. Mit einem neuen Satz Schlüssel können Sie auch die Methode 5.1.2 zum Hinzufügen der Schlüssel zur Benutzeroberfläche verwenden, ohne die proxy.pem zu ändern.
5.2.2 Betrieb einer unternehmenseigenen Zertifizierungsstelle
Wenn es erforderlich ist, mehrere Client-Hosts zu schützen, oder es gibt mehrere DataSunrise-Hosts, die in ein Unternehmensnetzwerk (Domain) oder mehrere vertraute Netzwerke (Forest) eingebunden sind, wäre es praktisch, Active Directory Certificate Services zu verwenden. In diesem Fall können Sie certreq verwenden, um eine proxy.pem zu generieren. Nehmen wir eine proxy.cfg, die in subs. 5.1.1. beschrieben wird, und generieren eine proxy.pem (die Befehle sollten als Benutzer mit ausreichenden Privilegien zur Ausstellung neuer Zertifikate oder als Domänenadministrator ausgeführt werden):
SET RANDFILE=random
SET PASS=89RT90qSWs020koH12
openssl genrsa -des3 -passout pass:%PASS% -out key.pem 2048
openssl rsa -passin pass:%PASS% -in key.pem -out key.pem
openssl req -new -config proxy.cfg -x509 -days 365 -key key.pem -out certificate.req
certreq -submit -attrib "CertificateTemplate:WebServer" certificate.req certificate.cer
openssl ecparam -genkey -name secp256r1 -out ec.pem
openssl dhparam -out dh.pem 1024
COPY certificate.cer+key.pem+dh.pem+ec.pem proxy.pem /b
DEL random certificate.req certreq zeigt ein Dialogfeld an, um ein Unternehmenszertifizierungszentrum auszuwählen, das zur Ausstellung eines neuen Zertifikats verwendet werden soll. Normalerweise ist es nur ein Zentrum in einer solchen Liste:
Aber das hängt von der Unternehmensdomäneninfrastruktur ab. Konsultieren Sie bei Bedarf Ihren Administrator.
Nach der Installation der proxy.pem sind keine zusätzlichen Konfigurationen des Netzwerkclients erforderlich, da nach der Installation von AD CS das Stammzertifikat alle Hosts der Domäne/Wald automatisch abdeckt.
Mit Hilfe eines Schlüsselsatzes und eines Zertifikats (certificate.cer, key.pem, dh.pem, ec.pem) können Sie auch die in subs. 5.1.2 beschriebene Methode verwenden, um Schlüssel über die Web-Benutzeroberfläche hinzuzufügen, ohne die proxy.pem zu ändern.
5.3 Viele Clients
Wenn Sie ein Zertifikat auf eine große Anzahl von Clients anwenden müssen, können Sie Gruppenrichtlinien verwenden. Weitere Informationen finden Sie im folgenden Microsoft-Leitfaden: https://technet.microsoft.com/en-us/library/cc770315%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 (Bereitstellen von Zertifikaten mit Gruppenrichtlinie).
6 Schluss
Mit jeder der oben beschriebenen Methoden können Sie ein hohes Sicherheitsniveau für die Proxy-Verbindung erreichen, aber es liegt an Ihnen, die Methode zu wählen, die am besten zu Ihrer Infrastruktur passt. Um die volle Sicherheit für Ihre SQL Server-Datenbank zu gewährleisten, können Sie die folgenden DataSunrise-Tools verwenden:
