अब तक का सबसे बड़ा DDoS हमला, अधिकतम 39.8 करोड़ rps तक पहुँचा

 (cloud.google.com)
1 पॉइंट द्वारा GN⁺ 2023-10-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DDoS हमलों का पैमाना तेज़ी से बढ़ रहा है। इसी बीच Google ने अगस्त 2023 में अधिकतम 39.8 करोड़ rps वाले हमले को निष्प्रभावी किया, जो पिछले वर्ष के 46 million rps रिकॉर्ड से 7.5 गुना बड़ा था
  • हमलावरों ने HTTP/2 की stream multiplexing का दुरुपयोग करने वाली Rapid Reset तकनीक का इस्तेमाल किया, जिससे कई internet infrastructure कंपनियाँ प्रभावित हुईं
  • हमलों की यह लहर अगस्त 2023 के अंत में शुरू हुई और सितंबर तक जारी रही। Google services, Google Cloud infrastructure और ग्राहकों सहित प्रमुख infrastructure providers इसके निशाने पर थे
  • Google ने network edge पर हमले को absorb किया और अपने defense systems को update किया। Application Load Balancer और Cloud Armor ग्राहकों को भी इसी आधारभूत सुरक्षा का लाभ मिला
  • HTTP/2 को support करने वाले server, proxy, application server और load balancer CVE-2023-44487 से प्रभावित हो सकते हैं, इसलिए vulnerability की जाँच और vendor patch लागू करना ज़रूरी है

हमले का पैमाना और Rapid Reset तकनीक

  • Google की DDoS Response Team ने पुष्टि की कि पिछले कुछ वर्षों में DDoS हमलों का पैमाना घातांकीय रूप से बढ़ रहा है
  • अगस्त 2023 में रोका गया हमला पिछले वर्ष के सबसे बड़े रिकॉर्ड से 7.5 गुना बड़ा था
    • यह अधिकतम 398 million requests per second(rps) तक पहुँचा
    • 2022 में दर्ज सबसे बड़ा DDoS हमला 46 million rps था
  • 2 मिनट तक चले इस हमले ने Wikipedia द्वारा सितंबर 2023 के पूरे महीने में रिपोर्ट किए गए कुल page views से भी अधिक requests पैदा कीं
  • इसकी मुख्य तकनीक HTTP/2 की stream multiplexing क्षमता का उपयोग करने वाला नया HTTP/2 Rapid Reset था

निशाने और services पर प्रभाव

  • हालिया हमलों की लहर अगस्त 2023 के अंत में शुरू हुई और सितंबर भर देखी गई
  • हमलों के निशाने में प्रमुख infrastructure providers शामिल थे
    • Google services
    • Google Cloud infrastructure
    • Google ग्राहक
  • Google ने global load balancing और DDoS mitigation infrastructure के जरिए services को लगातार चालू रखा
  • industry partners के साथ सहयोग के माध्यम से हमले की कार्यप्रणाली समझी गई और Google, उसके ग्राहकों तथा व्यापक internet ecosystem की सुरक्षा के लिए mitigation उपाय समन्वित किए गए

Google की mitigation पद्धति और Cloud ग्राहकों की सुरक्षा

  • जाँच में पाया गया कि हमले में व्यापक रूप से इस्तेमाल होने वाले HTTP/2 protocol की stream multiplexing क्षमता का उपयोग करने वाली Rapid Reset तकनीक अपनाई गई थी
  • Google ने network edge पर हमले को mitigate किया
    • edge capacity में निवेश का उपयोग कर Google services और customer services को अधिकांशतः अप्रभावित रखा गया
    • हमले की पद्धति को और समझने के बाद mitigation उपाय विकसित किए गए
    • proxy और denial-of-service defense systems को update कर इस तकनीक का प्रभावी रूप से असर कम किया गया
  • Google Cloud का Application Load Balancer और Cloud Armor वही hardware और software infrastructure इस्तेमाल करते हैं, जिनका उपयोग Google अपनी internet-facing services देने के लिए करता है
  • इन services का उपयोग करने वाले Cloud ग्राहकों के internet-facing web apps और services को भी इसी तरह की सुरक्षा मिलती है

CVE-2023-44487 और industry की संयुक्त प्रतिक्रिया

  • Google ने अगस्त के शुरुआती हमलों का पता चलते ही अतिरिक्त mitigation strategy लागू की और HTTP/2 protocol stack को implement करने वाले cloud providers तथा software maintainers के साथ industry-wide coordinated response का समन्वय किया
  • हमले के दौरान attack intelligence और mitigation methods को real time में साझा किया गया
  • इस सहयोग से कई बड़े infrastructure providers द्वारा उपयोग किए जाने वाले patch और mitigation techniques सामने आए
  • नई attack method तथा कई सामान्य open source और commercial proxy, application server और load balancer की संभावित vulnerabilities को coordinated disclosure के तहत सार्वजनिक किया गया
  • इस हमले से जुड़ी सामूहिक vulnerability को CVE-2023-44487 के रूप में track किया जा रहा है
    • severity High है
    • CVSS score 7.5/10 है

कौन प्रभावित हो सकता है और क्या कार्रवाई ज़रूरी है

  • internet पर HTTP-आधारित workloads उपलब्ध कराने वाले enterprise या individual इस हमले के जोखिम में हो सकते हैं
  • HTTP/2 पर संचार करने वाले server या proxy के ऊपर चलने वाले web application, service और API vulnerable हो सकते हैं
  • संगठनों को यह जाँचना चाहिए कि HTTP/2 को support करने वाले उनके server vulnerable तो नहीं हैं
  • यदि आप स्वयं HTTP/2-supporting server चलाते या manage करते हैं, तो open source या commercial होने की परवाह किए बिना संबंधित vendor patch उपलब्ध होते ही लागू करना चाहिए
  • CVE-2023-44487 के लिए vendor patch इस attack vector के प्रभाव को सीमित करने का उपाय है

Google Cloud वातावरण के लिए सुरक्षा सिफारिशें

  • बड़े पैमाने के DDoS हमलों से बचाव कठिन है, और patch होने या न होने से अलग, medium से बड़े हमलों के दौरान services को चालू रखने के लिए पर्याप्त infrastructure investment की ज़रूरत होती है
  • Google Cloud पर services चलाने वाले संगठन Cross-Cloud Network की global-scale capacity investments का उपयोग करके applications को deliver और protect कर सकते हैं
  • जो Google Cloud ग्राहक अपनी services को global या regional Application Load Balancer के माध्यम से expose करते हैं, उन्हें Cloud Armor always-on DDoS protection की सुरक्षा मिलती है
    • CVE-2023-44487 जैसी vulnerabilities का दुरुपयोग करने वाले हमले तेज़ी से mitigate किए जाते हैं
  • भले ही Cloud Armor always-on DDoS protection Google network edge पर प्रति सेकंड सैकड़ों मिलियन requests का अधिकांश हिस्सा absorb कर सके, फिर भी प्रति सेकंड लाखों unwanted requests आगे निकल सकती हैं
  • Layer 7 हमलों से निपटने के लिए Cloud Armor की custom security policies, proactive rate limiting rules, और AI-आधारित Adaptive Protection deployment की सिफारिश की जाती है
  • मौजूदा DDoS हमलों की इस लहर पर तकनीकी जानकारी HTTP/2 Rapid Reset DDoS हमला विश्लेषण में देखी जा सकती है

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

1 टिप्पणियां

 
GN⁺ 2023-10-11
Hacker News की राय
  • इससे जुड़े चल रहे threads:
    The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987
    HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks - https://news.ycombinator.com/item?id=37830998
  • सोच रहा हूं कि ऐसे DDoS हमले चलाने की प्रेरणा किसके पास होती है। किसी enterprise cloud infrastructure के खिलाफ बड़ा पैसा और sophisticated attack development लगाने की वजह साफ़ नहीं दिखती, और जो जवाब सबसे ज्यादा तर्कसंगत लगता है वह कोई विदेशी सरकार है
    फिर भी अगर नतीजा सिर्फ इतना है कि अमेरिकी tech companies और customers को कुछ घंटों तक असुविधा हो, तो समझ नहीं आता कि यह बार-बार क्यों होता रहता है
    • मैं करीब 20 साल से DDoS defense कर रहा हूं; जवाब कभी-कभी state actors होते हैं, लेकिन अक्सर पूर्वी यूरोप के scammers भी होते हैं। वे bot communities में reputation पाने के लिए बड़े हमले करते हैं
      उस reputation के दम पर वे ऐसे कम साफ-सुथरे clients से पैसे लेते हैं जो अपने competitors पर हमला करवाना चाहते हैं; कभी वह client सरकार होती है, कभी कोई suspicious company। पिछले साल crypto companies के एक-दूसरे की websites पर हमले करने के बहुत मामले थे
      ऐसे काम करने वाले लोग तकनीकी रूप से काफी सक्षम होते हैं, लेकिन वे जहां रहते हैं या जिस माहौल में बड़े हुए हैं, उसकी वजह से उस skill से पैसा कमाने के मौके अक्सर कम होते हैं
    • मकसद प्रचार है। Google या Cloudflare पर हमला करो, उनके “अब तक का सबसे बड़ा हमला” वाला blog post डालने का इंतज़ार करो, फिर potential customers से कहो कि तुम्हारा botnet किसी से भी बड़ा हमला कर सकता है और सबूत के तौर पर वह post दिखाओ
    • अगर attacker कच्चा है तो मकसद hacking community में दिखावा और प्रतिष्ठा पाना है; यह highway overpass पर graffiti छोड़ने से अलग नहीं है
      अगर attacker advanced है तो वह अपनी capability और response test कर रहा है। Taliban पहले base के बाहर बच्चों को पटाखे फोड़ने के लिए पैसे देते थे ताकि defense tactics, techniques और procedures देख सकें, और इससे लोगों को गोलियों की आवाज़ के प्रति सुन्न करने का असर भी होता था
      सच में बेहतरीन दुश्मन बाद वाला काम करते हुए खुद को पहले जैसा दिखाना जानता है
    • यह पुरानी जानकारी है, लेकिन botnet owner को कुछ सौ डॉलर देकर आप जिस व्यक्ति को नापसंद करते हैं उसके server को disrupt कर सकते थे। जैसे किसी competitive gaming clan का match खराब करना। दुनिया में ऐसी छोटी-मोटी हरकतें हैरान करने वाली मात्रा में होती हैं
      Mirai botnet के मामले में इसके कुछ creators DDoS mitigation company भी चलाते थे। यानी एक तरफ वे हथियार बेच रहे थे, दूसरी तरफ उसी हथियार से बचाव बेच रहे थे
      कभी-कभी motivation reputation, prank, या botnet बनाने की challenge ही होती है
    • हाल के इसी तरह के बड़े पैमाने के हमलों में botnet software लिखने वाले लोग एक अमेरिकी security company से थे जो DDoS mitigation solutions बेचती थी (https://en.wikipedia.org/wiki/Mirai_(malware))
  • मेरी पुरानी company पर इससे काफी छोटे scale के हमले बहुत बार होते थे। internally हम मानते थे कि कोई competitor हमें disrupt करने की कोशिश कर रहा है, लेकिन आखिरकार यह mystery ही रह गया
    चाहे बात internet infrastructure scale की हो या किसी खास company को target करने की, सोचता हूं क्या कोई ऐसा व्यक्ति, जो ऐसे हमलों में शामिल रहा हो, इतना बहादुर या पागल होगा कि temporary account बनाकर motivation बता दे
    • हमारे साथ भी ऐसा ही हुआ था, और पहले लगा कि script kiddies मज़े के लिए कर रहे हैं। बाद में पता चला कि किसी ने बेहद खराब microservice लिखी थी, और inefficient query कभी-कभी सारी alerts trigger कर रही थी
    • एक local hosting company ने local businesses में जिनके पास IT infrastructure था, उन पर DDoS attack किया और फिर DDoS protection शामिल अपने hosting solution का advertisement किया
    • Sweden की universities पर बड़े Quran burning controversy के बाद “Turkey” ने हमला किया। Twitter account से शेखी भी बघारी, लेकिन काफी साफ़ लग रहा था कि यह Russia था
    • सुना है कि कुछ हमलों में target subsystem होता है। ध्यान न खींचने के लिए वे पूरे network पर attack करते हैं
    • एक customer पर उसके competitors ने DDoS किया था, हालांकि competitors को शायद पता भी नहीं था कि वे DDoS कर रहे हैं। वे product listings को बहुत aggressive तरीके से scrape कर रहे थे, बिना किसी delay या rate limit के, और नतीजा DDoS बन गया
      उनका इरादा target site को धीमा करना नहीं था, लेकिन वे real paying customers की तुलना में ऐसी speed से data लेना चाहते थे कि server cost संभल न सके
      ऐसे हमले actual DDoS attacks से अलग हैं, लेकिन मेरे अनुभव में कहीं ज्यादा आम हैं, और Cloudflare या Akamai जैसी चीज़ों से अपेक्षाकृत आसानी से mitigate किए जा सकते हैं, इसलिए मैं customers को यही सलाह देता हूं
  • Cloudflare पर भी यही attack हुआ था: https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
  • “Google और AWS भी उसी समय यह attack देख रहे थे” वाला हिस्सा दिलचस्प है। अगर major providers में इस level पर काम करने वाला कोई हो, तो जानना चाहूंगा कि ऐसे scale के attack के दौरान असल में क्या होता है
    क्या Cloudflare, Google, AWS के लोग real-time video call में आकर आपस में coordinate करते हुए mitigation करते हैं, या फिर हर कोई दूर से दूसरे की स्थिति देखते हुए अपनी problem solve करने पर focus करता है?
    • आम तौर पर हर कोई अपनी-अपनी आग बुझाता है, लेकिन अगर किसी को कुछ interesting या नया दिखता है, तो आग बुझने के बाद पूछता है कि क्या कहीं और भी वैसा attack हुआ था। यह नया botnet, नया attack method आदि हो सकता है
      इस बार सबको एहसास हुआ कि वे एक ही चीज़ देख रहे हैं, और छोटे targets पर इसका असर बहुत बड़ा हो सकता है, इसलिए समस्या को साथ मिलकर समझा गया और सभी web server providers के साथ security response coordinate किया गया
  • जानना चाहता हूं कि DDoS mitigation कैसे काम करता है। “website को Cloudflare के पीछे रखकर DDoS mitigate करना” का ठीक-ठीक मतलब क्या है?
    क्या यह बस इतना है कि पर्याप्त बड़ा incoming bandwidth हो ताकि कुछ Gb/s झेल सकें और legitimate traffic के लिए spare capacity बची रहे?
    • वह भी शामिल है, लेकिन इसमें उससे कहीं ज्यादा चीजें होती हैं। आम तौर पर incoming flood को संभालने के लिए bandwidth और compute resources को dynamically बढ़ा सकना जरूरी होता है

काफी DDoS ट्रैफिक असल HTTP नहीं होता, बल्कि IP address की ओर पाइप भरने वाला बेकार ट्रैफिक होता है। बड़े पाइप और भौगोलिक रूप से फैले कई servers मदद करते हैं। TCP SYN flood की तरह ऐसे मामले भी होते हैं जहां सिर्फ TCP connections खोलकर उपलब्ध ports खत्म कर दिए जाते हैं। ऐसे असामान्य requests अक्सर server के front-end पर लगे कई सरल reverse proxies से संभाले जा सकते हैं
बाहर से सामान्य दिखने वाला HTTP traffic भेजने वाली ज्यादा sophisticated queries को अंततः process करना ही पड़ता है। जैसे cache से response देना, attackers को धीमा करने और normal traffic की पहचान के लिए CAPTCHA लगाना, या rate limiting लागू करना। असली server तक भेजने से पहले यह तय करना चाहते हैं कि request normal है या नहीं, और इसके लिए कई tools deploy किए जा सकते हैं

  • Cloudflare और दूसरी कंपनियां detect कर सकती हैं कि request DDoS traffic है या नहीं, और उसे server तक भेजने के बजाय drop, limit या verify कर सकती हैं
    server को इस तरह configure कर दें कि Cloudflare से आया traffic छोड़कर बाकी सब drop हो जाए, और यह तरीका efficient है
  • जब मैं Google SRE में था, लोग मजाक में कहते थे कि “DDoS traffic को बस Australia भेज देते हैं”
    आम तौर पर Google के internal data centers के बीच का traffic उस मात्रा से कहीं बड़ा होता है जो कोई DDoS में भेज सकता है, इसलिए उसे handle करने का कोई न कोई तरीका हमेशा मिल जाता है
  • अगर DDoS attack capacity-based है, तो उसे mitigate करने का एकमात्र तरीका इतना मोटा network रखना है कि traffic को संभाल सके, और ISP के साथ मिलकर upstream पर blocking शुरू करना है
    लेकिन हर DDoS capacity-based नहीं होता। slow loris attack की तरह protocol की basic functionality का दुरुपयोग करने वाले मामले भी होते हैं
    https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
  • आम तौर पर mitigation का मतलब DDoS requests को अपने-आप पहचानना और normal users पर असर डाले बिना उन्हें कम लागत में handle करना होता है
    इस मामले में यह तरीका हो सकता है कि client stream को तेजी से reset कर रहा है या नहीं, इसे पहचानकर उस traffic को slow lane में भेज दिया जाए या पूरी तरह filter कर दिया जाए
  • इस लेख में DDoS के हिस्से के रूप में इस्तेमाल हुए HTTP/2 Rapid Reset feature के बारे में अतिरिक्त जानकारी का link है: https://cloud.google.com/blog/products/identity-security/how...
  • क्या इस attack के source के बारे में कोई जिक्र नहीं है? ऐसा लगता है कि इसके लिए बहुत ज्यादा hardware चाहिए होगा, और अगर यह कोई botnet नहीं है तो इसे आसानी से trace किया जा सकेगा
    • खास तौर पर बुरी खबर यह है कि इस attack को सचमुच बहुत बड़े botnet की जरूरत नहीं है
      https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
      “record-breaking attack के बारे में एक मुख्य बात यह है कि इसमें लगभग 20,000 machines वाले medium-sized botnet की भागीदारी थी”
    • scale को देखते हुए, source को सार्वजनिक करना राजनीतिक और कानूनी रूप से संवेदनशील हो सकता है
    • तुरंत अनुमान यही है कि यह Iran कर रहा है। उसने पहले भी कई बार ऐसा किया है और Hamas का ally है। मैंने evidence नहीं देखा, लेकिन यह काफी safe अनुमान लगता है
  • क्या Cloudflare उस IP के अगले कुछ HTTP requests पर ऐसा page नहीं दिखा सकता जिसमें लिखा हो कि “आपके network में कुछ DDoS attack में भाग ले रहा है”
    बड़े providers सभी ऐसा करें, तो अगली बार किसी Cloudflare site पर जाने से पहले एक छोटा Turnstile जैसा page बीच में डाला जा सकता है
    अगर मेरे network में कोई infected device है तो मैं जानना चाहूंगा, और अभी इसे detect करने के लिए कोई वास्तविक monitoring भी नहीं है। यह पूरा solution नहीं है, लेकिन कम से कम user को यह बताना कि समस्या है, एक अच्छी शुरुआत है
    • अच्छा है। HTTPS से पहले के दौर में लौटकर, जब ISP HTML में ads inject करते थे, वैसा बनाया जा सकता है। इस बार बस CDN providers द्वारा ऐसा करना normalized हो जाएगा
    • CGNAT के दौर में यह अच्छा idea नहीं है
  • Cloudflare blog: https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...