Zur Absicherung Ihrer Datenbank stehen Ihnen diverse Möglichkeiten zur Verfügung. In nachfolgendem Beitrag werden Ihnen zwei verschiedene Methoden vorgestellt, um die Sicherheit Ihres Systems zu erhöhen.

MÖGLICHKEIT 1: TCP.VALIDNODE_CHECKING

Die Benutzung des Sicherheits-features TCP.VALIDNODE_CHECKING gestattet es unter Oracle, Client-Verbindungen zuzulassen oder gegebenfalls abzulehnen, basierend auf Hostname bzw. IP-Adressenbasis (Sie haben dabei die Möglichkeit einzelne IP-Adressen, ganze IP-Adressenblöcke bzw. Hostnames zu validieren.).

SCHRITT 1

Zum generellen Einschalten der Funktionalität müssen Sie dafür in der SQLNET.ORA-Datei Ihres Datenbank-Servers den Eintrag TCP.VALIDNODE_CHECKING auf YES setzen.

Die Textdatei SQLNET.ORA befindet sich standardmäßig im Verzeichnis $ORACLE_HOME/network/admin/sqlnet.ora

TCP.VALIDNODE_CHECKING=yes

SCHRITT 2 - ZUGELASSENE CLIENTS

Um festzulegen, welche Clients sich REMOTE an der Datenbank anmelden dürfen, tragen Sie alle erlaubten Adressen / Clients / Hostnamen bei dem Parameter TCP.INVITED_NODES ebenfalls in die SQLNET.ORA-Datei ein.

Beispiel:

TCP.INVITED_NODES=(client1,client2,client3,172.29.38.44)

SCHRITT 3 - ABZULEHNENDE CLIENTS

Möchten Sie bestimmte Adressen / Clients / Hostnames an der REMOTE-Anmeldung bei der Datenbank hindern, so können Sie dies über den Eintrag TCP.EXCLUDED_NODES steuern.

Beispiel:

TCP.EXCLUDED_NODES=(172.28.38.*,172.29.38.*, client10)

Anmerkung:

a)  Die Änderungen werden erst nach einem Neustart des LISTENERs wirksam.

b)  Achten Sie unbedingt darauf, dass sich vor den jeweiligen Einträgen in der SQLNET.ORA-Datei KEIN Leerzeichen befindet, da Oracle sonst den Parameter ignoriert und an den Änderungen einfach "vorbeiliest".

TCP.VALIDNODE_CHECKING=yes    #<=== falsch, wegen Leerzeichen am Anfang!
TCP.VALIDNODE_CHECKING=yes      #<=== Richtig!

c) Haben Sie eine Kombination aus INVITED- und EXCLUDED-Nodes gewählt, haben Einträge aus TCP.INVITED_NODES eine höhere Gewichtung als Einträge in TCP.EXCLUDED_NODES.

Übertragen auf die oben genannten Beispiele bedeutet dass, obwohl in TCP.EXCLUDED_NODES=(172.28.38.*,172.29.38.*) sämtliche IP-Adressen aus dem Haushalt 172.29.38.* und dem Haushalt 172.28.38.* geblockt wurden, wird aufgrund der höheren Gewichtung der TCP.INVITED_NODES-Einträge die IP-Adresse aus TCP.INVITED_NODES=(172.29.38.44) zugelassen und dem Client gestattet, sich mit der Datenbank zu verbinden. 

Im Ganzen könnte dann eine SQLNET.ORA-Datei also folgendermaßen aussehen:

#########################################################################

# sqlnet.ora Network Configuration File:
# C:\oracle\product\12.1.0.2\dbhome_1\network\admin\sqlnet.ora
# Generated by Oracle configuration tools.

# This file is actually generated by netca. But if customers choose to
# install "Software Only", this file wont exist and without the native
# authentication, they will not be able to connect to the database on NT.

SQLNET.AUTHENTICATION_SERVICES= (NTS)
TCP.VALIDNODE_CHECKING=yes
TCP.INVITED_NODES=(client1,client2,172.29.38.44)
TCP.EXCLUDED_NODES=(client10,172.29.38.*,172.29.38.*)

MÖGLICHKEIT 2: VALID_NODE_CHECKING_REGISTRATION_<LISTENER_NAME>

Eine weitere Möglichkeit Ihre Datenbank zu schützen ist, den LISTENER gegen unbefugten Zugriff durch fremde Datenbanken / Knoten / Nodes abzusichern.

Dies wird über den folgenden Parameter gesteuert:

VALID_NODE_CHECKING_REGISTRATION_<listener_name>

Per Default ist dieser Parameter auf [OFF bzw. 0] gesetzt, kann aber sowohl auf [ON bzw. 1 bzw. LOCAL] oder aber auf [SUBNET bzw. 2] umgeschaltet werden.

Bedeutung:

Wird der Parameter auf [ON | 1 | LOCAL] gesetzt, dann können nur noch lokale IP-Adressen ihre Dienste am Listener registrieren.

Wird der Parameter auf [SUBNET | 2] gesetzt, dann wird allen IP-Adressen aus dem selben Subnetz erlaubt, sich am Listener zu registrieren.

IP-Adressen die NICHT aus dem lokalen IP-Adressen-Haushalt stammen, können zusätzlich freigegeben werden und dürfen dann ihre Dienste am Listener registrieren.

REGISTRATION_INVITED_NODES_listener=(10.1.38.*, 10.1.32.0/24, 2001:CD6:fe38:7322, server1)

Zu Demonstrationszwecken sind die dafür notwendigen Schritte im nachfolgenden Beitrag schrittweise erklärt.

Ein Host [ 172.30.30.162 ] möchte eine Verbindung zum "entfernten" LISTENER [ 172.30.30.160 ] herstellen, dafür nimmt er die folgende Konfiguration vor.

SCHRITT 1 - EINTRAG IN DER TNSNAMES.ORA [172.30.30.162]

In der TNSNAMES.ORA-Datei eines Knotens [172.30.30.162] wird der Eintrag, über den sich die Datenbank am "entfernten" LISTENER [172.30.30.160] anmelden kann (Host + Port) vorgenommen.

REMOTELIST =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 172.30.30.160)(PORT = 1521))
    )
  )

SCHRITT 2 - REMOTE LISTENER SETZEN

Über den Parameter remote_listener wird auf den Eintrag aus der tnsnames.ora-Datei verwiesen, der die Verbindung zum "entfernten" LISTENER [172.30.30.160] herstellt.

SQL>  show parameter remote
NAME                                 TYPE        VALUE
------------------------------------ ----------- -------------
remote_listener                      string      REMOTELIST

SCHRITT 3 - KNOTEN [172.30.30.162] AM REMOTE LISTENER REGISTRIEREN.

Datenbank am Ziellistener (REMOTE LISTENER) registrieren.

SQL> alter system register;
System wurde geändert.

SCHRITT 4 - LISTENER ABSICHERN DURCH VALID_NODE_CHECKING_REGISTRATION

Zum Schutz der Datenbank durch Absicherung des LISTENER gegen unbefugten Zugriff durch fremde Datenbanken / Knoten / Nodes können Einstellungen in der LISTENER.ORA-Datei vorgenommen werden. Dies wird über den folgenden Parameter gesteuert:     

VALID_NODE_CHECKING_REGISTRATION_<listener_name>

Valid Node Checking bezogene Parametereinstellungen:

VALID_NODE_CHECKING_REGISTRATION_listener_name=<zulässiger Wert>

Zulässige Werte:

Bedeutung der Einträge in der LISTENER.ORA :

VALID_NODE_CHECKING_REGISTRATION_LISTENER=OFF

Wenn explizit gesetzt - oder aber der Eintrag NICHT existiert - kann sich KEINE NODE von außerhalb anmelden.

Hier sind NUR lokale IP-Adressen/Hostnames zulässig.

VALID_NODE_CHECKING_REGISTRATION_LISTENER=ON

Wenn explizit gesetzt kann über das Anmeldeverhalten externer NODES am LISTENER entschieden werden.

Ist der Parameter VALID_NODE_CHECKING_REGISTRATION_LISTENER=ON gesetzt, haben Sie die Möglichkeit, festzulegen welche externen NODES sich am LISTENER registrieren dürfen und welche nicht. Dazu stehen die beiden Parameter zur Verfügung:

REGISTRATION_EXCLUDED_NODES_<listenername>
REGISTRATION_INVITED_NODES_<listenername>

Beispiel:
Angenommen Sie haben in Ihrer LISTENER.ORA-Datei folgende Konfiguration vorgenommen:

VALID_NODE_CHECKING_REGISTRATION_LISTENER=ON
REGISTRATION_EXCLUDED_NODES_listener=(172.30.30.*)
REGISTRATION_INVITED_NODES_listener=(172.30.30.163)

Anmerkung: 

Beachten Sie bitte, dass Einträge in REGISTRATION_INVITED_NODES_<LISTENER> eine höhere Gewichtung als REGISTRATION_EXCLUDED_NODES_<LISTENER> haben.

Dies bedeutet, dass im oben gezeigten Beispiel sämtliche NODEs aus dem Subnetz 172.30.30.*  von der Anmeldung am LISTENER ausgeschlossen werden. Die unter REGISTRATION_INVITED_NODES_listener eingetragene NODE mit der IP 172.30.30.163 ist jedoch trotzdem zugelassen (wegen der höheren Gewichtung von INVITED_NODES gegenüber den EXCLUDED_NODES).

Beispiel:

Angenommen Sie haben nun in Ihrer LISTENER.ORA-Datei folgende Konfiguration vorgenommen:

VALID_NODE_CHECKING_REGISTRATION_LISTENER=ON
REGISTRATION_EXCLUDED_NODES_listener=(172.30.30.163)
REGISTRATION_INVITED_NODES_listener=(172.30.30.*) 

Dies bedeutet, dass hier sämtliche NODEs aus dem Subnetz 172.30.30.*  von der Anmeldung am LISTENER zugelassen werden, auch die IP-Adresse 172.30.30.163 (wegen der höheren Gewichtung von INVITED_NODES gegenüber den EXCLUDED_NODES) obwohl diese unter REGISTRATION_EXCLUDED_NODES_listener eingetragen wurde!

Dies kann auch über das Tool LSNRCTL (beim Ziellistener) beobachtet werden:

LSNRCTL> services
Anmeldung bei (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=DOZENT4)(PORT=1521)))
Services Übersicht...
Dienst "o12c" hat 2 Instanzen.
  Instanz "o12c", Status UNKNOWN, hat 1 Handler f³r diesen Dienst...
    Handler:
      "DEDICATED" eingerichtet:0 abgewiesen:0
         LOCAL SERVER
  Instanz "o12c", Status READY, hat 1 Handler f³r diesen Dienst...
    Handler:
      "DEDICATED" festgelegt:0 abgelehnt:0 Status:blocked
         REMOTE SERVER
         (ADDRESS=(PROTOCOL=TCP)(HOST=SCHULUNG63)(PORT=1521))
Dienst "o12cXDB" hat 1 Instanzen.
  Instanz "o12c", Status READY, hat 5 Handler f³r diesen Dienst...
    Handler:
      "D004" eingerichtet:0 abgewiesen:0 aktuell:0 max:1022 Status:ready
         DISPATCHER <machine: SCHULUNG63, pid: 3664>
         (ADDRESS=(PROTOCOL=tcp)(HOST=schulung63)(PORT=49176))
      "D003" eingerichtet:0 abgewiesen:0 aktuell:0 max:1022 Status:ready
         DISPATCHER <machine: SCHULUNG63, pid: 3660>
         (ADDRESS=(PROTOCOL=tcp)(HOST=schulung63)(PORT=49174))
      "D002" eingerichtet:0 abgewiesen:0 aktuell:0 max:1022 Status:ready
         DISPATCHER <machine: SCHULUNG63, pid: 3656>
         (ADDRESS=(PROTOCOL=tcp)(HOST=schulung63)(PORT=49172))
      "D001" eingerichtet:0 abgewiesen:0 aktuell:0 max:1022 Status:ready
         DISPATCHER <machine: SCHULUNG63, pid: 3648>
         (ADDRESS=(PROTOCOL=tcp)(HOST=schulung63)(PORT=49171))
      "D000" eingerichtet:0 abgewiesen:0 aktuell:0 max:1022 Status:ready
         DISPATCHER <machine: SCHULUNG63, pid: 3644>
         (ADDRESS=(PROTOCOL=tcp)(HOST=schulung63)(PORT=49169))
Der Befehl wurde erfolgreich ausgeführt.
LSNRCTL>

Wurde eine Verbindungsanfrage zum LISTENER abgelehnt so wird dieses in der LISTENER.LOG-Datei mitprotokolliert.

Listener (VNCR-Option 1) hat Registrierungsanforderung von Ziel 172.30.30.162 abgelehnt
26-JAN-2016 15:32:34 * service_register_NSGR * 1182
TNS-01182: Listener hat Registrierung von Service "" zurückgewiesen
Listener (VNCR-Option 1) hat Registrierungsanforderung von Ziel 172.30.30.162 abgelehnt
26-JAN-2016 15:32:36 * service_register_NSGR * 1182
TNS-01182: Listener hat Registrierung von Service "" zurückgewiesen

Wo Sie diese LISTENER.LOG-Datei finden, lässt sich über LSNRCTL > STATUS abfragen:

LSNRCTL> status
Anmeldung bei (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=schulung62)(PORT=1521)))
STATUS des LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for 64-bit Windows: Version 12.1.0.1.0 - Production
Startdatum                26-JAN-2016 14:11:26
Uptime                    0 Tage 1 Std. 26 Min. 26 Sek.
Trace-Ebene               off
Sicherheit                ON: Local OS Authentication
SNMP                      OFF
Parameterdatei des Listener  C:\oracle\product\12.1.0\dbhome_1\network\admin\listener.ora
Log-Datei des Listener       C:\Oracle\diag\tnslsnr\schulung62\listener\alert\log.xml

Ein Umsetzen auf ein anderes Verzeichnis lässt sich bei Bedarf durch das Anpassen der Einträge in der LISTENER.ORA Datei durchführen:

DIAG_ADR_ENABLED_LISTENER=OFF
LOG_DIRECTORY_LISTENER=C:\TEMP
LOG_FILE_LISTENER=listener.log
LOG_STATUS=ON

Abschließend kann also gesagt werden, dass unter Oracle einige Möglichkeiten geboten werden, um komfortabel und einfach die Sicherheit der sensiblen Datenbestände nach außen hin abzusichern.

Weitere spannende Infos dazu bekommen Sie in unserem Oracle Security Seminar. Gerne könne Sie auch eine Oracle Sicherheitsprüfung durch unser Consulting-Team vor Ort oder per Remote durchführen lassen.