जोम्ब्रा और मेल बम डिफेंस

ईमेल बमबारी सबसे पुराने प्रकार के साइबर हमलों में से एक है। इसके मूल में, यह एक नियमित DoS हमले से मिलता जुलता है, लेकिन विभिन्न IP- पतों से अनुरोधों की एक लहर के बजाय, ईमेल का एक शाफ्ट सर्वर पर भेजा जाता है, जो भारी मात्रा में मेल पतों में से एक पर पहुंचता है, जिसके कारण उस पर लोड काफी कम हो जाता है। इस तरह के हमले से मेलबॉक्स का उपयोग करने में असमर्थता हो सकती है, और कभी-कभी पूरे सर्वर की विफलता भी हो सकती है। इस प्रकार के साइबर हमले के लंबे इतिहास ने सिस्टम प्रशासकों के लिए कई सकारात्मक और नकारात्मक परिणाम दिए हैं। सकारात्मक कारकों में ईमेल बमबारी और इस तरह के हमले से बचाव के सरल तरीकों की उपलब्धता का अच्छा ज्ञान शामिल है। नकारात्मक कारकों में इन प्रकार के हमलों को अंजाम देने के लिए बड़ी संख्या में सार्वजनिक रूप से उपलब्ध सॉफ़्टवेयर समाधान शामिल हैं और किसी हमलावर की मज़बूती से खुद को पहचानने से बचाने की क्षमता है।



इस साइबरबैट की एक महत्वपूर्ण विशेषता यह है कि लाभ के लिए इसका उपयोग करना लगभग असंभव है। खैर, हमलावर ने मेलबॉक्सेस में से एक को एक ईमेल का एक शाफ़्ट भेजा, ठीक है, उसने व्यक्ति को सामान्य रूप से ईमेल का उपयोग करने की अनुमति नहीं दी, ठीक है, हमलावर ने किसी के कॉर्पोरेट मेल को हैक कर लिया और जीएएल पर पूरे हज़ारों ईमेलों को बड़े पैमाने पर मेल करना शुरू कर दिया, जिसके कारण सर्वर या तो दुर्घटनाग्रस्त हो गया या धीमा होना शुरू हो गया। ताकि इसका उपयोग करना असंभव हो जाए, और आगे क्या? इस तरह के साइबर अपराध को वास्तविक धन में बदलना लगभग असंभव है, इसलिए बुनियादी ढांचा तैयार करते समय बस ईमेल बमबारी वर्तमान में काफी दुर्लभ है और सिस्टम प्रशासक को इस तरह के साइबर हमले से बचाने की आवश्यकता शायद याद नहीं है।

फिर भी, इस तथ्य के बावजूद कि ईमेल बमबारी स्वयं एक संवेदनहीन व्यावसायिक गतिविधि है, यह अक्सर अन्य, अधिक जटिल और बहु-स्तरीय साइबरबैट का एक अभिन्न अंग है। उदाहरण के लिए, जब मेल हैक किया जाता है और किसी सार्वजनिक सेवा में किसी खाते को हाइजैक करने के लिए उपयोग किया जाता है, तो हमलावर अक्सर पीड़ित के मेलबॉक्स को अर्थहीन पत्रों के साथ "बम" कर देते हैं ताकि पुष्टि संदेश उनकी धारा में खो जाए और किसी का ध्यान न जाए। ईमेल बमबारी का उपयोग उद्यम पर आर्थिक दबाव के साधन के रूप में भी किया जा सकता है। इस प्रकार, एक उद्यम के सार्वजनिक मेलबॉक्स की सक्रिय बमबारी, जिसके लिए ग्राहकों से आवेदन प्राप्त किए जाते हैं, गंभीरता से उनके साथ काम को जटिल कर सकते हैं और इसके परिणामस्वरूप, उपकरण डाउनटाइम, बकाया आदेश, साथ ही प्रतिष्ठा और खो लाभ का नुकसान हो सकता है।

इसीलिए सिस्टम एडमिनिस्ट्रेटर को ईमेल बॉम्बिंग करने की संभावना के बारे में नहीं भूलना चाहिए और इस खतरे से बचाव के लिए हमेशा जरूरी उपाय करने चाहिए। यह देखते हुए कि यह मेल इन्फ्रास्ट्रक्चर के निर्माण के स्तर पर भी किया जा सकता है, साथ ही यह भी कि यह सिस्टम प्रशासक को बहुत कम समय और श्रम लगता है, उद्देश्य यह है कि ईमेल बमबारी से सुरक्षा प्रदान करने के लिए उनके बुनियादी ढांचे को उपलब्ध नहीं कराया जाए, बस । आइए एक नजर डालते हैं कि इस साइबर हमले से सुरक्षा के लिए जोम्बाड़ा सहयोग सूट ओपन-सोर्स संस्करण में कैसे लागू किया गया है।

ज़िचरा के दिल में पोस्टफिक्स है - इस समय सबसे विश्वसनीय और कार्यात्मक ओपन सोर्स मेल ट्रांसफर एजेंटों में से एक। और इसके खुलेपन का एक मुख्य लाभ यह है कि यह कार्यक्षमता के विस्तार के लिए तीसरे पक्ष के समाधानों की एक विस्तृत विविधता का समर्थन करता है। विशेष रूप से, Postfix पूरी तरह से cbpolicyd, मेल सर्वर के लिए एक उन्नत साइबर सुरक्षा उपयोगिता का समर्थन करता है। स्पैम से सुरक्षा करने और श्वेतसूची, ब्लैक लिस्ट और ग्रे लिस्ट बनाने के अलावा, cbpolicyd जोम्फ्रा प्रशासक को SPF हस्ताक्षर सत्यापन, साथ ही ईमेल या डेटा प्राप्त करने और भेजने की सीमा निर्धारित करने की अनुमति देता है। वे स्पैम और फ़िशिंग ईमेल के खिलाफ विश्वसनीय सुरक्षा प्रदान कर सकते हैं, साथ ही साथ सर्वर को ईमेल बमबारी से बचा सकते हैं।

सिस्टम एडमिनिस्ट्रेटर से आवश्यक पहली चीज cbpolicyd मॉड्यूल की सक्रियता है, जो कि इंफ्रास्ट्रक्चर एमटीए सर्वर पर जोम्बारा सहयोग सूट ओएसई में पूर्वस्थापित है। यह कमांड 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 = "";

उसके बाद, यह केवल Zmcontrol पुनरारंभ और zmapachectl पुनरारंभ आदेशों का उपयोग करके ज़िम्द्रा और ज़िचरा अपाचे सेवाओं को पुनरारंभ करने के लिए रहता है। उसके बाद, आपके पास example.com पर वेब इंटरफ़ेस का उपयोग होगा : 7780 / webui / index.php । मुख्य बारीकियों यह है कि इस वेब इंटरफेस के प्रवेश द्वार को किसी भी तरह से संरक्षित नहीं किया गया है और अनधिकृत व्यक्तियों को इसे प्रवेश करने से रोकने के लिए, आप वेब इंटरफेस के प्रत्येक प्रवेश के बाद पोर्ट 7780 पर कनेक्शन को बंद कर सकते हैं।

ईमेल भेजने के लिए कोटा, जो cbpolicyd के लिए धन्यवाद सेट किया जा सकता है, आपको आंतरिक नेटवर्क से आने वाले पत्रों के प्रवाह से खुद को बचाने की अनुमति देता है। ऐसे कोटा आपको अधिकतम अक्षरों की सीमा तय करने की अनुमति देते हैं जिन्हें एक मेलबॉक्स से एक यूनिट तक भेजा जा सकता है। उदाहरण के लिए, यदि आपकी कंपनी के प्रबंधक प्रति घंटे औसतन 60-80 ईमेल भेजते हैं, तो, छोटे मार्जिन को देखते हुए, आप प्रति घंटे 100 ईमेल का कोटा निर्धारित कर सकते हैं। ऐसे कोटा को समाप्त करने के लिए, प्रबंधकों को हर 36 सेकंड में एक पत्र भेजना होगा। एक तरफ, यह पूरी तरह से काम करने के लिए पर्याप्त है, और दूसरी तरफ, ऐसे कोटा के साथ, हमलावर जो आपके प्रबंधकों में से एक के मेल तक पहुंच प्राप्त करते हैं, वे उद्यम पर ईमेल बमबारी या बड़े स्पैम हमलों की व्यवस्था नहीं करेंगे।

इस तरह का कोटा निर्धारित करने के लिए, वेब इंटरफेस में पत्र भेजने के लिए एक नई प्रतिबंध नीति बनाना आवश्यक है और यह निर्दिष्ट करना चाहिए कि यह डोमेन के भीतर भेजे गए पत्रों और बाहरी पते पर अभिनय करने वाले पत्रों पर दोनों कार्य करता है। यह निम्नानुसार किया जाता है:



उसके बाद, पत्रों को भेजने के साथ जुड़े प्रतिबंधों को और अधिक विस्तार से निर्दिष्ट करना संभव होगा, विशेष रूप से, समय अंतराल निर्धारित करें जिसके बाद प्रतिबंधों को अपडेट किया जाएगा, साथ ही यह संदेश भी दिया जाएगा कि उपयोगकर्ता जो अपनी सीमा से अधिक हो जाएगा। उसके बाद, आप पत्र भेजने पर प्रतिबंध सेट कर सकते हैं। इसे आउटगोइंग अक्षरों की संख्या और प्रेषित सूचना के बाइट्स की संख्या के रूप में सेट किया जा सकता है। इस मामले में, निर्दिष्ट सीमा से अधिक भेजे जाने वाले पत्रों के साथ, अलग-अलग तरीके से करें। इसलिए, उदाहरण के लिए, आप उन्हें तुरंत हटा सकते हैं, या आप उन्हें सहेज सकते हैं ताकि वे संदेश भेजने की सीमा को अपडेट करने के तुरंत बाद जाएं। कर्मचारियों द्वारा ईमेल भेजने के लिए इष्टतम सीमा की पहचान करते समय दूसरे विकल्प का उपयोग किया जा सकता है।

पत्र भेजने पर प्रतिबंध के अलावा, cbpolicyd आपको पत्र प्राप्त करने की सीमा को कॉन्फ़िगर करने की अनुमति देता है। इस तरह का प्रतिबंध, पहली नज़र में, ईमेल बमबारी से सुरक्षा के लिए एक उत्कृष्ट समाधान है, लेकिन वास्तव में इस तरह की सीमा की स्थापना, भले ही बड़ी हो, इस तथ्य से भरा है कि कुछ शर्तों के तहत एक महत्वपूर्ण पत्र आप तक नहीं पहुंच सकता है। यही कारण है कि यह आने वाले मेल के लिए किसी भी प्रतिबंध को शामिल करने के लिए अत्यधिक हतोत्साहित है। हालांकि, यदि आप अभी भी एक मौका लेने का फैसला करते हैं, तो आने वाले संदेशों की सीमा को निर्धारित करने के लिए आपको विशेष ध्यान देने की आवश्यकता है। उदाहरण के लिए, आप भरोसेमंद समकक्षों से आने वाले पत्रों की संख्या को सीमित कर सकते हैं ताकि यदि उनके मेल सर्वर से समझौता किया गया हो, तो यह आपकी कंपनी पर स्पैम हमला नहीं करेगा।

ईमेल बमबारी के दौरान आने वाले संदेशों के शाफ्ट से खुद को बचाने के लिए, सिस्टम एडमिनिस्ट्रेटर को आने वाले मेल को प्रतिबंधित करने की तुलना में कुछ स्मार्ट करना चाहिए। ऐसा समाधान ग्रे सूचियों का उपयोग हो सकता है। उनकी कार्रवाई का सिद्धांत यह है कि एक अविश्वसनीय प्रेषक से एक संदेश देने का पहला प्रयास, सर्वर से कनेक्शन अचानक बाधित हो जाता है, यही कारण है कि संदेश का वितरण विफल हो जाता है। हालाँकि, यदि एक निश्चित अवधि में अविश्वसनीय सर्वर फिर से उसी संदेश को भेजने का प्रयास करता है, तो सर्वर डिस्कनेक्ट नहीं होता है और इसकी डिलीवरी सफल होती है।

इन सभी कार्यों का अर्थ यह है कि ईमेल के स्वचालित सामूहिक मेलिंग के कार्यक्रम आमतौर पर भेजे गए संदेश की डिलीवरी की सफलता को सत्यापित नहीं करते हैं और इसे दूसरी बार भेजने का प्रयास नहीं करते हैं, जबकि व्यक्ति निश्चित रूप से यह सुनिश्चित करेगा कि उसका पत्र पते पर भेजा गया था या नहीं।

आप cbpolicyd वेब इंटरफ़ेस में ग्रे सूचियों को भी सक्षम कर सकते हैं। काम करने के लिए सब कुछ करने के लिए, एक नीति बनाना आवश्यक है जिसमें हमारे सर्वर पर उपयोगकर्ताओं को संबोधित सभी आने वाले पत्र शामिल होंगे, और फिर इस नीति के आधार पर एक Greylisting नियम बनाएं, जहां आप उस अंतराल को कॉन्फ़िगर कर सकते हैं जिसके दौरान cbpolicyd एक अज्ञात से दोहराया प्रतिक्रिया की प्रतीक्षा करेगा इस। आमतौर पर यह 4-5 मिनट है। उसी समय, ग्रे सूचियों को कॉन्फ़िगर किया जा सकता है ताकि विभिन्न प्रेषकों से पत्र देने के सभी सफल और असफल प्रयासों को ध्यान में रखा जाए और, उनकी संख्या के आधार पर, स्वचालित रूप से प्रेषक को सफेद या काली सूची में जोड़ने का निर्णय लिया जाता है।

हम इस तथ्य पर आपका ध्यान आकर्षित करते हैं कि ग्रे सूचियों का उपयोग अधिकतम जिम्मेदारी के साथ किया जाना चाहिए। यह सबसे अच्छा होगा यदि इस तकनीक का उपयोग सफेद और काली सूचियों के निरंतर रखरखाव के साथ हाथ में जाता है ताकि उन पत्रों को खोने की संभावना को बाहर किया जा सके जो उद्यम के लिए वास्तव में महत्वपूर्ण हैं।

इसके अलावा, एसपीएफ, डीएमएआरसी और डीकेआईएम चेक को जोड़ने से मेल बॉम्बिंग से बचाव में मदद मिल सकती है। अक्सर, मेल बमबारी प्रक्रिया के दौरान प्राप्त पत्र ऐसे चेक पास नहीं करते हैं। यह कैसे करना है यह हमारे पिछले लेखों में से एक में वर्णित किया गया था।

इस प्रकार, ईमेल बमबारी के रूप में इस तरह के खतरों से खुद को बचाना काफी सरल है, और आप अपने उद्यम के लिए जोम्ब्रा इंफ्रास्ट्रक्चर के निर्माण के स्तर पर भी ऐसा कर सकते हैं। हालांकि, यह सुनिश्चित करना महत्वपूर्ण है कि इस तरह के संरक्षण का उपयोग करने से होने वाले जोखिम कभी भी आपको मिलने वाले लाभों से अधिक न हों।

Zextras Suite से संबंधित सभी प्रश्नों के लिए, आप Zextras Katerina Triandafilidi के प्रतिनिधि से ई-मेल katerina@zextras.com पर संपर्क कर सकते हैं