ثبت تمام رویدادهای رخ داده یکی از مهمترین کارکردهای هر سیستم شرکتی است. گزارشها به شما امکان میدهند مشکلات نوظهور را حل کنید، عملکرد سیستمهای اطلاعاتی را ممیزی کنید، و همچنین حوادث امنیت اطلاعات را بررسی کنید. 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 چگونه رمز عبوری را که دو بار اشتباه وارد شده و یک تلاش موفق برای ورود به سیستم را نشان می دهد.
Log در Zimbra OSE می تواند در شناسایی علل خرابی های مختلف بسیار مفید باشد. در لحظه ای که یک خطای بحرانی رخ می دهد، مدیر معمولاً زمانی برای خواندن گزارش ها ندارد. لازم است سرور را در اسرع وقت بازیابی کنید. با این حال، بعداً، وقتی سرور پشتیبانگیری میشود و گزارشهای زیادی تولید میکند، پیدا کردن ورودی مورد نیاز در یک فایل بزرگ دشوار است. برای یافتن سریع یک رکورد خطا، کافی است زمان راه اندازی مجدد سرور را بدانید و یک ورودی در گزارش های مربوط به این زمان پیدا کنید. ورودی قبلی یک رکورد از خطای رخ داده خواهد بود. همچنین می توانید با جستجوی کلمه کلیدی FATAL پیام خطا را پیدا کنید.
گزارشهای OSE Zimbra همچنین به شما امکان میدهند خرابیهای غیر بحرانی را شناسایی کنید. به عنوان مثال، برای یافتن استثناهای کنترل کننده، می توانید استثنای کنترل کننده را جستجو کنید. اغلب، خطاهای ایجاد شده توسط کنترلرها با یک ردیابی پشته همراه است که توضیح می دهد که چه چیزی باعث ایجاد استثنا شده است. در صورت بروز خطا در ارسال نامه، باید جستجوی خود را با کلمه کلیدی 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/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";
}
اسکریپت به زبان پرل نوشته شده است و برای اجرای آن باید آن را در یک فایل ذخیره کنید 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: removed
برای تمامی سوالات مربوط به سوئیت Zextras می توانید از طریق ایمیل با نماینده Zextras Ekaterina Triandafilidi تماس بگیرید. [ایمیل محافظت شده]
منبع: www.habr.com