يعد تفجير البريد أحد أقدم أنواع الهجمات الإلكترونية. في جوهره ، يشبه هجوم 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 = "الجذر" ؛
$ DB_TABLE_PREFIX = "" ؛
بعد ذلك ، يبقى فقط إعادة تشغيل خدمتي Zimbra و Zimbra Apache باستخدام أوامر إعادة تشغيل zmcontrol وإعادة تشغيل zmapachectl. بعد ذلك ، سيكون لديك حق الوصول إلى واجهة الويب على : 7780 / webui / index.php. فارق بسيط هو أن مدخل واجهة الويب هذه ليس محميًا بعد بأي شكل من الأشكال ، ومن أجل منع الأشخاص غير المصرح لهم من الدخول إليها ، يمكنك ببساطة إغلاق الاتصالات على المنفذ 7780 بعد كل دخول إلى واجهة الويب.
للحماية من تدفق رسائل البريد الإلكتروني الواردة من الشبكة الداخلية ، يمكنك استخدام الحصص لإرسال رسائل البريد الإلكتروني ، والتي يمكن تعيينها بفضل cbpolicyd. تسمح لك هذه الحصص بتعيين حد أقصى لعدد الرسائل التي يمكن إرسالها من صندوق بريد واحد في وحدة زمنية واحدة. على سبيل المثال ، إذا أرسل المديرون في عملك ما معدله 60-80 بريدًا إلكترونيًا في الساعة ، فيمكنك تعيين حصة تبلغ 100 بريد إلكتروني في الساعة مع مساحة صغيرة. من أجل استنفاد هذه الحصة ، سيتعين على المديرين إرسال حرف واحد كل 36 ثانية. من ناحية ، هذا يكفي للعمل بشكل كامل ، ومن ناحية أخرى ، مع مثل هذه الحصة ، لن يقوم المهاجمون الذين تمكنوا من الوصول إلى بريد أحد المديرين لديك بترتيب تفجير بريد أو هجوم بريد عشوائي ضخم على المؤسسة .
لتعيين مثل هذه الحصة ، تحتاج إلى إنشاء سياسة جديدة لتقييد إرسال البريد الإلكتروني في واجهة الويب وتحديد أنها تنطبق على كل من رسائل البريد الإلكتروني المرسلة داخل النطاق ورسائل البريد الإلكتروني المرسلة إلى عناوين خارجية. هذا يفعل كما يلي:
بعد ذلك ، سيكون من الممكن تحديد بمزيد من التفصيل القيود المرتبطة بإرسال الرسائل ، على وجه الخصوص ، تعيين الفاصل الزمني الذي سيتم بعده تحديث القيود ، وكذلك الرسالة التي سيتلقاها المستخدم الذي تجاوز الحد المسموح به. بعد ذلك ، يمكنك ضبط القيود المفروضة على إرسال الرسائل. يمكن تعيينه كعدد للرسائل الصادرة وعدد بايتات المعلومات المرسلة. في نفس الوقت ، مع الرسائل المرسلة التي تتجاوز الحد المعين ، تصرف بشكل مختلف. لذلك ، على سبيل المثال ، يمكنك ببساطة حذفها على الفور ، أو يمكنك حفظها بحيث تنتقل فورًا بعد تحديث حد إرسال الرسائل. يمكن استخدام الخيار الثاني عند تحديد القيمة المثلى للحد الأقصى لإرسال رسائل البريد الإلكتروني إلى الموظفين.
بالإضافة إلى إرسال حدود البريد الإلكتروني ، يسمح لك cbpolicyd بتعيين حد لتلقي رسائل البريد الإلكتروني. يعتبر هذا الحد ، للوهلة الأولى ، حلاً ممتازًا للحماية من تفجير البريد ، ومع ذلك ، في الواقع ، فإن وضع مثل هذا الحد ، حتى لو كان كبيرًا ، محفوف بحقيقة أنه في ظل ظروف معينة قد لا يصل إليك خطاب مهم . هذا هو السبب في عدم تشجيع تمكين أي قيود على البريد الوارد بشدة. ومع ذلك ، إذا قررت انتهاز الفرصة ، فأنت بحاجة إلى التعامل مع إعداد حد الرسائل الواردة باهتمام خاص. على سبيل المثال ، يمكنك تحديد عدد رسائل البريد الإلكتروني الواردة من الأطراف المقابلة الموثوقة بحيث إذا تم اختراق خادم البريد الخاص بهم ، فلن يرسل بريدًا عشوائيًا إلى عملك.
للحماية من تدفق الرسائل الواردة من تفجير البريد ، يجب على مسؤول النظام أن يفعل شيئًا أكثر ذكاءً من مجرد تقييد البريد الوارد. يمكن أن يكون مثل هذا الحل استخدام القوائم الرمادية. مبدأ عمليتهم هو أنه في المحاولة الأولى لتسليم رسالة من مرسل غير موثوق به ، يتم قطع الاتصال بالخادم فجأة ، مما يؤدي إلى فشل تسليم الرسالة. ومع ذلك ، إذا حاول خادم غير موثوق به إرسال نفس البريد الإلكتروني مرة أخرى خلال فترة زمنية معينة ، فلن يسقط الخادم الاتصال ويكون تسليمه ناجحًا.
الهدف من كل هذه الإجراءات هو أن برامج البريد الإلكتروني المجمعة عادةً لا تتحقق من نجاح الرسالة المرسلة ولا تحاول إرسالها مرة أخرى ، بينما يتأكد الشخص بالتأكيد مما إذا كان قد تم إرسال رسالته إلى العنوان أم لا .
يمكنك أيضًا تمكين القائمة الرمادية في واجهة ويب cbpolicyd. لكي يعمل كل شيء ، تحتاج إلى إنشاء سياسة تتضمن جميع الرسائل الواردة الموجهة إلى المستخدمين على خادمنا ، وبعد ذلك ، بناءً على هذه السياسة ، قم بإنشاء قاعدة القائمة الرمادية ، حيث يمكنك تكوين الفاصل الزمني الذي تنتظر خلاله cbpolicyd للحصول على رد ثانٍ من مرسل غير مألوف. عادة ما تكون 4-5 دقائق. في الوقت نفسه ، يمكن تكوين القوائم الرمادية بحيث تؤخذ في الاعتبار جميع المحاولات الناجحة وغير الناجحة لتسليم الرسائل من مرسلين مختلفين ، وبناءً على رقمهم ، يتم اتخاذ قرار بإضافة المرسل تلقائيًا إلى القوائم البيضاء أو السوداء.
نلفت انتباهك إلى حقيقة أنه يجب التعامل مع استخدام القوائم الرمادية بأقصى قدر من المسؤولية. سيكون من الأفضل أن يسير استخدام هذه التقنية جنبًا إلى جنب مع الصيانة المستمرة للقوائم البيضاء والسوداء من أجل استبعاد احتمال فقد الحروف المهمة حقًا للمؤسسة.
بالإضافة إلى ذلك ، يمكن أن تساعد إضافة فحوصات SPF و DMARC و DKIM في الحماية من تفجير البريد الإلكتروني. في كثير من الأحيان ، الرسائل التي تأتي في عملية تفجير البريد لا تمر بمثل هذه الفحوصات. تم شرح كيفية القيام بذلك .
وبالتالي ، من السهل جدًا حماية نفسك من مثل هذا التهديد مثل تفجير البريد ، ويمكنك القيام بذلك حتى في مرحلة بناء البنية التحتية لـ Zimbra لشركتك. ومع ذلك ، من المهم التأكد باستمرار من أن مخاطر استخدام هذه الحماية لا تفوق الفوائد التي تتلقاها.
المصدر: www.habr.com