बॉट्स को रोकने के लिए छोटे-छोटे टूल्स का पूरा इस्तेमाल

 (lambdacreate.com)
4 पॉइंट द्वारा GN⁺ 2025-06-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़ी AI/सर्च कंपनियों की अंधाधुंध crawling और scraping की वजह से व्यक्तिगत सर्वर और सेवाएँ गंभीर रूप से प्रभावित हो रही हैं, और resource consumption तथा service instability लगातार बनी रहती है
  • Zabbix·Loki आधारित monitoring से असामान्य ट्रैफिक पहचानने के बाद, log analysis tools (lnav, goaccess) और SQL आधारित queries से attacker patterns, IPs, और User Agents की विस्तार से पहचान की गई
  • Nginx settings में User Agent आधारित 403 block, rate limit, और Fail2Ban integration जैसी चरणबद्ध defense layers बनाकर सैकड़ों malicious IPs को block किया गया और server stability हासिल की गई
  • मुख्य समस्या वे बॉट्स थे जो पूरे Gitea repository को tarball के रूप में बड़े पैमाने पर डाउनलोड करने की कोशिश कर रहे थे, और केवल सामान्य content consumers नहीं बल्कि "AI data collection/model training purpose" वाला ट्रैफिक तेज़ी से बढ़ रहा था
  • लंबी अवधि में वैध सेवाओं (archive.org आदि) के लिए exception handling, और search engine exposure बनाए रखते हुए AI en-shitification का मुकाबला करने की रणनीति पर विचार किया जा रहा है

परिचय: मेरे छोटे सर्वर पर टूट पड़ा बॉट ट्रैफिक

  • हाल ही में व्यक्तिगत रूप से चलाए जा रहे lambdacreate ब्लॉग और कई सेवाओं पर अज्ञात भारी ट्रैफिक अचानक बढ़ गया
  • Archive.org जैसी वैध सेवाएँ स्वागतयोग्य हैं, लेकिन Amazon, Facebook, OpenAI जैसी बड़ी कंपनियों की अनियंत्रित data crawling साइट को नुकसान पहुँचाती है
  • AI model training आदि के कारण data collection की मांग बढ़ने से यह स्थिति और गंभीर हो गई है
  • इस हालात में असली पाठकों (मानव) की जगह मुख्य रूप से बड़े पैमाने के bot traffic से जूझना पड़ रहा है

समस्या की पहचान: monitoring tools से ट्रैफिक विस्फोट का निदान

  • Zabbix, Loki जैसे monitoring tools का उपयोग कर server resource consumption का विश्लेषण किया गया
  • Gitea instance में प्रतिदिन 20~30GB तक data बढ़ने की स्थिति, और कई CPU/memory warnings दर्ज हुईं
  • nginx traffic analysis के अनुसार, मासिक औसत 8req/s से बढ़कर कुछ समय के लिए 20req/s से ऊपर पहुँच गया
  • ट्रैफिक बहुत विशाल नहीं था, लेकिन सामान्य की तुलना में लगभग 10 गुना बढ़कर resource exhaustion पैदा कर रहा था

हमले के कारण का विश्लेषण: log files का गहन विश्लेषण

  • lnav और goaccess की मदद से nginx access logs का SQL के जरिए विश्लेषण किया गया
    • visitor IP, UserAgent, Referrer आदि के patterns की पहचान
  • नतीजे में यह स्पष्ट हुआ कि यह किसी विशेष service या community से आने वाला ट्रैफिक नहीं था, बल्कि विशिष्ट IP ranges से भारी crawling हो रही थी
  • UserAgent में Amazonbot, OpenAI, Applebot, Facebook जैसे स्पष्ट या spoofed मान बड़ी संख्या में पाए गए
  • इससे वास्तविक सेवा उपयोग प्रभावित होने लगा, इसलिए कड़े blocking policy की आवश्यकता सामने आई

समाधान: Nginx, Fail2Ban आदि कई defense layers का संयुक्त उपयोग

  • Nginx map का उपयोग कर malicious UserAgent पर तुरंत 403 return किया गया, और rate limit (visit speed limit) लागू की गई
  • नए और अभी तक न पहचाने गए bots के लिए भी web request frequency कम करके server load को न्यूनतम किया गया
  • 403 logs के आधार पर goaccess और lnav से नए malicious IPs और UserAgents का पता लगाया गया
  • automation security tool Fail2Ban के जरिए 403 responses अत्यधिक देने वाले IPs को 24 घंटे के लिए अपने-आप block किया गया
    • 735 से अधिक automatic ban records
  • वास्तविक resource usage काफी हद तक सामान्य स्तर पर लौट आया
  • आगे archive.org जैसी वैध सेवाओं के लिए exception rules लागू करने, search engine indexing की अनुमति बनाए रखने, लेकिन AI training के लिए अंधाधुंध crawling को लगातार block करने की योजना है

निष्कर्ष: tool combination की ताकत और personal services security की ज़रूरत

  • इस तरह की multi-layered defense measures लागू करके व्यक्तिगत ब्लॉग संचालन और service accessibility को फिर से सुचारु बनाया गया
  • यह भी स्पष्ट हुआ कि कई छोटे system administration और automation tools का उपयोग व्यक्तिगत server security के लिए प्रभावी है
  • बढ़ती हुई AI training demand के कारण जब व्यक्तिगत सर्वर तक अंधाधुंध crawl किए जा रहे हों, तब सक्रिय blocking और management automation अनिवार्य हो जाते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-02
Hacker News राय

  • अक्सर देखा है कि बहुत से बेशर्म crawlers बस बड़े search engines की नकल करते हैं। कुछ लोग कहते हैं कि user-agent जानकारी पर भरोसा नहीं करना चाहिए, लेकिन मेरी पसंदीदा तरकीब यह है कि robots.txt में संदिग्ध जानकारी (जैसे gzip bomb) डाल दो, और जो crawler उसे छू ले, उसे अगली request से block कर दिया जाए। इसे Caddy में आसानी से लागू किया जा सकता है, और इससे आम तौर पर गंभीर उल्लंघन करने वाले पकड़े जाते हैं। मैं bots के व्यवहार का बचाव नहीं कर रहा, लेकिन अगर ऐसे कुछ bots ही आपकी साइट गिरा दें, तो यह इस बात का भी सबूत है कि साइट किसी दुर्भावनापूर्ण हमलावर के सामने बहुत कमजोर है

    • लगा कि आखिरी टिप्पणी ने सच में मुद्दे की जड़ पकड़ ली। हो सकता है मैं अलग पीढ़ी का हूँ, लेकिन समझ नहीं आता कि आजकल लिखने वाले लोग इतने कम resource usage पर इतना क्यों अटकते हैं। जैसे दादा-दादी LED बल्ब बंद करने को लेकर हंगामा करें, या 5 सेंट ईंधन बचाने के लिए 24 किमी गाड़ी चलाएँ। प्रति सेकंड 20 requests सच में कुछ भी नहीं हैं। चाहे पेज dynamically generate हो रहे हों तब भी (और वह भी क्यों? उतने समय में caching सेट करना कहीं ज्यादा फायदेमंद है), आजकल fuck the bots टाइप के लेख चलन में हैं, लेकिन यह कोई नया विषय नहीं है। बिना समय बरबाद किए इससे निपटने के कहीं ज्यादा उत्पादक तरीके हैं

    • robots.txt से gzip bomb लगाने वाले तरीके के बारे में और सुनना चाहूँगा। मेरी समझ यह थी कि ज़्यादातर AI robots.txt को नज़रअंदाज़ करते हैं, तो क्या आखिरकार इसमें सिर्फ कुछ भोले crawlers ही फँसते हैं? मैं किसी से असहमत होने के लिए नहीं पूछ रहा, बस यह जानना चाहता हूँ कि इसे अच्छे पक्ष को नुकसान पहुँचाए बिना कैसे लागू किया जा सकता है

    • मैं अपने क्षेत्र की सबसे बड़ी wikis में से एक चलाता हूँ, और dev team के बाकी लोगों को gzip bomb इस्तेमाल करने के लिए मनाना लगभग नामुमकिन है। उनका कहना है कि इस तरीके में जोखिम बहुत ज्यादा है (EU regulations वाली सोच के कारण), इसलिए इसे आगे बढ़ाना ही सही नहीं। जानना चाहता हूँ कि क्या कोई वास्तव में सार्वजनिक साइट पर ऐसा तरीका इस्तेमाल करता है

  • आजकल bots robots.txt फ़ाइल का बिल्कुल सम्मान नहीं करते, और यह सच में गुस्सा दिलाता है। मुझे लगता है कि इसे बनाने वाले लोग बेहद स्वार्थी हैं। अगर किसी ने ऐसे bots बनाए हैं, तो वही भुगते

    • अगर robots फ़ाइल में trap (honeypot) डाल दिया जाए, तो जो bots इसे पूरी तरह नज़रअंदाज़ कर देते हैं वे भले न फँसें, लेकिन जो जानबूझकर मुसीबत करने आते हैं उन्हें छाँटने में मदद मिलती है

    • यही बात chatbot, search engine, price comparison tools जैसी चीज़ें इस्तेमाल करने वाले लोगों से भी कही जा सकती है। असल में ऐसे users ही scrapers को आर्थिक रूप से प्रोत्साहित करने वाले बड़े कारणों में हैं

  • मैं समझ सकता हूँ कि लेखक ने कहा कि वह “अब परवाह नहीं करता”, लेकिन मैंने banned IPs में Google, ripe.net, और semrush देखे। बाकी कंपनियों की बात अलग, लेकिन मैं Google को तो सच में block नहीं करूँगा। अगर आप चाहते हैं कि साइट लोगों तक पहुँचे, तो Semrush या ripe.net को block करने की भी शायद ज़रूरत नहीं। भले ही AI या अजीब लोग मेरा content scrape करें, अगर साइट शुरू से सार्वजनिक है तो कुछ हद तक उसके इस्तेमाल के लिए तैयार रहना चाहिए। जैसे motel का साइनबोर्ड बंद करके मेहमान बुलाने जैसा

    • Semrush ने बहुत लंबे समय तक कई स्तरों पर सच में बहुत खराब तरीके से तंग किया, इस हद तक कि पिछले 8 सालों से मैंने robots.txt में उनके लिए एक अलग संदेश तक छोड़ा हुआ है। आखिर में legal team तक लगानी पड़ी, तब जाकर मामला कुछ शांत हुआ। मेरे नज़रिए से किसी SEO कंपनी को यह अनुमति देने का कोई मूल्य नहीं कि वह असली visitors को धक्का देकर साइट को बेरहमी से scrape करे। Semrush के competitors भी उतने ही खराब रहे। अभी के AI scrapers भी इतने घटिया स्तर के हैं कि मुझे बड़े investors और PR departments तक बार-बार औपचारिक शिकायतें भेजनी पड़ीं। तकनीकी और कानूनी दोनों तरीकों से किसी तरह चीज़ों को फिर सामान्य किया

    • असली समस्या यह है कि bots बड़े पैमाने पर traffic (bandwidth, memory, CPU, disk resources) घेर लेते हैं। परिचय में भी इसे अस्वीकार्य बदतमीज़ी कहा गया है। ऐसा traffic scrapers को यूँ ही देने की कोई ज़रूरत नहीं लगती। Google भी AI scrapers चला रहा है, इसलिए शायद वही block list में आया हो

    • ऐसे असली malicious bots भी मौजूद हैं जो Google होने का नाटक करते हैं। पहले Google अपेक्षाकृत शिष्ट scraping करता था, लेकिन अगर लेखक चाहे block करे या न करे, और Google को पहले ही ज़रूरी traffic मिल रहा हो, तो उसे फ़र्क नहीं पड़ेगा

    • सोचता हूँ कि पिछले 10 सालों में भी लोगों को यह समझ नहीं आया कि Google का इस्तेमाल नहीं करना चाहिए। खासकर अब जब Google AI के ज़रिए स्वतंत्र साइटों को censor कर रहा है, इससे संबंधित टिप्पणी का सीधा लिंक भी है, अब मुझे लगता है कि Google किसी asset से ज़्यादा liability बन चुका है

  • bots की वजह से server log files इतनी बड़ी हो गईं कि मुझे अपने servers पर logging ही बंद करनी पड़ी। bots API, forms, यहाँ तक कि वेबसाइट के वे हिस्से भी लगातार scrape करते हैं जहाँ सिर्फ क्लिक करके पहुँचा जा सकता है। Anthropic, openAI, Facebook वगैरह अब भी मेरी साइट scrape कर रहे हैं

    • अगर कोई API सिर्फ क्लिक करके ही पहुँची जा सकती है, तो जिज्ञासा है कि bots वहाँ तक पहुँच कैसे रहे हैं

    • उस API वाली बात पर थोड़ा और जानना चाहूँगा। क्या मतलब UI का हिस्सा है या ऐसा भाग जिसे इंसान ही इस्तेमाल कर सकता है, या फिर वहाँ पहुँचने का कोई दूसरा रास्ता ही नहीं है? आजकल AI agents असली users के व्यवहार की नकल करते हैं, इसलिए इंसान और bot में फर्क करना लगभग असंभव होता जा रहा है

  • मुझे लगा था यह अच्छी बात है कि AI crawler bots User-Agent header ईमानदारी से भरते हैं, लेकिन यह जानकर थोड़ा हैरान हुआ कि इतना भारी traffic उसी वजह से है। ज़्यादातर वेबसाइटों को इतनी बार data की ज़रूरत नहीं होती, फिर भी traffic बहुत ज़्यादा है। developer blog हो तो यह और भी कम समझ आता है

    • ज़्यादातर AI crawlers robots.txt का पालन करते हैं, लेकिन block या रोके जाने पर वे तुरंत browser user-agent में बदल जाते हैं और residential IPs से फिर crawling की कोशिश करते हैं। हालांकि OpenAI/Amazon/Facebook होने का झूठा दावा करने वाले इतने ज़्यादा हैं कि सही मामलों को पहचानने में सावधानी रखनी चाहिए

  • मैं tirreno का निर्माता हूँ। हमारा platform live logged-in users के लिए optimize किया गया है, लेकिन bot detection और blocking में भी प्रभावी है। हम IP के आखिरी octet को * से बदलकर उसी subnet को एक account की तरह group करते हैं ताकि IP anonymize हो जाए। traffic anomalies (500/404 errors, brute-force login attempts, datacenter IPs आदि) के आधार पर automatic blacklist बनवाई जा सकती है। tirreno की blacklist API से unwanted traffic को error page पर redirect किया जा सकता है। monitoring dashboard भी है, जो false positives से बचने और management में मदद करता है
    tirreno Github, admin demo

    • आजकल कई ISPs CGNAT संरचना पर जा रहे हैं, जहाँ एक IP सैकड़ों असली users का प्रतिनिधित्व कर सकता है। ऐसे मामले को आप कैसे संभालते हैं, यह जानना चाहूँगा

    • मैं भी public IP ranges के आधार पर इसी तरह bot blocking बना रहा हूँ। सुधार के लिए कोई idea हो तो हमेशा स्वागत है

    • IP के आखिरी octet को बदलने वाली इस पद्धति की वजह से मैं किसी ऐसे address के पड़ोसियों के साथ एक ही user में बाँध दिया जाता हूँ जिसका मुझसे कोई संबंध नहीं। datacenter IPs के कारण false positives भी नज़रअंदाज़ नहीं किए जा सकते। हकीकत में अगर कुछ block न हो तो मुझे 87 traffic lights पर क्लिक करके जैसे-तैसे आगे बढ़ना पड़ता है। आखिरकार यह सब शायद इस दावे के लिए है कि false positive से बचाव के चरण में भी मेरी personal info बिना consent के इकट्ठी नहीं की जा रही। कृपया ऐसा feedback mechanism ज़रूर रखें जिससे customers को तुरंत पता चले कि वे असली paying users खो रहे हैं

  • एक बात जो मैं बहुत समय से सोच रहा हूँ, क्या “page knocking” यानी किसी खास क्रम में pages खोलकर access पाने वाली संरचना संभव हो सकती है? उदाहरण के लिए, पहले किसी तय private URL पर जाना पड़े, तभी बाकी pages 404 के बजाय सामान्य रूप से खुलें

    • ऐसी architecture उन मामलों के लिए ठीक नहीं बैठेगी जहाँ आम users को search engine से project ढूँढकर सीधे पहुँचने देना होता है, बिना account creation या अलग authentication के

    • usability के लिहाज़ से, चाहे इसे जितना भी अच्छे से design करें, असुविधा तो होगी ही। bookmark खोलने या दोस्त को link भेजने पर भी बार-बार 404 मिलने की परेशानी होगी

  • मेरा छोटा server ठीक चल रहा था, इसलिए मैंने हाल में fail2ban की स्थिति नहीं देखी थी
    कमांड चलाने का परिणाम:

    sshd-ddos:      0
postfix:       583
dovecot:     9690
postfix-sasl: 4227
nginx-botsearch: 1421
nginx-http-auth: 0
postfix-botnet:  5425
sshd:         202157

220,000 से ज़्यादा IPs block हुए देखकर थोड़ा झटका लगा

  • जिस bot को हम track कर रहे हैं, DotBot/1.2, उसने पिछले 2 हफ्तों में 220,000 से ज़्यादा requests छोड़ी हैं। pattern यह है कि वह webserver पर files और folders के नाम random तरीके से माँगता रहता है। जिज्ञासा में मैंने उसे जानबूझकर block नहीं किया, बस देख रहा हूँ कि वह कितनी दूर तक जाता है

  • अब लगता है कि AI या search engines के लिए centralized indexing संरचना को push या submission मॉडल पर बदलना चाहिए। अगर sharing सिर्फ तब हो जब मैं खुद चाहूँ, तो scraping की समस्या काफी कम हो सकती है

  • 90 के दशक में जब मैं बच्चा था, मुझे ISP से फोन आया था कि मेरा कंप्यूटर botnet में फँस गया है और इसलिए मेरा internet access बंद किया जा रहा है। कभी-कभी लगता है कि क्या हम उस दौर में वापस जा सकते हैं, और जो ISP यह सब होने देते हैं उनके पूरे ASN को ही block कर दें, तो शायद यह समस्या खत्म हो जाए

    • residential proxies ISP सीधे नहीं देते, बल्कि दुनिया भर में users जानबूझकर या अनजाने में malware install कर लेते हैं और अपना कंप्यूटर proxy के रूप में उपलब्ध करा देते हैं। कुछ समय पहले HN पर इस बारे में एक अच्छा लेख आया था

    • मैंने अपने network पर firewall rule सेट किया है जो हर बार alert देता है जब कोई device malware से जुड़े ports पर outbound connection की कोशिश करता है। port list को समय-समय पर update करना पड़ता है क्योंकि malware के targets बदलते रहते हैं। छोटा-सा उपाय है, लेकिन यह भी एक अतिरिक्त रक्षा-स्तर है