Identificando cuentas de correo comprometidas en zimbra con GrayLog

main

A partir del año pasado volví a administrar servidores zimbra después de 4 años de inactividad con esta suite colaborativa. Pese a ello la última versión que había usado en 2012 era la 7.1.3 y la última versión estable liberada en 2016 que hice la instalación era la 8.6.

 

El entorno en el cual desplegué la suite esta vez fue centralizado, con autenticación LDAP y más de 300 cuentas de correo.

Un problema recurrente en este entorno en que no administro las políticas de seguridad de algunos de los servidores LDAP es encontrarme con cuentas de correo comprometidas por dominios (AD) sin seguridad de contraseñas habilitada.

En este tipo de casos es vital que el tiempo entre el cual una cuenta es comprometida, y él momento cuando se tomen acciones correctivas sea el mínimo, esto para evitar consecuencias como enlistamientos permanentes y otras medidas que tomen los destinatarios del SPAM y entidades que vigilan (o monitorean) el tráfico de correo en internet.

Algunas medidas que tomé anteriormente a graylog fueron:

  • Habilitar el módulo de zimbra zmauditswatch para recibir notificaciones cuando se produjeran N cantidad de intentos de autenticación fallida en cuentas. El problema con esto es que cuando una cuenta estaba comprometida la autenticación no fallaba, los spammers tenían la contraseña correcta, así que no obtenía ninguna alerta a menos que la contraseña de la cuenta expirara y los envíos automatizados empezaran a fallar.
  • Solicitar al administrador de los dominios LDAP sin seguridad de contraseña habilitada que forzara parámetros para robustecer las políticas de sus cuentas pero esta opción se salía de mis manos y no obtuve respuesta a tiempo. El detalle con esto es que la reputación de todos los dominios pendía del mismo IP público así que pagaban “justos por pecadores” o  pagaban admins usando buenas prácticas por admins descuidados.
  • Intentar parametrizar ClueBringer PolicyD para controlar el volumen de correo saliente por cuenta. Este todavía variaba mucho por cada cuenta por lo que no estaba ajustado “idealmente” cuando conocí a graylog-server.

Entiendo que hay varias opciones de parseadores de logs en el mercado pero después de leer algunas publicaciones con comparativos entre herramientas para almacenar y analizar estas bitácoras, muchos me dirigieron a esa herramienta basada en Java, ElasticSearch y MongoDB.

La configuración para enviar logs desde un servidor linux y como recibirla en un “input” en el servidor graylog está documentada acá.

En el caso del servidor zimbra envié todo (*.* en mi rsyslog.conf) y luego identifiqué los tipos de mensajes de Postfix cuando se presentan los envíos masivos automatizados que son típicos de casos con cuentas comprometidas:

  • Excesivos rebotes de correo: En mushos casos estos envíos usan algunos cuentas de correos inexistentes o inactivas por lo que se presentan más rebotes de lo normal. Para este caso se puede filtrar “status=bounced”
  • Conexiones rechazadas (refused): Rechazados con códigos de error SMTP 421 o 554 son comunes como acciones instantáneas tomadas por destinatarios de ataques dirigidos. En este caso filtro “refused to talk to me” o los códigos de error anteriormente mencionados con el lenguaje de consulta de graylog: 
  • search
  • Excesivos fallos de autenticación: Estos se presentan cuando ya se tomaron las medidas correctivas de bloquear una cuenta, o por cambio de la contraseña ya se por expiración o por cambio manual. En este caso se pueden fitrar distintas frases como “authentication failed for” o “authentication failure” o bien combinación de distintas.

 

histogram

 

En este dashboard se puede hacer un comparativo en línea de tiempo del momento en que hay acceso a la cuenta (histograma de arriba) versus las autenticación fallidas (histograma de abajo) en el que se llega a tener hasta 302 intentos fallidos por hora. (común cuando los spammers encuentran oro) .

Lo que resta es configurar alertas cuando se presenten las distintas condiciones que queremos monitorear.

Otros links de interés:

http://sudotoolbox.com/how-to-find-compromised-id-in-zimbra/

Anuncios
1 comentario

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s

A %d blogueros les gusta esto: