Sistema de excepciones para el motor de análisis de contenido Kandadu

[francisco.lopez]

1. Introducción

Kandadu proporciona un sistema de excepción general que permite desactivar las respuestas de rechazo y de Smart GLD para ciertos destinos y orígenes.

El funcionamiento general es el siguiente:

• Kandadu genera códigos de respuesta en función de las reglas y configuraciones que pueden ser REJECT/BLOCKED, SCORED y también TEMPORAL-REJECT.

• El sistema de excepción permite transformar dichas respuestas, para ciertos casos, en códigos DUNNO.

  En esencia, el sistema de excepciones permite tener un plano de configuración general y para ciertos casos, desactivarlo, dando la flexibilidad necesaria para adaptarse a distintas condiciones de seguridad.

Cómo configurar una excepción de motor

1. Dentro de del HUB que esté controlando al usuario, destino, dominio o servidor afectado, pinchar en el apartado de gestión de excepciones y añadimos:

   

2. Dentro introduciremos una etiqueta para identificar mejor la excepción y también el selector que encajará tráfico dentro de transacciones (más abajo, dejamos distintos ejemplos):

   

3. Una vez creada la excepción, nos permitirá configurar qué parte queremos excepcionar. En este caso, desactivaremos las respuestas de Smart GLD y de Rechazo:

   

4. De manera que tras esto, quedaría del siguiente modo:

   

2. Cómo comprobar que la excepción está en marcha

Podemos comprobar cómo encajan el conjunto de las excepciones para ejemplos de tráfico concreto. Para ello:

1. Pinchamos en la herramienta de comprobación de excepciones:

   

2. Nos aparecerá la siguiente pantalla donde podremos especificar elementos del tipo de tráfico para buscar posibles excepciones que encajen (2). Opcionalmente, se puede indicar el objeto en particular que sería revisado por Kandadu.

Como se puede ver hay dos parte a la hora de comprobar si las excepciones añadidas encajan con lo que buscamos:

• La parte importante: describir para quién será el tráfico. Esto se hace indicando los datos que consideremos relevantes en “Especificación del tráfico”.

• Opcionalmente también se puede indicar qué tráfico en particular se quiere encajar con la regla. En la mayoría de los casos esto se puede dejar vacío.

  

3. Siguiendo el ejemplo, si queremos ver si encaja el selector que hemos introducido en las secciones anteriores, simplemente comprobamos del siguiente modo:

   

En el ejemplo anterior, vemos que para el tráfico con destino a this.user@hotmail.com, se activaría la excepción que hemos añadido, y por tanto, no se aplicaría Smart GLD ni Rechazo aun cuando se encuentren reglas que indiquen ese sentido.

3. Cómo comprobar las reglas de excepción con el cliente kandadu-cli.py

Para comprobar si un tráfico será marcado como REJECT/BLOCKED*, SCORED o TEMPORAL-REJECT podemos usar las siguientes opciones para indicar a qué transacción pertene cierto tráfico comprobado:

$ kandadu-cli.py -c element-to-check.com --destination=some.account@hotmail.com

En este caso, en lugar de simplemente comprobar con (kandadu-cli.py -c element-to-check.com), añadimos indicación de que la comprobación se produce en el contexto de tráfico con destino a la cuenta indicada.

Existen otros indicadores de tráfico que se pueden usar de manera individual o combinarse todos ellos para especificar aún más la transacción:

# opciones de especificación de transacción para kandadu-cli.py:
--destination=   : destino del tráfico (cuenta de correo, url, ip o dominio)
--sender= : origen del tráfico (cuenta de correo, url, ip or dominio)
--source=  : ip de origen del tráfico del último salto
--context=  : contexto en el que se produjo la consulta (más adelante sobre esto)
--protocol= : tipo de protocolo usado donde se produce el tráfico

4. Ejemplos de excepciones

A continuación se muestran una serie de ejemplo para configurar excepciones en distintos casos conocidos.

1. Desactivar Smart GLD y Rechazo para el tráfico recibido para cierta cuenta:

   Selector: disabled:cuenta.de.correo@dominio.com
   Activar ignorar GLD: Yes
   Activar ignorar Rechazo: Yes

   Esto desactivará la protección Kandadu para todo el tráfico recibido para esta cuenta al no haber rechazo ni GLD.

2. Desactivar Smart GLD y Rechazo para el tráfico recibido para cierto dominio:

   Selector: disabled:dominio.com
   Activar ignorar GLD: Yes
   Activar ignorar Rechazo: Yes

   Esto desactivará la protección Kandadu para todo el tráfico recibido para todas las cuentas y sistemas bajo el dominio dominio.com.

3. Desactivar Smart GLD y Rechazo para el tráfico recibido para todo un servidor con Kandadu Agent:

   Selector: token:nombre-del-servidor
   Activar ignorar GLD: Yes
   Activar ignorar Rechazo: Yes

   Esto desactivará la protección Kandadu para todo el tráfico recibido con destino al servidor indicado, lo que incluye todos los dominios, cuentas y webs en dicho servidor.

5. Referencia de selectores soportados

1. context:authenticated-user : encaja transacciones de usuarios autenticados en cualquier protocolo.

2. context:authenticated-smtp-user : encaja transacciones de usuarios authenticados en protocolo SMTP.

3. context:<app-context>: selector genérico para contextos definidos por las aplicaciones consumiendo el API de Kandadu. Estos contextos definen etapas dentro de la aplicación y son definidos por los emisores de consulta y que consumen el API de kandadu.

   A continuación se indican contextos conocidos y usados por Arachnida:

   • context:helo : selecciona las transacciones que ocurren en la fase HELO del SMTP.
   • context:headers : selecciona las transacciones que ocurren al comprobar las cabeceras de un correo.
   • context:all : selecciona las transacciones que ocurren al comprobar el contenido de un correo.

4. protocol:<protocol-name> : selector genérico para identificar todas las transacciones que ocurren bajo cierto protocolo de comunicaciones (smtp, http, ftp).

5. source:<ip,redes>: selector para encajar una IP o redes desde donde se recibió el tráfico de la transacción.

6. sender:<email,domain,subdomain> : selector genérico para identificar transacciones encajando con la dirección de correo o con el dominio o subdominio indicado y que identifica al remitente. En el caso de indicar como dominio: dominio.com entonces se encajará todo el tráfico de tipo cuenta.correo@dominio.com o subdominio.dominio.com, ltr1.server.dominio.com, etc.

7. destination:<email,domain,subdomain>: selector genérico para identificar transacciones encajando con la dirección de correo o con el dominio o subdominio indicado y que identifica al destinatario del tráfico. En el caso de indicar como dominio: dominio.com entonces se encajará todo el tráfico de tipo cuenta.correo@dominio.com o subdominio.dominio.com, ltr1.server.dominio.com, etc.

   Nota: el selector disabled: permite encajar tanto el tráfico que encajaría destination: más el tráfico que encajaría el selector auth-user: o ${protocol}-auth-user: (por ejemplo: smtp-auth-user:), todo ello bajo un mismo selector.

8. disabled:<email,domain,subdomain>: selector genérico para identificar transacciones encajando el destino o usuario autenticado saliente, con la dirección de correo o con el dominio o subdominio indicado y que identifica al destinatario del tráfico pero también el tráfico originado de manera autenticada y originada por dicho dominio.

   En el caso de indicar como dominio: dominio.com entonces se encajará todo el tráfico de tipo cuenta.correo@dominio.com o subdominio.dominio.com, ltr1.server.dominio.com, etc que se origine en salida como usuario autenticado con dichas cuentas o dominio y el tráfico con destino a dichas cuentas o dominios.

   Aliases: es posible configurar directamente dominio.com y email@dominio.com como selectores válidos. En tal caso, el sistema los detectará y lo cargará como disabled:dominio.com y disabled:email@dominio.com respectivamente.

9. token:<token-short-name>: selector genérico para identificar todas transacciones que vengan de determinado agente, autenticando y ejecutando bajo el token de agente indicado (short-name). Este selector es el indicado para seleccionar todo el tráfico que entra y sale de un servidor o conjunto de servidores conectados al agente Kandadu identificado por el token short-name que se indique.