स्क्रैपर बॉट्स के साथ छेड़छाड़

• सार्वजनिक वेबसाइटों पर हद से ज़्यादा requests भेजकर DDoS जैसा व्यवहार करने वाले scraper bots की समस्या पर चर्चा, और उनका समय बर्बाद करने के लिए एक प्रयोगात्मक तरीका प्रस्तुत
• Markov chain आधारित text generator बनाकर .php फ़ाइल जैसा दिखने वाला नकली data तैयार किया गया, ताकि malicious bots उसे download करें
• इसके बाद static content server बनाया गया, जो उपन्यास Frankenstein के paragraph यादृच्छिक रूप से देता है, और link structure के ज़रिए crawler को विस्फोटक रूप से फैलने के लिए डिज़ाइन किया गया
• सभी pages में noindex, nofollow attributes और request counter जोड़े गए, ताकि सामान्य search engines को बाहर रखा जाए और सिर्फ़ नियम तोड़ने वाले bots पकड़े जाएँ
• प्रयोग के नतीजे दिलचस्प थे, लेकिन Googlebot के false positive जोखिम के कारण इसे वास्तविक service में लागू नहीं किया गया और इसे सीखने व प्रयोग के project के रूप में रखा गया

---

scraper bot समस्या और जवाबी आइडिया

• scraper अनजाने में छोटी websites पर DDoS स्तर का load पैदा कर सकते हैं
• कुछ operators ने सुरक्षा के तरीकों के बारे में पूछा, लेकिन यह लेख “defense नहीं, counterattack” पर केंद्रित है
• किसी दूसरे developer का Markov chain से अनंत नकली data बनाकर bots को फँसाने वाला उदाहरण देखने के बाद लेखक ने खुद प्रयोग शुरू किया

Markov chain आधारित नकली PHP generator

• Rust में Markov chain learner लागू करके arbitrary text data के आधार पर वास्तविक जैसा content बनाया गया
• .env, .aws, .php जैसे कमज़ोर paths को निशाना बनाने वाले malicious bots के लिए असली जैसा दिखने वाला लेकिन अर्थहीन PHP code दिया गया
• file size को 2KB से 10MB तक बढ़ाकर bot के resources बर्बाद कराने की कोशिश की गई
• उदाहरण output में WordPress function names और comments मिले हुए काफ़ी भरोसेमंद दिखने वाले नकली PHP code का रूप था
• मकसद था bots का समय और संसाधन बर्बाद करना, और attacker को असली vulnerability खोजने में समय गँवाने पर मजबूर करना

दक्षता और static data serving प्रयोग

• VPS पर 1MB से बड़े files serve करने पर response delay और server load बढ़ना देखा गया
• इसे हल करने के लिए static site रूप का “garbage server” बनाया गया
  • Frankenstein उपन्यास को पूरा memory में लोड किया गया, और हर request पर 4 random paragraph लौटाए गए
  • हर page के नीचे 5 links जोड़कर विस्फोटक crawling expansion (5 गुना वृद्धि) के लिए उकसाया गया
• नतीजा https://herm.app/babbler/ पर देखा जा सकता है

डिज़ाइन की बारीकियाँ और संचालन का तरीका

• चुना गया उपन्यास public domain में है, और इसे Halloween के समय काम किए जाने तथा AI और Frankenstein की समानता के कारण चुना गया
• सभी pages को noindex,nofollow दिया गया ताकि सिर्फ़ नियम तोड़ने वाले bots पकड़े जाएँ
• हर page के नीचे request count counter दिखाया गया, जो memory आधारित deployment होने पर reset हो जाता है
• .php requests के लिए अलग server भी बनाया गया, जो असल PHP files को memory से यादृच्छिक रूप से उपलब्ध कराता है
• “Garbage for the garbage king!” वाक्य से project का सार बताया गया

जोखिम और सीमाएँ

• इस system को वास्तविक service में लागू करने पर search engine false positive का जोखिम है
  • अगर Googlebot गलत endpoint को crawl कर ले, तो site के spam site के रूप में वर्गीकृत होने की संभावना है
  • इससे search visibility कम हो सकती है या Chrome warning दिख सकती है
• इसलिए search पर निर्भर sites के लिए यह अनुशंसित नहीं है, और इसे केवल प्रयोगात्मक project के रूप में चलाया गया
• .php के लिए babbler HTML नहीं है, इसलिए Googlebot पर इसका असर नहीं पड़ता, और यह सिर्फ़ malicious bots को निशाना बनाता है

समापन और व्यक्तिगत निष्कर्ष

• malicious scrapers को लुभाने के लिए ब्लॉग में छिपे हुए links (rel="nofollow") जोड़े गए
• VPS की traffic limit पार होने पर Cloudflare cache इस्तेमाल करने पर विचार किया गया
• इस project के ज़रिए Markov chain और bot व्यवहार के सिद्धांत सीखे गए, और मज़े व झुंझलाहट के मिश्रण के साथ प्रयोग किया गया
• अंत में, हर कोशिश का व्यावहारिक होना ज़रूरी नहीं, कभी-कभी सिर्फ़ मज़े के लिए करना भी काफ़ी है

[GN⁺]

Hacker News राय

• दुनिया बदल जाए, आखिर में वही जैसी समस्याएँ फिर सामने आ जाती हैं
  10~15 साल पहले मैं social media monitoring services से जूझ रहा था। बड़े brands उन्हें forums की sentiment monitoring के लिए पैसे देते थे, लेकिन वे मेरे चलाए जा रहे मुफ़्त community को बिना अनुमति scrape करके server load बढ़ा रहे थे
  उनके bots को block करने पर भी वे IP और UA बदलकर लौट आते थे, इसलिए मैंने posts में random brand names डालने वाला एक filter बना दिया ताकि उनकी data quality खराब हो जाए। यह उपाय चालू करने के दो दिन के भीतर scraping पूरी तरह रुक गई

  • मेरा भी ऐसा ही अनुभव रहा है। एक bot मेरे site के donation form को credit card testing के लिए इस्तेमाल कर रहा था, और IP बदल-बदलकर लगातार कोशिश कर रहा था। इसलिए block करने के बजाय मैंने success/failure messages को random कर दिया; उनका data contaminate हो गया और कुछ ही दिनों में उन्होंने हार मान ली
  • headers analysis वाली बात सच में उपयोगी थी। अपने Fediverse server पर भी मैंने देखा कि पुराने Chrome UA इस्तेमाल करने वाले bots Accept-Language header बिल्कुल नहीं भेजते। nginx में 403 return करने के लिए सेट करते ही traffic कम होने लगा
  • फिल्म The Imitation Game की तरह, अगर आप हर request पर तुरंत प्रतिक्रिया देते हैं तो सामने वाला समझ जाता है। अगर सिर्फ कुछ requests को handle करें या random error codes दें, तो detect करना मुश्किल हो जाता है और उनका debugging काफी कठिन हो सकता है
  • ज़्यादातर bots अब भी HTTP headers set को सही तरह imitate नहीं कर पाते। 2025 में भी मैं उसी तरीके से filter कर रहा हूँ, और bots अब भी लगभग उसी pattern में evolve हो रहे हैं
  • मुझे जिज्ञासा है कि company names डालने से bots क्यों गायब हो गए। क्या ऐसा इसलिए हुआ कि brands mentions खोजने की उनकी प्रक्रिया में data signal contaminate हो गया?

• ये bots वास्तव में PHP files को parse नहीं कर रहे, बल्कि उनकी मौजूदगी से vulnerability detection के लिए fingerprinting बना रहे हैं। वे सिर्फ response code देखकर तुरंत आगे बढ़ जाते हैं

  • सही है, ऐसे मामलों में fail2ban या crowdsec जैसे tools ज़्यादा असरदार होते हैं। crowdsec इस्तेमाल करके मुझे पता चला कि कम traffic वाले servers पर भी vulnerability probing की कोशिशें बहुत ज़्यादा होती हैं
  • तो फिर जानबूझकर fake vulnerabilities expose करके bots को lure करने की strategy भी संभव लगती है। उदाहरण के लिए, automated bots को honeypot(honeybot) में खींचकर उनका internal behavior observe किया जा सकता है। संदर्भ: The Cuckoo’s Egg
  • अगर LLM scrapers ऐसे responses को training data की तरह इस्तेमाल करें, तो data poisoning का जोखिम और बढ़ सकता है। हाल की papers में भी कहा गया है कि बहुत कम data points से भी model को बिगाड़ा जा सकता है

• हाल में मैंने AI और scrapers के लिए tarpit के बारे में सुना। इसमें connection बंद नहीं किया जाता, बल्कि बहुत धीमी गति से अनंत data बहाया जाता है। Nepenthes नाम का tool दिलचस्प लगा, उस पर experiment करना चाहता हूँ

• पहले HN पर scrapers को रोकने पर लोगों से आलोचना मिलती थी। तर्क यह था कि “मैं कैसे access करूँ, इससे किसी को क्या फर्क पड़ता है”

  • लेकिन अब बात अलग है। किसी इंसान का व्यक्तिगत रूप से access करना और AI companies का बड़े पैमाने पर DDoS-स्तर की requests भेजना पूरी तरह अलग बातें हैं। दूसरा मामला साफ़ तौर पर अपने cost का बोझ दूसरों पर डालना है
  • मुझे भी सामान्य scraping से दिक्कत नहीं है। UA साफ़ होना चाहिए और robots.txt का पालन होना चाहिए। लेकिन अभी की तरह प्रति सेकंड दर्जनों requests भेजना और पुराने Chrome version का भेष बनाना बिल्कुल स्वीकार्य नहीं है
  • मैं एक academic project के लिए दिन में एक बार job sites को scrape करता हूँ। यह उचित उपयोग है। इसके उलट, हर कुछ मिनट में content scrape करना या vulnerabilities ढूँढना बिल्कुल अलग समस्या है
  • AI का आना नैतिक चेतना को ही कमजोर कर रहा है, यही सबसे उदास करने वाली बात है। जो लोग पहले freedom को महत्व देते थे, वे अब copyright सख्त करने या anonymity हटाने की माँग कर रहे हैं। technology लोगों को और बदतर बना रही है

• अगर आप Apache server सीधे manage करते हैं, तो RewriteEngine से PHP requests को तुरंत block कर सकते हैं

  RewriteEngine On
  RewriteCond %{REQUEST_URI} (\.php|%2ephp|%2e%70%68%70) [NC,OR]
  RewriteCond %{QUERY_STRING} \.php [NC,OR]
  RewriteCond %{THE_REQUEST} \.php [NC]
  RewriteRule .* - [F,L]
  

  मेरे server पर PHP है ही नहीं, इसलिए ऐसी सारी requests malicious हैं

  • nginx में भी इसे इसी तरह सेट किया जा सकता है। PHP या ASPX requests पर HTTP 418 “I’m a teapot” code return किया जाता है

    location ~* \.(?:php|aspx?|jsp|dll|sql|bak)$ { return 418; }
    error_page 418 /418.html;
    

    इससे logs को filter करना आसान हो जाता है। उदाहरण: FreeSolitaire.win/wp-login.php

• ज़्यादातर आक्रामक scrapers WordPress vulnerabilities को निशाना बनाते हैं। उन्हें PHP file से ज़्यादा उसका output चाहिए होता है। ऐसी setting एक तरह के honeypot जैसी है, लेकिन अगर bot script के मुताबिक न चले तो वह बस आगे बढ़ जाता है

  • शायद वे output में regex से admin login pattern खोजते होंगे। अगर न मिले तो तुरंत skip कर देते होंगे। यानी 4KB की fake PHP बनाना, एक regex line की तुलना में कहीं कम efficient है

• पहले मैंने zipbomb strategy HN पर पोस्ट की थी, फिर traffic एक दिन में 100,000 hits तक उछल गया। $6 वाले VPS पर यह संभालना संभव नहीं था। अब मैं सिर्फ सबसे आक्रामक bots पर zipbomb इस्तेमाल करता हूँ, बाकी को 403 देता हूँ। नई strategy अच्छी तरह काम कर रही है, लेकिन इसे फिर से सार्वजनिक करूँ या नहीं, इस पर सोच रहा हूँ। संदर्भ: पिछली पोस्ट

• पहले मैं सिर्फ fail2ban इस्तेमाल करता था, लेकिन मैं कुछ और मज़ेदार defense बनाना चाहता था
  .htaccess में suspicious paths (/.git, /wp-login) को decoy.php पर redirect करता हूँ, और 10GB का decoy.zip ज़बरदस्ती download करवाता हूँ।
  decoy.php requested sensitive file जैसा दिखता है, लेकिन वास्तव में fake logs और SQL data को अनंत stream करके bot को वहीं अटकाए रखता है

• ये bots PHP files scrape नहीं कर रहे, बल्कि framework vulnerabilities खोज रहे हैं। अगर उन्हें कोई अप्रत्याशित response मिले, तो वे तुरंत हार मानकर दूसरे target पर चले जाते हैं

• कभी-कभी मैं सोचता हूँ — क्या bots जो resources बर्बाद कर रहे हैं, उनसे cryptocurrency mine करवाई जा सकती है?

  • कोशिश करनी हो तो JavaScript execution कराना पड़ेगा, लेकिन ज़्यादातर bots के पास शायद ऐसी कोशिशों को रोकने के लिए पहले से countermeasures होंगे