Konfigurieren der Firewall zur Arbeit mit dem Kerberos-Authentifizierungsprotokoll

Benannt nach dem dreiköpfigen Hund, der in alten griechischen Mythen die Tore der Unterwelt bewacht, bietet das Kerberos-Protokoll einen sicheren Authentifizierungsdienst für Computernetzwerke. Es führt eine gegenseitige Authentifizierung zwischen dem Benutzer und dem Server mithilfe eines vertrauenswürdigen Drittanbieters, des Key Distribution Centers (KDC), durch, das Authentifizierungs- und Ticketvergabedienste bereitstellt. Alle großen Betriebssysteme, einschließlich Microsoft Windows, Linux, Apple OS X und FreeBSD, unterstützen das Kerberos-Protokoll.

Kerberos-Protokollnachrichten sind durch gemeinsame Geheimnis-Kryptographie gegen Replay-Angriffe und Abhören geschützt. Das Hauptziel von Kerberos besteht darin, die Übertragung von verschlüsselten Passwörtern über das Netzwerk zu vermeiden. Es eliminiert die Bedrohung durch Paket-Sniffer und erhöht die Gesamtsicherheit des Netzwerks.

Obwohl der Kerberos-Security-Support-Anbieter effektiv mit schweren Sicherheitsbedrohungen umgehen kann, kann die Implementierung aufgrund einer Vielzahl von Einschränkungen schwierig sein:

• Wenn der Kerberos-Server ausfällt, können sich Benutzer nicht anmelden. Das Problem kann durch die Verwendung von Fallback-Authentifizierungsmechanismen und mehreren Kerberos-Servern gelöst werden.
• Die Uhren der beteiligten Hosts müssen synchronisiert sein. Andernfalls schlägt die Authentifizierung fehl, da Kerberos-Tickets eine bestimmte Verfügbarkeitsdauer haben.
• Kerberos kann nicht verwendet werden, wenn Benutzer von nicht vertrauenswürdigen Systemen auf Dienste zugreifen möchten.
• Im Falle der Verwendung symmetrischer Kryptographie ermöglicht das Kompromittieren der Authentifizierungsinfrastruktur einem Angreifer, sich als beliebiger Benutzer auszugeben.
• Jeder Netzwerkdienst, der einen anderen Hostnamen erfordert, benötigt sein eigenes Satz von Kerberos-Schlüsseln.

Wie Kerberos-Authentifizierung funktioniert

Das Key Distribution Center besteht aus dem Authentifizierungsserver (SS) und dem Ticket Granting Server (TGS). TGT ist ein Ticket Granting Ticket.

1. Der Benutzer gibt Anmeldeinformationen und Passwort ein. Der Klartext-Benutzer-ID geht an den Authentifizierungsserver (AS) mit einer Dienstanforderung im Namen des Benutzers.
2. AS überprüft, ob der Benutzerlogin sich in der Datenbank befindet. Wenn Informationen über diesen Benutzer vorliegen, kann AS den Client-Schlüssel gemäß der Benutzer-ID und dem Passwort generieren. AS sendet dem Benutzer:
   • Client/TSG-Session-Schlüssel (verschlüsselt mit Client-Geheimschlüssel);
   • TGT, einschließlich Benutzer-ID, Netzwerkadresse und Ticket-Gültigkeitsdauer + Client/TGS-Session-Schlüssel (verschlüsselt mit TGS-Geheimschlüssel).
3. Der Benutzer dekodiert die erste Nachricht, kann aber die zweite nicht dekodieren, da der Benutzer den TSG-Geheimschlüssel nicht besitzt. Der Client sendet folgende Nachricht an TGS:
   • TGT, das von AS empfangen wurde + Server-ID + TGS/Client-Geheimschlüssel (verschlüsselt mit TGS-Geheimschlüssel);
   • Authenticator, einschließlich Client-ID und Zeitstempel (verschlüsselt mit Client/TSG-Session-Schlüssel).
4. TGS entschlüsselt die erste Nachricht, erhält TGT + TGS/Client-Session-Schlüssel, mit dem es die zweite Nachricht entschlüsselt. TGS überprüft, ob die Benutzer-ID aus der ersten Nachricht mit der ID aus der zweiten Nachricht übereinstimmt und ob der Zeitstempel die Ticket-Gültigkeitsdauer nicht überschreitet. Wenn alles richtig ist, sendet TSG dem Benutzer:
   • Benutzer-ID, Netzwerkadresse, Ticket-Gültigkeitsdauer + Client/Server-Session-Schlüssel (verschlüsselt mit Server-Geheimschlüssel);
   • Client/Server-Session-Schlüssel (verschlüsselt mit Client/TGS-Geheimschlüssel).
5. Der Client sendet folgendes an den Server, auf den er zugreifen möchte:
   • Benutzer-ID, Netzwerkadresse, Ticket-Gültigkeitsdauer + Client/Server-Session-Schlüssel (verschlüsselt mit Server-Geheimschlüssel);
   • Authenticator, einschließlich ID und Zeitstempel (verschlüsselt mit Client/Server-Session-Schlüssel).
6. Der Zielserver entschlüsselt die Nachrichten des Benutzers, überprüft, ob die Benutzer-ID aus beiden Nachrichten den gleichen Wert hat und ob die Gültigkeitsdauer nicht überschritten ist, und sendet dem Client den folgenden Parameter zur Bestätigung seiner Identität:
   • Zeitstempel + 1 (verschlüsselt mit Client/Server-Session-Schlüssel)

Der Client überprüft, ob der Zeitstempelwert Zeitstempel + 1 ist, was die wahre Identität des Servers zeigt. Wenn dies der Fall ist, kann der Client dem Server vertrauen und mit ihm arbeiten.

Konfigurieren der Firewall zur Arbeit mit dem Kerberos-Authentifizierungsprotokoll

DataSunrise-Datenbank-Firewall unterstützt das Kerberos-Authentifizierungsprotokoll. Einige Einstellungen müssen vorgenommen werden, um Kerberos-Operationen zu ermöglichen; diese können je nach verwendetem RDBMS-Produkt variieren. In diesem Artikel zeigen wir, wie Kerberos auf dem MS SQL Server angepasst werden kann.

Bei der Arbeit im Active Directory wird die Benutzerautorisierung über die Security Support Provider Interface (SSPI) durchgeführt. Es gibt zwei Protokolle, die verwendet werden können: NTLM und Kerberos. NTLM ist ein langsameres und weniger sicheres Protokoll, daher betrachten wir nur die Anpassung von Kerberos. Um Kerberos zu aktivieren, müssen mehrere Bedingungen erfüllt sein:

1. Delegation für Active Directory-Benutzer und -Computer muss aktiviert sein.
   • Gehen Sie zu Active Directory-Benutzer und -Computer.
   • Finden Sie das Computerkonto, auf dem DataSunrise installiert ist.
   • Gehen Sie zur Registerkarte “Delegation” und wechseln Sie in den Zustand „Trust this computer for delegation to any service“.
2. Die Proxy-Adresse muss mit dem registrierten SPN des MSSQLSvc-Dienstes übereinstimmen. Verwenden Sie das SetSPN-Tool, um zwei erforderliche SPNs für das Konto des Computers zu registrieren, für den Sie die Delegation erlaubt haben: setspn -A MSSQLSvc/proxy-host:proxy-port proxy-host setspn -A MSSQLSvc/full-fqdn-proxy-host:proxy-port proxy-host

   Die Liste aller registrierten SPNs kann mit dem folgenden Befehl abgerufen werden:

   setspn -L proxy-host

   Um den SPN-Proxy zu löschen, führen Sie folgendes aus:

   setspn -D MSSQLSvc/proxy-host:proxy-port proxy-host

   Um das Autorisierungsschema zu testen, führen Sie den folgenden Befehl nach dem Verbinden mit dem Server aus:

   select auth_scheme from sys.dm_exec_connections where session_id=@@spid

   Das Ergebnis entspricht dem auf dem Server verwendeten Authentifizierungsschema: SQL, NTLM oder KERBEROS.

3. Falls Sie den Fehler “Cannot generate SSPI context” erhalten, beziehen Sie sich auf die Microsoft-Support-Anweisungen, um das Problem mit der Sicherheits-Provider-Schnittstelle zu beheben.