როგორ ვიმუშაოთ 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. მოდით შევხედოთ ყველა დონეს სიმძიმის მზარდი თანმიმდევრობით.

• INFO - ამ დონის ღონისძიებები, როგორც წესი, გამიზნულია Zimbra OSE-ის პროგრესის შესახებ ინფორმირებისთვის. ამ დონეზე შეტყობინებები მოიცავს ანგარიშებს საფოსტო ყუთის შექმნის ან წაშლის შესახებ და ა.შ.
• გაფრთხილება - ამ დონის მოვლენები გვაწვდის ინფორმაციას პოტენციურად საშიში სიტუაციების შესახებ, მაგრამ არ იმოქმედებს სერვერის მუშაობაზე. მაგალითად, WARN დონე აღნიშნავს შეტყობინებას მომხმარებლის შესვლის წარუმატებელი მცდელობის შესახებ.
• ERROR - ჟურნალში მოვლენის ეს დონე აცნობებს შეცდომის წარმოქმნას, რომელიც ლოკალური ხასიათისაა და არ უშლის ხელს სერვერის მუშაობას. ამ დონეს შეუძლია მონიშნოს შეცდომა, რომლის დროსაც ინდივიდუალური მომხმარებლის ინდექსის მონაცემები დაზიანებულია.
• 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