حفاظت از بمباران زیمبرا و پست

بمب گذاری پستی یکی از قدیمی ترین انواع حملات سایبری است. در هسته خود، شبیه یک حمله DoS معمولی است، اما به جای موجی از درخواست‌ها از آدرس‌های IP مختلف، موجی از ایمیل‌ها به سرور ارسال می‌شود که به مقدار زیادی به یکی از آدرس‌های ایمیل می‌رسد و به همین دلیل بارگذاری می‌شود. روی آن به میزان قابل توجهی افزایش می یابد. چنین حمله ای می تواند منجر به ناتوانی در استفاده از صندوق پستی و حتی گاهی اوقات منجر به از کار افتادن کل سرور شود. سابقه طولانی این نوع حملات سایبری منجر به پیامدهای مثبت و منفی متعددی برای مدیران سیستم شده است. عوامل مثبت شامل دانش خوب بمب گذاری پستی و در دسترس بودن راه های ساده برای محافظت از خود در برابر چنین حمله ای است. عوامل منفی شامل تعداد زیادی راه حل نرم افزاری در دسترس عموم برای انجام چنین انواع حملات و توانایی مهاجم برای محافظت مطمئن از خود در برابر شناسایی است.

یکی از ویژگی های مهم این حمله سایبری این است که استفاده از آن برای سود تقریبا غیرممکن است. خب، مهاجم موجی از ایمیل‌ها را به یکی از صندوق‌های پستی ارسال کرد، خوب، او به شخص اجازه استفاده عادی از ایمیل را نداد، خوب، مهاجم ایمیل شرکتی را هک کرد و شروع به ارسال انبوه هزاران نامه در سراسر GAL کرد. این است که چرا سرور یا از کار افتاد یا شروع به کاهش سرعت کرد به طوری که استفاده از آن غیرممکن شد و بعد چه؟ تبدیل چنین جرایم سایبری به پول واقعی تقریباً غیرممکن است، بنابراین صرفاً بمباران پستی در حال حاضر یک اتفاق نسبتاً نادر است و مدیران سیستم، هنگام طراحی زیرساخت، ممکن است به سادگی نیاز به محافظت در برابر چنین حمله سایبری را به خاطر نداشته باشند.

با این حال، در حالی که بمباران ایمیل به خودی خود یک تمرین نسبتاً بیهوده از دیدگاه تجاری است، اغلب بخشی از سایر حملات سایبری پیچیده تر و چند مرحله ای است. به عنوان مثال، هنگام هک ایمیل و استفاده از آن برای ربودن یک حساب کاربری در برخی از خدمات عمومی، مهاجمان اغلب صندوق پستی قربانی را با حروف بی معنی بمباران می کنند تا نامه تایید در جریان آنها گم شود و مورد توجه قرار نگیرد. بمباران پستی همچنین می تواند به عنوان ابزاری برای فشار اقتصادی بر یک شرکت استفاده شود. بنابراین، بمباران فعال صندوق پستی عمومی یک شرکت، که درخواست‌های مشتریان را دریافت می‌کند، می‌تواند کار با آنها را به طور جدی پیچیده کند و در نتیجه می‌تواند منجر به از کار افتادن تجهیزات، سفارش‌های انجام نشده و همچنین از دست دادن شهرت و سود از دست رفته شود.

به همین دلیل است که مدیر سیستم نباید احتمال بمباران ایمیل را فراموش کند و همیشه اقدامات لازم را برای محافظت در برابر این تهدید انجام دهد. با توجه به اینکه این کار در مرحله ساخت زیرساخت پستی قابل انجام است و همچنین زمان و کار بسیار کمی از مدیر سیستم می‌گیرد، به سادگی هیچ دلیل عینی برای محافظت از زیرساخت شما در برابر بمباران پست وجود ندارد. بیایید نگاهی به نحوه اجرای حفاظت در برابر این حمله سایبری در Zimbra Collaboration Suite Open-Source Edition بیاندازیم.

Zimbra بر اساس Postfix، یکی از قابل اعتمادترین و کاربردی ترین عوامل انتقال ایمیل منبع باز در حال حاضر است. و یکی از مزایای اصلی باز بودن آن این است که از طیف گسترده ای از راه حل های شخص ثالث برای گسترش عملکرد پشتیبانی می کند. به طور خاص، Postfix به طور کامل از cbpolicyd، یک ابزار پیشرفته برای اطمینان از امنیت سایبری سرور ایمیل پشتیبانی می کند. علاوه بر محافظت در برابر هرزنامه و ایجاد لیست سفید، لیست سیاه و لیست خاکستری، cbpolicyd به مدیر Zimbra اجازه می دهد تا تأیید امضای SPF را پیکربندی کند، و همچنین محدودیت هایی را برای دریافت و ارسال ایمیل یا داده ها تعیین کند. آنها هم می توانند محافظت قابل اعتمادی در برابر هرزنامه و ایمیل های فیشینگ ایجاد کنند و هم از سرور در برابر بمباران ایمیل محافظت کنند.

اولین چیزی که از مدیر سیستم لازم است، فعال کردن ماژول cbpolicyd است که در Zimbra Collaboration Suite OSE روی سرور MTA زیرساخت از پیش نصب شده است. این کار با استفاده از دستور zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd انجام می شود. پس از این، باید رابط وب را فعال کنید تا بتوانید به راحتی cbpolicyd را مدیریت کنید. برای انجام این کار، باید به اتصالات در پورت وب شماره 7780 اجازه دهید، یک پیوند نمادین با استفاده از دستور ایجاد کنید. ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webuiو سپس فایل تنظیمات را با استفاده از دستور nano ویرایش کنید /opt/zimbra/data/httpd/htdocs/webui/includes/config.php، جایی که باید خطوط زیر را بنویسید:

$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";

پس از آن، تنها راه اندازی مجدد سرویس های Zimbra و Zimbra Apache با استفاده از دستورات zmcontrol restart و zmapachectl باقی می ماند. پس از این، به رابط وب دسترسی خواهید داشت example.com:7780/webui/index.php. نکته اصلی این است که ورودی این رابط وب هنوز به هیچ وجه محافظت نشده است و برای جلوگیری از ورود افراد غیرمجاز به آن، می توانید پس از هر بار ورود به رابط وب، به سادگی اتصالات را در پورت 7780 ببندید.

می‌توانید با استفاده از سهمیه‌هایی برای ارسال ایمیل‌ها که به لطف cbpolicyd تنظیم می‌شوند، از سیل ایمیل‌های دریافتی از شبکه داخلی محافظت کنید. چنین سهمیه هایی به شما امکان می دهد محدودیتی برای حداکثر تعداد نامه هایی که می توان از یک صندوق پستی در یک واحد زمان ارسال کرد تعیین کنید. به عنوان مثال، اگر مدیران کسب و کار شما به طور متوسط ​​60-80 ایمیل در ساعت ارسال می کنند، می توانید با در نظر گرفتن یک حاشیه کوچک، سهمیه ای 100 ایمیل در ساعت تعیین کنید. برای رسیدن به این سهمیه، مدیران باید هر 36 ثانیه یک ایمیل ارسال کنند. از یک طرف، این برای کار کامل کافی است و از طرف دیگر، با چنین سهمیه ای، مهاجمانی که به نامه یکی از مدیران شما دسترسی پیدا کرده اند، بمب گذاری ایمیل یا حمله گسترده هرزنامه را به شرکت راه اندازی نمی کنند.

برای تعیین چنین سهمیه ای، باید یک خط مشی محدودیت ارسال ایمیل جدید در رابط وب ایجاد کنید و مشخص کنید که هم برای ایمیل های ارسال شده در دامنه و هم برای ایمیل های ارسال شده به آدرس های خارجی اعمال شود. این کار به صورت زیر انجام می شود:

پس از آن، می توان با جزئیات بیشتری محدودیت های مربوط به ارسال نامه ها را مشخص کرد، به ویژه، بازه زمانی را که پس از آن محدودیت ها به روز می شود و همچنین پیامی که کاربر از حد مجاز خود فراتر رفته است را تنظیم کنید. پس از این می توانید محدودیت ارسال نامه را تعیین کنید. می توان آن را هم به عنوان تعداد پیام های خروجی و هم به عنوان تعداد بایت های اطلاعات ارسالی تنظیم کرد. در عین حال با نامه هایی که بیش از حد تعیین شده ارسال می شود، متفاوت عمل کنید. بنابراین، به عنوان مثال، می توانید به سادگی آنها را بلافاصله حذف کنید، یا می توانید آنها را ذخیره کنید تا بلافاصله پس از به روز رسانی محدودیت ارسال پیام، بروند. گزینه دوم را می توان هنگام تعیین مقدار بهینه برای محدودیت ارسال ایمیل به کارمندان استفاده کرد.

علاوه بر محدودیت های ارسال ایمیل، cbpolicyd به شما امکان می دهد محدودیتی برای دریافت ایمیل ها تعیین کنید. چنین محدودیتی در نگاه اول یک راه حل عالی برای محافظت در برابر بمباران پستی است، با این حال، در واقع، تعیین چنین محدودیتی، حتی اگر بزرگ باشد، مملو از این واقعیت است که تحت شرایط خاص ممکن است نامه مهمی به شما نرسد. . به همین دلیل است که از فعال کردن هرگونه محدودیت برای نامه های دریافتی به شدت اجتناب می شود. با این حال، اگر هنوز تصمیم دارید فرصتی را انتخاب کنید، باید با توجه ویژه به تنظیم محدودیت پیام دریافتی نزدیک شوید. به عنوان مثال، می‌توانید تعداد ایمیل‌های دریافتی از طرف‌های قابل اعتماد را محدود کنید تا اگر سرور ایمیل آن‌ها به خطر بیفتد، حمله اسپم به کسب‌وکار شما انجام ندهد.

به منظور محافظت در برابر هجوم پیام‌های دریافتی در هنگام بمباران ایمیل، مدیر سیستم باید کاری هوشمندانه‌تر از محدود کردن ایمیل‌های دریافتی انجام دهد. این راه حل می تواند استفاده از لیست های خاکستری باشد. اصل عملکرد آنها این است که در اولین تلاش برای تحویل پیام از یک فرستنده غیرقابل اعتماد، اتصال به سرور به طور ناگهانی قطع می شود و به همین دلیل تحویل پیام با شکست مواجه می شود. با این حال، اگر یک سرور نامعتبر سعی کند در مدت معینی دوباره همان ایمیل را ارسال کند، سرور اتصال را قطع نمی کند و تحویل آن با موفقیت انجام می شود.

نکته تمام این اقدامات این است که برنامه های ایمیل انبوه خودکار معمولاً موفقیت پیام ارسالی را بررسی نمی کنند و برای بار دوم اقدام به ارسال آن نمی کنند، در حالی که شخص مطمئناً مطمئن می شود که نامه او به آدرس ارسال شده است یا خیر. .

همچنین می توانید فهرست خاکستری را در رابط وب cbpolicyd فعال کنید. برای اینکه همه چیز کار کند، باید خط‌مشی ایجاد کنید که شامل تمام نامه‌های دریافتی خطاب به کاربران در سرور ما باشد، و سپس، بر اساس این خط‌مشی، یک قانون Greylisting ایجاد کنید، که در آن می‌توانید بازه‌ای را که در آن cbpolicyd منتظر بماند، پیکربندی کنید. برای پاسخ دوم از یک فرستنده ناآشنا. معمولاً 4-5 دقیقه است. در عین حال، لیست های خاکستری را می توان به گونه ای پیکربندی کرد که تمام تلاش های موفقیت آمیز و ناموفق برای تحویل نامه از فرستنده های مختلف در نظر گرفته شود و بر اساس تعداد آنها، تصمیم گرفته شود که فرستنده به طور خودکار به لیست های سفید یا سیاه اضافه شود.

توجه شما را به این واقعیت جلب می کنیم که استفاده از لیست های خاکستری باید با نهایت مسئولیت پذیری باشد. بهترین کار این است که استفاده از این فناوری با حفظ مداوم لیست‌های سفید و سیاه همراه باشد تا احتمال از دست دادن حروفی که واقعاً برای شرکت مهم هستند حذف شود.

علاوه بر این، افزودن چک‌های SPF، DMARC و DKIM می‌تواند به محافظت در برابر بمب‌گذاری ایمیل کمک کند. اغلب، نامه‌هایی که در فرآیند بمباران پستی می‌آیند، از چنین بررسی‌هایی عبور نمی‌کنند. نحوه انجام این کار مورد بحث قرار گرفت در یکی از مقالات قبلی ما.

بنابراین، محافظت از خود در برابر تهدیدی مانند بمب گذاری پستی بسیار ساده است و می توانید این کار را حتی در مرحله ساخت زیرساخت زیمبرا برای شرکت خود انجام دهید. با این حال، مهم است که دائماً اطمینان حاصل کنید که خطرات استفاده از چنین محافظتی هرگز از مزایای دریافتی شما بیشتر نباشد.

منبع: www.habr.com