1. Start
  2. Unternehmen
  3. Blog
  4. Remote Listener für Oracle Standard Edition 2 Datenbanken - Sicherheit (Teil 1 - Verstecken)

Remote Listener für Oracle Standard Edition 2 Datenbanken - Sicherheit (Teil 1 - Verstecken)

Im vierten Teil der Reihe “Remote Listener für Standard Edition 2” Datenbanken beleuchten wir zwei Security Features, die insbesondere beim Einsatz von Remote Listenern Sinn machen.

Zunächst einmal ist der Remote Listener auch "nur" ein Listener und damit gelten aus Security-Sicht auch die gleichen Anforderungen, Empfehlungen und Einschränkungen wie für lokale Listener.
Trotzdem kann man sich gerade mit Oracle Standard Edition 2 Lizenz diese Funktionen zur zusätzlichen Absicherung der Datenbankverbindungen zu Nutze machen.
 

1. Verstecken der Datenbank-Nodes

Durch die Verwendung des Remote-Listener-Nodes in einem TNS-Eintrag, anstelle des/der Datenbankserver(s) kann verhindert werden, dass Endbenutzer sehen, auf welchem Datenbankserver die Datenbank derzeit ausgeführt wird. Ist es nicht besser, den bereits bekannten Anwendungsserver, auf dem der Remote Listener ausgeführt wird, in der tnsnames.ora (oder im jdbc-Connect-String) anzuzeigen? 

Wenn der/die Datenbankserver in der Anwendung nicht angezeigt werden oder in einer Abfrage nicht ausgewertet werden können (z. B. durch Abfragen von v$instance), weil Endbenutzer keinen SQL-Zugriff oder keine Developer Tools besitzen, wissen Endbenutzer erst einmal nichts über den Datenbankserver.
Auch kann ein möglicher Angreifer, der Zugriff auf einen Client-PC bekommt, nicht einfach herausfinden, welches der Datenbankserver ist bzw. welche es sind. Er benötigt dazu Zugriff auf den Applikationsserver (zum Ausführen eines lsnrctl status) oder muss ein Netzwerktracing aktivieren.
Der nachfolgende Screenshot ist ein Beispiel für den TNS-Eintrag für einen Datenbankdienst, bei dem nur der Name des Anwendungsservers als Host angegeben ist, nicht jedoch die Namen der beiden Datenbankserver, auf denen dieser Datenbankdienst gestartet wird (je nach Rolle, Standby/Primär). Es sieht einfach wie ein Eintrag für einen einzelnen Datenbankserver aus (neben Security ist das natürlich auch, wie bereits beschrieben, ein Hochverfügbarkeitsfeature).

 

2. Verstecken des PDB- bzw. Datenbank-Services

Oftmals gibt es nur einen Datenbank-Service, der von einem Remote Listener aus auch wirklich verwendet werden soll: ein Applikationsdatenbank-Service (bitte keinen Default Service verwenden, aber das sollte inzwischen allen Administratoren bekannt sein). Gerade Remote Listener, die auf Applikationsservern installiert sind, sind häufig nur für genau einen Service gedacht. Das liegt im Normalfall daran, dass typischerweise die Applikationsserver nach Produktion und Test aufgeteilt sind und somit auch vom jeweiligen Applikationsserver aus nur auf genau einen dedizierten Datenbank-Service zugegriffen werden muss.

Was kaum jemand kennt: Dieser Service lässt sich in der listener.ora-Datei für den Remote Listener konfigurieren.
Es gibt dort einen, zugegebenermaßen relativ selten verwendeten, Parameter: DEFAULT_SERVICE_<Listener-Name>, also im Normalfall DEFAULT_SERVICE_LISTENER.
In der 19c Datenbank-Dokumentation steht folgendes zu diesem Parameter:
 

Nach dem Durchlesen des gelb markierten Bereiches könnte man annehmen, dass dieser Parameter in einer Container-Datenbank nicht funktioniert, da der Client den Service-Namen EXPLIZIT angeben muss. Aber der Parameter ist in der 23ai auch noch vorhanden und hier gibt es keine klassische Architektur mehr. Außerdem heißt der Parameter DEFAULT_SERVICE_<listener> und nicht DEFAULT_SID_<listener>. Zeit also, herauszufinden, ob der Parameter auch wirklich wirksam ist.
Zum Testen ist also der Default_SERVICE_LISTENER in der listener.ora Datei des Remote Listeners wie folgt gesetzt:

Nun wird der TNS-Eintrag angepasst und der Service entfernt.

 Wird der Verbindungsaufbau auch ohne explizite Service-Definition in der TNSNames.ora funktionieren?

Ja, das funktioniert. Mit der Kombination aus dem Verstecken der Datenbankserver und des Datenbank-Services kann also mit relativ einfachen Mitteln dafür gesorgt werden, dass auf Seiten der Client-PCs möglichst wenig Informationen über die Datenbank und deren darunterliegende(n) Server verfügbar sind. 

Kommentare

Keine Kommentare

Kommentar schreiben

* Diese Felder sind erforderlich