अगर समस्या है, तो IP स्तर पर ब्लॉक करें
(boston.conman.org)- हाल ही में web traffic का विश्लेषण करते समय पाया गया कि Thinkbot नाम का web bot सबसे अधिक traffic पैदा कर रहा था
- यह bot
robots.txtको अनदेखा करता है, और उसका self-introduction भी बेहद लापरवाह है—बस इतना कि “अगर समस्या है तो IP block कर दो” - एक महीने के दौरान इसने 74 अलग-अलग IP का इस्तेमाल किया, जो 41 network blocks में फैले हुए थे
- जांच में पता चला कि ये सभी network blocks Tencent के स्वामित्व में थे, जिससे यह संदेह पैदा हुआ कि कहीं यह Great Firewall की लागत दूसरों पर डालने से जुड़ा मामला तो नहीं
- अंततः लगभग 4.7 लाख से अधिक IPs को शामिल करने वाला एक विशाल block rule जोड़ा गया
Thinkbot का उभरना
- web traffic के विश्लेषण के दौरान पाया गया कि Thinkbot नाम का web bot शीर्ष हिस्सेदारी ले रहा था
- User-Agent string इस तरह बेहद लापरवाह थी
“Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.)”.
- “test phase में समस्या हो तो IP block कर दीजिए” जैसी पंक्ति के अलावा कोई reference URL भी नहीं था
- इसने
robots.txtफ़ाइल का बिल्कुल सम्मान नहीं किया और crawling जारी रखी - website operator के तौर पर इसे block करना चाहें तो भी यह किसी एक IP से नहीं, बल्कि 74 IP addresses का इस्तेमाल कर रहा था
- इसे trace back करके ASN देखा गया तो पता चला कि यह 41 network blocks से आ रहा था
- इसका मतलब था कि सिर्फ एक IP block करके इससे बचाव संभव नहीं था
Tencent से संबंध
- ये सभी 41 network blocks Tencent के स्वामित्व में थे
- लेखक को संदेह है कि चीनी सरकार इसे नज़रअंदाज़ कर रही हो या प्रोत्साहित कर रही हो, और इसे बाहरी दुनिया पर Great Firewall की लागत थोपने की कोशिश के रूप में पढ़ा जा सकता है
- चीन के भीतर content collection की अनुमति रहती है, और बाहर से block कर दिया जाए तो भी CCP के नज़रिए से यह समस्या नहीं, लेकिन block करने की कोशिश करने वाले दूसरे देशों और sites पर इसका बोझ पड़ता है
Firewall block कार्रवाई
- लेखक ने सीधे badbots firewall rules में Tencent network blocks जोड़ दिए
- उदाहरण:
43.130.0.0/18,101.32.0.0/20,150.109.96.0/19आदि - कुल 40 से अधिक network blocks जोड़े गए; ये Tencent के सभी IPs को कवर नहीं करते, लेकिन इनमें 476,590 से अधिक unique IPs शामिल हैं
निष्कर्ष और रूपक
- लेखक ने इस स्थिति को इस वास्तविकता के रूप में व्यक्त किया कि “internet पर अब अच्छी चीज़ें बरकरार नहीं रखी जा सकतीं”
- यह सिर्फ bot traffic block करने का मामला नहीं, बल्कि पूरे internet ecosystem में भरोसे की गिरावट और अपरिहार्य रक्षात्मक प्रतिक्रिया को दिखाने वाला उदाहरण है
6 टिप्पणियां
असल में चीन-खतरे की बात दूसरे क्षेत्रों में तो बहुत पहले ही हकीकत बन चुकी थी, लेकिन अब लगता है कि चीन इंटरनेट ecosystem के समग्र अस्तित्व को भी खतरे में डालना शुरू कर रहा है।
यह कोई बात सिर्फ नफ़रत की भावना या राजनीतिक पक्षपात के आधार पर नहीं कही जा रही, बल्कि यह सचमुच हकीकत बनती जा रही है—और मुझे लगता है कि बहुत से लोगों को यह समझने की ज़रूरत है।
अगर समस्या है, तो IP लेवल पर ब्लॉक कीजिए
हर बार ऐसे मामले-हादसों की तह में जाओ तो आखिर में CCP ही निकलता है..
वाह.. सच में कमाल है..
वाह..
फिर से चीन ही है।
Hacker News राय
वेब crawler बनाते समय मैंने उसे जितना हो सके उतना friendly बनाने की कोशिश की।
robots.txtको सख्ती से चेक किया, धीरे crawl किया, User Agent string में अपनी पहचान साफ़ लिखी, और सिर्फ़ एक IP address इस्तेमाल किया। लेकिन फिरrobots.txtफ़ाइल पर ही तरह-तरह की anti-bot tricks लागू होती दिखीं। हाल में तोrobots.txtslow loris attack की तरह बहुत धीरे डाउनलोड हुआ, जिससे मैंने गलती से उसे 404 मान लिया और crawl जारी रखा। उस अनुभव के बाद timeout होने परDisallow /मानने वाला code लिख दिया। विडंबना यह है कि नियमों का पालन करने की कोशिश करते-करते भी anti-bot tools को detect करने वाला code लिखना पड़ रहा हैयह ऐसा है जैसे चोरों को रोकने के लिए doorbell ही छिपा दी जाए
जैसे server application में करते हैं, वैसे ही client side पर भी अगर सामने वाला malicious हो या ग़लत व्यवहार करे, तो चुपचाप TCP connection काट देता हूँ। फिर सामने वाले को कुछ समय तक resources बर्बाद करने के बाद खुद समझना चाहिए कि क्या हुआ
मुझे लगता है कि कई बार यह जानबूझकर नहीं होता।
robots.txtनियम न मानने वाले malicious bots तो वैसे भी यह फ़ाइल डाउनलोड ही नहीं करते, इसलिए यह बुरी नीयत से ज़्यादा गलती या अयोग्यता भी हो सकती हैजो लोग नियम मानने की कोशिश करते हैं, सिर्फ़ उन्हीं को दंडित करने वाली व्यवस्था उल्टा असर करती है
नियमों का ठीक से पालन करने की कोशिश सराहनीय है।
robots.txtपर limits लगाना शायद गलती हो, लेकिन कुछ crawlersrobots.txtसे और भी दिलचस्प pages ढूँढ़ लेते हैं, इसलिए उसे धीमा करना जल्दी में समस्या टालने का तरीका हो सकता है। आख़िरकार यह bots की जानकारी रोकता है और उन्हें धीमा भी करता है। site operator के नज़रिए से malicious bots से नुकसान हो रहा है, इसलिए honest bots और बुरे bots में फ़र्क करने पर वे हमेशा ज़्यादा ध्यान नहीं दे पातेमुझे जिज्ञासा है कि bots से बुरी तरह प्रभावित होने वाली websites में क्या common होता है। मैंने कई साल तक घर से
.comTLD पर web server चलाया है, संबंधित keywords पर Google search ranking भी काफ़ी अच्छी रही, और router या server पर कोई ख़ास bot-blocking setting भी नहीं थी। जिज्ञासा में मैंने bots की requests गिनी थीं, लेकिन ज़्यादातर सिर्फ़ port scan करते थे या index page लेते थे, dynamic links को लगभग कभी follow नहीं करते थे। Apache 2 के समय भी और अब Axum के साथ कई sites चलाते हुए भी bots का कोई खास असर नहीं दिखा। सोचता हूँ शायद directory listing वजह हो सकती है, अच्छा होगा अगर कोई समझाएलगता है कि कई बहुत होशियार लोग web scraping issue को लेकर ज़रूरत से ज़्यादा obsessed हैं। अगर bot activity सच में site पर भारी load या गंभीर समस्या नहीं ला रही है—हालाँकि exceptions हो सकती हैं—तो ज़्यादातर मामलों में यह एक बेकार का ‘capture the flag’ game ही है। फ़र्क बस इतना है कि इसमें सामने वाले का flag मिलता नहीं, सिर्फ़ समय बर्बाद होता है। सबसे अच्छा जवाब शायद यह है कि तेज़ और अच्छी तरह designed web product बनाया जाए, ताकि load पैदा करने वाले, पहचानना मुश्किल participants के फैलने पर भी system टिके रहे। व्यावहारिक रूप से यह असली human users की satisfaction भी बहुत बढ़ाता है
मेरे अनुभव में हो सकता है कि आपको इस समस्या की गंभीरता का अंदाज़ा न हो। पिछली नौकरी में मैं web app की application performance देखता था। कुछ users के लिए app बिजली जैसी तेज़ थी, लेकिन ज़्यादातर के लिए धीमी। performance logs देखने पर पता चला कि कुल requests का 60% known bots का था—अजीब bots को छोड़कर। कुछ companies ने तो service पर DoS attack भी किया, जिससे site डाउन हो गई थी। दिक्कत यह है कि bots हमेशा cached responses ही लेते हैं, इसलिए असली user conversations LRU cache से बार-बार बाहर हो जाती हैं। कुछ bots हर visited page को हर कुछ मिनट में फिर scrape करते हैं, और कुछ throughput बढ़ाते रहते हैं जब तक service धीमी न पड़ जाए। कभी-कभी वे JavaScript चलाने और forms submit करने की भी कोशिश करते हैं। सिर्फ़ Googlebot ही शालीनता से व्यवहार करता है। असली incoming traffic का 40% सिर्फ़ एक URL पर जाता था, इसलिए bots से कोई खास फायदा भी नहीं था। बाद में समझ आया कि इनमें से बहुत से bots शुरुआती AI companies के data collection के लिए थे
मेरा एक दोस्त सिर्फ़ दोस्तों के इस्तेमाल के लिए छोटा-सा public
giteainstance चलाता है। फिर भी हर घंटे हज़ारों bot requests आती हैं। सेवा पर सीधा असर न भी पड़े, तो भी कम से कम यह harassment जैसा लगता हैमैं तेज़ web product बनाने के लिए data premium देकर हासिल करता हूँ। इसलिए ऐसे entities को block करना समय की बर्बादी नहीं, बल्कि सच में bandwidth और server cost बचाना है। और इससे असली customers को भी वही फायदा मिलता है, भले ही content scrape न हो। मुझे यह तर्क समझ नहीं आता कि कोई आपको exploit कर रहा हो और आप कुछ न करें
‘capture the flag’ से ज़्यादा यह whack-a-mole game जैसा है। मेरे अनुभव में, जिन forums में लोग ‘bad bots’ को पहचानकर block करने की कोशिश करते हैं, वहाँ हमेशा और bots आते रहते हैं और इसका अंत नहीं होता
हममें बहुत से लोग होशियार हैं, लेकिन tech problems पर ज़रूरत से ज़्यादा अटक भी जाते हैं। कुछ न किया जाए तो वह बात दिमाग में बनी रहती है; कम से कम block कर देने से चिढ़ थोड़ी कम होती है
मुझे हमेशा हैरानी होती है कि Hacker News पर इतने लोग
robots.txtको गंभीरता से लेते हैं। यह देखना अच्छा लगता है कि अच्छे इरादों वाले लोग अब भी बहुत हैं। लेकिनrobots.txtकोई व्यावहारिक समाधान नहीं है। लोगों कोrobots.txtके बारे में पता होना चाहिए, और crawler में उसे check करने वाला code भी जोड़ना पड़ता है, इसलिए complexity बढ़ती है। सोचता हूँ क्या कोई और practical solution है। ‘micropayments’ या ‘identity verification के लिए giant Merkle tree’ जैसी बातें बहुत समय से उठती रही हैं, लेकिन कभी वास्तव में लागू नहीं हुईंमुझे नहीं लगता कि कोई bot developer
robots.txtसे अनजान होगा। बस कुछ लोग मान लेते हैं कि उनका project एक special case है और सबके नियमों को ignore कर सकता हैrobots.txtकी कोई legal enforceability नहीं हैहमारे logs में भी ऐसे bot patterns दिखते हैं। काफ़ी परेशान करने वाले हैं, लेकिन कम से कम वे खुद को bot बताते हैं और असली traffic बहुत ज़्यादा नहीं है। ज़्यादातर traffic उन bots का है जो खुद को real browser बताते हैं, या Brazil और Asia के कई IPs से आते हैं। पिछले हफ़्ते मैंने bot blocking के लिए तरह-तरह के प्रयोग किए, इसलिए कुछ उपयोगी अनुभव साझा कर रहा हूँ।
सैकड़ों IPs से दिन में सिर्फ़ कुछ बार requests आती हैं, लेकिन सब real UA बनकर आते हैं
वे लगभग कभी referrer URL नहीं भेजते, लेकिन Huawei Cloud bot कभी-कभी referrer भेजता है (हालाँकि traffic कम है)
मेरा मुख्य प्रयोग यह था कि
id=वाले URLs की bandwidth limit (1Kb/s) कर दूँ ताकि वे धीमे पड़कर हार मान लें, लेकिन bots को कोई फ़र्क नहीं पड़ा और वे requests करते रहेउन्होंने keep-alive connections के हिसाब से भी खुद को ढाल लिया, इसलिए
/cgit/पर keep-alive पूरी तरह बंद किया, लेकिन फिर भी उन्होंने connections घेर लिएअभी मैं यह कर रहा हूँ कि
id=वाले URLs सिर्फ़ तब allow हों जब query string मेंnotbotहो; अगर referrer नहीं है तो 403 message में बता देता हूँ कि legitimate user हो तोnotbotparameter जोड़ो। इससे load कम हुआ और legitimate users के connections बेहतर हुए, लेकिन bots अब भी requests करते हैं और बस 403 पाते रहते हैंनिष्कर्ष यही लगता है कि या तो हर site के लिए special ad hoc तरीका अपनाओ, या Cloudflare जैसी resources वाली service को काम सौंपो। standard bot-blocking solutions की सीमा यह है कि जिनके पास बहुत resources हैं वे उन्हें bypass कर लेते हैं या उसकी cost झेल लेते हैं
एक तरीका यह भी है कि
MSIE 3.0याHP-UXजैसे कम इस्तेमाल होने वाले UA substrings को पहले से 403 दे दो। फिर 403 logs इकट्ठा करके problem वाले ASN को अलग से block करते रहो—यानी वही whack-a-moleमैं djbwares के Bernstein
publicfileपरिवार के software का इस्तेमाल करता हूँ। साथ में static GEMINI UCSPI-SSL tools भी जोड़े हैं, और GEMINI spec से लिया गया एक विचार लागू किया है: request URL में fragment और query parameters दोनों को पूरी तरह ban करना। वजह वही है जो GEMINI में ban करने के पीछे है, और यह static HTTP service पर भी लागू होती है। server setup में query parameters को सही तरह handle करने के लिए कई अजीब filenames अलग से बनानी पड़तीं, जो व्यावहारिक नहीं है। इस विचार की वजह से CGI या PHP vulnerabilities पर होने वाली attack attempts filesystem तक पहुँचती ही नहीं, request parsing के चरण में ही रुक जाती हैं। static site operators को मैं GEMINI की तरह query parameters भी block करने की सलाह दूँगा। हाँ, अगर कोई static site category में सचमुच query parameters इस्तेमाल करना चाहता है, तो यह अपवाद होगाकुछ समय से सोच रहा हूँ कि क्या कभी IP ranges को whitelist करने का तरीका सच में व्यावहारिक हो सकता है। adblock lists की तरह community effort से maintain होने वाला approach भी दिमाग में आता है
दुर्भाग्य से, अच्छे bots ही आमतौर पर stable IPs इस्तेमाल करते हैं, जबकि malicious actors कभी भी residential proxies इस्तेमाल कर लेते हैं। residential proxy IPs को ban करने पर असली users को नुकसान होता है, और बुरा actor तुरंत कहीं और चला जाता है। हज़ारों IPs के साथ काम करने के अनुभव से कहूँ तो, सिर्फ़ IP-based information से फ़ैसला करना मुश्किल है; अतिरिक्त signals चाहिए
Pokémon Go वाली company ने भी launch के तुरंत बाद scraping रोकने के लिए यही तरीका आज़माया था। उन्होंने IPs को तीन categories में बाँटा: blacklist (
Google Cloud,AWSआदि), untrusted IPs (residential), और whitelist (सामान्य IPv4 आदि)। शुरुआत में इसने बड़े scrapers को रोका, लेकिन सबसे बड़े scraper ने modem farms चलाकर इसे bypass कर लिया। नतीजा यह हुआ कि आम users ने map के बिना game छोड़ दिया, और hardcore players ने उल्टा scraper usage के लिए पैसे देना बढ़ा दिया। आख़िरकार servers पर और ज़्यादा load आ गया। Pokémon Go के कई खराब फैसलों में से यह भी एक थाबहुत-सी अमेरिकी companies यह पहले से कर रही हैं। लेकिन जब आप विदेश में हों और service cancel करने का तरीका भी न दिया जाए, जबकि वे billing जारी रखें, तो यह अव्यावहारिक है
whitelist और blacklist को ज़रूरी नहीं कि binary choice की तरह देखना पड़े। ज़्यादातर traffic grey zone में होता है। अगर किसी IP को whitelist किया गया और बाद में suspicious behavior दिखा, तो उसे whitelist से हटाना, सूचना देना, रिपोर्ट लेना, और resolution तक mutual coordination करना बहुत जटिल हो जाता है। whitelist असल में सिर्फ़ trusted partners के बीच प्रभावी है। blacklist problem addresses, या CIA, Russia, China, cloud providers वगैरह को block करने में उपयोगी हो सकती है। robust anti-abuse systems वाले internal corporate hosts जैसी चीज़ों को ही whitelist करना व्यावहारिक approach है
मैं open source project GoodBots के ज़रिए अच्छे bots की positive whitelist बना रहा हूँ। PR का स्वागत है
मैं सभी requests में custom header जोड़कर भेजता हूँ, और बाकी सभी requests को block कर देता हूँ
बाहर की तरफ़ Cloudflare proxy है, और अंदर Crowdsec तथा Modsecurity CRS को Traefik के सामने रखा है। false positives कम करने के लिए tuning के बाद यह बहुत स्थिर चल रहा है। temporarily blocked IPs और reported IPs को Crowdsec में भेजता हूँ, फिर logs को Discord channel में पोस्ट करता हूँ। औसतन रोज़ कई दर्जन अलग-अलग IPs block होते हैं। महसूस होता है कि private resources तक पहुँचने या CVE exploit करने की कोशिशें US IPs से China IPs की तुलना में कहीं ज़्यादा आती हैं। public content crawling की मुझे परवाह नहीं, बाकी सब कुछ सिर्फ़ SSO या intranet से ही accessible है। specific countries को block करने से ज़्यादा असरदार है कि exploit या flooding attempts को ही रोका जाए
Crowdsec जैसा approach आकर्षक है, लेकिन मुझे लगता है कि server का सारा traffic किसी for-profit company को दे देना बड़ा risk है
गंभीर attack attempts तो आख़िरकार Cloudflare WAF जैसी जगह पर पहले ही block हो जाएँगी
कई apartment buildings सिर्फ़ कुछ IP addresses के ज़रिए ही बाहर की दुनिया से जुड़ पाते हैं (Carrier-grade NAT देखें)
मेरे traffic का आधे से ज़्यादा हिस्सा Bing, Claude और Facebook bots का है। ये traffic के बड़े contributor नहीं हैं, लेकिन server resources खा जाते हैं और site धीमी होने पर अक्सर मुख्य कारण बनते हैं (AI, Microsoft और Facebook कई बार सामान्य समझ को भी नज़रअंदाज़ कर देते हैं)। China वगैरह तो malicious traffic का सिर्फ़ एक हिस्सा हैं; असली समस्या वे अमेरिकी companies हैं जो
robots.txtया DNS rate limit को ignore करती हैं