बॉट्स को रोकने के लिए छोटे-छोटे टूल्स की पूरी फौज लगाना

• निजी सर्वर पर चल रहे Gitea और ब्लॉग पर scraping ट्रैफिक का इतना दबाव पड़ा कि डिस्क·CPU·मेमोरी चेतावनियां लगातार आने लगीं, और ऑपरेटर ने लॉग विश्लेषण·Nginx·Fail2Ban को मिलाकर बचाव शुरू किया
• Zabbix के अनुसार ट्रैफिक सामान्य से काफी ऊपर चला गया; Nginx का मासिक औसत 8 requests per second था, जबकि सबसे खराब समय में यह 20+ requests per second तक पहुंच गया
• वजह Reddit या Hacker News जैसी किसी एकल referral spike नहीं थी, बल्कि कई IP ब्लॉक्स द्वारा www.lambdacreate.com और krei.lambdacreate.com के URLs को scrape करने वाली distributed scraping के ज्यादा करीब थी
• Nginx ने ज्ञात malicious user agents को 403 लौटाया और प्रति-IP request limits लागू कीं; जो clients जरूरत से ज्यादा 403 ट्रिगर कर रहे थे, उन्हें Fail2Ban से 24 घंटे के लिए block किया गया
• लेखन के समय block list कुल 735 bans तक पहुंच चुकी थी, और खास तौर पर Gitea के public repositories में हर commit के लिए tarball बनाने की कोशिश ने सर्वर पर बोझ बढ़ा दिया

---

scraping ट्रैफिक ने निजी सर्वर पर दबाव डाला

• निजी इंटरनेट स्पेस पर अचानक अनचाहा bot ट्रैफिक उमड़ पड़ा, जिससे उन सेवाओं पर भी असर पड़ा जिन तक असली पाठकों को पहुंचना चाहिए था
• Archive.org जैसी साइट संरक्षण के लिए index करने वाली सेवाएं स्वीकार्य हैं, लेकिन Amazon, Facebook, OpenAI और तरह-तरह के random bots को ऐसे उपभोक्ता के रूप में देखा गया जो कंटेंट को अपने उद्देश्यों के लिए खपत करते हैं
• माना गया कि बड़ी कंपनियों द्वारा इंटरनेट से बड़े पैमाने पर डेटा संग्रह और AI model training data की मांग ने scraping pressure को और बढ़ाया है
• यह ट्रैफिक Lambdacreate के वास्तविक उपभोक्ता नहीं थे, बल्कि मानव पाठकों की accessibility घटाने वाला व्यवधान माना गया

Zabbix ने सबसे पहले असामान्य संकेत पकड़े

• समस्या की पहली सूचना Zabbix ने दी, जब container disk भर जाने की चेतावनी आई
• LXD-आधारित environment में ZFS sparse file को बढ़ाकर साइट को थोड़ी देर नीचे ले जाकर फिर ऊपर किया गया, लेकिन मूल कारण बना रहा
• इसके बाद Gitea instance हर दिन पूरी disk खपा रहा था और प्रतिदिन 20~30GB डेटा बना रहा था
• शुरुआत में इसे इस रूप में देखा गया कि Gitea repository archives की cleanup को default रूप से enabled नहीं करता, इसलिए आक्रामक cleanup jobs सेट की गईं
• जल्द ही CPU और memory warnings भी आने लगीं, Gitea में git pull·git push मुश्किल हो गया, और weechat client भी connection बनाए नहीं रख सका

सामान्य से 10 गुना तक बढ़ा request volume

• पुराने metrics और मौजूदा स्थिति की तुलना करने के लिए out-of-band monitoring मौजूद थी, जिससे abnormal patterns की पुष्टि हो सकी
• Zabbix dashboard में मुख्य metrics Nginx request count और network throughput graphs थे
• एक महीने के आधार पर Nginx requests का औसत 8 requests per second था
• सबसे खराब समय में 20+ requests per second आए; बड़े services के हिसाब से यह छोटा लग सकता है, लेकिन निजी सर्वर के लिए यह सामान्य का 10 गुना था, इसलिए असर बड़ा था
• सिर्फ request volume ही नहीं, Gitea से जुड़े disk और CPU usage में बढ़ोतरी भी साथ दिखी, जिससे server संचालन का बोझ बढ़ गया

lnav और goaccess से logs की जांच

• server को इतना देर तक जिंदा रखने के लिए कि logs देखे जा सकें, containers और Nginx को थोड़ी देर बंद कर विश्लेषण शुरू किया गया
• इस्तेमाल किए गए tools थे lnav और goaccess
• lnav logs को रंगीन TUI में दिखाता है और सामान्य log formats के ऊपर abstraction layer देता है, जिससे SQL queries के जरिए logs को query किया जा सकता है
• access.log में जांच का फोकस इन सवालों पर था
  • कुल visitor IP कितने हैं
  • क्या IP address patterns हैं
  • क्या ट्रैफिक किसी खास referrer से आ रहा है
  • कौन से user agents इस्तेमाल हो रहे हैं
  • कौन सा IP किस user agent से जुड़ा है
• विश्लेषण से पता चला कि यह किसी एक referrer से आया “hug of death” नहीं था, बल्कि कई IP blocks पूरी साइट के URLs scrape कर रहे थे

user agent आधारित 403 और request limiting

• पहली प्रतिक्रिया Nginx में समस्या पैदा करने वाले user agents की सूची बनाकर 403 लौटाने की थी
• उदाहरण config में map $http_user_agent $badagent का उपयोग कर AdsBot-Google, Amazonbot, Amazonbot/0.1 जैसे agents को चिह्नित किया गया
• base Nginx config में user agent rules को include किया गया और प्रति-IP rate limit भी सेट की गई
• virtual host config में ये व्यवहार शामिल थे
  • limit_req zone=krei burst=20 nodelay; से request limiting लागू करना
  • अगर $badagent true हो तो return 403; से content access रोकना
• यह तरीका backend processing घटाने में मदद करता है, लेकिन server को HTTP requests स्वीकार कर 403 process करना ही पड़ता है, इसलिए भारी concurrent requests में बोझ फिर भी बना रहता है

Fail2Ban से firewall blocks का automation

• 403 logs जमा होने के बाद lnav से 403 पाने वाले unique IPs देखे जा सकते हैं
• goaccess का उपयोग पुराने और वर्तमान logs को साथ में analyze कर server में आई requests की संख्या और सबसे ज्यादा target किए गए endpoints देखने के लिए किया गया
• server की वास्तविक सुरक्षा के लिए Fail2Ban जोड़ा गया
• Fail2Ban rule सरल था: Nginx access log में जरूरत से ज्यादा 403 responses पैदा करने वाले IPs को पकड़ना
• block duration 86400 seconds, यानी 24 घंटे, सेट की गई
• लेखन के समय fail2ban-client status nginx-forbidden का परिणाम इस प्रकार था
  • वर्तमान failures: 13
  • कुल failures: 57135
  • वर्तमान blocks: 38
  • कुल blocks: 735

असली निशाना ब्लॉग नहीं, Gitea tarball generation था

• अंततः पाठक फिर से ब्लॉग और Lambdacreate की अन्य सेवाओं तक पहुंच सके
• जब bot ट्रैफिक को रोकना पड़ रहा हो, तो ब्लॉग पोस्ट लिखना भी मुश्किल हो जाता है
• समस्या पैदा करने वाला ट्रैफिक ब्लॉग scraping नहीं, बल्कि Gitea instance के हर public repository में सभी commits के लिए tarball generation को निशाना बना रहा था
• लंबे समय में block list बढ़ाने या Archive.org जैसी वैध सेवाओं के लिए exceptions रखने पर विचार किया जाएगा
• रुख यह है कि वे नहीं चाहते कि content search engines से गायब हो जाए, लेकिन इसे इंटरनेट की AI-चालित गिरावट के लिए ईंधन भी नहीं बनने देना चाहते