Juni 2016 - DaFRK - Online Brainware for IT Professionals

&bdquo;Woher zieht der sich den Scheiß?“. Diese Frage schwirrt mir beim Upgrade und bei der Installation von komplexen Enterprise-Technologien immer über den Kopf, wenn Dumps geworfen werden, ohne dass in den Logs irgendwelche aussagekräftigen Informationen stehen würden. Hierbei kann es oftmals helfen, wenn man mit tracen kann, welche SQL Statements gerade von der automatischen Prozedur auf der Datenbank ausgeführt werden, und welche Dateien auf dem DAteisystem verändert werden. Dieser Beitrag wird regelmäßig geupdatet, um verschiedene Datenbanken und Dateisysteme abzudecken. SQL-Statements auf eine Oracle Datenbank tracen. Als erstes müssen Sie wissen, wie der User heißt, dessen Session Sie tracen wollen. Eine Liste aller User kriegen Sie über dann braucht irh den client identifier für eine session, die unter diesem usernamen braucht. Den Cleint identifier könnt ihr rausbekommen über Danach aktivieren wir für diesen User die STatistiken Jetzt lasst ihr die atuomatishce Prozedur, die ihr analysieren wollt, nochmal laufen, so dass die abzufangenden SQL Statements auf die Datenbank angesetzt werden. Sobald ihr sicher seid, dass die SQL Statements abgesetzt wurden, deaktiviert ihr den Trace wieder über Die gesammelten Statistiken für den Client identifier könnt ihr nun abrufen über beispielsweise In den STatistiken stehen noch nicht die SQL Statements drin, sondern nur statistische informationen, also beispielsweise welche Art von Statement ausgeführt wurde und wie lange diese gedauert hat. Nun wollen wir detaillierter gehen und aktivierten statt den Statistiken einen detaillierten SQL Trace. Bevor wir den SQL Trace checken müssen wir einige Paramter checken über den Befehl Hierbi checkenw ir folgende parameter diagnostic_dest. Zeigt den Ordner an, in dem später der trace geschrieben wird. In einem SAP system ist dieser Ordner meistens auf X:\ORACLE\TRP\SAPTRACE. MAX_DUMP_FILE_SIZE. Dieser Parameter steht standardmäßig auf UNLIMITED, was bedeutet, dass die Trace Files beliebig groß werden können. DAs kann natürlich dazu führen, dass die Festplattenpartition, in welche die Traces geschrieben werden, voll wird – was wir nicht wollen. Deswegen sollte hier ein Limit gesetzt werden. STATISTICS_LEVEL. Steht diese rWert uaf all, werden zusätzlich zu den SQL Statements auch die Reaktionszeiten mitgeloggt, die wir bereits weiter oben einmal geloggt haben. ist der Wert auf BASIC, werdne diese hingegen nicht mit gesammelt. Desweiterne wird es ohne einen TraceFile Identifier sehr schwer werden herauszufinden, welches Tracefile nachher für uns interessant ist. Daher setzen wir einen solchen Identifier über jetzt aktivierne wir das Tracing für die gesamte Datnebankinstanz über wenn der Trace aktiv ist, bekommt ihr nun einen Datensatz zurück bei der Abfrage Jetzt führen wir wieder die Prozedur aus, die zu den aufzuzeichnednen sQL Statements führt, und beenden danach das Tracing wieder über Wenn ihr nach Deaktiiveren des Traces nun in euer DIAGNOSTIC_DEST-Verzeichnis schaut, werdet ihr dort jede Menge aktuelle Tracefiles finden. Öffnet ihr diese, werdet ihr dort nun SQL Statements vorfinden, die auf die Datenbank ausgeführt wurden. Diese Trace Files könnt ihr jetzt entweder innerhalb des Verzeichnisses nach beispielsweise einer bestimmten Tabelle oder Spalte greppen. Oder ihr könnt die Trace Files auch mit Hilfe der Binary trcsess in eine einzige Datei zusammenfügen. Alle Dateien finden, die sich die letzten x Minuten geändert haben. Oftmals führen Sie eine Tätigkeit in einem Programm durch und Sie wollen wissen, welche Dateien auf dem Betriebssystem dadurch beeinflusst werden. Wenn Sie sich merken, wann Sie die Aktion durchgeführt haben, beispielsweise um 21:35, und um 21:40 wollen Sie wissen, welche Dateien sich die letzten 5 Minuten geändert haben, können Sie im betreffenden Verzeichnis einfach eingeben Oder alternativ können Sie alle DAteien in diesem Verzeichnis nach dem Änderungsdatum absteigend sortieren (die neusten Files stehen unten) und dann eine Uhrzeit greppen. Der folgende String greppt nach allen Dateien, die irgendwann zwischen 21:30 und und 21:39 verändert wurden Dateisystemänderungen dauerhaft tracen. wenn Ihnen die Methode aus dem oberen Abschnitt nicht genügt und Sie stattdessen änderungen auf bestimmte Dateien dauerhaft tracen wollen, ist eventuell die binary audit etwas für Sie. Installation über Starten über Jetzt bestimmen Sie, welche Daten der auditd überwachen soll. Wenn Sie beispielsweise eine Auditing-Regel auf die /etc/passwd legen wollen, die sowohl lesezugriffe als auch Veränderungen an den Ateiattributen trackt, dann geben Sie ein Der Parameter -p bestimmt mit den Werten &bdquo;ra“, dass Lesezugriff (read) und Attributsänderungen (attribute) auf die Datei getrackt werden. Über den Parameter -k geben sie einen eindeutigen Namen ein, der dann in den Audit Logs auftaucht, wenn so eine Aktion an /etc/passwd durchgeführt wird. Wenn Sie nun das log auswerten über dann suchen Sie im Log nach allen Einträgen, die auf Ihre Auditing-Regel passwdtrace zutreffen. Sie können aber nicht nur nach Audit-REgelnamen filtern, sondern z. B. auch nach executables, die auf die Dateien zugegriffen haben oder nach Usern Weitere Nützliche File Changing Tools. inofity-tools, incron DaFRK Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement. www.andreas-loibl.eu

Monatsarchiv: Juni 2016

SAP Systeme absichern und schützen

SAP HANA – Aktuelle Migrations- und Implementierungsszenarien

SQL-Statements und Dateisystemänderungen tracen

Neueste Beiträge

Neueste Kommentare

Archive

Kategorien

Meta