Logo Oracle Deutschland   DBA Community  -  November 2012
SSL: Alternative Netzwerkverschlüsselung für Oracle Datenbanken
von Heinz-Wilhelm Fabry, ORACLE Deutschland B.V. & Co. KG

Auslesen des Netzwerkverkehrs mit Wireshark Das Netzwerk bietet eine extrem kritische Angriffsfläche in jeder Sicherheitsarchitektur. Einerseits ist kaum zu verhindern, dass externe oder auch interne Angreifer auf das Netzwerk zugreifen: So sieht etwa jemand, der Zugriff auf einen sogenannten Netzwerksniffer hat (zum Beispiel auf das weit verbreitete Wireshark) alle Daten, die im Netzwerk übertragen werden.

Andererseits gehen alle Befehle, die an eine Oracle Datenbank geschickt werden - mit Ausnahme der Informationen zu Benutzernamen und Passwort beim LOGIN - sowie alle Daten, die aus einer Datenbank ausgegeben werden, im Klartext über das Netzwerk. Dies zeigt auch die Abbildung rechts, in der man im unteren, grauen Bereich deutlich Daten aus der Tabelle EMP erkennt. Das Risiko, über das Netzwerk Daten 'zu verlieren', ist daher nur in den Griff zu bekommen, wenn man den Datenstrom verschlüsselt. Im Oracle Umfeld gibt es dazu zur Zeit zwei gängige Möglichkeiten:
  • Man setzt spezielle Hardware ein und verschlüsselt damit den gesamten Netzwerkverkehr. Diese Variante ist mit beträchtlichen Investitionen verbunden und schiesst besonders dann über das Ziel hinaus, wenn nicht nur kritische, sondern auch relativ viele unkritische Daten über das Netzwerk übertragen werden.
  • Man verschlüsselt ausschließlich Daten, die kritische Datenbanken betreffen. Das ist mit der Advanced Security Option (ASO) der Enterprise Edition der Datenbank sehr gezielt möglich.
Die einfachste Lösung zur Verschlüsselung des Datenstroms bietet ASO mit der sogenannten nativen Verschlüsselung über SQL*Net. Sie ist bei Bedarf und ohne Neustart der Datenbank ganz einfach und im Extremfall mit einer einzigen Einstellung in der Konfigurationsdatei SQLNET.ORA zu implementieren, nämlich mit
SQLNET.ENCRYPTION_SERVER = REQUIRED
Wegen der einfachen Umsetzung wird diese Variante von der ganz überwiegenden Mehrheit der ASO Anwender bevorzugt eingesetzt. Im Rahmen der Datenbank Community wurde dieses Verfahren der Netzwerkverschlüsselung auch schon näher betrachtet. Allerdings lässt sich mit der ASO auch die Verschlüsselung des Netzwerks über SSL implementieren. Wie das aufzusetzen ist beschreibt dieser Tipp. Er versteht sich als erstes How-To zur Einarbeitung in die Thematik.

Vorbemerkungen

Die Beschaffung der für die Arbeit mit SSL notwendigen Zertifikate, ihre Verteilung und ihre Verwaltung erfordern einen relativ hohen Aufwand. Viele Unternehmen scheuen diesen Aufwand, wenn er sich nur auf einen relativ kleinen Ausschnitt der eigenen EDV bezieht. Und natürlich spielt die eigene Erfahrung auch eine Rolle: Wer unsicher im Umgang mit SSL ist, wird SSL nicht als Element erkennen, das die eigene Sicherheit erhöhen könnte. Deshalb wird die SSL Verschlüsselung im Oracle Umfeld fast aussschliesslich von Unternehmen eingesetzt, die auch in anderen Bereichen ihrer EDV bevorzugt damit arbeiten.

Es stellt sich aber selbstverständlich die Frage, warum dann überhaupt SSL eingesetzt wird. Die Erklärung liegt im zweifachen Nutzen von SSL. Denn erstens kann man damit den Netzwerkverkehr verschlüsseln, aber zweitens kann man unabhängig davon eine eindeutige Identifizierung von Benutzern erreichen. Das wiederum bedeutet einen zusätzlichen Gewinn an Sicherheit vor sogenannten Man-In-The-Middle Angriffen. Wie im Advanced Security Guide beschrieben, bietet die native Netzwerkverschlüsselung über das "Authentication Key-Fold in" zwar einen hohen Schutz gegen solche Angriffe, aber SSL bietet hier den wohl zur Zeit optimalen Schutz. Ist also ein Man-In-The-Middle Angriff ein hoch eingeschätztes Risiko im selbst ermittelten Bedrohungsszenario, sollte der Einsatz von SSL unbedingt in Betracht gezogen werden. Allerdings muss auch berücksichtigt werden, dass der Verbindungsaufbau über SSL aufwändiger ist als der Aufbau einer nativ verschlüsselten Verbindung und deshalb auch entsprechend langsamer vonstattengeht.

Dieser Artikel setzt voraus, dass zwei (virtuelle) Rechner zur Verfügung stehen. Auf dem einen ist die Datenbank installiert, auf dem anderen genügt die Client Software. Zwischen den beiden Rechnern besteht eine Netzwerkverbindung. Die Beispiele dieses Artikels basieren auf virtuellen Rechnern, auf denen Oracle Enterprise Linux Versionen 5.5 und 5.7 sowie die Datenbanksoftware der Version 11.2.0.3. installiert sind.

In folgenden Abschnitten wird die Vorgehensweise erläutert:
  1. Zertifikate einrichten
  2. Konfigurationsdateien des Servers bearbeiten
  3. Konfigurationsdateien des Client bearbeiten
  4. Benutzer anlegen und testen
  5. Hinweis und weitere Informationen

Zertifikate einrichten

Wie schon angemerkt und wie sicherlich auch bekannt arbeitet SSL mit Zertifikaten. Diese Zertifikate werden von Certificate Authorities ausgestellt. Zum Testen kann man allerdings auch mit selbst signierten Zertifikaten arbeiten. Diese Variante wird hier genutzt. Im einzelnen sind folgende Arbeitsschritte abzuarbeiten:
  1. Da Zertifikate in Wallets gespeichert werden, wird als erstes ein Wallet auf der Serverseite angelegt. Oracle bietet dazu drei Werkzeuge an: mkstore, orapki und den Oracle Wallet Manager (owm). Nur orapki unterstützt alle weiteren durchzuführenden Schritte. Damit nicht ständig zwischen unterschiedlichen Werkzeugen gewechselt werden muss, soll deshalb hier orapki genutzt werden. Folgender Aufruf erzeugt das Wallet:
    orapki wallet create -wallet . -auto_login -pwd oracle_1
    
    Nach dem Parameter -wallet erfolgt die Angabe des Verzeichnisses, in dem das Wallet angelegt wird, hier also im aktuellen Verzeichnis. Als aktuelles Verzeichnis wird für diesen Artikel $ORACLE_HOME/network/admin gewählt, da hier weitere Dateien liegen, die später noch zu bearbeiten sind. Der Parameter -auto_login bewirkt, dass das Wallet ständig für den Zugriff durch Oracle geöffnet ist. Dazu wird von orapki auf der Betriebssystemebene nicht nur das eigentliche Wallet namens EWALLET.P12, sondern eine weitere Datei namens CWALLET.SSO angelegt. Weiterhin ist anzumerken, dass man normalerweise das Passwort wohl nicht sichtbar eingeben sollte. Dazu verwendet man den Parameter -pwd dann einfach nicht. Das führt dazu,dass orapki vor dem Ausführen des Befehls nach einem Passwort fragt. Genügt das Passwort nicht den Sicherheitsanforderungen erhält man die Fehlermeldung PKI-01002: Ungültiges Kennwort: Kennwörter müssen mindestens acht Zeichen umfassen und eine Kombination von Buchstaben und Zahlen oder Sonderzeichen enthalten.

  2. Nun wird ein selbst signiertes Zertifikat erzeugt und in dem Wallet gespeichert. In diesem Fall wird zusätzlich automatisch ein sogenanntes User Zertifkat erzeugt. Es wird ebenfalls automatisch in dem Wallet gespeichert.
    orapki wallet add -wallet . -dn 'cn=orcl' -keysize 1024 -self_signed -validity 4000 -pwd oracle_1
    
    Wie man sieht, ist ein sogenannter distinguished name anzugeben. Für diesen Artikel genügt es, lediglich den sogenannten common name (cn) anzugeben, hier ORCL. Es sind auch weitere Angaben möglich. Ausserdem wird die Länge des Schlüssels (512, 1024, oder 2048 Bits) festgelegt, dass es sich um ein selbst signiertes Zertifikat handelt, dass das Zertifikat 4000 Tage lang gültig ist und selbstverständlich auch das Passwort für das Wallet (entweder hier oder nach dem Prompt).

  3. Das auf der Serverseite gespeicherte Zertifikat wird später auch auf der Clientseite benötigt. Deshalb wird es mit folgendem Befehl aus dem Wallet in die Datei SERVER.CERT im aktuellen Verzeichnis exportiert.
    orapki wallet export -wallet . -dn 'cn=orcl' -cert server.cert -pwd oracle_1
    
  4. Auf der Clientseite werden diese Schritte nun analog ausgeführt. Nach dem Anlegen des Wallet wird das Zertifikat erzeugt - natürlich nicht mit dem gleichen common name, denn schliesslich soll dieses Zertifikat einen Benutzer auf der Clientseite eindeutig identifizieren. Hier wird der common name COMMDBA verwendet. Anschliessend wird das Zertifikat ebenfalls in eine Datei exportiert, nämlich in die Datei CLIENT.CERT. Damit kann es im nächsten Schritt der Serverseite zugänglich gemacht werden. Die Befehle sehen folgendermassen aus
    orapki wallet create -wallet . -auto_login -pwd oracle_1
    orapki wallet add    -wallet . -dn 'cn=commdba' -keysize 1024 -self_signed -validity 4000 -pwd oracle_1
    orapki wallet export -wallet . -dn 'cn=commdba' -cert client.cert -pwd oracle_1
    
  5. Nun werden die Zertifikate vom Server zum Client und vom Client zum Server kopiert (zum Beispiel mit scp) und in die jeweiligen Wallets importiert.
    -- Serverseite
    orapki wallet add -wallet . -trusted_cert -cert client.cert -pwd oracle_1
    -- Clientseite
    orapki wallet add -wallet . -trusted_cert -cert server.cert -pwd oracle_1
    
    Damit sind die Schritte abgeschlossen, die in erster Linie mit den Zertifikaten und Wallets zu tun haben. Hier eine Darstellung der bisherigen Aktionen im owm.
Ergebnis der bisherigen Aktionen im Oracle Wallet Manager (owm)

Konfigurationsdateien des Servers bearbeiten

In den nächsten beiden Arbeitsschritten muss die Voraussetzung geschaffen werden, dass der Server das Wallet und die darin abgelegten Zertifikate nutzt. Dazu sind Einträge in den Dateien SQLNET.ORA und LISTENER.ORA nötig.
  1. In der Datei SQLNET.ORA auf der Serverseite werden folgende Einträge gemacht:
    -- TCPS, damit die Authentifizierung über SSL genutzt werden kann.
    SQLNET.AUTHENTICATION_SERVICES = (BEQ,TCPS)
    
    -- Damit authentifiziert die Datenbank die / den Benutzer über SSL
    SSL_CLIENT_AUTHENTICATION=TRUE
    
    -- Pfad zum Wallet mit den Zertifikaten
    WALLET_LOCATION=(SOURCE=
                    (METHOD=FILE)
                    (METHOD_DATA=
                    (DIRECTORY=$ORACLE_HOME/network/admin)))
    
    Wen die Schreibarbeit stört, der kann übrigens auch den graphischen Oracle Net Manager (netmgr) für diese Konfigurationsschritte verwenden. Hier eine Abbildung:

  2. SQLNET.ORA mit dem Oracle Net Manager (netmgr) anpassen

  3. Auch die Datei LISTENER.ORA muss angepasst werden. Dazu wird der Parameter WALLET_LOCATION genauso eingestellt wie schon in der Datei SQLNET.ORA. Ausserdem wird als Protokoll TCPS angegeben. Der gemeinhin verwendete Port ist hier 2484. Allerdings kann - gerade zum Testen - auch eine andere Portnummer verwendet werden (der gültige Wertebereich geht von 1024 bis 65535). Folgende Einträge sind in der hier verwendeten LISTENER.ORA zu finden:
    -- TCPS mit Port 2484 für die SSL Verbindungen hinzufügen
    LISTENER =
      (DESCRIPTION_LIST =
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
          (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.56.101)(PORT = 1521))
          (ADDRESS = (PROTOCOL = TCPS)(HOST = 192.168.56.101)(PORT = 2484))
        )
      )
    
    -- Speicherort des Wallets angeben (analog zur Datei SQLNET.ORA
    WALLET_LOCATION=(SOURCE=
    		(METHOD=FILE)
    		(METHOD_DATA=
    		(DIRECTORY=$ORACLE_HOME/network/admin)))
    
    -- Nicht der Listener identifiziert den Benutzer, sondern die Datenbank.
    SSL_CLIENT_AUTHENTICATION=FALSE
    

Konfigurationsdateien des Client bearbeiten

In den nächsten Schritten muss die Voraussetzung geschaffen werden, dass der Client das Wallet und die darin abgelegten Zertifikate nutzt. Dazu sind Einträge in den Dateien SQLNET.ORA und TNSNAMES.ORA nötig.
  1. In der Datei SQLNET.ORA werden folgende Einträge gemacht:
    -- TCPS, damit die Authentifizierung über SSL genutzt werden kann.
    SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)
    
    -- Damit authentifiziert die Datenbank die / den Benutzer über SSL
    SSL_CLIENT_AUTHENTICATION = TRUE
    
    -- Speicherort des Wallets auf dem Client
    WALLET_LOCATION =
      (SOURCE =
        (METHOD = FILE)
        (METHOD_DATA =
          (DIRECTORY = /oracle/product/dbhome/network/admin)
        )
      )
    
    -- Der distinguished name des Servers muss identisch sein mit dem Servicenamen 
    -- und muss mit dem SSL_SERVER_CERT_DN in der Datei TNSAMES.ORA übereinstimmen.
    SSL_SERVER_DN_MATCH=ON
    
  2. Die Datei TNSNAMES.ORA enthält folgende Einträge
    ORCL =
      (DESCRIPTION =
        (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = TCPS)(HOST = 192.168.56.101)(PORT = 2484))
        )
        (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = orcl.de.oracle.com)
        )
       (security=(SSL_SERVER_CERT_DN="cn=orcl"))
      )
    
    (Hinweis: In der hier benutzten Konfiguration trat immer dann ein Fehler auf, wenn versucht wurde, eine Verbindung vom Client zum Server aufzubauen, und die Angaben zum Parameter SECURITY über mehr als eine Zeile liefen.)

Benutzer anlegen und testen

Um die bis hierhin erstellte Beispielkonfiguration zu testen, wird nun ein Benutzer angelegt, der über das im Wallet gespeicherte Client Benutzerzertifikat authentifiziert wird. Ausserdem werden diesem Benutzer die Privilegien CREATE SESSION und die Rolle DBA zugewiesen.
CREATE USER commdba IDENTIFIED EXTERNALLY AS 'CN=commdba';
GRANT create session TO commdba;
Nun kann die SSL Verbindung vom Client zur Datenbank auf zweifache Weise genutzt werden. Zunächst die Variante, in der nur auf die Netzwerkverschlüsselung zurückgegrifffen wird: SCOTT ruft SQL*Plus auf und erhält dann den Prompt zu seinem Passwort. Der zweite Aufruf zeigt, dass COMMDBA sich ohne Passwort bei der Datenbank anmelden kann: COMMDBA wird über das Zertifikat im Wallet eindeutig identifiziert. Und ausserdem wird natürlich auch hier eine verschlüsselte Verbindung genutzt.
-- Als Benutzer SCOTT
sqlplus scott@orcl
...
Enter password:
...
SQL> show user
USER is "SCOTT"

-- Als Benutzer COMMDBA
sqlplus /@orcl
...
SQL> show user
USER is "COMMDBA"
...

Verschlüsselter Netzwerkverkehr in Wireshark Das Bild rechts knüpft an den Anfang des Tipps an, beim Sniffen mit Wireshark. Hier wird angedeutet, dass nach der Verbindung über SSL die Daten nicht mehr im Klartext erkennbar sind, sondern nur noch in verschlüsselter Form.

Hinweise und weitere Informationen

Dieser Tipp will nur eine erste Einführung in das Thema bieten. Deshalb fehlt auch die Darstellung weitergehender Möglichkeiten, etwa wie man festlegt, welcher Verschlüsselungs- oder Prüfsummenalgorithmus verwendet wird (fehlt die Angabe 'einigen' Datenbank und Client sich bei der Kontaktaufnahme auf die zu verwendenden Algorithmen). Bei Interesse an dem Thema ist die Lektüre der relevanten Kapitel in den Handbüchern zur
  1. Advanced Security Option (dort auch Informationen zu orapki) und zu
  2. SQL*Net mit den für SSL relevanten Parametern der Dateien SQLNET.ORA, LISTENER.ORA und TNSNAMES.ORA unbedingt nötig.
Ausserdem bietet natürlich My Oracle Support (MOS) eine ganze Reihe von Informationen zum Thema, beginnend zum Beispiel mit
  1. Dokument 736510 "Step by Step Guide To Configure SSL Authentication", auf das sich dieser Beitrag massgeblich stützt, oder
  2. Dokument 264080.1 "An Introduction to PKI and SSL"
  3. Dokument 166492.1 "Oracle Advanced Security SSL Troubleshooting Guide".


Zurück zur Community-Seite