Beim Parsen von Snort-Protokollen mit dem Pypar-Modul ist ein Problem aufgetreten.
Das Problem besteht darin, das Snort-Protokoll zu trennen (mit mehrzeiligen Einträgen, getrennt durch eine Leerzeile) und pyparsing zu machen, um jeden Eintrag als ganzen Block zu analysieren, anstatt zeilenweise zu lesen und zu erwarten, dass die Grammatik mit jedem funktioniert Linie (offensichtlich nicht.)
Ich habe versucht, jeden Chunk in einen temporären String umzuwandeln, indem ich die Zeilenumbrüche in jedem Chunk ausstreiche, aber er verweigert die korrekte Verarbeitung. Ich mag zwar völlig falsch liegen, aber ich denke nicht (ein ähnliches Formular funktioniert perfekt für Logs vom Typ syslog, aber diese sind einzeilige Einträge und eignen sich daher für Ihre grundlegende Datei-Iterator- / Zeilenverarbeitung)
Hier ist ein Beispiel für das Protokoll und den Code, den ich bisher hatte:
%Vor%Und der aktualisierte Code:
%Vor%Jede Hilfe, Zeiger, RTFMs, Sie tun es falsch, usw., sehr geschätzt.
Sie haben noch etwas Regex zu verlernen, aber hoffentlich wird das nicht zu schmerzhaft sein. Der größte Schuldige in Ihrem Denken ist die Verwendung dieses Konstrukts:
%Vor% Jeder Subparser in einem Pyparsing-Parser ist ziemlich eigenständig und arbeitet sequentiell durch den eingehenden Text. Der Ausdruck "Regex" hat also keine Möglichkeit, auf den nächsten Ausdruck zu schauen, um zu sehen, wo die Wiederholung '*' enden sollte. Mit anderen Worten, der Ausdruck Regex(".*") wird nur bis zum Ende der Zeile gelesen, da% ce_de% aufhört, ohne mehrzeilig zu spezifizieren.
Beim Piparsen wird dieses Konzept mit SkipTo implementiert. Hier ist, wie Ihre Kopfzeile geschrieben wird:
%Vor%Ihr ". *" Problem wird gelöst, indem Sie es in:
ändern %Vor%Das Gleiche gilt für cls.
Ein letzter Fehler, Ihre Definition von Datum ist kurz von eins ':' + Ganzzahl:
%Vor%sollte sein:
%Vor%Ich denke, dass diese Änderungen ausreichen werden, um Ihre Protokolldaten zu analysieren.
Hier sind einige andere Stilvorschläge:
Sie haben viele wiederholte ".*" -Ausdrücke. Ich habe angefangen, alle meine unterdrückbaren Interpunktionen in einer sehr kompakten und leicht zu pflegenden Aussage zu definieren:
(Erweitern Sie, um weitere Interpunktionszeichen hinzuzufügen, die Ihnen gefallen). Jetzt kann ich diese Zeichen mit ihren symbolischen Namen verwenden, und ich finde den resultierenden Code ein wenig einfacher zu lesen.
Sie beginnen den Header mit Suppress("]") . Ich mag es nie, in Literalen eingebettete Leerzeichen auf diese Weise zu sehen, da es einige der Parsing-Robustheiten umgeht. Pyparsing bietet Ihnen das automatische Whitespace-Skipping. Wenn aus irgendeinem Grund der Abstand zwischen "[**]" und "[" geändert wurde, um 2 oder 3 Leerzeichen oder eine Registerkarte zu verwenden, würde das unterdrückte Literal fehlschlagen. Kombiniere dies mit dem vorherigen Vorschlag, und der Header würde mit
Ich weiß, dass dies ein generierter Text ist, daher ist eine Variation in diesem Format unwahrscheinlich, aber es spielt besser auf die Stärken von pyparsing an.
Sobald Sie Ihre Felder analysiert haben, beginnen Sie, verschiedenen Elementen in Ihrem Parser Ergebnisnamen zuzuweisen. Dies wird es einfacher machen, die Daten später herauszubekommen. Ändern Sie beispielsweise cls zu:
%Vor% Ermöglicht Ihnen den Zugriff auf die Klassifizierungsdaten mit header = Suppress("[**] [") + ... .
Nun, ich weiß Snort oder pyparsing nicht, also entschuldigt mich im Voraus, wenn ich etwas Dummes sage. Ich bin mir nicht sicher, ob das Problem darin besteht, dass pyparsing die Einträge nicht verarbeiten kann oder dass Sie sie nicht im richtigen Format an pyparsing senden können. Wenn das letztere, warum nicht so etwas tun?
Natürlich, wenn Sie jeden Chunk ändern müssen, bevor Sie ihn an pyparsing senden, können Sie dies tun, bevor yield es tut.