वेब सार्वजनिक सेवाओं के पास हमलावरों से बचाव का कोई बुनियादी तरीका नहीं है
नमस्ते, मैं निकम्मा हूँ।
हाल ही में हमलों में काफी बढ़ोतरी हुई है, इसलिए मैं बिना ज़्यादा सोचे कुछ लिख रहा हूँ।
HTTP क्लाइंट से होने वाले हमलों से बचाव का कोई बुनियादी तरीका नहीं है
सबसे पहले, आइए अलग-अलग सुरक्षा उपायों पर विचार करें।
IP पता
IPv6 पता हो तो ठीक है, लेकिन CGNAT वाले माहौल में साझा IPv4 पता आवंटित होता है, जिससे हमले के निशाने पर मौजूद व्यक्ति के अलावा दूसरे पीड़ित भी इसकी चपेट में आ जाते हैं।
इसके अलावा, IP रोटेशन करना आसान है। आजकल हमले के लिए अक्सर इस्तेमाल होने वाले, दुनिया भर में बड़ी संख्या में IP पते रखने वाले अमेरिका के सस्ते VPS या चीन-आधारित क्लाउड सेवाओं से हज़ारों IP पते जुटाकर DDoS हमले करना आम होता जा रहा है। AS Number स्तर पर रोक लगाने पर भी, अगर आपकी सेवा चीन में उपलब्ध है, तो चीन-आधारित क्लाउड IP पतों को रोकना कोई बुनियादी समाधान नहीं होगा और इससे चीनी उपयोगकर्ताओं को भी बेवजह नुकसान होगा।
मुझे नहीं लगता कि चीन के क्लाउड वातावरण को बिना सोचे-समझे रोक देना चाहिए, क्योंकि दूसरे देशों के लोग अक्सर इनका दुरुपयोग करते हैं।
मेरा मूल विचार यह है कि अगर कोई सेवा वर्ल्ड वाइड वेब पर उपलब्ध है और उसका आनंद लेने वाला एक भी व्यक्ति है, तो मैं उसे बिना सोचे-समझे ब्लॉक नहीं करना चाहता।
मैं भी कभी-कभी BiliBili के वीडियो देखता हूँ, और अमेरिकी सेवाएँ भी इस्तेमाल करता हूँ।
User-Agent
मूल रूप से, इस पर बात करना ही व्यर्थ है। मेरे विचार से अनुरोध हेडर का मूल्यांकन करके पहुँच सीमित करना लगभग बेकार है, इसलिए इस बारे में ज़्यादा कुछ कहने को नहीं है।
इसे जितनी बार चाहें नकली बनाया जा सकता है, इसलिए केवल UA के आधार पर रोक नहीं लगाई जा सकती।
अगर कुछ करना हो, तो कोई googlebot के रूप में UA का दावा करे और उसका रिवर्स-लुकअप होस्ट *.googlebot.com या *.google.com न हो, तो उसे पूरी तरह ब्लॉक किया जा सकता है—जैसा कि मैं इस साइट पर कर रहा हूँ। लेकिन यह खुद लागू करना होगा, या यह देखना होगा कि CDN में ऐसा कोई मिलता-जुलता तरीका पहले से लागू है या नहीं। इसके अलावा, भले ही Google आधिकारिक तौर पर यही कहता हो, कुछ वैध बॉट ऐसे भी हैं जिन्हें Google रिवर्स-लुकअप में इन होस्टों के अलावा दूसरे होस्ट से भेजता है। इसलिए सिर्फ़ इस जाँच के आधार पर पूरी तरह भरोसा नहीं किया जा सकता।
वैसे, इस कचरे जैसी साइट पर भी इतने लोग Googlebot होने का दावा करते हैं:
fail2ban report - fake-googlebot
देशों को ब्लॉक करना
किसी हमले के बाद यह एक अस्थायी उपाय हो सकता है, लेकिन स्थायी समाधान के रूप में इसका कोई मतलब नहीं है। वजह IP पते के आधार पर रोक लगाने जैसी ही है, इसलिए यहाँ दोहराऊँगा नहीं।
हालाँकि, अगर सेवा केवल घरेलू उपयोगकर्ताओं के लिए है, तो यह उपयोगी हो सकता है।
TLS Fingerprint
TLS फ़िंगरप्रिंट को भी आसानी से नकली बनाया जा सकता है।
ऐसा इसलिए, क्योंकि HTTP क्लाइंट में ब्राउज़र में शामिल उसी क्रिप्टोग्राफ़िक लाइब्रेरी को जोड़ देने पर ब्राउज़र का फ़िंगरप्रिंट नकली बनाया जा सकता है।
यह कहना मुश्किल है कि इसका कोई असर बिल्कुल नहीं होता, लेकिन उदाहरण के लिए, अगर कोई वैध बॉट उसी क्रिप्टोग्राफ़िक लाइब्रेरी का इस्तेमाल करके अनुरोध भेज रहा हो, तो उसे गलती से ब्लॉक किया जा सकता है।
कई HTTP क्लाइंट के साथ इसकी समानता होने का जोखिम ज़्यादा है, इसलिए इसका सीधा-सादा मूल्यांकन नहीं किया जा सकता।
इसलिए, इसे निर्णय लेने के कई मानदंडों में से एक के रूप में इस्तेमाल किया जा सकता है। अकेली शर्त के तौर पर इस्तेमाल करने के बजाय इसे दूसरे नियमों के साथ मिलाकर देखने पर कुछ उपयोगिता हो सकती है।
Cloudlfare Challenge / PoW Challenge
Cloudflare Challenge को हेडलेस ब्राउज़र इस्तेमाल किए बिना भी आसानी से बायपास किया जा सकता है।
पता नहीं Anubis कैसा है, लेकिन UX के लिहाज़ से यह बहुत अच्छा नहीं है: इसमें क्लाइंट-साइड गणना करवानी पड़ती है और पेज बदलते समय यह काफी परेशानी देता है।
एक मायने में, यह JS Challenge के साथ मिलकर सुरक्षा दे सकता है। वास्तव में, हाल के दिनों में लीक फ़ोरमों में भी कस्टम PoW Challenge लागू करने वालों की संख्या बढ़ रही है। इसलिए, PoW Challenge का इस्तेमाल कहाँ किया जाए, और अगर मकसद DoS से बचाव है, तो क्या एप्लिकेशन लेयर के इतने करीब इस PoW Challenge से सुरक्षा देना सही है—यह थोड़ा संदिग्ध है। अगर इसका इस्तेमाल बहुत सीमित परिस्थितियों में किया जाए, तो शायद ऐसा फ्रंट-एंड सुरक्षा उपाय बनाया जा सके जो UX को जितना हो सके उतना प्रभावित किए बिना अपेक्षाकृत अच्छी सुरक्षा दे।
Pay Wall
पे-वॉल लगाने की ज़रूरत वाली सेवाएँ सीमित हैं, इसलिए इसे छोड़ता हूँ।
HTTP कैश
मुझे थोड़ा संदेह था कि इस लेख में इसे शामिल करना चाहिए या नहीं, लेकिन फिर भी शामिल कर लिया।
CDN कैश के ज़रिए Origin तक पहुँचने वाले अनुरोधों की संख्या कम करने की बात करें, तो GET आदि के लिए यह उपयोगी होगा। लेकिन मुझे लगता है कि अब तक लगभग हर जगह इसे लागू किया जा चुका है।
इसे मुख्य रूप से सुरक्षा उपाय के तौर पर न देखें। उपयोगकर्ता अनुभव बेहतर बनाने और त्रुटि वाले जवाब लौटाने पर होने वाले ट्रैफ़िक के उछाल से बचने के लिए यह उपयोगी है। इसे ऐप पर असर डाले बिना प्रदर्शन बेहतर करने के नज़रिए से इस्तेमाल करना बेहतर होगा।
दर सीमित करना
हर सेवा में key अलग हो सकती है, इसलिए लागू करने के नियम ठीक से जाँच लेना बेहतर होगा। कम-से-कम Nginx के मामले में, कुल ट्रैफ़िक, हर URI, हर IP के आधार पर या इनके संयोजन से भी दर सीमित की जा सकती है। DoS से बचाव के लिहाज़ से यह उपयोगी है।
तो फिर क्या करें?
मुझे लगता है कि अलग-अलग लेयर पर बाँटकर और कई शर्तें मिलाकर ही इससे निपटा जा सकता है।
अभी मैं सोच रहा हूँ कि AS Number के आधार पर तीन भरोसेमंद क्लाउड प्रदाताओं और हर कंपनी के सोशल मीडिया आदि के क्रॉलर को अनुमति-सूची में रखा जाए, और बाकी के लिए नियम थोड़े सख्त किए जाएँ।
हमलावरों के कुछ बुनियादी पैटर्न में ऐसे अनुरोध शामिल हैं जो निश्चित रूप से संदिग्ध हैं:
वे IP पते जो
.envआदि को स्कैन करते हैंवे जो
googlebotहोने का दावा करते हैं, लेकिन स्पष्ट रूप से संदिग्ध हैंवे जो
POST/PUTआदि के ज़रिए नामुमकिन अनुरोध भेजते हैंवे जो
/loginजैसे रास्तों या सत्र बनाने वाले पथों पर बेतुके अनुरोध भेजते हैं
ऐसे मामलों में शायद सीधे ब्लॉक कर देना ही ठीक है। सच कहूँ तो, सस्ते VPS का अक्सर दुरुपयोग होता है, इसलिए उन्हें एक साथ ब्लॉक करने का मन करता है। लेकिन मैं भी सस्ते VPS पर VPN सर्वर चलाता हूँ और उसके एग्ज़िट IP से अक्सर साइटें देखता हूँ, इसलिए सोचता हूँ कि शायद यह ज़्यादा हो जाएगा—हालाँकि कुछ सेवाओं के लिए यह ठीक हो सकता है।
इसके अलावा, हाल ही में ऑडियो डिवाइस का पता लगाकर फ़िंगरप्रिंट बनाने के तरीके की आलोचना हुई थी, लेकिन मुझे लगता है कि यह वास्तव में उपयोगी है। इसलिए अगर इसका पता न चल पाए, तो ब्लॉक करना ठीक हो सकता है। किसी न किसी दिन इसे नकली बनाने का तरीका आ जाएगा, लेकिन...
शायद भविष्य में GPU Fingerprint और Audio Finderprint जैसे तरीकों को मिलाकर उपयोगकर्ता के डिवाइस का पता लगाने के लिए इस्तेमाल किया जाएगा।