Како да работите со логовите на Zimbra OSE

Евидентирањето на сите настани е една од најважните функции на секој корпоративен систем. Дневниците ви овозможуваат да ги решите новите проблеми, да ја ревидирате работата на информациските системи, а исто така да истражувате инциденти за безбедноста на информациите. Zimbra OSE исто така води детални дневници за своето работење. Тие ги вклучуваат сите податоци од перформансите на серверот до испраќањето и примањето е-пошта од корисниците. Сепак, читањето на дневниците генерирани од Zimbra OSE е прилично нетривијална задача. Во оваа статија, користејќи конкретен пример, ќе ви кажеме како да ги читате дневниците на Zimbra OSE, како и како да ги направите централизирани.

Zimbra OSE ги зачувува сите локални дневници во папката /opt/zimbra/log, а логовите може да се најдат и во датотеката /var/log/zimbra.log. Најважно од нив е mailbox.log. Ги снима сите дејства што се случуваат на серверот за пошта. Тие вклучуваат пренос на е-пошта, податоци за автентикација на корисникот, неуспешни обиди за најавување и други. Записите во mailbox.log се текстуална низа што го содржи времето во кое се случил настанот, нивото на настанот, бројот на нишката во која се случил настанот, корисничкото име и IP адресата, како и текстуален опис на настанот .

Нивото на дневник го означува степенот на влијание на настанот врз работата на серверот. Стандардно има 4 нивоа на настани: INFO, WARN, ERROR и FATAL. Да ги погледнеме сите нивоа по зголемен редослед на сериозност.

• ИНФО - Настаните на ова ниво обично имаат за цел да информираат за напредокот на Зимбра ОСЕ. Пораките на ова ниво вклучуваат извештаи за создавање или бришење на поштенско сандаче итн.
• ПРЕДУПРЕДУВАЊЕ - настаните од ова ниво информираат за ситуации кои се потенцијално опасни, но не влијаат на работата на серверот. На пример, нивото WARN означува порака за неуспешен обид за најава на корисникот.
• ГРЕШКА - ова ниво на настан во дневникот информира за појава на грешка која е локална по природа и не ја попречува работата на серверот. Ова ниво може да означи грешка во која податоците за индексот на индивидуален корисник се оштетени.
• FATAL - ова ниво укажува на грешки поради кои серверот не може да продолжи да работи нормално. На пример, нивото FATAL ќе биде за запис кој укажува на неможност за поврзување со DBMS.

Датотеката за евиденција на серверот за пошта се ажурира секој ден. Најновата верзија на датотеката секогаш го има името Mailbox.log, додека дневниците за одреден датум имаат датум во името и се содржани во архивата. На пример mailbox.log.2020-09-29.tar.gz. Ова многу го олеснува правењето резервни копии на дневниците на активности и пребарувањето низ дневниците.

За погодност на администраторот на системот, папката /opt/zimbra/log/ содржи други дневници. Тие вклучуваат само записи кои се однесуваат на специфични елементи на Zimbra OSE. На пример, audit.log содржи само записи за автентикација на корисникот, clamd.log содржи податоци за работата на антивирусот итн. Патем, одличен метод за заштита на серверот Zimbra OSE од натрапници е заштита на серверот користејќи Fail2Ban, кој само работи врз основа на audit.log. Исто така, добра практика е да се додаде cron задача за да се изврши командата grep -ir „неважечка лозинка“ /opt/zimbra/log/audit.logда добивате дневни информации за неуспехот на најавување.

Пример за тоа како audit.log прикажува лозинка внесена двапати погрешно и успешен обид за најавување.

Дневниците во Zimbra OSE може да бидат исклучително корисни за идентификување на причините за различни критични неуспеси. Во моментот кога ќе се појави критична грешка, администраторот обично нема време да ги чита дневниците. Потребно е да се врати серверот што е можно поскоро. Меѓутоа, подоцна, кога серверот ќе се направи резервна копија и ќе генерира многу дневници, може да биде тешко да се најде потребниот запис во голема датотека. За брзо да пронајдете запис за грешка, доволно е да го знаете времето во кое серверот е рестартиран и да пронајдете запис во дневниците кои датираат од ова време. Претходниот запис ќе биде запис за настанатата грешка. Пораката за грешка можете да ја најдете и со пребарување на клучниот збор FATAL.

Дневниците на Zimbra OSE исто така ви овозможуваат да идентификувате некритични неуспеси. На пример, за да најдете исклучоци од управувачот, можете да пребарувате за исклучок од управувачот. Честопати, грешките генерирани од управувачите се придружени со трага на стек што објаснува што го предизвикало исклучокот. Во случај на грешки при испорака на пошта, треба да го започнете вашето пребарување со клучниот збор LmtpServer, а за да пребарувате за грешки поврзани со протоколите POP или IMAP, можете да ги користите клучните зборови ImapServer и Pop3Server.

Дневниците исто така можат да помогнат при истражување на инциденти со безбедноста на информациите. Ајде да погледнеме конкретен пример. На 20 септември, еден од вработените испратил писмо заразено со вирус на клиент. Како резултат на тоа, податоците на компјутерот на клиентот беа шифрирани. Сепак, вработениот се колне дека ништо не испратил. Како дел од истрагата за инцидентот, службата за безбедност на претпријатието бара од системскиот администратор дневниците на серверот за пошта за 20 септември поврзани со корисникот што се истражува. Благодарение на временскиот печат, системскиот администратор ја наоѓа потребната датотека за евиденција, ги извлекува потребните информации и ги пренесува на специјалисти за безбедност. Тие, пак, гледаат низ него и откриваат дека IP адресата од која е испратено ова писмо одговара на IP адресата на компјутерот на корисникот. Снимките од CCTV потврдија дека вработениот бил на своето работно место кога е испратено писмото. Овие податоци беа доволни да го обвинат дека ги прекршил правилата за безбедност на информациите и да го отпуштат. 

Пример за вадење записи за една од сметките од дневникот на Mailbox.log во посебна датотека

Сè станува многу покомплицирано кога станува збор за инфраструктурата со повеќе сервери. Бидејќи дневниците се собираат локално, работата со нив во мулти-серверска инфраструктура е многу незгодно и затоа има потреба да се централизира собирањето на дневници. Ова може да се направи со поставување на домаќин за собирање логови. Нема посебна потреба да се додаде посветен домаќин на инфраструктурата. Секој сервер за пошта може да дејствува како јазол за собирање дневници. Во нашиот случај, ова ќе биде јазолот Mailstore01.

На овој сервер треба да ги внесеме следните команди:

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

Уредете ја датотеката /etc/sysconfig/rsyslog и поставете ја SYSLOGD_OPTIONS=”-r -c 2″

Уредете /etc/rsyslog.conf и отстранете ги коментарите на следните редови:
$ModLoad imudp
$UDPServerRun 514

Внесете ги следниве команди:

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

Можете да проверите дали сè работи со помош на командата zmprov gacf | grep zimbraLogHostname. По извршувањето на командата, треба да се прикаже името на домаќинот што собира дневници. За да го промените, мора да ја внесете командата zmprov mcf zimbraLogHostname mailstore01.company.ru.

На сите други инфраструктурни сервери (LDAP, MTA и други продавници за пошта), извршете ја командата zmprov gacf |grep zimbraLogHostname за да го видите името на домаќинот до кој се испраќаат дневниците. За да го промените, можете исто така да ја внесете командата zmprov mcf zimbraLogHostname mailstore01.company.ru

Исто така, мора да ги внесете следните команди на секој сервер:

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

После ова, сите логови ќе бидат снимени на серверот што го наведовте, каде што може практично да се прегледаат. Исто така, во администраторската конзола Zimbra OSE, на екранот со информации за статусот на серверите, вклучената услуга Logger ќе се прикаже само за серверот mailstore01.

Друга главоболка за администраторот може да биде следење на одредена е-пошта. Бидејќи е-пораките во Zimbra OSE поминуваат низ неколку различни настани одеднаш: скенирање со антивирус, антиспам и така натаму, пред да бидат прифатени или испратени, за администраторот, доколку е-поштата не пристигне, може да биде доста проблематично да се следи во која фаза тоа беше изгубено.

За да го решите овој проблем, можете да користите специјална скрипта, која беше развиена од специјалистот за безбедност на информации Виктор Духовни и препорачана за употреба од развивачите на Postfix. Оваа скрипта ги поврзува записите од дневниците за одреден процес и, поради тоа, ви овозможува брзо прикажување на сите записи поврзани со испраќање одредена буква врз основа на нејзиниот идентификатор. Неговата работа е тестирана на сите верзии на Zimbra OSE, почнувајќи од 8.7. Еве го текстот на сценариото.

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

Скриптата е напишана во Perl и за да ја извршите треба да ја зачувате во датотека collate.pl, направете ја извршна, а потоа извршете ја датотеката специфицирајќи ја датотеката за евиденција и користејќи pgrep за да ги извлечете информациите за идентификација на буквата што ја барате collate.pl /var/log/zimbra.log | pgrep'[заштитена по е-пошта]>'. Резултатот ќе биде последователен излез на линии кои содржат информации за движењето на буквата на серверот.

# 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

За сите прашања поврзани со Zextras Suite, можете да контактирате со Претставникот на Zextras Екатерина Триандафилиди преку е-пошта [заштитена по е-пошта]

Извор: www.habr.com