- TablePlus कई हफ्तों से जारी DDoS प्रयासों के बावजूद IP block या Cloudflare “Under Attack” mode के बिना सर्वर की स्थिति देख रहा है
- पिछले 30 दिनों में installer file download के प्रयास लगभग 60 लाख रहे, जिनमें से पिछले 5 दिनों में ही 800,126 प्रयास हुए, और फ़ाइल का आकार प्रति download लगभग 200MB है
- हमले के दौरान भी सर्वर CPU उपयोग अधिकांश समय 0~1% पर रहा, और लगभग 8 API services तथा databases को बिना cache के हर महीने अरबों requests संभालने लायक बनाया गया है
- backend को हर app के लिए monolithic service के रूप में रखा गया है, और Docker·Kubernetes·runtime environment के बिना single binary को नए VPS पर deploy किया जाता है
- Go/Rust frameworks, database indexing, log DB separation, Nginx reverse proxy, Cloudflare CDN/R2, और email sending throttling जैसी सरल संरचना हमले की लागत और operations की जटिलता कम करती है
कई हफ्तों से जारी DDoS प्रयास
- किसी ने TablePlus सर्वर पर कई हफ्तों तक सैकड़ों मिलियन requests भेजीं और installer files को लाखों बार डाउनलोड करने की कोशिश की
- installer file download के प्रयास पिछले 5 दिनों में 800,126 और पिछले 30 दिनों में लगभग 60 लाख तक पहुँचे
- installer file का आकार प्रति download लगभग 200MB है
- पिछले 30 दिनों के API calls के आधार पर, अधिकतर traffic EU, खासकर Germany और United Kingdom से आया
- इस आँकड़े में download requests और CDN traffic शामिल नहीं हैं
- यह लेख लिखे जाने के समय भी हमला जारी है
वास्तविक प्रतिक्रिया: block करने से ज़्यादा टिकाऊ संरचना
- attacker के IP addresses को block नहीं किया गया
- Cloudflare इस्तेमाल हो रहा है, लेकिन “Under Attack” mode चालू नहीं किया गया
- हमले के दौरान भी सर्वर CPU अधिकतर 0~1% पर, यानी लगभग idle स्थिति में रहा
- service हर महीने अरबों requests बिना समस्या संभाल सकती है और लागत का दबाव भी बड़ा नहीं है, इसलिए अलग से लगभग कोई कार्रवाई नहीं की गई
सरल backend डिज़ाइन
- TablePlus app की डिज़ाइन simplicity पर केंद्रित है, और backend services भी जहाँ तक संभव हो न्यूनतम संरचना में रखी जाती हैं
- Vercel या Netlify जैसी third-party rendering services हमले के दौरान bottleneck या अनपेक्षित billing पैदा कर सकती हैं, इसलिए उनका उपयोग नहीं किया जाता
- उनका मानना है कि अपना web server इस्तेमाल करने से ऐसी सीमाओं से बचा जा सकता है
- पहले कमजोर VPS और processor के कारण monolith bottleneck बन सकता था, लेकिन अब VPS multi-core CPU, बड़ी RAM और तेज SSD देते हैं
- तेज SSD और RAM database performance को काफी बढ़ाते हैं
- सही implementation होने पर single-instance monolith service भी हर महीने अरबों requests संभाल सकती है
हर app के लिए monolith चलाने का तरीका
- हर app के लिए ज़रूरी API, website, email, payment आदि को एक ही service में जोड़ा जाता है
- deployment सिर्फ एक config file, build और deploy तक सीमित रहता है
- किसी दूसरे cloud vendor पर service migrate करनी हो या नई deployment करनी हो, तो यह काम तेज़ी से किया जा सकता है
- dependencies कम होने से debugging और bottleneck पहचानना आसान होता है
- error होने पर जाँचने के लिए सिर्फ एक या बहुत कम services होती हैं
- monolith framework के कुछ विकल्प इस प्रकार हैं
- Golang: Echo, Gin
- PHP: Laravel
- Ruby: Rails
- Rust: Actix, Rocket, Warp
हर महीने अरबों requests के लिए संरचना के सिद्धांत
- high-performance web framework चुना जाता है, और TablePlus Golang तथा Rust को प्राथमिकता देता है
- dataset बड़ा होने पर query time कम करने के लिए database में indexes सेट किए जाते हैं
- core business performance की रक्षा के लिए main database और log·usage database को अलग रखा जाता है
- main database उस data के लिए है जो बदलता नहीं या समय के साथ आकार में नहीं बढ़ता
- log·usage database उस data के लिए है जो समय के साथ लगातार बढ़ता है
- core API के सामने reverse proxy रखकर requests को process और distribute किया जाता है
- कई servers की ज़रूरत होने पर यह उपयोगी होता है
- TablePlus Nginx का उपयोग करता है
- सब कुछ Cloudflare के पीछे रखकर cache, Argo, और Cloudflare व server के बीच full SSL को उचित तरीके से configure किया जाता है
- DDoS protection वाला CDN इस्तेमाल किया जाता है
- TablePlus लागत कम करने और सुरक्षा के लिए Amazon CloudFront + S3 की तुलना में Cloudflare R2 और CDN को पसंद करता है
- बड़े download files को CDN या caching के बिना VPS पर रखने से bandwidth जल्दी खत्म हो सकती है
- TablePlus unlimited bandwidth वाला Cloudflare CDN इस्तेमाल करता है
- उसी domain पर Argo enabled होने पर Cloudflare CDN traffic Argo से होकर जा सकता है, और Argo bandwidth मुफ़्त नहीं होने से लागत बढ़ सकती है
- password reset जैसी requests, जिनमें server को email भेजना पड़ता है, उनके लिए throttling से mailer की सुरक्षा की जाती है
deployment तरीका: container के बिना binary चलाना
- TablePlus deployment process को Docker, Kubernetes, containers, या अलग runtime environment setup के बिना जितना संभव हो उतना सरल रखता है
- deployment unit binary है
- इसे Linux server पर copy करने के बाद process के रूप में चलाया जाता है
- इसे macOS पर TablePlus app चलाने के तरीके जैसा माना जाता है
- Linux Systemctl process को monitor कर सकता है और fatal error होने पर restart भी कर सकता है
- VM, virtualization, या third-party infrastructure managers जैसी मध्यवर्ती परतों में CPU/RAM बर्बाद न हो, इसलिए इसे native तरीके से चलाया जाता है
- Go और Rust high-performance languages हैं और deployment के लिए binary files बना सकती हैं, इसलिए इन्हें चुना गया है
Vercel इस्तेमाल करने पर कौन-से protection features चालू रखने चाहिए
- Vercel ऐसी स्थिति में site की सुरक्षा के लिए Spend Management और Attack Challenge Mode देता है
- Spend Management: soft या hard spending limits सेट की जा सकती हैं
- Attack Challenge Mode: Cloudflare के “Under Attack” mode जैसा है
- अगर Vercel इस्तेमाल किया जाए, तो इन features को चालू रखना ज़रूरी है
1 टिप्पणियां
Hacker News की राय
यह लेख खुद की बहुत ज़्यादा तारीफ़ जैसा लगता है। “महीने में 1 अरब requests” का मतलब प्रति सेकंड सिर्फ़ कुछ सौ requests है, इसलिए यह मामूली स्तर है और इसे DDoS कहना भी मुश्किल है
ऊपर से साइट CDN Cloudflare के पीछे है, इसलिए performance के नज़रिये से इसमें कुछ बहुत बड़ा किया गया है, ऐसा क्यों माना जाए, यह और भी कम समझ आता है
उदाहरण के लिए, ऐसी कोई वाजिब स्थिति नहीं है जिसमें 200MB फ़ाइल CDN पर cache होकर serve न हो। यह कोई गर्व की बात नहीं कि application server हर download पर disk से 200MB पढ़कर client को copy नहीं कर रहा; ऐसा करना तो साफ़ तौर पर बहुत खराब design होगा
अगर 200MB फ़ाइल से मतलब https://tableplus.com/download पर TablePlus client app download है, तो Windows वाला 183MB है और वास्तव में Cloudflare पर cache हो रहा है
# curl -v https://files.tableplus.com/windows/5.9.2/TablePlusSetup.exec > /dev/null< cache-control: max-age=691200< cf-cache-status: HIT< age: 2980आम तौर पर क्या यह वही तरह की चीज़ नहीं है जिसे FAANG कंपनी होने पर लोग कहें कि इसके लिए 1,000 से ज़्यादा developers चाहिए होंगे? बड़ी कंपनियाँ भी जो काम नियमित रूप से नहीं कर पातीं, उसे सिर्फ़ खुद की तारीफ़ कैसे कहा जा सकता है, यह समझ नहीं आता
इसे सिर्फ़ प्रति सेकंड कुछ सौ requests के रूप में देखना ठीक नहीं। request density समय के हिसाब से बराबर नहीं होती और अक्सर average से 20 गुना तक पहुँच सकती है
महीने के 4TB को सच में DDoS attack कहना मुश्किल नहीं है क्या? अगर घंटे के 4TB होते तो DDoS कह सकते थे, लेकिन महीने के 4TB का मतलब सिर्फ़ 1.5MB प्रति सेकंड है
महीने के 60 लाख requests भी सिर्फ़ 2 requests प्रति सेकंड हैं। इस scale पर यह बात कि service monolith के रूप में चल रही है, बहुत महत्वपूर्ण नहीं लगती, खासकर जब Cloudflare CDN cache से ज़्यादातर requests संभाल रहा हो
वेब का बहुत बड़ा हिस्सा महीने के 5~20 डॉलर वाले multi-tenant hosting पर चलने वाली WordPress sites है, और थोड़े बड़े संगठनों में अक्सर Drupal होता है। वे बिना cache लगाए सीधे database से जुड़े होते हैं, इसलिए इंटरनेट की ज़्यादातर sites सिर्फ़ 4 requests प्रति सेकंड पर भी down हो सकती हैं
यह पागलपन जैसा लग सकता है, लेकिन हक़ीक़त यही है। पहले मैं Cloudflare में DDoS defense, WAF, firewall और customer-facing security projects संभालता था, और अक्सर देखा कि web scraping या बहुत मामूली, कम HTTP request rate से ही customer sites गिर जाती थीं
headlines में बड़े numbers आते हैं, लेकिन ज़्यादातर लोग असल में छोटे numbers का असर महसूस करते हैं
service denial attack सिर्फ़ प्रति घंटे कुछ KB से भी हो सकता है। target service के heavy API endpoint को hit कर दो, वही service गिराने के लिए काफ़ी हो सकता है, और Distributed का मतलब बस इतना है कि कई machines एक साथ attack कर रही हैं
DDoS के लिए ज़रूरी नहीं कि बहुत बड़ा throughput हो। बस खबरों में आम तौर पर बड़े attacks ही आते हैं
ऐसे attacks का मक़सद origin server का bandwidth quota ख़त्म करना या bandwidth cost को असहनीय बना देना हो सकता है। यह एक या कुछ attack machines से भी बहुत सस्ते में किया जा सकता है। ज़्यादातर datacenters और hosting providers bandwidth limit रखते हैं या एक तय मात्रा के बाद charge करते हैं, और बहुत बार target कंपनी को तब पता चलता है जब उसके पास भारी-भरकम bill आ चुका होता है
एक game download website है जिसके कुल users शायद 50 के आसपास होंगे। लगभग कोई इसका इस्तेमाल नहीं करता, और असली लोग महीने में बस कुछ ही बार game download करते होंगे
लेकिन एक 2GB zip फ़ाइल से पिछले महीने 5TB traffic निकला, और यह कई सालों से चलता आ रहा है। यह DDoS नहीं, बल्कि एक गलत तरह से configured bot/crawler है जो हर link follow करता है और download cancel नहीं कर पाता
यह शायद दिन का 1TB लगता है, लेकिन फिर भी यह बहुत छोटा है
यह traffic कितना irregular है, शायद बात उस पर निर्भर करती है
यह desktop app के लिए बस एक static marketing site है। न कोई discussion forum है, न feedback; feedback GitHub issues में लिया जाता है
static marketing site deploy करना कितना आसान है, और static files दिन में लाखों बार download होकर भी टिक जाती हैं, इस पर शेख़ी बघारना काफ़ी अजीब है। और यहाँ mitigation का काम Cloudflare कर रहा है, वे नहीं। वह भी तब, अगर इतने छोटे traffic पर mitigation की ज़रूरत मानें
अगर मुझे ऐसा “attack” मिला होता, तो शायद Cloudflare के हर महीने आने वाले “X TB transferred, लगभग 100% bandwidth saved” ईमेल देखने तक मुझे पता भी नहीं चलता
app ख़ुद मुझे पसंद है और recommend करने लायक है
यह DDoS attack से ज़्यादा, विवरण के हिसाब से महीने के लगभग 8TB अतिरिक्त traffic वाला “बेकार मगर परेशान करने वाला service abuse” लगता है
अगर ऐसा abuse cost या resource exhaustion की समस्या नहीं पैदा कर रहा, तो इसे ignore करना ठीक हो सकता है, लेकिन “बाद में पता चला कि autoscaling fleet capacity का 80% कोई काम का काम किए बिना ही खर्च हो रहा था” जैसी बातें दुखद रूप से बहुत आम हैं, इसलिए कम से कम निगरानी रखना ज़रूरी है
ऐसे abuse में सबसे परेशान करने वाली चीज़ अक्सर logs होती हैं। logs का बड़ा हिस्सा उन्हीं hosts की उन्हीं बेकार activities से भर जाता है। अगर log storage सस्ता और पर्याप्त है, तो यह बहुत बड़ी समस्या नहीं, लेकिन कुछ traffic को अपने-आप abuse classify करके उसके routine handling को दबाना निश्चित ही अच्छा विचार है
लेकिन यह कहना जितना आसान है, करना उतना नहीं। incoming SMTP server पर खुल्लम-खुल्ला और बेवकूफ़ाना abuse पकड़ने के लिए मैंने न जाने कितनी बार classification logic जोड़ी है, और हर बार कुछ borderline लेकिन valid scenarios भी फँस जाते थे
अगर आप लगातार ऐसे rabbit hole में बहुत समय लगाएँ, तो असली काम ही नहीं हो पाता। इसलिए कभी outsourcing बेहतर होती है, या अगर वह भी बहुत झंझट या महँगी हो, तो कभी-कभी खीझ के बावजूद abuse को बस ignore करना ही बेहतर होता है
उदाहरण के लिए DigitalOcean में s-4vcpu-8gb-intel पर शामिल 5TB से ऊपर के 3TB extra के लिए 30 डॉलर लगते हैं, और Linode में 3TB extra के 15 डॉलर। इसलिए मुझे लगता है कि लेख की बात में कुछ दम है
यह कोई उल्लेखनीय “हमला” नहीं है। किसी की मशीन पर बेकाबू चल रही एक अकेली bash script से भी यह संभव है
“यूके से प्रति माह 5 करोड़ requests” का मतलब औसतन प्रति सेकंड 20 requests भी नहीं होता। उम्मीद की जा सकती है कि एक अकेला Go server बिना किसी बड़े optimization के भी उससे 250 गुना ज़्यादा request load संभाल लेगा
सलाह अपने-आप में ज़रूरी नहीं कि खराब हो, लेकिन ये संख्याएँ उस सलाह के सबूत नहीं बनतीं। अगर यह Go HTTP API service है, तो छोटे~मध्यम VPS पर database work और थोड़ा JSON formatting होने पर भी बिना optimization के प्रति सेकंड 5,000 requests संभालने की उम्मीद की जा सकती है। यह आँकड़ा उस अनुभव पर आधारित है जहाँ ऐसे ही कई दर्जन services deploy की गई थीं, जो रोज़ अरबों requests लेती थीं और peak पर प्रति सेकंड 5 लाख requests से ऊपर जाती थीं
यह अच्छी बात है कि इससे नुकसान नहीं हुआ, लेकिन इसे सलाह की तरह लेने में झिझक होती है क्योंकि इसमें बहुत कुछ छूटा हुआ है
Docker की जगह binary deployment को पसंद करना ठीक है, लेकिन वह binary जिस host पर चलेगी उसका क्या? Containers इस्तेमाल करने का एक कारण यह भी है कि security hardening settings को deployment के साथ bundle किया जा सके, ताकि बाद में scale करना पड़े तो भरोसा रहे कि अलग-अलग nodes पर security settings एक जैसी हैं
यहाँ जिस monolith की बात हो रही है, उसे एक अकेले VPS पर चलाया जा सकता है, और यह अच्छा भी है और सस्ता भी। लेकिन अगर crash हो जाए या hardware किसी भी वजह से fail हो जाए, तो काफ़ी बड़ा downtime हो सकता है
एक और चिंता यह है कि सब कुछ monolith में बाँध देने से application stack की defense in depth खत्म हो जाती है। अगर कोई frontend के ज़रिए app में घुस गया, तो वह सीधे backend data store तक पहुँच सकता है। इसी वजह से बहुत लोग data store को internal web service के पीछे रखते हैं और frontend से अलग private network के security groups से उसे बंद रखते हैं, ताकि attack surface browser से किए जा सकने वाले कामों के स्तर तक सीमित रहे
attack surface बढ़ाकर सुरक्षा बेहतर नहीं होती
अगर आपको लगता है कि Docker install कर देने भर से host secure हो जाता है, तो यह गलत है। scale करते समय अतिरिक्त hosts को कैसे configure करेंगे?
Docker इस्तेमाल करने पर सिर्फ containers ही नहीं, host भी सुरक्षित होना चाहिए, यानी वह service भी जो containers चलाती है। और जब scale करके नए hosts deploy किए जाएँ, तब भी वे उसी तरह सुरक्षित होने चाहिए
अगर आप infrastructure as code और configuration as code इस्तेमाल करते हैं, तो system settings के पीछे binary deploy करें या Docker deploy करें, मूल रूप से कोई फ़र्क नहीं है
“bare metal” setup को कुछ हद तक reproducible बनाने वाले tools मौजूद हैं। जैसे NixOS, Ansible, और Amazon AMI image builds
“frontend के ज़रिए app में घुसना” वाली बात हमेशा समझ से बाहर लगती है। SQL injection बिना remote code execution के भी data store को सीधे छू सकता है, और XSS दूसरे users को horizontal तरीके से प्रभावित करता है
लेकिन frontend से पूरे backend तक कोई खुली पहुँच आखिर कैसे मिल जाती है? क्या लोग Go API service के अंदर shell access वाले JavaScript interpreter चला रहे हैं और user input पर
evalबुला रहे हैं? तकनीकी रूप से यह बहुत ज़्यादा खींची हुई बात लगती हैआख़िरकार यह security through obscurity ही नहीं है क्या? यानी चीज़ों को इतना जटिल बना दो कि हम खुद भी न समझें, तो दूसरे भी नहीं समझ पाएँगे?
अहम बात ज़्यादा दीवारें बनाना नहीं, बल्कि दीवारों को तोड़ पाना असंभव बनाना है। Interfaces performance घटाते हैं और complexity बढ़ाते हैं
व्यक्तिगत रूप से यह भाषा खटकती है। “प्रति माह 1 अरब requests” लगभग प्रति सेकंड 370 requests के बराबर है। यह ऐसा स्तर है जिसे एक ठीक से configured server भी संभाल सकता है, और निश्चित ही 10 servers से कम में हो जाएगा
एक अकेली दुर्भावनापूर्ण bash script भी इतना ट्रैफिक बना सकती है
हो सकता है मेरी reality check कमजोर हो, लेकिन प्रति माह कई अरब requests कोई बहुत बड़ी बात नहीं लगतीं। क्या इसे बड़ा DDoS attack माना जाता है?
“हर app के लिए deploy और maintain करने में आसान monolith service बनाते हैं। Docker नहीं, Kubernetes नहीं, dependencies नहीं, runtime environment नहीं, बस एक binary file जिसे किसी भी नए VPS पर deploy किया जा सकता है” — यह हिस्सा अच्छा लगा
मैं खुद TablePlus इस्तेमाल नहीं करता। अगर यह marketing website की बात है, तो Kubernetes की ज़रूरत नहीं होना स्वाभाविक है
लेकिन अगर यह application की बात है, तो dependencies न होना अजीब लगता है। क्या यह data store नहीं करता और logs नहीं लिखता?
यह Golang का सचमुच शानदार फ़ायदा है। VPS शुरू करें, कुछ समझदार default settings लगाएँ, cross-compile करें और binary चला दें
Python, Node, PHP deployment की तुलना में इसमें कहीं कम बेवजह की complexity है
काश database server चलाना और उसे लगातार ज़िंदा रखना भी इतना ही सरल होता
शीर्षक देखकर मैं कुछ और swole doge जैसा पढ़ने की उम्मीद कर रहा था। सलाह के काफ़ी हिस्से से सहमत हूँ, लेकिन Cloudflare के पीछे होना किसी भी तरह “कुछ नहीं” नहीं है
traffic distribution के आधार पर, Cloudflare के बिना भी सिर्फ VPS से यह स्थिति आराम से संभल सकती थी, और scale भी इतना बड़ा नहीं लगता। अगर प्रति सेकंड requests और Cloudflare ने origin तक पहुँचने से पहले कितना block किया, जैसे ज़्यादा विस्तृत आँकड़े मिलते, तो दिलचस्प होता
मेरी जानकारी में स्वीडिश कंपनियों को निशाना बनाने वाला रूस से आया Layer 7 DDoS इतना बड़ा था कि बड़े providers capacity issues से जूझते हुए गिर गए थे। इसमें Verizon, Azure Frontdoor, Cloudflare, और GCP load balancer तक शामिल थे। उस स्तर के सामने यह strategy बिल्कुल काम नहीं करेगी