टोर के माध्यम से गुमनाम रूप से भेजे गए इनबाउंड HTTP अनुरोधों का पता कैसे लगाया जाए?

Question

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

मैं एक आईपी पते से भारी ट्रैफिक के आधार पर उपयोगकर्ताओं को अवरुद्ध करने की रणनीतियों की कल्पना कर सकता हूं, लेकिन Tor network कई सर्किट सेट करता है जिसका अनिवार्य रूप से मतलब है कि एक ही उपयोगकर्ता का यातायात समय के साथ अलग-अलग आईपी पते से आता है।

मुझे पता है कि टोर ट्रैफिक का पता लगाना संभव है जब मैंने अपने फ़ायरफ़ॉक्स एक्सटेंशन के साथ Vidalia स्थापित किया, google.com ने मुझे कैप्चा के साथ प्रस्तुत किया।

तो, मैं ऐसे अनुरोधों का पता कैसे लगा सकता हूं?

(मेरी वेबसाइट के ASP.NET MVC 2 में है, लेकिन मुझे लगता है कि किसी भी यहां इस्तेमाल किया दृष्टिकोण स्वतंत्र भाषा होगा)

Answer 1

मैं एक वेबसाइट के विकास कर रहा हूँ और कर रहा हूँ लोगों के प्रति संवेदनशील scraping स्क्रीन मेरी डेटा

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

मैं भविष्य के उत्तरों के प्रस्तावों के किसी भी विचार पर प्रतिवाद पोस्ट करूंगा।

Answer 2

टोर नेटवर्क घटकों के डिज़ाइन से रिसीवर यह पता लगाना संभव नहीं है कि अनुरोधकर्ता मूल स्रोत है या यदि यह केवल एक रिलेड अनुरोध है।

Google के साथ आपने जो व्यवहार देखा वह शायद एक अलग सुरक्षा उपाय के कारण हुआ था। Google यह पता लगाता है कि लॉग-इन उपयोगकर्ता अपने आईपी को बदलता है और हानिकारक अवरोध को रोकने के लिए कैप्चा प्रस्तुत करता है और सत्र की निरंतरता को भी अनुमति देता है यदि कोई प्रमाणीकृत उपयोगकर्ता वास्तव में अपना आईपी बदलता है (आईएसपी को फिर से लॉगऑन करके)।

Answer 3

आप Tor Exit Nodes की सूची के विरुद्ध अपना आईपी पता देख सकते हैं। मैं एक तथ्य के लिए जानता हूं कि यह किसी को भी धीमा नहीं करेगा जो आपकी साइट को स्क्रैप करने में रूचि रखता है। टोर बहुत धीमी है, ज्यादातर स्क्रैपर्स इसे भी नहीं मानेंगे। हजारों खुले प्रॉक्सी सर्वर हैं जिन्हें आसानी से स्कैन किया जा सकता है या एक सूची खरीदी जा सकती है। प्रॉक्सी सर्वर अच्छे हैं क्योंकि यदि आप अपनी अनुरोध टोपी हिट करते हैं तो आप उन्हें थ्रेड या घुमा सकते हैं।

Google उपयोगकर्ताओं द्वारा दुरुपयोग किया गया है और अधिकांश निकास नोड्स Google ब्लैक लिस्ट पर हैं और यही कारण है कि आप कैप्चा प्राप्त कर रहे हैं।

मुझे पूरी तरह से स्पष्ट होने दें: कुछ भी नहीं है जो आप अपनी साइट को स्क्रैप करने से रोक सकते हैं।

Answer 4

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

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

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

यह आपके अंतिम उपयोगकर्ताओं (दोस्ताना बॉट सहित) के लिए विफलता का एक बिंदु भी हो सकता है। यदि कोई वैध उपयोगकर्ता या ग्राहक अवरुद्ध हो जाता है तो आपको ग्राहक सेवा दुःस्वप्न मिल गया है और यदि गलत क्रॉलर अवरुद्ध हो जाता है तो आप अपने खोज ट्रैफ़िक को अलविदा कह रहे हैं।

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

यदि आपकी साइट गतिशील सामग्री वाली एक सेवा है जो पूरी कहानी है। मैं वास्तव में संरचित स्वामित्व डेटा की भारी मात्रा में "चोरी" करने के लिए इस तरह की कई साइटों को स्क्रैप करता हूं, लेकिन इसे कठिन बनाने के विकल्प हैं। आप प्रति आईपी अनुरोध को सीमित कर सकते हैं, लेकिन प्रॉक्सी के साथ घूमना आसान है। कुछ वास्तविक सुरक्षा के लिए अपेक्षाकृत सरल obfuscation एक लंबा रास्ता चला जाता है। यदि आप Google परिणामों को स्क्रैप करने या यूट्यूब से वीडियो डाउनलोड करने की कोशिश करते हैं तो आपको पता चलेगा कि रिवर्स इंजीनियर के लिए बहुत कुछ है। मैं इनमें से दोनों करता हूं, लेकिन 99% लोग जो असफल प्रयास करते हैं क्योंकि उन्हें ऐसा करने के लिए ज्ञान की कमी है। वे आईपी सीमाएं प्राप्त करने के लिए प्रॉक्सी को स्क्रैप कर सकते हैं लेकिन वे किसी भी एन्क्रिप्शन को तोड़ नहीं रहे हैं।

एक उदाहरण के रूप में, जहां तक ​​मुझे याद है कि एक Google परिणाम पृष्ठ obfuscated javscript के साथ आता है जो पृष्ठ लोड पर डीओएम में इंजेक्शन दिया जाता है, तो किसी प्रकार के टोकन सेट होते हैं ताकि आपको उन्हें बाहर निकालना पड़े। फिर उन टोकन के साथ एक अजाक्स अनुरोध है जो ओएसएफस्केटेड जेएस या जेएसओएन देता है जो परिणाम बनाने के लिए डीकोड किया जाता है और इसी तरह। डेवलपर के रूप में आपके अंत में करना मुश्किल नहीं है, लेकिन संभावित चोरों का विशाल बहुमत इसे संभाल नहीं सकता है। अधिकांश जो प्रयास में नहीं डाल सकते हैं। मैं Google को वास्तव में मूल्यवान सेवाओं को लपेटने के लिए ऐसा करता हूं लेकिन अधिकांश अन्य सेवाओं के लिए मैं अलग-अलग प्रदाताओं पर कुछ कम लटकते फल पर जाता हूं।

आशा है कि यह किसी भी व्यक्ति के आने के लिए उपयोगी होगा।

Answer 5

मुझे लगता है कि एक वेबसाइट को स्क्रैप करने से निर्धारित और तकनीकी रूप से समझदार उपयोगकर्ता को रोकने के लिए 'असंभव' कैसे है, इस पर ध्यान केंद्रित किया जाता है। @ ड्रू नोएक्स का कहना है कि वेबसाइट में ऐसी जानकारी होती है जब कुल मिलाकर कुछ 'मूल्य' होता है। यदि किसी वेबसाइट पर कुल डेटा है जो अनजान अनाम उपयोगकर्ताओं द्वारा आसानी से सुलभ है, तो हां, स्क्रैपिंग को रोकने से 'असंभव' हो सकता है।

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

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

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

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

इसी प्रकार, अनुरोध उपयोगकर्ताओं से उन मानदंडों के आंकड़ों के लिए जो मानदंड से काफी अधिक हैं, उन व्यक्तियों की पहचान करने में मदद कर सकते हैं जो डेटा को स्क्रैप करने की संभावना रखते हैं; इस तरह के दृष्टिकोण को भी स्वचालित किया जा सकता है और यहां तक ​​कि पैटर्न के लिए कई खातों को देखने के लिए आगे बढ़ाया जा सकता है जो स्क्रैपिंग को इंगित करते हैं। उपयोगकर्ता 1 स्क्रैप 10%, उपयोगकर्ता 2 अगले 10% स्क्रैप करता है, उपयोगकर्ता 3 अगले 10% स्क्रैप करता है, आदि ... पैटर्न (और अन्य) जैसे पैटर्न एक व्यक्ति या समूह का उपयोग करके सिस्टम के दुर्भावनापूर्ण उपयोग के मजबूत संकेतक प्रदान कर सकते हैं एकाधिक खाते

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

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