Բոլոր տեղի ունեցող իրադարձությունների գրանցումը ցանկացած կորպորատիվ համակարգի կարևորագույն գործառույթներից մեկն է: Գրանցամատյանները թույլ են տալիս լուծել ի հայտ եկած խնդիրները, աուդիտ իրականացնել տեղեկատվական համակարգերի աշխատանքը, ինչպես նաև հետաքննել տեղեկատվական անվտանգության միջադեպերը: 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 սերվերը ներխուժողներից պաշտպանելու հիանալի մեթոդ է , որը պարզապես աշխատում է 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, դարձրեք այն գործարկելի, այնուհետև գործարկեք ֆայլը՝ նշելով log ֆայլը և օգտագործելով 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