अनधिकृत स्पाइडरिंग को कैसे रोकें

Question

मैं वैध स्पिडरिंग (googlebot, आदि) को प्रभावित नहीं करते समय हमारी साइटों में से किसी एक से स्वचालित HTML स्क्रैपिंग को रोकना चाहता हूं। क्या ऐसा कुछ है जो इसे पूरा करने के लिए पहले से मौजूद है? क्या मैं सही शब्दावली का भी उपयोग कर रहा हूं?

संपादित करें: मैं मुख्य रूप से उन लोगों को रोकने के लिए देख रहा हूं जो यह दुर्भावनापूर्ण तरीके से करेंगे। अर्थात। वे robots.txt

EDIT2: "उपयोग की दर" द्वारा उपयोग को रोकने के बारे में क्या है ... यानी कैप्चा ब्राउज़िंग जारी रखने के लिए क्या है यदि स्वचालन का पता चला है और यातायात वैध नहीं है (google , याहू, एमएसएन, आदि) आईपी।

Answer 1

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

इस स्थिति में robots.txt का उपयोग करने में समस्या यह है कि मकड़ी सिर्फ इसे अनदेखा कर सकती है।

संपादित करें: दर सीमित करना एक संभावना है, लेकिन यह "अच्छा" और "खराब" उपयोगकर्ता एजेंट/आईपी की पहचान (और ट्रैक रखने) की कुछ समस्याओं से ग्रस्त है। एक प्रणाली में हमने कुछ आंतरिक पृष्ठ दृश्य/सत्र गिनती करने के लिए लिखा है, हम पृष्ठ दृश्य दर के आधार पर सत्रों को खत्म करते हैं, लेकिन हम "अच्छे" मकड़ियों को खत्म करने की भी चिंता नहीं करते हैं क्योंकि हम नहीं चाहते हैं कि वे डेटा में गिना जाए। हम किसी भी ग्राहक को वास्तव में पृष्ठों को देखने से रोकने के बारे में कुछ नहीं करते हैं।

Answer 2

robots.txt केवल तभी काम करता है जब मकड़ी इसे सम्मानित करती है। आप उन मकड़ियों को फ़िल्टर करने के लिए एक HttpModule बना सकते हैं जिन्हें आप अपनी साइट को क्रॉल नहीं करना चाहते हैं।

Answer 3

आपको दुर्भावनापूर्ण उपयोग का पता लगाने के दौरान क्या अच्छा फ़ायरवॉल करना चाहिए - उन्हें चलते रहें, लेकिन उन्हें कुछ और न दें। यदि आप 403 या 404 फेंकना शुरू करते हैं तो उन्हें पता चलेगा कि कुछ गलत है। यदि आप यादृच्छिक डेटा वापस करते हैं तो वे अपने व्यवसाय के बारे में जानेंगे।

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

Answer 4

एक दृष्टिकोण एक HTTP टैर गड्ढे स्थापित करना है; एक लिंक एम्बेड करें जो केवल स्वचालित क्रॉलरों के लिए दृश्यमान होगा। लिंक को यादृच्छिक पाठ और स्वयं से लिंक वाले पृष्ठ पर जाना चाहिए (लेकिन अतिरिक्त पृष्ठ जानकारी के साथ: /tarpit/foo.html, /tarpit/bar.html, /tarpit/baz.html - लेकिन स्क्रिप्ट/tarpit पर है/200 परिणाम के साथ सभी अनुरोधों को संभाल लें)।

अच्छे लोगों को गड्ढे से बाहर रखने के लिए, यदि उपयोगकर्ता एजेंट Google या याहू है तो अपने होम पेज पर 302 रीडायरेक्ट उत्पन्न करें।

यह सही नहीं है, लेकिन यह कम से कम बेवकूफ़ों को धीमा कर देगा।

संपादित करें: कॉन्स्टेंटिन द्वारा सुझाए गए अनुसार, आप टैर पिट को robots.txt में ऑफलाइन के रूप में चिह्नित कर सकते हैं। अच्छे लोग वेब मकड़ियों का उपयोग करते हैं जो इस प्रोटोकॉल का सम्मान करते हैं, वे टैर गड्ढे से बाहर रहेंगे। यह ज्ञात अच्छे लोगों के लिए रीडायरेक्ट उत्पन्न करने की आवश्यकता से छुटकारा पा जाएगा।

Answer 5

यदि आप सामान्य क्रॉलर से खुद को सुरक्षित रखना चाहते हैं, तो एक हनीपॉट का उपयोग करें।

उदाहरण के लिए, http://www.sqlite.org/cvstrac/honeypot देखें। अच्छा मकड़ी इस पृष्ठ को नहीं खोल पाएगा क्योंकि साइट का robots.txt इसे स्पष्ट रूप से अस्वीकार करता है। मानव इसे खोल सकता है, लेकिन "मैं एक मकड़ी हूं" लिंक पर क्लिक नहीं करना चाहता हूं। खराब मकड़ी निश्चित रूप से दोनों लिंक का पालन करेगा और इसलिए इसकी असली पहचान को धोखा देगी।

यदि क्रॉलर विशेष रूप से आपकी साइट के लिए बनाया गया है, तो आप (सिद्धांत रूप में) एक चलती हनीपॉट बना सकते हैं।

Answer 6

मैं आमतौर पर हनीपॉट दृष्टिकोण से सहमत हूं। हालांकि, मैंने "/robots.txt" द्वारा अवरुद्ध पृष्ठ पर हनीपॉट पेज/संसाधन को केवल लिंक दिया - साथ ही साथ हनीपॉट अवरुद्ध किया गया। इस तरह, दुर्भावनापूर्ण रोबोट को खुद को प्रतिबंधित करने के लिए "अस्वीकार" नियम (ओं) TWICE का उल्लंघन करना पड़ता है। एक विशिष्ट उपयोगकर्ता मैन्युअल रूप से एक अनजान लिंक का पालन करने की संभावना है, केवल एक बार ऐसा करने के लिए और हनीपॉट यूआरएल वाले पेज को नहीं मिल सकता है।

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

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