Amazon AI crawler से अस्थिर हुआ मेरा Git server

 (xeiaso.net)
1 पॉइंट द्वारा GN⁺ 2025-01-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सार्वजनिक Gitea server git.xeserv.us AmazonBot requests की वजह से अस्थिर हो गया, इसलिए operator ने AmazonBot team से इस domain को block list में डालने का अनुरोध किया
  • robots.txt में सभी bots के लिए Disallow: / सेट किया गया था, फिर भी requests आती रहीं, जिससे public Git server चलाने का काम ही बंद करना पड़ सकता था
  • AI crawlers user agent बदलकर या residential IP proxy इस्तेमाल करके blocking को मुश्किल बना देते हैं
  • nginx ingress में Amazon user agent पर 418 return करने के लिए block लगाया गया, लेकिन requests अलग-अलग IPs से जारी रहीं और करीब 10% में amazonbot user agent भी नहीं था
  • आखिरकार Gitea server को फिर से VPN के पीछे ले जाया गया, और requests से पहले proof-of-work check करने वाला reverse proxy Anubis बनाया गया

AmazonBot requests और robots.txt की सीमाएं

  • operator ने AmazonBot operators से git.xeserv.us को blocked domains list में जोड़ने का अनुरोध किया
  • उन्होंने कहा कि अगर Git server को crawl करना है, तो अत्यधिक resource usage संभालने के लिए hardware upgrade cost चुकाने के बारे में संपर्क करें
  • सभी bots को रोकने वाला robots.txt पहले से configured था, लेकिन वास्तविक requests रोकने के लिए यह पर्याप्त नहीं था
User-agent: *
Disallow: /
  • AI crawler bots को block करना मुश्किल क्यों है, इसे भी संक्षेप में बताया गया
    • bots झूठ बोलते हैं
    • user agent बदलते हैं
    • residential IP addresses को proxy के रूप में इस्तेमाल करते हैं
    • और भी तरीके अपनाते हैं

nginx ingress blocking और Anubis का公開 होना

  • 2025-01-17 17:50 UTC पर nginx ingress configuration में user agent blocking जोड़ी गई
nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($http_user_agent ~* "(Amazon)" ){
    return 418;
  }
  • इस setting के बाद भी bot हर बार अलग IP से requests करता रहा, और करीब 10% requests में amazonbot user agent नहीं था
  • 2025-01-18 19:00 UTC पर Gitea server को फिर से VPN के पीछे ले जाया गया
  • इसके बाद Gitea server के front में requests allow करने से पहले proof-of-work check करने वाला reverse proxy बनाना शुरू किया गया
  • 2025-01-18 23:50 UTC पर यह proxy Anubis नाम से https://git.xeserv.us/ पर देखा जा सकने लगा
  • 2025-03-26 14:27 UTC तक Anubis एक standalone project बन गया, जिसकी documentation site है

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

1 टिप्पणियां

 
GN⁺ 2025-01-19
Hacker News की राय

  • अब वकील के नाम से पत्र भेजने का समय है। Computer Fraud and Abuse Act के अभियोजन दिशानिर्देशों को देखें तो, अमेरिकी न्याय विभाग आम तौर पर ऐसे public server access को, जो स्पष्ट हमला न हो, “unauthorized access” नहीं मानता; लेकिन उसके बाद यदि अधिकार-धारक स्पष्ट लिखित cease request भेजता है और प्रतिवादी उसे प्राप्त करके समझ लेता है, तो उस समय से इसे unauthorized माना जाता है।
    इसलिए किसी वकील से “स्पष्ट cease and desist” पत्र लिखवाइए, और वकील जिस तरीके की सलाह दे—registered mail या process server के जरिए—उसे Amazon तक पहुंचा दीजिए। शायद दोनों करने चाहिए और email भी भेजना चाहिए।
    इसके बाद देखें कि Amazon रुकता है या नहीं; अगर नहीं रुकता, तो आप criminal complaint दर्ज करा सकते हैं। तब Amazon भी इसे गंभीरता से लेगा।
    https://www.justice.gov/jm/jm-9-48000-computer-fraud

    • “देखें कि Amazon रुकता है या नहीं” तभी सही है जब वह request सच में Amazon से आ रही हो। लेख की details—rotating user agents, residential IPs, और ऐसा व्यवहार मानो robots.txt को parse नहीं किया जा रहा—देखकर इसकी संभावना कम लगती है।
      Amazon bot को ज्ञात Amazon IP ranges से आना चाहिए और robots.txt का पालन करना चाहिए। एक Amazon engineer ने भी दूसरे comment में इसकी पुष्टि की है: https://news.ycombinator.com/item?id=42751729
      अगर Amazon से मेल खाने वाली चीज सिर्फ “AmazonBot” user agent string है, और IP range या behavior मेल नहीं खाते, तो Amazon को lawyer letter भेजना पैसे जलाने जैसा है।
    • सच कहूं तो Hacker News के front page पर आ जाना ही इतना शर्मनाक होगा कि मुझे लगता है common sense department का कोई व्यक्ति मेरा विनम्र “कृपया मेरा git server scrape न करें” वाला email पढ़कर जवाब देगा। अगर अगले मंगलवार तक जवाब नहीं आया, तो मैं वकील से formal cease request letter लिखवाऊंगा।
    • क्या अब ऐसा कानून चाहिए कि “robots को robots.txt का पालन करना ही होगा”?
    • यहां process server से ठीक-ठीक क्या मतलब है, यह जानना चाहूंगा।

  • मुझे इस comment का solution पसंद आया: https://news.ycombinator.com/item?id=42727510
    साइट में कहीं ऐसा link डालें जिस पर कोई इंसान जाने वाला नहीं, robots.txt में उसे disallow कर दें, और अगर कोई IP उस link पर जाए तो उसे 24 घंटे के लिए block कर दें। कहा जा रहा है कि OpenAI crawler खास तौर पर wildcards ignore करता है, इसलिए उसे wildcard के नीचे रखने जैसा तरीका अपनाया गया।

    • मैंने पहले भी wide address ranges का इस्तेमाल करने वाली bot activity से निपटा है, और अगर conditions के आधार पर bot confirm हो जाए तो उस IP को 24 घंटे block करने जैसा तरीका इस्तेमाल किया है।
      लेकिन जुड़े हुए IP इतने ज्यादा थे कि traffic पर लगभग कोई असर नहीं पड़ा।
      मैं received headers को बहुत detail में देखने की सलाह दूंगा। varnishlog ऐसी चीजों के लिए काफी अच्छा है, और लंबे समय तक देखने पर आपको सभी requests में shared characteristics मिल सकते हैं। जैसे reported language और geographic location का अजीब combination, या वही पुराना browser version।
    • web crawlers सचमुच बेहद परेशान करने वाले हैं। करीब 8 साल पहले जहां मैं काम करता था, वहां vehicle image server down हो गया था। उस crawler ने उन vehicle image links को access किया जो हमारे काम की प्रकृति के कारण मौजूद थे, और साथ में यह सबसे खराब स्थिति भी थी कि images असल में मौजूद नहीं थीं; इस combination ने status report image server को effectively DoS कर दिया।
      और भी खराब यह था कि error handler में bug था, इसलिए यह condition आने पर server process restart हो जाता था, और उस दौरान “.NET 2.0 के हिसाब से काफी ठीक-ठाक” cache implementation भी invalidate हो जाता था।
      इसलिए याद है कि हमने safety measure के तौर पर canary technique डालनी शुरू की थी। कुछ simple canaries जोड़ना दूसरे web server जोड़ने से फिर भी सस्ता था। बेशक, हमने cache issue भी fix किया, और उस service पर bad requests बहुत ज्यादा होने पर “चीखने” वाला तरीका भी जोड़ा।
    • जब मैं अपने search engine के लिए crawler बना रहा था, तब मुझे पता चला कि real world के हिसाब से सही crawler library लगभग नहीं के बराबर हैं। आखिरकार Amazon और Google की काफी complex nested robots files और requested cooldown period तक का पालन करने वाला implementation खुद बनाने में काफी मेहनत लगी।
      लेकिन मजेदार बात यह है कि उन companies के अपने crawlers ही अपने बनाए manifests को parse नहीं कर पाते थे।

  • हम भी सभी AI·SEO bots में यही behavior देख रहे हैं, इसलिए यह recommend करता हूं। वे robots.txt का बस नाममात्र पालन करते हैं और block करना भी मुश्किल है। crawl करते समय वे spam की तरह टूट पड़ते हैं, load बहुत बढ़ाते हैं और कई customer servers को गिरा देते हैं।
    अगर AI crawlers access चाहते हैं, तो उन्हें ठीक से व्यवहार करना होगा या पैसे देने होंगे। नहीं तो नतीजा लगभग universal blocking होगा।

    • solution है global tarpit। AI crawlers को अलग रखकर भी यह समझ में आता है। जब पहले इसे implement करना पड़ा था, तो मैंने semi-manually access logs parse करके उन IPs पर iptables से -j TARPIT लगाया था जो /api पर औसतन प्रति सेकंड X से ज्यादा requests कर रहे थे।
      cloud में इसे कैसे implement करूंगा, यह ठीक से नहीं जानता। वहां अभी तक इसकी जरूरत नहीं पड़ी।
      https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62f...
    • “लगभग universal blocking” कैसे करेंगे, समझ नहीं आता। समस्या तो यही है कि यह मुश्किल है, है न? अगर संभव होता तो हम पहले ही ऐसा कर रहे होते।
    • robots.txt का “नाममात्र” पालन करने का क्या मतलब है, जानना चाहूंगा। क्या यह binary नहीं है? क्या मतलब यह है कि कुछ directives मानते हैं और बाकी ignore करते हैं?
    • क्या कोई तरीका नहीं कि websites अपना data बड़ी zip file के रूप में AI bots को बेच सकें? लगातार DDoS झेलने से तो बेहतर होगा।
      या कम से कम शिष्टाचार के तौर पर रात में या non-peak hours में scrape करें।
    • block करने से क्या फायदा? तब तक तो वे पूरा content scrape कर चुके होंगे।

  • मैं यह मानकर नहीं चलूंगा कि यह सचमुच Amazon है। लेखक ऐसे requests देख रहा है जिनमें residential IPs को rotate किया जा रहा है और user-agent string भी बदल रही है
    बड़ी कंपनी का crawler होने का नाटक करना उन लोगों की आम तरकीब है जो ध्यान में नहीं आना चाहते। requests का residential IPs से आना इस बात का बड़ा warning sign है कि कुछ और चल रहा है

    • मैं Amazon में काम करता हूं, लेकिन web crawling का सीधे जिम्मेदार नहीं हूं
      अंदरूनी तौर पर जो जानकारी देख पाया, उसके आधार पर इसके सचमुच Amazon होने की संभावना बहुत कम है। Amazonbot को robots.txt का पालन करना चाहिए और हमेशा Amazon-owned IP addresses से आना चाहिए। verification procedure यहां है: https://developer.amazon.com/en/amazonbot
      मैंने इसे internally forward कर दिया है ताकि यह पक्का कर सकूं कि कहीं कोई अजीब internal team, जिसके बारे में मुझे पता नहीं, ऐसा तो नहीं कर रही। लेकिन लेखक के लिए बेहतर होगा कि इस traffic को malicious मानकर user agent को झूठा बताने वाला समझे
    • ऐसी चीजें service के रूप में commercially उपलब्ध हैं[1]। किसी जगह शामिल किसी library की वजह से करोड़ों networks backdoor की तरह इस्तेमाल होकर crawlers/scrapers बन जाते हैं, और terms में कहीं मौजूद व्यापक भाषा से users को वैध और अवैध गतिविधियों के बीच की चीजों का मोहरा बनाना भी कानूनी जैसा बना दिया जाता है
      [1] https://brightdata.com/proxy-types/residential-proxies
    • आजकल अगर कोई company aggressive crawling कर रही है, तो यह पक्के तौर पर कहना मुश्किल है कि वह proxy network इस्तेमाल नहीं कर रही

  • हाल ही में मुझे भी यही समस्या हुई। मेरा Forgejo instance home server CPU का 100% इस्तेमाल करने लगा, क्योंकि Claude और Meta·Google के AI दोस्त लगभग अनंत links को तेज रफ्तार से hit कर रहे थे
    robots.txt और Caddy की user-agent आधारित block list से कुछ हद तक कम किया, लेकिन पता नहीं यह कितने समय तक काम करेगा
    scraping की शालीनता आखिर गई कहां?

    • वजह पैसा है। AI companies के पास जितना ज्यादा data, जितनी जल्दी हो सके, जहां से भी मिल सके, लेने का financial incentive है। अभी उनके पास जलाने के लिए इतना cash है कि efficiently करने की भी खास जरूरत नहीं
    • जब कई companies को यह संकेत मिला है कि कम-से-कम फिलहाल AI क्या खा सकता है, इस पर Overton window बहुत चौड़ी है, तो वे regulation कसने से पहले जितना हो सके उतना उठा लेना चाहेंगी
      इससे भी बड़ा खतरा यह है कि इनमें से कोई company, यहां तक कि खुद को “Open” कहने वाली भी, economy या national security के नजरिए से “fail होने देने लायक नहीं” आकार की हो जाए
    • वही हुआ है जो हर दूसरे context में शालीनता के साथ हुआ। शालीनता सिर्फ उन contexts में मौजूद थी जहां उसे ignore करने से पैसा नहीं बनता था। जैसे ही वह आधार खत्म हुआ, उसे तुरंत फेंक दिया गया
    • क्या कोई AI crawlers को रोकने के लिए ठीक-ठाक robots.txt या user-agent list share कर सकता है?
    • Hacker News पर आखिरी व्यक्ति को कब एहसास होगा कि Meta, OpenAI और सभी big tech companies तेज पैसे के लिए आखिरकार हम सबको नुकसान पहुंचाएंगी?
      Facebook इस बात के लिए मशहूर था कि उसने MySpace से friend list scrape करना आसान बनाया, और खुद बड़ा हो जाने के बाद अपनी site पर वही व्यवहार ban कर दिया
      कृपया होश में आना होगा

  • क्या पक्का है कि यह Amazon बनकर किया गया DDoS नहीं है?
    requests का residential IPs से आना सचमुच suspicious है
    ऐसे DDoS का motive छोटे sites को गिराना और इसे Amazon की गलती जैसा दिखाकर Amazon को निशाना बनाना हो सकता है
    अगर यह सचमुच Amazon है, तो शुरुआत उनके publish किए गए सभी IP ranges को block करने से होगी। हालांकि सुनने में लग रहा है कि requests उन ranges के बाहर से भी आ रहे हैं

    • grass dot io जैसी websites देखनी चाहिए। मैं direct link नहीं दूंगा क्योंकि उन्हें traffic नहीं देना चाहता
      ऐसी services users की bandwidth के लिए पैसा देती हैं और फिर उसे third parties को resell करती हैं, इसलिए काफी bot traffic residential IPs से आता हुआ दिखता है

  • मेरी site Pinboard भी शायद AI crawlers से पिट रही है। इस summer में यह China और Singapore IPs से शुरू हुआ था, लेकिन अब IP ranges block भी नहीं कर सकता, इसलिए CAPTCHA पर निर्भर होना पड़ रहा है
    traffic level इतना है कि site को तुरंत मार दे, और मेरे पास train कराने लायक कोई interesting text भी नहीं है, सिर्फ links हैं
    मुझे हैरानी है कि original poster को कैसे पता चला कि Amazon crawler वजह है। मैं भी दोष डालने के लिए कोई target ढूंढना चाहता हूं

  • ऐसी चीजों से लड़ने का सबसे अच्छा तरीका blocking नहीं हो सकता। blocking Amazon या किसी और company को कोई नुकसान नहीं पहुंचाती
    इसके बजाय अगर bot को साफ तौर पर harmful या corrupting content खिलाया जा सके तो?
    अगर यह बड़े scale पर हो और Amazon को poison data मिले, तो उन्हें उसे जल्दी हटाने पर पैसा खर्च करना पड़ेगा और वे bots को ऐसा data खाने से रोकने की कोशिश करेंगे
    बेशक सबसे बड़ी समस्या यह है कि ऐसी चीज अपनी site पर रखना कोई नहीं चाहेगा

    • “harmful content” खिलाने का idea AI companies के खराब व्यवहार की सीमा को पूरी तरह गलत समझता है
      ये scrapers पहले से ही CSAM और उसके बराबर भयानक चीजें भी बिना झिझक खा रहे हैं। OpenAI के Kenya data-tagging subcontractors में से कुछ ने इसी वजह से काम छोड़ा था। यह 2023 का Time article है
      अभी AI companies को data quality की परवाह नहीं, वे सिर्फ quantity देखती हैं। उन्हें नुकसान पहुंचाने का एकमात्र तरीका 0 bytes देना है
      Sam Altman ने जिसकी मंजूरी दी है, उसका 10वां हिस्सा भी कोई आम आदमी करे तो सीधे जेल जाएगा
    • इस मकसद के लिए मैंने इस tarpit की recommendation देखी है। जब site crawl होती है, तो यह endless directory nesting और अंतहीन junk content बनाता है ताकि bot घंटों उसमें फंसा रहे
      https://zadzmo.org/code/nepenthes/
    • अगर harmful content से मतलब inaccurate content है, तो इस thread के दूसरे comment में कोई असल में ऐसा कर रहा है: https://marcusb.org/hacks/quixotic.html
    • billionaire companies लगातार बिना सजा के कानून तोड़ती रहें, तो हवा के खिलाफ पेशाब करने की जिम्मेदारी मेरी क्यों हो?

  • Amazon और दूसरे bots द्वारा बनाए गए outbound traffic overage की भरपाई के सद्भावना संकेत के तौर पर कुछ AWS credits दे दें तो अच्छा होगा। फिर भी शायद इस post की ad revenue से यह cover हो जाएगा। ad blocker बंद कर दें तो हिसाब बराबर हो जाता है

  • Nginx से ब्लॉक करने से पहले, Bytespider 59% और Amazonbot 21% पर था; दोनों मिलकर हमारे Git सर्वर के कुल ट्रैफिक का 80% हिस्सा बना रहे थे
    ClaudeBot ने एक महीने में Redmine पर उतना ट्रैफिक भेजा, जितना ClaudeBot से पहले के 5 वर्षों को मिलाकर भी नहीं भेजा गया था