Mitgehört

Typische Angriffe auf die Kombination von SAP und Oracle-Datenbank und ihre Abwehr waren Thema in iX 8/2008. Um den Einsatz von Auditing zur Aufdeckung von Angriffen und schädlichen Handlungen geht es im Folgenden.

18.12.2008, 02:00 Uhr

Lesezeit: 10 Min.

iX Magazin

Von

Jan Kästle
Stefan Hölzner

Im Vordergrund eines Sicherheitskonzepts sollte immer das Verhindern von Angriffen stehen. Falls es aber doch einmal passiert: Wie kann man wenigstens im Nachhinein das Vorgehen des Angreifers entlarven? Und wie bindet man privilegierte Benutzer, etwa Administratoren, zu ihrem eigenen Schutz sowie zur Einhaltung von Gesetzen und Regularien in ein ganzheitliches Überwachungskonzept ein? Manche Normen, wie der Data Security Standard der Kredikartenindustrie [1], fordern etwa das Aufzeichnen von Zugriffen auf bestimmte Daten. Es ergeben sich also unterschiedliche Aufgaben, die man mit Logging- und Auditing-Konzepten in großen Teilen bewältigen kann.

Dieser Artikel gibt einen Überblick über Einsatzmöglichkeiten und Grenzen von Logging- und Auditing-Features als aufdeckende Kontrollen und illustriert ihren Einsatz an Beispielen.

Beim Aufbau eines Auditing-Konzepts sollte man zuerst festlegen, welche Ereignisse zu protokollieren sind, wie sich betrügerische Handlungen erkennen lassen und auf welche Weise das Auditing überwacht wird.

Zu auditierende Ereignisse stellen in der Regel Abweichungen von der Norm dar und treten somit nicht massenhaft auf. Bei einer zu großzügigen Definition der Filter kann die Anzahl der Log-Einträge jedoch massiv ansteigen und die Leistung stark beeinträchtigen. Insbesondere im Fall von SAP ist es deshalb nötig, die zu überwachenden Ereignisse sorgfältig auszuwählen.

Audit-Dateien vor Manipulation schützen

Zudem sollte man für den Schutz der Audit-Dateien sorgen, damit ein Angreifer das Auditing nicht abstellen oder Log-Dateien löschen kann. Nur so kann der „Audit-Trail“ die zeitliche Reihenfolge der aufzuzeichnenden Handlungen oder Systemfunktionen manipulationssicher dokumentieren.

Standardmäßig ist bei Oracle-Datenbanken lediglich das sogenannte Mandatory Auditing aktiv, das sich nicht abschalten lässt. Es protokolliert das Starten und Anhalten der Datenbank sowie Anmeldungen des Benutzers SYS und Verbindungen mit SYSOPER- und SYSDBA-Rechten. Mandatory Auditing schreibt sein Protokoll immer in Dateien.

Onlinequellen

SYSDBA-Rechte sind allumfassende Befugnisse, die noch über normale Administrationsrechte – die sogenannten DBA-Rechte – hinausgehen. Wer sie besitzt, darf Datenbanken anlegen, starten und anhalten sowie Backup oder Recovery ausführen. SYSOPER-Rechte sind demgegenüber einschränkt, beispielsweise gestatten sie nicht das Anlegen einer Datenbank. Oracle empfiehlt, SYS-Berechtigungen so wenig wie möglich einzusetzen. Für normale Administrationstätigkeiten reichen DBA-Erlaubnisse aus (siehe „Onlinequellen“, [a]).

Weniger schweigsam als das viel zu knappe Mandatory Auditing zeigt sich Standard Auditing, das normale Datenbanktätigkeiten protokollieren kann. Es erfasst jedoch keine Benutzer mit SYS-Rechten. Speziell für sie hat Oracle das SYS Auditing geschaffen. Fine Grained Auditing erweitert die Standard-Variante: Es wertet detaillierte Kriterien für die Erzeugung von Protokolleinträgen aus. Des Weiteren können Datenbank-Trigger das Eintreten komplexerer Ereignisse aufzeichnen. Einige kommerzielle Audit-Produkte beziehen auch die Redo-Logs der Datenbank in ihre Auswertungen mit ein.

Das Auditing sämtlicher SQL-Befehle des mächtigen Benutzers SYS sowie Verbindungen mit SYSDBA- und SYSOPER-Berechtigungen aktiviert der Eintrag audit_sys_operations = true in init.ora. Hier gilt es jedoch, eine Besonderheit zu beachten: Wer sich mit SYSDBA-Rechten mit der Datenbank verbindet, wird als Benutzer SYS in der Datenbank geführt; bei einer Anmeldung als SYSOPER taucht er dort als PUBLIC auf. Dadurch ermöglicht der Protokolleintrag keine Rückschlüsse auf den tatsächlichen Akteur.

Personalisierte Konten erlauben Identifizierung

Da das Betriebssystembenutzerkonto, mit dem die Anmeldung an der Datenbank erfolgt, ebenfalls im Log erscheint, lässt sich die Identifizierbarkeit jedoch durch die Verwendung personalisierter Benutzerkonten im Betriebssystem erreichen.

Personalisierte Benutzerkonten sollten ohnehin für Administrationsarbeiten auf dem Betriebssystem verwendet werden, damit sich diese Aktionen zuordnen lassen. Wenn immer root solche Arbeiten durchführt, bleibt der tatsächliche Anwender unerkannt.

Weil bei der Anmeldung an der Datenbank mit SYS-Rechten von einem anderen Rechner keine Kontrolle über das Betriebssystembenutzerkonto vorhanden ist, sollte man diese Art der Verbindung verhindern. Dazu müssen der init.ora-Parameter remote_login_passwordfile auf none gesetzt und Oracles Passwortdatei entfernt sein. Ein Benutzer ist somit nur berechtigt, sich mit SYSDBA-Rechten anzumelden, wenn er der lokalen Unix-Gruppe dba angehört. Bei Windows heißt diese Gruppe ORA_<SID>_DBA [b]. Den Trail des SYS Auditing schreibt Oracle grundsätzlich direkt in Dateien, da Benutzer mit SYS-Rechten in der Datenbank alle Rechte haben und folglich Protokolleinträge in Datenbanktabellen löschen können. Deshalb sollten die Dateiberechtigungen sicherstellen, dass die SYS-Benutzer die Protokolldateien nicht ändern können. Einen vollständigen Schutz kann man jedoch nur erreichen, wenn die Protokolleinträge an ein anderes System gesendet werden.

Schrankenloses SYS Auditing

SYS Auditing ist keineswegs optimal, weil man dafür keine Kriterien oder Filterregeln festlegen kann. Es protokolliert schlicht jedes einzelne SQL-Statement. Da Standard Auditing Benutzer mit SYS-Rechten jedoch nicht erfasst, ist es hierzu keine Alternative – und weitere Maßnahmen sind nötig.

Beim Standard Auditing kann man Regeln erstellen, die außergewöhnliche Ereignisse definieren. Sie sind für alle Benutzer ohne SYS-Rechte wirksam. Der Parameter audit_trail schaltet Standard Auditing ein; audit_trail = OS beispielsweise schickt die Protokolleinträge in Dateien. Alternativ kann Oracle sie in Datenbanktabellen schreiben. Das Einschalten via audit_trail alleine erzeugt noch keine Protokolleinträge. Das geschieht erst, wenn die festzuhaltenden Ereignisse definiert sind. Zu ihnen sollte unbedingt gehören, welcher Benutzer sich wann an der Datenbank anmeldet. Dies kann durch Überwachen des für den Verbindungsaufbau benötigten Privilegs CREATE SESSION erfolgen:

audit create session;

Fehlgeschlagene Anmeldungen mit nicht vorhandenen Benutzern oder mehrere fehlgeschlagene Logins hintereinander sind klare Anzeichen für einen Angriff. Die Logeinträge beim Versuch, sich mit Oracles Standardbenutzern mit Standardpasswörtern anzumelden, zeigt Listing 1 [2].

Listing 1: Anmeldeversuche mit nicht existierenden Benutzerkonten

SQL> select username,action_name,returncode,
     to_char(timestamp,'DD-MON-YYYY HH24:MI:SS')
     from dba_audit_session
     where not exists
        ( select 'x'
          from dba_users
          where dba_users.username=dba_audit_session.username);

USERNAME        ACTION   RETURNCODE TIMESTAMP
--------------- -------- ---------- --------------------
ADAMS           LOGON          1017 23-AUG-2008 02:33:51
ADLDEMO         LOGON          1017 23-AUG-2008 02:33:51
APPLSYS         LOGON          1017 23-AUG-2008 02:33:51
APPLYSYSPUB     LOGON          1017 23-AUG-2008 02:33:51
APPS            LOGON          1017 23-AUG-2008 02:33:51
AQ              LOGON          1017 23-AUG-2008 02:33:51
AQDEMO          LOGON          1017 23-AUG-2008 02:33:52
AQJAVA          LOGON          1017 23-AUG-2008 02:33:52
AQUSER          LOGON          1017 23-AUG-2008 02:33:52
AUDIOUSER       LOGON          1017 23-AUG-2008 02:33:52
BC4J            LOGON          1017 23-AUG-2008 02:33:52
BLAKE           LOGON          1017 23-AUG-2008 02:33:52
CATALOG         LOGON          1017 23-AUG-2008 02:33:52
CDEMO82         LOGON          1017 23-AUG-2008 02:33:52
CDEMOCOR        LOGON          1017 23-AUG-2008 02:33:52
CDEMORID        LOGON          1017 23-AUG-2008 02:33:52
CDEMOUCB        LOGON          1017 23-AUG-2008 02:33:52
CENTRA          LOGON          1017 23-AUG-2008 02:33:52
CIDS            LOGON          1017 23-AUG-2008 02:33:52
CIS             LOGON          1017 23-AUG-2008 02:33:52
CISINFO         LOGON          1017 23-AUG-2008 02:33:52
...

Ferner ist es wichtig, Änderungen der Audit-Konfiguration selbst zu protokollieren. So lässt sich aufdecken, wenn ein Angreifer seine Spuren verwischen will:

audit audit system by access;

Anzeichen für einen Angriff oder betrügerische Handlungen sind beispielsweise das Anlegen von Benutzern, das Zuweisen von Systemrechten, das Anlegen von Datenbank-Links sowie das Ändern von Datenbankprofilen. All dies auditieren die folgenden Kommandos:

audit user by access;
audit system grant by access;
audit public database link by access;
audit database link by access;
audit profile by access;

Das Privileg ALTER SYSTEM kann hier ebenfalls mit einbezogen werden, um grundlegende Änderungen an der Konfiguration der Datenbank zu auditieren. Listing 2 zeigt die möglichen Logeinträge aus einem Angriff auf einen ungeschützten TNS-Listener. Er manipuliert durch Umsetzen des Listener-Logfiles das Skript glogin.sql und erlaubt dem Angreifer so, ein eigenes Benutzerkonto anzulegen. Zwar wurde das hier nicht verhindert, die Attacke ist jedoch in den Logeinträgen eindeutig dokumentiert. Erfolgt eine geeignete Alarmierung, kann man dem Vorfall schnell nachgehen. Allerdings sollte der TNS-Listener von vornherein gegen solche Manipulationen abgesichert sein.

Listing 2: Log-Einträge nach einem Angriff über den TNS-Listener

SQL> select  username, priv_used, obj_name, 
     to_char(timestamp,'DD-MON-YYYY HH24:MI') timestamp, 
     returncode 
     from dba_audit_trail 
     where priv_used is not null 
     and priv_used<>'CREATE SESSION';

USERNAME PRIV_USED           OBJ_NAME    TIMESTAMP         RETURNCODE
-------- ------------------- ----------- ----------------- ----------
ADMIN    CREATE USER         HACK3R      23-AUG-2008 02:46          0
ADMIN    GRANT ANY ROLE                  23-AUG-2008 02:46          0
ADMIN    GRANT ANY PRIVILEGE             23-AUG-2008 02:46          0

Wer welche Daten gelesen hat

Bei besonders hohen Sicherheitsanforderungen lassen sich mit Fine Grained Auditing detailliertere Bedingungen definieren, zum Beispiel um den lesenden Zugriff auf eine bestimmte Spalte einer Tabelle zu protokollieren. Das Fine Grained Auditing wird anhand sogenannter Policies definiert. Dabei lässt sich einschränken, für welche Tabellen und Spalten sie gelten. Zudem ist es möglich, weitere Kriterien zur Erzeugung von Protokolleinträgen anzugeben. Das hier aufgeführte Beispiel zeigt eine Policy, die lesende Zugriffe auf die Gehaltstabelle eines SAP-HR-Systems protokolliert, sofern das selektierte Jahresgehalt über 100 000 liegt.

DBMS_FGA.ADD_POLICY(
     object_schema => 'SAPR3',
     object_name => 'PA0008',
     policy_name => 'check_gehalt',
     audit_condition => 'ANSAL > 100000',
     audit_column => 'ANSAL'
     statement_types => 'select');

Diese Definitionen beziehen die vom SAP-System selbst durchgeführten Zugriffe ein, was eine größere Zahl von Protokolleinträgen erzeugt. Dies lässt sich durch eine geeignete Wahl der audit_condition ausschließen. Zugriffe innerhalb der Anwendung sollte das SAP-System selbst protokollieren.

Datenbankadministratoren oder andere Angreifer können in der Datenbank gespeicherte Audit-Logs löschen. Deshalb sollten die Protokolle nicht dorthin, sondern an das Betriebssystem gehen. Unter Linux/Unix müssen möglichst restriktive Berechtigungen den Zugriff auf diese Logs und das Verzeichnis schützen, in dem sie liegen. Dies reduziert zwar das Risiko, bietet jedoch keine vollständige Funktionstrennung, die in der Praxis auch oft nicht realisierbar ist. Neuere Linux/Unix-Releases gestatten es, die Audit-Logs in das Syslog des Betriebssystems zu schreiben, zu dem nur Superuser Zugriff haben. Der Königsweg ist jedoch, die Audit-Logs über den Syslog-Mechanismus direkt an einen zentralen Log-Host zu senden.

Wählt man bei Windows das Betriebssystem als Ablageort, schreibt Oracle die Audit-Einträge in das Event-Log, sodass man sie ebenfalls an einen zentralen Host senden kann. Dort sollten die Audit-Logs einer regelmäßigen Kontrolle unterliegen. Entsprechend ihrem Risiko sollten die Ereignisse priorisiert und unterschiedlich behandelt werden, etwa durch das Versenden von E-Mail oder SMS an einen Verantwortlichen für besonders kritische Ereignisse. Die Administratoren dürfen keinen schreibenden Zugriff auf dieses System haben.

Mit den beiden neueren Produkten von Oracle, dem Database Vault und dem Audit Vault, lassen sich eine echte Funktionstrennung und ein zentraler Log-Host realisieren. Der Database Vault erlaubt es, Berechtigungen zu trennen, für die dies bisher nicht oder nur schwer möglich war. Dazu gehören die SYS-Rechte. Der Audit Vault ist eine auf Oracle-Datenbanken optimierte zentrale Auditing-Lösung, die Ereignisse aus allen in diesem Artikel genannten Auditing-Funktionen einbeziehen kann. Beide Produkte sind jedoch derzeit von der SAP AG nicht freigegeben [d].

Jan Kästle und Stefan Hölzner
arbeiten bei KPMG in der IT-Sicherheitsberatung und in der Prüfung von IT-Systemen. Jan Kästle ist Senior Associate, Stefan Hölzner Senior Manager und Leiter des Security-Testing-Teams.