AWS bot को एक महीने में 2 अरब requests भेजने से कैसे रोका जा सकता है?

• AWS infrastructure में अप्रत्याशित बड़ी मात्रा में web requests की समस्या सामने आई
• एक महीने में 20 करोड़ से 2 अरब तक तेज़ी से बढ़े traffic pattern की रिपोर्ट मिली
• log analysis के नतीजों में एक खास User-Agent से बार-बार requests आने की पुष्टि हुई
• AWS support team से संपर्क किया गया, लेकिन स्पष्ट समाधान नहीं मिला
• firewall rules सेट करना, User-Agent को block करना आदि जैसे कई blocking methods पर विचार करने की ज़रूरत सामने आई

---

समस्या का परिचय

• एक AWS user ने web server पर एक महीने के दौरान 2B (2 अरब) requests आने की घटना पर सवाल उठाया
• ये requests एक खास User-Agent इस्तेमाल करने वाले bot से आ रही थीं, और सामान्य usage pattern से मेल न खाने वाला असामान्य traffic थीं
• traffic में यह अचानक बढ़ोतरी cost बढ़ने और system load की समस्या पैदा करने का जोखिम रखती है

कारण विश्लेषण

• भारी संख्या में requests का अधिकांश हिस्सा संदिग्ध AWS IP range से आया
• access records के ज़रिए यह समझा गया कि एक खास bot या script इसकी वजह है
• User-Agent में एक समान pattern मौजूद था, इसलिए filtering संभव है

मौजूदा प्रतिक्रिया और सीमाएँ

• AWS support team से संपर्क किया गया, लेकिन कोई निर्णायक उपाय नहीं मिला
• इस तरह की बड़ी संख्या में requests से service disruption और cost burden बढ़ने की आशंका है

समाधान की दिशा और विचारणीय बिंदु

• firewall rules जोड़ना, User-Agent आधारित traffic block करना, IP blacklist लागू करना जैसी कई blocking policies की ज़रूरत पर विचार किया गया
• लंबी अवधि में traffic monitoring system को मजबूत करना, असामान्य access detection और automatic blocking framework की आवश्यकता उभरकर सामने आई

[GN⁺]

Hacker News की राय

• 30x redirect आज़माने का अनुभव है, जैसे 301 response देकर उन कंपनियों द्वारा होस्ट की गई बहुत बड़ी files की ओर भेजना जिन्हें मैं पसंद नहीं करता; अगर उस कंपनी की AWS instances एक साथ 70,000 Windows ISO डाउनलोड करने लगें तो वे ज़रूर नोटिस करेंगे। साथ ही, Cloudflare पर यह आसान नहीं है, लेकिन तथाकथित ‘tar pit’ strategy भी इस्तेमाल की जा सकती है: request मिलने के बाद response को एक-एक character करके, हर character के बीच 30 सेकंड की देरी से भेजना। अगर हर request पर 10KB header/response के साथ प्रति सेकंड 700 requests आएँ, तो server बेहद धीमा दिखेगा
  • अगर 301 redirect के target के लिए कोई खास कंपनी पसंद न हो, तो Amazon जैसी जगह चुनने की सलाह है
  • request लेकर एक-एक character बहुत धीरे भेजने वाली strategy, Slow Loris DDoS attack के ठीक उलट लगती है। Slow Loris attack का विवरण Cloudflare पर देखा जा सकता है, यानी हमला slow connection से करने के बजाय defender side slow connection से जवाब दे रही है
  • विकल्प के तौर पर .sg official government site पर 301 redirect करके local law enforcement से मामला handle करवाने का विचार भी हो सकता है
  • यह भी बताया गया कि AWS पर inbound traffic free होता है, इसलिए instance owner बहुत ज्यादा data receive करे तब भी AWS उससे अतिरिक्त शुल्क नहीं लेता
• साफ़ तौर पर malicious bot चलाने को operational cost के लिहाज़ से महँगा बनाना भी एक तरीका है, खासकर gzip bomb जैसी techniques bot के vulnerable होने पर असरदार होती हैं। लेकिन केवल response से पहले लगभग 10 सेकंड रुकने से भी server पर लगभग 7,000 ports consume करवाए जा सकते हैं, और ज़्यादातर Linux processes इसे सह नहीं पाते और crash हो जाते हैं। इसे nginx + mod-http-echo से आसानी से implement किया जा सकता है
  • वास्तव में कुछ लोगों ने यह strategy पहले से implement की हुई है; open source code की user agent list से यह दिखता है, और implementation खुद भी बहुत सरल है। संबंधित source यहाँ देखा जा सकता है
  • AWS customers को outbound traffic के लिए पैसे देने पड़ते हैं, लेकिन उल्टा AWS या Cloudflare की तरफ़ से हमारे पास बड़े पैमाने पर traffic भेजने का कोई तरीका है या नहीं, यह भी जानना चाहा गया
  • ऐसा ही अनुभव हुआ था: हमारी site की pricing जानकारी scrape करने की कोशिश में malicious scraping बार-बार हुआ। catalog में लाखों products थे और dynamic pricing calculate करने में बहुत resources लगते थे। अचानक request flood आने पर infrastructure लगभग जवाब दे गया था। defense के तौर पर spam traffic को tags से अलग करके cache करने की कोशिश की गई ताकि असली customers पर असर न पड़े, और साथ ही pricing में random error values डालकर data को बेकार बनाने का विचार भी हुआ। आखिरकार Cloudflare के साथ मिलकर malicious requests को जल्दी block करने पर टिके, लेकिन इसमें समय और लागत दोनों लगे। attacker शायद किसी competitor की outsourced service थी, जबकि officially API देना संभव था; फिर भी सीधे संपर्क न करना खलता रहा। पहले ऐसे मामलों में माहौल यह था कि "अगर traffic नहीं झेल सकते तो site की गलती है", लेकिन अब सोच काफी बदलती लगती है
  • क्या ऐसा करने पर मेरे server पर भी 7,000 ports consume नहीं होंगे, यह पूछा गया
  • यह भी पूछा गया कि इस technique से क्या मेरे server पर भी उतनी ही connections नहीं बनेंगी
• Anubis का main author हूँ। अनुभव रहा कि अगर Cloudflare को HTTP 200 response return करने के लिए set कर दिया जाए, तो bot 200 मिलने तक मारना बंद कर देता है
  • वैसे अभी main site पर शायद कोई issue है
  • application layer पर detect होते ही connection को ज़बरदस्ती काट देने का तरीका भी इस्तेमाल किया है; Cloudflare side settings मुश्किल हों तो यह primitive bots पर काम करता दिखता है
• पहले अपने personal blog पर ऐसी ही स्थिति झेली थी। शायद 7–8 साल पहले अचानक traffic बहुत बढ़ गया; पहले लगा viral हो गया, लेकिन pattern इतना mechanical था कि अजीब लगा। कारण खोजने पर पता चला कि किसी का bot/crawler test के तौर पर मेरी site scrape कर रहा था। कई महीनों तक विनम्रता से कई बार रुकने को कहा, कोई असर नहीं हुआ। आख़िर में redirect करके उस bot को random porn sites पर भेज दिया, तब crawling रुक गई
  • यह तरीका practically सबसे बढ़िया है: crawler को ऐसी जगह redirect करो जिसे वह logs में नहीं देखना चाहे, या फिर उसी की तरफ़, उसके provider की तरफ़, या किसी unwanted content की तरफ़ मोड़ दो
• 200 response की body में EICAR test string शामिल करके data contamination करवाना भी काफ़ी संतोषजनक बदले का तरीका है। EICAR test file का विवरण देखें
  • SSRF attack के उलट concept के रूप में bot को cloud metadata API पर redirect करके <shutdown> जैसे endpoint call करवाने का विचार भी मज़ेदार लग सकता है। redirect response में EICAR test string भी डाल दी जाए तो automated security detection systems भी trigger हो सकते हैं
• अगर AWS Singapore से legitimate traffic लेने की कोई ज़रूरत ही नहीं है, तो उस पूरे range को blackhole करना भी एक विकल्प है
  • WAF का इस्तेमाल करके उन packets को सीधे drop किया जा सकता है। Cloudflare WAF का "block" feature इसी काम आता है
  • मैंने भी पहले ऐसा किया था: Byte Dance का Byte Spider bot लाखों images scrape कर रहा था। आखिर में Cloudinary से user-agent blocking की request भी की, और शुरुआत में पूरे Singapore को block भी किया था। AI scraping कंपनियों के bots को इतना malicious तरीके से चलते देख बहुत गुस्सा आया। Cloudinary जैसी अच्छी service की वजह से कुछ लागत बची, और अब Cloudflare से सभी AI bots को block करके मामला खत्म किया जाता है
  • जानकारी के लिए AWS के region-wise IP ranges यहाँ देखे जा सकते हैं
• 2018 में कुछ छोटे पैमाने पर ऐसा ही हुआ था। AWS official IP range json list पढ़कर Windows Firewall में उन ranges को block करने वाला tool खुद बनाया था। संबंधित blog post यहाँ देखी जा सकती है, और tool का readme यहाँ उपलब्ध है। सालों तक server पर scheduled task के रूप में ठीक चला, लेकिन आज भी काम करता है या नहीं, इसका भरोसा नहीं। दिलचस्पी हो तो code public करने या किसी और को सौंपने पर भी विचार किया जा सकता है। खुद implement करना भी बहुत कठिन नहीं होगा। शुभकामनाएँ
• Singapore का telecom regulator porn का simple possession भी प्रतिबंधित करता है, इसलिए malicious bot को जवाब में softcore content भेजने और साथ ही authority व AWS को email complaint करने की strategy सुझाई गई
  • अगर कोई बार-बार internet पर नुकसान पहुँचा रहा हो, तो उसके देश के कानून का इस्तेमाल करके जवाब देना सबसे असरदार होता है। बाकी agencies से आम तौर पर किसी कार्रवाई की उम्मीद नहीं की जा सकती
• अगर Cloudflare को बता दिया जाए कि यह traffic malicious है, तो वे account के बाहर से ही block कर सकते हैं, जिससे मेरी तरफ़ traffic accounting पर बोझ नहीं पड़ेगा
• ऐसा ही अनुभव हुआ था: 80MB का software installer बहुत बड़ी मात्रा में request किया जा रहा था। offending requests को please-stop.txt नाम की file पर redirect किया, और उस file में समस्या समझाकर रुकने की विनती लिखी; सचमुच वे रुक गए