हमले के मानचित्र पर धब्बा: अपने सर्वर पर उसका क्या करें

हमले के मानचित्र पर एक देश के ऊपर घना धब्बा है, और «उसे पूरा ही प्रतिबंधित कर दो» वाला नियम अपने आप सुझाई देता है। उससे लगभग कुछ नहीं मिलेगा: निकास देश बदलने में हमलावर के कुछ मिनट लगते हैं, जबकि प्रतिबंध के नीचे आपके अपने आगंतुक आएँगे और यात्रा में आप स्वयं। इससे भी बुरा यह कि एक ही क्लाउड से आने वाला दिखाई देने वाला क्रॉलर अवरोध के बाद घरेलू पतों पर चला जाएगा और लोगों से अलग पहचाना ही नहीं जाएगा।

नीचे पाँच चरण हैं जो उसी सर्वर पर वास्तव में परिणाम देते हैं: स्कैनरों को काटना, गति सीमित करना, आवश्यक को न काटना और, यदि फिर भी ज़रूरत हो, सही ढंग से रोकना। यह सब एक ही बैठक में जाँचा और लगाया जा सकता है।

चरण 1. देखें कि धब्बा असल में कौन बना रहा है

पहले अनुरोधों का लॉग खोजें। कई साइटों वाले सर्वर पर access.log अकसर खाली रहता है, जबकि प्रविष्टियाँ संबंधित वर्चुअल होस्ट के लॉग में जाती हैं:

sudo ls -lS /var/log/apache2/*access*.log /var/log/apache2/*requests*.log 2>/dev/null

आगे के सभी आदेशों में वही फ़ाइल रखें जो उस सूची में सबसे ऊपर आई। पहले दिन भर के अग्रणी पते, फिर यह कि सबसे ऊपर वाला माँग क्या रहा है:

sudo awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20
sudo grep '^203\.0\.113\.' /var/log/apache2/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

दूसरा आदेश मुख्य प्रश्न का उत्तर देता है। यदि परिणाम में आपकी ही साइट के दर्जनों अलग-अलग पृष्ठ हैं, तो यह सामग्री संग्राहक है: हानिरहित, और इतना पर्याप्त है कि उसे आगंतुक न गिना जाए। यदि वहाँ /wp-login.php, /.env, /phpmyadmin और वह सब है जो आपके पास है ही नहीं, तो यह स्कैनर है, और उससे चरण 2 निपटता है। nginx में लॉग /var/log/nginx/ में होते हैं, क्षेत्र वही हैं।

चरण 2. उन अनुरोधों पर jail जो आपके पास है ही नहीं

अनुरोध का पथ गढ़ा नहीं जा सकता — पते और User-Agent के विपरीत वही तो मंशा है। फ़िल्टर /etc/fail2ban/filter.d/web-probes.local:

[Definition]
failregex = ^<HOST> .* "(GET|POST|HEAD) /(wp-login\.php|wp-admin|xmlrpc\.php|\.env|\.git/|phpmyadmin|administrator/)
ignoreregex =

Jail /etc/fail2ban/jail.d/web-probes.local:

[web-probes]
enabled  = true
port     = http,https
filter   = web-probes
logpath  = /var/log/apache2/*access.log
maxretry = 1
findtime = 1h
bantime  = 1d

यहाँ maxretry = 1 उचित है: किसी और के प्रशासन पृष्ठ पर संयोग से कोई नहीं पहुँचता। इसे लागू करें और सुनिश्चित करें कि फ़िल्टर आपके अपने लॉग की पंक्तियाँ पकड़ रहा है:

sudo fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/web-probes.local
sudo systemctl reload fail2ban && sudo fail2ban-client status web-probes

चरण 3. गति सीमित करें

स्कैनर और क्रॉलर अपनी रफ़्तार से पकड़ में आ जाते हैं, चाहे वे किसी भी देश से हों। एक ही पते से प्रति मिनट तीस पृष्ठ वह सीमा है जो सूची पलटते व्यक्ति को नहीं छूती:

[http-flood]
enabled  = true
port     = http,https
filter   = apache-overflows
logpath  = /var/log/apache2/site_access.log
maxretry = 30
findtime = 60
bantime  = 1h

निर्णायक बात यह है कि logpath में कौन सा लॉग लिखा है। यदि उस पैटर्न के नीचे स्वयं नियंत्रण पैनल या प्रशासन भाग का लॉग आ गया, तो आप स्वयं को ही रोक लेंगे: वहाँ का एक ही पृष्ठ शैलियों और स्क्रिप्टों के लिए दर्जन भर अनुरोध खींचता है, और तीस दो क्लिक में पूरे हो जाते हैं। इसीलिए पैनल को अलग लॉग फ़ाइल दी जाती है जो jail के पैटर्न से मेल न खाए, और स्थिर फ़ाइलों को लंबी कैश अवधि, ताकि ब्राउज़र हर पृष्ठ परिवर्तन पर उन्हें दोबारा न माँगे। यदि फिर भी ऐसा हो गया तो लक्षण: HTML आ जाता है, प्रस्तुति नहीं आती, पृष्ठ अटक जाता है। अवरोध हटाना:

sudo fail2ban-client set http-flood unbanip 203.0.113.10

चरण 4. उसकी रक्षा करें जिसे काटना नहीं चाहिए

अवरोध चालू करने से पहले अपवाद लिख लें — अन्यथा उनके नीचे सबसे पहले आवश्यक ही आएगा:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24 66.249.64.0/19

इस पंक्ति में अनिवार्य रूप से क्या होना चाहिए और क्यों:

• आपका अपना पता या कार्यालय का उपजाल। सर्वर तक पहुँच खोने का सबसे आम कारण हमला नहीं, अपना ही नियम होता है;
• परास 66.249.64.0/19। Google का खोज रोबोट User-Agent से पहचाना जाता है, पर उसका वह हिस्सा जो JavaScript चलाता है, सामान्य Chrome/Linux बनकर आता है और अपना नाम नहीं बताता। «डेटा केंद्रों से आने वाला ट्रैफ़िक रोको» जैसा कोई भी नियम ठीक उसी पर चोट करता है, जिसके बाद पृष्ठ चुपचाप अनुक्रमणिका से बाहर हो जाते हैं। संदिग्ध पते की जाँच उलटे प्रश्न से हो सकती है: dig -x 66.249.66.1 +short को googlebot.com क्षेत्र का नाम लौटाना चाहिए;
• भुगतान सूचनाओं के पते। भुगतान प्रणालियों के वेबहुक AWS और Azure सर्वरों से आते हैं। यदि आप इन क्लाउडों को पूरा बंद कर देंगे, तो भुगतान की पुष्टियाँ आनी बंद हो जाएँगी, और यह आपको तब पता चलेगा जब ग्राहक लिखेगा कि पैसे कट गए पर पहुँच नहीं मिली। परास आपके भुगतान प्रदाता के दस्तावेज़ों से लिए जाते हैं।

चरण 5. यदि अवरोध फिर भी चाहिए — उपजाल रोकें, देश नहीं

एक ही नेटवर्क से आता स्थिर घनापन, जो कई दिन टिकता है और एक जैसे अनुरोधों के साथ आता है, एक ही निष्पादक है जो सूची के क्रम से चल रहा है। ऐसे मामले को लक्षित ढंग से और समयबद्ध रूप से रोका जाता है:

sudo ufw deny from 198.51.100.0/22 to any
sudo ufw status numbered

दूसरे आदेश से नियम का क्रमांक याद कर लें: अवरोध बाद में उसी के ज़रिए हटाना होगा, sudo ufw delete <क्रमांक>। अपने साथ एक अवधि तय करें — मान लीजिए एक माह — और हटाने की तारीख कैलेंडर में डालें। «हमेशा के लिए» लगाए गए नियम एक साल बाद ऐसी सूची बन जाते हैं जिसे छूने की हिम्मत कोई नहीं करता, क्योंकि किसी को याद नहीं रहता कि वे पते वहाँ किस कारण पहुँचे थे।

कौन सा उपजाल रोकना है, यह पहले चरण के पते से पता चलता है: whois 198.51.100.17 | grep -iE 'route|cidr|netname'।

इन पाँच चरणों के बाद क्या बदलता है

स्कैनर मूल के अनुसार नहीं, मंशा के अनुसार काटे जाते हैं और पहले ही अनुरोध पर पकड़ में आ जाते हैं। क्रॉलर गति की सीमा से टकराते हैं। खोज रोबोट और भुगतान सूचनाएँ पहले की तरह आती रहती हैं। जो एक चौड़ा अवरोध बचा है वह लक्षित है, ज्ञात अवधि और समझ में आने वाले कारण के साथ।

मानचित्र इससे कहीं नहीं जाता, पर उसकी भूमिका बदल जाती है: वह देशों को बंद करने के लिए नहीं, बल्कि उस घनेपन को देख पाने और एक सप्ताह पहले से उसकी तुलना करने के लिए चाहिए। इसके लिए इतिहास चाहिए, चालू दिन का चित्र नहीं। ऐसा मानचित्र अवरोध लॉग और खुले पोर्टों की सूची के साथ कैसा दिखता है, यह नीचे दिए डेमो पृष्ठ दिखाते हैं।