Exemples de problèmes d'analyse syntaxique

Conversion de protocole

L'exemple suivant illustre une conversion de protocole typique qui recherche TCP, UDP, ICMP, ou GRE partout dans le contenu. Le modèle de recherche est entouré par toute limite de mot, par exemple, onglet, espace, fin de ligne. De même, la casse est ignorée :

<pattern id="Protocol" case-insensitive="true" xmlns="">
<![CDATA[\b(TCP|UDP|ICMP|GRE)\b]]>
</pattern> 
<matcher field="Protocol" order="1" pattern-id="Protocol" capture-group="1" />

Effectuer une substitution unique

L'exemple suivant montre une substitution qui analyse l'adresse IP source, puis remplace le résultat et définit l'adresse IP sur 192.0.2.1, en ignorant l'adresse IP dans le contenu.

Cet exemple suppose que l'adresse IP source correspond à quelque chose de similaire à SrcAddress=203.0.113.1, suivi d'une virgule :

<pattern id="SourceIp_AuthenOK" xmlns=""> 
<![CDATA[SrcAddress=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}),]]>
</pattern>

<matcher field="SourceIp" order="1" pattern-id="SourceIp_AuthenOK" 
capture-group="192.0.2.1" enable-substitutions="true"/>

Génération d'une adresse MAC séparée par deux points

QRadar détecte les adresses MAC sous la forme d'adresses séparées par un signe deux-points. Parce que tous les périphériques risquent de ne pas utiliser ce format, l'exemple suivant montre comment corriger cette situation :

<pattern id="SourceMACWithDashes" xmlns="">
    <![CDATA[SourceMAC=([0-9a-fA-F]{2})-([0-9a-fA-F]{2})-([0-9a-fA-F]{2})-
    ([0-9a-fA-F]{2})-([0-9a-fA-F]{2})-([0-9a-fA-F]{2})]]>
</pattern> 
 <matcher field="SourceMAC" order="1" pattern-id=" 
    SourceMACWithDashes" capture-group="\1:\2:\3:\4:\5:\6" />

Dans l'exemple précédent, SourceMAC=12-34-1a-2b-3c-4d est converti en adresse MAC 12:34:1a:2b:3c:4d.

Si les tirets sont supprimés du motif, le motif convertit une adresse MAC et n'a pas de séparateurs. Si des espaces sont insérés, le motif convertit une adresse MAC séparée par des espaces.

Combinaison d'adresse IP et de port

Typiquement une adresse IP et le port sont combinés en un seul champ, qui est séparé par une virgule.

L'exemple suivant utilise plusieurs groupes de capture avec un motif :

pattern id="SourceIPColonPort" xmlns="">
<! [CDATA[Source=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}):([\d]{1,5})]]>
</pattern> 

<matcher field="SourceIp" order="1" pattern-id="SourceIPColonPort" capture-group="1" /> 
<matcher field="SourcePort" order="1" pattern-id="SourceIPColonPort" capture-group="2" />

Modification d'une catégorie d'événement

Une catégorie d'événement de périphérique peut être codée en dur, ou la gravité peut être ajustée.

L'exemple suivant ajuste la gravité pour un seul type d'événement :

<event-match-single event-name="TheEvent" device-event-category="Actual Category" severity="6" send-identity="UseDSMResults" />

Suppression des événements de changement d'identité

Un DSM peut inutilement envoyer des événements de changement d'identité.

Les exemples suivants montrent comment éviter que des événements de changement d'identité soient envoyés à partir d'un seul type d'événement et un groupe d'événements.

// Never send identity for the event with an EventName of Authen OK 
<event-match-single event-name="Authen OK" device-event-category="ACS" 
severity="6" send-identity="OverrideAndNeverSend" />

// Never send any identity for an event with an event name starting with 7, 
followed by one to five other digits: 
<pattern id="EventNameId" xmlns=""><![CDATA[(7\d{1,5})]]>
</pattern>

<event-match-multiple pattern-id="EventNameId" capture-group-index="1" 
device-event-category="Cisco Firewall" severity="7" 
send-identity="OverrideAndNeverSend"/> 

Formatage des dates d'événements et d'horodatages

Une extension de source de journal peut détecter plusieurs formats de date et d'horodatage différents sur les événements.

Etant donné que les fabricants de périphériques ne se conforment pas à un format d'horodatagestandard, le paramètre optionnel ext-data est inclus dans l'extension de la source de journal pour permettre à DeviceTime d'être reformaté. L'exemple suivant montre comment un événement peut être reformaté pour corriger le formatage d'horodatage :

<device-extension> 
<pattern id="EventName1">(logger):</pattern> 
<pattern id="DeviceTime1">time=\[(\d{2}/\w{3}/\d{4}:\d{2}:\d{2}:\d{2})\]</pattern> 
<pattern id="Username">(TLSv1)</pattern> 

<match-group order="1" description="Full Test"> 
   <matcher field="EventName" order="1" pattern-id="EventName1_Pattern" capture-group="1"/> 
   <matcher field="DeviceTime" order="1" pattern-id="DeviceTime1_Pattern" 
   capture-group="1" ext-data="dd/MMM/YYYY:hh:mm:ss"/> 
   <matcher field="UserName" order="1" pattern-id="Username_Pattern" capture-group="1"/>
</match-group>
</device-extension>

Formats de journaux multiples dans une source de journal unique

Parfois, plusieurs formats de journaux sont inclus dans une source de journal unique.

May 20 17:15:50 kernel: DROP IN=vlan2 OUT= MAC= SRC=<Source_IP_address> 
DST=<Destination_IP_address> PROTO=UDP SPT=1900 DPT=1900
May 20 17:16:26 <server>[22331]: password auth succeeded for 'root' from <IP_address>
May 20 17:16:28 <server>[22331]: exit after auth (root): Exited normally </br>
May 20 17:16:14 <server>[22331]: bad password attempt for 'root' from <IP_address>:3364

Par exemple, il existe deux formats de journal : l'un pour les événements de pare-feu, et un pour les événements d'authentification. Vous devez écrire plusieurs motifs pour analyser les événements. Vous pouvez spécifier l'ordre d'analyse. Typiquement, les événements les plus fréquents sont analysés en premier, suivis des événements les moins fréquents. Vous pouvez avoir autant de motifs que nécessaire pour analyser tous les événements. La variable de commande détermine dans quel ordre les motifs sont appariés.

L'exemple suivant montre de multiples formats pour les champs suivants EventName et UserName

Des motifs distincts sont écrits pour analyser chaque type de journal unique. Les deux motifs sont référencés lorsque vous affectez la valeur aux champs normalisés.

<pattern id="EventName-DDWRT-FW_Pattern" xmlns=""><![CDATA[kernel\:\s(.*?)\s]]></pattern>
<pattern id="EventName-DDWRT-Auth_Pattern" xmlns=""><![CDATA[sdrophear\[\d{1,5}\]|:\s(.*?\s.*?)\s]]>
</pattern>

<pattern id="UserName_DDWRT-Auth1__Pattern" xmlns=""><![CDATA[\sfor\s\'(.*?)\'s]]></pattern>
<pattern id="UserName_DDWRT-Auth2__Pattern" xmlns=""><![CDATA[\safter\sauth\s\((.*?)\)\:]]></pattern>

<match-group order="1" description="DD-WRT Device Extensions xmlns=""> 
   <matcher field="EventName" order="1" pattern-id="EventName-DDWRT-FW_Pattern" capture-group="1"/> 
   <matcher field="EventName" order="2" pattern-id="EventName-DDWRT-Auth_Pattern" capture-group="1"/> 
   
   <matcher field="UserName" order="1" pattern-id="UserName-DDWRT-Auth1_Pattern" capture-group="1"/> 
   <matcher field="UserName" order="2" pattern-id="UserName-DDWRT-Auth2_Pattern" capture-group="1"/> 
   

Analyse d'un format de journal CSV

Pour analyser un fichier journal au format CSV, utilisez le type d'expression de liste générique disponible dans l'éditeur DSM. Pour plus d'informations, voir Expressions au format de liste générique pour les données structurées (https://www.ibm.com/docs/en/qsip/7.5?topic=editor-expressions-in-generic-list-format-structured-data).

Event,User,Source IP,Source Port,Destination IP,Destination Port
Failed Login,<Username>,<Source_IP_address>,1024,<Destination_IP_address>,22 
Successful Login,<Username>,<Source_IP_address>,1743,<Destination_IP_address>,110 
Privilege Escalation,<Username>,<Source_IP_address>,1028,<Destination_IP_address>,23