Fehlerbehebung Abfluss von nicht verarbeiteten FMC-Warnmeldungen
Inhalt
Einleitung
In diesem Dokument wird die Fehlerbehebung bei nicht verarbeiteten Ereignissen und bei häufigen Ereignisstatuswarnungen in FirePOWER Management Center beschrieben.
Problemübersicht
Das FirePOWER Management Center (FMC) generiert einen der folgenden Integritätsalarme:
- Häufige Abwanderung von Unified Low Priority-Ereignissen
- Ableitung nicht verarbeiteter Ereignisse aus Unified-Ereignissen mit niedriger Priorität
Obwohl diese Ereignisse generiert und auf dem FMC angezeigt werden, beziehen sie sich auf einen verwalteten Gerätesensor, egal ob es sich um ein FTD-Gerät (Firepower Threat Defense) oder ein NGIPS-Gerät (Intrusion Prevention System der nächsten Generation) handelt. Im Übrigen bezieht sich der Begriff Sensor auf FTD- und NGIPS-Geräte, sofern nichts anderes angegeben ist.
Dies ist die Struktur der Integritätswarnungen:
- Häufiger Abfluss von <SILO NAME>
- Nicht verarbeitete Ereignisse werden aus <SILO NAME> abgeleitet.
In diesem Beispiel ist SILO NAME ein Unified-Ereignis mit niedriger Priorität. Dies ist eines der isolierten Bereiche des Datenträgermanagers (weitere Informationen finden Sie im Abschnitt Hintergrundinformationen).
Zusätzlich:
- Obwohl jedes Silo technisch gesehen eine häufige Abnahme von <SILO NAME> Statuswarnungen erzeugen kann, sind die am häufigsten beobachteten Ereignisse Ereignisse, die mit Ereignissen in Zusammenhang stehen, darunter die Ereignisse mit niedriger Priorität, einfach weil diese die Art von Ereignissen sind, die häufiger von den Sensoren generiert werden.
- Ein häufiges Ereignis mit Ablauf von <SILO NAME> hat einen Warnschweregrad, wenn es sich um ein ereignisbezogenes Silo handelt. Wenn diese verarbeitet wurden (als Nächstes wird erklärt, was ein nicht verarbeitetes Ereignis darstellt), befinden sie sich in der FMC-Datenbank.
- Bei Silo-Elementen, die keine Ereignisse betreffen, wie z. B. Backup-Silo, ist die Warnung kritisch, da diese Informationen verloren gehen.
- Nur silos von Ereignistypen generieren eine Ableitung nicht verarbeiteter Ereignisse aus der <SILO NAME> Integritätswarnung. Dieser Alarm hat immer einen kritischen Schweregrad.
Weitere Symptome können sein:
- Veranstaltungsausfall
- Langsamkeit auf der Benutzeroberfläche des FÜZ
Häufige Fehlerbehebungsszenarien
Häufige Verluste von <SILO NAME> werden durch zu viele Eingaben in das Silo verursacht, um dessen Größe zu erreichen. In diesem Fall leert (löscht) der Datenträgermanager diese Datei mindestens zweimal im letzten 5-Minuten-Intervall. In einem Ereignistypsilo wird dies normalerweise durch übermäßige Protokollierung dieses Ereignistyps verursacht. Wenn bei einem Drain nicht verarbeitete Ereignisse der <SILO NAME>-Integritätswarnung vorliegen, kann dies auch durch einen Engpass im Ereignisverarbeitungspfad verursacht werden.
Das Diagramm weist drei potenzielle Engpässe auf:
- Der EventHandler-Prozess auf FTD ist überbelegt (er liest langsamer als das, was Snort schreibt).
- Die Ereignisschnittstelle ist überbelegt.
- Der SFDataCorrelator-Prozess auf FMC ist überbelegt.
Weitere Informationen zur Ereignisverarbeitungsarchitektur finden Sie im Abschnitt Deep Dive.
Fall 1: Übermäßige Protokollierung
Wie im vorherigen Abschnitt erwähnt, besteht eine der häufigsten Ursachen für Gesundheitswarnungen dieses Typs in übermäßiger Eingabe.
Der Unterschied zwischen der Niedrigwassermarke (LWM) und der Hochwassermarke (HWM) (gesammelt aus dem Kommando show disk-manager CLISH) zeigt, wie viel Platz benötigt wird, um dieses Silo aufzunehmen. Um von LWM (frisch entwässert) zum HWM-Wert zu wechseln, müssen Sie bei häufigen Ereignisabläufen (mit oder ohne nicht verarbeitete Ereignisse) zuerst die Protokollierungskonfiguration überprüfen.
Eine ausführliche Erklärung des Disk Manager-Prozesses finden Sie im Abschnitt Deep Dive.
Unabhängig davon, ob es sich um eine doppelte Protokollierung oder nur um eine hohe Ereignisrate im gesamten Ökosystem der Manager-Sensoren handelt, müssen die Protokollierungseinstellungen überprüft werden.
Empfohlene Maßnahmen
Schritt 1: Überprüfen auf Doppelprotokollierung
Szenarien mit doppelter Protokollierung können identifiziert werden, wenn Sie die Perfomstats des Korrelators auf dem FMC überprüfen, wie in der folgenden Ausgabe dargestellt:
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
129 statistics lines read
host limit: 50000 0 50000
pcnt host limit in use: 0.01 0.01 0.01
rna events/second: 0.00 0.00 0.06
user cpu time: 0.48 0.21 10.09
system cpu time: 0.47 0.00 8.83
memory usage: 2547304 0 2547304
resident memory usage: 28201 0 49736
rna flows/second: 126.41 0.00 3844.16
rna dup flows/second: 69.71 0.00 2181.81
ids alerts/second: 0.00 0.00 0.00
ids packets/second: 0.00 0.00 0.00
ids comm records/second: 0.02 0.01 0.03
ids extras/second: 0.00 0.00 0.00
fw_stats/second: 0.00 0.00 0.03
user logins/second: 0.00 0.00 0.00
file events/second: 0.00 0.00 0.00
malware events/second: 0.00 0.00 0.00
fireamp events/second: 0.00 0.00 0.00
In diesem Beispiel ist eine hohe Rate duplizierter Flows in der Ausgabe zu sehen.
Schritt 2: Überprüfen der Protokolleinstellungen des ACP
Sie müssen mit einer Überprüfung der Protokolleinstellungen der Zugriffskontrollrichtlinie (Access Control Policy, ACP) beginnen. Stellen Sie sicher, dass Sie die unter Best Practices für die Verbindungsprotokollierung beschriebenen Best Practices verwenden.
Eine Überprüfung der Protokollierungseinstellungen ist in allen Situationen ratsam, da die aufgeführten Empfehlungen nicht nur Doppelprotokollierungsszenarien abdecken.
Um die Rate der generierten Ereignisse in FTD zu überprüfen, überprüfen Sie diese Datei, und konzentrieren Sie sich auf die Spalten TotalEvents und PerSec:
admin@firepower:/ngfw/var/log$ sudo more EventHandlerStats.2023-08-13 | grep Total | more
{"Time": "2023-08-13T00:03:37Z", "TotalEvents": 298, "PerSec": 0, "UserCPUSec": 0.995, "SysCPUSec": 4.598, "%CPU": 1.9, "MemoryKB": 33676}
{"Time": "2023-08-13T00:08:37Z", "TotalEvents": 298, "PerSec": 0, "UserCPUSec": 1.156, "SysCPUSec": 4.280, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:13:37Z", "TotalEvents": 320, "PerSec": 1, "UserCPUSec": 1.238, "SysCPUSec": 4.221, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:18:37Z", "TotalEvents": 312, "PerSec": 1, "UserCPUSec": 1.008, "SysCPUSec": 4.427, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:23:37Z", "TotalEvents": 320, "PerSec": 1, "UserCPUSec": 0.977, "SysCPUSec": 4.465, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:28:37Z", "TotalEvents": 299, "PerSec": 0, "UserCPUSec": 1.066, "SysCPUSec": 4.361, "%CPU": 1.8, "MemoryKB": 33676}
Schritt 3: Übermäßige Protokollierung wird erwartet.
Sie müssen überprüfen, ob eine übermäßige Protokollierung eine erwartete Ursache hat. Wenn übermäßige Protokollierung durch DOS/DDoS-Angriffe, einen Routing-Loop oder eine bestimmte Anwendung/einen bestimmten Host mit einer großen Anzahl von Verbindungen verursacht wird; Sie müssen Verbindungen von unerwarteten/exzessiven Verbindungsquellen prüfen und abschwächen/stoppen.
Schritt 4: Überprüfen Sie, ob die Datei diskmanager.log beschädigt ist
Normalerweise kann ein Eintrag 12 durch Kommas getrennte Werte enthalten. So prüfen Sie auf beschädigte Zeilen mit einer anderen Anzahl von Feldern:
admin@firepower:/ngfw/var/log$ sudo cat diskmanager.log | awk -F',' 'NF != 12 {print}'
admin@firepower:/ngfw/var/log$
Wenn es eine beschädigte Linie mit anderen als 12 Felder angezeigt werden.
Schritt 5: Upgrade-Modell
Das FTD-Hardwaregerät auf ein Modell mit höherer Leistung (z. B. FPR2100 —> FPR4100) aufrüsten, da sich das Quellsilo erhöhen würde.
Schritt 6. Überlegen Sie, ob Sie Log to Ramdisk deaktivieren können
Bei einem Unified Low Priority-Ereignis-Silo können Sie die Option Log to Ramdisk deaktivieren, um die Silo-Größe zu erhöhen. Sie können die Nachteile im Abschnitt Deep Dive (Tieftauchen) überprüfen.
Fall 2: Engpass im Kommunikationskanal zwischen Sensor und FMC
Eine weitere häufige Ursache für diese Art von Warnmeldungen sind Verbindungsprobleme und/oder Instabilitäten im Kommunikationskanal (Sftunnel) zwischen dem Sensor und dem FMC. Das Kommunikationsproblem kann folgende Ursachen haben:
- sftunnel ist überbelegt.
- sftunnel ist ausgefallen oder instabil (flaps).
Stellen Sie bei einem Problem mit der Sftunnel-Verbindung sicher, dass das FMC und der Sensor über die Erreichbarkeit zwischen ihren Verwaltungsschnittstellen auf dem TCP-Port 8305 verfügen.
Auf FTD können Sie in der Datei [/ngfw]/var/log/messages nach dem sftunneld String suchen. Verbindungsprobleme führen dazu, dass Meldungen wie diese generiert werden:
Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_ch_util [INFO] Delay for heartbeat reply on channel from 10.62.148.75 for 609 seconds. dropChannel... Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_connections [INFO] Ping Event Channel for 10.62.148.75 failed Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState dropChannel peer 10.62.148.75 / channelB / EVENT [ msgSock2 & ssl_context2 ] << Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState freeChannel peer 10.62.148.75 / channelB / DROPPED [ msgSock2 & ssl_context2 ] << Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_connections [INFO] Need to send SW version and Published Services to 10.62.148.75 Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_peers [INFO] Confirm RPC service in CONTROL channel Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState do_dataio_for_heartbeat peer 10.62.148.75 / channelA / CONTROL [ msgSock & ssl_context ] << Sep 9 15:41:48 firepower SF-IMS[5458]: [5464] sftunneld:tunnsockets [INFO] Started listening on port 8305 IPv4(10.62.148.180) management0 Sep 9 15:41:51 firepower SF-IMS[5458]: [27602] sftunneld:control_services [INFO] Successfully Send Interfaces info to peer 10.62.148.75 over managemen Sep 9 15:41:53 firepower SF-IMS[5458]: [5465] sftunneld:sf_connections [INFO] Start connection to : 10.62.148.75 (wait 10 seconds is up) Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_peers [INFO] Peer 10.62.148.75 needs the second connection Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Interface management0 is configured for events on this Device Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Connect to 10.62.148.75 on port 8305 - management0 Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Initiate IPv4 connection to 10.62.148.75 (via management0) Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Initiating IPv4 connection to 10.62.148.75:8305/tcp Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Wait to connect to 8305 (IPv6): 10.62.148.75
Eine Überbelegung der Verwaltungsschnittstelle des FMC kann eine Spitze des Verwaltungsdatenverkehrs oder eine konstante Überbelegung sein. Verlaufsdaten des Gesundheitsmonitors sind ein guter Indikator dafür.
Zunächst einmal ist festzustellen, dass das FMC in den meisten Fällen mit einer einzigen Netzwerkkarte für die Verwaltung bereitgestellt wird. Diese Schnittstelle wird verwendet für:
- FMC-Management
- Management von FMC-Sensoren
- Erfassung von FMC-Ereignissen von den Sensoren
- Aktualisierung von Intelligence Feeds
- Herunterladen von SRU-, Software-, VDB- und GeoDB-Updates von der Software-Download-Site
- Die Abfrage für URL-Reputationen und -Kategorien (falls zutreffend)
- Die Abfrage für Dateipositionen (falls zutreffend)
Empfohlene Maßnahmen
Sie können eine zweite Netzwerkkarte im FMC für eine dedizierte Ereignisschnittstelle bereitstellen. Die Implementierungen hängen vom Anwendungsfall ab. Allgemeine Richtlinien finden Sie im FMC Hardware Guide - Deploying on a Management Network.
Fall 3: Ein Engpass im SFDataCorrelator-Prozess
Das letzte Szenario betrifft einen Engpass auf der Seite des SFDataCorrelator (FMC).
Der erste Schritt besteht darin, sich die Datei diskmanager.log anzusehen, da es wichtige Informationen zu sammeln gibt, wie zum Beispiel:
- Die Frequenz des Drains.
- Die Anzahl der Dateien mit abgelaufenen nicht verarbeiteten Ereignissen.
-
Das Auftreten des Drains mit nicht verarbeiteten Ereignissen.
Informationen zur Datei diskmanager.log und deren Interpretation finden Sie im Abschnitt Datenträgerverwaltung. Die Informationen aus der Datei diskmanager.log können dazu verwendet werden, die nachfolgenden Schritte einzugrenzen.
Außerdem müssen Sie die entsprechenden Leistungsstatistiken überprüfen:
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
129 statistics lines read
host limit: 50000 0 50000 pcnt host limit in use: 100.01 100.00 100.55 rna events/second: 1.78 0.00 48.65 user cpu time: 2.14 0.11 58.20 system cpu time: 1.74 0.00 41.13 memory usage: 5010148 0 5138904 resident memory usage: 757165 0 900792 rna flows/second: 101.90 0.00 3388.23 rna dup flows/second: 0.00 0.00 0.00 ids alerts/second: 0.00 0.00 0.00 ids packets/second: 0.00 0.00 0.00 ids comm records/second: 0.02 0.01 0.03 ids extras/second: 0.00 0.00 0.00 fw_stats/second: 0.01 0.00 0.08 user logins/second: 0.00 0.00 0.00 file events/second: 0.00 0.00 0.00 malware events/second: 0.00 0.00 0.00 fireamp events/second: 0.00 0.00 0.01
Diese Statistiken beziehen sich auf das FÜZ und entsprechen der Gesamtzahl aller von ihm verwalteten Sensoren. Im Fall von Unified-Ereignissen mit niedriger Priorität sind Sie hauptsächlich auf der Suche nach:
- Gesamtanzahl an Flows pro Sekunde für jeden Ereignistyp, um eine mögliche Überbelegung des SFDataCorrelator-Prozesses zu bewerten.
- Die beiden in der vorherigen Ausgabe hervorgehobenen Zeilen:
- rna flows/second - Gibt die Rate von Ereignissen mit niedriger Priorität an, die vom SFDataCorrelator verarbeitet werden.
- rna dup flows/second - Gibt die Rate der duplizierten Ereignisse mit niedriger Priorität an, die vom SFDataCorrelator verarbeitet werden. Dies wird durch die doppelte Protokollierung generiert, wie im vorherigen Szenario beschrieben.
Auf der Grundlage der Ergebnisse kann der Schluss gezogen werden, dass
- Es gibt keine doppelte Protokollierung, wie durch die RNA-Duplikat-Flüsse/zweite Zeile angegeben.
- In der Zeile rna flows/second ist der Maximum-Wert viel höher als der Durchschnittswert, da die Rate der Ereignisse, die vom SFDataCorrelator-Prozess verarbeitet wurden, einen Spitzenwert aufwies. Dies ist zu erwarten, wenn Sie sich frühmorgens erneut ansehen, wenn der Arbeitstag Ihrer Benutzer gerade erst begonnen hat. Im Allgemeinen ist dies ein rotes Fähnchen und erfordert weitere Untersuchungen.
Weitere Informationen zum SFDataCorrelator-Prozess finden Sie im Abschnitt Ereignisverarbeitung.
Empfohlene Maßnahmen
Zuerst müssen Sie feststellen, wann die Spitze aufgetreten ist. Dazu müssen Sie die Korrelatorstatistiken für jedes 5-minütige Abtastintervall überprüfen. Die Informationen aus der Datei diskmanager.log helfen Ihnen dabei, die kritischen Zeitrahmen zu überprüfen.
admin@FMC:~$ sudo perfstats -C < /var/sf/rna/correlator-stats/now
<OUTPUT OMITTED FOR READABILITY>
Wed Sep 9 16:01:35 2020 host limit: 50000 pcnt host limit in use: 100.14 rna events/second: 24.33 user cpu time: 7.34 system cpu time: 5.66 memory usage: 5007832 resident memory usage: 797168 rna flows/second: 638.55 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.02 ids extras/second: 0.00 fw stats/second: 0.00 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:06:39 2020 host limit: 50000 pcnt host limit in use: 100.03 rna events/second: 28.69 user cpu time: 16.04 system cpu time: 11.52 memory usage: 5007832 resident memory usage: 801476 rna flows/second: 685.65 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.01 ids extras/second: 0.00 fw stats/second: 0.00 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:11:42 2020 host limit: 50000 pcnt host limit in use: 100.01 rna events/second: 47.51 user cpu time: 16.33 system cpu time: 12.64 memory usage: 5007832 resident memory usage: 809528 rna flows/second: 1488.17 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.02 ids extras/second: 0.00 fw stats/second: 0.01 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:16:42 2020 host limit: 50000 pcnt host limit in use: 100.00 rna events/second: 8.57 user cpu time: 58.20 system cpu time: 41.13 memory usage: 5007832 resident memory usage: 837732 rna flows/second: 3388.23 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.01 ids extras/second: 0.00 fw stats/second: 0.03 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 197 statistics lines read host limit: 50000 0 50000 pcnt host limit in use: 100.01 100.00 100.55 rna events/second: 1.78 0.00 48.65 user cpu time: 2.14 0.11 58.20 system cpu time: 1.74 0.00 41.13 memory usage: 5010148 0 5138904 resident memory usage: 757165 0 900792 rna flows/second: 101.90 0.00 3388.23 rna dup flows/second: 0.00 0.00 0.00 ids alerts/second: 0.00 0.00 0.00 ids packets/second: 0.00 0.00 0.00 ids comm records/second: 0.02 0.01 0.03 ids extras/second: 0.00 0.00 0.00 fw_stats/second: 0.01 0.00 0.08 user logins/second: 0.00 0.00 0.00 file events/second: 0.00 0.00 0.00 malware events/second: 0.00 0.00 0.00 fireamp events/second: 0.00 0.00 0.01
Verwenden Sie die Informationen in der Ausgabe, um:
- Ermitteln Sie die normale/Baseline-Rate von Ereignissen.
- Ermitteln Sie das 5-Minuten-Intervall, in dem die Spitze auftrat.
Im vorherigen Beispiel gibt es eine offensichtliche Spitze in der Rate der Ereignisse empfangen um 16:06:39 und darüber hinaus. Dies sind 5-Minuten-Mittelwerte, sodass der Anstieg abrupter sein kann als dargestellt (Burst), jedoch in diesem 5-Minuten-Intervall verdünnt, wenn es gegen Ende davon begonnen.
Dies führt zu dem Schluss, dass diese Spitze von Ereignissen den Abfluss von nicht verarbeiteten Ereignissen verursacht hat. Sie können die Verbindung von Ereignissen aus der grafischen Benutzeroberfläche (GUI) des FMC mit dem entsprechenden Zeitfenster sehen, um die Art von Verbindungen zu verstehen, die die FTD-Box in dieser Spitze passiert haben:
Wenden Sie dieses Zeitfenster an, um die gefilterten Verbindungsereignisse anzuzeigen (vergessen Sie nicht, die Zeitzone zu berücksichtigen). In diesem Beispiel verwendet der Sensor UTC und FMC UTC+1. Verwenden Sie die Tabellenansicht, um die Ereignisse anzuzeigen, die die Überlastung der Ereignisse ausgelöst haben, und entsprechende Maßnahmen zu ergreifen:
Basierend auf den Zeitstempeln (Zeit des ersten und letzten Pakets) kann man sehen, dass es sich um kurzlebige Verbindungen handelt. In den Spalten Initiator (Initiator) und Responder Packet (Antwortpaket) wird angezeigt, dass nur ein Paket in jede Richtung ausgetauscht wurde. Dies bestätigt, dass die Verbindungen kurzlebig waren und nur sehr wenig Daten ausgetauscht wurden.
Sie können sehen, dass alle Flows auf dieselben Responder-IPs und denselben Port abzielen. Außerdem werden sie alle vom gleichen Sensor gemeldet (der neben den Eingangs- und Ausgangsschnittstellen auch Informationen über Ort und Richtung der Ströme liefern kann). Zusätzliche Maßnahmen:
- Überprüfen Sie die Syslogs auf dem Zielendpunkt.
- DOS-/DDoS-Schutz implementieren oder andere vorbeugende Maßnahmen ergreifen.
Anmerkung: In diesem Artikel sollen Richtlinien zur Fehlerbehebung bei Warnungen zum Ablauf nicht verarbeiteter Ereignisse angegeben werden. In diesem Beispiel wurde hping3 verwendet, um eine TCP-SYN-Flood zum Zielserver zu generieren. Richtlinien zum Härten Ihres FTD-Geräts finden Sie im Cisco Firepower Threat Defense Hardening Guide.
Vor der Kontaktaufnahme mit dem Cisco Technical Assistance Center (TAC) zu sammelnde Artikel
Es wird dringend empfohlen, die folgenden Artikel zu sammeln, bevor Sie sich an das Cisco TAC wenden:
- Screenshot(s) der erkannten Integritätswarnungen.
- Fehlerbehebung in der vom FMC generierten Datei
- Fehlerbehebung in der Datei, die vom betroffenen Sensor generiert wurde
- Datum und Uhrzeit, an der das Problem erstmals aufgetreten ist.
- Informationen zu allen kürzlich vorgenommenen Änderungen der Richtlinien (falls zutreffend).
- Die Ausgabe des Befehls stats_unified.pl, wie im Abschnitt Ereignisverarbeitung beschrieben (mit einem Hinweis auf die betroffenen Sensoren).
Details
In diesem Abschnitt werden die verschiedenen Komponenten ausführlich erläutert, die an den Typen von Systemwarnungen beteiligt sein können. Dazu gehören:
- Ereignisverarbeitung: Deckt die Pfadereignisse ab, die sowohl auf den Sensorgeräten als auch auf dem FMC auftreten. Dies ist vor allem dann nützlich, wenn sich die Integritätswarnung auf einen Ereignistyp "Silo" bezieht.
- Datenträgerverwaltung: Behandelt den Prozess der Datenträgerverwaltung, Silos und deren Entleerung.
- Integritätsmonitor: Beschreibt, wie die Health Monitor-Module zum Generieren von Health Alerts verwendet werden.
- Bei Ramdisk anmelden: Behandelt die Funktion zur Protokollierung auf RAM-Disk und ihre möglichen Auswirkungen auf Statuswarnungen.
Um die Warnmeldungen zum Zustand "Ablauf von Ereignissen" zu verstehen und potenzielle Fehlerpunkte zu identifizieren, müssen Sie untersuchen, wie diese Komponenten funktionieren und miteinander interagieren.
Ereignisverarbeitung
Während die Warnmeldungen zur Art des häufigen Ablaufs durch isolierte Bereiche ausgelöst werden können, die nicht ereignisbezogen sind, bezieht sich die überwiegende Mehrheit der vom Cisco TAC erkannten Fälle auf ereignisbezogene Informationen zum Ablauf. Um zu verstehen, was eine Abwanderung nicht verarbeiteter Ereignisse darstellt, müssen Sie sich außerdem die Architektur für die Ereignisverarbeitung und ihre Komponenten ansehen.
Wenn ein FirePOWER-Sensor ein Paket von einer neuen Verbindung empfängt, generiert der Snort-Prozess ein Ereignis im Unified2-Format. Dabei handelt es sich um ein Binärformat, das schnelleres Lesen/Schreiben sowie leichtere Ereignisse ermöglicht.
Die Ausgabe zeigt den FTD-Befehl system support trace, wo Sie sehen können, dass eine neue Verbindung erstellt wurde. Wichtige Teile werden hervorgehoben und erläutert:
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Packet: TCP, SYN, seq 3310981951
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Session: new snort session
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0)
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 new firewall session
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 using HW or preset rule order 4, 'Default Inspection', action Allow and prefilter rule 0
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 HitCount data sent for rule id: 268437505,
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 allow action
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Firewall: allow rule, 'Default Inspection', allow
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Snort id 0, NAP id 1, IPS id 0, Verdict PASS
Snort Unified_events-Dateien werden pro Instanz unter dem Pfad [/ngfw]var/sf/detection_engine/*/instance-N/ generiert, wobei:
- * ist die Snort UUID. Dies ist für jede Appliance einzigartig.
- N ist die Snort-Instanz-ID, die als Instanz-ID aus der vorherigen Ausgabe berechnet werden kann (im Beispiel die hervorgehobene 0) + 1
Es gibt zwei Arten von Unified_events-Dateien in einem beliebigen Snort-Instanzordner:
- unified_events-1 (Enthält Ereignisse mit hoher Priorität.)
- unified_events-2 (Enthält Ereignisse mit niedriger Priorität.)
Ein Ereignis mit hoher Priorität ist ein Ereignis, das einer potenziell schädlichen Verbindung entspricht.
Veranstaltungstypen und ihre Priorität:
| Hohe Priorität (1) |
Niedrige Priorität (2) |
| Eindringen |
Verbindung |
| Malware |
Erkennung |
| Sicherheitsinformationen |
Datei |
| Zugehörige Verbindungsereignisse |
Statistik |
Die nächste Ausgabe zeigt ein Ereignis, das zu der neuen Verbindung gehört, die im vorherigen Beispiel verfolgt wurde. Das Format ist unified2 und wird aus der Ausgabe des jeweiligen Unified Event Logs entnommen, das sich unter [/ngfw]/var/sf/detection_engine/*/instance-1/ befindet, wobei 1 die fett formatierte Snort-Instanz-ID in der vorherigen Ausgabe +1 ist. Der Formatname des Unified Event Logs verwendet die Syntax unified_events-2.log.1599654750, wobei 2 für die Priorität der Ereignisse steht, wie in der Tabelle und der letzten fett formatierter Teil (1599654750) ist der Zeitstempel (Unix-Zeit) des Erstellens der Datei.
Tipp: Sie können den Linux-Befehl date verwenden, um die Unix-Zeit in ein lesbares Datum zu konvertieren:
admin@FP1120-2:~$ sudo date -d@1599654750
Sept. 9 14:32:30 MESZ 2020
Unified2 Record at offset 2190389
Type: 210(0x000000d2)
Timestamp: 0
Length: 765 bytes
Forward to DC: Yes
FlowStats:
Sensor ID: 0
Service: 676
NetBIOS Domain: <none>
Client App: 909, Version: 1.20.3 (linux-gnu)
Protocol: TCP
Initiator Port: 42310
Responder Port: 80
First Packet: (1599662092) Tue Sep 9 14:34:52 2020
Last Packet: (1599662092) Tue Sep 9 14:34:52 2020
<OUTPUT OMITTED FOR READABILITY>
Initiator: 192.168.0.2
Responder: 192.168.1.10
Original Client: ::
Policy Revision: 00000000-0000-0000-0000-00005f502a92
Rule ID: 268437505
Tunnel Rule ID: 0
Monitor Rule ID: <none>
Rule Action: 2
Neben jeder unified_events-Datei gibt es eine Lesezeichendatei, die 2 wichtige Werte enthält:
- Zeitstempel für die aktuelle Datei "unified_events" für diese Instanz und Priorität.
- Position in Byte für das letzte Leseereignis in der Datei "unified_event".
Die Werte werden der Reihe nach durch ein Komma getrennt, wie in diesem Beispiel gezeigt:
root@FTD:/home/admin# cat /var/sf/detection_engines/d5a4d5d0-6ddf-11ea-b364-2ac815c16717/instance-1/unified_events-2.log.bookmark.1a3d52e6-3e09-11ea-838f-68e7af919059
1599862498, 18754115
Dadurch kann der Disk Manager-Prozess erkennen, welche Ereignisse bereits verarbeitet (an FMC gesendet) wurden und welche nicht.
Anmerkung: Wenn der Datenträgermanager ein Ereignissilo löscht, werden vereinheitlichte Ereignisdateien entfernt.
Weitere Informationen zum Abfluss von Silos finden Sie im Abschnitt Datenträgerverwaltung.
Eine entleerte, vereinheitlichte Datei gilt als nicht verarbeitet, wenn eines der folgenden Ereignisse zutrifft:
- Der Zeitstempel des Lesezeichens ist kürzer als die Erstellungszeit der Datei.
- Der Zeitstempel des Lesezeichens entspricht dem Zeitpunkt der Dateierstellung, und die Position in Byte in der Datei ist kleiner als ihre Größe.
Der EventHandler-Prozess liest Ereignisse aus den vereinheitlichten Dateien und überträgt sie (als Metadaten) über sftunnel an das FMC. Dieser Prozess ist für die verschlüsselte Kommunikation zwischen dem Sensor und dem FMC verantwortlich. Dies ist eine TCP-basierte Verbindung, sodass das Ereignis-Streaming vom FMC bestätigt wird.
Sie können diese Meldungen in der Datei [/ngfw]/var/log/messages sehen:
sfpreproc:OutputFile [INFO] *** Opening /ngfw/var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478 for output" in /var/log/messages
EventHandler:SpoolIterator [INFO] Opened unified event file /var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478
sftunneld:FileUtils [INFO] Processed 10334 events from log file var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478
Diese Ausgabe bietet:
- Snort hat die Datei unified_events für die Ausgabe geöffnet (um sie darin zu schreiben).
- Der Ereignishandler hat die gleiche Datei "unified_events" geöffnet (um sie zu lesen).
- sftunnel hat die Anzahl von Ereignissen gemeldet, die von dieser Datei "unified_events" verarbeitet wurden.
Die Lesezeichendatei wird dann entsprechend aktualisiert. Der Sftunnel verwendet zwei verschiedene Kanäle, den Unified Events (UE)-Kanal 0 und 1 für Ereignisse mit hoher bzw. niedriger Priorität.
Mit dem CLI-Befehl sfunnel_status auf der FTD können Sie die Anzahl der gestreamten Ereignisse anzeigen.
Priority UE Channel 1 service
TOTAL TRANSMITTED MESSAGES <530541> for UE Channel service
RECEIVED MESSAGES <424712> for UE Channel service
SEND MESSAGES <105829> for UE Channel service
FAILED MESSAGES <0> for UE Channel service
HALT REQUEST SEND COUNTER <17332> for UE Channel service
STORED MESSAGES for UE Channel service (service 0/peer 0)
STATE <Process messages> for UE Channel service
REQUESTED FOR REMOTE <Process messages> for UE Channel service
REQUESTED FROM REMOTE <Process messages> for UE Channel service
Im FMC werden die Ereignisse vom SFDataCorrelator Prozess empfangen. Der Status der Ereignisse, die von jedem Sensor verarbeitet wurden, kann angezeigt werden, indem Sie den Befehl stats_unified.pl ausführen:
admin@FMC:~$ sudo stats_unified.pl
Current Time - Fri Sep 9 23:00:47 UTC 2020
**********************************************************************************
* FTD - 60a0526e-6ddf-11ea-99fa-89a415c16717, version 6.6.0.1
**********************************************************************************
Channel Backlog Statistics (unified_event_backlog)
Chan Last Time Bookmark Time Bytes Behind
0 2020-09-09 23:00:30 2020-09-07 10:41:50 0
1 2020-09-09 23:00:30 2020-09-09 22:14:58 6960
Dieser Befehl zeigt den Status des Ereignisrückstands für ein bestimmtes Gerät pro Kanal an. Die verwendete Kanal-ID entspricht dem Sftunnel. Der Bytes Behind-Wert kann als die Differenz zwischen der in der einheitlichen Ereignislesezeichendatei angezeigten Position und der Größe der einheitlichen Ereignisdatei (sowie jeder nachfolgenden Datei mit einem höheren Zeitstempel als der in der Lesezeichendatei) berechnet werden.
Der SFDataCorrelator-Prozess speichert auch Leistungsstatistiken, die in /var/sf/rna/correlator-stats/ gespeichert werden. Pro Tag wird eine Datei erstellt, in der die Leistungsstatistiken für diesen Tag im CSV-Format gespeichert werden. Der Name der Datei hat das Format JJJJ-MM-TT und die Datei, die dem aktuellen Tag entspricht, wird jetzt aufgerufen.
Die Statistiken werden alle 5 Minuten gesammelt (es gibt eine Zeile pro 5-Minuten-Intervall).
Die Ausgabe dieser Datei kann mit dem Befehl perfstats gelesen werden.
Anmerkung: Dieser Befehl wird auch zum Lesen von SNORT-Leistungsstatistikdateien verwendet. Daher müssen die entsprechenden Flags verwendet werden.
C: Weist perfstats an, dass die Eingabe eine korrelator-stats-Datei ist (ohne dieses Flag geht perfstats davon aus, dass es sich bei der Eingabe um eine Snort-Performance-Statistikdatei handelt).
-q: Im Ruhemodus wird nur die Zusammenfassung für die Datei gedruckt.
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
287 statistics lines read
host limit: 50000 0 50000
pcnt host limit in use: 100.01 100.00 100.55
rna events/second: 1.22 0.00 48.65
user cpu time: 1.56 0.11 58.20
system cpu time: 1.31 0.00 41.13
memory usage: 5050384 0 5138904
resident memory usage: 801920 0 901424
rna flows/second: 64.06 0.00 348.15
rna dup flows/second: 0.00 0.00 37.05
ids alerts/second: 1.49 0.00 4.63
ids packets/second: 1.71 0.00 10.10
ids comm records/second: 3.24 0.00 12.63
ids extras/second: 0.01 0.00 0.07
fw_stats/second: 1.78 0.00 5.72
user logins/second: 0.00 0.00 0.00
file events/second: 0.00 0.00 3.25
malware events/second: 0.00 0.00 0.06
fireamp events/second: 0.00 0.00 0.00
Jede Zeile in der Zusammenfassung hat drei Werte in dieser Reihenfolge: Durchschnitt, Minimum, Maximum.
Wenn Sie ohne das -q-Flag drucken, sehen Sie auch die 5-Minuten-Intervallwerte (die Zusammenfassung wird am Ende angezeigt).
Anmerkung: Jedes FMC verfügt über eine maximale Flussrate, die in seinem Datenblatt beschrieben ist. Die nächste Tabelle enthält die Werte pro Modul aus dem jeweiligen Datenblatt.
| Modell |
FMC 750 |
FMC 1000 |
FMC 1600 |
FÜZ 2000 |
FMC 2500 |
FMC 2600 |
FMC 4000 |
FMC 4500 |
FMC 4600 |
FMC V |
FMCv300 |
| Maximale Durchsatzrate (fps) |
2000 |
5000 |
5000 |
12000 |
12000 |
12000 |
20000 |
20000 |
20000 |
Variable |
12000 |
Anmerkung: Diese Werte gelten für die Summe aller Ereignisarten, die in der Statistikausgabe von SFDataCorrelator fett dargestellt werden.
Wenn Sie sich die Ausgabe ansehen und das FMC so dimensionieren, dass Sie auf das Worst-Case-Szenario vorbereitet sind (wenn alle Maximalwerte gleichzeitig auftreten), dann ist die Rate der Ereignisse, die dieses FMC erkennt, 48,65 + 348,15 + 4,63 + 3,25 + 0,06 = 404,74 fps.
Der Gesamtwert kann mit dem Wert aus dem Datenblatt des jeweiligen Modells verglichen werden.
Der SFDataCorrelator kann zusätzlich zu den empfangenen Ereignissen (z. B. Korrelationsregeln) weitere Aufgaben ausführen und diese dann in der Datenbank speichern, die abgefragt wird, um verschiedene Informationen in der FMC-GUI, z. B. Dashboards und Ereignisansichten, aufzufüllen.
Datenträgerverwaltung
Das nächste Diagramm zeigt die logischen Komponenten für den Health Monitor- und den Disk Manager-Prozess, da sie für die Generierung von festplattenbezogenen Integritätswarnungen miteinander verflochten sind.
Kurz gesagt, der Disk-Manager-Prozess verwaltet die Festplattennutzung der Box und hat seine Konfigurationsdateien im Ordner [/ngfw]/etc/sf/. Es gibt mehrere Konfigurationsdateien für den Datenträgerverwaltungsprozess, die unter bestimmten Umständen verwendet werden:
- diskmanager.conf: Standard-Konfigurationsdatei
- diskmanager_2hd.conf: Wird verwendet, wenn in der Box zwei Festplatten installiert sind. Die zweite Festplatte bezieht sich auf die Malware-Erweiterung, die zum Speichern von Dateien gemäß der Dateirichtlinie verwendet wird.
- ramdisk-diskmanager.conf: Wird verwendet, wenn das Protokoll für Ramdisk aktiviert ist. Weitere Informationen finden Sie im Abschnitt Log to Ramdisk.
Jeder Dateityp wird vom Datenträgermanager überwacht, dem ein Silo zugewiesen ist. Auf Basis des verfügbaren Festplattenspeichers im System berechnet der Festplattenmanager für jedes Silo eine Wassermarke (High Water Mark, HWM) und eine Wassermarke (Low Water Mark, LWM). Wenn der Disk Manager-Prozess ein Silo entleert, tut er dies bis zum Erreichen des LWM. Da Ereignisse pro Datei entladen werden, kann dieser Schwellenwert überschritten werden.
Um den Status von Silos auf einem Sensorgerät zu überprüfen, können Sie folgenden Befehl ausführen:
> show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.208 MB 130.417 MB Temporary Files 0 KB 108.681 MB 434.726 MB Action Queue Results 0 KB 108.681 MB 434.726 MB User Identity Events 0 KB 108.681 MB 434.726 MB UI Caches 4 KB 326.044 MB 652.089 MB Backups 0 KB 869.452 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.089 MB 1.274 GB Performance Statistics 45.985 MB 217.362 MB 2.547 GB Other Events 0 KB 434.726 MB 869.452 MB IP Reputation & URL Filtering 0 KB 543.407 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.736 GB Archives & Cores & File Logs 0 KB 869.452 MB 4.245 GB Unified Low Priority Events 974.109 MB 1.061 GB 5.307 GB RNA Events 879 KB 869.452 MB 3.396 GB File Capture 0 KB 2.123 GB 4.245 GB Unified High Priority Events 252 KB 3.184 GB 7.429 GB IPS Events 3.023 MB 2.547 GB 6.368 GB
Der Datenträgerverwaltungsprozess wird ausgeführt, wenn eine der folgenden Bedingungen erfüllt ist:
- Der Prozess wird gestartet (oder neu gestartet)
- Ein Silo erreicht die HWM
- Ein Silo wird manuell entleert
- Einmal pro Stunde
Jedes Mal, wenn der Disk Manager-Prozess ausgeführt wird, generiert er einen Eintrag für jedes der verschiedenen Silos in seiner eigenen Protokolldatei, die sich unter [/ngfw]/var/log/diskmanager.log befindet und Daten im CSV-Format enthält.
Als Nächstes wird eine Beispielzeile aus der Datei diskmanager.log angezeigt. Er wurde von einem Sensor entnommen, der den Ablauf nicht verarbeiteter Ereignisse aus der Integritätswarnung für Ereignisse mit einheitlicher niedriger Priorität sowie die Aufschlüsselung der entsprechenden Spalten auslöste:
priority_2_events,1599668981,221,4587929508,1132501868,20972020,4596,1586044534,5710966962,1142193392,110,0
| Spalte | Wert |
| Silo-Label |
priority_2_events |
| Entleerungszeit (Epochenzeit) |
1599668981 |
| Anzahl der entleerten Dateien | 221 |
| Byte entladen | 4587929508 |
| Aktuelle Datengröße nach Ablauf (Byte) | 1132501868 |
| Größte entleerte Datei (Byte) | 20972020 |
| Kleinste entleerte Datei (Byte) | 4596 |
| Älteste entleerte Datei (Epochenzeit) | 1586044534 |
| Hohes Wasserzeichen (Byte) | 5710966962 |
| Niedrige Wasserzeichen (Byte) | 1142193392 |
| Anzahl der Dateien mit nicht verarbeiteten Ereignissen, die gelöscht wurden | 110 |
| Diskmanager-Zustandsmerkmal | 0 |
Diese Informationen werden dann vom jeweiligen Health Monitor-Modul gelesen, um den entsprechenden Health Alert auszulösen.
Manuelles Entleeren eines Silos
In bestimmten Szenarien können Sie ein Silo manuell entleeren. Um beispielsweise Speicherplatz mit einem manuellen Silo-Drain freizugeben, haben manuelle Dateientfernungen den Vorteil, dass der Datenträgermanager entscheiden kann, welche Dateien aufbewahrt und welche gelöscht werden. Der Datenträgermanager speichert die neuesten Dateien für dieses Silo.
Jedes Silo kann entladen werden, und dies funktioniert wie beschrieben (der Datenträgermanager entlädt Daten, bis die Datenmenge unter den LWM-Grenzwert fällt). Der Befehl system support silo-drain ist im FTD CLISH-Modus verfügbar und bietet eine Liste der verfügbaren Silos (Name + numerische ID).
Dies ist ein Beispiel für eine manuelle Ableitung des Unified Low Priority Events-Silos:
> show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.213 MB 130.426 MB Temporary Files 0 KB 108.688 MB 434.753 MB Action Queue Results 0 KB 108.688 MB 434.753 MB User Identity Events 0 KB 108.688 MB 434.753 MB UI Caches 4 KB 326.064 MB 652.130 MB Backups 0 KB 869.507 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.130 MB 1.274 GB Performance Statistics 1.002 MB 217.376 MB 2.547 GB Other Events 0 KB 434.753 MB 869.507 MB IP Reputation & URL Filtering 0 KB 543.441 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.737 GB Archives & Cores & File Logs 0 KB 869.507 MB 4.246 GB Unified Low Priority Events 2.397 GB 1.061 GB 5.307 GB RNA Events 8 KB 869.507 MB 3.397 GB File Capture 0 KB 2.123 GB 4.246 GB Unified High Priority Events 0 KB 3.184 GB 7.430 GB IPS Events 0 KB 2.547 GB 6.368 GB > system support silo-drain Available Silos 1 - misc_fdm_logs 2 - Temporary Files 3 - Action Queue Results 4 - User Identity Events 5 - UI Caches 6 - Backups 7 - Updates 8 - Other Detection Engine 9 - Performance Statistics 10 - Other Events 11 - IP Reputation & URL Filtering 12 - arch_debug_file 13 - Archives & Cores & File Logs 14 - Unified Low Priority Events 15 - RNA Events 16 - File Capture 17 - Unified High Priority Events 18 - IPS Events 0 - Cancel and return Select a Silo to drain: 14 Silo Unified Low Priority Events being drained. > show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.213 MB 130.426 MB Temporary Files 0 KB 108.688 MB 434.753 MB Action Queue Results 0 KB 108.688 MB 434.753 MB User Identity Events 0 KB 108.688 MB 434.753 MB UI Caches 4 KB 326.064 MB 652.130 MB Backups 0 KB 869.507 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.130 MB 1.274 GB Performance Statistics 1.002 MB 217.376 MB 2.547 GB Other Events 0 KB 434.753 MB 869.507 MB IP Reputation & URL Filtering 0 KB 543.441 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.737 GB Archives & Cores & File Logs 0 KB 869.507 MB 4.246 GB Unified Low Priority Events 1.046 GB 1.061 GB 5.307 GB RNA Events 8 KB 869.507 MB 3.397 GB File Capture 0 KB 2.123 GB 4.246 GB Unified High Priority Events 0 KB 3.184 GB 7.430 GB IPS Events 0 KB 2.547 GB 6.368 GB
Integritätsüberwachung
Dies sind die wichtigsten Punkte:
- Alle Statusmeldungen, die im FMC im Menü für den Zustandsmonitor oder auf der Registerkarte für den Zustand im Nachrichtencenter angezeigt werden, werden vom Zustandsüberwachungsprozess generiert.
- Dieser Prozess überwacht den Zustand des Systems, sowohl für das FMC als auch für die verwalteten Sensoren, und besteht aus einer Reihe verschiedener Module.
- Integritätswarnmodule werden in der Integritätsrichtlinie definiert, die pro Gerät angehängt werden kann.
- Integritätswarnungen werden vom Modul "Datenträgerverwendung" generiert, das auf jedem vom FMC verwalteten Sensor ausgeführt werden kann.
- Wenn der Integritätsüberwachungsprozess auf dem FMC ausgeführt wird (alle 5 Minuten oder wenn ein manueller Vorgang ausgelöst wird), überprüft das Modul Datenträgerverwendung die Datei diskmanager.log, und wenn die richtigen Bedingungen erfüllt sind, wird die entsprechende Integritätswarnung ausgelöst.
Damit eine Integritätswarnung für das Ableiten nicht verarbeiteter Ereignisse ausgelöst wird, müssen alle folgenden Bedingungen zutreffen:
- Das Feld Bytes drained ist größer als 0 (gibt an, dass die Daten aus diesem Silo drained waren).
- Die Anzahl der Dateien mit nicht verarbeiteten Ereignissen, deren Drain-Wert größer als 0 ist (dies zeigt an, dass in den drainierten Daten nicht verarbeitete Ereignisse aufgetreten sind).
- Die Zeit der Entleerung ist innerhalb der letzten 1 Stunde.
Damit eine Warnung über die Status-Alarmierung bei häufigen Ereignisabläufen ausgelöst wird, müssen die folgenden Bedingungen zutreffen:
- Die letzten beiden Einträge in der Datei diskmanager.log müssen wahr sein:
- Das Feld Bytes drained ist größer als 0 (gibt an, dass die Daten aus diesem Silo drained waren).
- Der Abstand sollte weniger als 5 Minuten betragen.
- Der Zeitpunkt der Entleerung im letzten Eintrag für dieses Silo liegt innerhalb der letzten 1 Stunde.
Die vom Laufwerksnutzungsmodul (und von anderen Modulen) erfassten Ergebnisse werden über Sftunnel an das FMC gesendet. Sie können die Zähler für die über sftunnel ausgetauschten Systemereignisse anzeigen, indem Sie den Befehl sftunnel_status ausführen:
TOTAL TRANSMITTED MESSAGES <3544> for Health Events service
RECEIVED MESSAGES <1772> for Health Events service
SEND MESSAGES <1772> for Health Events service
FAILED MESSAGES <0> for Health Events service
HALT REQUEST SEND COUNTER <0> for Health Events service
STORED MESSAGES for Health service (service 0/peer 0)
STATE <Process messages> for Health Events service
REQUESTED FOR REMOTE <Process messages> for Health Events service
REQUESTED FROM REMOTE <Process messages> for Health Events service
Bei Ramdisk anmelden
Während die meisten Ereignisse auf der Festplatte gespeichert werden, ist das Gerät standardmäßig so konfiguriert, dass es sich bei Ramdisk anmeldet, um eine allmähliche Beschädigung der SSD zu verhindern, die durch ständige Schreibvorgänge und Löschungen von Ereignissen auf der Festplatte verursacht werden kann.
In diesem Szenario werden die Ereignisse nicht unter [/ngfw]/var/sf/detection_engine/*/instance-N/ gespeichert, sondern befinden sich in [/ngfw]/var/sf/detection_engines/*/instance-N/connection/, einer symbolischen Verknüpfung zu /dev/shm/instance-N/connection. In diesem Fall befinden sich die Ereignisse nicht im physischen, sondern im virtuellen Speicher.
admin@FTD4140:~$ ls -la /ngfw/var/sf/detection_engines/b0c4a5a4-de25-11ea-8ec3-4df4ea7207e3/instance-1/connection
lrwxrwxrwx 1 sfsnort sfsnort 30 Sep 9 19:03 /ngfw/var/sf/detection_engines/b0c4a5a4-de25-11ea-8ec3-4df4ea7207e3/instance-1/connection -> /dev/shm/instance-1/connection
Um zu überprüfen, welches Gerät derzeit für die Ausführung des Befehls show log-events-to-ramdisk aus der FTD-CLISH konfiguriert ist. Sie können dies auch ändern, wenn Sie den Befehl configure log-events-to-ramdisk <enable/disable> ausführen:
> show log-events-to-ramdisk
Logging connection events to RAM Disk.
> configure log-events-to-ramdisk
Enable or Disable enable or disable (enable/disable)
Warnung: Wenn der Befehl configure log-events-to-ramdisk disable ausgeführt wird, müssen zwei Bereitstellungen auf dem FTD durchgeführt werden, damit snort nicht in einem D-Zustand (Unterbrechungsfreier Energiesparmodus) feststeckt, was zu einem Datenverkehrsausfall führen würde.
Dieses Verhalten wird mit der Cisco Bug-ID CSCvz53372 dokumentiert. Bei der ersten Bereitstellung wird die Neubewertung der Snort-Speicherphase übersprungen, wodurch snort in den Zustand D wechselt. Die Problemumgehung besteht darin, eine weitere Bereitstellung mit etwaigen Dummy-Änderungen zu erstellen.
Wenn Sie sich bei ramdisk anmelden, ist der Hauptnachteil, dass das jeweilige Silo einen kleineren Platz hat und unter den gleichen Umständen öfter entleert wird. Die nächste Ausgabe ist der Disk-Manager von einem FPR 4140 mit und ohne die Log-Ereignisse zu ramdisk aktiviert für den Vergleich.
Bei Ramdisk anmelden aktiviert:
> show disk-manager
Silo Used Minimum Maximum
Temporary Files 0 KB 903.803 MB 3.530 GB
Action Queue Results 0 KB 903.803 MB 3.530 GB
User Identity Events 0 KB 903.803 MB 3.530 GB
UI Caches 4 KB 2.648 GB 5.296 GB
Backups 0 KB 7.061 GB 17.652 GB
Updates 305.723 MB 10.591 GB 26.479 GB
Other Detection Engine 0 KB 5.296 GB 10.591 GB
Performance Statistics 19.616 MB 1.765 GB 21.183 GB
Other Events 0 KB 3.530 GB 7.061 GB
IP Reputation & URL Filtering 0 KB 4.413 GB 8.826 GB
arch_debug_file 0 KB 17.652 GB 105.914 GB
Archives & Cores & File Logs 0 KB 7.061 GB 35.305 GB
RNA Events 0 KB 7.061 GB 28.244 GB
File Capture 0 KB 17.652 GB 35.305 GB
Unified High Priority Events 0 KB 17.652 GB 30.892 GB
Connection Events 0 KB 451.698 MB 903.396 MB
IPS Events 0 KB 12.357 GB 26.479 GB
Bei Ramdisk anmelden deaktiviert:
> show disk-manager
Silo Used Minimum Maximum
Temporary Files 0 KB 976.564 MB 3.815 GB
Action Queue Results 0 KB 976.564 MB 3.815 GB
User Identity Events 0 KB 976.564 MB 3.815 GB
UI Caches 4 KB 2.861 GB 5.722 GB
Backups 0 KB 7.629 GB 19.074 GB
Updates 305.723 MB 11.444 GB 28.610 GB
Other Detection Engine 0 KB 5.722 GB 11.444 GB
Performance Statistics 19.616 MB 1.907 GB 22.888 GB
Other Events 0 KB 3.815 GB 7.629 GB
IP Reputation & URL Filtering 0 KB 4.768 GB 9.537 GB
arch_debug_file 0 KB 19.074 GB 114.441 GB
Archives & Cores & File Logs 0 KB 7.629 GB 38.147 GB
Unified Low Priority Events 0 KB 9.537 GB 47.684 GB
RNA Events 0 KB 7.629 GB 30.518 GB
File Capture 0 KB 19.074 GB 38.147 GB
Unified High Priority Events 0 KB 19.074 GB 33.379 GB
IPS Events 0 KB 13.351 GB 28.610 GB
Die geringere Größe des Silos wird durch die höhere Geschwindigkeit kompensiert, mit der auf die Ereignisse zugegriffen und diese an das FMC übertragen werden können. Dies ist eine bessere Option unter angemessenen Bedingungen, während der Nachteil berücksichtigt werden muss.
Häufig gestellte Fragen
F: Werden die Integritätswarnungen bei Ablauf von Ereignissen nur von Verbindungsereignissen generiert?
A: Nein.
- Alerts of Frequent Drain können von jedem Disk-Manager Silo generiert werden.
- Warnungen über den Ablauf nicht verarbeiteter Ereignisse können von jedem ereignisbezogenen Silo generiert werden. Verbindungsereignisse sind die häufigsten Ursachen.
F: Ist es immer ratsam, ein Protokoll auf Ramdisk zu deaktivieren, wenn eine Warnung über den Zustand häufiger Abflüsse angezeigt wird?
A: Nein. Nur in Szenarien mit übermäßiger Protokollierung, mit Ausnahme von DOS/DDoS, wenn das betroffene Silo das Verbindungsereignissilo ist, und nur in Fällen, in denen es nicht möglich ist, die Protokollierungseinstellungen weiter anzupassen. Wenn DOS/DDOS übermäßige Protokollierung verursacht, besteht die Lösung darin, DOS/DDOS-Schutz zu implementieren oder die Quelle(n) der DOS/DDOS-Angriffe zu beseitigen.
Die Standardfunktion "Log to Ramdisk" reduziert den SSD-Verschleiß. Daher wird dringend empfohlen, die Funktion zu verwenden.
F: Was ist ein nicht bearbeitetes Ereignis?
A: Ereignisse werden nicht einzeln als nicht verarbeitet gekennzeichnet. In folgenden Fällen weist eine Datei nicht verarbeitete Ereignisse auf:
- Der Erstellungszeitstempel ist höher als das Zeitstempelfeld in der jeweiligen Lesezeichendatei.
Oder
- Der Erstellungszeitstempel entspricht dem Zeitstempelfeld in der jeweiligen Lesezeichendatei und seine Größe ist größer als die Position im Byte-Feld in der jeweiligen Lesezeichendatei.
F: Woher weiß das FMC die Anzahl der Bytes, die für einen bestimmten Sensor zurückliegen?
A: Der Sensor sendet Metadaten über den Dateinamen und die Größe der Unified_events-Datei sowie die Informationen über die Lesezeichendateien, wodurch FMC genügend Informationen bereitstellt, um die Bytes zu berechnen, hinter denen sich:
Aktuelle Unified_events-Dateigröße - Position in Bytes-Feld aus Lesezeichendatei + Größe aller Unified_events-Dateien mit einem höheren Zeitstempel als dem Zeitstempel in der jeweiligen Lesezeichendatei.
Bekannte Probleme
1. Öffnen Sie das Bug Search Tool und verwenden Sie diese Abfrage:
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
4.0 |
10-Jul-2026
|
Aktualisierter Titel (zu lang), Rechtschreibung, Grammatik, eingefügte Zeilen in separaten Abschnitten zur besseren Lesbarkeit, aktualisierter Alternativtext und CCW-Warnungen. |
3.0 |
03-May-2024
|
Aktualisierte Einführung, PII, Alt-Text, maschinelle Übersetzung, Linkziele und Formatierung. |
1.0 |
25-Sep-2020
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)