Si si punoni me logët e Zimbra OSE

Regjistrimi i të gjitha ngjarjeve që ndodhin është një nga funksionet më të rëndësishme të çdo sistemi korporativ. Logët lejojnë zgjidhjen e problemeve që lindin, kryerjen e auditit të punës së sistemeve informacionit, si dhe hetimin e incidenteve të sigurisë informatike. Zimbra OSE gjithashtu mbledh detaje të hollësishme të punës së saj. Ato përfshijnë të dhëna nga performanca e serverit deri te dërgimi dhe marrja e e-maileve nga përdoruesit. Megjithatë, leximi i logëve të gjeneruar nga Zimbra OSE është një detyrë mjaft e komplikuar. Në këtë artikull, përmes një shembulli konkret, ne do t'ju tregojmë se si të lexoni logët e Zimbra OSE, si dhe si t'i centralizoni ato.

Si si punoni me logët e Zimbra OSE
Të gjitha loget lokale të Zimbra OSE ruhen në dosjen /opt/zimbra/log, ndërsa loget e tjera mund të gjenden në skedarin /var/log/zimbra.log. Më e rëndësishme prej tyre është mailbox.log. Ai regjistron të gjitha veprimet që ndodhin në serverin e postës. Ndër to janë transferimi i e-maileve, të dhënat për autentifikimin e përdoruesve, përpjekjet e pasuksesshme për t'u lidhur dhe të tjera. Shënimet në mailbox.log përbëhen nga një varg tekstual, në të cilin përfshihet koha kur ndodhi ngjarja, niveli i ngjarjes, numri i thread-it nën të cilin ndodhi ngjarja, emri i përdoruesit dhe adresa e tij IP, si dhe përshkrimi tekstual i ngjarjes.

Si si punoni me logët e Zimbra OSE

Niveli i logut tregon gradën e ndikimit të ngjarjes në funksionimin e serverit. Në mënyrë standarde përdoren katër nivele ngjarjesh: INFO, WARN, ERROR dhe FATAL. Do t'i shqyrtojmë të gjitha nivelet sipas rritjes së seriozitetit të tyre.

  • INFO — ngjarjet nĂ« kĂ«tĂ« nivel zakonisht kanĂ« pĂ«r qĂ«llim tĂ« informojnĂ« pĂ«r ecurinĂ« e punĂ«s sĂ« Zimbra OSE. NdĂ«r mesazhet e kĂ«tij niveli janĂ« raportet pĂ«r krijimin ose fshirjen e kutive postare dhe kĂ«shtu me radhĂ«.
  • WARN — ngjarjet e kĂ«tij niveli informojnĂ« pĂ«r situata qĂ« janĂ« potencialisht tĂ« rrezikshme, por nuk ndikojnĂ« nĂ« funksionimin e serverit. Niveli WARN shĂ«non, pĂ«r shembull, njĂ« mesazh pĂ«r njĂ« pĂ«rpjekje tĂ« dĂ«shtuara pĂ«r t'u futur nga pĂ«rdoruesi.
  • ERROR — ky nivel i ngjarjeve nĂ« log informon pĂ«r ndodhinĂ« e njĂ« gabimi, i cili Ă«shtĂ« lokal dhe nuk pengon funksionimin e serverit. NjĂ« gabim tĂ« kĂ«tij niveli mund tĂ« shĂ«nojĂ« njĂ« gabim ku tĂ« dhĂ«nat indeksuese tĂ« njĂ« pĂ«rdoruesi janĂ« dĂ«mtuar.
  • FATAL — ky nivel shĂ«non gabime, pĂ«r shkak tĂ« tĂ« cilave serveri nuk mund tĂ« vazhdojĂ« tĂ« funksionojĂ« normalisht. PĂ«r shembull, niveli FATAL do tĂ« jetĂ« pĂ«r njĂ« regjistrim mbi pamundĂ«sinĂ« pĂ«r t'u lidhur me DBMS.

Skedari me logjet e serverit të postës përditësohet çdo ditë. Versioni i ri i skedarit gjithmonë ka emrin Mailbox.log, ndërsa logjet për një numër të caktuar kanë datën në titull dhe ndodhen në arkiv. Për shembull, mailbox.log.2020-09-29.tar.gz. Kjo e lehtëson ndjeshëm rezervimin e regjistrave dhe kërkimin përmes logjeve.

Për lehtësinë e administratorit të sistemit, në dosjen /opt/zimbra/log/ ndodhen edhe logje të tjera. Aty përfshihen vetëm ato të dhëna që i përkasin elementeve specifikë të Zimbra OSE. Për shembull, në audit.log gjenden vetëm regjistrimet mbi autentikimin e përdoruesve, në clamd.log informacioni mbi funksionimin e antivirusit dhe kështu me radhë. Për më tepër, një metodë e shkëlqyer për të mbrojtur serverin Zimbra OSE nga sulmuesit është mbrojtja e serverit me Fail2Ban, i cili punon në bazë të audit.log. Gjithashtu, një praktikë e mirë është të shtoni një detyrë cron për të ekzekutuar komandën grep -ir "invalid password" /opt/zimbra/log/audit.log, për të marrë informacion çdo ditë mbi rastet e përpjekjeve të dështuara për t'u futurose.

Si si punoni me logët e Zimbra OSE
Shembuj të asaj siç shfaqen dy herë në audit.log fjalëkalimi i gabuar dhe përpjekja e suksesshme për t'u futurose

Logët në Zimbra OSE mund të jenë jashtëzakonisht të dobishme për të zbuluar arsyet e ndryshme për dështimet kritike. Në momentin kur ndodh një gabim kritik, administratori zakonisht nuk ka kohë për të lexuar logët. Kërkohet sa më shpejt që të jetë e mundur rifillimi i punës së serverit. Megjithatë, më vonë, kur serveri përsëri funksionon dhe gjeneron shumë logë, gjetja e regjistrimit të nevojshëm në një skedar të madh mund të jetë e vështirë. Për të gjetur shpejt regjistrimin e gabimit, mjafton të dini orën kur serveri është rinisur dhe të kërkoni në logët për regjistrime të datuara në këtë kohë. Regjistrimi paraardhës do të jetë regjistrimi i gabimit të ndodhur. Gjithashtu, mund të gjeni mesazhin e gabimit duke kërkuar për fjalën kyç FATAL.

Po kështu, logjet e Zimbra OSE lejojnë identifikimin edhe të dështimeve jo kritike. Për shembull, për të gjetur përjashtime të trajtuesit, mund të bëni kërkimin me frazën handler exception. Shpesh, gabimet që gjeneron trajtuesi shoqërohen me një gjurmë të grumbullimit, që shpjegon se çfarë ishte shkaku i shfaqjes së përjashtimit. Në rastin e komplikimeve me dorëzimin e postës, është mirë të filloni kërkimin me fjalën kyçe LmtpServer, ndërsa për të gjetur gabimet e lidhura me protokollet POP ose IMAP, mund të përdorni fjalët kyçe ImapServer dhe Pop3Server.

Të dhënat nga log-et gjithashtu mund të ndihmojnë në hetimin e incidenteve të sigurisë së informacionit. Le të shqyrtojmë një rast konkret. Më 20 Shtator, një nga punonjësit dërgoi një email të infektuar me virus për një klient. Si rezultat, të dhënat në kompjuterin e klientit u koduan. Megjithatë, punonjësi betohet se nuk ka dërguar asgjë. Në kuadër të hetimit të incidentit, shërbimi i sigurisë i ndërmarrjes kërkon nga administratori i sistemit log-et e serverit të postës për 20 Shtator, të lidhura me përdoruesin për të cilin po kryhet hetimi. Falë shenjës temporale, administratori i sistemit gjen skedarin e duhur me log-et, nxjerr informacionin e nevojshëm dhe ia kalon sigurisë. Ata, nga ana e tyre, e shqyrtojnë atë dhe zbulojnë se adresa IP nga e cila ishte dërguar ky email përputhet adresën IP me kompjuterin e përdoruesit. Regjistrimet e kamerave të mbikëqyrjes e konfirmuan se punonjësi gjatë dërgimit të emailit ishte në vendin e tij të punës. Këto të dhëna ishin të mjaftueshme për ta akuzuar atë për shkelje të rregullave të sigurisë së informacionit dhe për ta pushuar nga puna. 

Si si punoni me logët e Zimbra OSE
Shembuj ekstraktimi i regjistrimeve për një nga llogaritë nga logu Mailbox.log në një skedë të veçantë

Gjithçka komplikohet ndjeshĂ«m kur bĂ«het fjalĂ« pĂ«r njĂ« infrastrukturĂ« me shumĂ« serverĂ«. Pasi loget mblidhen lokal, puna me to nĂ«n kushtet e infrastrukturĂ«s multi-server Ă«shtĂ« shumĂ« e papĂ«rshtatshme dhe prandaj lind nevoja pĂ«r centralizimin e mbledhjes sĂ« logeve. KĂ«tĂ« mund ta realizoni duke konfiguruar njĂ« host pĂ«r mbledhjen e logeve. Nuk ka nevojĂ« tĂ« shtoni njĂ« host tĂ« dedikuar nĂ« infrastrukturĂ«. Çdo server i postĂ«s mund tĂ« shĂ«rbejĂ« si njĂ« nyje pĂ«r mbledhjen e logeve. NĂ« rastin tonĂ«, ky do tĂ« jetĂ« nyja Mailstore01.

Në këtë server, ne duhet të futim komandat e mëposhtme:

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

Editoni skedarin /etc/sysconfig/rsyslog dhe vendosni parametrin SYSLOGD_OPTIONS=”-r -c 2″

Editoni /etc/rsyslog.conf dhe ndizni rreshtat e mëposhtëm:
$ModLoad imudp
$UDPServerRun 514

Futni komandat e mëposhtme:

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

Kontrolloni që gjithçka funksionon me komandën zmprov gacf | grep zimbraLogHostname. Pas ekzekutimit të komandës, do të shfaqet emri i hostit që realizon grumbullimin e logeve. Për ta ndryshuar, duhet të futni komandën zmprov mcf zimbraLogHostname mailstore01.company.ru.

Në të gjitha serverat e tjerë të infrastrukturës (LDAP, MTA dhe depo të tjera postare) ekzekutoni komandën zmprov gacf | grep zimbraLogHostname për të parë emrin e hostit ku shkojnë loget. Për ta ndryshuar, mund të futni gjithashtu komandën zmprov mcf zimbraLogHostname mailstore01.company.ru.

Gjithashtu, në çdo server duhet të futni komandat e mëposhtme:

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

Pas kësaj, të gjitha loget do të regjistrohen në serverin që keni specifikuar, ku mund të shihen lehtësisht. Po ashtu, në konsolën e administratorit Zimbra OSE, në ekranin me informacionin mbi gjendjen e serverëve, shërbimi Logger do të shfaqet vetëm në serverin mailstore01.

Si si punoni me logët e Zimbra OSE

Një tjetër dhimbje koke për administratorin mund të bëhet monitorimi i një mesazhi të caktuar elektronik. Duke parë se emailet në Zimbra OSE kalojnë nëpër disa ngjarje të ndryshme: kontrollimi nga antivirus, antispam, dhe kështu me radhë, para se të pranohet ose të dërgohet, për administratorin, në rast se emaili nuk arrin, mund të jetë mjaft problematike të përcaktojë në cilin hap ai është humbur.

Për të zgjidhur këtë problem, mund të përdorni një skript të veçantë, i zhvilluar nga specialisti i sigurisë informative Viktor Duhovny dhe i rekomanduar për përdorim nga zhvilluesit e Postfix. Ky skript konkatenton regjistrimet nga log-et për një proces të caktuar dhe përmes kësaj lejon të shfaqen shpejt të gjitha regjistrimet e lidhura me dërgimin e një emaili në bazë të identifikuesit të tij. Funksionimi i tij është testuar në të gjitha versionet e Zimbra OSE, duke filluar nga 8.7. Po sjellim tekstin e skriptit.

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

Skripti Ă«shtĂ« shkruar nĂ« Perl dhe pĂ«r ta ekzekutuar, duhet ta ruani atĂ« nĂ« njĂ« skedar collate.pl, e bĂ«n atĂ« ekzekutiv, pastaj nisni skedarin me tregimin e skedarit tĂ« logs dhe me ndihmĂ«n e pgrep nxirrni informacionin identifikues tĂ« emailit tĂ« kĂ«rkuar collate.pl /var/log/zimbra.log | pgrep ‘’. Rezultati do tĂ« jetĂ« njĂ« renditje e radhĂ«s sĂ« rreshtave qĂ« pĂ«rmbajnĂ« informacionin mbi lĂ«vizjen e emailit nĂ« server.

# collate.pl /var/log/zimbra.log | pgrep '<20200929101700.user@mail.company.ru>'
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

Për çdo pyetje lidhur me Zextras Suite, mund të kontaktoni përfaqësuesen e kompanisë «Zextras», Ekaterina Triandafiliidi në e-mail katerina@zextras.com

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster