Бардык болуп жаткан окуяларды каттоо ар кандай корпоративдик системанын эң маанилүү функцияларынын бири болуп саналат. Журналдар пайда болгон көйгөйлөрдү чечүүгө, маалыматтык системалардын ишин текшерүүгө, ошондой эле маалыматтык коопсуздук инциденттерин иликтөөгө мүмкүндүк берет. 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 - журналдагы окуянын бул деңгээли локалдык мүнөзгө ээ жана сервердин иштешине тоскоол болбогон катанын келип чыгышы жөнүндө маалымдайт. Бул деңгээл жеке колдонуучунун индексинин маалыматтары бузулган катаны белгилей алат.
- ӨЛҮМЧҮ - бул деңгээл сервер кадимкидей иштей албаган каталарды көрсөтөт. Мисалы, ӨЛҮМЧҮ деңгээл DBMS менен туташуу мүмкүн эместигин көрсөткөн жазуу үчүн болот.
Почта серверинин журнал файлы күн сайын жаңыртылып турат. Файлдын эң акыркы версиясында ар дайым Mailbox.log аталышы болот, ал эми белгилүү бир датадагы журналдардын аталышында датасы бар жана архивде камтылган. Мисалы mailbox.log.2020-09-29.tar.gz. Бул аракет журналдарынын камдык көчүрмөсүн сактоону жана журналдар аркылуу издөөнү бир топ жеңилдетет.
Системалык администратордун ыңгайлуулугу үчүн /opt/zimbra/log/ папкасында башка журналдар бар. Алар белгилүү Zimbra OSE элементтерине тиешелүү жазууларды гана камтыйт. Мисалы, audit.log колдонуучунун аутентификациясы жөнүндө гана жазууларды камтыйт, clamd.log антивирустун иштеши жөнүндө маалыматтарды камтыйт жана башкалар. Айтмакчы, Zimbra OSE серверин зыянкечтерден коргоонун эң сонун ыкмасы , ал жөн гана audit.log негизинде иштейт. Ошондой эле буйрукту аткаруу үчүн cron тапшырмасын кошуу жакшы практика болуп саналат grep -ir "жараксыз сырсөз" /opt/zimbra/log/audit.logкүнүмдүк кирүү катасын алуу үчүн.
Audi.log эки жолу туура эмес киргизилген сырсөздү жана ийгиликтүү кирүү аракетин көрсөткөн мисал.
Zimbra OSEдеги журналдар ар кандай критикалык каталардын себептерин аныктоодо абдан пайдалуу болушу мүмкүн. Критикалык ката пайда болгондо, администратордун журналдарды окууга убактысы жок. Серверди мүмкүн болушунча тез арада калыбына келтирүү талап кылынат. Бирок, кийинчерээк, сервер резервдик көчүрүлүп, көптөгөн журналдарды түзүп жатканда, чоң файлдан керектүү жазууну табуу кыйын болушу мүмкүн. Ката жазуусун тез табуу үчүн сервердин кайра иштетилген убактысын билүү жана ошол убактагы журналдардан жазууну табуу жетиштүү. Мурунку жазуу орун алган катанын жазуусу болот. Ката кабарын FATAL ачкыч сөзүн издөө аркылуу да таба аласыз.
Zimbra OSE журналдары ошондой эле критикалык эмес каталарды аныктоого мүмкүндүк берет. Мисалы, иштеткичтен өзгөчө учурларды табуу үчүн, иштеткичтен өзгөчө учурду издесеңиз болот. Көбүнчө, иштетүүчүлөр тарабынан түзүлгөн каталар өзгөчөлүккө эмне себеп болгонун түшүндүрүүчү стек изи менен коштолот. Почтаны жеткирүүдө каталар келип чыккан учурда, сиз издөөнү LmtpServer ачкыч сөзү менен башташыңыз керек жана POP же IMAP протоколдоруна байланыштуу каталарды издөө үчүн ImapServer жана Pop3Server ачкыч сөздөрүн колдонсоңуз болот.
Журналдар маалыматтык коопсуздук инциденттерин иликтөөдө да жардам берет. Келгиле, конкреттүү мисалды карап көрөлү. 20-сентябрда кызматкерлердин бири кардарга вирус жуккан кат жөнөткөн. Натыйжада кардардын компьютериндеги маалыматтар шифрленген. Бирок, кызматкер эч нерсе жиберген эмес деп ант берет. Окуяны иликтөөнүн алкагында ишкананын коопсуздук кызматы системалык администратордон 20-сентябрга карата текшерилип жаткан колдонуучу менен байланышкан почта серверинин журналдарын сурайт. Убакыт белгисинин аркасында системанын администратору керектүү журнал файлын таап, керектүү маалыматты чыгарып, коопсуздук боюнча адистерге өткөрүп берет. Алар, өз кезегинде, аны карап чыгып, бул кат жөнөтүлгөн IP дареги колдонуучунун компьютеринин IP дарегине дал келерин табышат. Кат жөнөтүлгөндө кызматкер өзүнүн жумуш ордунда болгонун видеокөзөмөл камералары тастыктаган. Бул маалыматтар аны маалыматтык коопсуздук эрежелерин бузган деп айыптап, жумуштан кетирүүгө жетиштүү болгон.
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/zmupdateauthkeyszmprov 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 иштеп чыгуучулары тарабынан колдонууга сунушталган атайын сценарийди колдонсоңуз болот. Бул скрипт белгилүү бир процесс үчүн журналдардагы жазууларды бириктирет жана ушундан улам, анын идентификаторунун негизинде белгилүү бир катты жөнөтүүгө байланышкан бардык жазууларды тез көрсөтүүгө мүмкүндүк берет. Анын иши 8.7ден баштап Zimbra OSEнин бардык версияларында сыналган. Бул жерде сценарийдин тексти.
#! /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: removedZextras Suite менен байланышкан бардык суроолор боюнча сиз Zextras өкүлү Екатерина Триандафилидиге электрондук почта аркылуу кайрылсаңыз болот. [электрондук почта корголгон]
Source: www.habr.com