अपनी साइट को स्पैमर्स और हाइजैकिंग से बचाना

यह लेख मौलिक रूप से कुछ भी नया नहीं होगा, लेकिन कुछ अनुभव के साथ एक स्पैमर (पहले से ही पूर्व) की ओर से देखने में बहुत रुचि लेंगे। इस लेख को पढ़ने के बाद, हबर को लिखने का विचार बहुत पहले आया था, जिसने केवल एक मुस्कुराहट का कारण बना। यह सिर्फ इतना हुआ कि बहुत समय पहले, विश्वविद्यालय में अध्ययन करते समय, मुझे दूरस्थ काम की तलाश थी, क्योंकि किसी तरह के मनोरंजन का उल्लेख नहीं करना, छात्रवृत्ति पर टिकना मुश्किल है। फिर एक दोस्त ने मुझे उस कंपनी में आमंत्रित किया, जहाँ उसने काम किया था। कार्य सरल था - कुछ साइटों के लिंक को कहीं भी छोड़ दें, साथ ही साथ कुछ संदेश भी जोड़ दें, अर्थात्। नियमित स्पैम। यहां, जैसा कि आप समझते हैं, बिल्कुल नहीं कैप्चा, कुकीज़ या जावास्क्रिप्ट की जांच करने से स्थिति नहीं बचती है, क्योंकि एक सामान्य व्यक्ति एक सामान्य ब्राउज़र का उपयोग करके पंजीकृत होता है। स्वचालित स्पैमिलोक के संबंध में, स्थिति समान है यदि वे "स्क्रिप्टेड ब्राउज़र" का एक प्रकार हैं। हालांकि, स्पैमर के जीवन को जटिल बनाने के तरीके हैं और यदि पूरी तरह से हटाया नहीं जाता है, तो अपनी साइट पर स्पैम के प्रवाह को काफी कम करें।


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

साइट को संसाधन डेटाबेस में प्राप्त करने से सुरक्षा

संसाधन आधार उन साइटों की सूची के साथ एक बड़ा कचरा है, जिस पर आप संभावित रूप से एक लिंक बना सकते हैं। ऐसे डेटाबेस का उपयोग सभी प्रकार के स्पैम कार्यक्रमों को फिर से भरने के लिए किया जाता है जो उनके गंदे काम करने की कोशिश करेंगे। सफलता की दर बहुत अधिक नहीं है, लगभग 5-10% (डेटाबेस की गुणवत्ता के आधार पर), हालांकि, डेटाबेस में एक लाख साइटें (और यह एक बड़ा डेटाबेस भी नहीं है), आपको 50,000-100,000 लिंक मिल सकते हैं, और यह पहले से ही बहुत कुछ है। स्वाभाविक रूप से, यह एक बार में नहीं किया जाता है, क्योंकि साइट तुरंत खोज इंजन के स्नान में होगी, लेकिन आप धीरे-धीरे निर्माण कर सकते हैं और एक समय में एक से अधिक साइट को बढ़ावा दे सकते हैं। लेकिन यह एक और सवाल है, और हम विषय पर लौटते हैं। डेटाबेस के लिए साइटों को खोजने का सबसे लोकप्रिय और तार्किक तरीका सभी समान खोज इंजनों का सही उपयोग है। और साइटों को उनके प्लेटफार्मों के पैरों के निशान (विशिष्ट विशेषताओं) द्वारा खोजा जाता है। उदाहरण के लिए, एक स्पैमर वर्डप्रेस का उपयोग करने वाली साइट पर एक बार एक लिंक छोड़ने में कामयाब रहा। वह तय करता है कि आपको अपने संसाधन आधार के लिए जितनी संभव हो उतनी ही साइटें जोड़ने की आवश्यकता है, वह Google को खोलता है और "inurl: wp-login.php" जैसी किसी चीज़ में प्रवेश करता है, जिसके बाद आप सुरक्षित रूप से अपने डेटाबेस में साइट जोड़ सकते हैं (स्वाभाविक रूप से, यह सब हो चुका है) स्वचालित रूप से)। यदि उसे एक निश्चित विषय की आवश्यकता है, उदाहरण के लिए, "अचल संपत्ति", तो अनुरोध होगा: "अचल संपत्ति inurl: wp-login.php"। ऐसे कीवर्ड जोड़कर, आप खोज इंजनों की अधिकतम संख्या को प्रदर्शित परिणामों को सीमित कर सकते हैं। इसलिए तार्किक निष्कर्ष: पैरों के निशान से छुटकारा पाएं। लोकप्रिय सीएमएस के लिए बहुत सारे प्लगइन्स हैं जो "सुंदर लिंक" बनाते हैं - उनका उपयोग करें। इसके अलावा, साइट के फ़ुटर्स से ब्ला-ब्ला द्वारा संचालित सभी प्रकार के हटाना न भूलें, और यदि आप डेवलपर्स को श्रद्धांजलि देना चाहते हैं, तो टेक्स्ट को बदलें या इसे तस्वीर के साथ बदलें।
बेशक, अधिक परिष्कृत तरीके हैं जो स्पैमर आधार बनाते हैं, लेकिन उनकी समीक्षा अपने आप में लेख पर आ जाएगी। यदि समाज इस मुद्दे में दिलचस्पी दिखाता है, तो शायद मैं हर चीज के बारे में और अधिक विस्तार से लिखूंगा।

लिंक बिल्डिंग प्रोटेक्शन

लिंक बिल्डरों वे लोग हैं जो उच्च गुणवत्ता वाले स्पैम करने वाले हैं। उनकी ख़ासियत यह है कि वे लगभग हर जगह से गुजरते हैं, जहां, विचार के अनुसार, केवल एक व्यक्ति को पास होना चाहिए। लिंकबिल्डर उत्पादकता कार्यक्रमों की तुलना में बहुत कम है, और प्रति दिन लगभग 40 लिंक है। वे टिप्पणियों में विषयगत सवालों के जवाब देने की कोशिश करते हैं, जिससे उनकी पहचान अक्सर मुश्किल हो जाती है।
उनके खिलाफ सुरक्षा के लिए सबसे कट्टरपंथी कदम संदेश मॉडरेशन की शुरूआत होगी। इसे किसी भी नियम से सुगम बनाया जा सकता है, जैसे "लिंक वाले केवल संदेशों का मॉडरेशन" या "उन उपयोगकर्ताओं का मॉडरेशन, जिनके पास कम से कम अन्य संदेश हैं।" मैं पंजीकरण की तारीख से मॉडरेशन भी जोड़ूंगा, एक स्पैमर आपकी साइट को 5 दिनों या उसके बाद याद रखने की संभावना नहीं है।
यदि कोई मॉडरेशन आपके लिए अस्वीकार्य है, तो एक स्पैमर को अक्सर पंजीकरण चरण में रोका जा सकता है। अधिकांश स्पैमर तथाकथित "अस्थायी मेल" सेवाओं का उपयोग करते हैं। उनमें से सबसे प्रसिद्ध और लोकप्रिय मेलिनेटर है। इसकी लोकप्रियता इस तथ्य के कारण है कि हजारों डोमेन इसे संदर्भित करते हैं, जो खुले स्रोतों में नहीं हैं, और आप अपना खुद का भी जोड़ सकते हैं। यानी स्पैमर खरीदता है (या एक मुफ़्त रजिस्टर करता है) डोमेन, उसे मेलिनेटर से बांधता है और अपना मेल सर्वर प्राप्त करता है, जिसकी मदद से वह तब तक स्पैम करता है जब तक डोमेन स्पैम डेटाबेस में नहीं आता। हालाँकि, ऐसे डोमेन का पता लगाया जा सकता है उनका MX रिकॉर्ड एक बार की मेल सेवा को संदर्भित करता है। मूल डोमेन का MX रिकॉर्ड सेवा को संदर्भित नहीं करता है, लेकिन GET अनुरोध के साथ इसे रीडायरेक्ट करता है। यह सत्यापित करने में हर्ज नहीं है कि मेल डोमेन ऐसी सेवाओं से संबंधित हैं। यदि आप अपने सर्वर पर अतिरिक्त लोड नहीं चाहते हैं, तो इन चेक को जावास्क्रिप्ट में करें, हालांकि यह सुरक्षा के स्तर को कम कर देगा, लिंक बिल्डरों को शायद ही कभी बुद्धि में भिन्नता है और यह अच्छा है यदि वे ऐसे शब्द भी जानते हैं।
खैर, निश्चित रूप से, मैं ब्लैकलिस्ट जैसी सेवाओं के बारे में जोड़ना नहीं भूलूंगा। वे अपने स्पैम डेटाबेस में आईपी और ईमेल की उपस्थिति की जांच करते हैं, एक साधारण एपीआई का उपयोग करके कनेक्ट करते हैं और अच्छी बुनियादी सुरक्षा प्रदान करते हैं।
यह भी महत्वपूर्ण है कि स्पैमर को न दिखाएँ कि आप जानते हैं कि वह स्पैमर है। यदि आपके ट्रिगर्स ने एक स्पैमर की पहचान की है, तो आपको बड़े लाल अक्षरों में प्रदर्शित करने की आवश्यकता नहीं है कि वह क्या बुरा काम करता है - वह बस प्रॉक्सी / मेल को बदल देगा और फिर से प्रयास करेगा। एक समझदार समाधान एक छद्म सेवा संदेश प्रदर्शित करना होगा, उदाहरण के लिए, "तकनीकी कार्य चल रहा है, पंजीकरण अस्थायी रूप से अक्षम है" या यहां तक ​​कि किसी प्रकार की पांच सौवीं त्रुटि (आंतरिक त्रुटि) का अनुकरण भी किया जा सकता है।

स्पैम कार्यक्रमों के खिलाफ सुरक्षा

यह आइटम सशर्त रूप से दो संभावित भूखंडों में विभाजित किया जा सकता है: आपकी साइट केवल विशाल स्पैमर डेटाबेस में से एक है और आपकी साइट लक्ष्य है। पहले मामले में, सब कुछ काफी सरल है: बस पैरों के निशान को हटा दें, पंजीकरण पृष्ठ (उस पर बाद में) को थोड़ा मोड़ दें और, सबसे अधिक संभावना है, कोई भी इसके माध्यम से नहीं टूटेगा। यदि किसी स्पैमर को आपकी साइट पर बहुत सारे खातों की आवश्यकता है, तो बड़े पैमाने पर पंजीकरण से बचाना अधिक कठिन है। शुरुआत में मैंने जिस लेख का उल्लेख किया, उसमें सामान्य ज्ञान का एक अंश है, लेकिन केवल एक अंश है। यह ज्ञात है कि कैप्चा लंबे समय तक बॉट्स के खिलाफ सुरक्षा का गारंटर नहीं रहा है, बहुत सारी सेवाएं हैं जहां आपके सभी कैप्चा भारतीयों द्वारा एक पैसे के लिए हल किए जाते हैं। लेकिन पंजीकरण पृष्ठ से कैप्चा हटाना एक बहुत ही मूर्खतापूर्ण निर्णय है, क्योंकि पंजीकरण केवल स्पैमर्स के लिए बिल्कुल मुफ्त नहीं होगा, बल्कि अविश्वसनीय रूप से तेज़ होगा (औसतन एक भारतीय द्वारा कैप्चा को हल करने में 30 सेकंड लगते हैं)। छिपे हुए क्षेत्रों के लिए, उदाहरण के लिए, मेरे कार्यक्रम में यह लंबे समय से ध्यान में रखा गया है कि स्वचालित मोड में केवल एक गैर-ऊंचाई और चौड़ाई वाले फ़ील्ड दिखाई दे रहे हैं। इस प्रकार, यहां तक ​​कि उन स्पैमर जो इस बारे में कुछ भी नहीं जानते हैं वे आसानी से इस "सुरक्षा" को बायपास करते हैं। पहले वर्णित विधियों के साथ-साथ टेलीफोन सत्यापन (जो मैं स्पष्ट कारणों के लिए बिल्कुल नहीं मानता), मैं केवल एक को वास्तव में मुश्किल काम करने की सिफारिश कर सकता हूं: कैप्चा, जहां आपको किसी तरह की कार्रवाई करने की आवश्यकता होती है, जैसे कि एक सरल पहेली डालना। ऐसे कैप्चा का एक अच्छा उदाहरण PlayThru है।
पंजीकरण पृष्ठ के अनुकूलन को चोट नहीं पहुंचेगी। यह संभावना नहीं है कि एक साधारण उपयोगकर्ता स्रोत कोड पढ़ेगा, इसलिए फ़ील्ड्स को क्यों बुलाएं (यहां मेरा मतलब "नाम" और "आईडी") जैसे "उपयोगकर्ता नाम", "ईमेल" जैसे स्पष्ट नाम हैं? कोई भी स्वाभिमानी कार्यक्रम स्वत: मोड में पंजीकरण के इस रूप का सामना करेगा। एक वांछनीय न्यूनतम इन विशेषताओं को अपठनीय बनाने या उन्हें स्वैप करने के लिए है (उदाहरण के लिए, लॉगिन फ़ील्ड को "ईमेल" कहा जाना चाहिए)। लेकिन आप (और अधिमानतः) इन विशेषताओं को गतिशील बनाने के लिए और भी आगे बढ़ सकते हैं। आप पूछ सकते हैं कि सर्वर गतिशील पैरामीटर नामों को कैसे संभालता है? मैं एक एल्गोरिथ्म की एन्क्रिप्शन कुंजी के साथ एक छिपे हुए इनपुट की पेशकश कर सकता हूं जिसे केवल आप जानते हैं। इसलिए, अनुक्रम निम्नानुसार है:
सर्वर एक यादृच्छिक कुंजी उत्पन्न करता है -> सर्वर विशेषताओं के नामों को एन्क्रिप्ट करता है -> उपयोगकर्ता इनपुट के एन्क्रिप्ट किए गए गुणों के साथ एक पेज प्राप्त करता है और आपकी कुंजी के साथ एक छिपा इनपुट -> फॉर्म सबमिट करते समय, सर्वर विशेषताओं को डिक्रिप्ट करता है और निर्धारित करता है कि यह किसके लिए जिम्मेदार है।
लेकिन 100% काम करने के लिए इस दृष्टिकोण के लिए, फ़ील्ड का आकार समान होना चाहिए, जैसे पृष्ठ पर यादृच्छिक क्रम में प्रदर्शित किया जाता है और, अधिमानतः, एक या अधिक फ़ील्ड जोड़ें "इस फ़ील्ड को खाली छोड़ दें।" और अंतिम स्पर्श लेबल के बजाय समान आकार और गतिशील पते की छवियों का उपयोग करना होगा।
लेकिन आप आगे भी जा सकते हैं और मुख्य मूल्यों को सीधे छिपे हुए इनपुट में पारित नहीं कर सकते हैं, लेकिन इसे सर्वर पर गतिशील रूप से उत्पन्न जावास्क्रिप्ट फ़ंक्शन के साथ प्रदान करते हैं, जिसे वांछित कुंजी वापस करना होगा। यह बेवकूफी से POST अनुरोध भेजने वाले कार्यक्रमों का उपयोग करके पंजीकरण करने के किसी भी प्रयास को नकार देगा।
बेशक, यह सब जटिल है, लेकिन यह वास्तविक उपयोगकर्ताओं के लिए लगभग कोई असुविधा के साथ आपकी साइट की पूरी तरह से रक्षा करेगा।

लेकिन प्राधिकरण फॉर्म के बारे में क्या?

यह सब साइट पर निर्भर करता है। कई समझ में नहीं आता है कि हब पर, लॉग इन करने के लिए, आपको हमेशा कैप्चा दर्ज करने की आवश्यकता है। मैं मानता हूं कि यह खराब रूप है, लेकिन यह दो तरीकों में से एक है जिसे मैं आपके खातों की सुरक्षा करना जानता हूं। इसी तरह के तरीके होते हैं जहां कुछ विशेषाधिकार खाते से जुड़े हो सकते हैं, जो डिफ़ॉल्ट रूप से सभी के लिए सुलभ नहीं होने चाहिए। एक हब पर यह कुछ अन्य साइटों पर - धन या संलग्न डिजिटल खरीद को आमंत्रित करता है। किसी भी अकाउंट को हाईजैक किया जा सकता है और इससे कोई फर्क नहीं पड़ता कि आपका पासवर्ड कितना मुश्किल है। वे फॉर्म ईमेल: पासवर्ड के खरीदे गए डेटाबेस के आधार पर एक जानवर की मदद से ऐसा करते हैं। और हास्यास्पद पैसे के लिए अड्डों को लाखों लाइनों में बेचा जाता है। जहां तक ​​मुझे पता है, उन्हें SQL कमजोरियों के माध्यम से विभिन्न मंचों से निकालकर निकाला जाता है। तो सोचिए कि आप मेल / लॉगिन और पासवर्ड के वास्तविक संयोजन वाले डेटाबेस को कितने खातों में डायल कर सकते हैं। सामान्य तौर पर, अपने आप को बचाने के लिए, आदर्श रूप से, प्रत्येक साइट का एक अलग पासवर्ड होना चाहिए। फिर, यदि इस साइट के आधार को मिला दिया जाता है, तो आपको कुछ भी खतरा नहीं है। सभी पासवर्डों को याद रखने के लिए, आप उदाहरण के लिए, उस साइट के नाम से कुछ अक्षरों को जोड़ सकते हैं, जिस पर आप एक मुख्य पासवर्ड पर पंजीकरण करते हैं। लेकिन यह एक पूरी तरह से अलग विषय है, और हम हमारे पास लौट आएंगे। Brute को प्राधिकरण के पते पर POST अनुरोध भेजकर किया जाता है, और अगर कैप्चा जैसी कोई समस्या नहीं है, तो यह सब बहुत जल्दी और, इसके अलावा, मुफ्त में होगा। लेकिन अगर आप कैप्चा जोड़ते हैं, तो ब्रूट दसियों गुना अधिक समय लेगा और 1 मिलियन लाइनों में आधार की जांच करने पर लगभग 1400 डॉलर खर्च होंगे। लेकिन, जैसा कि मैंने ऊपर लिखा था, कैप्चा के बिना साइट की सुरक्षा करने का एक और तरीका है, जो कि अजीब तरह से पर्याप्त है, मुझे अधिक विश्वसनीय लगता है। इसका सार एक विशिष्ट ब्राउज़र और / या आईपी से बांधना है, और जब कोई उपयोगकर्ता किसी अन्य कंप्यूटर से लॉग इन करता है, तो उसे एक गुप्त प्रश्न का उत्तर देने के लिए कहें। मैं पहले से ही इस तरह के कार्यान्वयन से मिला था और शायद, हेब्र डेवलपर्स को भी कुछ ऐसा ही करना चाहिए। अतिरिक्त सुरक्षा के रूप में, आप एन्क्रिप्शन कुंजी के साथ ट्रिक का उपयोग कर सकते हैं, फिर ऐसी साइट के लिए एक ब्रूट प्रोग्राम बनाना सैद्धांतिक रूप से संभव होगा, लेकिन अत्यंत कठिन।

अंत में

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

युपीडी
जैसा कि उपयोगकर्ता एवोकैटस ने सुझाव दिया था , अभी भी प्रॉक्सी और उपयोगकर्ता-एजेंट की परवाह किए बिना, जानवर को निर्धारित करने की एक विधि है। इसका सार स्थापित प्लगइन्स और फोंट की जांच और तुलना करना है।