- अत्यधिक AI scraping bot requests के कारण एक निजी सर्वर डाउन हो गया
- लॉग विश्लेषण में Alibaba(US) Technology के सिंगापुर-होस्टेड IP range (
47.79.*) से केंद्रित access attempts की पुष्टि हुई
Mozilla/5.0 जैसे spoofed User-Agent के कारण सामान्य bot detection systems निष्प्रभावी हो गए- Fail2ban और Nginx की automatic blocking systems पर इतना लोड पड़ा कि पूरे IP range को मैन्युअली block करना पड़ा
- बार-बार के हमलों से निजी सर्वर चलाने वालों के लिए self-hosting environment पर दबाव बढ़ रहा है, और वे केंद्रीकृत platforms की ओर धकेले जा रहे हैं
सर्वर डाउन होने का कारण और शुरुआती प्रतिक्रिया
- कुछ दिन पहले साइट होस्ट कर रहा छोटा सर्वर scraping bot attack की वजह से अस्थायी रूप से बंद हो गया
- पहले भी ऐसे हमले हो चुके थे, और Anubis जैसे मजबूत defense tool को अपनाने पर विचार किया जा रहा है
- बार-बार के हमलों के कारण व्यक्तिगत डेवलपर का रचनात्मक उत्साह और शौकिया आनंद कम हो रहा है
- सर्वर access में देरी के बाद
top कमांड से जांच करने पर पता चला कि Gitea और Fail2ban लगभग पूरा CPU इस्तेमाल कर रहे थे
- Gitea process बंद करने के बाद भी Fail2ban का लोड कम नहीं हुआ, और Nginx access log अनियंत्रित रूप से बढ़ चुका था
लॉग विश्लेषण और हमले का पैटर्न
- लॉग में
/commit/ path को निशाना बनाकर कई HTTP 502 requests दर्ज हुईं
- request headers में
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) जैसे सामान्य browser के रूप में छिपे User-Agent इस्तेमाल किए गए
- अधिकांश User-Agent inspection tools ने इन्हें सामान्य traffic समझ लिया, जिससे detection evasion संभव हुई
- attack IPs एक ही source से नहीं बल्कि कई addresses से आए, लेकिन सभी में
47.79.* range समान थी
ipinfo.io lookup के अनुसार यह range Alibaba(US) Technology Co., Ltd. के स्वामित्व में है- PhpBB forum सहित अन्य जगहों पर भी इसी IP range से जुड़े हमलों की रिपोर्ट मिलती है
बचाव के उपाय और उनकी सीमाएँ
- Fail2ban ने Nginx logs का real-time analysis करके block rules लागू किए, लेकिन logs की बाढ़ से processing में देरी हुई
/commit/ access attempt करने वाले IPs को तुरंत block करने के लिए script चलाई गई, लेकिन speed limitation बनी रही- अंत में
iptables कमांड के जरिए 47.79.0.0/16 पूरे range को मैन्युअली block करना पड़ा
- ऐसी प्रतिक्रिया सिर्फ अस्थायी उपाय है, और नए IP ranges से हमले जारी रह सकते हैं
- Cloudflare जैसी external protection services या Anubis जैसी उन्नत defense systems अपनाने पर विचार चल रहा है
- लेकिन tracking features वाले US servers के जरिए routing नहीं चाहिए, इसलिए इसे अपनाने में हिचक है
निजी सर्वर चलाने की कठिनाइयाँ
- Gitea instance को Codeberg पर migrate करने की संभावना पर विचार हो रहा है
- बार-बार के हमलों के कारण निजी सर्वर ऑपरेटर self-hosting छोड़कर केंद्रीकृत platforms की ओर जा रहे हैं
- यह प्रवृत्ति इंटरनेट की decentralization और autonomy को कमजोर करती है
- अन्य bloggers ने भी ऐसे हमलों से नुकसान की बात कही है, और यह छोटे वेब ऑपरेटरों की व्यापक समस्या बनती जा रही है
अन्य देखी गई असामान्य ट्रैफिक गतिविधि
bioware.com, mcdonalds.com, microsoft.com जैसे बड़ी कंपनियों के domains को refer करने वाले spoofed Referer headers भी मिले
- वास्तव में उन sites ने कोई link नहीं दिया था, फिर भी अस्पष्ट उद्देश्य वाला traffic spike देखा गया
- हमले दोहराए जाने के बावजूद self-hosting न छोड़ने की प्रतिबद्धता जताई गई
- लेख के अंत में “Get Hostin’ Or Die Tryin’” वाक्य के साथ स्वायत्त सर्वर संचालन जारी रखने की इच्छा पर ज़ोर दिया गया
1 टिप्पणियां
Hacker News राय
अब ऐसा लगता है कि इंटरनेट सॉफ्टवेयर शौकिया डेवलपर्स के लिए सुरक्षित जगह नहीं रहा
मैं लगभग 2005 से अपने सर्वर खुद चला रहा हूँ, और सर्वर ऑनलाइन होते ही उस पर हमेशा हमले शुरू हो जाते थे
खासकर जब DNS नाम जोड़ते हैं या TLS certificate इस्तेमाल करते हैं, तो certificate transparency logs में दिखने की वजह से हमले और बढ़ जाते हैं
वेबसाइट सार्वजनिक करते ही malicious traffic की बाढ़ आ जाती है, और अगर किसी खास संगठन को नाराज़ कर दें तो लगता है वे किसी को DDoS कराने के लिए रख लेते हैं
crawlers, botnets, automated attacks, और गुस्साए लोग — यह सब हर साल झेलना पड़ता है
कई hosting providers आज़माए, लेकिन नतीजा लगभग एक जैसा ही रहा
WordPress अपडेट नहीं किया तो कुछ घंटों में SEO spam से संक्रमित हो गया, और Redis गलती से बाहर खुला रह गया तो botnet RAT इंस्टॉल हो गया
लेकिन मुझे नहीं लगता कि इन बातों का मतलब यह है कि इंटरनेट ‘खतरनाक’ है
बल्कि ये ऐसे अनुभव थे जिन्होंने मुझे सिखाया कि मुझे क्या सीखना चाहिए
उसके बाद मैंने certificate logs में न दिखने के लिए star-cert इस्तेमाल किया, basic auth जोड़ा, backups बनाए रखे, और ज़्यादा सावधानी से ऑपरेट करना शुरू किया
असली खतरा मुझे यह लगता है कि तकनीक न जानने वाले लोग कोई भी exe इंस्टॉल कर लेते हैं, और Facebook या TikTok को अपनी सारी जानकारी सौंप देते हैं
ज़्यादातर requests WordPress vulnerabilities को निशाना बनाती हैं, जबकि मैंने कभी WordPress इस्तेमाल ही नहीं किया
पहली बार logs देखे तो झटका लगा था, लेकिन अब इसे रोज़मर्रा की बात मान लिया है
उदाहरण: https://www.masswerk.at/wp-admin
वह समय था जब IP ranges scan करने और vulnerabilities अपने आप ढूँढने वाले tools फैल रहे थे
1995~2008 के बीच का वेब याद आता है, जब Web Rings, Technorati, और fan sites हुआ करते थे
संदर्भ: Script Kiddie wiki
पहले मैंने zipbomb का इस्तेमाल करके bots को रोका था, और वह असरदार था
लेकिन HN पर उसके बारे में पोस्ट करने के बाद, नए bots का झुंड आ गया और $6 वाला सर्वर उसे संभाल नहीं पाया
हर दिन 1 लाख requests पर 1~10MB payload देना संभव नहीं था
बाद में मैंने सिर्फ कुछ खास bots को target किया, honeypot बनाया, IPs इकट्ठे किए, और 403 response देना शुरू किया
कुछ महीनों बाद traffic फिर सामान्य स्तर पर लौट आया
लेकिन target customer कौन होगा, यह पता नहीं। ज़्यादातर self-hosting users के पास बहुत पैसा नहीं होता
मेरा cgit server भी पिछले 1 साल से लगातार scrapers की पहुँच में है
हालाँकि यह प्रति मिनट 2~3 requests ही करता है, इसलिए काफ़ी ‘सभ्य’ bot है
मज़ेदार बात यह है कि मैंने जो code डाला है वह सब upstream से सीधे clone किया जा सकता है, फिर भी यह यूँ scrape करता रहता है
logs देखें तो यह सचमुच बहुत अक्षम automation है
अगर Nginx की rate-limiting feature खुद configure कर लें, तो Fail2ban से भी आसान हल मिल सकता है
संदर्भ ब्लॉग: https://blog.nginx.org/blog/rate-limiting-nginx
ब्लॉग जैसी public services पर इसे लागू करना मुश्किल है, लेकिन अगर यह private self-hosting है तो reverse proxy पर mTLS authentication लगाने की सलाह दूँगा
certificate के बिना आने वाली requests तुरंत block हो जाती हैं, और सिर्फ मेरे devices ही access कर पाते हैं
एक बार सेटअप हो जाए तो बाद में लगभग कोई झंझट नहीं रहता
इसकी setup आसान है और Android, iOS पर भी अच्छी तरह काम करती है
अब मैंने अपनी सारी self-hosted services को सिर्फ Wireguard VPN के अंदर से ही access होने लायक बनाया है, और firewall में सिर्फ Wireguard port खुला छोड़ा है
Anubis bots के साथ इस ‘cat-and-mouse’ game को अच्छी तरह खेल रहा है
लेकिन Cloudflare जैसी जगहें, जिनके पास बड़े पैमाने का traffic data है, वही IP reputation आधारित blocking ठीक से कर पाती हैं
छोटे operators को अक्सर पूरे IP ranges block करने पड़ते हैं, जो अक्षम तरीका है
Crowdsec जैसी कोई solution चाहिए, जो reputation data साझा करे, malicious IPs को block करे, और JS के बिना simple challenge दे
अगर ऐसा तरीका संभव हो जाए, तो hobby developers के लिए फिर से services चलाना आसान हो सकता है
मेरे Gitea instance पर भी हाल ही में distributed IPs और ASN के ज़रिए scraping हुई है
अगर सामने पैसे वाले AI कंपनियाँ हों, तो शायद Anubis से भी रोकना मुश्किल होगा
इसलिए मैं ‘scraper poisoning’ पर विचार कर रहा हूँ — यानी code की जगह कचरा data देना
ऐसी services scraping को और मुश्किल बना देती हैं
जो चीज़ लोकप्रिय हो जाती है, वह आखिरकार जनता के हाथ लगकर बिगड़ने वाले चक्र से गुज़रती है
इसलिए ऐसा लगता है कि बस लगातार नए इलाकों की ओर बढ़ते रहना ही एकमात्र हल है
Cloudflare पर DNS ले जाने के बाद अजीब SYN packets लगातार आने लगे
443 या 22 port पर हर सेकंड requests आती हैं, लेकिन SYN-ACK के बाद कोई response नहीं मिलता
ज़्यादातर यह ब्राज़ील वगैरह के VPS game server hosting providers से आते हुए लगते हैं
इसलिए मैं SYN packets capture करके RDAP से lookup करता हूँ, और उन संगठनों के पूरे subnets block कर देता हूँ
सिर्फ Google को whitelist में रखा है
Digital Ocean malicious traffic के बड़े स्रोतों में से एक लगता है
network stack retry करता रहता है, जिससे victim तक amplified traffic पहुँचता है
अक्सर src IP spoof किया जाता है, इसलिए
rp_filterको strict पर सेट करने की सलाह हैजैसे बिजली कंपनी लाल बल्ब के इस्तेमाल पर रोक नहीं लगाती, वैसे ही service providers द्वारा traffic को नियंत्रित करना उचित नहीं है
मुझे यह लेख इसलिए अच्छा लगा क्योंकि इंटरनेट सुरक्षित है इसलिए नहीं, बल्कि इसलिए कि इसने इस वास्तविकता को दर्ज किया
मैं भी Alibaba /16 और AWS के पूरे ranges block कर रहा हूँ
मैं रोज़ cron से RouteViews data लेकर उसे iptables पर लागू करने वाली script इस्तेमाल करता हूँ
उदाहरण code:
उम्मीद है दूसरे cloud providers भी ऐसा ही करें