Subscribe to RSS Feed

CIFS-Audit mit NetApp und SCOM

17. November 2010 by

Endlich gepackt… Ich habe jetzt vier Tage damit verbracht CIFS – Auditprotokolle auf eine halbwegs anständige Weise in einen zentralen Auditserver zu integrieren. Dabei werden durch NetAPP Event-LOG-Dateien produziert, welche auf einer speziellen Freigabe liegen. Diese Dateien liegen im Microsoft Security-LOG-Format vor. Diese werden zunächst via Task eingesammelt und mit einem Powershellskript aufbereitet und eine MS-SQL Datenbank abgelegt. Für mich als Powershell-Noob war es doch ein Stück arbeit die Inhalte aus der .evt Datei entsprechend aufzubereiten und über den Reporting Service die  entsprechende Reports zu hinterlegen. Alles in Allem ist das kein Hexenwerk, aber ich kann sagen, ich habe doch einiges dazu gelernt. Da die Dateien im Moment noch mit einem regelmäßigen Task abgehot werden, will ich über SCOM eine SYSLOG getriggerte Variante implementieren, damit die Dateien nicht unnötig lange auf einem zentralen Storage liegen. Mal schauen, wie lange ich dafür die nächste Zeit brauche…

Tags: , ,

4 Responses to CIFS-Audit mit NetApp und SCOM

  1. KK on 25. November 2010 at 22:03

    Poser ;)

    Jetzt aber zurück zu Linux !

  2. Jordan on 21. September 2011 at 15:15

    Hi, ich stehe genau vor dieser Herausforderung, Könnte ich ein paar Infos von dir bekommen wie du das Problem gelöst hast, am meisten interessiert mich wie du die Daten in die SCOM DB reinbekommen hast und hast du es bereits geschaft die Auditdaten mittels Syslog in die AuditDB einzuspeisen?

  3. Lupo on 4. Juni 2013 at 11:33

    Moin, der Eintrag ist zwar schon älter …. aber vielleicht kannst du mir ja ein Tipp geben wie ich die .evt über den Reporting Service zum Scom schicke

  4. admin on 10. Juni 2013 at 10:12

    Leider habe ich hierfür keine Dokumentation mehr zur Hand, da ich das Unternehmen zwischenzeitlich verlassen habe.
    Ich hätte mir damals das ManagementPack exportieren sollen- aber das habe ich leider vergessen :(
    Ich werde dir aber alles, was ich noch darüber weiß gerne beschreiben.

    Generell:
    Das ist eine Lösung die ganz klar Bastelarbeit erfordert, aber nach der Implementierung sehr zuverlässig funktioniert hatte.
    Da die Lösung schon mehr als zwei Jahre alt ist und es zum damaligen Zeitpunkt keine professionelle Lösung
    gab – musste es leider über diesen Weg laufen:

    Allerdings hat sich der Datenschutzbeauftragte des Landes Hessen damals für diese Lösung interessiert und hat diese lobend in
    in seinem Jahresbericht erwähnt. So schlecht kann die Lösung also nicht gewesen sein ;)

    Was wir dazu brauchen war folgendes [eine Kurzfassung, welche dir hoffentlich den Ansatz zeigt]:

    1. Einen Service Account
    Einen Service Account, welcher Berechtigung hat, sich auf dem SCOM Server als Task anzumelden.
    Dieser Service Account benötigt zusätzlich Berechtigungen sich auf den Audit-Share anzumelden (Lesen/Schreiben)

    2. Syslog Weiterleitung
    Eine SYSLOG Weiterleitung von der NetAPP zum SCOM Server. Dieses wird benötigt um das “Audit File Created” Event abzufangen.
    Dieses triggert dann eine Prozedur im SCOM server, welcher einen Task startet.

    3. Einen Task auf dem SCOM Server [wir haben diesen Task damals auf den ACS laufen lassen]
    Dieser muss mit den Berechtigungen des Service Accounts aus 1. laufen. Dieser Task hat einen stündlichen Rhythmus, wird
    aber durch eine Rule (in 4.) getriggert. Dieser Task enthält ein Powershell skript, welches
    a. die .evt Datei abholt
    b. diese als Events einließt
    c. in eine separat erstellte Tabelle in der Auditdatenbank abspeichert
    d. Die .evt anschließend Verschlüsselt (mittels GPG) und wieder ablegt.
    e. Dieser Task erstellt abhängig von der Verarbeitung lokale Events im Application Log (z.B. Cifs Datei verarbeitet, Cifs Datei fehlte…, ….)
    Diese Events sollten via Regeln/Monitore im SCOM abgefangen und überwacht werden.

    4. Eine Rule (Regel) im SCOM Server.
    Diese Regel lauscht auf Syslog Eingänge von den Filerköpfen (NetApp) mit den Inhalt “Audit file Created”. und triggert den
    in 3. angegebenen Task. Damit erhälst du eine minimalisierte Zeitverzögerung von der Erstellung der Event-Datei bis zur Abholung.
    im Regelfall dauert es dann bis zu 10 Sekunden – ansonsten ist der maximale Unterschied zwischen Generierung und Abholung der Datei,
    der Zeitabstand deines Tasks.

    5. Eine separate Audit-Tabelle (oder Datenbank) im SQL
    Um die .evt in eine Datenbank zu bringen benötigt man hierfür Tabelle in der sich alle Events befinden. Ich habe die Events immer nach den Attributen
    aufgesplittet:
    * EventID
    * User/Group
    * TargetObject (File or directory)
    * Original Message Text

    6. Einen Report im SQL Reporting Server
    Um die Events auch ordentlich verwerten zu können, müssen hier Reports angelegt werden – je nach Bedürfnis auf besonders
    schützenswerte Ordner oder bestimmte Events. Manchmal reichte auch nur ein normaler Report

    7. Mehrere SCOM Monitore
    Der SCOM Monitor dient dazu, zu messen, ob in regelmäßigen Intervallen
    a. Das Event “Syslog Settings… modified” von der Netapp geliefert wurde (deutet auf ein Abschalten des Syslogs hin!!)
    b. Das Event “Cifs Audit Disabled…” von der Netapp gelifert wurde (cifs audit wurde abgeschaltet)
    c. Das Event “Audit File Created” mindestens innerhalb der letzten zwei Stunden aufgetreten ist (es kommt auf die Nutzung des Filers an)
    Aber wenn das Event nicht regelmäßig erstellt wird, deutet es auf ein Abschalten des Audits hin

    Basierend auf den Monitoren natürlich entsprechende Alertingrules um Alarme zu eskalieren.

    Lass mich wissen wenn du noch weitere Hilfe brauchst oder Fragen hast.

    Viele Grüße und viel Erfolg

    Toni

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


Stay in Tune

    Twitter

    Follow Me on Twitter!