SIEM in der Praxis: Freundschaft schließen mit Prelude + Cisco IPS und HeartBleed-Betrieb durch Korrelation aufdecken

    Guten Tag an alle!
    Das SIEM-Thema selbst war in letzter Zeit sehr beliebt. Angesichts der komplexen Komplexität dieser Systeme sind die mit ihrer Verwendung verbundenen Probleme tiefgreifend und umfangreich. Es gibt eine ganze Reihe von Artikeln (über Habré und nicht nur), die sich mit SIEM befassen. Die überwiegende Mehrheit von ihnen geht jedoch auf das Thema in Bezug auf Theorie, Methodik und allgemeine Prinzipien für die Konstruktion von Prozessen ein. Es gibt jedoch nicht katastrophal wenige Artikel, die die praktischen Aspekte der Anwendung / Konfiguration dieser Systeme beschreiben . In diesem Artikel wird beschrieben, wie Sie IPS- und SIEM-Freunde anhand von Cisco IPS und Prelude in der Praxis gewinnen. Außerdem wird ein Beispiel für eine Korrelationsregel beschrieben, die den erfolgreichen Betrieb der HeartBleed-Sicherheitsanfälligkeit aufzeigt, die in den letzten Tagen schmerzhaft geworden ist.




    1. Einleitung / Problemstellung


    Also, wir haben IPS in Inline implementiert , was nun?
    Offensichtlich besteht der nächste Schritt darin, irgendwie zu überwachen, was IPS fängt, in welcher Menge, von wem und wo angegriffen wird usw.
    Genauer gesagt:
    1. Es ist erforderlich, eine Reihe von aktiven Signaturen zu verwalten, die für die geschützten Hosts relevant sind.
    2. Für den effektiven Betrieb von IPS-Sensoren müssen Sie sich ständig "auf dem Laufenden halten": Sie müssen den Sensor ständig an bestimmte Netzwerke und Verkehr anpassen. Dies wird durch das Einrichten von Regeln mit Ausnahmen erreicht.
    3. Unter den zahlreichen Warnungen, die von IPS empfangen werden, müssen die wirklich wichtigen und kritischen Punkte hervorgehoben werden.
    4. Für kritische Warnungen ist es außerdem erforderlich, die richtigen aggressiven Aktionen (Blockieren des Datenverkehrs, Zurücksetzen von Sitzungen, IP-Sperren usw.) des Sensors anzugeben und den Administrator darüber zu informieren.
    5. Der Zustand des Sensors selbst muss ebenfalls überwacht werden (Auslastung des Scanmoduls, Aktualisierungsfehler, Gültigkeitsdauer der Lizenz usw.).

    Um solche Probleme zu lösen, müssen Sie ein bequemes und gleichzeitig funktionales Werkzeug auswählen.

    2. Native IPS-Ereignisanzeige


    Es gibt viele Möglichkeiten, Ereignisse aus IPS zu erfassen und zu verarbeiten.
    Unter den Standard-Ereignisanzeigen von Cisco-Sensoren gibt es folgende Optionen:

    2.1 Ereignisse lokal auf dem Sensor anzeigen


    Dieses Werkzeug, dessen Prinzip als "in der Stirn" beschrieben werden kann. Jeder Sensor verfügt über einen eigenen lokalen Ereignisspeicher. Natürlich können Sie darin nur sehen, was direkt an einem bestimmten Sensor erkannt wurde.



    Eine Gruppierung / Zusammenfassung von Ereignissen aus irgendwelchen Gründen ist nicht vorgesehen. Das Maximum, das Sie sich leisten können, besteht darin, die angezeigten Ereignisse nach einer Reihe von Kriterien zu filtern (Signaturkritikalität, Abtastzeit, Ereignisse des Sensorsystems anzeigen / nicht anzeigen). Die Ereignisliste selbst sieht folgendermaßen aus:



    Tatsächlich ist die Verwendung dieser Funktion entweder für das Debuggen (beim Übertragen von Ereignissen auf externe Systeme) oder für die Verwendung eines einzelnen Sensors durch die Organisation sinnvoll (obwohl die Lösung, um es milde auszudrücken, selbst für eine solche Situation nicht die bequemste ist) )

    2.2 Cisco IPS Manager Express


    Die nächste "native" Alternative zum vorherigen Tool ist IME. Dies ist eine kostenlose Lösung von Cisco, die die Konfiguration und Ereignisüberwachung von maximal 10 IPS-Sensoren ermöglicht. In Bezug auf die Konfiguration ist anzumerken, dass es sich hier um eine gemeinsame Konsole für Geräte handelt, d.h. Es gibt keine Möglichkeit, Konfigurationsrichtlinien zu erstellen (mit Ausnahme von drei Parametern für die Funktionen Globale Korrelation, Reputationsfilterung und Netzwerkteilnahme).
    Bei der Erfassung von Ereignissen ist die Situation hier viel besser: Warnungen von verschiedenen Sensoren werden in einer gemeinsamen Datenbank erfasst.



    Die Ereigniserfassung wird sowohl von IPS-Anwendungen / Modulen als auch von IOS-IPS-Routern unterstützt. Es ist möglich, Ereignisse nach verschiedenen Kriterien zu gruppieren und zu filtern. In jedem Fall können Sie "fehlschlagen", um detailliertere Informationen anzuzeigen:



    Eine weitere nützliche Funktion von IME ist die Möglichkeit, über von IPS empfangene Ereignisse per E-Mail benachrichtigt zu werden. Es gibt nur zwei Kriterien für die Auswahl von Warnungen: Bewertung des Angriffsschweregrads und Risikobewertung.



    Obwohl IME ein ziemlich funktionales Tool ist, ist es nicht ohne Einschränkungen. Einer der wesentlichen Nachteile ist, dass IME kein Client-Server-System ist, sondern im Wesentlichen eine reguläre Anwendung, die eine MySQL-Datenbank verwendet. In früheren Versionen wurde IME nicht einmal auf Server- und x64-Bit-Betriebssystemen unterstützt. Die Einschränkungen sind auch die maximale Anzahl unterstützter Geräte (nicht mehr als 10) und die Anzahl verarbeiteter Ereignisse pro Sekunde (100 EPS).

    2.3 Cisco Security Manager


    CSM ist bereits als vollwertige Unternehmenslösung für die zentrale Verwaltung verschiedener Geräte (IPS, ASA / PIX, IOS-Router usw.) positioniert. Die Anzahl der Geräte, die gesteuert werden können, hängt von der erworbenen Lizenz ab. Die Verwaltung selbst erfolgt bereits auf der Grundlage von Richtlinien: Sie können einen Referenzsatz von Einstellungen vornehmen, die später repliziert werden können.
    In Bezug auf das Sammeln, Speichern und Anzeigen von Ereignissen ist CSM IME sehr ähnlich:



    Hier ist es wie in IME möglich, angezeigte Ereignisse nach verschiedenen Kriterien zu gruppieren / aggregieren und zu filtern. Zusätzlich zu Ereignissen von IPS kann CSM auch Ereignisse von ASA / FWSM / PIX-Firewalls verfolgen.
    Sie können auch bei jeder Warnung einen Fehler machen, um detailliertere Informationen anzuzeigen:



    Obwohl CSM im Gegensatz zu demselben IME als Enterprise-Lösung positioniert ist, kann es keine Warnungen von IOS-IPS erfassen (es kann sie jedoch gleichzeitig über Richtlinien konfigurieren). Außerdem kann CSM keine E-Mail-Benachrichtigungen zu Ereignissen senden, die von IPS erfasst wurden.

    CS-MARS
    Es gab noch ein solches CS-MARS-System , aber dieses Projekt wurde für einige Zeit eingestellt, daher wird es nur als historischer Hinweis erwähnt.


    3. SIEM


    Die oben beschriebenen Lösungen sind jeweils auf ihre Weise gut. Aus Sicht der Ereigniserfassung sind sie jedoch eng fokussiert: Zusätzlich zu Ereignissen von IPS (und von Firewalls im Fall von CSM) können wir in ihnen nichts anderes erkennen.

    In meiner Praxis haben Kollegen benachbarter Abteilungen häufig Fragen:
    • Wir haben hier <Kanalbeladung erhöht | Dienst reagiert nicht mehr | System ist ausgezogen | etwas ist passiert> weiß nicht was damit zusammenhängt?
    • Und Sie (IS) haben dort nichts Verdächtiges bemerkt?
    • usw

    In solchen Fällen müssen Ereignisse von Routern, Switches, Protokollen von Unix / Windows, Protokollen bestimmter Systeme, Virenschutzprogramme, Mail-Gateways usw. überprüft werden. Tatsächlich geht die Liste weiter und weiter.
    Vergleichen Sie dies alles anhand einiger Kriterien (Korrelation), und holen Sie sich unterwegs zusätzliche Informationen über die an der Veranstaltung teilnehmenden Hosts: Welche Art von Ressource ist anfällig oder nicht, welche Ports sind offen usw.
    Hier kommen SIEM-Systeme zum Einsatz. Sie sind in der Lage, all das zu tun und dies mit der gebotenen Sorgfalt - auch automatisiert.

    Eines dieser Systeme ist ein in Runet wenig bekanntes Tier namens Prelude. Es wird diskutiert.
    Warum gerade über ihn?
    1. Er gefällt mir.
    2. Es funktioniert (und das schon seit geraumer Zeit).
    3. Er hat eine OSS-Version.
    4. Hat native Kompatibilität mit anderen OSS-Systemen .
    5. Bei Bedarf können Sie eine beliebige Quelle verbinden, die ein Protokoll schreibt.
    6. Daraus können Sie Ihr eigenes „Schweizer Messer“ zusammenstellen, um Vorfälle zu identifizieren, zu untersuchen und darauf zu reagieren.
    7. Das Korrelationsmodul ist in Python als Plug-In-Skript implementiert, was Flexibilität im wahrsten Sinne des Wortes bedeutet. Eine vollständige Programmiersprache bietet die Möglichkeit, beliebige Korrelationsregeln zu schreiben.
    8. Es gibt eine praktische Prewikka-Oberfläche.

    Das Prelude basiert auf dem IDMEF- Format , das die Felder in empfangenen Nachrichten vordefiniert. Zusätzlich zu vordefinierten Feldern können Sie auch eigene Felder mit einem bestimmten Namen und Format (zusätzliche Daten) erstellen, in die Sie alles schreiben können, was nicht in Standardfelder passt. Basierend auf den in verschiedenen Feldern erfassten Daten kann eine Filterung, Aggregation und Korrelation von Ereignissen durchgeführt werden.

    3.1 Präludium Architektur


    In einer vereinfachten Version kann die Systemarchitektur wie folgt dargestellt werden:



    Manager - ist der Kern des Systems. Es ist verantwortlich für den Empfang bereits normalisierter (gepaarter) Ereignisse von LML-Agenten, dem Korrelationsmodul, Systemen von Drittanbietern oder untergeordneten Managern (verfügbar in der kommerziellen Version). Die empfangenen Nachrichten werden in die Datenbank geschrieben. Er ist auch für E-Mail-Benachrichtigungen verantwortlich.

    LML ist ein Systemagent und ein primärer Ereignisanbieter. Es empfängt Protokolle von verschiedenen Systemen (über eine lokale Datei oder über Syslog an einen UDP-Port). Es analysiert / normalisiert die empfangenen Protokolle basierend auf einer Reihe von Regeln, die aus regulären Ausdrücken bestehen. Normalisierte Ereignisse werden an Manager übergeben. LML kann sowohl lokal (auf demselben Server wie Manager) als auch remote ausgeführt werden.

    Korrelator- Korrelationsmodul. Stellt eine Verbindung zu Manager als Agent her. Korreliert Ereignisse, die von Manager empfangen werden, basierend auf Plugins, die als Python-Skripte implementiert sind.

    DataBase - eigentlich eine Datenbank , die speichert alle Ereignisse vom System verarbeitet.

    3 der dritten Partei Systems - Einparteiensystem IDMEF Unterstützung, so dass Sie sie direkt an den Manager-in verbinden.

    Prewikka ist die im Web implementierte Hauptsystemschnittstelle . Entwickelt, um verarbeitete Ereignisse, deren Aggregation / Filterung, Statistikausgabe usw. anzuzeigen.

    Es sieht alles so aus:



    Ereignisse werden in einer Tabelle angezeigt, in deren Spalten sich Informationen zu / über befinden:
    • Klassifizierung von Alarmen (Klassifizierung), die Felder mit dem Namen des Ereignisses, einem Zeichen für dessen (nicht erfolgreichen) Abschluss, ID-Ereignis (Signaturnummer, Schwachstellennummer nach CVE usw.), Kritikalität des Ereignisses usw. enthalten.
    • Quelle / Ziel (Quelle / Ziel) mit Feldern mit IP-Adresse, Mac-Adresse (falls vorhanden), ursprünglichem Benutzernamen, Prozess, Datei usw.
    • Analyzer (Analyzer - Ereignisquelle) mit Feldern mit IP-Adresse, Analyzerklasse usw.

    Die Anzahl der angezeigten IDMEF-Felder hängt von der Art des Ereignisses und der Regel zu seiner Verarbeitung ab. Einige Felder können indiziert werden, d.h. mehrere Werte enthalten. Beispielsweise kann es zwei Felder mit der Kennung userid.name geben, von denen eines den Wert samaccountname und das zweite die Kennung desselben Kontos enthält. Und zum Beispiel wird im Falle eines Ereignisses des Systems zur Überprüfung der Integrität von Dateien in den Quell- und Zielinformationen weder die Adresse noch der Port noch das Protokoll angezeigt - diese Felder werden mit Informationen über die geänderte Datei, Prüfsummen und anderen zusätzlichen Informationen belegt.
    In jedem Fall können Sie "fehlschlagen", um detailliertere Informationen anzuzeigen:



    4. Wie nehme ich Ereignisse von Sensoren auf?


    Bevor Sie IPS als Quelle an unser System anschließen, müssen Sie wissen, wie Sie die darin gespeicherten Warnungen vom IPS abrufen können.
    Es gibt zwei Methoden zum Übertragen von Ereignissen von Cisco-Sensoren (und eine Halbmethode für IOS-IPS) an externe Systeme:

    1) Über SNMP-Trap , der den Sensor selbst auf die Tatsache einer Signatur oder eines Systemereignisses sendet.
    Vom Sensor gesendete Übergänge lauten wie folgt:

    #012iso.3.6.1.2.1.1.3.0 15:1:47:08.58#011iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.4.1.9.9.383.0.1#011iso.3.6.1.4.1.9.9.383.1.1.1.0 6822393729640#011iso.3.6.1.4.1.9.9.383.1.1.2.0 "07 DE 04 0A 0B 2C 0E 00 "#011iso.3.6.1.4.1.9.9.383.1.1.3.0 "07 DE 04 0A 07 2C 0E 00 "#011iso.3.6.1.4.1.9.9.383.1.1.4.0 "IPS-SENSOR-01"#011iso.3.6.1.4.1.9.9.383.1.2.2.0 2147516416#011iso.3.6.1.4.1.9.9.383.1.2.3.0 "Heartbleed"#011iso.3.6.1.4.1.9.9.383.1.2.4.0 "OpenSSL Information Disclosure"#011iso.3.6.1.4.1.9.9.383.1.2.5.0 4187#011iso.3.6.1.4.1.9.9.383.1.2.6.0 0#011iso.3.6.1.4.1.9.9.383.1.2.7.0 "S785"#011iso.3.6.1.4.1.9.9.383.1.2.13.0 0#011iso.3.6.1.4.1.9.9.383.1.2.14.0 "iBCRX+m57XRkOtzSnz0MSIw/CJWscqWUKqhEjadJYMWue6yLZAgTFpc8+LuL#012H/4o5rulPzbm1D9tQZ2tnoY/qfwSZ3H1VE2Wt2/rwUHcjVaKjGue9I0FdGZN#012JgpdbIcOOiBxB0T0JJ0qsqAzTMO37pf6GNOcByoHVgcgubBM2x148331MWSP#012O4hROt/p8Zpk8ZmNBIfUwy4yA0ByxPANY4e+ixHoPOe0aJGk1GUthnyAhKn8#012ztzv/kfCXHyPH5X7DBXTTXYZN+Xv6vnWYJV3tojoaOIpv6shRYLjeg84qeO5#012vY3P0uXwcYSCj1YY4rdgQpQvL8PkOxYDAgAEDgAAAA=="#011iso.3.6.1.4.1.9.9.383.1.2.15.0 "FgMCANwBAADYAwJTQ1uQnZtyC7wMvCuSqEiXz705BMwWCoUDkJ93BDPU3gAA#012ZsAUwArAIsAhADkAOACIAIfAD8AFADUAhMASwAjAHMAbABYAE8ANwAMACsAT#012wAnAH8AeADMAMgCaAJkARQBEwA7ABAAvAJYAQcARwAfADMACAAUABAAVABIA#012CQAUABEACAAGAAMA/wEAAEkACwAEAwABAgAKADQAMgAOAA0AGQALAAwAGAAJ#012AAoAFgAXAAgABgAHABQAFQAEAAUAEgATAAEAAgADAA8AEAARACMAAAAPAAEB#012GAMCAAMBQAAYAwIAAwFAAA=="#011iso.3.6.1.4.1.9.9.383.1.2.16.0 "192.168.1.1:51716"#011iso.3.6.1.4.1.9.9.383.1.2.17.0 "osIdSource=\"unknown\" osRelevance=\"relevant\" osType=\"unknown\" 10.10.10.1:443"#011iso.3.6.1.4.1.9.9.383.1.2.21.0 "InterfaceAttributes:  context=\"single_vf\" physical=\"Unknown\" backplane=\"PortChannel0/0\" ; "#011iso.3.6.1.4.1.9.9.383.1.2.25.0 70#011iso.3.6.1.4.1.9.9.383.1.2.26.0 5#011iso.3.6.1.4.1.9.9.383.1.2.27.0 6#011iso.3.6.1.4.1.9.9.383.1.2.42.0 70#011iso.3.6.1.4.1.9.9.383.1.2.49.0 "vs0"#011iso.3.6.1.4.1.9.9.383.1.3.1.0 "high"
    

    2) Durch den SDEE-Standard. In diesem Fall fungiert der IPS-Sensor als Webserver, und externe Systeme stellen unabhängig eine Verbindung zu ihm her und erfassen neue Warnungen. Diese Methode wird in CSM- und IME-Produkten verwendet. Ciscos SDEE verwendet die CIDEE-Erweiterung, in der zusätzliche Felder beschrieben werden.
    Sie können SDEE-Warnungen in "reiner Form" über den Browser anzeigen, indem Sie https: // in der Adressleiste bewerten/ cgi-bin / sdee-server (Authentifizierung erforderlich).
    Die Warnungen selbst sehen folgendermaßen aus:

    IPS-SENSOR-01sensorApp27106139266879604444500017TCP segment is out of state ordervsx302192.168.0.144310.10.10.124479true2525ge0_3tcp

    Wenn man ein wenig voraus ist, ist es sofort erwähnenswert, dass der Einsatz von SDEE Vor- und Nachteile hat. Über SDEE empfangene Daten enthalten mehr Informationen zu der Warnung als die SNMP-Trap. Beispielsweise gibt es Informationen zu den vom Sensor ausgeführten Aktionen. Für den Export von Daten über SDEE nach SIEM ist jedoch ein spezieller Konnektor erforderlich (in Prelude nur in der kommerziellen Version).

    3) Über Syslog(nur für IOS-IPS). Der Vollständigkeit halber sei auch auf einige Funktionen von IOS-IPS hingewiesen. Sie unterstützen auch SDEE, können jedoch keine Warnungen über SNMP senden. Im Gegensatz zu seinen "älteren" Brüdern kann IOS-IPS Informationen über Warnungen in den lokalen Syslog-Speicher des Routers schreiben. Das Syslog des Routers kann wiederum auf einen externen Server übertragen werden. Die Daten, die in syslog geschrieben werden, sind jedoch äußerst knapp:

    Für iOS 12.x :
    Aug 20 14:21:35 MSK: %IPS-4-SIGNATURE: Sig:15002 Subsig:1 Sev:50  [192.168.1.1:1066 -> 10.10.10.1:5938] RiskRating:30
    

    Sogar der Name der Unterschrift fehlt. Nur ihre SingatureID und SubsibgnatureID.

    Für iOS 15.x :
    Mar  3 11:15:24 MSK: %IPS-4-SIGNATURE: Sig:11020 Subsig:0 Sev:25 BitTorrent Client Activity [192.168.1.1:62809 -> 10.10.10.1:6881] VRF:NONE RiskRating:25
    

    Aber durch SDEEDieselben Warnungen werden in "normaler" Form angezeigt, d. h. mit detaillierten Informationen:
    IOS-IPS-ROUTER13977992510799519200jabber:tcp25192.168.1.16120810.10.10.15222NONEFa0/1NONE


    5. Setup


    Für die Implementierung der auf dem OSS konzipierten Version ist nur die Option mit SNMP-Traps geeignet.
    Das Anschlussdiagramm sieht folgendermaßen aus:



    1. IPS fängt den Angriff ab und sendet SNMP-Trap darüber. (IOS-IPS sendet sofort ein Protokoll an rsyslogd).
    2. Wir akzeptieren SNMP-Trap und senden es an Syslog.
    3. rsyslogd schreibt die empfangene Leiter in eine Datei.
    4. LML analysiert das Protokoll, normalisiert es, extrahiert die Werte aus den für uns interessanten Feldern und schreibt sie in die entsprechenden IDMEF-Felder (Zuordnung).
    5. Das normalisierte Ereignis wird an Manager gesendet und in die Datenbank geschrieben. Danach kann die Veranstaltung über Prewikka angesehen werden.
    6. Eingehende Ereignisse von IPS können auch an das Korrelationsmodul gesendet werden (diese Phase wird separat betrachtet).


    5.1 Vorbereitung


    Sie müssen Prelude zuerst selbst installieren und konfigurieren. Wie zu tun hat dies bereits beschrieben hier .
    Zusätzlich zu Prewikka und Prelude-Manager benötigen wir Prelude-lml und Prelude-Correlator .
    Weitere Informationen finden Sie auch auf der offiziellen Prelude- Website .

    Um snmp- Traps verarbeiten zu können, müssen Sie die Dämonen snmptrapd und rsyslogd (oder ähnliche) konfigurieren .
    Die Hauptaufgabe besteht darin, snmp-Traps aufzunehmen und in eine Datei zu schreiben.
    Sie können dies zum Beispiel so tun:

    snmptrapd.conf
    donotlogtraps  no
    printeventnumbers  yes
    ignoreauthfailure  yes
    authCommunity log,execute public
    traphandle default /usr/sbin/snmptthandler
    

    rsyslog.conf
    if $programname == 'snmptrapd' \
    then /var/log/snmptrapd
    & ~
    

    5.2 Sensorseiteneinstellung


    Der nächste Schritt besteht darin, unseren Sensor zu veranlassen, bei jedem Auslösen der Signatur sowie bei Fehlern am Sensor selbst snmp-Traps zu senden. Aktivieren Sie dazu global SNMP-Traps und geben Sie den Zielserver und die Community an, an die sie gesendet werden sollen:



    Außerdem muss die Aktion "SNMP-Trap anfordern" über "Ereignisaktion" für alle RiskRating-Bereiche zugewiesen werden (wir möchten nichts aus den Augen verlieren). Überschreiben:



    Nach diesen Einstellungen sollten beim Auslösen von IPS die folgenden Ereignisse in unserem / var / log / snmptrapd-Protokoll angezeigt werden :

    Apr 18 16:01:59 prelude-server snmptrapd[11106]: 2014-04-18 16:01:59 10.0.0.1 [UDP: [10.0.0.1]:60457->[192.168.0.1]]:#012iso.3.6.1.2.1.1.3.0 24:12:04:52.86#011iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.4.1.9.9.383.0.1#011iso.3.6.1.4.1.9.9.383.1.1.1.0 6822393753725#011iso.3.6.1.4.1.9.9.383.1.1.2.0 "07 DE 04 13 16 01 3B 00 "#011iso.3.6.1.4.1.9.9.383.1.1.3.0 "07 DE 04 13 12 01 3B 00 "#011iso.3.6.1.4.1.9.9.383.1.1.4.0 "IPS-SENSOR-01"#011iso.3.6.1.4.1.9.9.383.1.2.2.0 2147516416#011iso.3.6.1.4.1.9.9.383.1.2.3.0 "[ \\x26=?.]/etc/passwd[ \\x26=?]"#011iso.3.6.1.4.1.9.9.383.1.2.4.0 "Unix Password File Access Attempt"#011iso.3.6.1.4.1.9.9.383.1.2.5.0 3201#011iso.3.6.1.4.1.9.9.383.1.2.6.0 1#011iso.3.6.1.4.1.9.9.383.1.2.7.0 "S238"#011iso.3.6.1.4.1.9.9.383.1.2.13.0 0#011iso.3.6.1.4.1.9.9.383.1.2.15.0 "R0VUIC9uZXdzL2luZGV4LnBocD9FTEVNRU5UX0lEPS4uLy4uLy4uLy4uLy4u#012Ly4uLy4uLy4uLy4uL2V0Yy9wYXNzd2QgSFRUUC8xLjENCkhvc3Q6IA=="#011iso.3.6.1.4.1.9.9.383.1.2.16.0 "192.168.1.1:22238"#011iso.3.6.1.4.1.9.9.383.1.2.17.0 "osIdSource=\"unknown\" osRelevance=\"relevant\" osType=\"unknown\" 10.10.10.1:80"#011iso.3.6.1.4.1.9.9.383.1.2.21.0 "InterfaceAttributes:  context=\"single_vf\" physical=\"Unknown\" backplane=\"PortChannel0/0\" ; "#011iso.3.6.1.4.1.9.9.383.1.2.25.0 65#011iso.3.6.1.4.1.9.9.383.1.2.26.0 5#011iso.3.6.1.4.1.9.9.383.1.2.27.0 6#011iso.3.6.1.4.1.9.9.383.1.2.42.0 65#011iso.3.6.1.4.1.9.9.383.1.2.49.0 "vs0"#011iso.3.6.1.4.1.9.9.383.1.3.1.0 "medium"
    

    Hier ist 10.0.0.1 die IPS-SENSOR-01-Sensoradresse, 192.168.0.1 die Adresse des Vorservers, auf dem Prelude und snmptrapd tatsächlich installiert sind.

    5.3 LML konfigurieren


    Jetzt müssen Sie den Teil konfigurieren, in dem die ganze „Magie“ des Verwandelns der vom Sensor empfangenen SNMP-Falle in ein Ereignis stattfindet, das auf der grafischen Oberfläche bequem dargestellt wird. Verantwortlich dafür ist das Modul prelude-lml. Es muss auf demselben Server installiert sein, auf dem die SNMP-Traps installiert sind, und ist im Prelude-Manager als Agent registriert.
    Es ist in mehreren Stufen konfiguriert.

    1) Wir bestimmen das Format (und ggf. die Kodierung) des Originalprotokolls. Dies geschieht in der Datei prelude-lml.conf :
    [format=Cisco-IPS]
    time-format = "%b %d %H:%M:%S"
    prefix-regex = "^(?P.{15}) (?P\S+) (?:(?P\S+?)(?:\[(?P[0-9]+)\])?: )?"
    file = /var/log/snmptrapd
    

    Mit dieser Einstellung legen wir im Voraus fest, wie das Zeitformat der Ereignisse im Protokoll aussehen soll, wie der Name und die Adresse des Analysators (in diesem Fall die Adresse des Servers selbst), der Name und die Nummer des Prozesses, der das Protokoll empfangen hat.
    Später können mit einer direkten Analyse des Ereignisses alle diese Werte neu definiert werden. Wenn das Ereignis nicht durch einen Satz von Regeln analysiert werden kann, bleiben die in dieser Phase definierten Werte erhalten.

    2) Wir geben an, auf welches der eingehenden Ereignisse welche Protokollanalyseregeln angewendet werden sollen. Dies geschieht in der Datei pcre.rules und sieht in unserem Beispiel so aus:
    regex=snmptrapd;                        include = cisco-ips.rules;
    

    3) Sie müssen den angegebenen Regelsatz erstellen: cisco-ips.rules . In der Tat verdient dieser Absatz es, ihm einen eigenen Artikel zu widmen. Um die Größe des Artikels nicht zu verdoppeln, führe ich nur die wichtigsten Punkte auf:
    • Ein Regelwerk besteht aus einer Folge von regulären Ausdrücken.
    • Wir können die Reihenfolge ihrer Verarbeitung beeinflussen und „Unterregeln“ für verschiedene Verschachtelungen erstellen.
    • In jeder Regel können wir den gewünschten Wert in Form einer Variablen aus dem Protokoll "herausziehen" und in das entsprechende IDMEF-Feld eingeben. Dieser Vorgang wird als Mapping bezeichnet.
    • Optional können „Unterregeln“ aufgerufen werden, die es ermöglichen, Werte in Ereignissen abhängig von ihrer Zusammensetzung zu ändern.

    Beispiel: Standardmäßig weisen wir allen Ereignissen den Wert des Schweregrads "informativ" zu. Wenn die vom Sensor gesendete Warnung einen anderen Wert für den Angriffsschweregrad enthält, wird unser Attribut neu geschrieben. Auf diese Weise können Sie im Allgemeinen an beliebige Parameter binden und Ereignisse nach Belieben in die Datenbank schreiben. Welchen Grad an Kritikalität SIEM eingehenden Ereignissen (mit oder ohne Korrekturmaßnahmen) zuweisen sollte, ist bereits eine methodologische Frage. Mit den Regeln können Sie jede bequeme / beliebte Option implementieren.
    Das folgende Regelwerk wurde empirisch entwickelt:
    cisco-ips.rules
    #####
    # Copyright (C) 2013 Vladimir Lapshin 
    # Copyright (C) 2013 lei_wulong
    #
    # This file is part of the Prelude-LML program.
    #
    # This program is free software; you can redistribute it and/or modify
    # it under the terms of the GNU General Public License as published by
    # the Free Software Foundation; either version 2, or (at your option)
    # any later version.
    #
    # This program is distributed in the hope that it will be useful,
    # but WITHOUT ANY WARRANTY; without even the implied warranty of
    # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    # GNU General Public License for more details.
    #
    # You should have received a copy of the GNU General Public License
    # along with this program; see the file COPYING.  If not, write to
    # the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
    #
    #####
    #<>).type=string; \
     additional_data(-1).meaning=Cisco Signature Template:; \
     additional_data(-1).data=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$1&signatureSubId=$2; chained; silent;
    regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.13(?:\.0)? (\d+); \
     id=5004; \
     target(0).node.address(0).vlan_name=$1; chained; silent;
    regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.16(?:\.0)? "(?:0\.0\.0\.0 \[)?([\w:]+?|\d+?\.\d+?\.\d+?\.\d+?)(?:\])?(?::(\d+?))?"; \
     id=5005; \
     source(0).node.address(0).category=ipv4-addr; \
     source(0).node.address(0).address=$1; \
     source(0).service.port=$2; chained; silent;
    #ANOMALY DETECTION
    regex=011iso.3.6.1.4.1.9.9.383.1.2.16(?:\.0)? "[\d\.\:]+"\#011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.21(?:\.0)? ".\s+adExtraData: numDestIps=\d+\S currentThreshold=\d+\S protocol=\d+; \
     id=5006; \
     target(0).node.address(0).category=ipv4-addr; \
     target(0).node.address(0).address=0.0.0.0; \
     target(0).service.port=0; \
     target(0).service.portlist=0; \
     additional_data(0).type=string; \
     additional_data(0).meaning=osIdSource:; \
     additional_data(0).data=unknown; \
     additional_data(1).type=string; \
     additional_data(1).meaning=osRelevance:; \
     additional_data(1).data=unknown; \
     additional_data(2).type=string; \
     additional_data(2).meaning=osType:; \
     additional_data(2).data=unknown; chained; silent;
    regex=\[UDP: \[([^\]]+)\]:\d+->\[[^\]]+\]\]:.012iso\.3\.6\.1\.2\.1\.1\.3\.0 \d?\d?\d?:?\d\d:\d\d:\d\d\.\d\d.011iso\.3\.6\.1\.6\.3\.1\.1\.4\.1\.0 iso\.3\.6\.1\.4\.1\.9\.9\.383\.0\.1.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.1 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.2 "[\d\w\s]+".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.3 "[\d\w\s]+".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.4 "(\S+)".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.1 "(info|low|medium|high)(?:rmational)?".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.2 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.3 "([^"]+)"#011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.4 "([^"]+)".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.5 (\d+).011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.6 (\d+).011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.7 "[^"]+".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.12 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.13 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.16 "([^"]+)".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.21 "\.\s+adExtraData: numDestIps=(\d+). currentThreshold=(\d+). protocol=(\d+) . ".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.25 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.26 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.27 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.42 \d+; \
      id=5030; \
      revision=1; \
      classification.text=$5; \
      classification.reference(0).origin=vendor-specific; \
      classification.reference(0).name=$6.$7; \
      classification.reference(0).meaning=ips_id; \
      classification.reference(0).url=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$6&signatureSubId=$7; \
      assessment.impact.severity=$3; \
      assessment.impact.type=other; \
      assessment.impact.description=$4; \
      source(0).node.address(0).category=ipv4-addr; \
      source(0).node.address(0).address=$8; \
      target(0).node.address(0).category=ipv4-addr; \
      target(0).node.address(0).address=0.0.0.0; \
      analyzer(0).node.address(0).address=$1; \
      analyzer(0).node.name=$2; \
      analyzer(0).manufacturer=Cisco; \
      analyzer(0).class=IPS; \
      analyzer(0).name=Cisco IPS; \
    last;
    #>>ALERT>>
    #<>ERROR>>
    #<>MESSAGE TYPE>>
    #<
    \[(\d+.\d+.\d+.\d+)\]\]:; \ classification.text=snmp unknown message; \ classification.reference(0).origin=vendor-specific; \ id=5090; \ revision=1; \ assessment.impact.severity=high; \ assessment.impact.type=other; \ assessment.impact.description=This event was generated by snmptrapd; \ source(0).node.address(0).address=$1; \ analyzer(0).node.address(0).address=$2; \ last; #>>MAIN RULE>> #EOF


    Dieser Regelsatz enthält das folgende Prinzip:
    • Das eingehende Protokoll fällt zuerst unter die allgemeine Signatur des IPS-Ereignisses: Regel 5090;
    • optional überprüfter Nachrichtentyp - Fehler / Systemnachricht / Warnung: Regeln von 5080 bis 5089;
    • Wenn sich die empfangene Nachricht auf einen Fehler bezieht, bestimmen wir deren Typ: Regeln von 5040 bis 5079;
    • Wenn die empfangene Nachricht eine Signatur auslöst, ziehen wir alles heraus, was uns interessiert: Regeln von 5000 bis 5039;

    Das heißt Die Protokollverarbeitung nach der Regel erfolgt von oben nach unten. Aber ein Teil der Regeln mit verketteten Schlüsseln ; still Sie nehmen erst an dieser Verarbeitung teil, wenn ihnen explizit ein Link von einer untergeordneten Regel (mit dem Optgoto- Schlüssel ) gegeben wird.

    Für IOS-IPS können Sie auch Protokolle auf unseren Server umleiten und auf ähnliche Weise die folgenden Regeln anwenden:
    cisco-ios-ips.rules
    #
    # Copyright (C) 2013 lei_wulong
    #
    # This file is part of the Prelude-LML program.
    #
    # This program is free software; you can redistribute it and/or modify
    # it under the terms of the GNU General Public License as published by
    # the Free Software Foundation; either version 2, or (at your option)
    # any later version.
    #
    # This program is distributed in the hope that it will be useful,
    # but WITHOUT ANY WARRANTY; without even the implied warranty of
    # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    # GNU General Public License for more details.
    #
    # You should have received a copy of the GNU General Public License
    # along with this program; see the file COPYING.  If not, write to
    # the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
    #
    #####
    ##RULES FOR CISCO IOS-IPS###
    ## id pool = [580-599]
    regex=Subsig\:\d+\s+Sev\:25; \
     id=580; \
     assessment.impact.severity=info; \
     silent
    regex=Subsig\:\d+\s+Sev\:50; \
     id=581; \
     assessment.impact.severity=low; \
     silent
    regex=Subsig\:\d+\s+Sev\:75; \
     id=582; \
     assessment.impact.severity=medium; \
     silent
    regex=Subsig\:\d+\s+Sev\:100; \
     id=583; \
     assessment.impact.severity=high; \
     silent
    ### For IOS 12.4(11)###
    regex=(\d+\.\d+\.\d+\.\d+)\s+\d+\:\s+(.+?)\:.+?\%IPS-4-SIGNATURE\: Sig\:(\d+)\s+Subsig\:(\d+)\s+Sev\:(\d+)\s+\[([\d\.]+)\:(\d+)\s+\-\>\s+([\d\.]+)\:(\d+)\]\s+RiskRating\:(\d+); \
     classification.text=$3.$4; \
     classification.reference(0).origin=vendor-specific; \
     classification.reference(0).meaning=cisco_id; \
     classification.reference(0).name=$3.$4; \
     classification.reference(0).url=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$3&signatureSubId=$4; \
     id=584; \
     revision=2; \
     analyzer(0).name=Cisco IPS; \
     analyzer(0).manufacturer=Cisco; \
     analyzer(0).class=IPS; \
     analyzer(0).node.address(0).address=$1; \
     analyzer(0).node.name=$2; \
     assessment.impact.type=other; \
     source(0).node.address(0).category=ipv4-addr; \
     source(0).node.address(0).address=$6; \
     target(0).node.address(0).category=ipv4-addr; \
     target(0).node.address(0).address=$8; \
     source(0).service.port=$7; \
     target(0).service.port=$9; \
     additional_data(0).type=integer; \
     additional_data(0).meaning=Signature Severity; \
     additional_data(0).data=$5; \
     additional_data(1).type=integer; \
     additional_data(1).meaning=Risk Rating; \
     additional_data(1).data=$10; \
    ###FOR IOS 15.1 ###
    regex=(\d+\.\d+\.\d+\.\d+)\s+\d+\:\s+(.+?)\:.+?\%IPS-4-SIGNATURE\: Sig\:(\d+)\s+Subsig\:(\d+)\s+Sev\:(\d+)\s+(.+?)\s+\[([\d\.]+)\:(\d+)\s+\-\>\s+([\d\.]+)\:(\d+)\]\s+VRF\:(.+?)\s+RiskRating\:(\d+); \
     classification.text=$6; \
     classification.reference(0).origin=vendor-specific; \
     classification.reference(0).meaning=cisco_id; \
     classification.reference(0).name=$3.$4; \
     classification.reference(0).url=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$3&signatureSubId=$4; \
     id=585; \
     revision=2; \
     analyzer(0).name=Cisco IPS; \
     analyzer(0).manufacturer=Cisco; \
     analyzer(0).class=IPS; \
     analyzer(0).node.address(0).address=$1; \
     analyzer(0).node.name=$2; \
     assessment.impact.type=other; \
     source(0).node.address(0).category=ipv4-addr; \
     source(0).node.address(0).address=$7; \
     target(0).node.address(0).category=ipv4-addr; \
     target(0).node.address(0).address=$9; \
     source(0).service.port=$8; \
     target(0).service.port=$10; \
     additional_data(0).type=integer; \
     additional_data(0).meaning=Signature Severity; \
     additional_data(0).data=$5; \
     additional_data(1).type=integer; \
     additional_data(1).meaning=Risk Rating; \
     additional_data(1).data=$12; \
     additional_data(2).type=string; \
     additional_data(2).meaning=VRF; \
     additional_data(2).data=$11; \
    last;
    


    Nach all den oben genannten Manipulationen erhalten wir das folgende Ergebnis:



    In der Konsole werden Trigger von allen IPS-Sensoren angezeigt. Der Screenshot oben zeigt die Gruppierung nach Quell- und Zieladresse. Hier gibt es Ereignisse von IPS-Modulen und -Anwendungen sowie von Routern mit aktiviertem IOS-IPS (dies ist im Screenshot aufgrund von „Verschleierungstechnologien“ nicht sichtbar). Wir können nach allen Werten gruppieren / filtern, die während der Verarbeitung durch unser Regelwerk ermittelt wurden.
    Dementsprechend können Sie auf jeden Fall "scheitern" und die Details anzeigen:



    6. Korrelation Herzblutung


    Der letzte Schliff im Setup ist der Teil, der die Ereignisanzeige von SIEM unterscheidet: Korrelation.
    Nehmen wir als Beispiel für das Einrichten der Korrelationsregel eine kürzlich aufgetretene Sicherheitsanfälligkeit in der OpenSSL- Bibliothek - HeartBleed .

    Cisco hat eine Signatur, mit der versucht werden kann, diese Sicherheitsanfälligkeit auszunutzen: tools.cisco.com/security/center/viewIpsSignature.x?signatureId=4187&signatureSubId=0
    Die Signatur lautet 4187.0 und wird als "OpenSSL Information Disclosure" bezeichnet.
    Das Auslösen dieser Signatur bedeutet noch nicht, dass die Sicherheitsanfälligkeit ausgenutzt wurde, da IPS weiß nicht, ob der angegriffene Host anfällig ist oder nicht. Aber SIEM könnte diese Frage beantworten.
    Das allgemeine Prinzip der Korrelationsregel lautet wie folgt: Wenn das oben genannte Ereignis von IPS in SIEM eintrifft, prüft SIEM selbst, ob der Zielhost die HeartBleed-Sicherheitsanfälligkeit aufweist. Wenn der Host anfällig ist, wird ein separates Korrelationsereignis generiert.
    Die Regel selbst lautet wie folgt:

    #
    # Copyright (C) 2014 Vladimir Lapshin 
    # Copyright (C) 2014 lei_wulong
    #
    # This program is free software; you can redistribute it and/or modify
    # it under the terms of the GNU General Public License as published by
    # the Free Software Foundation; either version 2, or (at your option)
    # any later version.
    #
    # This program is distributed in the hope that it will be useful,
    # but WITHOUT ANY WARRANTY; without even the implied warranty of
    # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    # GNU General Public License for more details.
    #
    # You should have received a copy of the GNU General Public License
    # along with this program; see the file COPYING.  If not, write to
    # the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
    #
    import re
    from PreludeCorrelator.pluginmanager import Plugin
    from PreludeCorrelator.context import Context
    import time
    import subprocess
    localtime = time.localtime()
    timestamp = time.strftime('%d %b %H:%M:%S', localtime)
    print str(timestamp) + ' HeartBleed plugin  (correlator) INFO: Starting...'
    class heartbleed(Plugin):
        def run(self, idmef):
            if not idmef.match('alert.classification.text', re.compile('^OpenSSL Information Disclosure$|^Other security event$')):
                return
            addr = idmef.Get('alert.target(*).node.address(*).address')
            if not addr:
                return
            port = idmef.Get('alert.target(0).service.port')
            if not port:
                port='443'
            script = str('python2.6 /etc/prelude-correlator/heartbleed.py ') + str(addr).strip('[\'\']') + str(' -p ') + str(port)
            print script
            PIPE = subprocess.PIPE
            p = subprocess.Popen(script, shell=True, stdin=PIPE, stdout=PIPE, stderr=subprocess.STDOUT, close_fds=True)
            while True:
                s = p.stdout.readline()
                if not s:
                    break
                if re.findall('server is vulnerable', s):
                    ctx = Context(("HEART_BLEED", addr), update=True, idmef=idmef)
                    ctx.Set("alert.classification.text", "HeartBleed vulnerability detected")
                    ctx.Set("alert.correlation_alert.name", "HeartBleed vulnerability detected")
                    ctx.Set("alert.assessment.impact.severity", "high")
                    ctx.Set("alert.classification.reference(0).origin", "vendor-specific")
                    ctx.Set("alert.classification.reference(0).name", "CVE-2014-0160")
                    ctx.alert()
                    ctx.destroy()
                    print 'Vulnerable!'
                    return
    

    In diesem Beispiel wird zur Überprüfung der Sicherheitsanfälligkeit das folgende Skript verwendet: gist.github.com/sh1n0b1/10100394 . Es sollte sich im selben Verzeichnis wie das Korrelations-Plugin befinden. Für das obige Beispiel lautet dieser Pfad /etc/prelude-correlator/heartbleed.py.Vergessen Sie

    auch nicht, auf den IPS-Sensoren eine Ausnahme für 4187.x-Signaturen und die Quelladresse zu machen, unter der Prelude installiert ist. Dies wird auch von IPS erkannt (wir verwenden im Wesentlichen dasselbe Heartbleed) -> neue IPS-Warnung -> Korrelationen -> usw. Dies kann über den Ereignisaktionsfilter erfolgen.
    Oder Sie können die Rekursion in der Regel selbst ausschließen, indem Sie Folgendes hinzufügen:
    if idmef.match("alert.source(0).node.address(0).address", re.compile("0\.0\.0\.0")) # <- Prelude-Correlator addr
        return
    

    Wenn Sie den Ereignisaktionsfilter jedoch nicht konfigurieren, reagiert unser IPS auf die von Prelude selbst durchgeführte Überprüfung. Wenn sein Sensor ihn blockiert, können wir nicht nach einer Schwachstelle suchen.

    Nach dem Festlegen der Regel erhalten wir beim Auslösen der Cisco 4187.0-Signatur das folgende Ergebnis:



    Tatsächlich bedeutet dies, dass ein für diesen Angriff anfälliger Host angegriffen wurde. Die Korrelationsregel im Beispiel wartet auf Ereignisse mit dem Namen '^ OpenSSL Information Disclosure $ | ^ Anderes Sicherheitsereignis $'. Natürlich können Sie nicht auf ein Ereignis von Cisco IPS beschränkt sein. Nach dem gleichen Prinzip kann die IPS-Korrelation aller anderen mit dem System verbundenen Anbieter durchgeführt werden.
    Sie können sich auch an das Anmeldeereignis auf dem Webserver binden. Wenn es anfällig ist, ist das zum Anmelden verwendete Konto möglicherweise gefährdet.
    Die in diesem Artikel beschriebene Regel ist nur ein Beispiel für einen speziellen Anwendungsfall für die neuesten aktuellen Ereignisse. Alle anderen Wunschzettel sind nur durch Fantasie und Python begrenzt (lesen - nicht durch irgendetwas eingeschränkt). Zum Beispiel können Sie im vorgeschlagenen Skript verschiedene Szenarien übertreffen: Überprüfen Sie nur anhand Ihrer Ressourcen (nur graue Adressen / Pool externer Adressen), ändern Sie die IP-Adresse und den Port des "Opfers", wenn sich unsere Ressource hinter NAT befindet, usw.

    7. Nachwort


    Abschließend sei noch auf die Möglichkeit hingewiesen, Ereignisse über SDEE zu sammeln.
    Weil In diesem Artikel wurde die Konfiguration für die OSS-Version von Prelude berücksichtigt. Anschließend mussten IPS und Prelude über SNMP (für IPS-Module / -Anwendungen) und Syslog (für IOS-IPS) befreundet sein. Aber, wie im vierten Abschnitt erwähnt , können alle diese Geräte über SDEE betrieben werden. Gleichzeitig wird es möglich, Ereignisse von IPS in einer einheitlichen Form mit den vollständigsten Informationen zu jeder Warnung zu empfangen. Dazu benötigen Sie einen SDEE-Connector, der nur in der kommerziellen Version von Prelude vorhanden ist.

    Weitere Unterschiede zwischen der kommerziellen Version von PreludePro:
    • leistung
    • die Fähigkeit, Sklavenmanager anzuschließen;
    • hinzufügen. Funktionen in Prewikka (Authentifizierung über LDAP, die Möglichkeit, eigene Befehle in das Webinterface einzubetten, etc.);
    • дополнительные модули (log-management, система инвентаризации, и т.д.)

    Wieder stellte sich heraus, dass es voluminös war, und versuchte, so gut er konnte "zu drücken".
    Hoffe es war interessant und hilfreich.
    Viel Glück bei der Identifizierung von Vorfällen!
    _____
    Im Artikel verwendete Materialien:
    CSM-Benutzerhandbuch www.cisco.com/c/en/us/td/docs/security/security_management/cisco_security_manager/security_manager/4-6/user/guide/CSMUserGuide.html
    IME-Benachrichtigungsbeispiel: www .cisco.com / c / de / us / support / docs / security / ips-4200-series-sensors / 111659-ips-email-ime-config.html
    IOS IPS-Ereignisse über IME: www.cisco.com/c/ de / de / support / docs / security / intrusion-prevent-system / 113576-ptn-113576.html Offizielle
    Prelude OSS-Seite www.prelude-ids.org
    Übersicht über die Prewikka-Oberfläche: is-systems.org/siem/interface

    Jetzt auch beliebt: