Meydana gelen tüm olayların günlüğe kaydedilmesi, herhangi bir kurumsal sistemin en önemli işlevlerinden biridir. Günlükler, ortaya çıkan sorunları çözmenize, bilgi sistemlerinin işleyişini denetlemenize ve ayrıca bilgi güvenliği olaylarını araştırmanıza olanak tanır. Zimbra OSE ayrıca işleyişinin ayrıntılı kayıtlarını da tutar. Sunucu performansından kullanıcılar tarafından e-posta gönderilip alınmasına kadar tüm verileri içerirler. Ancak Zimbra OSE tarafından oluşturulan logların okunması oldukça basit bir iştir. Bu yazımızda spesifik bir örnek kullanarak Zimbra OSE loglarının nasıl okunacağını ve bunların nasıl merkezi hale getirileceğini anlatacağız.
Zimbra OSE tüm yerel günlükleri /opt/zimbra/log klasöründe saklar ve günlükler ayrıca /var/log/zimbra.log dosyasında da bulunabilir. Bunlardan en önemlisi mailbox.log'dur. Posta sunucusunda meydana gelen tüm eylemleri kaydeder. Bunlar arasında e-postaların iletimi, kullanıcı kimlik doğrulama verileri, başarısız oturum açma girişimleri ve diğerleri yer alır. mailbox.log dosyasındaki girişler, olayın meydana geldiği zamanı, olayın düzeyini, olayın meydana geldiği iş parçacığı numarasını, kullanıcı adını ve IP adresinin yanı sıra olayın metin açıklamasını içeren bir metin dizesidir. .
Günlük düzeyi, olayın sunucunun çalışması üzerindeki etki derecesini gösterir. Varsayılan olarak 4 olay düzeyi vardır: BİLGİ, UYARI, HATA ve ÖLÜMCÜL. Artan şiddet sırasına göre tüm düzeylere bakalım.
- BİLGİ - Bu seviyedeki etkinliklerin amacı genellikle Zimbra OSE'nin ilerleyişi hakkında bilgi vermektir. Bu düzeydeki mesajlar, bir posta kutusunun oluşturulması veya silinmesi vb. ile ilgili raporları içerir.
- UYARI - bu seviyedeki olaylar, potansiyel olarak tehlikeli olan ancak sunucunun çalışmasını etkilemeyen durumlar hakkında bilgi verir. Örneğin, WARN seviyesi, başarısız bir kullanıcı oturum açma girişimiyle ilgili bir mesajı işaretler.
- HATA - günlükteki bu olay düzeyi, doğası gereği yerel olan ve sunucunun çalışmasına müdahale etmeyen bir hatanın oluşumu hakkında bilgi verir. Bu düzey, bireysel kullanıcının dizin verilerinin bozulduğu bir hatayı işaretleyebilir.
- FATAL - bu seviye, sunucunun normal şekilde çalışmaya devam edememesine neden olan hataları gösterir. Örneğin FATAL düzeyi, DBMS'ye bağlanılamayacağını belirten bir kayıt için olacaktır.
Posta sunucusu günlük dosyası her gün güncellenir. Dosyanın en son sürümü her zaman Mailbox.log adını taşırken, belirli bir tarihe ait günlüklerin adında bir tarih bulunur ve arşivde bulunur. Örneğin mailbox.log.2020-09-29.tar.gz. Bu, etkinlik günlüklerini yedeklemeyi ve günlüklerde arama yapmayı çok daha kolay hale getirir.
Sistem yöneticisine kolaylık olması açısından /opt/zimbra/log/ klasöründe başka günlükler bulunur. Yalnızca belirli Zimbra OSE öğeleriyle ilgili girişleri içerirler. Örneğin, Audit.log yalnızca kullanıcı kimlik doğrulamasıyla ilgili kayıtları içerir; clamd.log, antivirüsün çalışmasıyla ilgili verileri vb. içerir. Bu arada, Zimbra OSE sunucusunu davetsiz misafirlere karşı korumanın mükemmel bir yöntemi , yalnızca Audit.log'a dayalı olarak çalışır. Komutu yürütmek için bir cron görevi eklemek de iyi bir uygulamadır. grep -ir "geçersiz şifre" /opt/zimbra/log/audit.logGünlük oturum açma hatası bilgilerini almak için.
Audit.log'un iki kez yanlış girilen bir şifreyi ve başarılı bir giriş denemesini nasıl gösterdiğine dair bir örnek.
Zimbra OSE'deki günlükler, çeşitli kritik arızaların nedenlerinin belirlenmesinde son derece yararlı olabilir. Kritik bir hatanın oluştuğu anda yöneticinin genellikle günlükleri okuyacak zamanı yoktur. Sunucunun mümkün olan en kısa sürede geri yüklenmesi gerekmektedir. Ancak daha sonra sunucu yedeklendiğinde ve çok sayıda günlük oluşturduğunda, büyük bir dosyada gerekli girişi bulmak zor olabilir. Bir hata kaydını hızlı bir şekilde bulmak için, sunucunun yeniden başlatıldığı zamanı bilmek ve günlüklerde bu zamana ait bir giriş bulmak yeterlidir. Önceki giriş, meydana gelen hatanın bir kaydı olacaktır. FATAL anahtar kelimesini arayarak da hata mesajını bulabilirsiniz.
Zimbra OSE günlükleri ayrıca kritik olmayan arızaları tanımlamanıza da olanak tanır. Örneğin, işleyici istisnalarını bulmak için işleyici istisnasını arayabilirsiniz. Genellikle işleyiciler tarafından oluşturulan hatalara, istisnanın nedenini açıklayan bir yığın izleme eşlik eder. Posta tesliminde hata olması durumunda aramaya LmtpServer anahtar sözcüğüyle başlamalı, POP veya IMAP protokolleriyle ilgili hataları aramak için ise ImapServer ve Pop3Server anahtar sözcüklerini kullanabilirsiniz.
Günlükler ayrıca bilgi güvenliği olaylarını araştırırken de yardımcı olabilir. Belirli bir örneğe bakalım. 20 Eylül'de çalışanlardan biri bir müşteriye virüs bulaşmış bir mektup gönderdi. Sonuç olarak, müşterinin bilgisayarındaki veriler şifrelendi. Ancak çalışan hiçbir şey göndermediğine yemin ediyor. Olayla ilgili soruşturmanın bir parçası olarak kurumsal güvenlik hizmeti, sistem yöneticisinden araştırılan kullanıcıyla ilişkili 20 Eylül tarihli posta sunucusu günlüklerini talep ediyor. Zaman damgası sayesinde sistem yöneticisi gerekli log dosyasını bulur, gerekli bilgileri çıkarır ve güvenlik uzmanlarına aktarır. Bunlar da mektubu inceliyor ve bu mektubun gönderildiği IP adresinin kullanıcının bilgisayarının IP adresine karşılık geldiğini buluyor. CCTV görüntüleri, mektubun gönderildiği sırada çalışanın işyerinde olduğunu doğruladı. Bu veri onu bilgi güvenliği kurallarını ihlal etmekle suçlayıp kovmak için yeterliydi.
Hesaplardan birine ilişkin kayıtların Mailbox.log günlüğünden ayrı bir dosyaya çıkarılmasına bir örnek
Çoklu sunucu altyapısı söz konusu olduğunda her şey çok daha karmaşık hale geliyor. Loglar yerel olarak toplandığından çoklu sunucu altyapısında bunlarla çalışmak oldukça sakıncalıdır ve bu nedenle logların toplanmasının merkezileştirilmesine ihtiyaç vardır. Bu, günlükleri toplayacak bir ana bilgisayar kurularak yapılabilir. Altyapıya özel bir ana bilgisayar eklemeye özel bir ihtiyaç yoktur. Herhangi bir posta sunucusu, günlüklerin toplanması için bir düğüm görevi görebilir. Bizim durumumuzda bu Mailstore01 düğümü olacaktır.
Bu sunucuda aşağıdaki komutları girmemiz gerekiyor:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -v/etc/sysconfig/rsyslog dosyasını düzenleyin ve SYSLOGD_OPTIONS=”-r -c 2″ değerini ayarlayın.
/etc/rsyslog.conf dosyasını düzenleyin ve aşağıdaki satırların açıklamalarını kaldırın:
$ModLoad imudp
$UDPSunucu Çalıştır 514
Aşağıdaki komutları girin:
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 | komutunu kullanarak her şeyin çalışıp çalışmadığını kontrol edebilirsiniz. grep zimbraLogHostname.dll Komutu yürüttükten sonra günlükleri toplayan ana bilgisayarın adı görüntülenmelidir. Bunu değiştirmek için zmprov mcf zimbraLogHostname mailstore01.company.ru komutunu girmelisiniz.
Diğer tüm altyapı sunucularında (LDAP, MTA ve diğer posta depoları), günlüklerin gönderildiği ana bilgisayarın adını görmek için zmprov gacf |grep zimbraLogHostname komutunu çalıştırın. Bunu değiştirmek için zmprov mcf zimbraLogHostname mailstore01.company.ru komutunu da girebilirsiniz.
Ayrıca her sunucuya aşağıdaki komutları da girmelisiniz:
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 restartBundan sonra, tüm günlükler belirttiğiniz sunucuya kaydedilecek ve burada rahatlıkla görüntülenebilecektir. Ayrıca Zimbra OSE yönetici konsolunda, sunucuların durumuyla ilgili bilgilerin yer aldığı ekranda, yalnızca mailstore01 sunucusu için çalışan Logger hizmeti görüntülenecektir.
Bir yöneticinin başka bir baş ağrısı da belirli bir e-postayı takip etmek olabilir. Zimbra OSE'deki e-postalar aynı anda birkaç farklı olaydan geçtiğinden: kabul edilmeden veya gönderilmeden önce antivirüs, antispam vb. ile tarama, yönetici için, eğer e-posta gelmezse, hangi aşamada olduğunu takip etmek oldukça sorunlu olabilir. kaybolmuştu.
Bu sorunu çözmek için bilgi güvenliği uzmanı Viktor Dukhovny tarafından geliştirilen ve Postfix geliştiricileri tarafından kullanılması önerilen özel bir komut dosyası kullanabilirsiniz. Bu komut dosyası, belirli bir işlem için günlüklerdeki girişleri birleştirir ve bu nedenle, tanımlayıcısına göre belirli bir mektubun gönderilmesiyle ilişkili tüm girişleri hızlı bir şekilde görüntülemenize olanak tanır. Çalışması Zimbra OSE'nin 8.7'den başlayarak tüm versiyonlarında test edilmiştir. İşte betiğin metni.
#! /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";
}Betik Perl'de yazılmıştır ve çalıştırmak için onu bir dosyaya kaydetmeniz gerekir. harmanla.pl, çalıştırılabilir hale getirin ve ardından günlük dosyasını belirterek dosyayı çalıştırın ve aradığınız mektubun kimlik bilgilerini çıkarmak için pgrep'i kullanın. collate.pl /var/log/zimbra.log | pgrep'[e-posta korumalı]>’. Sonuç, mektubun sunucudaki hareketi hakkında bilgi içeren satırların sıralı bir çıktısı olacaktır.
# 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 ile ilgili tüm sorularınız için Zextras Ekaterina Triandafilidi Temsilcisi ile e-posta yoluyla iletişime geçebilirsiniz. [e-posta korumalı]
Kaynak: habr.com