Ejemplos de problemas de análisis

Cuando se crea una extensión de origen de registro, es posible que encuentre algunos problemas de análisis. Utilice estos ejemplos de XML para resolver problemas específicos de análisis.

Convertir un protocolo

El ejemplo siguiente muestra una conversión de protocolo habitual que busca TCP, UDP, ICMP o GRE en cualquier lugar de la carga útil. El patrón de búsqueda está delimitado por cualquier límite de palabra, por ejemplo, tabulador, espacio o fin de línea. Además, las mayúsculas y minúsculas de los caracteres se ignoran:

<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" />

Efectuar una única sustitución

El ejemplo siguiente muestra una sustitución que analiza la dirección IP de origen y, a continuación, altera temporalmente el resultado y establece la dirección IP en 192.0.2.1, ignorando la dirección IP en la carga útil.

En este ejemplo se presupone que la dirección IP de origen coincide con algo similar a SrcAddress=203.0.113.1 seguido de una coma:

<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"/>

Generar una dirección MAC separada por dos puntos

QRadar detecta las direcciones MAC en un formato separado por dos puntos. Puesto que es que posible que no todos los dispositivos utilicen este formato, el ejemplo siguiente muestra cómo corregir dicha situación:

<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" />

En el ejemplo anterior, SourceMAC=12-34-1a-2b-3c-4d se convierte en una dirección MAC de 12:34:1a:2b:3c:4d.

Si se eliminan los guiones del patrón, éste convierte una dirección MAC y no tiene separadores. Si se insertan espacios, el patrón convierte una dirección MAC separadas por espacios.

Combinar dirección IP y puerto

Normalmente, una dirección IP y un puerto se combinan en un campo, que está separado por dos puntos.

En el ejemplo siguiente se utilizan varios grupos de captura con un patrón:

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" />

Modificar una categoría de suceso

Puede codificarse una categoría de suceso de dispositivo o ajustarse la gravedad.

El ejemplo siguiente ajusta la gravedad de un tipo de suceso único:

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

Suprimir sucesos de cambio de identidad

Un DSM puede enviar innecesariamente sucesos de cambio de identidad.

Los ejemplos siguientes muestran cómo suprimir sucesos de cambio de identidad para que no se envíen desde un tipo de suceso único y un grupo de sucesos.

// 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"/>

Formato de indicaciones de fecha y hora de suceso

Una extensión de origen de registro puede detectar varios formatos de indicación de fecha y hora en los sucesos.

Dado que los fabricantes de dispositivos no se ajustan a un formato de indicación de fecha y hora estándar, se incluye el parámetro opcional ext-data en la extensión de origen de registro para permitir el formateo de DeviceTime. El ejemplo siguiente muestra cómo puede reformatearse un suceso para corregir el formato de indicación de fecha y hora:

<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>

Varios formatos de registro en un único origen de registro

Ocasionalmente, se incluyen varios formatos de registro en un único origen de registro.

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

Por ejemplo, hay 2 formatos de registro: uno para los sucesos de cortafuegos y uno para los sucesos de autenticación. Debe escribir varios patrones para analizar los sucesos. Puede especificar el orden de análisis. Normalmente, los sucesos más frecuentes se analizan en primer lugar, seguidos de los sucesos menos frecuentes. Puede tener tantos patrones como sean necesarios para analizar todos los sucesos. La variable de orden determina el orden de comparación de los patrones.

El ejemplo siguiente muestra varios formatos para los campos siguientes EventName y UserName

se escriben patrones independientes para analizar cada tipo de registro exclusivo. Se hace referencia a ambos patrones al asignar el valor a los campos normalizados.


<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"/>

Analizar un formato de registro CSV

Para analizar un archivo de registro que está en formato CSV, utilice el tipo de expresión Lista genérica que está disponible en el Editor de DSM. Para obtener más información, consulte Expresiones en formato de lista genérica para datos estructurados (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