कुछ bots को block करने के तरीके

 (nochan.net)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CDN के बिना HTTP protocol/IP range/client signals/TCP characteristics/TLS fingerprint/content compression को मिलाकर, कमजोर implementation या configuration वाले ज़्यादातर bots को block करने के तरीकों को व्यवस्थित किया गया है
  • सभी तरीकों को चुनिंदा रूप से समायोजित करना चाहिए, और 1~3 साल के access logs का पहले विश्लेषण किए बिना VPN users/search engines/CDN/schools/libraries/विशिष्ट language users को साथ में block किया जा सकता है
  • HTTP/1.1 clients और data center के AS/CIDR ranges को block करने से कई bots हटाए जा सकते हैं, लेकिन GoogleBot सहित search engines और वैध data center users भी बाहर हो सकते हैं
  • Nginx header inspection और nftables के TCP window size/MSS/TTL filters साधारण crawlers और scanners को कम करते हैं, लेकिन LTE/VPN/Windows जैसे वैध environments में false positives हो सकते हैं
  • लंबे समय में JA4 TLS fingerprint detection और Brotli-only responses को विकल्प के रूप में सुझाया गया है, लेकिन यह पूरी blocking की गारंटी नहीं देता और revenue-generating services में इसका उपयोग न करने की चेतावनी दी गई है

block की सीमा और लागू करने की पूर्वशर्तें

  • पहले यह तय करना चाहिए कि लक्ष्य कुछ bots/ज़्यादातर bots/सभी bots में से कौन-सा है
    • यहाँ बताई गई विधियाँ परिष्कृत automation tools के पूरे वर्ग को नहीं, बल्कि कमजोर implementation या configuration वाले ज़्यादातर bots को अपेक्षाकृत सरल तरीके से block करने पर केंद्रित हैं
    • हर विधि के साथ वैध users और search engines को block करने के जोखिम को भी दिखाया गया है
  • 26 जुलाई 2026 को Hacker News पर साझा किए जाने के बाद, ज़्यादातर blocking features को ब्लॉग से एक अलग demo site पर ले जाकर ऐसा puzzle रूप देने की योजना है जिसमें पाठक तरीका पढ़ने के बाद खुद access करने की कोशिश करें
  • सभी settings को चुनकर बदला या छोड़ा जा सकता है, और वास्तविक उपयोग से पहले पर्याप्त जाँच और testing ज़रूरी है
  • वैध users/internal organizational systems/निर्भर external services block हो सकते हैं, इसलिए लागू करने की पूरी ज़िम्मेदारी operator की है
  • Revenue कमाने वाले production environment में इसका उपयोग न करें

तरीका 1: HTTP protocol से अलग करना

  • वैध users के block होने का जोखिम कम है, और कुछ search engines के block होने का जोखिम मध्यम है
  • यह इस अंतर का उपयोग करता है कि सामान्य browsers HTTP/2.0 इस्तेमाल करते हैं, जबकि कई bots HTTP/1.1 इस्तेमाल करते हैं
    • माना गया है कि GoogleBot HTTP/1.1 इस्तेमाल करता है और इस तरीके से block हो जाएगा
    • Bing और Facebook crawlers HTTP/2.0 इस्तेमाल करते हैं
    • HTTP/1.1 से link titles या छोटे previews लाने वाली services भी block हो सकती हैं
    • Opera Mini भी इससे बाहर हो जाएगा
  • Nginx में $server_protocol यदि HTTP/2.0 न हो तो उसे किसी दूसरे page पर redirect करने या 200, 403, 444 लौटाने के लिए configure किया जाता है
if ($server_protocol != HTTP/2.0) {  
    return 403 'Upgrade your client';  
}
  • 444 लौटाने पर अलग response दिए बिना connection बंद किया जा सकता है
  • Google search traffic को block करने से होने वाले नुकसान की तुलना में फायदा ज़्यादा है या नहीं, यह हर संगठन को खुद तय करना चाहिए

तरीका 2: data center IP ranges को block करना

  • वैध home/LTE users के block होने का जोखिम कम है, लेकिन VPN users के लिए मध्यम है, और data center में चलने वाले search engines के लिए block होने का जोखिम बहुत अधिक है
  • हाल के 1~2 साल के access logs में नीचे दिए signals को मिलाकर संदिग्ध requests खोजी जाती हैं
    • HTTP protocol
    • User-Agent
    • Accept-Language
    • Sec-Fetch-Mode
    • Accept
  • संदिग्ध IP को BGP Tools या Hurricane Electric BGP Toolkit में देखकर उसका AS और advertised Prefix जाँचा जाता है
  • दिया गया network blackhole list CDN और search engine ranges भी शामिल कर सकता है, इसलिए चुनकर लागू करना चाहिए
  • अलग सूची से पहले 3/8, 10/8, 11/8, 25/8, 26/8, 38/8, 41/8, 60/8, 61/8, 200/8, 224/3 ranges को पहले से blackhole करने वाला configuration इस्तेमाल किया गया है
  • AS के Prefix page को copy करके shell function से सिर्फ CIDR निकालकर sort/deduplicate/merge किया जाता है
    • sum_cidr.pl का उपयोग होता है और Perl module Net::CIDR::Lite चाहिए
    • बने हुए परिणाम की समीक्षा के बाद उसे /usr/local/etc/*.netset file में ले जाया जाता है
  • server start होने पर हर CIDR को blackhole route के रूप में जोड़ा जाता है
for CflIP in $(grep -E ^[1-9] /usr/local/etc/_cloudflare.netset); do  
    /sbin/ip route add blackhole "${CflIP}" 2>/dev/null  
done
  • उदाहरण में पूरे Cloudflare range को block किया गया है ताकि Workers आदि के जरिए requests स्वीकार न हों
  • firewall के ipset rules की तुलना में Linux blackhole routing कम CPU इस्तेमाल करती है, इसलिए routing approach चुना गया है
  • वर्तमान server जिस hosting provider में है, उसके ranges भी block किए जा सकते हैं
    • DNS/configuration/internal services में वही address space इस्तेमाल नहीं होना चाहिए
    • directly connected gateway routes, blackhole routes पर प्राथमिकता लेते हैं

तरीका 3: country/proxy/Tor/malicious IP block करना

  • FireHOL Blocklists repository से lists डाउनलोड करके ज़रूरी ranges को blackhole routes के रूप में जोड़ा जाता है
  • list files में comments होते हैं, इसलिए grep -Ev '^#' से हटाकर process करना चाहिए
  • खास तौर पर नीचे दी गई lists सुझाई गई हैं
    • firehol_abusers_30d.netset
    • firehol_level2.netset
  • बड़ी lists के कारण startup script का execution time लंबा हो सकता है
  • वास्तविक server और firewall configuration में इस्तेमाल की गई config files भी दी गई हैं

तरीका 4: HTTP client signals की जाँच

  • यह मानकर चला गया है कि User-Agent या headers को spoof किया जा सकता है, लेकिन speed को प्राथमिकता देने वाले सरल bots अक्सर इन्हें ठीक से spoof नहीं करते
  • Curl, Wget requests पर plain text लौटाया जाता है और Bot, GPT, LLM, Spider वाले requests पर 410 Gone लौटाया जाता है
if ($http_user_agent ~* Curl)   { return 200 '\nGNU Terry Pratchett\n\n'; }  
if ($http_user_agent ~* Wget)   { return 200 '\nGNU Terry Pratchett\n\n'; }  
if ($http_user_agent ~* Bot)    { return 410 '1000101'; }  
if ($http_user_agent ~* GPT)    { return 410 '1000101'; }  
if ($http_user_agent ~* LLM)    { return 410 '1000101'; }  
if ($http_user_agent ~* Spider) { return 410 '1000101'; }
  • देखे गए User-Agent के कुछ strings को एक लंबी regex में जाँचकर crawler/scanner/collection tools को block किया जाता है
    • इसमें Go-http, Java, libwww, okhttp, urllib, python, nmap, zgrab, semrush, shodan, rss, scrap, crawler, headless, github, facebook, google, bing आदि वाले substrings शामिल हैं
  • लागू करने से पहले 2~3 साल के User-Agent को aggregate करके देखना चाहिए कि कहीं असली वैध clients उस regex से match तो नहीं कर रहे
sort access-user-agents.txt | uniq -c | sort
  • अगर matching request HTTP/1.1 है, तो उसे bot होने की अधिक संभावना माना जाता है, हालांकि GoogleBot को अपवाद के रूप में देखना चाहिए
  • अगर request HTTP/2.0 है, तो BGP tools में IP ownership को अतिरिक्त रूप से जाँचा जाता है

Sec-Fetch-Mode

  • Sec-Fetch-Mode को access logs में जोड़कर, यदि उसका मान cors, no-cors, navigate में से कोई नहीं है तो block किया जाता है
if ($http_sec_fetch_mode !~ (cors|no-cors|navigate)) {  
    return 410 '1000101';  
}

Referer जाँच

  • दूसरे sites से content embed या scan करने वाली requests रोकने के लिए, Referer में कुछ विशेष strings होने पर block किया जाता है
    • admin pages/search engines/social networks/cryptocurrency/adult content/scanners/WordPress से जुड़े strings की जाँच की जाती है
  • https://www.google.com/ को Referer बताने वाले एक खास bot प्रकार को अलग से block किया जाता है
    • यह pattern उन requests में देखा गया जो पुराने Android होने का नाटक करते थे

HTTP methods सीमित करना

  • वैध browser requests के लिए ज़रूरी सिर्फ GET और POST की अनुमति दी जाती है और बाकी methods block कर दिए जाते हैं
if ($request_method !~ (^GET$|^POST)) {  
    return 410 '1000101';  
}
  • वास्तविक application में POST की ज़रूरत वाले paths को और बारीकी से सीमित किया जा सकता है, या अगर ज़रूरत न हो तो इसे पूरी तरह हटाया जा सकता है

proxy और browser shape की जाँच

  • X-Forwarded-For header होने पर उसे proxy request मानकर block किया जाता है
    • schools या libraries जैसे वैध shared proxy environments भी block हो सकते हैं
  • User-Agent में Linux, BSD, Macintosh, Windows, Mozilla, WhatsApp में से एक भी न हो तो request को browser जैसा न दिखने वाला माना जाता है
  • Accept-Language में en या es न होने पर block करने वाला rule भी इस्तेमाल होता है
    • इससे कुछ browsers और वे वैध users जिनकी भाषा English/Spanish नहीं है, block हो सकते हैं
  • br या sy शामिल language settings को अलग से block करने वाला optional rule भी दिया गया है

sensitive paths की scan blocking

  • नीचे दिए files या paths की request आने पर उसे automated scan मानकर block किया जाता है
    • .git
    • .yml
    • .db
    • .sql
    • .conf

तरीका 5: nftables से TCP scanners block करना

  • nftables की raw table के PREROUTING chain में TCP SYN packets की विशेषताओं की जाँच की जाती है
  • उदाहरण server address 172.238.221.88 को destination के रूप में स्पष्ट लिखा गया है ताकि packet loss की स्थिति में होने वाले false positives कम हों
  • 80/443 ports पर आने वाले SYN packets में नीचे की शर्तों को block किया जाता है
    • TCP window size 12,288 bytes से कम
    • MSS 1,220~1,460 range के बाहर
  • यह मानदंड इस्तेमाल किया गया है कि वास्तविक clients बड़े window size इस्तेमाल करते हैं, और इस range से बाहर का MSS वैध client होने की कम संभावना दिखाता है
  • MSS को ठीक 1460 तक सीमित करने पर नियम और सख्त हो जाता है, लेकिन इससे ज़्यादातर LTE और VPN users block हो सकते हैं

TTL-आधारित optional restriction

  • TCP SYN का TTL 128 से बड़ा होने पर ज़्यादातर LTE devices block किए जा सकते हैं
  • TTL 64 से बड़ा होने पर ज़्यादातर Windows systems भी block हो जाते हैं
  • default TTL का आधार इस तरह बताया गया है
    • Linux/Mac/BSD: 64
    • Windows: 128
    • LTE: इससे भी बड़ा मान

connection tracking से बाहर रखना

  • 80/443 ports को notrack के रूप में सेट करके web traffic को conntrack table में नहीं डाला जाता
  • इस स्थिति में filter table में send/receive direction के लिए stateless rules सीधे configure करने पड़ते हैं
  • उदाहरण में client source port 1000-65535 और server के 80/443 ports के बीच traffic की अनुमति दी गई है

तरीका 6: adult content और robot headers

  • adult content access restrictions के लिए RTA: Restricted To Adults header का उपयोग किया जाता है
  • RTA के अलावा उम्र सत्यापन के दूसरे तरीकों को user tracking और monetization के लिए माना गया है
  • Nginx responses में नीचे दिए headers हमेशा जोड़े जाते हैं
add_header Rating 'RTA-5042-1996-1400-1577-RTA' always;  
add_header adult 'porn, sex, politics, religion, philosophy' always;  
add_header X-Robots-Tag "none,noindex,nofollow,nosnippet,noai" always;
  • सामान्य bots इन headers को अनदेखा कर सकते हैं, लेकिन search engines या adult content से बचने के लिए डिज़ाइन किए गए bots पर इसका असर हो सकता है

तरीका 7: TLS fingerprint detection

  • ऊपर के 1~6 तरीके सभी मोटे heuristics हैं, और लंबे समय में TLS fingerprint analysis बेहतर विकल्प हो सकता है
  • यदि bots अपना TLS fingerprint सामान्य browsers जैसा नहीं बदलते, तो JA4 का उपयोग किया जा सकता है
  • पहले Deploying JA4 की deployment विधि देखकर, फिर FoxIO JA4 लागू करने का मार्गदर्शन दिया गया है

तरीका 8: सिर्फ Brotli-compressed content देना

  • site content को पहले से Brotli में compress करके web server को केवल compressed files लौटाने के लिए configure किया जाता है
  • यह इस बात का उपयोग करता है कि कई bots Brotli-compressed HTML को parse नहीं कर पाते
  • लागू करने के बाद देखा गया कि कई bots अब page links को follow नहीं करते, जिससे पुष्टि हुई कि वे वास्तव में HTML parse नहीं कर पा रहे
  • Nginx में static Brotli files हमेशा serve करने के लिए configuration किया जाता है
brotli_static always;
  • HTML files को इस तरह pre-compress किया जाता है
cat ./i.html | brotli --best -fncv > ./i.html.br

तरीका 9: scanners को खुद की पहचान करवाना

  • बार-बार vulnerability paths खोजने वाले शुरुआती attackers और scanners को कम करने का एक अलग तरीका Help Attackers Self Report में बताया गया है

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News की राय

  • कई public websites चलाने और दूसरी sites को scrape करके tools में इस्तेमाल करने वाले व्यक्ति के तौर पर, मुझे समझ नहीं आता कि लोग bots को लेकर इतना परेशान क्यों हैं
    cache वाले WordPress भी सबसे सस्ते VPS पर लगभग 1,000 requests प्रति सेकंड संभाल लेते हैं, और ठीक से बनी static site तो शायद इसका 10 गुना भी कर ले। सोचता हूँ क्या लोग blogs को Lambda जैसी किसी चीज़ पर serve कर रहे हैं, या यह बस जुनून, vulnerability defense, या उस दौर की आदत है जब crawling का सच में service पर असर पड़ता था

    • मेरे मामले में Forgejo instance समस्या है। ब्लॉग तो limited pages वाली static files है, इसलिए ठीक है, लेकिन Forgejo एक dynamic service है जहाँ bots लगभग अनंत pages ढूँढ सकते हैं, और कुछ pages बनाते समय background में Git भी चलता है, इसलिए छोटा server आसानी से overload हो जाता है
      repository open source है, इसलिए जानबूझकर public रखी है। अभी मैं simple cookie check से बचाव करता हूँ और केवल कुछ bots को ही गुजरने देता हूँ, लेकिन इसके बदले search engine visibility की क़ुर्बानी देनी पड़ती है
    • shared hosting पर मेरी personal site लगातार AI bot crawling की वजह से ज़्यादा CPU इस्तेमाल करने लगी और हाल ही में suspend कर दी गई। crawling अपने आप में उतनी समस्या नहीं है, असली दिक्कत यह है कि bots बहुत ज़्यादा हैं और बहुत inefficient तरीके से काम करते हैं
    • यह एक experiment है, मज़े के लिए देख रहा हूँ कि JavaScript जैसी कौन-सी common characteristics मिल सकती हैं जिन्हें bot operators के लिए avoid या bypass करना मुश्किल हो। यह ब्लॉग RAM disk पर रखे pre-compressed static content से चलता है, इसलिए शायद प्रति सेकंड लाखों requests भी संभाल सकता है
      मकसद यह दिखाना है कि forum, imageboard, chat server आदि पर इसे कैसे लागू किया जा सकता है, और हर option को tune या disable किया जा सकता है। असली deployment से पहले test server पर validate करना चाहिए, और चाहें तो बस इसे देखकर हँसकर आगे बढ़ सकते हैं
    • घर पर 40Gbit connection और उसके लायक server रखना संभव नहीं है। Google Cloud VPS की कुछ instances अगर nmap और तरह-तरह के web vulnerability scans चलाकर distributed denial-of-service attack करें, तो low-spec hardware की performance आसानी से गिर जाती है
      DMZ block होने की वजह से local IMAP server चेक करने में कुछ सेकंड और लग जाएँ, यह कोई बड़ी बात नहीं है, लेकिन इसका मतलब यह नहीं कि मुझे यह पसंद है या इसे लगातार होने देना चाहिए
    • सबसे बड़ी समस्या यह है कि bots से निपटने में वह समय छिन जाता है जो ज़्यादा उपयोगी कामों में लग सकता था
      इस weekend मैंने 10–20 साल से चला रहे viewvc (CVS·Subversion) और hgweb (Mercurial) web interfaces बंद कर दिए। residential proxy IPs से रोज़ 27 लाख requests, औसतन 30 requests प्रति सेकंड आ रही थीं, जिससे पुराने uWSGI/CGI programs और उसी server की दूसरी sites पर बोझ पड़ रहा था, और traffic भी VPS की 1TB monthly limit के करीब पहुँच गया था
      dynamic VCS URL combinations लाखों में हो सकते हैं, इसलिए cache का फायदा भी अनिश्चित था, और server को और tune करने में समय लगाना भी उचित नहीं लगा, इसलिए अंत में मैंने ऐसा फ़ैसला किया जो internet के और अधिक centralization की ओर एक और कदम है

  • “approved” user agents के अलावा सब कुछ block करना मौजूदा browser monopoly को और मज़बूत करेगा और dystopia को तेज़ी से ले आएगा। RMS दशकों से इसी तरह की समस्या के बारे में चेतावनी देते आए हैं
    अगर कुछ block करना है तो traffic volume और request frequency के आधार पर करना चाहिए। मैं भी अपनी site पर पहुँच नहीं पाता, लेकिन इसके हिसाब से चलने का इरादा नहीं है, और DRM की तरह, सामने वाला अगर पर्याप्त दृढ़ है तो आख़िरकार अंदर आ ही जाएगा

    • यह आलोचना मुझे स्वीकार है। मैं RMS के साथ कुछ बार रहा हूँ; वे दिलचस्प और बेहद बुद्धिमान व्यक्ति हैं, और अगर इस मुद्दे पर मुलाकात होती तो शायद उनकी अंतहीन डाँट सुननी पड़ती
      फिर भी, इस दावे से अलग कि आप कोई भी browser इस्तेमाल कर सकते हैं, ऐसे browsers से खास सावधानी रखनी चाहिए जो तुरंत-फुरंत generate किए गए code पर बने हों या malicious sites के ख़िलाफ़ पर्याप्त रूप से verify न किए गए हों। reader apps भी, अगर उन्होंने penetration testing experts द्वारा व्यापक third-party code review न करवाया हो, तो malicious servers के प्रति vulnerable हो सकते हैं
    • व्यवहार के आधार पर भी फैसला किया जा सकता है। go-away यह जाँचता है कि image और CSS load हो रहे हैं या नहीं, और meta refresh redirect follow किया जा रहा है या नहीं; Anubis यह देखता है कि कुछ सेकंड तक JavaScript execution संभव है या नहीं
    • user agent string अपने आप में ही ज़्यादातर हानिकारक है। अगर कोई नया browser है, तो बेहतर है कि बस Chrome user agent कॉपी कर ले

  • मुझे यह विचार पसंद आया कि 169.254.169.254 की ओर इशारा करने वाला नकली cpanel subdomain जोड़ दिया जाए, ताकि नौसिखिया attacker अपनी ही hosting provider पर port scan चला दे और इस वजह से detect या block हो जाए

    • जब मैंने पहली बार यह experiment किया, तो लगा था कुछ नहीं होगा। कुछ ही दिनों में Germany के Amazon EC2 पर किसी ने शायद उन records को खोजने के लिए मेरे domain के कुछ हिस्सों पर zone transfer की कोशिश की जिन्हें avoid करना चाहिए था; उसके बाद उसने मेरा domain पूरी तरह exclude कर दिया, और scanning भी जल्द रुक गई
      source IPs दुनिया भर में बिखरे हुए थे, लेकिन असली scanning noise दरअसल सिर्फ एक ही व्यक्ति से आ रहा था
    • समझ नहीं आता कि AWS को instance metadata service (IMDS) पर fail2ban चलाने की क्या ज़रूरत होगी। क्या उन्हें अपने implementation पर भरोसा नहीं है, या वे किसी बड़े customer का lawsuit चाहते हैं, यह भी सवाल है

  • IP-आधारित ब्लॉकिंग में सावधानी बरतनी चाहिए। IP रेंज कभी-कभी फिर से आवंटित हो जाती हैं, इसलिए किसी गलत व्यक्ति को ब्लॉक किया जा सकता है, और कई बार ऐसा भी देखा है कि किसी region या datacenter होने की वजह से ब्लॉक की गई रेंज बाद में residential ISP को चली गई
    HTTP/1.1 ब्लॉकिंग भी पुराने browser इस्तेमाल करने वाले असली users को रोक देने का बड़ा जोखिम रखती है। साथ ही, कुछ browser cross-origin request में पूरा URL नहीं भेजते, इसलिए Google search से आने पर referrer सिर्फ Google root page की ओर इशारा कर सकता है; अगर इसे bot का झूठ मानकर ब्लॉक कर दिया जाए, तो Google search से आने वाला traffic भी गायब हो सकता है

    • दुख की बात है कि कई लोग अनजाने में ऐसे network पर होते हैं जिन्हें residential VPN के रूप में दोबारा बेचा जाता है
      दूसरी ओर, HTTP/1.1 ब्लॉकिंग मुझे उचित लगती है। लगभग सभी browser को इससे आगे के protocol support किए हुए 10 साल से ज़्यादा हो चुके हैं, और अगर कोई browser इतना पुराना है, तो mainstream web का ज़्यादातर हिस्सा वैसे भी उसमें टूट चुका होगा, इसलिए किसी एक personal site का भी न चलना कोई अपवाद नहीं बल्कि रोज़मर्रा की बात होगी
    • शौकिया और experimental sites पर मैं Google के सभी ASN को पूरी तरह ब्लॉक करता हूँ। हाल में वहाँ से कोई उपयोगी traffic नहीं मिला, और मुझे लगता है कि search quality भी बिगड़ चुकी है
      पुराने browser और API tools छूट जाएँ तब भी HTTP/1.1 ब्लॉकिंग बनाए रखने का इरादा है। अगर यह किसी पुराने financial system का proprietary code हो तो समझ में आता है, लेकिन public internet को अपने ही लिए खुद को update करना चाहिए
      मैंने Google को बहुत पहले से ब्लॉक किया हुआ है, इसलिए Google से आने का दावा करने वाली सभी requests झूठी हैं। मैं blog को कई random domains में घुमाता हूँ ताकि relation और snapshot टूटे रहें, और लोग मेरी लिखी चीज़ें किन रास्तों से खोजें, इस पर नियंत्रण रखना चाहता हूँ
    • कुछ साल पहले मैंने AWS से आने वाले traffic को ब्लॉक किया और उस पर एक पोस्ट लिखी थी। आम तौर पर मेरे यहाँ हफ़्ते में कुछ दर्जन ही असली visitor आते हैं, लेकिन उस पोस्ट को लगभग 3 महीनों में 15,000 वास्तविक लोगों ने देखा और फिर उसे जल्दी भुला दिया गया
      इसकी वजह से मुझे एक मुफ्त penetration test भी मिल गया, और मैं इस निष्कर्ष पर पहुँचा कि बचाव उपाय और processing pipeline मज़बूत हैं। survival pressure की वजह से bot traffic का 90% VPN पर चला गया है और VPN endpoints Christmas tree की तरह चमक रहे हैं
      मैं one-time access IP feed भी दे सकता हूँ, लेकिन user का ठीक से verification होना चाहिए और उसका use case भी approved होना चाहिए। यह process अपने आप में मज़ेदार है
    • लेखक ने साफ़ कहा है कि कई तरह के असली users का ब्लॉक हो जाना भी उन्हें स्वीकार है, इसलिए मैं उनकी सलाह नहीं मानूँगा

  • अगर पढ़ा नहीं जा रहा है, तो archive copy https://archive.ph/d3236 पर देख सकते हैं

    • सामान्य iOS Safari users के लिए यह अफ़सोसनाक implementation है: https://i.ibb.co/vCDH79d0/IMG-0303.png
      मैं bot नहीं हूँ, फिर भी कुछ पढ़ने के लिए iCloud Private Relay बंद नहीं करना चाहूँगा। लेखक के दूसरे जवाबों के मुताबिक यह test site के रूप में अच्छा implementation है, लेकिन दूसरे web admins अगर संभव हो तो इसके सारे तरीक़े ज्यों-का-त्यों न अपनाएँ
    • यह दिलचस्प है कि मैं भी access नहीं कर पाया, लेकिन archive.ph crawler आराम से निकल गया

  • response body में सिर्फ 410 और Sec-Fetch-Mode: string दिख रही है, इससे लगता है कि मुझे bot समझा गया। पढ़ने या देखने के लिए कुछ नहीं है, इसलिए बस निकल जाना पड़ता है; modern web भयानक है

    • असली browser वह header भेजते हैं, लेकिन कुछ reader apps और Chrome Headless का इस्तेमाल न करने वाले ज़्यादातर bots इसे नहीं भेजते
      support status https://caniuse.com/?search=sec-fetch-mode पर, और कुछ headers https://nochan.net/.env पर देखे जा सकते हैं
    • मैं वहाँ तक भी नहीं पहुँच पाया; TLS handshake भी पार नहीं हो सकी और PR_END_OF_FILE_ERROR आया

  • मुझे लगता है कि web traffic का 99% से ज़्यादा bot या agent होगा, इसलिए visitor count दिखाना बंद कर दूँ क्या, इस पर सोच रहा हूँ। यह संख्या अर्थहीन है और site को वास्तविकता से कहीं ज़्यादा व्यस्त दिखाती है, लेकिन कहीं ऐसा न हो कि असली लोग लेख पढ़ ही न सकें या किताबें डाउनलोड न कर पाएँ, इसलिए कदम उठाने में हिचक रहा हूँ

    • techno-thriller, SF और mystery novels—इन्हें बाद में देखना चाहूँगा

  • अगर blocking ज़रूरी हो, तो आम तौर पर allowlist denylist से ज़्यादा प्रभावी होती है, और अगर allowlist लागू नहीं की जा सकती, तो यह तरीका भी शायद अच्छा समाधान नहीं है
    Cloudflare और Anubis जैसे tools गंभीर accessibility समस्याएँ पैदा कर सकते हैं, इसलिए मैं request rate limiting को प्राथमिकता देता हूँ। यह accessibility को नुकसान पहुँचाए बिना साफ़-सुथरा रहता है, और अस्थायी समस्याओं के लिए छोटी IP blocking भी अच्छा काम करती है
    निजी तौर पर मैं fail2ban से HTTP logs का विश्लेषण करता हूँ और robots.txt में मना किए गए URL, wp-login.php जैसे path, या बहुत बार request rate limit पार करने वाले IP को N घंटों के लिए ब्लॉक कर देता हूँ। अभी Git web UI में Anubis का परीक्षण कर रहा हूँ

    • B2B संचार में मैंने network-to-network VPN के ज़रिए allowlist लागू की थी। VPN के बाहर से server तक पहुँचा ही नहीं जा सकता, और कर्मचारी company VPN के ज़रिए access कर सकते हैं

  • सिर्फ fail2ban से भी काफ़ी अच्छी रोकथाम हो सकती है, लेकिन शुरुआती कुछ महीनों में environment के अनुसार बारीक tuning करनी पड़ती है
    पहले मैंने failregex = ^ - \\S+ \\[\\] ".*?" 40[034] filter से detection शुरू किया, फिर उसे और specific lists में जोड़ा; अब लगभग 80 regex के साथ सारा traffic ब्लॉक हो जाता है और सामान्य 40[034] filter तक पहुँचने वाली request काफ़ी समय से नहीं आई
    लेकिन load balancer या proxy के पीछे होने पर असली IP पाने का तरीका चाहिए, जिससे fail2ban और मूल पोस्ट वाला तरीका दोनों झंझट वाले हो जाते हैं

    • ज़्यादातर layer 7 load balancers असली IP वाला header जोड़ने की सुविधा देते हैं। बस web server को उस header को log करने के लिए configure करना होता है, और यह CDN के real IP forward करने के तरीके से बहुत मिलता-जुलता है

  • इन टिप्पणियों और मेरे access प्रयास को देखकर लगता है कि bots ही नहीं बल्कि सारा सामान्य traffic भी ब्लॉक हो रहा है

    • सिर्फ टिप्पणियाँ देखकर ग़लतफ़हमी हो सकती है। अब तक लगभग 2,600 लोग और कुछ bots इस लेख को देख पाए हैं
      रविवार को web browse करते समय लोग सबसे ज़्यादा अजीब browser और apps इस्तेमाल करते दिखते हैं, और weekdays में सामान्य mainstream browser ज़्यादा होते हैं, इसलिए यह अच्छी testing बन जाती है