Als PDF Downloaden!
Werbung
Tipps & Tricks: März 2016 Bereich: DBA, Security Erstellung: 03/2016 RZ Versionsinfo: 12.1 Letzte Überarbeitung: 03/2016 RZ TCP VALIDNODE CHECKING 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 Sicherheitsfeatures TCP.VALIDNODE_CHECKING gestattet es unter Oracle, Client-Verbindungen zuzulassen oder gegebenfalls abzulehnen, basierend auf Hostname bzw. IP-Adressen-Basis (Sie haben dabei die Möglichkeit einzelne IP-Adressen, ganze IP-Adressenblöcke bzw. Hostnamen 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 / Hostnamen 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 Muniqsoft GmbH Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40 IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0 Seite 1 von 6 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 TCP.VALIDNODE_CHECKING=yes #<=== falsch, wegen Leerzeichen am Anfang! #<=== 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 registieren. 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. Muniqsoft GmbH Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40 IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0 Seite 2 von 6 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 - Den 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.20.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> Muniqsoft GmbH Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40 IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0 Seite 3 von 6 Zulässige Werte: OFF[DEFAULT bzw. 0 - Wert] ON bzw. LOCAL 1 SUBNET bzw.12c) (ab 2 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/Hostnamen 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.20.30.* von der Anmeldung am LISTENER ausgeschlossen werden. Die unter REGISTRATION_INVITED_NODES_listener eingetragene NODE mit der IP 172.20.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.20.30.* von der Anmeldung am LISTENER zugelassen werden, auch die IP-Adresse 172.20.30.163 (wegen der höheren Gewichtung von INVITED_NODES gegenüber den EXCLUDED_NODES) obwohl diese unter REGISTRATION_EXCLUDED_NODES_listener Muniqsoft GmbH Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40 IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0 Seite 4 von 6 Dies bedeutet, dass hier sämtliche NODEs aus dem Subnetz 172.20.30.* von der Anmeldung am LISTENER zugelassen werden, auch die IP-Adresse 172.20.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.20.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.20.30.162 abgelehnt 26-JAN-2016 15:32:36 * service_register_NSGR * 1182 TNS-01182: Listener hat Registrierung von Service "" zurückgewiesen Muniqsoft GmbH Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40 IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0 Seite 5 von 6 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. Muniqsoft GmbH Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40 IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0 Seite 6 von 6
