Az események naplózása az egyik legfontosabb funkciója minden vállalati rendszernek. A naplók lehetővé teszik a felmerülő problémák megoldását, az informatikai rendszerek működésének auditálását, valamint az információbiztonsági incidensek vizsgálatát. A Zimbra OSE szintén részletes naplókat vezet a működéséről. Ezek tartalmazzák az összes adatot a szerver teljesítményéről egészen a felhasználók e-mailjeinek küldéséig és fogadásáig. Azonban a Zimbra OSE által generált naplók olvasása meglehetősen nem triviális feladat. Ebben a cikkben egy konkrét példán keresztül bemutatjuk, hogyan olvashatjuk a Zimbra OSE naplóit, valamint azt, hogyan lehet őket centralizálni.
A Zimbra OSE összes helyi naplója az /opt/zimbra/log mappában található, a naplókat a /var/log/zimbra.log fájlban is megtalálhatjuk. A legfontosabb közülük a mailbox.log. Ebben minden olyan tevékenység rögzítésre kerül, amely a levelezőszerveren történik. Közéjük tartozik a levelek küldése, a felhasználók hitelesítési adatai, a sikertelen bejelentkezési kísérletek és egyebek. A mailbox.log bejegyzései szöveges sorok, amelyek tartalmazzák az esemény időpontját, az esemény szintjét, a szál számát, amelynek keretében az esemény zajlott, a felhasználó nevét és IP-címét, valamint az esemény szöveges leírását.
A napló szintje az esemény szerverre gyakorolt hatásának mértékét jelenti. Alapértelmezés szerint négy eseményszint van: INFO, WARN, ERROR és FATAL. Nézzük meg az összes szintet a súlyosságuk növekvő sorrendjében.
- INFO — ezen a szinten az események általában arról tájékoztatnak, hogy a Zimbra OSE működése hogyan halad. E szint üzenetei között szerepelnek a levelezőfiók létrehozásáról vagy törléséről készült jelentések és így tovább.
- WARN — e szint eseményei tájékoztatnak olyan helyzetekről, amelyek potenciálisan veszélyesek, de nem befolyásolják a szerver működését. A WARN szint például azt az üzenetet jelöli, amely a felhasználó sikertelen bejelentkezési kísérletéről szól.
- ERROR — ez a napló szintje arról tájékoztat, hogy lokális hiba merült fel, amely nem akadályozza meg a szerver működését. Ezen a szinten például jelezhető, ha egy adott felhasználó indexadatai megsérültek.
- FATAL — ezen a szinten a szerver normális működését megakadályozó hibák kerülnek rögzítésre. Például a FATAL szintű bejegyzés akkor szerepel, ha nem lehet csatlakozni az adatbázis-kezelő rendszerhez.
A levelek kiszolgáló naplófájlja minden nap frissül. A fájl legfrissebb verziója mindig Mailbox.log néven ismert, míg a meghatározott számú nap naplói a nevében dátummal rendelkeznek, és archiváltak. Például mailbox.log.2020-09-29.tar.gz. Ennek köszönhetően jelentősen egyszerűsödik a tevékenységek naplóinak biztonsági mentése és a naplók közötti keresés.
A rendszergazda kényelme érdekében a /opt/zimbra/log/ mappában további naplók találhatók. Ezek kizárólag a Zimbra OSE konkrét elemeivel kapcsolatos bejegyzéseket tartalmaznak. Például az audit.log csak a felhasználók hitelesítési adatait tartalmazza, a clamd.log pedig az antivírus működéséről szóló adatokat és így tovább. Egyébként nagyszerű módszer a Zimbra OSE kiszolgáló védelmére a , amely éppen az audit.log alapján működik. Szintén jó gyakorlat, ha cron-feladatot adunk hozzá a grep -ir „invalid password“ /opt/zimbra/log/audit.log, hogy minden nap értesülhessünk a sikertelen bejelentkezési kísérletekről.
Példa arra, hogyan jelenik meg a naplóban az audit.log kétszer hibásan megadott jelszó és a sikeres bejelentkezési kísérlet
A Zimbra OSE naplói rendkívül hasznosak lehetnek a különböző kritikus rendszerhibák okainak feltárásában. Amikor kritikus hiba történik, a rendszergazda általában nem a naplók olvasásával foglalkozik. Minél előbb helyre kell állítani a kiszolgáló működését. Azonban később, amikor a kiszolgáló újra működik és számos naplót generál, a megfelelő bejegyzés keresése egy nagy fájlban nem mindig egyszerű. Ahhoz, hogy gyorsan megtaláljuk a hibáról szóló bejegyzést, elegendő tudni, hogy mikor indult újra a kiszolgáló, és a naplók között ezt az időt dátumozott bejegyzést keresni. A megelőző bejegyzés lesz a hiba bejegyzése. Ezen kívül a hibaüzenetet a FATAL kulcsszóval is kereshetjük.
A Zimbra OSE naplók lehetővé teszik a nem kritikus hibák azonosítását is. Például, ha a kezelő kivételek keresésére van szükség, a 'handler exception' kifejezésre kereshetünk. Gyakran a kezelők által generált hibákhoz tartozik egy veremtáblázat, amelyben magyarázatot találunk arra, mi okozta a kivételt. Ha e-mail kézbesítési hibákkal van dolgunk, érdemes az 'LmtpServer' kulcsszóval kezdeni a keresést, míg a POP vagy IMAP protokollokkal kapcsolatos hibák kereséséhez az 'ImapServer' és 'Pop3Server' kulcsszavakat használhatjuk.
A naplók segítséget nyújthatnak az információbiztonsági események kivizsgálásában is. Nézzünk egy konkrét példát. Szeptember 20-án az egyik munkatárs vírusos levelet küldött egy ügyfélnek. Ennek következtében az ügyfél számítógépen lévő adatok titkosítva lettek. A munkatárs azonban esküszik, hogy nem küldött semmit. Az esemény kivizsgálása során a cég biztonsági szolgálata a rendszergazdától kéri a szeptember 20-i e-mail szerver naplóit az érintett felhasználóval kapcsolatban. A időbélyegkódnak köszönhetően a rendszergazda megtalálja a szükséges naplófájlt, kinyeri a szükséges információkat, és átadja azokat a biztonságiaknak. Ők pedig átnézik, és észreveszik, hogy az e-mailt küldő IP-cím megegyezik a IP-cím alapján határozza meg a helyet felhasználó számítógépével. A megfigyelő kamerák felvételei megerősítették, hogy a munkatárs az e-mail elküldése során a munkahelyén tartózkodott. Ezek az adatok elegendőek voltak ahhoz, hogy az információbiztonsági szabályok megsértésével vádolják meg, és elbocsássák.
Példája annak, hogyan lehet egy felhasználói fiók bejegyzéseit kinyerni a Mailbox.log naplóból egy külön fájlba.
Minden jelentősen bonyolultabbá válik, amikor a több szerverből álló infrastruktúrára kerül a sor. Mivel a naplók helyben gyűjtődnek, a több szerverrel működő infrastruktúrában való kezelésük nagyon kényelmetlen, ezért szükség van a naplók gyűjtésének központosítására. Ezt a naplók gyűjtésére szolgáló gazdagép beállításával lehet elérni. Nincs szükség külön gazdagép hozzáadására az infrastruktúrához. A naplók gyűjtésére bármelyik e-mail szerver megvalósulhat. Ebben az esetben a Mailstore01 csomópontunk lesz.
Ezen a szerveren be kell írnunk az alábbi parancsokat:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vSzerkessze a fájlt /etc/sysconfig/rsyslog, és állítsa be a SYSLOGD_OPTIONS paramétert="-r -c 2"
Szerkessze a /etc/rsyslog.conf fájlt, és távolítsa el a megjegyzéseket a következő sorokról:
$ModLoad imudp
$UDPServerRun 514
Adja meg a következő parancsokat:
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/zmupdateauthkeysEllenőrizheti, hogy minden működik az "zmprov gacf | grep zimbraLogHostname" parancs segítségével. A parancs végrehajtása után meg kell jelennie a naplókat gyűjtő gazdagép nevének. Ha meg szeretné változtatni, akkor írja be a "zmprov mcf zimbraLogHostname mailstore01.company.hu" parancsot.
Minden más infrastruktúra szerveren (LDAP, MTA és egyéb levelező tárolók) futtassa a "zmprov gacf | grep zimbraLogHostname" parancsot, hogy láthassa, melyik gazdagépre irányítják a naplókat. Ennek megváltoztatásához ugyanazzal a "zmprov mcf zimbraLogHostname mailstore01.company.hu" parancsot használhatja.
A minden egyes szerveren a következő parancsokat is be kell írni:
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 restartEzt követően minden napló az Ön által megadott szerverre fog íródni, ahol kényelmesen megtekintheti őket. A Zimbra OSE adminisztrátori konzolján a szerverek állapotinformációival kapcsolatos képernyőn a Logger szolgáltatás csak a mailstore01 szerveren fog megjelenni.
Egy másik fejfájás az adminisztrátor számára lehet egy adott e-mail nyomon követése. Mivel az elektronikus levelek a Zimbra OSE-ban számos különböző eseményen átmennek: víruskeresés, spam-ellenőrzés stb. előtt, mielőtt elfogadnák vagy elküldenék, az adminisztrátor számára, ha az elektronikus levél nem érkezik meg, meglehetősen problémás lehet nyomon követni, hogy melyik lépésnél veszhetett el.
A probléma megoldásához felhasználhatunk egy speciális scriptet, amelyet az informatikai biztonsági szakértő, Viktor Dukhivnyj fejlesztett ki, és amelyet a Postfix fejlesztői ajánlanak. Ez a script összefűzi a naplóbejegyzéseket egy adott folyamat alapján, így gyorsan megjeleníthetjük az összes bejegyzést, amely a megadott azonosítójú levél küldésével kapcsolatos. Működését minden Zimbra OSE verzióval tesztelték, kezdve a 8.7-es verziótól. Az alábbiakban bemutatjuk a script szövegét.
#! /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";
}A script Perl nyelven íródott, és a futtatásához el kell menteni egy fájlba. collate.pl, végül végrehajthatóvá kell tenni, majd a naplófájl megadásával és a pgrep segítségével ki kell választani a keresett levél azonosítási információit. collate.pl /var/log/zimbra.log | pgrep ‘’. Az eredmény egy sorozatos kimenet lesz, amely a levél szerverre érkezésével kapcsolatos információkat tartalmazza.
# 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: removedBármilyen kérdése van a Zextras Suitere vonatkozóan, a Zextras cég képviselőjéhez, Trianda Katerinához fordulhat a katerina@zextras.com e-mail címen.
Forrás: habr.com
