Logo Oracle Deutschland Juni 2017
Kennen Sie schon die Database Service Firewall in der Oracle Datenbank 12.2?
Norman Sibbing

Den aufmerksamen Blicken eines Datenbank-Administrators ist es sicherlich bereits aufgefallen. Mit der Version 12.2 ist die Anzahl der mitgelieferten Datenbank-Benutzer leicht gestiegen. Einer dieser neuen Benutzer heißt DBSFWUSER.

Doch welche Aufgabe hat er?

Seine Aufgabe entspricht im Prinzip genau seinem Namen 'DataBase Service FireWall USER'. Aber eine Art SQL*Net Firewall (TCP.VALIDNODE_CHECKING) für die Datenbank existiert doch bereits. Worin sich die neue Sicherheitsmaßnahme jetzt genau unterscheidet, sehen wir jetzt.
Blicken wir erst einmal zurück und schauen uns die bekannte (alte) Funktionalität nochmal an.

Der Oracle Listener als SQL*Net Firewall

SQL*NET kann den Zugriff auf eine Oracle Datenbank auf Basis von IP-Adressen einschränken. Dies konnte einfach mit den Parametern TCP.VALIDNODE_CHECKING, TCP.INVITED_NODES und/oder TCP.EXCLUDED_NODES in der SQLNET.ORA eingerichtet werden. Auch bekannt als kleine SQL*Net Firewall.

TCP.VALIDNODE_CHECKING = YES
TCP.INVITED_NODES = (10.200.110.205)
Es müssen hier keine, wie im Beispiel verwendet, statische IP-Adressen angegeben werden. Hostnamen, Wildcards (*), IPv4, IPv6 und CDIR sind ebenfalls möglich.
TCP.INVITED_NODES = (10.1.26.*, 10.16.40.0/24, 2001:DB8:3eff:fe38, node2)  

Diese zwei oben gezeigten Parameter bewirken nun, dass ein Zugriff auf die Datenbank nur mit einem Client mit der IP-Adresse 10.200.110.205 möglich ist.
[oracle@dbserver]$ ifconfig enp0s3
enp0s3: flags=4163  mtu 1500
        inet 10.200.110.205  netmask 255.255.255.0  broadcast 10.200.110.255
        inet6 fe80::e252:252c:ae52:7daa  prefixlen 64  scopeid 0x20
        ether 08:00:27:fc:89:5e  txqueuelen 1000  (Ethernet)
        RX packets 3809  bytes 407940 (398.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3280  bytes 450136 (439.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[oracle@dbserver]$ sqlplus system@\"dbserver/pdb1.vbox.local\"

SQL*Plus: Release 12.2.0.1.0 Production on Mon May 15 10:27:02 2017

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

Enter password: 
Last Successful login time: Fri May 12 2017 11:51:56 +02:00

Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

SQL> 
Nun versuchen wir mit einem Client mit der IP-Adresse 10.200.110.1 auf die Datenbank zuzugreifen.
nsibbing@nsibbing-lnx:[~]$ ifconfig vboxnet0
vboxnet0  Link encap:Ethernet  HWaddr 0a:00:27:00:00:00  
          inet addr:10.200.110.1  Bcast:10.200.110.255  Mask:255.255.255.0
          inet6 addr: fe80::800:27ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2067 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:199552 (199.5 KB)


nsibbing@nsibbing-lnx:[~]$ sqlplus system@\"dbserver/pdb1.vbox.local\"

SQL*Plus: Release 12.1.0.2.0 Production on Mon May 15 10:37:13 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Enter password: 
ERROR:
ORA-12547: TNS:lost contact
Der Wirkbereich dieser Sicherheitsmaßnahme gilt allerdings für den Zugriff aller im Listener registrierten Datenbank-Services beziehungsweise Pluggable-Databases. Der Zugriff auf eine einzelne im Listener registrierte Pluggable-Database lässt sich damit nicht kontrollieren. Eine neue, mit der Datenbank Version 12.2 eingeführte Funktionalität - nämlich Service-Level-ACLs - kann genau dieses. Zugriffskontrolle pro Pluggable-Database. Eine weitere Möglichkeit zur Netz-Isolierung von Pluggable-Databases.

Service-Level-ACLs für Pluggable-Databases


Die Funktion Service-Level-ACLs für Pluggable-Databases ermöglicht es für jede Pluggable-Database eine eigene Zugriffskontrollliste (engl: Access Control List) auf Basis von IP-Adressen zu konfigurieren. Diese Zugriffskontrolllisten werden vom Listener beziehungsweise vom Datenbank-Serverprozess ausgewertet. Ein Zugriff auf eine Pluggable-Database ist nur aus dem für sie in der Zugriffskontrollliste freigegebenen IP-Adressen beziehungsweise Netzwerkbereiche möglich. Zur Konfiguration dieser Funktionalität wurde das Package DBMS_SFW_ACL_ADMIN zur Verfügung gestellt. Das Package DBMS_SFW_ACL_ADMIN bietet Schnittstellen zur Erstellung und Verwaltung der Database Service Firewall Zugriffskontrolllisten. Jede Zugriffskontrollliste enthält die IP-Adressen beziehungsweise Netzwerkbereichen der Clients und Hosts, welche Zugriff auf einen bestimmten Datenbankdienst haben. Listener und die Serverprozesse validieren alle eingehenden Verbindungen und handeln entsprechend. Angenommen wir haben mehrere Pluggable-Databases und wollen den Zugriff auf einzelnen Pluggable-Databases nur über bestimmte IP-Adressen erlauben.

Dann gehen wir wie folgt vor.

Zuerst schauen wir uns an, welche Services im Listener registriert sind.
[oracle@dbserver cdb3]$ lsnrctl status

LSNRCTL for Linux: Version 12.2.0.1.0 - Production on 15-MAY-2017 09:59:16

Copyright (c) 1991, 2016, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.200.110.205)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 12.2.0.1.0 - Production
Start Date                15-MAY-2017 09:31:39
Uptime                    0 days 0 hr. 27 min. 37 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/oracle/db/product/12.2.0/dbhome_1/network/admin/listener.ora
Listener Log File         /u01/oracle/db/diag/tnslsnr/dbserver/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.200.110.205)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=10.200.110.205)(PORT=2484)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary...
Service "cdb3.vbox.local" has 2 instance(s).
  Instance "cdb3", status UNKNOWN, has 1 handler(s) for this service...
  Instance "cdb3", status READY, has 1 handler(s) for this service...
Service "cdb3XDB.vbox.local" has 1 instance(s).
  Instance "cdb3", status READY, has 1 handler(s) for this service...
Service "hr_app_pdb01.vbox.local" has 1 instance(s).
  Instance "cdb3", status READY, has 1 handler(s) for this service...
Service "hr_app_root.vbox.local" has 1 instance(s).
  Instance "cdb3", status READY, has 1 handler(s) for this service...
Service "pdb1.vbox.local" has 1 instance(s).
  Instance "cdb3", status READY, has 1 handler(s) for this service...
The command completed successfully

Um die Pluggable-Database 'PDB1' mit dem Servicenamen 'pdb1.vbox.local' im Netz zu Isolieren, gehen wir wie folgt vor. Zunächst muss der Listener ein dynamisches Registrieren der Zugriffskontrolllisten erlauben. Hierzu setzen wir den neuen Listener.ora Parameter LOCAL_REGISTRATION_ADDRESS_listener_name auf ON.
LOCAL_REGISTRATION_ADDRESS_listener=ON
Danach den Listener bitte einmal durchstarten.
Jetzt kommt der neue Benutzer DBSFWUSER ins Spiel. Er hat alle notwendigen Berechtigungen um die Zugriffskontrolllisten für die unterschiedlichen Pluggable-Databases zu erstellen und zu verwalten. Zunächst müssen wir den Benutzer entsperren und ihm ein Passwort geben, da er standardmäßig 'EXPIRED & LOCKED' ist. Alle folgenden Aktionen werden in der Root Container Datenbank durchgeführt.
[oracle@dbserver admin]$ sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on Mon May 15 13:07:01 2017

Copyright (c) 1982, 2016, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

SQL> alter user dbsfwuser identified by **** account unlock;

User altered.
Jetzt melden wir uns als DBSFWUSER an der Root Container-Datenbank an und schauen nach, welche Zugriffskontrolllisten bereits existieren. Eine View mit dem Namen IP_ACL zeigt uns alle Zugriffskontrolllisten an, die zur Verfügung stehen. Eine zweite View V$IP_ACL zeigt an, welche Zugriffskontrolllisten für welche Pluggable-Databases aktiv sind.
SQL> conn dbsfwuser
Enter password: 
Connected.
SQL> select * from ip_acl;

no rows selected

SQL> select * from v$ip_acl;

no rows selected
Natürlich existieren in einer neuen Datenbank keine Zugriffskontrolllisten. Nun legen wir mit dem DBMS_SFW_ACL_ADMIN Package für unsere Pluggable-Database PDB1 eine Zugriffskontrollliste an und bestätigen diese durch Ausführung der DBMS_SFW_ACL_ADMIN .COMMIT_ACL Prozedur.
SQL> exec dbms_sfw_acl_admin.ip_add_pdb_ace (P_PDB_NAME=> 'pdb1', P_HOST=> '10.200.110.205');

PL/SQL procedure successfully completed.

SQL> exec dbms_sfw_acl_admin.commit_acl;

PL/SQL procedure successfully completed.
Auch hier müssen keine statische IP-Adressen angegeben werden. Hostnamen, Wildcards (*), IPv4, IPv6 und CDIR sind ebenfalls möglich. Danach überprüfen wir ob die Zugriffskontrollliste in unserer Konfiguration aktiv ist mittels der V$IP_ACL View.
SQL> select * from v$ip_acl;

SERVICE_NAME	     HOST		      CON_ID
-------------------- -------------------- ----------
PDB1.VBOX.LOCAL      10.200.110.205		   3
Ab jetzt kann sich ein Client nur noch mit der Pluggable-Database 'PDB1' verbinden, wenn er die entsprechende IP-Adresse (10.200.110.205) hat.
Jetzt führen wir den Verbindungstest mittels eines Oracle-Clients durch, dessen IP-Adresse (10.200.110.1) sich außerhalb der erlaubten IP-Adressen befindet.
nsibbing@nsibbing-lnx:[tns]$ sqlplus system@\"dbserver/pdb1.vbox.local\"

SQL*Plus: Release 12.2.0.1.0 Production on Tue May 16 14:06:19 2017

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

Enter password: 
ERROR:
ORA-12506: TNS:listener rejected connection based on service ACL filtering

Enter user-name:
Der Listener quittiert dies mit folgendem Listener.log Eintrag:
16-MAY-2017 14:06:19 * [FIREWALL] * (CONNECT_DATA=(SERVICE_NAME=pdb1.vbox.local)(INSTANCE_NAME=cdb3)(CLIENT_REGISTRATION=4711_LNX)(CID=(PROGRAM=sqlplus)(HOST=nsibbing-lnx)(USER=nsibbing))(CLIENT_REGISTRATION=4711_LNX)) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.200.110.1)(PORT=54764)) * establish * pdb1.vbox.local * 12506 * 10.200.110.1
TNS-12506: TNS:listener rejected connection based on service ACL filtering
Jetzt führen wir den Verbindungstest mittels eines Oracle-Clients durch, dessen IP-Adresse (10.200.110.205) sich innerhalb der erlaubten IP-Adressen befindet.
[nsibbing@dbserver ~]$ sqlplus system@\"dbserver/pdb1.vbox.local\"

SQL*Plus: Release 12.2.0.1.0 Production on Mon May 15 14:46:07 2017

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

Enter password: 
Last Successful login time: Mon May 15 2017 13:38:12 +02:00

Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

SQL> 
Nach jeder Änderung der Zugriffskontrolllisten und nach einem Neustart der Datenbank muss das Kommando 'dbms_sfw_acl_admin.commit_acl' erneut ausgeführt werden. Um das Arbeiten mit den Service-Level Zugriffskontrolllisten flexibel zu halten, wurde ein zusätzliches Attribut für den Listener eingeführt. Das Attribut FIREWALL steuert den Modus der Validierung gegenüber der Zugriffskontrolllisten beim Verbindungsaufbau eines Clients.
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 10.200.110.205)(PORT = 1521)(FIREWALL=ON) )
    )
  )
'FIREWALL = ON' behandelt die Zugriffskontrolllisten nach dem Whitelist-Ansatz. Das bedeutet, dass alle Services die nicht explizit in der Zugriffskontrollliste gelistet sind, geblockt werden.

'FIREWALL = OFF' bewirkt keinerlei Validierungen beim Zugriff eines Clients. Egal ob Zugriffskontrolllisten existieren oder nicht.

Wenn das FIREWALL Attribut nicht angegeben ist, werden vorhandene Zugriffskontrolllisten umgesetzt. Für Datenbank-Services ohne Zugriffskontrollliste wird der Zugriff wie gewohnt zugelassen.

Lizenz

Für die Verwendung der Service-Level-ACLs ist keine zusätzliche Lizenz notwendig oder vorausgesetzt.

Weitere Informationen

 

Zurück zum Anfang des Artikels

Zurück zur Community-Seite