Cómo trabajar con los registros de Zimbra OSE

El registro de todos los eventos que ocurren es una de las funciones más importantes de cualquier sistema corporativo. Los registros le permiten resolver problemas emergentes, auditar el funcionamiento de los sistemas de información y también investigar incidentes de seguridad de la información. Zimbra OSE también mantiene registros detallados de su funcionamiento. Incluyen todos los datos, desde el rendimiento del servidor hasta el envío y recepción de correos electrónicos por parte de los usuarios. Sin embargo, leer los registros generados por Zimbra OSE no es una tarea trivial. En este artículo, utilizando un ejemplo específico, le diremos cómo leer los registros de Zimbra OSE, así como cómo centralizarlos.

Cómo trabajar con los registros de Zimbra OSE
Zimbra OSE almacena todos los registros locales en la carpeta /opt/zimbra/log, y los registros también se pueden encontrar en el archivo /var/log/zimbra.log. El más importante de ellos es mailbox.log. Registra todas las acciones que ocurren en el servidor de correo. Estos incluyen la transmisión de correos electrónicos, datos de autenticación de usuarios, intentos fallidos de inicio de sesión y otros. Las entradas en mailbox.log son una cadena de texto que contiene la hora a la que ocurrió el evento, el nivel del evento, el número de hilo en el que ocurrió el evento, el nombre de usuario y la dirección IP, así como una descripción de texto del evento. .

Cómo trabajar con los registros de Zimbra OSE

El nivel de registro indica el grado de influencia del evento en el funcionamiento del servidor. Por defecto hay 4 niveles de eventos: INFORMACIÓN, ADVERTENCIA, ERROR y FATAL. Veamos todos los niveles en orden creciente de gravedad.

  • INFORMACIÓN: los eventos de este nivel suelen tener como objetivo informar sobre el progreso de Zimbra OSE. Los mensajes de este nivel incluyen informes sobre la creación o eliminación de un buzón, etc.
  • ADVERTENCIA: los eventos de este nivel informan sobre situaciones que son potencialmente peligrosas, pero no afectan el funcionamiento del servidor. Por ejemplo, el nivel WARN marca un mensaje sobre un intento fallido de inicio de sesión de un usuario.
  • ERROR: este nivel de evento en el registro informa sobre la aparición de un error que es de naturaleza local y no interfiere con el funcionamiento del servidor. Este nivel puede señalar un error en el que los datos del índice de un usuario individual se han dañado.
  • FATAL: este nivel indica errores por los cuales el servidor no puede continuar funcionando normalmente. Por ejemplo, el nivel FATAL será para un registro que indique la imposibilidad de conectarse al DBMS.

El archivo de registro del servidor de correo se actualiza todos los días. La última versión del archivo siempre tiene el nombre Mailbox.log, mientras que los registros de una fecha determinada tienen una fecha en el nombre y están contenidos en el archivo. Por ejemplo mailbox.log.2020-09-29.tar.gz. Esto hace que sea mucho más fácil realizar copias de seguridad de los registros de actividad y buscar entre ellos.

Para comodidad del administrador del sistema, la carpeta /opt/zimbra/log/ contiene otros registros. Solo incluyen entradas que se relacionan con elementos específicos de Zimbra OSE. Por ejemplo, audit.log contiene solo registros sobre la autenticación del usuario, clamd.log contiene datos sobre el funcionamiento del antivirus, etc. Por cierto, un método excelente para proteger un servidor Zimbra OSE de intrusos es protección del servidor usando Fail2Ban, que simplemente funciona según audit.log. También es una buena práctica agregar una tarea cron para ejecutar el comando. grep -ir "contraseña no válida" /opt/zimbra/log/audit.logpara recibir información diaria sobre fallas de inicio de sesión.

Cómo trabajar con los registros de Zimbra OSE
Un ejemplo de cómo audit.log muestra una contraseña ingresada dos veces incorrectamente y un intento de inicio de sesión exitoso.

Los registros en Zimbra OSE pueden resultar extremadamente útiles para identificar las causas de diversas fallas críticas. En el momento en que ocurre un error crítico, el administrador generalmente no tiene tiempo para leer los registros. Es necesario restaurar el servidor lo antes posible. Sin embargo, más adelante, cuando el servidor realiza una copia de seguridad y genera muchos registros, puede resultar difícil encontrar la entrada requerida en un archivo grande. Para encontrar rápidamente un registro de error, basta con saber la hora a la que se reinició el servidor y encontrar una entrada en los registros que data de esa hora. La entrada anterior será un registro del error ocurrido. También puede encontrar el mensaje de error buscando la palabra clave FATAL.

Los registros de Zimbra OSE también le permiten identificar fallas no críticas. Por ejemplo, para buscar excepciones del controlador, puede buscar excepciones del controlador. A menudo, los errores generados por los controladores van acompañados de un seguimiento de la pila que explica qué causó la excepción. En caso de errores con la entrega de correo, debe comenzar su búsqueda con la palabra clave LmtpServer, y para buscar errores relacionados con los protocolos POP o IMAP, puede utilizar las palabras clave ImapServer y Pop3Server.

Los registros también pueden ayudar a la hora de investigar incidentes de seguridad de la información. Veamos un ejemplo específico. El 20 de septiembre, uno de los empleados envió una carta infectada con el virus a un cliente. Como resultado, se cifraron los datos en la computadora del cliente. Sin embargo, el empleado jura que no envió nada. Como parte de la investigación del incidente, el servicio de seguridad empresarial solicita al administrador del sistema los registros del servidor de correo del 20 de septiembre asociados con el usuario investigado. Gracias a la marca de tiempo, el administrador del sistema encuentra el archivo de registro necesario, extrae la información necesaria y la transfiere a los especialistas en seguridad. Estos, a su vez, lo revisan y descubren que la dirección IP desde la que se envió esta carta corresponde a la dirección IP de la computadora del usuario. Las imágenes de CCTV confirmaron que el empleado estaba en su lugar de trabajo cuando se envió la carta. Estos datos fueron suficientes para acusarlo de violar las reglas de seguridad de la información y despedirlo. 

Cómo trabajar con los registros de Zimbra OSE
Un ejemplo de extracción de registros sobre una de las cuentas del registro Mailbox.log en un archivo separado

Todo se vuelve mucho más complicado cuando se trata de infraestructura multiservidor. Dado que los registros se recopilan localmente, trabajar con ellos en una infraestructura de múltiples servidores es muy inconveniente y, por lo tanto, es necesario centralizar la recopilación de registros. Esto se puede hacer configurando un host para recopilar registros. No existe una necesidad particular de agregar un host dedicado a la infraestructura. Cualquier servidor de correo puede actuar como nodo para recopilar registros. En nuestro caso, este será el nodo Mailstore01.

En este servidor necesitamos ingresar los siguientes comandos:

sudo su – zimbra 
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -v

Edite el archivo /etc/sysconfig/rsyslog y configure SYSLOGD_OPTIONS=”-r -c 2″

Edite /etc/rsyslog.conf y descomente las siguientes líneas:
$ModLoad imudp
$UDPServerRun 514

Ingrese los siguientes comandos:

sudo /etc/init.d/rsyslog stop
sudo /etc/init.d/rsyslog start
sudo su – zimbra
zmcontrol start
exit
sudo /opt/zimbra/libexec/zmloggerinit
sudo /opt/zimbra/bin/zmsshkeygen
sudo /opt/zimbra/bin/zmupdateauthkeys

Puedes comprobar que todo funciona usando el comando zmprov gacf | grep zimbraLogHostname. Después de ejecutar el comando, se debe mostrar el nombre del host que recopila los registros. Para cambiarlo, debe ingresar el comando zmprov mcf zimbraLogHostname mailstore01.company.ru.

En todos los demás servidores de infraestructura (LDAP, MTA y otros almacenes de correo), ejecute el comando zmprov gacf |grep zimbraLogHostname para ver el nombre del host al que se envían los registros. Para cambiarlo, también puede ingresar el comando zmprov mcf zimbraLogHostname mailstore01.company.ru

También debe ingresar los siguientes comandos en cada servidor:

sudo su - zimbra
/opt/zimbra/bin/zmsshkeygen
/opt/zimbra/bin/zmupdateauthkeys
exit
sudo /opt/zimbra/libexec/zmsyslogsetup
sudo service rsyslog restart
sudo su - zimbra
zmcontrol restart

Después de esto, todos los registros se grabarán en el servidor que especificó, donde se podrán ver cómodamente. Además, en la consola de administrador de Zimbra OSE, en la pantalla con información sobre el estado de los servidores, se mostrará el servicio Logger en ejecución solo para el servidor mailstore01.

Cómo trabajar con los registros de Zimbra OSE

Otro dolor de cabeza para un administrador puede ser realizar un seguimiento de un correo electrónico específico. Dado que los correos electrónicos en Zimbra OSE pasan por varios eventos diferentes a la vez: escaneo por antivirus, antispam, etc., antes de ser aceptados o enviados, para el administrador, si el correo electrónico no llega, puede resultar bastante problemático rastrear en qué etapa se perdió.

Para resolver este problema, puede utilizar un script especial desarrollado por el especialista en seguridad de la información Viktor Dukhovny y recomendado por los desarrolladores de Postfix. Este script concatena entradas de registros para un proceso específico y, debido a esto, le permite mostrar rápidamente todas las entradas asociadas con el envío de una carta en particular según su identificador. Su trabajo ha sido probado en todas las versiones de Zimbra OSE, a partir de la 8.7. Aquí está el texto del guión.

#! /usr/bin/perl

use strict;
use warnings;

# Postfix delivery agents
my @agents = qw(discard error lmtp local pipe smtp virtual);

my $instre = qr{(?x)
	A			# Absolute line start
	(?:S+ s+){3} 		# Timestamp, adjust for other time formats
	S+ s+ 		# Hostname
	(postfix(?:-[^/s]+)?)	# Capture instance name stopping before first '/'
	(?:/S+)*		# Optional non-captured '/'-delimited qualifiers
	/			# Final '/' before the daemon program name
	};

my $cmdpidre = qr{(?x)
	G			# Continue from previous match
	(S+)[(d+)]:s+	# command[pid]:
};

my %smtpd;
my %smtp;
my %transaction;
my $i = 0;
my %seqno;

my %isagent = map { ($_, 1) } @agents;

while (<>) {
	next unless m{$instre}ogc; my $inst = $1;
	next unless m{$cmdpidre}ogc; my $command = $1; my $pid = $2;

	if ($command eq "smtpd") {
		if (m{Gconnect from }gc) {
			# Start new log
			$smtpd{$pid}->{"log"} = $_; next;
		}

		$smtpd{$pid}->{"log"} .= $_;

		if (m{G(w+): client=}gc) {
			# Fresh transaction 
			my $qid = "$inst/$1";
			$smtpd{$pid}->{"qid"} = $qid;
			$transaction{$qid} = $smtpd{$pid}->{"log"};
			$seqno{$qid} = ++$i;
			next;
		}

		my $qid = $smtpd{$pid}->{"qid"};
		$transaction{$qid} .= $_
			if (defined($qid) && exists $transaction{$qid});
		delete $smtpd{$pid} if (m{Gdisconnect from}gc);
		next;
	}

	if ($command eq "pickup") {
		if (m{G(w+): uid=}gc) {
			my $qid = "$inst/$1";
			$transaction{$qid} = $_;
			$seqno{$qid} = ++$i;
		}
		next;
	}

	# bounce(8) logs transaction start after cleanup(8) already logged
	# the message-id, so the cleanup log entry may be first
	#
	if ($command eq "cleanup") {
		next unless (m{G(w+): }gc);
		my $qid = "$inst/$1";
		$transaction{$qid} .= $_;
		$seqno{$qid} = ++$i if (! exists $seqno{$qid});
		next;
	}

	if ($command eq "qmgr") {
		next unless (m{G(w+): }gc);
		my $qid = "$inst/$1";
		if (defined($transaction{$qid})) {
			$transaction{$qid} .= $_;
			if (m{Gremoved$}gc) {
				print delete $transaction{$qid}, "n";
			}
		}
		next;
	}

	# Save pre-delivery messages for smtp(8) and lmtp(8)
	#
	if ($command eq "smtp" || $command eq "lmtp") {
		$smtp{$pid} .= $_;

		if (m{G(w+): to=}gc) {
			my $qid = "$inst/$1";
			if (defined($transaction{$qid})) {
				$transaction{$qid} .= $smtp{$pid};
			}
			delete $smtp{$pid};
		}
		next;
	}

	if ($command eq "bounce") {
		if (m{G(w+): .*? notification: (w+)$}gc) {
			my $qid = "$inst/$1";
			my $newid = "$inst/$2";
			if (defined($transaction{$qid})) {
				$transaction{$qid} .= $_;
			}
			$transaction{$newid} =
				$_ . $transaction{$newid};
			$seqno{$newid} = ++$i if (! exists $seqno{$newid});
		}
		next;
	}

	if ($isagent{$command}) {
		if (m{G(w+): to=}gc) {
			my $qid = "$inst/$1";
			if (defined($transaction{$qid})) {
				$transaction{$qid} .= $_;
			}
		}
		next;
	}
}

# Dump logs of incomplete transactions.
foreach my $qid (sort {$seqno{$a} <=> $seqno{$b}} keys %transaction) {
    print $transaction{$qid}, "n";
}

El script está escrito en Perl y para ejecutarlo es necesario guardarlo en un archivo. cotejar.pl, hágalo ejecutable y luego ejecute el archivo especificando el archivo de registro y usando pgrep para extraer la información de identificación de la letra que está buscando. collate.pl /var/log/zimbra.log | pgrep'[email protected]>'. El resultado será una salida secuencial de líneas que contienen información sobre el movimiento de la carta en el servidor.

# collate.pl /var/log/zimbra.log | pgrep '<[email protected]>'
Oct 13 10:17:00 mail postfix/pickup[4089]: 4FF14284F45: uid=1034 from=********
Oct 13 10:17:00 mail postfix/cleanup[26776]: 4FF14284F45: message-id=*******
Oct 13 10:17:00 mail postfix/qmgr[9946]: 4FF14284F45: from=********, size=1387, nrcpt=1 (queue active)
Oct 13 10:17:00 mail postfix/smtp[7516]: Anonymous TLS connection established to mail.*******[168.*.*.4]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Oct 13 10:17:00 mail postfix/smtp[7516]: 4FF14284F45: to=*********, relay=mail.*******[168.*.*.4]:25, delay=0.25, delays=0.02/0.02/0.16/0.06, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 878833424CF)
Oct 13 10:17:00 mail postfix/qmgr[9946]: 4FF14284F45: removed
Oct 13 10:17:07 mail postfix/smtpd[21777]: connect from zimbra.******[168.*.*.4]
Oct 13 10:17:07 mail postfix/smtpd[21777]: Anonymous TLS connection established from zimbra.******[168.*.*.4]: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Oct 13 10:17:08 mail postfix/smtpd[21777]: 0CB69282F4E: client=zimbra.******[168.*.*.4]
Oct 13 10:17:08 mail postfix/cleanup[26776]: 0CB69282F4E: message-id=zimbra.******
Oct 13 10:17:08 mail postfix/qmgr[9946]: 0CB69282F4E: from=zimbra.******, size=3606, nrcpt=1 (queue active)
Oct 13 10:17:08 mail postfix/virtual[5291]: 0CB69282F4E: to=zimbra.******, orig_to=zimbra.******, relay=virtual, delay=0.03, delays=0.02/0/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
Oct 13 10:17:08 mail postfix/qmgr[9946]: 0CB69282F4E: removed

Para todas las preguntas relacionadas con Zextras Suite, puede comunicarse con el Representante de Zextras Ekaterina Triandafilidi por correo electrónico [email protected]

Fuente: habr.com