Keine DB Links in meiner Datenbank!

Einführung

Über das sichere Setup eines DB Links in einer Oracle Datenbank habe ich bereits schon berichtet. Neulich kam die Anfrage, wie man prinizipiell die Kommunikation über DB Links zwischen Datenbanken verhindern könnte.
Hierzu eine wirklich einfache Maßnahme, die man schnell umsetzen kann.

INIT.ORA Parameter OPEN_LINKS

Seit einigen Versionen kennt die Oracle Datenbank den init.ora Parameter OPEN_LINKS. Mit diesem Parameter stellt man ein, wie viele DB Links in einer Session geöffnet werden können. Der Default Wert ist 4. D.h. aus einer Datenbank Session heraus dürfen maximal 4 parallele Connections zu entfernten DBs aufgemacht werden. Das schöne bei diesem Parameter ist, dass hier auch external Procedures Calls von betroffen sind.

Will man nun in seiner gesamten DB Landschaft die Kommunikation mittels DB Links verhindern, so wäre eine einfache Maßnahme diesen Parameter in allen Datenbanken auf "0 (NULL)" zu setzen.

Also den Parameter ändern und Datenbank restarten und schon ist die Kommunikation nicht mehr möglich:

SQL > alter system set open_links=0 scope=spfile;
SQL > shutdown immediate

SQL > Startup

Oracle Patch CVE-2012-3132: Privilege escalation

Oracle hat einen Patch zu einer Schwachstelle in der Datenbank geliefert. Genaueres kann man bei Heise lesen.

Nun, wie kann man schnell prüfen, ob die eigene Datenbank betroffen ist. Hierfür habe ich einen kleinen SQL-Script vorbereitet, der überprüft, ob die Privilegien, die erforderlich sind diese Schwachstelle zu nutzen, in der Datenbank vergeben wurden.

DB-User, die folgende Privilegien besitzen, könnten die Schwachstelle ausnutzen und somit  hochprivilegierte Rechte erlangen:

• CREATE TABLE
• CREATE PROCEDURE
• EXECUTE ON CTX_DDL
• EXECUTE ON DBMS_STAT

Folgendes Script könnt Ihr ausführen, um dies schnell zu prüfen:

set heading off
set scan off
select '********** DB SECURITY CHECK USERRIGHTS'||sysdate||
       ' FOR DATABASE: '||name||' **********' from v$database;
set heading on;
echo off; 
feedback off;
verify off; 
underline on;
timing off;
set linesize 400
set pages 1000

spool output.log
col owner format a30
col table_name format a30
col privilege format a30
col grantee format a30
SELECT * from (
select NULL OWNER, 'SYSTEM PRIV' TABLE_NAME, 
       privilege, grantee from dba_sys_privs
 where privilege in ('CREATE TABLE',
                     'CREATE PROCEDURE', 
                     'CREATE ANY TABLE',
                     'CREATE ANY PROCEDURE')
UNION
select owner,
       table_name,
       privilege,
       grantee
  from dba_tab_privs
where  privilege = 'EXECUTE' 
  and table_name in ('DBMS_STATS', 
                     'CTX_DDL')
)
order by grantee, privilege;
col owner clear
col table_name clear
col privilege clear
col grantee clear
spool off
exit

In meiner Datenbank ist genau ein Benutzer betroffen und zwar SCOTT. Die output.log Datei zeigt das Ergebnis.

Der nächste Schritt: Überprüfen, ob die Privilegien notwendig sind, wenn nein entziehen. Danach Patch einspielen.
Oracle Details finden Ihr hier.

Oracle: Change to Audit by Session

Die Empfehlung lautet, Oracle Auditing Statements mittels AUDIT BY ACCESS einzustellen.
In der Dokumentation findet Ihr eine Zusammenfassung:

• Was hat sich verändert? Change to AUDIT BY SESSION:
  http://docs.oracle.com/cd/E11882_01/network.112/e16543/whatsnew.htm#CJAGCGGE
• Vorteile: Benefits of Using the BY ACCESS Clause in the AUDIT Statement
  http://docs.oracle.com/cd/E11882_01/network.112/e16543/auditing.htm#BCGHCAED

Ich habe das mal ausprobiert

Fangen wir mit dem by Session Audit an. Ich möchte gerne ein SELECT meines DB Accounts AUDITSESSION auf eine Tabelle TEST protokollieren. Wenn ich mit dem DB Account AUDITSESSION in der Datenbank eine Abfrage gegen die Tabelle TEST ausführe, so wird das protokolliert:

SQL > connect auditsession

SQL > select  * from test;

Die Protokollierung zeigt mir einen AUDIT_ACTION_CODE (103)= SESSION REC an, sowie den vorherigen Login.

Nun kommt by Access Audit an die Reihe. Ich wiederhole das SELECT meines DB Accounts AUDITSESSION auf die Tabelle Test:

SQL > connect auditsession

SQL > select  * from test;

Die Ausgabe sieht fast identisch aus. Mit BY ACCESS wird aber der Action Code anders gewählt. Nun haben wir einen Action_Code 3 = SELECT.

FAZIT:
Oracle sagt in der Doku, dass mit BY ACCESS die Audit Informationen genauer sind. Ich habe nicht alle Spalten miteinander verglichen, aber dieses Beispiel zeigt einen Unterschied. Also immer BY ACCESS nutzen.