कई हफ्तों से जारी DDoS हमले की कोशिशों पर हम कोई कार्रवाई नहीं कर रहे

DDoS हमले का सामना कर रहे हैं, लेकिन कुछ नहीं कर रहे

• कई हफ्तों से कोई DDoS हमला करने की कोशिश कर रहा है.
• सर्वर पर लाखों requests भेजकर configuration file को लाखों बार डाउनलोड करने की कोशिश की जा रही है.
• सिर्फ पिछले 5 दिनों में ही 8 लाख से ज़्यादा download attempts हुए, और configuration file हर download पर लगभग 200MB की है.
• ज़्यादातर traffic EU से, खासकर Germany और UK से आ रहा है.
• यह हमला इस ब्लॉग पोस्ट के लिखे जाने के समय भी जारी है.

इस आपात स्थिति में हम क्या कर रहे हैं

• हम हमलावर के IP addresses को block नहीं कर रहे.
• हम Cloudflare का उपयोग कर रहे हैं, लेकिन "Under Attack" mode को enable नहीं कर रहे.
• हमले के दौरान भी server CPU ज़्यादातर समय लगभग idle रहता है.
• आम तौर पर, हम लगभग कुछ भी नहीं कर रहे.

ऐसा क्यों?

• यह service बिना किसी समस्या के हर महीने अरबों requests संभाल सकती है, और इसकी लागत भी बहुत ज़्यादा नहीं है.
• लगभग 8 API services और databases हैं, और वे बिना caching के भी हर महीने अरबों requests संभाल सकती हैं.
• हमारे पास Cloudflare और unlimited bandwidth है.

यह कैसे संभव है?

• TablePlus app का design simple है, और यही philosophy backend services पर भी लागू होती है, जिन्हें न्यूनतम रखा गया है.
• हम Vercel या Netlify जैसी third-party services का उपयोग नहीं करते. इसके बजाय, हम बिना सीमाओं वाले web servers का उपयोग करते हैं.
• पहले, कमज़ोर VPS/processor के कारण monolith bottleneck बन जाता था, लेकिन आज के powerful VPS एक single instance पर हर महीने अरबों requests संभाल सकते हैं.
• इसलिए हम हर app के लिए monolithic service बनाते हैं. इससे deployment और maintenance आसान हो जाते हैं.

आइए monolith के बारे में बात करें

• चीज़ों को ज़रूरत से ज़्यादा complex बनाने की प्रवृत्ति होती है, लेकिन यह तब तक समस्या नहीं बनती जब तक दबाव या सीमाएँ सामने न आएँ.
• हमें complexity पसंद नहीं, इसलिए हम monolith चुनते हैं. app को जो कुछ चाहिए, उसे एक single service में समाहित करते हैं.
• deployment simple है. सिर्फ एक configuration file, build और deployment की ज़रूरत होती है.
• dependencies कम होने से debugging और bottlenecks की पहचान करना आसान होता है.

अगर सही तरह से implement किया जाए, तो Go या Rust का एक single web framework हर महीने अरबों requests संभाल सकता है

• हम high-performance framework चुनते हैं.
• database को index करते हैं ताकि data set बढ़ने पर fetch time कम हो.
• main database को log/usage database से अलग रखते हैं, ताकि performance issues core business को प्रभावित न करें.
• Nginx जैसे powerful reverse proxy का उपयोग करके requests को handle और core API तक distribute करते हैं.
• सब कुछ Cloudflare के पीछे रखते हैं और उसे सही तरह से configure करते हैं.
• DDoS protection वाले CDN का उपयोग करते हैं.
• CDN या caching के बिना बड़े downloadable files को VPS पर नहीं रखते.

आइए deployment के बारे में बात करें

• TablePlus में हम deployment process को जितना संभव हो सके उतना simple बनाते हैं.
• हम Docker, Kubernetes या containers का उपयोग नहीं करते, और environment setup की ज़रूरत नहीं होती.
• हम binaries का उपयोग करते हैं. binaries को copy करके Linux server पर process की तरह चलाया जा सकता है.
• हम Go और Rust चुनते हैं. ये high-performance languages हैं और deployment के लिए binary files बना सकती हैं.

अपडेट

• Vercel ने संपर्क किया है और कहा है कि उनके पास इस तरह की स्थिति में site को protect करने वाले features हैं.
• spend management के ज़रिए spending limit set की जा सकती है, और एक attack challenge mode भी है, जो CF के "Under Attack" mode जैसा है.

GN⁺ की राय

• यह लेख दिखाता है कि DDoS हमले के बावजूद stable service operation के लिए मजबूत infrastructure और simplified deployment strategy कितनी महत्वपूर्ण है.
• यह भी सामने आता है कि monolithic architecture complexity घटाने, deployment आसान बनाने और performance optimization में फायदेमंद हो सकता है.
• cloud services और CDN का प्रभावी उपयोग करके DDoS हमलों के प्रति resilience बनाना दूसरी कंपनियों के लिए भी एक अच्छा उदाहरण हो सकता है.
• यह approach खासकर शुरुआती चरण के startups या छोटे और मध्यम व्यवसायों के लिए cost-effective infrastructure बनाने पर उपयोगी insight देती है.
• हालांकि, हर system या application के लिए monolithic approach उपयुक्त नहीं होती, इसलिए अपनी ज़रूरतों और परिस्थितियों के अनुसार architecture चुनना महत्वपूर्ण है.

[GN⁺]

Hacker News राय

• पहले कमेंट का सार:

  • कमेंट करने वाले को लगता है कि वेबसाइट की performance के बारे में शेखी बढ़ा-चढ़ाकर की गई है।
  • "मासिक 1 अरब requests" का मतलब प्रति सेकंड केवल कुछ सौ requests है, जो बहुत मामूली स्तर है और इसे DDoS attack नहीं माना जा सकता।
  • साइट CDN (Cloudflare) के पीछे है, इसलिए ऐसा नहीं लगता कि performance के मामले में कुछ खास किया गया है।
  • 200MB फ़ाइल का CDN के जरिए cache होकर serve होना स्वाभाविक है, और इसे लेकर शेखी बघारना अनुपयुक्त design जैसा लगता है।

• दूसरे कमेंट का सार:

  • मासिक 4TB traffic को DDoS attack मानना मुश्किल है।
  • मासिक 60 लाख requests का मतलब प्रति सेकंड केवल 2 requests है, और इस स्तर पर एक single service (monolith service) चलाना समस्या नहीं है।
  • माना जाता है कि ज़्यादातर requests को Cloudflare CDN स्तर पर cache करके संभाल लेगा।

• तीसरे कमेंट का सार:

  • साइट एक साधारण static marketing site है, इसमें discussion forum नहीं है और feedback GitHub issues के जरिए संभाला जाता है।
  • static files के हर दिन लाखों बार download होने को एक simple deployment से संभाल सकने पर शेखी बघारना अजीब लगता है।
  • Cloudflare ही पूरा mitigation कर रहा है, और वास्तव में traffic इतना कम है कि शायद इसकी ज़रूरत भी नहीं हो।

• चौथे कमेंट का सार:

  • वर्णित अतिरिक्त traffic "service का अर्थहीन दुरुपयोग" जैसा दिखता है, और इसे वास्तविक DDoS attack कहना कठिन है।
  • जब तक इस दुरुपयोग से cost या resource exhaustion की समस्या नहीं होती, इसे नज़रअंदाज़ किया जा सकता है।
  • autoscaling infrastructure का ज़्यादातर हिस्सा उपयोगी काम नहीं करता, ऐसी बात आम है, इसलिए traffic पर नज़र रखना अच्छा है।
  • logging को लेकर शिकायत है; अगर log storage सस्ता और पर्याप्त है तो यह समस्या नहीं है, लेकिन abuse traffic को अपने-आप classify करके रोज़मर्रा की processing को दबाना बेहतर होगा।

• पाँचवें कमेंट का सार:

  • यूके में मासिक 5 करोड़ requests एक single script चलने से भी हो सकती हैं।
  • लेखक को उम्मीद है कि एक Go server बिना optimization के भी इससे 250 गुना अधिक requests प्रति सेकंड संभाल सकता है।
  • सलाह अपने-आप में बुरी नहीं है, लेकिन उनके दिए हुए आँकड़े उस सलाह का प्रमाण नहीं बनते।

• छठे कमेंट का सार:

  • binaries को deploy करना Docker इस्तेमाल करने से अधिक पसंद किया जा सकता है, लेकिन binaries चलाने वाले host की security को लेकर चिंता होती है।
  • एक single VPS पर host की गई single service (monolith service) सस्ती और अच्छी हो सकती है, लेकिन hardware में समस्या आने पर काफ़ी downtime हो सकता है।
  • सब कुछ एक single service में समेट देने से defence in depth कम हो सकती है, जिससे security issue होने पर data store तक access मिल सकता है।

• सातवें कमेंट का सार:

  • "मासिक 1 अरब requests" ऐसा स्तर है जिसे एक single server संभाल सकता है, और एक गलत script अकेले इतना traffic पैदा कर सकती है।

• आठवें कमेंट का सार:

  • यह सवाल उठाया गया कि क्या मासिक अरबों requests को सचमुच बड़ा DDoS attack माना जा सकता है।

• नौवें कमेंट का सार:

  • हर app के लिए single service (monolith service) बनाना deployment और maintenance के लिहाज़ से आसान है।
  • Docker, Kubernetes, dependencies और runtime environment के बिना सिर्फ binary files deploy करनी होती हैं।

• दसवें कमेंट का सार:

  • शीर्षक पढ़कर उससे बड़ा मामला लग रहा था, लेकिन Cloudflare के पीछे होना एक महत्वपूर्ण factor है।
  • traffic distribution पर निर्भर करते हुए, Cloudflare के बिना भी यह VPS पर ठीक चल सकता है।
  • रूस से होने वाले layer7 DDoS attacks इतने बड़े पैमाने के होते हैं कि capacity समस्या के कारण बड़े providers भी विफल हो जाते हैं।