Die IT-Sicherheit und im Speziellen die Datenbanksicherheit wurde in der Vergangenheit in vielen Fällen recht stiefmütterlich behandelt. Spätestens seit den NSA-Enthüllungen im Sommer 2013 bekam dieses Thema jedoch immer mehr Aufmerksamkeit und ist inzwischen ein ständiger Begleiter einer jeden IT-Lösung. Für Firmen, die mit Kreditkartendaten in Berührung kommen, sei es die Abwicklung von Transaktionen, die Übermittlung von Kreditkartendaten oder die Speicherung dieser Daten, ist das Thema Sicherheit und im speziellen die PCI-DSS- Zertifizierung kein Neuland mehr.

Doch was ist diese PCI-DSS-Zertifizierung überhaupt? Die Abkürzung PCI-DSS steht für Payment Card Industry Data Security Standard. Hierbei handelt es sich, einfach ausgedrückt, um einen Datensicherheitsstandard der Kreditkartenindustrie, welcher im Jahr 2006 von American Express, Discover Financial Services, JCB International, MasterCard und VISA Inc. ins Leben gerufen wurde. Durch diesen Standard sollen die Kreditkartendaten der Endkunden sowohl vor Diebstahl als auch vor Missbrauch geschützt werden. Zertifiziert werden müssen diejenigen Systeme, welche mit Kreditkartendaten in Berührung kommen. Dazu zählt neben den üblichen Kreditkartendaten, wie z.B. der Kreditkartennummer auch die dreistellige Kreditkartenprüfnummer. Kommen die firmeneigenen Systeme zu keiner Zeit mit Kreditkartendaten in Berührung, ist auch keine Zertifizierung notwendig. Im Falle einer Überschneidung, auch wenn es z.B. nur die Weiterleitung der Daten an einen Zahlungsdienstleister ist, muss eine Zertifizierung vorliegen. Bei Missachtung werden hohe Strafzahlungen fällig bis hin zum vollständigen Entzug der Erlaubnis, Kreditkartentransaktionen verarbeiten zu dürfen.

Die Firma Herrmann & Lenz Services GmbH hat dabei in der Vergangenheit bereits mehrfach, erfolgreich Kunden bei der PCI-DSS-Zertifizierung begleitet und dabei unter anderem den Bereich Datenbanken übernommen, welcher in den folgenden Abschnitten näher beleuchtet wird. Dabei werden verschiedene Einstellungsmöglichkeiten und Lösungen zur Erhöhung der Sicherheit gezeigt, die in fast jeder Edition (SE, SE One, SE Two, EE) eingesetzt werden können.

Oracle Binaries

Die Sicherheit einer Datenbank beginnt bereits mit einer erfolgreich abgeschlossenen Oracle Server Installation. Im „bin“ Verzeichnis der Installation (ORACLE_HOME) liegen die Executables einer jeden Datenbank. Dort ist auch das Binary

1. oracle (unter Unix/Linux) oder
2. oracle.exe (unter Windows)

zu finden. Unter Linux/Unix besitzt dieses Binary folgende Berechtigungen:

-rwsr-s--x oracle

Auf den ersten Blick ist zu erkennen, dass der Eigentümer der Datei alle Rechte auf diese Datei hat (Lesend, Schreibend und Ausführend). Das „s“ bedeutet dabei, dass die Datei bzw. das Programm zusätzlich zu den Rechten des Users, unter dem das Programm gerade läuft, mit den Rechten des Eigentümers läuft.

Bei den Angaben zu den Gruppenberechtigungen wird sichtbar, dass die Datei ein „r“ für Lesend und ein „x“ bzw. „s“ für Ausführend vorweist. Das „s“ steht in diesem Fall dafür, dass das Programm zusätzlich zu den Rechten des ausführenden Users mit den Berechtigungen der Gruppe läuft.

Alle anderen Benutzer, ausgenommen der Eigentümer und die Benutzer der gleichen Gruppe, dürfen das Programm nur ausführen.

Um nun das eigentliche „Problem“ zu verstehen, ist es gut zu wissen, wie die Datenbank die Verarbeitung von Serververbindungen aufbaut und verwaltet.

Wird eine Verbindung zur Datenbank ohne den Listener aufgebaut, erstellt die Datenbank einen Userprozess und verwaltet diesen (Stichwort: bequeathing oder „beq“) über einen weiteren Serverprozess, dessen Child-Prozess-ID mit der Parent-Prozess-ID des Anwendungsprozesses, z.B. sqlplus, übereinstimmt.

Wird also nach dem Programm sqlplus auf dem Datenbankserver gesucht,

ps –ef | grep sqlplus
26138 22094  sqlplus jkadmin

erhalten wir in diesem Beispiel die Parent-Prozess-ID 26138. Mit Hilfe dieser ID können nun weitere involvierte Prozesse (der Datenbankserverprozess und der sqlplus-Userprozess) gefunden werden:

ps -ef | grep 26138
26139 26138 oracleORCL (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
26138 22094 sqlplus jkadmin

Wird nun die Verbindung über den Listener aufgebaut, erstellt dieser einen Prozess für den User (Stichwort: forking) und baut dabei die Verbindung mit der Datenbank auf. Dabei spielt es keine Rolle, ob die Verbindung lokal vom Datenbankserver oder von einem Client aus über den Listener erstellt wurde. Eine Suche, wie sie bereits oben beschrieben wurde, führt in diesem Fall zu keinem Ergebnis. Es kann zwar der Applikationsprozess gefunden werden, in diesem Fall sqlplus, jedoch nicht der passende Serverprozess. Aus diesem Grund müssen wir die Datenbank mit folgenden SQL-Befehl zu Rate ziehen:

select spid
from v$session s, v$process p
where s.audsid = sys_context('USERENV','SESSIONID')
and p.addr = s.paddr;

Mit Hilfe der gefundenen Prozess-ID kann nun auf dem Datenbankserver danach gesucht werden:

ps -ef | grep 1266
1266  1  oracleORCL (LOCAL=NO)

Aus den nun eben erwähnten Informationen lässt sich ableiten, dass die Datenbank den Serverprozess startet und verwaltet und nicht der User selbst. Der Serverprozess verwendet dabei das Binary „oracle“ oder „oracle.exe. Die Erkenntnis daraus ist, dass die oben beschriebenen Dateiberechtigungen nicht benötigt werden und entfernt werden können:

chmod 0700 $ORACLE_HOME/bin/oracle

Bei diesem Befehl wird auch das SUID-Bit „s“ entfernt und durch ein „x“ ersetzt. Dies bedeutet jedoch, dass keine „bequeathing“ Verbindungen mehr zur Datenbank von anderen Usern, ausgenommen ist der Eigentümer des Binaries, geöffnet werden können. Verbindungen über den Listener sind jedoch nach wie vor möglich.

Neben dem Binary „oracle“ oder „oracle.exe“ gibt es noch weitere Executables, die in Bezug auf ihre Rechte angepasst werden sollten. Leider ist es im Rahmen des Artikels nicht möglich, auf weitere Beispiele einzugehen.

Oracle User Management

Immer wieder ist in verschiedenen Nachrichten zu lesen, dass Benutzerkonten wegen verschiedenster Gründe geknackt wurden.

Aus diesem Grund sieht es die PCI-DSS-Zertifizierung unter anderem vor, dass zum einen keine unnötigen Datenbankbenutzer existieren und zum anderen, dass eine bestimmte Passwortkomplexität etabliert wurde.

Es gibt jedoch Fälle, in denen ein Benutzerkonto nicht gelöscht werden kann. In diesem Fall, seien es nun Oracle Systemuser, technische User oder ehemaliger Mitarbeiter, müssen diese gesperrt werden. Zusätzlich müssen alle Standardpasswörter geändert werden.

Im „Database 2 Day + Security Guide“ als auch im

„Database Installation Guide 12c Release 1“ kann eine Liste aller Oracle Standardbenutzer mit ihren Standartpasswörtern eingesehen werden.

Mit Hilfe des folgenden SQL-Statements können alle User auf einer Datenbank angezeigt werden, welche aktuell ein Oracle Standard Passwort besitzen:

Select * from DBA_USERS_WITH_DEFPWD;

In Bezug auf den User „XS$NULL“ gibt es einen Hinweis im „Database 2 Day + Security Guide“:

[…

An internal account that represents the absence of database user in a session and the actual session user is an application user supported by Oracle Real Application Security. XS$NULL has no privileges and does not own any database object. No one can authenticate as XS$NULL, nor can authentication credentials ever be assigned to XS$NULL.

…]

Mit anderen Worten: Es ist nicht möglich das Passwort dieses Accounts zu ändern.

Passwortregeln

Auch bei der Passwortkomplexität muss ein gewisser Level erreicht werden. Dabei sollte zwischen technischen und persönlichen Benutzern unterschieden werden. Mit Hilfe von Datenbankprofilen kann diese Differenzierung realisiert werden. Ein Grund für eine Trennung in zwei verschiedene Profile ist z. B., dass es für die Funktionalität des Systems kontraproduktiv sein kann, wenn ein Passwort nach 90 Tagen automatisch abläuft. Im folgenden Abschnitt werden einige Beispiele für die Passwortkomplexität aufgezeigt und ein Beispielprofil gezeigt:

1. Bei der ersten Anmeldung muss das Passwort geändert werden.
2. Das Passwort besteht aus mindesten acht Zeichen, welches sich aus Groß- und Kleinbuchstaben, Sonderzeichen und Zahlen zusammensetzt. Bei der Umsetzung des Passworts sollte dabei nicht auf die Ehrlichkeit des Users vertraut werden, sondern vielmehr dieses mit Hilfe einer Passwortprüfungsfunktion automatisiert überprüft werden.
3. Die letzten vier Passwörter dürfen nicht wiederverwendet werden.
4. Ein Passwort wird nach 90 Tagen ungültig und muss geändert werden.

Es existieren noch viele weitere Möglichkeiten, das Passwort vor möglichen Angreifern zu sichern. Die oben genannte Liste beinhaltet nur einen kleinen Ausschnitt der möglichen Optionen. Der folgende Code zeigt eine Beispielimplementierung eines Profils:

create profile personal_users limit
password_life_time 90
PASSWORD_REUSE_TIME 365
PASSWORD_REUSE_MAX 4
FAILED_LOGIN_ATTEMPTS 6
PASSWORD_VERIFY_FUNCTION f_check_personal_pwd;

Das oben genannte Profil weist folgende Konfiguration vor:

1. Das Passwort ist maximal 90 Tage lang gültig
2. Ein Passwort kann 365 Tage lang nicht wiederverwendet werden
3. Die letzten vier Passwörter sind ebenfalls gesperrt
4. Nach sechs fehgeschlagenen Anmeldeversuchen wird der Account gesperrt
5. Das Passwort wird mittels einer Funktion überprüft.

Neben diesen sind noch weitere Einstellungen möglich.

Audit-Einstellungen

Um im Falle eines Vorfalls eine nahezu lückenlose Aufklärung betreiben zu können, bietet Oracle mit seinen Audit-Einstellungen ein hohes Maß an Überwachung einzelner Aktionen an. Im Zuge einer geplanten Zertifizierung ist es unabdingbar, dass Aktionen, vor allem von personenbezogenen Accounts, überwacht werden. Die Überwachung der technischen User ist an vielen Stellen nicht sinnvoll, da z. B. das Löschen oder Verändern von Datensätzen durchaus im Rahmen gewisser Prozesse nötig ist. Dennoch könnte es z.B. sinnvoll sein, gewisse Tabelleninhalte von technischen Usern zu überwachen. Ein Beispiel wäre die Überprüfung von verschlüsselten Kreditkartennummern dahingehend, dass diese auch wirklich verschlüsselt in der Tabelle abgespeichert wurden. Neben der Überwachung der persönlichen und administrativen Benutzer, muss auch eine lückenlose Überwachung aller Aktionen der Oracle Systemuser (SYS und SYSTEM) garantiert sein.

Im folgenden Abschnitt werden einige Audit-Einstellungen gezeigt und kurz erläutert:

audit select table by %USERNAME% by access;

Bei dieser Auditeinstellung werden alle Select-Statements auf Tabellen von einem Benutzer protokolliert. %USERNAME% ist dabei durch den entsprechenden Benutzernamen zu ersetzten. Mehrere User können kommasepariert angegeben werden.

audit session by %USERNAME% by access;

Bei dieser Einstellung wird jede Erstellung einer Session eines Users protokolliert.

audit alter sequence, alter table, delete table, execute procedure by %USERNAME% by access;

In diesem Beispiel werden die Anpassung einer Sequenz, die Änderung einer Tabelle, das Löschen einer Tabelle und das Ausführen einer Prozedur für einen oder mehrere Benutzer überwacht.

Weitere Einstellungen können dem „Database Security Guide“ entnommen werden.

Um die Aktivitäten des SYS-Users zu überwachen, können keine Audit-Einstellung verwendet werden. Aus diesem Grund ist es notwendig, dass der folgende Datenbankparameter gesetzt wird:

AUDIT_SYS_OPERATIONS=TRUE

Die Audit-Informationen können dabei entweder in der Datenbank abgespeichert oder aber im Filesystem abgelegt werden. Eine Ablage im Filesystem hat den Vorteil, dass zum einen keine Datenbankoperationen, wie das Löschen der Audit-Informationen, durchgeführt werden können, zum anderen kann der Zugriff auf diese Dateien mit Hilfe von Verzeichnisberechtigungen beschränkt und im Falle eines Datenbankausfalls weiterhin gelesen werden. Des Weiteren lassen sich Dateien mittels Monitoring Lösungen automatisiert überwachen.

Firmen, die im Besitzt einer Enterprise Edition sind, haben die Möglichkeit, weitere detailliertere Auditeinstellung mittels Oracle FGA (Fine Grained Auditing) vorzunehmen.

begin
DBMS_FGA.ADD_POLICY(OBJECT_SCHEMA => 'SCOTT',
OBJECT_NAME => 'T_CREDITCARD',
POLICY_NAME => 'CC_varString_Audit',
AUDIT_CONDITION => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'')!= ''SCOTT'' ',
AUDIT_COLUMN => NULL,
ENABLE => TRUE,
STATEMENT_TYPES => 'SELECT,INSERT,UPDATE,DELETE',
audit_trail => DBMS_FGA.XML + DBMS_FGA.EXTENDED);
end;
/

Das oben genannte FGA-Beispiel sorgt für eine Überwachung der Tabelle T_CREDITCARD im Schema SCOTT für die SQL-Befehle „SELECT“, „INSERT“, „UPDATE“ und „DELETE“. Von der Überwachung sind alle User, außer der Tabelleneigentümer SCOTT, betroffen. Mit Hilfe von FGA wäre auch die Überwachung der Selektion einer einzelnen Tabellenspalte möglich.

Seit der Version 12c stehen mit dem Feature „Unified Auditing“ weitere Möglichkeiten zur Verfügung. Weitere Informationen können diesbezüglich dem „Database Security Guide“ entnommen werden.

Listener-Konfigurationen

Auch der Listener ist immer wieder Angriffspunk für mögliche „man-in-the-middle“ Attacken. Spätestens seit Veröffentlichung der Sicherheitslücke CVE-2012-1675 von Oracle, auch bekannt unter „TNS Listener Poison Attack“, sollte jeder Listener bis Version 11.2.0.3 folgende Parameter beinhalten:

SECURE_REGISTER_LISTENER_PROD=(IPC)

Dieser Parameter sorgt dafür, dass der Listener die Registrierung zur Datenbank nur noch über das IPC-Protokoll aufbaut. Da sich für dieses Protokoll die Datenbank und der Listener auf demselben Host befinden müssen, sind „man-in-the-middle“-Attacken nicht mehr ohne weiteres möglich. Ab Version 11.2.0.4 gibt es eine andere Möglichkeit um den Listener zu sichern (Stichwort: VALID_NODE_CHECKING) – siehe MOS-Artikel 14538831.1. Die zuvor beschriebene Lösung ist jedoch weiterhin möglich. Zusätzlich sollte, sofern kein Data Guard, RAC oder das PL/SQL Gateway für APEX im Einsatz ist, der Parameter

dynamic_registration_LISTENER_NAME=off

gesetzt werden. Diese Einstellung bewirkt, dass der Listener keine dynamischen Registrierungen mehr zulässt.

Zusätzlich sollte das Listener-Log automatisiert überwacht werden. Nur so lassen sich mögliche Attacken auch frühzeitig erkennen.

SQLNET.ORA Parameter

Mit Hilfe von SQLNET.ORA Parametern ist es ebenfalls möglich, die Sicherheit der Datenbank zu erhöhen. Mit Hilfe der beiden Parameter

TCP.VALIDNODE_CHECKING=YES
TCP.INVITED_NODES=(%node1%,%node2%)

kann z. B. die Datenbank so konfiguriert werden, dass nur von bestimmten Servern oder Clients aus, Verbindungen zur Datenbank aufgebaut werden können. Der erste Parameter sorgt dabei für eine generelle Aktivierung dieses Features und dementsprechend für einen Abgleich der IP-Adressen zwischen der Adresse, von der die Verbindunganfrage kommt mit denen, die in der White List aufgelistet sind.

Die White List stellt der zweite Parameter – TCP.INVITED_NODES – dar. Hier werden alle IP-Adressen, kommasepariert, aufgelistet, die für eine Verbindung zur Datenbank freigegeben sind.

PFILE/SPFILE-Parameter

Neben den bisherigen beschriebenen Möglichkeiten gibt es ganze Listen an weiteren Möglichkeiten, mit denen die Datenbank mit Hilfe von Konfigurationsparametern gehärtet werden kann. Mit Hilfe des Datenbankparameters

SEC_MAX_FAILED_LOGIN_ATTEMPTS=3

wird z. B. der maximale fehlgeschlagene Verbindungsaufbauversuch zur Datenbank festgelegt. Sollte, wie in diesem Fall, der dritte Versuch eines möglichen Logins fehlschlagen, wird die Verbindung automatisch beendet.

Neben den zuvor genannten Parameter ist der folgende ein weiterer wichtiger Kandidat:

SEC_PROTOCOL_ERROR_TRACE_ACTION=ALERT

Mit Hilfe dieser Einstellung werden sogenannte „Bad Packets“ protokolliert. Je nach Konfiguration werden diese Informationen z.B. entweder ignoriert oder aber, wie bei der oben genannten Initialisierung, in Form eines kurzen Einzeilers in ein Trace-File und das Alert.log der Datenbank geschrieben. Das eigentliche Problem wurde dadurch jedoch nicht gebannt oder gelöst. Mit Hilfe des folgenden Parameters kann z. B. ein „denial-of-service“-Angriff etwas entschärft werden:

SEC_PROTOCOL_ERROR_FURTHER_ACTION=Delay,3

Dieser Parameter gibt die Zeit in Sekunden an, welche die Datenbank nach der Identifizierung eines Client oder Server Protokoll Fehlers („Bad packets“) z.B. aufgrund eines „denial-of-service“-Angriffs wartet, bevor die nächste Anfrage desselben Clients entgegen genommen wird.

Patch-Management (PSU)

In regelmäßigen Abständen – einmal pro Quartal – werden von Oracle sogenannte Patch Set Updates (PSU) veröffentlicht. Diese Patche beinhalten neben normalen Bug Fixes auch Sicherheitsupdates.

Nach Erscheinen eines solchen PSUs sollte dieses umgehend auf allen Datenbanken installiert werden. Das Patch-Management ist auch ein wichtiger Bestandteil einer PCI-DSS-Zertifizierung. Weitere Informationen können unter dem fünften Punk der „Links“ eingesehen werden.

Monitoring

Auch das oft stiefmütterlich behandelte Monitoring dient als zusätzlicher Schutz vor möglichen Angreifern. Um frühzeitig über mögliche Gefahren oder Probleme auf der Datenbank informiert zu werden, ist eine automatisierte Überwachung diverser Dienste und Dateien durch eine Monitoring Lösung, wie das Monitoring-Module der Firma Herrmann & Lenz Solutions GmbH, unabdingbar.

Fazit

Das Thema Sicherheit ist in der heutigen Zeit eines der zentralen Themen in einer jeden IT-Landschaft. Oracle bietet mit seiner Datenbanklösung eine Vielzahl von Sicherheitslösungen an. Viele dieser Einstellungen können dabei bereits in einer Standard-Edition eingesetzt werden.

Sollten die, in einer Standard Edition zur Verfügung stehenden Sicherheitsvorkehrungen nicht ausreichen, kann mit Hilfe der Enterprise Edition auf weitere Funktionalitäten zugegriffen werden.

Mit Hilfe der lizenzpflichtigen Zusatzoption „Oracle Advanced Security“ stehen nochmals weitere Features, wie z.B. die Verschlüsselung sämtlicher Tabelleninhalte, zur Verfügung. Eine Verschlüsselung von Datenbank Exports und RMAN-Backups ist mit dieser Option ebenfalls möglich.

Die im Verlauf dieses Artikels gezeigten Möglichkeiten reichen jedoch nicht aus, um z.B. erfolgreich eine PCI-DSS-Zertifizierung bestehen zu können. Des Weiteren ist zu beachten, dass nicht alle Bereiche und Einstellungen sowie Konfigurationen beleuchtet werden konnten.

Dieser Artikel soll lediglich als Denkanstoß dienen und über die Vielfalt der möglichen Sicherheitseinstellungen und Konfigurationen einer Oracle Datenbank informieren.

Sollten Sie Unterstützung rund um das Thema Datenbanksicherheit benötigen, können Sie sich jederzeit an die Firma Herrmann & Lenz Services GmbH wenden.

Links

[1] PCI Security Standards Council: https://de.pcisecuritystandards.org/minisite/en/

[2] Database 2 Day + Security Guide: https://docs.oracle.com/database/121/TDPSG/toc.htm

[3] Database Installation Guide 12c Release 1: https://docs.oracle.com/database/121/LADBI/toc.htm

[4] Database Security Guide: https://docs.oracle.com/database/121/DBSEG/toc.htm

[5] Critical Patch Updates: http://www.oracle.com/technetwork/topics/security/alerts-086861.html

[6] HL-Monitoring: https://hl-solutions.de/produkte/monitoring-module/

[7] OraInfo: https://hl-solutions.de/produkte/orainfo/