निवर्तमान स्पैम को रोकें


5

अपने सर्वर को छोड़ने से स्पैम को रोकने के कुछ तरीके क्या हैं, एक होस्टिंग खाते को समझौता करना चाहिए?

Cpanel के साथ एक सर्वर पर ग्राहकों का एक समूह है, लेकिन अगर एक खाता समझौता किया गया था बस एक मौका को रोकने के लिए एक तरीका था सोच रहा था।

  • जब मेरा मतलब था कि मैंने समझौता किया है, तो क्लाइंट साइन अप करता है या क्लाइंट अकाउंट हैक हो जाता है और उसका अकाउंट स्पैम के लिए इस्तेमाल किया जाता है।

  • क्या आप किसी प्रकार के फ़िल्टर / ब्लैकलिस्ट शब्दों को एक्ज़िम या स्पैमसैसेन में सेट नहीं कर सकते हैं जो मेल से बाहर जाना बंद / रोक देगा अगर यह मेल खाता है?

जवाबों:


6

समझौता मत करो। गंभीरता से।

  • अपने यातायात की निगरानी करें। आप समझ जाएंगे कि क्या सामान्य है और असामान्य ट्रैफ़िक को पहचानने में सक्षम है।

  • अनावश्यक डेमों को बंद करें। यदि सर्वर को मेल भेजने की आवश्यकता नहीं है, तो Sendmail या पोस्टफ़िक्स न चलाएँ।

  • SSH पहुंच को प्रतिबंधित करें और / या SSH को एक गैर-मानक पोर्ट असाइन करें (जैसे डिफ़ॉल्ट पोर्ट 22 का उपयोग न करें)। यदि आपको पोर्ट 22 का उपयोग करने की आवश्यकता है, तो इनहाउस SSH बॉट प्रमाणीकरण प्रयासों को ट्रैक करने और रोकने के लिए DenyHosts जैसी सेवा के साथ वृद्धि करें ।

  • अपने और अपने ग्राहकों के लिए मजबूत पासवर्ड का उपयोग करें या लागू करें।

ओह, और यह: लड़ स्पैम - मैं क्या कर सकता हूँ: ईमेल प्रशासक, डोमेन स्वामी, या उपयोगकर्ता?


जब मेरा मतलब था कि मैंने समझौता किया है, तो क्लाइंट साइन अप करता है या क्लाइंट हैक हो जाता है और स्पैम के लिए इस्तेमाल किया जाता है।
निकी विल्सन

मै समझता हुँ। अपने ग्राहकों के लिए मजबूत पासवर्ड का उपयोग करें। उनकी गतिविधि की निगरानी करें।
इविहित

1
यह सभी अच्छी सामान्य सलाह है, और यहाँ पालन किया जाना चाहिए, लेकिन वास्तव में वेब होस्टिंग प्रदाताओं के लिए विशिष्ट चीजों को संबोधित नहीं करता है।
माइकल हैम्पटन

क्या यह एक वेब होस्ट है? मैं ओपी से नहीं बता सकता।
इविहित

1
मैं बता सकता था। सभी आवश्यक संकेत दिए हैं वहाँ (cpanel के साथ एक सर्वर पर ग्राहकों की गुच्छा) ...
माइकल हैम्पटन

3

सबसे आसान काम पोर्ट 25 के लिए आउटगोइंग कनेक्शन को ब्लॉक करना होगा जब तक कि क्लाइंट "अनुरोध" नहीं करता कि यह उनके आईपी के लिए अनब्लॉक हो। वास्तव में पहली जगह में CPanel होस्टिंग साइट से मेल सर्वर चलाने वाला कोई भी व्यक्ति नहीं होना चाहिए (यदि वे किसी अन्य सर्वर द्वारा "भेजा गया" ई-मेल उत्पन्न कर रहे हैं, तो उसे उस सर्वर पर पोर्ट 587 प्रति RFC और भेजा जाना चाहिए 1998 से इस तरह से है)।

मैं वास्तव में चाहता हूं कि अधिक प्रदाताओं के पास आपके विचार का स्तर था, भले ही आप गंतव्य पोर्ट 25 यातायात को अवरुद्ध न करें। हम विचार की सराहना करते हैं, और फ़ायरवॉल की और भी अधिक सराहना करेंगे।


3

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

आम तौर पर सर्वर को सुरक्षित करने के लिए आपको उन चीजों से अलग होना चाहिए, जिन पर विचार करें:

  • जैसे ग्राहक डेटा के खिलाफ मैलवेयर स्कैन एक उपकरण का उपयोग कर चलाएँ maldet । अपनी परिभाषाएँ अद्यतन रखें।

  • केवल अपने स्थानीय मेल सर्वर पर जावक SMTP ट्रैफ़िक की अनुमति दें, जहाँ आप लॉग इन करें और आउटगोइंग मेल पर कुछ नियंत्रण कर सकते हैं। एक आउटबाउंड फ़ायरवॉल नियम जोड़ें, जो आपके मेल सर्वर को दूरस्थ होस्ट पर पोर्ट 25 से कनेक्ट करने से कुछ भी रोकता है। एक उदाहरण नियम हो सकता है:

    iptables -I OUTPUT -m owner ! --uid-owner EXIM_USER -p tcp --dport 25 -j DROP
    

    (ग्राहक के थर्ड पार्टी मेल सर्वर जैसे जीमेल में प्रमाणित एसएमटीपी ट्रैफ़िक, पोर्ट 587 पर चलेगा और इससे अप्रभावित रहेगा।)


1

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

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


0

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

एक और सुझाव है कि अपने ग्राहक के ऐप्स पर एक आउटबाउंड SMTP आउटबाउंड SMTP के लिए सेट करें। उनके वेब सर्वर को मेल उत्पन्न नहीं करना चाहिए, इसलिए यदि वे करते हैं, तो आप यह देखना चाहते हैं कि इसके बारे में क्या है - शायद आप मूल स्रोत में कुछ अंतर्दृष्टि को चमका सकते हैं। शायद कोशिश करने के लिए अन्य चीजें:

यदि आप अपने ग्राहक के आईपी ब्लॉक को जानते हैं, तो आप वेब होस्ट को टेलनेट, रिमोट डेस्कटॉप (3389) और एसएसएच ट्रैफ़िक पर कब्जा कर सकते हैं और परिणामों से अपने आईपी ब्लॉक को फ़िल्टर कर सकते हैं। इससे आपको अंदाजा लगना चाहिए कि अगर कोई भी उनके अलावा मेजबान को नियंत्रित कर रहा है।

स्नूप का एक अन्य प्रकार आईआरसी है, क्योंकि यह प्रोटोकॉल व्यापक रूप से ज़ोंबी कंप्यूटर के लिए कमांड-एंड-कंट्रोल नेट के रूप में उपयोग किया जाता है। या बस अपने फ़ायरवॉल पर IRC पोर्ट ड्रॉप करें उसी तरह से जब आपने SMTP गिराया था।

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

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


-3

CSF (कॉन्फ़िगर्सवर फ़ायरवॉल) स्थापित करें


2
क्या आप इस पर विस्तार करना चाहेंगे कि यह इस स्थिति में कैसे मदद कर सकता है?
user619714

CSF केवल अन्य उपयोगकर्ताओं को स्पैम को भेजने से रोकने के लिए आसान बनाता है। ओपी पूछ रहा है कि उन उपयोगकर्ताओं को ई-मेल भेजने की अनुमति देने वाले स्पैम को कैसे फ़िल्टर किया जाए
टिफ़नी वॉकर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.