Visu notiekošo notikumu reģistrēšana ir viena no svarīgākajām jebkuras korporatīvās sistēmas funkcijām. Žurnāli ļauj risināt radušās problēmas, auditēt informācijas sistēmu darbību, kā arī izmeklēt informācijas drošības incidentus. Zimbra OSE arī glabā detalizētus žurnālus par savu darbību. Tie ietver visus datus, sākot no servera veiktspējas līdz lietotāju e-pasta ziņojumu sūtīšanai un saņemšanai. Tomēr Zimbra OSE ģenerēto žurnālu lasīšana ir diezgan nenozīmīgs uzdevums. Šajā rakstā, izmantojot konkrētu piemēru, mēs jums pateiksim, kā lasīt Zimbra OSE žurnālus, kā arī tos centralizēt.
Zimbra OSE visus vietējos žurnālus saglabā mapē /opt/zimbra/log, un žurnālus var atrast arī failā /var/log/zimbra.log. Vissvarīgākais no tiem ir mailbox.log. Tas reģistrē visas darbības, kas notiek pasta serverī. Tie ietver e-pasta ziņojumu pārsūtīšanu, lietotāja autentifikācijas datus, neveiksmīgus pieteikšanās mēģinājumus un citus. Ieraksti mailbox.log ir teksta virkne, kurā ir ietverts notikuma laiks, notikuma līmenis, pavediena numurs, kurā notika notikums, lietotājvārds un IP adrese, kā arī notikuma teksta apraksts. .
Žurnāla līmenis norāda notikuma ietekmes pakāpi uz servera darbību. Pēc noklusējuma ir 4 notikumu līmeņi: INFO, WARN, ERROR un FATAL. Apskatīsim visus līmeņus pieaugošā smaguma secībā.
- INFORMĀCIJA — šī līmeņa pasākumi parasti ir paredzēti, lai informētu par Zimbra OSE gaitu. Ziņojumi šajā līmenī ietver ziņojumus par pastkastes izveidi vai dzēšanu utt.
- BRĪDINĀJUMS - šāda līmeņa notikumi informē par situācijām, kas ir potenciāli bīstamas, bet neietekmē servera darbību. Piemēram, WARN līmenis apzīmē ziņojumu par neveiksmīgu lietotāja pieteikšanās mēģinājumu.
- KĻŪDA – šis notikuma līmenis žurnālā informē par kļūdas rašanos, kas pēc būtības ir lokāla un netraucē servera darbību. Šis līmenis var atzīmēt kļūdu, kurā ir bojāti atsevišķa lietotāja indeksa dati.
- FATAL — šis līmenis norāda uz kļūdām, kuru dēļ serveris nevar turpināt normāli darboties. Piemēram, FATAL līmenis būs ierakstam, kas norāda uz nespēju izveidot savienojumu ar DBVS.
Pasta servera žurnālfails tiek atjaunināts katru dienu. Faila jaunākajai versijai vienmēr ir nosaukums Mailbox.log, savukārt noteikta datuma žurnālu nosaukumā ir datums, un tie atrodas arhīvā. Piemēram, mailbox.log.2020-09-29.tar.gz. Tas ievērojami atvieglo darbību žurnālu dublēšanu un meklēšanu žurnālos.
Sistēmas administratora ērtībām mapē /opt/zimbra/log/ ir citi žurnāli. Tie ietver tikai ierakstus, kas attiecas uz konkrētiem Zimbra OSE elementiem. Piemēram, audit.log satur tikai ierakstus par lietotāja autentifikāciju, clamd.log satur datus par antivīrusa darbību utt. Starp citu, lieliska metode Zimbra OSE servera aizsardzībai no iebrucējiem ir , kas vienkārši darbojas, pamatojoties uz audit.log. Laba prakse ir arī pievienot cron uzdevumu, lai izpildītu komandu grep -ir "nederīga parole" /opt/zimbra/log/audit.loglai saņemtu ikdienas pieteikšanās kļūdu informāciju.
Piemērs tam, kā audit.log parāda divreiz nepareizi ievadītu paroli un veiksmīgu pieteikšanās mēģinājumu.
Zimbra OSE žurnāli var būt ļoti noderīgi, lai noteiktu dažādu kritisku kļūmju cēloņus. Brīdī, kad notiek kritiska kļūda, administratoram parasti nav laika lasīt žurnālus. Ir nepieciešams pēc iespējas ātrāk atjaunot serveri. Tomēr vēlāk, kad serveris ir dublēts un ģenerē daudz žurnālu, var būt grūti atrast vajadzīgo ierakstu lielā failā. Lai ātri atrastu kļūdas ierakstu, pietiek zināt laiku, kurā serveris tika restartēts, un žurnālos atrast ierakstu, kas datēts ar šo laiku. Iepriekšējais ieraksts būs radušās kļūdas ieraksts. Kļūdas ziņojumu var atrast arī, meklējot atslēgvārdu FATAL.
Zimbra OSE žurnāli arī ļauj identificēt nekritiskas kļūmes. Piemēram, lai atrastu apdarinātāja izņēmumus, varat meklēt apdarinātāja izņēmumu. Bieži vien apdarinātāju radītajām kļūdām tiek pievienota steka izsekošana, kas izskaidro izņēmuma cēloni. Ja rodas kļūdas ar pasta piegādi, sāciet meklēšanu ar atslēgvārdu LmtpServer, savukārt, lai meklētu kļūdas, kas saistītas ar POP vai IMAP protokoliem, varat izmantot atslēgvārdus ImapServer un Pop3Server.
Žurnāli var būt noderīgi arī informācijas drošības incidentu izmeklēšanā. Apskatīsim konkrētu piemēru: 20. septembrī darbinieks nosūtīja klientam ar vīrusu inficētu e-pastu. Rezultātā dati klienta datorā tika šifrēti. Tomēr darbinieks zvēr, ka neko nav nosūtījis. Incidenta izmeklēšanas ietvaros uzņēmuma drošības dienests pieprasa sistēmas administratoram sniegt pasta servera žurnālus par 20. septembri, kas saistīti ar izmeklējamo lietotāju. Izmantojot laika zīmogu, sistēmas administrators atrod attiecīgo žurnālfailu, iegūst nepieciešamo informāciju un nodod to drošības speciālistiem. Viņi savukārt pārskata žurnālus un atklāj, ka IP adrese, no kuras tika nosūtīts e-pasts, atbilst. IP adrese Lietotāja dators. Videonovērošanas ieraksts apstiprināja, ka darbinieks e-pasta nosūtīšanas brīdī atradās pie sava galda. Šie pierādījumi bija pietiekami, lai viņu apsūdzētu informācijas drošības noteikumu pārkāpšanā un atlaistu no darba.
Piemērs ierakstu izvilkšanai par vienu no kontiem no žurnāla Mailbox.log atsevišķā failā
Viss kļūst daudz sarežģītāks, ja runa ir par vairāku serveru infrastruktūru. Tā kā žurnāli tiek vākti lokāli, darbs ar tiem vairāku serveru infrastruktūrā ir ļoti neērts un tāpēc ir nepieciešams centralizēt žurnālu vākšanu. To var izdarīt, iestatot resursdatoru žurnālu vākšanai. Nav īpašas vajadzības infrastruktūrai pievienot īpašu resursdatoru. Jebkurš pasta serveris var darboties kā mezgls žurnālu vākšanai. Mūsu gadījumā tas būs Mailstore01 mezgls.
Šajā serverī mums jāievada šādas komandas:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vRediģējiet failu /etc/sysconfig/rsyslog un iestatiet SYSLOGD_OPTIONS=”-r -c 2″
Rediģējiet /etc/rsyslog.conf un atņemiet komentārus no šādām rindiņām:
$ModLoad imudp
$UDPServerRun 514
Ievadiet šādas komandas:
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/zmupdateauthkeysVarat pārbaudīt, vai viss darbojas, izmantojot komandu zmprov gacf | grep zimbraLogHostname. Pēc komandas izpildes ir jāparāda resursdatora nosaukums, kas apkopo žurnālus. Lai to mainītu, jāievada komanda zmprov mcf zimbraLogHostname mailstore01.company.ru.
Visos citos infrastruktūras serveros (LDAP, MTA un citos pasta veikalos) palaidiet komandu zmprov gacf |grep zimbraLogHostname, lai redzētu resursdatora nosaukumu, kuram tiek nosūtīti žurnāli. Lai to mainītu, varat arī ievadīt komandu zmprov mcf zimbraLogHostname mailstore01.company.ru
Katrā serverī jāievada arī šādas komandas:
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 restartPēc tam visi žurnāli tiks ierakstīti jūsu norādītajā serverī, kur tos varēs ērti apskatīt. Arī Zimbra OSE administratora konsolē ekrānā ar informāciju par serveru statusu darbojošais Logger pakalpojums tiks parādīts tikai serverim mailstore01.
Vēl viena administratora galvassāpes var būt konkrēta e-pasta izsekošana. Tā kā e-pastiem Zimbra OSE vienlaikus notiek vairāki dažādi notikumi: skenēšana, izmantojot pretvīrusu, pretsurogātpastu un tā tālāk, pirms to pieņemšanas vai nosūtīšanas administratoram, ja e-pasts nepienāk, var būt diezgan problemātiski izsekot, kurā posmā. tas tika pazaudēts.
Lai atrisinātu šo problēmu, varat izmantot īpašu skriptu, ko izstrādājis informācijas drošības speciālists Viktors Dukhovny un ieteicis lietot Postfix izstrādātāji. Šis skripts savieno ierakstus no konkrēta procesa žurnāliem un ļauj ātri parādīt visus ierakstus, kas saistīti ar konkrētas vēstules nosūtīšanu, pamatojoties uz tās identifikatoru. Tās darbība ir pārbaudīta visās Zimbra OSE versijās, sākot no 8.7. Šeit ir skripta teksts.
#! /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";
}Skripts ir rakstīts programmā Perl, un, lai to palaistu, tas ir jāsaglabā failā salīdzināt.pl, padariet to izpildāmu un pēc tam palaidiet failu, norādot žurnālfailu un izmantojot pgrep, lai izvilktu meklētās vēstules identifikācijas informāciju collate.pl /var/log/zimbra.log | pgrep '<20200929164500.user@mail.company.ru>'. Rezultāts būs secīga rindu izvade, kas satur informāciju par burta kustību 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: removedPar visiem jautājumiem, kas saistīti ar Zextras Suite, varat sazināties ar Zextras pārstāvi Jekaterinu Triandafilidi pa e-pastu katerina@zextras.com
Avots: www.habr.com
