Firewall-Konfiguration mit dem Kerberos-Authentifizierungsprotokoll

Benannt nach dem dreiköpfigen Hund, der in den antiken griechischen Mythen die Tore zu Hades bewacht, bietet das Kerberos-Protokoll einen sicheren Authentifizierungsdienst für Computernetzwerke. Es führt eine gegenseitige Authentifizierung zwischen dem Benutzer und dem Server durch, indem es die Hilfe eines vertrauenswürdigen dritten Parteien, dem Key Distribution Center (KDC), nutzt, das Authentifizierungs- und Ticketausgabedienste bereitstellt. Alle wichtigen Betriebssysteme, einschließlich Microsoft Windows, Linux, Apple OS X und FreeBSD, unterstützen das Kerberos-Protokoll.

Kerberos-Protokollnachrichten sind durch gemeinsame geheime Kryptographie vor Wiedergabeangriffen und Abhören geschützt. Der Hauptzweck von Kerberos besteht darin, die Übertragung verschlüsselter Passwörter über das Netzwerk zu vermeiden. Es eliminiert die Bedrohung durch Paket-Sniffer und verbessert die allgemeine Netzwerksicherheit.

Obwohl der Kerberos-Sicherheitsunterstützungsanbieter effektiv mit gravierenden Sicherheitsbedrohungen umgeht, kann die Implementierung aufgrund verschiedener 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ügbarkeitsperiode haben.
• Kerberos kann nicht verwendet werden, wenn Benutzer von nicht vertrauenswürdigen Systemen aus auf Dienste zugreifen möchten.
• Im Falle der Verwendung symmetrischer Kryptographie ermöglicht die Kompromittierung der Authentifizierungsinfrastruktur einem Angreifer, sich als beliebiger Benutzer auszugeben.
• Jeder Netzwerkdienst, der einen anderen Hostnamen erfordert, benötigt sein eigenes Set von Kerberos-Schlüsseln.

Wie die Kerberos-Authentifizierung funktioniert

Das Key Distribution Center besteht aus einem Authentication Server (AS) und einem Ticket Granting Server (TGS). TGT ist ein Ticket Granting Ticket.

1. Der Benutzer gibt den Login und das Passwort ein. Die Klartext-Benutzer-ID wird an den Authentication Server (AS) mit der Anfrage nach Diensten im Namen des Benutzers gesendet.
2. AS überprüft, ob der Benutzer-Login in der Datenbank vorhanden ist. Wenn Informationen über diesen Benutzer vorhanden sind, kann AS den geheimen Schlüssel des Clients basierend auf der Benutzer-ID und dem Passwort generieren. AS sendet an den Benutzer:
   • Client/TSG-Sitzungsschlüssel (verschlüsselt mit dem geheimen Schlüssel des Clients);
   • TGT einschließlich Benutzer-ID, Netzwerkadresse und Ticket-Gültigkeitszeitraum + Client/TGS-Sitzungsschlüssel (verschlüsselt mit dem geheimen Schlüssel von TGS).
3. Der Benutzer dekodiert die erste Nachricht, kann aber die zweite nicht dekodieren, da er nicht über den geheimen Schlüssel von TSG verfügt. Der Client sendet folgende Nachricht an TGS:
   • TGT, erhalten von AS + Server-ID + TGS/Client-Geheimschlüssel (verschlüsselt mit dem geheimen Schlüssel von TGS);
   • Authenticator einschließlich Client-ID und Zeitstempel (verschlüsselt mit dem Client/TSG-Sitzungsschlüssel).
4. TGS entschlüsselt die erste Nachricht, erhält TGT + TGS/Client-Sitzungsschlü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 nicht den Ticket-Gültigkeitszeitraum überschreitet. Wenn alles stimmt, sendet TSG die folgende Nachricht an den Benutzer:
   • Verwendete ID, Netzwerkadresse, Ticket-Validierungszeitraum + Client/Server-Sitzungsschlüssel (verschlüsselt mit dem geheimen Schlüssel des Servers);
   • Client/Server-Sitzungsschlüssel (verschlüsselt mit dem Client/TGS-Geheimschlüssel).
5. Der Client sendet folgende Nachricht an den Server, zu dem er Zugriff erhalten möchte:
   • Verwendete ID, Netzwerkadresse, Ticket-Validierungszeitraum + Client/Server-Sitzungsschlüssel (verschlüsselt mit dem geheimen Schlüssel des Servers);
   • Authenticator einschließlich ID und Zeitstempel (verschlüsselt mit dem Client/Server-Sitzungsschlüssel).
6. Der Zielserver entschlüsselt die Nachrichten des Benutzers, überprüft, ob die Benutzer-IDs aus beiden Nachrichten denselben Wert haben und ob der Gültigkeitszeitraum nicht überschritten ist, und sendet dann dem Client folgende Parameter zur Bestätigung seiner Identität:
   • Zeitstempel + 1 (verschlüsselt mit dem Client/Server-Sitzungsschlü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 der Arbeit beginnen.

Konfigurieren der Firewall für die Arbeit mit dem Kerberos-Authentifizierungsprotokoll

Die DataSunrise-Datenbank-Firewall unterstützt das Kerberos-Authentifizierungsprotokoll. Einige Einstellungen müssen implementiert werden, um Kerberos-Operationen zu ermöglichen, und sie können je nach verwendetem RDBMS-Produkt variieren. In diesem Artikel zeigen wir, wie man Kerberos auf MS SQL Server anpasst.

Bei der Arbeit im Active Directory erfolgt die Benutzerautorisierung über die Security Support Provider Interface (SSPI). 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. Die Delegierung 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 “Vertrauen Sie diesem Computer für die Delegation an jeden Dienst”.
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 aktiviert 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 durch 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

   Zum Testen des Autorisierungsschemas führen Sie nach der Verbindung zum Server den folgenden Befehl aus:

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

   Das Ergebnis entspricht dem Authentifizierungsschema, das vom Server verwendet wurde: SQL, NTLM oder KERBEROS.

3. Falls Sie einen Fehler “Kann SSPI-Kontext nicht generieren” erhalten, folgen Sie den Microsoft-Supportanweisungen, um das Problem mit der Sicherheitsunterstützungsschnittstelle zu beheben.