„Secure by Default“ in Oracle 11g – Die sichere Datenbank out-of-the-box? Kathleen Hock ORDIX AG Wiesbaden Schlüsselworte: „Secure by Default“, Security, Auditing, Benutzerprofil, ACLs, Passwortverwaltung, Passwortschutz Einleitung Noch nie hat Oracle das Thema „Security“ so ernst genommen wie in letzter Zeit. Die aktuelle Datenbank Version 11g ist gespickt mit zahlreichen internen, neuen und verbesserten Security-Funktionen. Einen entscheidenden Anteil nimmt hierbei die neue Initiative „Secure by Default“ ein, die es dem Datenbankadministrator erleichtert, eine sicherere Datenbank outof-the-box zu installieren. Überblick Unter „Secure by Default“ versteht Oracle eine ganze Reihe von out-of-the-box Maßnahmen, welche die Oracle 11g Datenbank sicherer machen sollen als eine vergleichbare 10gInstallation. Zu diesen Maßnahmen gehören: • Standardmäßiges Auditing • Änderungen am Standard Benutzerprofil • Verbesserte Überprüfung der Passwort-Komplexität • Delayed Failed Logins • Fine Grained Access Control (FGAC) bei Netzwerk-Callouts aus der Datenbank Neben der Vorstellung der oben genannten „Enhanced default security settings“ spielen der verbesserte Passwortschutz und ein erweitertes Passwortmanagement eine zentrale Rolle unter den neuen Security-Funktionen, die Oracle 11g standardmäßig mit sich bringt. Ob und wie die hier eingeführten Maßnahmen wirklich zu einer out-of-the-box sichereren Datenbank führen und mit welchem Aufwand dies für den Datenbankadministrator zu erreichen ist, wird im Rahmen des Vortrages näher beleuchtet. „Enhanced Default Security Settings” im DBCA 11g Gleich zu Beginn des Arbeitens mit Oracle 11g kommt der Anwender mit der neuen Initiative „Secure by Default“ in Berührung. Schon der Database Configuration Assistant (DBCA) fragt

sowohl beim Anlegen, als auch beim nachträglichen Ändern der Datenbank, ob die „Enhanced default security settings“ eingeschaltet werden sollen:

Abb. 1: Abfrage im DBCA, ob die „Enhanced default security settings“ eingeschaltet werden sollen.

Oracle empfiehlt, diese Frage mit dem ersten Auswahlpunkt zu beantworten (siehe Abbildung 1). Dies hat Anpassungen des Standard-Benutzerprofils sowie ein standardmäßiges Auditing bestimmter Operationen zur Folge, was in den folgenden zwei Absätzen näher erläutert wird. Standardmäßiges Auditing Über das Standard-Auditing lassen sich Aktionen von Benutzern in drei Bereichen protokollieren: • • •

Objekte Kommandos Privilegien

Werden die „Enhanced Default Security Settings“ unter Oracle 11g eingeschaltet, so ändert sich der Default des Standard-Auditings folgendermaßen: • •

Der Parameter AUDIT_TRAIL steht dann auf DB, statt wie bisher auf NONE. Viele Aktionen werden nun zwangsweise per Standard-Auditing in die Audit-Tabelle AUD$ protokolliert. Hierzu zählen Aktionen, die unter Nutzung der in Abbildung 2 dargestellten Privilegien durchgeführt werden.

Abb. 2: Vordefinierte Einstellungen des Standard-Auditing unter Oracle 11g.

Was aus Gründen der Sicherheit eine gute Maßnahme darstellt, kann sich allerdings schnell zum Problem entwickeln, da es keinen Automatismus für das Löschen der Audit-Daten in der Audit-Tabelle (AUD$) gibt. Die Tabelle wird schnell zunehmend größer, was je nach Konfiguration bis zum Stillstand der Instanz führen kann. Die Tabelle sollte also in einen dedizierten Tablespace gelegt werden. Zudem sollten die entstandenen Audit-Daten regelmäßig verarbeitet werden. Bei einer neu erstellten oder migrierten Datenbank empfiehlt es sich außerdem, diese Audit-Einstellungen zu überprüfen und ggf. an die eigenen Bedürfnisse anzupassen. Änderungen am Standard-Benutzerprofil Durch das Einschalten der „Enhanced default security settings“ werden nicht nur die Einstellungen für ein standardmäßiges Auditing aktiviert, sondern auch Änderungen am Standard-Benutzerprofil vorgenommen (siehe Abbildung 3). SQL> select from where and

RESOURCE_NAME, LIMIT DBA_PROFILES PROFILE = 'DEFAULT' RESOURCE_TYPE = 'PASSWORD';

RESOURCE_NAME -------------------------------FAILED_LOGIN_ATTEMPTS PASSWORD_LIFE_TIME PASSWORD_REUSE_TIME PASSWORD_REUSE_MAX PASSWORD_VERIFY_FUNCTION PASSWORD_LOCK_TIME PASSWORD_GRACE_TIME

LIMIT -----------------------------10 180 UNLIMITED UNLIMITED NULL 1 7

Abb. 3: Änderungen am Standard-Benutzerprofil beim Einschalten der „Enhanced default security settings“.

Drei der Profileinstellungen, PASSWORD_LOCK_TIME, PASSWORD_GRACE_TIME und PASSWORD_LIFE_TIME, werden durch die automatische Anpassung nun restriktiver behandelt. So bedeutet die PASSWORD_LIFE_TIME von 180, dass sämtliche Benutzer – egal ob DBA oder Batch-Benutzer – nach 180 Tagen ihr Passwort ändern müssen! Was aus Security-Sicht sicherlich der richtige Ansatz ist, führt jedoch bei Batch-Programmen, Skripten etc., die ihre Kennwörter fest verdrahtet haben und diese nicht selbständig ändern können, zum Absturz nach 180 Tagen! Um dies zu verhindern, empfiehlt es sich vor Ablauf der 180 Tage ein spezielles Profil anzulegen, in dem PASSWORD_LIFE_TIME auf UNLIMITED gesetzt wird, und nur den Benutzern zuzuteilen, deren Passwort aus genannten Gründen nie ablaufen soll.

„Secure by Default“ – Verbesserte Passwort-Verifizierungsfunktion Oracle liefert mit dem erweiterten Passwort-Management, welches bereits in Oracle 8 eingeführt wurde, das Skript $ORACLE_HOME/rdbms/admin/utlpwdmg.sql aus. Über die Ausführung dieses Skriptes wird in der Datenbank eine PL/SQL-Funktion angelegt, die neu eingegebene oder geänderte Benutzerkennwörter auf ausreichende Komplexität überprüft. In Oracle 11g wurde das Skript utlpwdmg.sql erweitert und liefert jetzt zusätzlich die Funktion VERIFY_FUNCTION_11G, in der die Anforderungen an die Komplexität des Passwortes signifikant erhöht wurden: • • • • • • •

Minimale Passwortlänge von 8 Stellen (bisher: 4 Stellen) Passwort ungleich Username(1-100) (neu) Passwort ungleich Username rückwärts geschrieben (neu) Passwort ungleich Datenbankname, Datenbankname(1-100) (neu) Mehr „einfache“ Passwörter werden geprüft (z. B. welcome1, database1, user1234, etc.) Passwort ungleich oracle(1-100) (neu) Passwort muss mindestens 1 Buchstabe und mindestens 1 Zahl beinhalten (bisher: 1 Buchstabe, 1 Zahl und 1 Sonderzeichen)

Da die neue Verifizierungsfunktion auch in 11g standardmäßig nicht eingerichtet ist, muss das Skript utlpwdmg.sql weiterhin explizit ausgeführt werden. Mit Ausführung des Skriptes werden neben der Erstellung der neuen Funktion, der Parameter PASSWORD_VERIFY_FUNCTION auf VERIFY_FUNCTION_11G geändert sowie die auf die Ressource PASSWORD bezogenen Parameter gemäß den „Enhanced Default Security“Einstellungen neu gesetzt. „Secure by Default“ – Verzögertes Login bei falscher Passworteingabe Der Versuch, sich mehrfach mit falschem Kennwort an einen existierenden Benutzer in der Datenbank anzumelden, löst ab Oracle 11g eine verzögerte Bearbeitung weiterer LoginVersuche an diesen Benutzer aus. Diese Maßnahme, mit deren Hilfe Brute-Force-Attacken erschwert werden sollen, gehört mit zum Standard in 11g und wird nach 3 Fehlversuchen wirksam. Die verzögerte Login-Bearbeitung greift auch dann, wenn versucht wird, die Verbindung von einer anderen IP-Adresse oder Host aus aufzunehmen. FAILED_LOGIN_ATTEMPTS vs. SEC_MAX_FAILED_LOGIN_ATTEMPTS Die soeben beschriebene Verzögerung bei fehlerhaften Anmeldeversuchen setzt sich bis zur Sperrung des betroffenen Accounts in der Datenbank fort. Die Anzahl der hier möglichen Versuche ist auch in 11g weiterhin durch die Angabe FAILED_LOGIN_ATTEMPTS im Passwortprofil des Benutzers begrenzt. Im Gegensatz dazu bezieht sich der in Oracle 11g eingeführte Initialisierungsparameter SEC_MAX_FAILED_LOGIN_ATTEMPTS nicht auf einen bestehenden Account in der

Datenbank, sondern auf jeglichen fehlerhaften Anmeldeversuch mit unbekanntem Benutzer und Passwort. Bleiben 10 dieser wahlfreien Angriffsversuche (= Intruder) ohne Erfolg, wird die Verbindung abgebrochen; eine Funktionalität, die allerdings nur im Kontext einer OCIApplikation zum Tragen kommt. Access Control Listen (ACLs) – Kontrolle der Netzwerkzugriffe aus der Datenbank In der Oracle Datenbank existieren bereits seit längerer Zeit eine Reihe von PL/SQLPackages, mit deren Hilfe Informationen aus der Datenbank heraus an beliebige, im Netzwerk erreichbare Server geschickt werden können. Zu diesen „Netzwerk“-Paketen zählen: • • • • •

UTL_TCP UTL_SMTP UTL_MAIL UTL_HTTP UTL_INADDR

Diese Pakete sind bis Oracle 10g durch das EXECUTE-Privileg, das standardmäßig an PUBLIC(!) vergeben ist, zur Ausführung freigegeben. Diese uneingeschränkte und allgemeingültige Zugriffsmöglichkeit auf das gesamte Netzwerk erscheint praktisch, stellt aber ein erhebliches Sicherheitsrisiko dar. Dem begegnet Oracle 11g mit einem neu eingeführten Sicherheitskonzept: Netzwerkzugriffe, die durch PL/SQL-Pakete erfolgen, müssen vom DBA sowohl für die einzelnen Ziele als auch für die einzelnen Benutzer bzw. Rollen separat freigegeben werden. Diese Freigabe erfolgt über so genannte Access Control Listen (ACLs). Programmtechnisch werden die ACLs mit dem neuen Package DBMS_NETWORK_ACL_ADMIN erzeugt und verwaltet (siehe Abbildung 4). BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'khodba_ordix.xml', description => 'Network Access Control for KHODBA with UTL_*', principal => 'KHODBA', is_grant => TRUE, privilege => 'connect'); END; / BEGIN DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( acl => 'khodba_ordix.xml', host => 'ordix.de'); END; / commit; Abb. 4: Anlage und Zuordnung einer ACL unter Oracle 11g.

Aber Achtung: ACLs werden als XML-Dokumente unter Verwendung der XML DBKomponente abgelegt. Daher muss für das Arbeiten mit ACLs die XML DB in der Datenbank installiert sein. Stärkerer Passwortschutz: Case-sensitive Passwörter Die Erkennung von Groß- und Kleinschreibung bei Kennwörtern, was bei Unix-Systemen längst zur üblichen Notation gehört, wird ebenfalls mit Version 11g eingeführt. Gemäß dem neuen Standard werden Passwörter jetzt zusätzlich case-sensitiv erstellt und sind aufgrund des hierdurch erweiterten Zeichensatzes stärker gegenüber Angriffen – z. B. per Brute-Force oder über Wörterbuch – gewappnet. Über den dynamischen Parameter sec_case_sensitive_logon Funktionalität zu- und abschalten (siehe Abbildung 5).

lässt

sich

diese

SQL> alter system set sec_case_sensitive_logon=TRUE; System altered. Abb. 5: Ab Oracle 11g können Passwörter case-sensitiv erstellt werden.

Bei aus früheren Datenbankversionen migrierten oder importierten Benutzern bleiben die Kennwörter zunächst case-insensitiv erhalten, bis das Passwort erstmalig in Oracle 11g geändert wird. Erst danach zieht die neue case-sensitive Authentifizierung. Stärkerer Passwortschutz: Passwort Versionen In welcher Oracle-Version das Passwort erstellt wurde, kann der zusätzlichen Spalte PASSWORD_VERSIONS in der View DBA_USERS entnommen werden (siehe Abbildung 6). SQL> select username, password_versions from dba_users; USERNAME PASSWORD --------------- -------RON 10G JOE 10G 11G BOB 11G

Abb. 6: Passwortversionen in der View DBA_USERS.

Wie das Beispiel in der Abbildung zeigt, wurde Benutzer RON über ein Upgrade übernommen, das Kennwort aber noch nicht umgesetzt, so dass die alte Kennwortmethode über Großbuchstaben (10G) hier weiterhin gilt. Demgegenüber wird bei den beiden Benutzern JOE und BOB die neue case-sensitive Methode befolgt, sollte sie denn über sec_case_sensitive_logon=TRUE eingestellt sein.

Der Hash-Wert des case-sensitiven Passwortes (11G) wurde hier entweder durch ein unter 11g neu erstelltes oder auf 11g gewechseltes Passwort erzeugt. Bei BOB wird zudem die Case-Sensitivität des Passwortes erzwungen, indem nur der 11g Oracle Hash als Wert (IDENTIFIED BY VALUES) verwendet wurde; ein Wechsel auf das alte Verfahren ist hier nicht mehr möglich, was vielleicht die sicherste Einstellung an dieser Stelle darstellt. Datenbank-Links und Case-Sensitivität Passwörter in früheren Releases sind nicht case-sensitiv; sie werden ausschließlich in Großbuchstaben abgelegt. Aus diesem Grund kann sich hier der Verbindungsaufbau zu einer „case-sensitiven“ Oracle 11g Datenbank mittels Datenbank-Link als problematisch herausstellen. Sobald Groß- und Kleinschreibung auf der entfernten Gegenseite abgeprüft wird, gilt es, für die Angabe des Passwortes folgende Besonderheiten zu berücksichtigen (siehe Abbildung 7).

Abb. 7: Datenbank-Links und Case-Sensitivität.

Stärkerer Passwortschutz: Case-Sensitive Passwortdatei Die entfernte Authentifizierung von Administratoren mit SYSDBA- oder SYSOPERPrivilegien wird außerhalb der Datenbank mit Hilfe der Passwortdatei vorgenommen. Auch bei entfernten Anmeldungen über SYSDBA oder SYSOPER gilt ab Oracle 11g grundsätzlich die Nutzung case-sensitiver Passwörter. Diese Wirkungsweise kann hier über die Definition des Password Files mit folgendem Befehl wieder deaktiviert werden: orapwd file= $ORACLE_HOME/dbs/orapw$ORACLE_SID ignorecase=y

Zu beachten gilt, dass Passwörter von aus früheren Releases migrierten oder importierten Benutzern mit SYSDBA- bzw. SYSOPER-Privileg vorerst case-insensitiv bleiben. Erst die nächste Änderung ihres Passwortes unter Verwendung einer case-sensitiven Passwortdatei, berücksichtigt auch die Groß- und Kleinschreibung bei Anmeldungen über das Password File. Stärkerer Passwortschutz: Passwort Hashing In Oracle 11g wird das verschlüsselte Passwort nicht mehr in der Spalte PASSWORD der Data Dictionary View DBA_USERS angezeigt. Benutzer mit dem SELECT-Privileg auf DBA_USERS (via SELECT_CATALOG_ROLE) werden somit ab jetzt daran gehindert, über den Hash-Wert der Kennwörter Manipulationen unter fremden Benutzerkennungen vorzunehmen. Verfahren, die sich mittels „ALTER USER IDENTIFIED BY VALUES...;“ weiterhin dem verschlüsselten Kennwort bedienen möchten, benötigen stattdessen den Lesezugriff auf die interne Tabelle SYS.USER$ (siehe Abbildung 8).

Abb. 8: Ablage der Hash-Werte beider Passwortversionen im Data Dictionary.

In USER$.PASSWORD wird nach wie vor das case-insensitive Passwort in Form des Oracle 10g Hash Wertes (= Hash über USERNAME||UPPER(PASSWORD)) abgelegt. In USER$.SPARE4 wird das case-sensitive Passwort nun zusätzlich mit einem „echten“ SALT zusammengesetzt und ein Hash-Wert mit dem ab 11g verwendeten Hash-Algorithmus SHA-1 (= 160-bit Hash) gebildet. Stärkerer Passwortschutz: Prüfung auf Standardpasswörter Bisherigen Erfahrungen zufolge gehören Standardkennwörter mit zu den Hauptrisiken für einen unberechtigten Zugriff auf die Datenbank durch Dritte.

Demzufolge lässt sich die Frage nach dem Auffinden von Standardkennwörtern, die in jedem Security-Projekt gleich zu Anfang gestellt wird, sehr gut nachvollziehen. Mit der in Oracle 11g eingeführten View DBA_USERS_WITH_DEFPWD trägt Oracle dieser Fragestellung Rechnung. Eine einfache Abfrage auf diese View ergibt eine Liste der von Oracle angelegten Benutzer, die noch über ihr Standardkennwort verfügen (siehe Abbildung 9). SQL> select * from dba_users_with_defpwd; USERNAME -----------------------------OUTLN SCOTT SYSTEM XDB ... Abb. 9: Abfrage zum Auffinden von Standardkennwörtern..

Da die neue View auch gesperrte (‘LOCKED’) Datenbank-Accounts beinhaltet, empfiehlt sich, die Abfrage mit der View DBA_USERS zu verknüpfen (siehe Abbildung 10). select username from dba_users_with_defpwd where username in (select username from dba_users where account_status = 'OPEN'); Abb. 10: Abfrage zum Auffinden von Standardkennwörtern von aktiven Benutzern.

Als Ergebnis werden nur noch Standardbenutzer mit einem Standardkennwort und aktivem Account Status (‚OPEN’) angezeigt, was hier von eigentlichem Interesse ist. Wir empfehlen, die View DBA_USERS_WITH_DEFPWD regelmäßig zu kontrollieren und die Standardpasswörter der hier gefundenen, aktiven Oracle-Benutzer umgehend zu ändern. Kontaktadresse: ORDIX AG Kathleen Hock Kreuzberger Ring 13 D-65205 Wiesbaden Telefon: Fax: E-Mail Internet:

+49 (0)611 77840-15 +49 (0)180 1673490 [email protected] www.ordix.de