दो पल होते हैं जब लोगों को पता चलता है कि DDoS मिटिगेशन असल में कैसे काम करता है। पहला पल शांत होता है, ख़रीदते वक़्त, जब कोई एक फ़ीचर लिस्ट पढ़ता है जिसमें लिखा है "DDoS प्रोटेक्शन शामिल है" और चुपचाप मान लेता है कि यह वाक्य हर चीज़ को कवर करता है। दूसरा पल रात के तीन बजे आता है, जब साइट डाउन हो, ग्राफ़ ऐसे ग़लत दिखें जिनका कोई मतलब न बने, और वह शामिल प्रोटेक्शन — सही तरीक़े से, और डिज़ाइन के मुताबिक़ — बिल्कुल कुछ न कर रहा हो।
दोनों पल एक ही प्रोडक्ट और एक ही सच्चाई से जुड़े होते हैं: एक होस्टिंग प्रोवाइडर उन हमलों को फ़िल्टर करता है जो कच्चे वॉल्यूम के तौर पर आते हैं, क्योंकि वह उस पाइप का मालिक है जिससे वे पैकेट गुज़रते हैं, आप नहीं। यह उन हमलों को फ़िल्टर नहीं कर सकता जो सामान्य दिखने वाले रिक्वेस्ट के तौर पर आते हैं, क्योंकि नेटवर्क की नज़र से वे सामान्य दिखने वाले रिक्वेस्ट ही हैं। वह रेखा — जो फ्लड आपका होस्ट सोख लेता है और जो फ्लड आपको ख़ुद झेलना पड़ता है, इन दोनों के बीच — ही पूरा विषय है। आगे जो कुछ भी है, वह यह पता लगाने के बारे में है कि आप इस रेखा के किस तरफ़ हैं, और हर तरफ़ क्या करना है।
एक ही नाम वाले दो अलग हमले
"DDoS" एक ऐसा शब्द है जो दो समस्याओं को ढँकता है, और नतीजे के अलावा इन दोनों में लगभग कुछ भी साझा नहीं है। इन्हें अलग-अलग जगहों पर, अलग-अलग लोगों द्वारा, अलग-अलग औज़ारों से रोका जाता है, और इन्हें गड्डमड्ड कर देना ही वजह है कि इतनी सारी मिटिगेशन कोशिशें ग़लत लेयर पर जाकर ख़त्म होती हैं।
| वॉल्यूमेट्रिक — लेयर 3 और 4 | एप्लिकेशन — लेयर 7 | |
|---|---|---|
| क्या आता है | SYN फ्लड, खुले DNS, NTP या memcached रिफ्लेक्टर के ज़रिए UDP एम्प्लिफ़िकेशन, ACK फ्लड, सीधी कचरा पैकेट बाढ़ | सामान्य HTTP रिक्वेस्ट: GET फ्लड, POST फ्लड, slow-loris, कैश-बस्टिंग क्वेरी स्ट्रिंग |
| किसमें मापा जाता है | गीगाबिट और लाखों पैकेट प्रति सेकंड | रिक्वेस्ट प्रति सेकंड — अक्सर बस कुछ हज़ार |
| आपको नुक़सान पहुँचाने के लिए ज़रूरी बैंडविड्थ | बहुत ज़्यादा। यह एक क्षमता की होड़ है | लगभग कुछ नहीं। अगर एंडपॉइंट काफ़ी महँगा हो तो एक अकेला लैपटॉप भी यह कर सकता है |
| इसे कहाँ रोकना ज़रूरी है | अपस्ट्रीम, आपके प्रोवाइडर द्वारा। जब तक पैकेट आपके पोर्ट तक पहुँचते हैं, नुक़सान हो चुका होता है | आपके सर्वर पर, आपके द्वारा, या उसके आगे आपके नियंत्रण वाली किसी प्रॉक्सी पर |
| बॉक्स पर यह कैसा दिखता है | इंटरफ़ेस भरा हुआ, पैकेट काउंटर बेतुके, CPU शायद ख़ाली भी हो | मामूली बैंडविड्थ, पर हर वर्कर व्यस्त, लोड बढ़ता हुआ, डेटाबेस क्यू बढ़ती हुई |
| इसे कौन ठीक करता है | आपके होस्ट की स्क्रबिंग, अपने-आप, आमतौर पर सेकंडों में | आपका कॉन्फ़िगरेशन — रेट लिमिट, कैशिंग, कनेक्शन सीमाएँ |
आख़िरी दो पंक्तियाँ फिर से पढ़ें, क्योंकि इनमें व्यावहारिक बात छुपी है। अगर इंटरफ़ेस भर चुका है, तो सर्वर में आप जो भी टाइप करें उससे कोई फ़र्क़ नहीं पड़ेगा: पैकेट पहले ही पोर्ट को खा चुके हैं, और इन्हें गिराने वाला अकेला पक्ष वह है जो अपस्ट्रीम राउटर का मालिक है। अगर इंटरफ़ेस शांत है पर साइट फिर भी डाउन है, तो उल्टा सच है — आपके होस्ट को कुछ भी ग़लत नहीं दिखता क्योंकि उनकी लेयर पर सच में कुछ भी ग़लत नहीं है, और यह ठीक करना पूरी तरह आपका काम है।
"DDoS प्रोटेक्शन शामिल है" असल में क्या देता है
नेटवर्क-लेयर प्रोटेक्शन असली है, क़ीमती है, और लगभग हमेशा ग़लत समझा जाता है। जब कोई प्रोवाइडर L3/L4 फ़िल्टरिंग का विज्ञापन करता है, तो उसका मतलब है कि उनका नेटवर्क आपके पते के लिए आने वाले ट्रैफ़िक पर नज़र रखता है, और जब कोई फ्लड पकड़ में आता है तो ट्रैफ़िक को स्क्रबिंग हार्डवेयर से गुज़ारा जाता है जो नुक़सानदेह हिस्सा गिरा देता है और जो वैध दिखे उसे आगे भेज देता है। यह बिना किसी सपोर्ट टिकट के होता है, और आमतौर पर आपको एक छोटी-सी झलक के अलावा कुछ पता भी नहीं चलता।
यह एक वाक्य बहुत सारा काम कर रहा है, इसलिए यह समझना ज़रूरी है कि इसमें क्या शामिल है और क्या नहीं:
- यह उन हमलों को कवर करता है जिन्हें आप अकेले नहीं झेल सकते। 1 Gbps पोर्ट वाले सर्वर के ख़िलाफ़ 200 Gbps का एम्प्लिफ़िकेशन फ्लड कोई कॉन्फ़िगरेशन समस्या नहीं है। यह सीधा हिसाब-किताब है। अपस्ट्रीम स्क्रबिंग ही अकेला जवाब है जो मौजूद है।
- यह आपके एप्लिकेशन के बारे में कुछ नहीं जानता। फ़िल्टर को नहीं पता कि आपके कौन-से URL महँगे हैं, कौन-से विज़िटर लॉग-इन हैं, या यह कि आपके सर्च एंडपॉइंट पर एक रिक्वेस्ट की क़ीमत आपके लोगो पर एक रिक्वेस्ट से चार सौ गुना ज़्यादा है।
- यह एक थ्रेशोल्ड पर प्रतिक्रिया देता है, आपकी तकलीफ़ पर नहीं। डिटेक्शन ट्रैफ़िक वॉल्यूम पर ट्रिगर होता है। जो हमला कभी थ्रेशोल्ड पार नहीं करता, वह इसे कभी ट्रिगर नहीं करता — चाहे उसने आपकी साइट को कितनी ही बुरी तरह क्यों न गिरा दिया हो।
- बेहद असाधारण मामलों में यह कुछ देर के लिए नल-रूट भी कर सकता है। हर नेटवर्क की एक सीमा होती है। अगर कोई हमला साझा इन्फ्रास्ट्रक्चर के लिए ख़तरा बन जाए, तो पता कुछ समय के लिए गिराया जा सकता है — यह मानक और सार्वभौमिक बात है, और इसके होने से पहले ही इसके बारे में जान लेना बेहतर है, बीच में नहीं।
एक पंक्ति में: आपका होस्ट अपने नेटवर्क की रक्षा करता है, और इसका फ़ायदा आपको मिलता है। यह आपके एप्लिकेशन की रक्षा नहीं करता, और इसका कोई तरीक़ा भी नहीं है। लेयर 7 कोई अपसेल नहीं है जो आपसे रोक ली गई हो — यह एक ऐसी लेयर है जिसके अंदर आपका प्रोवाइडर बिना आपका TLS टर्मिनेट किए झाँक ही नहीं सकता, और यह किसी के लिए भी जो ऑफ़शोर होस्ट कर रहा हो, अपनी ही गंभीर क़ीमत वाला एक सौदा है।
पहले तय करें कि यह हमला है भी या नहीं
DDoS का शक होने वाली घटनाओं में एक बड़ा हिस्सा असल में कुछ और होता है, बस उसका कोट पहने हुए, और इनके इलाज एक-दूसरे की जगह काम नहीं करते। कुछ भी रेट-लिमिट करने से पहले, नक़ली मामलों को ख़ारिज करने में दो मिनट लगाएँ — यहाँ ग़लत पहचान आपको एक घंटा, और कभी-कभी आपके असली यूज़र, ख़र्च करवा देती है।
- आप मशहूर हो गए। किसी बड़े एग्रीगेटर पर एक लिंक बिल्कुल एक L7 फ्लड जैसा दिखने वाला ट्रैफ़िक शेप पैदा करता है, बस फ़र्क़ इतना है कि रेफ़रर असली होते हैं और रिक्वेस्ट उन पेजों के लिए होते हैं जिन्हें कोई इंसान देखना चाहेगा। यह एक ख़ुशनुमा वजह वाली क्षमता समस्या है; इसे रेट-लिमिट करना ख़ुद को नुक़सान पहुँचाना है।
- किसी क्रॉलर के तौर-तरीक़े बिगड़ गए। आक्रामक स्क्रैपर और AI ट्रेनिंग बॉट किसी छोटे सर्वर को आसानी से पछाड़ सकते हैं। यूज़र-एजेंट आमतौर पर ख़ुद बता देता है, और इलाज है
robots.txtप्लस एक लक्षित लिमिट, न कि एक सामान्य लिमिट। - आपने कुछ तोड़ दिया। कोई डिप्लॉयमेंट जिसने कैशिंग बंद कर दी, कोई बेक़ाबू क्रॉन जॉब, कोई डेटाबेस जिसका इंडेक्स खो गया — ये सब "अचानक लोड, कोई साफ़ वजह नहीं" जैसे दिखते हैं। अगर समय आपके किए किसी बदलाव से मेल खाता है, तो उसी बदलाव को दोषी मानें।
- आपकी अपनी मॉनिटरिंग ही फ्लड है। दुर्लभ, शर्मनाक, और जितना कोई मानता है उससे कहीं ज़्यादा आम। बिना बैकऑफ़ के दोबारा कोशिश करने वाला एक हेल्थ-चेक लूप सच में एक प्रभावशाली रिक्वेस्ट रेट पैदा कर सकता है।
फ़र्क़ करने वाला सवाल आसान है: क्या ट्रैफ़िक को कुछ चाहिए? असली लोड — यहाँ तक कि दुश्मनी जैसे दिखने वाले असली लोड को भी — एक शेप होती है। यह उन पेजों पर जाता है जो मौजूद हैं, लिंक फ़ॉलो करता है, ऐसेट लोड करता है, और नेटवर्क के एक विश्वसनीय फैलाव से आता है। हमला आमतौर पर इतनी परवाह नहीं करता।
सर्वर से ख़ुद हमले को पढ़ना
क्या हो रहा है यह पहचानने के लिए आपको किसी डैशबोर्ड की ज़रूरत नहीं। सही क्रम में चलाए गए चार कमांड आपको एक मिनट से भी कम में बता देंगे कि आप किस लेयर में लड़ रहे हैं — और यह जानना ही तय करता है कि आगे आप क्या करेंगे।
क्या पाइप भर चुकी है? इंटरफ़ेस काउंटर देखें। अगर थ्रूपुट पोर्ट की सीमा के क़रीब अटका हुआ है, तो आप एक वॉल्यूमेट्रिक हमले में हैं, और आपका काम एक सपोर्ट टिकट है, कोई कॉन्फ़िग बदलाव नहीं:
vnstat -tr 10— दस सेकंड में औसत थ्रूपुट, सैचुरेशन का सबसे तेज़ ईमानदार आँकड़ा।cat /proc/net/devको एक सेकंड के फ़ासले पर दो बार — हर इंटरफ़ेस के पैकेट और बाइट का अंतर, बिना किसी टूल के।
क्या यह SYN फ्लड है? हाफ़-ओपन कनेक्शन SYN-RECV में जमा होते जाते हैं। मुट्ठी भर सामान्य है; हज़ारों नहीं:
ss -s— सारांश पंक्ति, एक नज़र में स्टेट के हिसाब से कनेक्शन गिनती।ss -tn state syn-recv | wc -l— वह ख़ास संख्या जो मायने रखती है।
क्या यह लेयर 7 है? अगर बैंडविड्थ सामान्य है पर सब कुछ धीमा है, तो अपने एक्सेस लॉग में हर क्लाइंट के रिक्वेस्ट गिनें। दसियों हज़ार हिट वाला एक अकेला पता एक शौक़िया है; तीन-तीन हिट वाले एक लाख पते असली माल हैं:
tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30- इसके बजाय माँगे गए पाथ को रैंक करने के लिए
$1की जगह$7रखें। अगर एक महँगा एंडपॉइंट हावी है, तो आपको निशाना भी मिल गया और आधा इलाज भी।
असल में ख़त्म क्या हुआ है? लोड एवरेज अकेले बहुत कम बताता है। उस ख़ास सीमा को खोजें जो आपने छू ली है: PHP-FPM के सारे चाइल्ड व्यस्त, डेटाबेस कनेक्शन अपनी सीमा पर, फ़ाइल डिस्क्रिप्टर ख़त्म, या डिस्क का इंतज़ार करते D स्टेट में फँसे वर्कर। वह सीमा — ट्रैफ़िक नहीं — है जिसने साइट को गिराया, और अक्सर इसे बढ़ाना किसी भी चीज़ को फ़िल्टर करने से तेज़ होता है।
देखते वक़्त यह ध्यान रखें: अगर आप प्राइवेसी-केंद्रित सेवा चलाते हैं, तो हमला ठीक वही पल है जब लॉगिंग बढ़ाकर वैसी ही छोड़ देने का सबसे ज़्यादा मन करता है। अगर ज़रूरी हो तो बढ़ाएँ, फिर बाद में इसे वापस घटाएँ और फ़ाइलों को आक्रामक तरीक़े से रोटेट करें। ऐसी घटना जो पूरे महीने के पूरी-तफ़सील वाले विज़िटर लॉग डिस्क पर छोड़ जाए, एक समस्या को उससे बदतर और लंबे समय तक टिकने वाली दूसरी समस्या से बदल देती है। हमारी Server OpSec गाइड इस अनुशासन को कवर करती है।
पहले दस मिनट
दबाव में, लोग सबसे बड़ा उपलब्ध लीवर पकड़ लेते हैं, और सबसे बड़ा लीवर आमतौर पर ग़लत होता है। यह वह क्रम है जो नुक़सान सीमित करता है, मोटे तौर पर सबसे तेज़-और-सबसे-सुरक्षित पहले:
- कार्रवाई से पहले पहचानें। भरा हुआ इंटरफ़ेस माने वॉल्यूमेट्रिक; व्यस्त वर्कर वाला शांत इंटरफ़ेस माने लेयर 7। यहाँ ख़र्च किए तीस सेकंड आपको एक घंटे तक ग़लत लेयर ठीक करने से बचा लेते हैं।
- अगर यह वॉल्यूमेट्रिक है, तो फ़ौरन एक टिकट खोलें और उसमें डेस्टिनेशन पता, शुरू होने का समय, और अपने इंटरफ़ेस काउंटर शामिल करें। फिर सर्वर में टाइप करना बंद कर दें — आप इसे अंदर से ठीक नहीं कर सकते।
- अगर यह लेयर 7 है, तो पहले कैश करें। अनाम विज़िटर के लिए आक्रामक फ़ुल-पेज कैशिंग चालू करना, किसी आउटेज को महज़ एक कंधा उचकाने में बदलने का अकेला सबसे तेज़ तरीक़ा है, और यह अकेला उपाय है जो असली ट्रैफ़िक के ख़िलाफ़ भी मदद करता है।
- फिर रेट-लिमिट करें — पहले निशाना बना एंडपॉइंट, बाक़ी सब बाद में। शुरुआत सतर्क रखें। ऐसी लिमिट जो आपके अपने यूज़र को बाहर कर दे, हमले की ख़ुद-लगाई गई अगली कड़ी है।
- सिर्फ़ वही ब्लॉक करें जो बिल्कुल साफ़ हो। एक दर्जन पते जिनमें से हर एक पर एक लाख रिक्वेस्ट, कोई साफ़ नक़ली यूज़र-एजेंट, कोई एक देश जहाँ आपका कोई यूज़र नहीं। हमले के बीच पेचीदा नियम लिखने की इच्छा पर काबू रखें; अगले महीने आपको वे याद ही नहीं रहेंगे।
- अगर ज़रूरी हो तो जान-बूझकर लोड कम करें। बिना लॉग-इन वाले विज़िटर को एक स्टैटिक "अंडर मेंटेनेंस" पेज परोसना बॉक्स को ज़िंदा रखता है, आपका API चालू रखता है, और सोचने का वक़्त ख़रीदता है। क्या क़ुर्बान करना है यह ख़ुद तय करना, इससे बेहतर है कि यह आपके लिए तय हो जाए।
- जो किया उसे लिख लें। हर अस्थायी नियम जो आपने जोड़ा, आने वाले कल के आपके लिए एक बारूदी सुरंग है। जिन नियमों ने मदद की वे स्थायी बन जाते हैं; बाक़ी कल हटा दिए जाते हैं।
टिकने वाली रेट लिमिट, और वह ग़लती जो हर कोई करता है
रेट लिमिटिंग लेयर 7 के लिए मुख्य औज़ार है, और nginx इसे दो डायरेक्टिव के साथ बख़ूबी करता है जो दो सच में अलग-अलग समस्याएँ हल करते हैं। limit_req रिक्वेस्ट की रेट सीमित करता है — यानी एक क्लाइंट कितनी बार पूछ सकता है। limit_conn समवर्ती कनेक्शन सीमित करता है — यानी एक क्लाइंट एक साथ कितने कनेक्शन खुले रख सकता है। फ्लड को पहले वाले की ज़रूरत होती है; slow-loris हमलों को, जो आपके वर्कर पूल को थकाने के लिए हज़ारों लगभग-निष्क्रिय कनेक्शन थामे रहते हैं, दूसरे वाले की। सिर्फ़ एक तैनात करें और आप आधी समस्या के ख़िलाफ़ ही सुरक्षित हैं।
तीन बारीकियाँ एक काम करने वाली लिमिट को एक दिखावटी लिमिट से अलग करती हैं:
- बर्स्ट इस्तेमाल करें, और
nodelayइस्तेमाल करें। असली ब्राउज़र बर्स्ट में चलते हैं — एक अकेला पेज व्यू एक दर्जन लगभग-एक-साथ ऐसेट रिक्वेस्ट दाग़ता है। बिना गुंजाइश वाली लिमिट असली विज़िटर को रोक देती है जबकि थ्रेशोल्ड से बस नीचे अपनी रफ़्तार रखने वाला हमलावर आराम से निकल जाता है। - महँगे एंडपॉइंट को अलग से सीमित करें। आपका सर्च पेज, लॉगिन फ़ॉर्म, पासवर्ड रीसेट और डेटाबेस में लिखने वाला कोई भी एंडपॉइंट, आपके स्टैटिक ऐसेट से कहीं ज़्यादा तंग बजट का हक़दार है। हमलावर इन्हें बिना कोशिश किए ढूँढ लेते हैं, क्योंकि यही वे हैं जो चोट पहुँचाते हैं।
- 429 लौटाएँ, 503 नहीं। यह स्टेटस कोड सही-व्यवहार वाले क्लाइंट और सर्च इंजन को यह संकेत देता है कि यह थ्रॉटलिंग है, नाकामी नहीं — और यह एक बुरी दोपहर को रैंकिंग समस्या बनने से रोकता है।
वह ग़लती जो चुपचाप यह सब बेकार कर देती है: अगर आपके सर्वर के आगे कुछ भी बैठा है — एक CDN, एक लोड बैलेंसर, आपकी अपनी रिवर्स प्रॉक्सी — तो हर रिक्वेस्ट उसके पते से आता है, विज़िटर के पते से नहीं। तब एक प्रति-क्लाइंट रेट लिमिट पूरे इंटरनेट को एक क्लाइंट मानकर गिनती करती है, और यह या तो बिल्कुल कुछ नहीं करेगी या आपकी पूरी ऑडियंस को एक साथ बैन कर देगी। आपको अपना रियल-IP सोर्स कॉन्फ़िगर करना ही होगा (nginx में, प्रॉक्सी की रेंज के लिए set_real_ip_from प्लस वह हेडर जो प्रॉक्सी भेजता है उसके लिए real_ip_header) — और यह लिमिट के कोई मतलब रखने से पहले करना होगा। इसे भी प्रॉक्सी की अपनी रेंज तक सीमित रखें: खुले इंटरनेट से आया क्लाइंट-दिया हेडर भरोसा करने पर एक हमलावर हर रिक्वेस्ट पर एक नई पहचान गढ़ सकता है और आपकी हर लिमिट से सीधा निकल सकता है।
कैशिंग सबसे सस्ती मिटिगेशन है जो आप कभी तैनात करेंगे
एक रेट लिमिट काम को नकारती है। एक कैश काम को मौजूद ही नहीं रहने देता। अनाम विज़िटर को दिखने वाली किसी भी चीज़ के लिए, फ़ुल-पेज कैशिंग पूरे हमले का हिसाब-किताब बदल देती है: जो रिक्वेस्ट पहले एक डेटाबेस राउंड-ट्रिप, एक टेम्पलेट रेंडर और एक PHP वर्कर की क़ीमत लेता था, वह अब माइक्रोसेकंड में मापी जाने वाली एक फ़ाइल रीड बन जाता है। जो सर्वर चार सौ डायनेमिक रिक्वेस्ट प्रति सेकंड पर ढह गया था, वही अब दसियों हज़ार कैश्ड रिक्वेस्ट बिना अटके परोस देगा।
जब आप इसे ग़ुस्से में चालू करते हैं तो ये बातें मायने रखती हैं:
- सिर्फ़ अनाम विज़िटर के लिए कैश करें। सेशन कुकी पर बायपास रखें। एक लॉग-इन यूज़र का पेज किसी दूसरे को परोस देना, जिस आउटेज को आप ठीक कर रहे थे उससे कहीं बुरी घटना है।
- जान-बूझकर बासी कंटेंट परोसें। nginx का
proxy_cache_use_stale,updating error timeoutके साथ, इसका मतलब है कि जब आपका बैकएंड जूझ रहा हो, तो विज़िटर को एरर की बजाय थोड़ा पुराना पेज मिलता है। हमले के दौरान यही फ़र्क़ है एक ठीक-ठाक दिखती साइट और एक मरी हुई दिखती साइट के बीच। - दोहरे मिस को इकट्ठा करें।
proxy_cache_lockयह पक्का करता है कि एक ही अनकैश्ड पेज के लिए हज़ार एक साथ आए रिक्वेस्ट, हज़ार नहीं बल्कि एक बैकएंड रिक्वेस्ट पैदा करें। इसके बिना, एक कैश-बस्टिंग हमला कैश से सीधा गुज़रकर पूरी ताक़त से आपके डेटाबेस पर जा गिरता है। - कैश-बस्टिंग क्वेरी स्ट्रिंग को बेअसर करें। आम तरकीब है
?और एक रैंडम वैल्यू जोड़ना ताकि हर रिक्वेस्ट एक यूनीक की बन जाए और हमेशा मिस हो। अपनी कैश की को नॉर्मलाइज़ करें ताकि वे क्वेरी पैरामीटर नज़रअंदाज़ हों जिन्हें आपका एप्लिकेशन असल में इस्तेमाल ही नहीं करता।
यहाँ एक सुखद असमानता है जिसे समझ लेना अच्छा है: कैशिंग पर लगाया हर घंटा, साइट को उसके सबसे अच्छे दिन भी तेज़, चलाने में सस्ता, और कामयाबी झेलने में बेहतर बना देता है। मुश्किल से कोई और सुरक्षा-पंक्ति ऐसी है जो तब भी मुनाफ़ा दे जब सब कुछ ठीक-ठाक चल रहा हो।
वे सीमाएँ जो तय करती हैं कि आप गिरेंगे या नहीं
ज़्यादातर सर्वर इसलिए नहीं मरते कि उनका CPU ख़त्म हो गया। वे इसलिए मरते हैं क्योंकि वे एक अदृश्य सीमा से टकरा जाते हैं जिसे किसी ने जान-बूझकर सेट नहीं किया था — एक दशक पुराना डिफ़ॉल्ट जो उस हार्डवेयर पर मायने रखता था जिसे अब कोई इस्तेमाल नहीं करता। हमले के दौरान, असल में सबसे पहले यही टूटते हैं:
- एप्लिकेशन वर्कर। PHP-FPM का
pm.max_children, आपकी Python वर्कर गिनती, आपके Node क्लस्टर का साइज़। यही आपकी साइट की असली कंकरन्सी सीमा है। जब ये सब व्यस्त हों, तो हर अतिरिक्त विज़िटर क्यू में लग जाता है, और साइट डाउन रहती है चाहे CPU कितना भी ख़ाली क्यों न दिखे। इसे सिर्फ़ उतना ही बढ़ाएँ जितनी मेमोरी इजाज़त दे — स्वैपिंग, क्यूइंग से बदतर है। - एक्सेप्ट क्यू।
net.core.somaxconnऔर आपका लिसन बैकलॉग तय करते हैं कि कितने कनेक्शन स्वीकार होने का इंतज़ार कर सकते हैं। एक छोटा बैकलॉग एक झेली जा सकने वाली बर्स्ट को ठुकराए गए कनेक्शन में बदल देता है। - SYN कुकीज़।
net.ipv4.tcp_syncookiesकर्नेल को उन कनेक्शन के लिए स्टेट बनाए बिना एक SYN फ्लड का जवाब देने देता है जो कभी पूरे होने वाले ही नहीं। आधुनिक कर्नेल इसे डिफ़ॉल्ट रूप से चालू रखते हैं; मान लेने की बजाय जाँच लें, क्योंकि इसकी कोई क़ीमत नहीं है और यह आपको सबसे आम फ्लड से बचाता है जो मौजूद है। - फ़ाइल डिस्क्रिप्टर। हर कनेक्शन एक डिस्क्रिप्टर है। डिफ़ॉल्ट
nofileलिमिट अक्सर उन कनेक्शन की संख्या से कम होती है जिन्हें आप परोसने की कोशिश कर रहे हैं, और नाकामी का तरीक़ा — जब सब कुछ सेहतमंद दिखते हुए भी accept फेल हो रहा हो — रात तीन बजे सच में उलझन भरा होता है। - डेटाबेस कनेक्शन। कनेक्शन पूल बढ़ाए बिना वर्कर गिनती बढ़ाना क्यू को बस किसी ऐसी जगह खिसका देता है जहाँ देखना मुश्किल हो। इन दोनों संख्याओं को साथ में एडजस्ट करना ज़रूरी है।
इन्हें किसी शांत दिन पर ट्यून करें, किसी घटना के दौरान नहीं। इन्हें जानने का मतलब यह है कि जब साइट गिरे, तो आप अंदाज़ा लगाने की बजाय उस सीमा का नाम ले सकें जिससे वह टकराई — और नाम ली गई सीमा ही ठीक की जा सकने वाली सीमा है।
ओरिजिन के आगे कुछ रखना
ऊपर बताई गई हर चीज़ सर्वर पर होती है। अगला क़दम यह तय करना है कि क्या सर्वर को सीधे ट्रैफ़िक पाने वाली चीज़ होना भी चाहिए। तीन ईमानदार विकल्प हैं, और सही जवाब इस बात पर आप जो अफ़ोर्ड कर सकते हैं उससे कहीं ज़्यादा इस बात पर निर्भर करता है कि आप होस्ट क्या कर रहे हैं।
| तरीक़ा | आपको क्या मिलता है | आपको क्या क़ीमत चुकानी पड़ती है |
|---|---|---|
| ओरिजिन सीधे एक्सपोज़्ड, हार्डन किया हुआ | सादगी, कोई थर्ड पार्टी नहीं, कोई ऐसा TLS टर्मिनेशन नहीं जो आपके नियंत्रण में न हो | आपका पता पब्लिक और स्थायी है। लेयर 7 पूरी तरह आपकी ज़िम्मेदारी है |
| कमर्शियल CDN या स्क्रबिंग सेवा | बेहद बड़ी सोखने की क्षमता, एक क्लिक में एक चैलेंज पेज, ग्लोबल कैशिंग | आपके कंटेंट पर राय रखने वाला एक एब्यूज़ डेस्क, और एक कंपनी जो आपका ट्रैफ़िक देख सकती है। ऑफ़शोर या DMCA-संवेदनशील प्रोजेक्ट के लिए यह अक्सर एक वरना सतर्क सेटअप की सबसे कमज़ोर कड़ी बन सकता है |
| आपका अपना फ़्रंट नोड — nginx चलाने वाला एक छोटा VPS, जो एक फ़ायरवॉल में बंद ओरिजिन तक प्रॉक्सी करता है | पूरा नियंत्रण, रिक्वेस्ट के रास्ते में कोई थर्ड पार्टी नहीं, एक ऐसा पता जिसे आप जला और बदल सकते हैं, और एक असली पता जो छुपा रहता है | उसकी अपनी क्षमता सीमाएँ, और चलाने के लिए एक और मशीन। अलग-अलग नेटवर्क में दो-तीन फ़्रंट इसे गिराना काफ़ी मुश्किल बना देते हैं |
सेल्फ़-होस्टेड फ़्रंट नोड को आमतौर पर मिलने से ज़्यादा ध्यान मिलना चाहिए, ख़ासकर उन लोगों के लिए जिन्होंने ऐसी वजहों से ऑफ़शोर होस्टिंग चुनी जिनसे कोई बड़ा CDN शायद हमदर्दी न रखे। तरीक़ा बिना किसी चमक-दमक का है: आगे सस्ते प्रॉक्सी नोड, ओरिजिन एक फ़ायरवॉल में बंद कि सिर्फ़ उन्हीं नोड से कनेक्शन स्वीकार करे, DNS फ़्रंट की ओर इशारा करता हुआ। अगर किसी फ़्रंट पर हमला हो, तो आप उसे मिनटों में एक नए पते से बदल देते हैं और ओरिजिन को पता भी नहीं चलता। इस आर्किटेक्चर का पूरा वर्शन — साथ में वे छह तरीक़े जिनसे एक ओरिजिन पता फिर भी लीक हो जाता है — हमारी गाइड ओरिजिन सर्वर IP छुपाना का विषय है।
छुपा हुआ ओरिजिन किसी भी फ़िल्टर से ज़्यादा क़ीमती है
यह साफ़-साफ़ कह देना ज़रूरी है, क्योंकि यह सामान्य प्राथमिकता को उलट देता है: आपको उपलब्ध सबसे सस्ती DDoS मिटिगेशन एक ऐसा पता है जो हमलावर के पास नहीं है। फ़िल्टरिंग वह है जो आप तब करते हैं जब यह पहले ही नाकाम हो चुका हो।
यह सुनने से कहीं ज़्यादा मायने रखता है, क्योंकि ओरिजिन पते लगातार और चुपचाप लीक होते हैं। प्रॉक्सी लगाने से पहले के पुराने DNS रिकॉर्ड, बदलाव के बरसों बाद तक बने रहते हैं। एप्लिकेशन से सीधे भेजी मेल अपने हेडर में पता ले जाती है। कच्चे पते पर जारी किया गया एक TLS सर्टिफ़िकेट सर्टिफ़िकेट ट्रांसपेरेंसी लॉग में स्थायी रूप से छप जाता है। एक एरर पेज, एक रीडायरेक्ट, या कोई गुमनाम सबडोमेन जिसे कभी प्रॉक्सी नहीं किया गया, सब इसे उजागर कर देते हैं। अगर आपने किसी ऐसे सर्वर के आगे CDN लगाया है जो पहले एक्सपोज़्ड था, तो मान लें कि पुराना पता तब तक जाना-पहचाना है जब तक आपने उसे बदल न दिया हो।
इसका नतीजा एक फ़ायरवॉल नियम है, और यह इस गाइड की सबसे क़ीमती अकेली पंक्ति है: एक बार जब कुछ आगे बैठ जाए, तो ओरिजिन को 80 और 443 पर उस फ़्रंट के पतों को छोड़कर बाक़ी सब से कनेक्शन ठुकरा देने चाहिए। इसके बिना, प्रॉक्सी बस एक सुझाव है — जो कोई भी असली पता जान लेता है, वह बस उसके इर्द-गिर्द से निकलकर आप पर सीधा हमला कर देता है, और आपने फ़्रंट पर जो कुछ भी कॉन्फ़िगर किया वह सिर्फ़ दिखावा बनकर रह जाता है।
हार्डवेयर और लोकेशन ऐसे चुनना कि हमले उबाऊ बने रहें
इसमें से कुछ हिस्सा हमला होने से पहले ही तय हो जाता है, ठीक उस पल जब आप कोई प्लान चुनते हैं। तीन ख़ासियतें स्पेसिफ़िकेशन शीट के अंदाज़े से कहीं ज़्यादा मायने रखती हैं:
- अनमीटर्ड बैंडविड्थ। मीटर्ड प्लान पर, हमला सिर्फ़ एक आउटेज नहीं होता — यह एक इनवॉइस भी होता है। जो ट्रैफ़िक आपने कभी माँगा नहीं और ठुकरा भी नहीं सकते थे, वह भी आपके अलाउंस में गिना जाता है। अनमीटर्ड ट्रांसफ़र एक वित्तीय जोखिम को महज़ एक तकनीकी जोखिम में बदल देता है, जो एक कहीं बेहतर क़िस्म की समस्या है।
- क्या पोर्ट सिर्फ़ आपका है। किसी साझा वर्चुअलाइज़्ड होस्ट पर, हमले की चपेट में आया कोई पड़ोसी आपको भी नुक़सान पहुँचा सकता है, और आपकी अपनी प्रोटेक्शन सीमा भी साझा होती है। अपने पोर्ट वाला डेडिकेटेड हार्डवेयर दोनों असर हटा देता है। ऐसे प्रोजेक्ट के लिए जिसे दुश्मनी भरा ध्यान मिलने की उम्मीद हो, यही VPS से ऊपर जाने की सबसे साफ़ वजह है — कोर या RAM से भी ज़्यादा।
- नेटवर्क कहाँ बैठा है। असली ट्रांज़िट क्षमता वाला एक अच्छी तरह जुड़ा यूरोपीय नेटवर्क वह फ्लड सोख लेता है जो एक ख़राब-पीयर्ड नेटवर्क नहीं सोख पाएगा, और जो क्षेत्राधिकार आपने क़ानूनी वजहों से चुना, उसकी नेटवर्क ख़ासियतें भी होती हैं। उपलब्ध लोकेशन में से चुनते वक़्त दोनों जाँच लेना बेहतर है।
यहाँ एक स्केल वाली दलील भी है जो चुपचाप सादगी के पक्ष में जाती है। किसी मामूली सर्वर पर कैश के पीछे बैठी एक स्टैटिक साइट को गिराना असाधारण रूप से मुश्किल है; वही कंटेंट अगर एक भारी-भरकम CMS पर एक अनकैश्ड सर्च एंडपॉइंट के साथ हो, तो एक स्क्रिप्ट लिए एक ज़िद्दी इंसान उसे तोड़ सकता है। जो डायनेमिक है उसे घटाना भी एक मिटिगेशन है, और यह मुफ़्त है। अगर आपका प्रोजेक्ट सच में लगातार लोड के तहत जीता है, तो हमारी हाई-ट्रैफ़िक होस्टिंग नोट्स इसी सवाल के साइज़िंग वाले पहलू को कवर करते हैं।
पाँच चीज़ें जो नहीं करनी चाहिए
यहाँ नाकामी के तरीक़े इतने एक-जैसे हैं कि उन्हें सूचीबद्ध किया जा सके, और हर एक ने किसी न किसी का पूरा वीकेंड ख़र्च करवाया है:
- ख़ुद को नल-रूट मत करें। अपने ही पते को ब्लैकहोल करना हमले को सबसे शाब्दिक तरीक़े से ख़त्म करता है — आपके यूज़र समेत कोई भी आप तक नहीं पहुँच पाता। यह आपके प्रोवाइडर के लिए आख़िरी उपाय वाला औज़ार है, कोई ऐसा क़दम नहीं जो आप ख़ुद अपनी मर्ज़ी से उठाएँ।
- fail2ban को DDoS प्रोटेक्शन मत मानें। यह कुछ पतों से आने वाली ब्रूट-फ़ोर्स कोशिशों के ख़िलाफ़ एक बढ़िया औज़ार है। एक डिस्ट्रिब्यूटेड फ्लड के ख़िलाफ़ यह सेकंडों में आने वाली किसी चीज़ पर मिनटों में प्रतिक्रिया देता है, और हज़ारों पतों को बैन करने वाला एक नियम, फ़ायरवॉल प्रोसेसिंग में हमले से भी ज़्यादा क़ीमत ले सकता है।
- फ़िरौती मत दें। तबाही मचाने वाले हमले की धमकी देने वाले जबरन-वसूली ईमेल की बहुत बड़ी बहुसंख्या ऐसे लोगों से आती है जिनके पास कोई क्षमता नहीं होती और जो हज़ारों एक-जैसे मैसेज भेजते हैं। जो छोटी-सी अल्पसंख्या सच में कर गुज़र सकती है, वह वापस आएगी, क्योंकि आपने साबित कर दिया कि आप भुगतान करते हैं।
- जवाबी हमला मत करें। लगभग हर जगह यह ग़ैर-क़ानूनी होने के अलावा, स्रोत ख़ुद समझौता किए गए थर्ड पार्टी होते हैं। आप पीड़ितों पर हमला कर रहे होंगे, और वह भी एक ऐसे पते से जो बेशक़ आपका ही है।
- घबराकर माइग्रेट मत करें। हमले के बीच होस्ट बदलने का मतलब है कि नया पता मिनटों में पब्लिक हो जाता है और आपके पास कोई काम करता कॉन्फ़िगरेशन नहीं होता। पहले स्थिर हों, बाद में सोच-समझकर आगे बढ़ें — और अगर आप बदलते ही हैं, तो बिना डाउनटाइम माइग्रेट करने पर हमारी गाइड ठीक इसीलिए मौजूद है ताकि यह बदलाव ख़ुद एक दूसरी घटना न बन जाए।
संक्षिप्त वर्शन
तर्क को हटाकर, काम करने वाला मॉडल आठ पंक्तियों में समा जाता है:
- पहले पहचानें। भरा हुआ इंटरफ़ेस माने वॉल्यूमेट्रिक, और यह आपके होस्ट का काम है। थके हुए वर्कर वाला शांत इंटरफ़ेस माने लेयर 7, और यह आपका काम है।
- वॉल्यूमेट्रिक के लिए, पता, टाइमस्टैंप और अपने काउंटर के साथ एक टिकट फ़ाइल करें — फिर सर्वर को छूना बंद कर दें।
- अनाम विज़िटर के लिए आक्रामक तरीक़े से कैश करें, दबाव में बासी कंटेंट परोसें, और दोहरे मिस इकट्ठा करें। यह वह बदलाव है जिसका सबसे ज़्यादा असर होता है।
- रिक्वेस्ट रेट और समवर्ती कनेक्शन, दोनों से रेट-लिमिट करें, सबसे महँगे एंडपॉइंट पर सबसे तंग, और 429 लौटाएँ।
- बाक़ी सब कुछ करने से पहले अपना रियल-IP कॉन्फ़िगरेशन ठीक करें, वरना प्रॉक्सी के पीछे हर प्रति-क्लाइंट लिमिट या तो बेकार होगी या तबाही मचाने वाली।
- अपनी सीमाएँ जानें — वर्कर, बैकलॉग, डिस्क्रिप्टर, डेटाबेस कनेक्शन — और किसी शांत दिन जान-बूझकर इन्हें बढ़ाएँ।
- ओरिजिन पता गुप्त रखें और उसे अपने फ़्रंट नोड तक फ़ायरवॉल में बंद रखें। यह हर फ़िल्टर को मिलाकर भी उससे ज़्यादा क़ीमती है।
- अनमीटर्ड बैंडविड्थ ख़रीदें ताकि जो ट्रैफ़िक आपने माँगा ही नहीं वह कभी बिल भी न बने।
इनमें से कुछ भी आपको अभेद्य नहीं बनाता, और जो कोई भी अभेद्यता बेच रहा हो वह कुछ और ही बेच रहा है। यह जो करता है वह यह है कि आपको उस आबादी से बाहर निकाल देता है जिसे कोई ऊबा हुआ किशोर भी ऑफ़लाइन कर देता है, और उस आबादी में डाल देता है जिसे परेशान करने के लिए असली संसाधन और असली इरादे की ज़रूरत होती है — जो, ज़्यादातर प्रोजेक्ट के लिए, सुरक्षित होने से अलग पहचाना ही नहीं जा सकता। बाक़ी वही बिना चमक-दमक वाला काम है जो एक सर्वर को हर और चीज़ में भी अच्छा बनाता है: पहले ही दिन हार्डन किया हुआ, सबसे बुरे दिन रीस्टोर किया जा सकने वाला, और कहीं ऐसी जगह चलता हुआ जो आपके ट्रैफ़िक को आपका अपना कारोबार मानकर बरते।