Hur man arbetar med Zimbra OSE-loggar

Loggning av alla inträffade händelser är en av de viktigaste funktionerna i alla företagssystem. Loggar låter dig lösa nya problem, granska hur informationssystem fungerar och även undersöka informationssäkerhetsincidenter. Zimbra OSE för också detaljerade loggar över sin verksamhet. De inkluderar all data från serverprestanda till att skicka och ta emot e-post från användare. Men att läsa loggarna som genereras av Zimbra OSE är en ganska icke-trivial uppgift. I den här artikeln, med hjälp av ett specifikt exempel, kommer vi att berätta hur du läser Zimbra OSE-loggar, samt hur du gör dem centraliserade.

Hur man arbetar med Zimbra OSE-loggar
Zimbra OSE lagrar alla lokala loggar i mappen /opt/zimbra/log, och loggar kan också hittas i filen /var/log/zimbra.log. Den viktigaste av dessa är mailbox.log. Den registrerar alla åtgärder som sker på e-postservern. Dessa inkluderar överföring av e-postmeddelanden, användarautentiseringsdata, misslyckade inloggningsförsök och annat. Inlägg i mailbox.log är en textsträng som innehåller tidpunkten då händelsen inträffade, nivån på händelsen, trådnumret där händelsen inträffade, användarnamn och IP-adress, samt en textbeskrivning av händelsen .

Hur man arbetar med Zimbra OSE-loggar

Loggnivån anger graden av påverkan av händelsen på serverns drift. Som standard finns det 4 händelsenivåer: INFO, VARNING, ERROR och FATAL. Låt oss titta på alla nivåer i ökande svårighetsgrad.

  • INFO - Evenemang på denna nivå är vanligtvis avsedda att informera om utvecklingen av Zimbra OSE. Meddelanden på den här nivån inkluderar rapporter om skapandet eller raderingen av en brevlåda och så vidare.
  • VARNING - händelser på denna nivå informerar om situationer som är potentiellt farliga, men som inte påverkar driften av servern. Till exempel markerar WARN-nivån ett meddelande om ett misslyckat inloggningsförsök.
  • FEL - denna händelsenivå i loggen informerar om förekomsten av ett fel som är lokalt till sin natur och som inte stör serverns drift. Denna nivå kan flagga ett fel där en enskild användares indexdata har blivit korrupta.
  • FATAL - denna nivå indikerar fel på grund av vilka servern inte kan fortsätta att fungera normalt. Till exempel kommer FATAL-nivån att vara för en post som indikerar oförmågan att ansluta till DBMS.

E-postserverns loggfil uppdateras varje dag. Den senaste versionen av filen har alltid namnet Mailbox.log, medan loggar för ett visst datum har ett datum i namnet och finns i arkivet. Till exempel mailbox.log.2020-09-29.tar.gz. Detta gör det mycket lättare att säkerhetskopiera aktivitetsloggar och söka igenom loggar.

För att underlätta för systemadministratören innehåller mappen /opt/zimbra/log/ andra loggar. De inkluderar endast poster som relaterar till specifika Zimbra OSE-element. Till exempel innehåller audit.log endast poster om användarverifiering, clamd.log innehåller data om hur antiviruset fungerar och så vidare. Förresten, en utmärkt metod för att skydda en Zimbra OSE-server från inkräktare är serverskydd med Fail2Ban, som bara fungerar baserat på audit.log. Det är också bra att lägga till en cron-uppgift för att utföra kommandot grep -ir "ogiltigt lösenord" /opt/zimbra/log/audit.logför att få daglig information om inloggningsfel.

Hur man arbetar med Zimbra OSE-loggar
Ett exempel på hur audit.log visar ett felaktigt inmatat lösenord två gånger och ett lyckat inloggningsförsök.

Loggar i Zimbra OSE kan vara extremt användbara för att identifiera orsakerna till olika kritiska fel. I det ögonblick då ett kritiskt fel inträffar har administratören vanligtvis inte tid att läsa loggarna. Det krävs att servern återställs så snart som möjligt. Men senare, när servern säkerhetskopieras och genererar många loggar, kan det vara svårt att hitta den nödvändiga posten i en stor fil. För att snabbt hitta en felpost räcker det att veta när servern startades om och hitta en post i loggarna från denna tidpunkt. Den föregående posten kommer att vara en registrering av felet som uppstod. Du kan också hitta felmeddelandet genom att söka på nyckelordet FATAL.

Zimbra OSE-loggar låter dig också identifiera icke-kritiska fel. För att till exempel hitta hanterarundantag kan du söka efter hanterarundantag. Ofta åtföljs fel som genereras av hanterare av en stackspårning som förklarar vad som orsakade undantaget. Vid fel med postleverans bör du börja din sökning med nyckelordet LmtpServer, och för att söka efter fel relaterade till POP- eller IMAP-protokollen kan du använda nyckelorden ImapServer och Pop3Server.

Loggar kan också vara till hjälp när man utreder informationssäkerhetsincidenter. Låt oss titta på ett specifikt exempel. Den 20 september skickade en av de anställda ett virusinfekterat brev till en klient. Som ett resultat av detta krypterades data på klientens dator. Den anställde svär dock att han inte skickat något. Som en del av utredningen av incidenten begär företagssäkerhetstjänsten från systemadministratören e-postserverloggarna för den 20 september kopplade till användaren som utreds. Tack vare tidsstämpeln hittar systemadministratören den nödvändiga loggfilen, extraherar nödvändig information och överför den till säkerhetsspecialister. De i sin tur tittar igenom det och finner att IP-adressen som detta brev skickades från motsvarar IP-adressen för användarens dator. CCTV-filmer bekräftade att den anställde var på sin arbetsplats när brevet skickades. Dessa uppgifter räckte för att anklaga honom för att bryta mot reglerna för informationssäkerhet och sparka honom. 

Hur man arbetar med Zimbra OSE-loggar
Ett exempel på att extrahera poster om ett av kontona från Mailbox.log-loggningen till en separat fil

Allt blir mycket mer komplicerat när det kommer till multi-server infrastruktur. Eftersom loggar samlas in lokalt är det mycket obekvämt att arbeta med dem i en infrastruktur med flera servrar och därför finns det ett behov av att centralisera insamlingen av loggar. Detta kan göras genom att ställa in en värd för att samla in loggar. Det finns inget särskilt behov av att lägga till en dedikerad värd till infrastrukturen. Vilken e-postserver som helst kan fungera som en nod för att samla in loggar. I vårt fall kommer detta att vara Mailstore01-noden.

På denna server måste vi ange följande kommandon:

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

Redigera filen /etc/sysconfig/rsyslog och ställ in SYSLOGD_OPTIONS=”-r -c 2″

Redigera /etc/rsyslog.conf och avkommentera följande rader:
$ModLoad imudp
$UDPServerRun 514

Ange följande kommandon:

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

Du kan kontrollera att allt fungerar med kommandot zmprov gacf | grep zimbraLogHostname. Efter att ha utfört kommandot ska namnet på värden som samlar in loggar visas. För att ändra det måste du ange kommandot zmprov mcf zimbraLogHostname mailstore01.company.ru.

På alla andra infrastrukturservrar (LDAP, MTA och andra e-postbutiker), kör kommandot zmprov gacf |grep zimbraLogHostname för att se namnet på den värd som loggarna skickas till. För att ändra det kan du också ange kommandot zmprov mcf zimbraLogHostname mailstore01.company.ru

Du måste också ange följande kommandon på varje server:

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

Efter detta kommer alla loggar att registreras på den server du angav, där de enkelt kan ses. I Zimbra OSE-administratörskonsolen, på skärmen med information om servrarnas status, kommer den pågående Logger-tjänsten att visas endast för mailstore01-servern.

Hur man arbetar med Zimbra OSE-loggar

En annan huvudvärk för en administratör kan vara att hålla reda på ett specifikt e-postmeddelande. Eftersom e-postmeddelanden i Zimbra OSE går igenom flera olika händelser samtidigt: skanning med antivirus, antispam och så vidare, innan de accepteras eller skickas, för administratören, om e-postmeddelandet inte kommer fram, kan det vara ganska problematiskt att spåra i vilket skede det var förlorat.

För att lösa detta problem kan du använda ett speciellt skript, som utvecklats av informationssäkerhetsspecialisten Viktor Dukhovny och rekommenderas för användning av Postfix-utvecklare. Detta skript sammanfogar poster från loggar för en specifik process och, på grund av detta, låter dig snabbt visa alla poster som är kopplade till att skicka ett visst brev baserat på dess identifierare. Dess arbete har testats på alla versioner av Zimbra OSE, från och med 8.7. Här är texten till manuset.

#! /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";
}

Skriptet är skrivet i Perl och för att köra det måste du spara det i en fil collate.pl, gör den körbar och kör sedan filen som anger loggfilen och använd pgrep för att extrahera identifieringsinformationen för bokstaven du letar efter collate.pl /var/log/zimbra.log | pgrep '[e-postskyddad]>'. Resultatet blir en sekventiell utmatning av rader som innehåller information om rörelsen av bokstaven på servern.

# 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

För alla frågor relaterade till Zextras Suite kan du kontakta representanten för Zextras Ekaterina Triandafilidi via e-post [e-postskyddad]

Källa: will.com