زيمبرا ودفاع قنبلة البريد

يعتبر تفجير البريد الإلكتروني أحد أقدم أنواع الهجمات الإلكترونية. في جوهرها ، يشبه الهجوم المنتظم DoS ، ولكن بدلاً من موجة من الطلبات من عناوين IP مختلفة ، يتم إرسال مجموعة من رسائل البريد الإلكتروني إلى الخادم ، والتي تصل بكميات هائلة إلى أحد عناوين البريد ، بسبب زيادة التحميل عليها بشكل كبير. مثل هذا الهجوم يمكن أن يؤدي إلى عدم القدرة على استخدام صندوق البريد ، وأحيانا يمكن أن يؤدي إلى فشل الخادم بأكمله. أدى التاريخ الطويل لهذا النوع من الهجمات الإلكترونية إلى عدد من النتائج الإيجابية والسلبية لمسؤولي النظام. تشمل العوامل الإيجابية معرفة جيدة بقصف البريد الإلكتروني وتوافر طرق بسيطة للدفاع ضد مثل هذا الهجوم. تشمل العوامل السلبية عددًا كبيرًا من حلول البرمجيات المتاحة للجمهور لتنفيذ هذه الأنواع من الهجمات وقدرة المهاجم على حماية نفسه بشكل موثوق من الكشف.



من الخصائص المهمة لهذه الهجمة الإلكترونية أنه يكاد يكون من المستحيل استخدامها لتحقيق الربح. حسنًا ، أرسل المهاجم مجموعة من رسائل البريد الإلكتروني إلى أحد صناديق البريد ، حسنًا ، لم يسمح للشخص باستخدام البريد الإلكتروني بشكل طبيعي ، حسنًا ، قام المهاجم باختراق بريد شركة شخص ما وبدأ إرسال بريد إلكتروني جماعي لآلاف رسائل البريد الإلكتروني في جميع أنحاء GAL ، بسبب تعطل الخادم أو بدءه في التباطؤ بحيث أصبح من المستحيل استخدامه ، وماذا بعد؟ يكاد يكون من المستحيل تحويل مثل هذه الجريمة الإلكترونية إلى أموال حقيقية ، لذلك ببساطة يعد تفجير البريد الإلكتروني نادرًا جدًا وقد لا يتذكر مسؤولو النظام عند تصميم البنية الأساسية الحاجة إلى الحماية من مثل هذا الهجوم السيبراني.

ومع ذلك ، على الرغم من أن تفجير البريد الإلكتروني بحد ذاته نشاط تجاري لا معنى له ، فإنه غالبًا ما يكون جزءًا لا يتجزأ من الهجمات الإلكترونية الأخرى الأكثر تعقيدًا ومتعددة المراحل. على سبيل المثال ، عند اختراق البريد واستخدامه لاختطاف حساب في بعض الخدمات العامة ، غالبًا ما يقوم المهاجمون "بتفجير" صندوق بريد الضحية بأحرف لا معنى لها بحيث تضيع رسالة التأكيد في ساحة مشاركاتهم دون أن يلاحظها أحد. يمكن أيضًا استخدام تفجير البريد الإلكتروني كوسيلة للضغط الاقتصادي على المؤسسة. وبالتالي ، فإن القصف النشط لصندوق البريد العام للمؤسسة ، والذي يتم استلام الطلبات من العملاء ، يمكن أن يعقد العمل معهم بشكل خطير ، ونتيجة لذلك ، يمكن أن يؤدي إلى تعطل المعدات والأوامر المعلقة ، بالإضافة إلى فقدان السمعة والأرباح المفقودة.

هذا هو السبب في أن مسؤول النظام لا ينبغي أن ينسى احتمال إجراء تفجير البريد الإلكتروني واتخاذ التدابير اللازمة دائما للحماية من هذا التهديد. بالنظر إلى أن هذا يمكن القيام به حتى في مرحلة بناء البنية التحتية للبريد ، وكذلك الأمر الذي يستغرق مسؤول النظام القليل من الوقت والعمل ، وأسباب موضوعية من أجل عدم توفير البنية التحتية الخاصة بهم مع الحماية من تفجير البريد الإلكتروني ، ببساطة لا يبقى . دعنا نلقي نظرة على كيفية تطبيق الحماية ضد هذا الهجوم السيبراني في الإصدار المفتوح المصدر من Zimbra Collaboration Suite.

في قلب 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 = "الجذر" ؛
$ DB_TABLE_PREFIX = ""؛

بعد ذلك ، يبقى فقط إعادة تشغيل خدمات Zimbra و Zimbra Apache باستخدام أوامر إعادة التشغيل zmcontrol وإعادة التشغيل zmapachectl. بعد ذلك ، يمكنك الوصول إلى واجهة الويب على example.com : 7780 / webui / index.php . الفرق الأساسي هو أن مدخل واجهة الويب هذه غير محمي بأي شكل من الأشكال ، ولمنع الأشخاص غير المصرح لهم من الدخول إليه ، يمكنك ببساطة إغلاق الاتصالات على المنفذ 7780 بعد كل مدخل لواجهة الويب.

تسمح لك حصص إرسال الرسائل الإلكترونية ، والتي يمكن ضبطها بفضل cbpolicyd ، بحماية نفسك من تدفق الرسائل الواردة من الشبكة الداخلية. تتيح لك هذه الحصص تعيين حد أقصى لعدد الأحرف التي يمكن إرسالها من صندوق بريد واحد إلى وحدة زمنية واحدة. على سبيل المثال ، إذا كان مديرو شركتك يرسلون ما يتراوح بين 60 و 80 رسالة بريد إلكتروني في الساعة ، في ضوء الهامش الصغير ، يمكنك تعيين حصة قدرها 100 رسالة إلكترونية في الساعة. من أجل استنفاد مثل هذه الحصة ، سيتعين على المديرين إرسال خطاب واحد كل 36 ثانية. من ناحية ، هذا يكفي للعمل بشكل كامل ، ومن ناحية أخرى ، مع مثل هذه الحصة ، فإن المهاجمين الذين يمكنهم الوصول إلى بريد أحد مديرك لن يرتبوا تفجيرات البريد الإلكتروني أو البريد العشوائي الجماعي في الشركة.

من أجل تعيين هذه الحصة ، من الضروري إنشاء سياسة تقييد جديدة لإرسال الرسائل في واجهة الويب وتحديد أنها تعمل على كل من الرسائل المرسلة داخل المجال وعلى الرسائل التي تعمل على عناوين خارجية. ويتم ذلك على النحو التالي:



بعد ذلك ، سيكون من الممكن تحديد القيود المرتبطة بإرسال الرسائل بمزيد من التفصيل ، على وجه الخصوص ، تعيين الفاصل الزمني الذي سيتم بعده تحديث القيود ، وكذلك الرسالة التي سيحصل عليها المستخدم الذي يتجاوز الحد المسموح به. بعد ذلك ، يمكنك ضبط القيود على إرسال الرسائل. يمكن تعيينها كعدد من الرسائل الصادرة وعدد من وحدات البايت للمعلومات المرسلة. في هذه الحالة ، مع الأحرف التي يتم إرسالها الزائدة عن الحد المحدد ، قم بعمل مختلف. لذلك ، على سبيل المثال ، يمكنك ببساطة حذفها على الفور ، أو يمكنك حفظها بحيث يتم الانتقال فورًا بعد تحديث الحد المسموح به لإرسال الرسائل. يمكن استخدام الخيار الثاني عند تحديد الحد الأمثل لإرسال رسائل البريد الإلكتروني من قبل الموظفين.

بالإضافة إلى القيود المفروضة على إرسال الرسائل ، يسمح لك cbpolicyd بتكوين حد لاستلام الرسائل. يعد هذا التقييد ، للوهلة الأولى ، حلاً ممتازًا للحماية من تفجير البريد الإلكتروني ، ولكن في الواقع ، فإن وضع هذا الحد ، حتى لو كان كبيرًا ، محفوف بحقيقة أنه في بعض الحالات قد لا تصل إليك رسالة مهمة. هذا هو سبب عدم تشجيعه بشدة على تضمين أي قيود على البريد الوارد. ومع ذلك ، إذا كنت لا تزال ترغب في اغتنام فرصة ، فيقترب من تحديد حد الرسائل الواردة التي تحتاج إلى التعامل معها باهتمام خاص. على سبيل المثال ، يمكنك الحد من عدد الرسائل الواردة من الأطراف المقابلة الموثوق بها بحيث إذا تم اختراق خادم البريد الخاص بهم ، فلن يقوم بتنفيذ هجوم غير مرغوب فيه على شركتك.

من أجل حماية نفسك من رمح الرسائل الواردة أثناء تفجير البريد الإلكتروني ، يجب على مسؤول النظام القيام بشيء أكثر ذكاءً من مجرد تقييد البريد الوارد. مثل هذا الحل يمكن أن يكون استخدام القوائم الرمادية. مبدأ إجراءهم هو أن المحاولة الأولى لتوصيل رسالة من مرسل غير موثوق به ، تمت مقاطعة الاتصال بالخادم بشكل مفاجئ ، وهذا هو السبب في فشل تسليم الرسالة. ومع ذلك ، إذا حاول خادم غير موثوق به في فترة معينة إرسال نفس الرسالة ، فلن ينقطع الخادم ونجح تسليمه.

معنى كل هذه الإجراءات هو أن برامج البريد الإلكتروني الجماعي الشامل لرسائل البريد الإلكتروني لا تتحقق عادة من نجاح تسليم الرسالة المرسلة ولا تحاول إرسالها مرة أخرى ، في حين أن الشخص سوف يتأكد بالتأكيد من إرسال رسالته إلى العنوان أم لا.

يمكنك أيضًا تمكين القوائم الرمادية في واجهة الويب cbpolicyd. لكي يعمل كل شيء ، تحتاج إلى إنشاء سياسة تشمل جميع الرسائل الواردة الموجهة إلى المستخدمين على الخادم الخاص بنا ، ثم إنشاء قاعدة قائمة الرمادي على أساس هذه السياسة ، حيث يمكنك تكوين الفاصل الزمني الذي تنتظر خلاله cbpolicyd استجابة متكررة من مجهول المرسل. عادة ما يكون 4-5 دقائق. في الوقت نفسه ، يمكن تهيئة القوائم الرمادية بحيث تؤخذ في الاعتبار جميع المحاولات الناجحة وغير الناجحة لتسليم رسائل من مرسلين مختلفين ، وبناءً على عددهم ، يتم اتخاذ قرار بإضافة المرسل تلقائيًا إلى القوائم البيضاء أو السوداء.

نلفت انتباهكم إلى حقيقة أن استخدام القوائم الرمادية ينبغي التعامل معه بأقصى قدر من المسؤولية. سيكون من الأفضل إذا كان استخدام هذه التقنية يسير جنبًا إلى جنب مع الصيانة المستمرة للقوائم البيضاء والسوداء من أجل استبعاد إمكانية فقدان الحروف المهمة حقًا للمشروع.

بالإضافة إلى ذلك ، يمكن أن تساعد إضافة فحوصات SPF و DMARC و DKIM على الحماية من تفجير البريد. في كثير من الأحيان ، لا تتجاوز الرسائل التي يتم تلقيها أثناء عملية تفجير البريد عمليات التحقق هذه. تم شرح كيفية القيام بذلك في أحد مقالاتنا السابقة .

وبالتالي ، فإن حماية نفسك من تهديدات مثل تفجير البريد الإلكتروني أمر بسيط للغاية ، ويمكنك القيام بذلك حتى في مرحلة بناء البنية التحتية Zimbra لمؤسستك. ومع ذلك ، من المهم التأكد باستمرار من أن مخاطر استخدام هذه الحماية لا تتجاوز الفوائد التي تتلقاها.

بالنسبة لجميع الأسئلة المتعلقة بـ Zextras Suite ، يمكنك الاتصال بممثل شركة "Zextras" Katerina Triandafilidi عن طريق البريد الإلكتروني katerina@zextras.com