“मोबाइल साइट रीडायरेक्ट” वर्डप्रेस प्लगइन (संस्करण 1.2.1 तक और शामिल) में एक सुरक्षा कमजोरी का खुलासा हुआ है (CVE‑2025‑9884)। संक्षेप में: प्लगइन में अपर्याप्त क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) सुरक्षा का दुरुपयोग करके स्थायी (स्टोर्ड) क्रॉस-साइट स्क्रिप्टिंग (XSS) पेलोड बनाया जा सकता है। प्रशासनिक या फ्रंट-एंड संदर्भों में स्टोर्ड XSS उच्च जोखिम है: एक हमलावर जो आपकी साइट में JavaScript को स्थायी रूप से रख सकता है, किसी भी आगंतुक या प्रशासनिक उपयोगकर्ता के संदर्भ में ब्राउज़र-साइड क्रियाएँ निष्पादित कर सकता है जो संक्रमित डेटा को देखता है।.

मैं एक हांगकांग स्थित सुरक्षा पेशेवर के रूप में लिखता हूँ जिसके पास वर्डप्रेस साइटों की सुरक्षा का व्यावहारिक अनुभव है। नीचे एक व्यावहारिक मार्गदर्शिका है: जोखिम कैसे काम करता है, जोखिम का निर्धारण करने के लिए त्वरित जांच, सुरक्षित शमन कदम, सफाई और पुनर्प्राप्ति के लिए मार्गदर्शन, और दीर्घकालिक मजबूत करने के कार्य। मैं शोषण कोड या चरण-दर-चरण शोषण निर्देश प्रकाशित नहीं करूंगा; यह मार्गदर्शन रक्षकों को सुरक्षित और प्रभावी ढंग से प्रतिक्रिया देने में मदद करने के लिए है।.

TL;DR (त्वरित क्रियाएँ)

• जांचें कि क्या मोबाइल साइट रीडायरेक्ट प्लगइन स्थापित है और क्या इसका संस्करण ≤ 1.2.1 है। यदि हाँ, तो इसे कमजोर मानें।.
• यदि आप तुरंत एक निश्चित संस्करण (लेखन के समय कोई उपलब्ध नहीं) में अपडेट नहीं कर सकते हैं, तो प्लगइन को निष्क्रिय या हटा दें।.
• यदि आप एक प्रबंधित WAF या वर्चुअल पैचिंग सेवा चलाते हैं, तो इस प्लगइन के लिए ज्ञात शोषण प्रयासों को रोकने वाले नियम सक्षम करें।.
• स्थायी XSS पेलोड के लिए साइट को स्कैन करें (पोस्ट, पृष्ठ, विजेट, प्लगइन विकल्प, रीडायरेक्ट प्रविष्टियाँ, डेटाबेस फ़ील्ड)।.
• व्यवस्थापक पासवर्ड बदलें, सत्रों को रद्द करें, और व्यवस्थापकों के लिए दो-कारक प्रमाणीकरण सक्षम करें।.
• नीचे दिए गए विस्तृत containment, cleanup और hardening चेकलिस्ट का पालन करें।.

कमजोरी क्या है (साधारण अंग्रेजी)

यहाँ दो अलग-अलग समस्याएँ मिलती हैं:

• CSRF (क्रॉस-साइट अनुरोध धोखाधड़ी): प्लगइन ऐसी क्रियाएँ उजागर करता है जिनमें उचित एंटी-CSRF सुरक्षा की कमी है (उदाहरण के लिए, कोई nonce या गायब क्षमता जांच नहीं), जिससे एक हमलावर एक प्रमाणित उपयोगकर्ता को अनचाही अनुरोध करने के लिए धोखा दे सकता है।.
• स्टोर्ड XSS (स्थायी क्रॉस-साइट स्क्रिप्टिंग): हमलावर-नियंत्रित JavaScript या HTML साइट डेटाबेस में संग्रहीत होता है और जब अन्य उपयोगकर्ता उन पृष्ठों या प्रशासनिक स्क्रीन पर जाते हैं जो उस डेटा को प्रदर्शित करते हैं, तो निष्पादित होता है।.

रिपोर्ट की गई श्रृंखला है CSRF → स्टोर्ड XSS: एक हमलावर प्लगइन को दुर्भावनापूर्ण इनपुट को स्थायी रूप से संग्रहीत करने का कारण बना सकता है। वह इनपुट बाद में देखने पर निष्पादित होता है, संभावित रूप से हमलावर को प्रशासनिक क्रियाओं तक ब्राउज़र-स्तरीय पहुंच देने या साइट आगंतुकों को प्रभावित करने की क्षमता प्रदान करता है।.

कौन जोखिम में है

• कोई भी वर्डप्रेस साइट जिसमें मोबाइल साइट रीडायरेक्ट संस्करण 1.2.1 या उससे पहले स्थापित है।.
• ऐसी साइटें जिनमें अक्सर सक्रिय व्यवस्थापक नहीं होते — स्टोर्ड XSS अभी भी फ्रंट-एंड आगंतुकों को प्रभावित कर सकता है।.
• कई उपयोगकर्ताओं, ईकॉमर्स, या संवेदनशील ग्राहक डेटा वाली साइटें — प्रभाव और तात्कालिकता अधिक होती है।.

यह पुष्टि करने के लिए कि क्या आप प्रभावित हैं (सुरक्षित जांच)

1. प्लगइन सूची

   डैशबोर्ड → प्लगइन्स → स्थापित प्लगइन्स। यदि “मोबाइल साइट रीडायरेक्ट” मौजूद है और स्थापित संस्करण 1.2.1 (या उससे कम) है, तो इसे असुरक्षित मानें।.

2. फ़ाइल प्रणाली जांच (WP‑CLI या SFTP)

   जांचें /wp-content/plugins/mobile-site-redirect/ (नाम भिन्न हो सकता है)। संस्करण पंक्ति के लिए प्लगइन रीडमी या मुख्य प्लगइन फ़ाइल हेडर की जांच करें। निरीक्षण करते समय प्लगइन PHP को निष्पादित न करें।.

3. संदिग्ध प्रविष्टियों के लिए डेटाबेस की खोज करें (पढ़ने के लिए केवल)

   wp_posts, wp_options, widget_* तालिकाओं और किसी भी प्लगइन-विशिष्ट विकल्प पंक्तियों में इनलाइन टैग या एन्कोडेड जावास्क्रिप्ट के लिए देखें। संपादन से पहले DB की एक प्रति को स्टेजिंग सिस्टम पर निर्यात करना पसंद करें, और उत्पादन पर पढ़ने के लिए केवल क्वेरी का उपयोग करें।.

4. लॉग और ट्रैफ़िक

   संदिग्ध POST अनुरोधों के लिए सर्वर एक्सेस लॉग की जांच करें जो प्लगइन प्रशासन अंत बिंदुओं पर या अपरिचित IP से बार-बार अनुरोध कर रहे हैं। संदिग्ध POST से ठीक पहले अजीब डोमेन की ओर इशारा करने वाले बाहरी संदर्भों की तलाश करें।.

यदि आप प्लगइन विकल्पों से संबंधित अप्रत्याशित इनलाइन जावास्क्रिप्ट या रीडायरेक्ट सेटिंग्स पाते हैं, तो साइट को संभावित रूप से समझौता किया गया मानें और नीचे दिए गए कंटेनमेंट कदम शुरू करें।.

तात्कालिक शमन (अभी क्या करना है, सुरक्षित रूप से)

यदि प्लगइन स्थापित है और असुरक्षित है:

1. साइट को रखरखाव मोड में डालें (वैकल्पिक लेकिन आगंतुकों के लिए जोखिम को कम करता है)।.
2. प्रशासन डैशबोर्ड से तुरंत प्लगइन को निष्क्रिय करें: डैशबोर्ड → प्लगइन्स → “मोबाइल साइट रीडायरेक्ट” को निष्क्रिय करें। यदि प्रशासन UI अनुपलब्ध है, तो SFTP/SSH के माध्यम से प्लगइन फ़ोल्डर का नाम बदलें (जैसे, mobile-site-redirect → mobile-site-redirect.disabled)।.
3. यदि आप WAF/वर्चुअल पैचिंग सेवा का उपयोग करते हैं, तो उन नियमों को सक्षम करें या लागू करें जो इस प्लगइन को लक्षित करने वाले शोषण पैटर्न को अवरुद्ध करते हैं।.
4. सभी व्यवस्थापक पासवर्ड को बदलें और सक्रिय सत्रों को रद्द करें: उपयोगकर्ता → सभी उपयोगकर्ता → प्रत्येक व्यवस्थापक को संपादित करें → सभी सत्रों से लॉग आउट करें, या उपयोगकर्ता मेटा में session_tokens को साफ करें।.
5. सभी व्यवस्थापक खातों के लिए तुरंत दो-कारक प्रमाणीकरण (2FA) सक्षम करें।.
6. मरम्मत करने से पहले फोरेंसिक विश्लेषण के लिए पूरे साइट (फाइलें + डेटाबेस) का बैकअप एक अलग स्थान पर लें।.
7. प्रशासन अंत बिंदुओं के लिए निगरानी और लॉगिंग बढ़ाएं और जहां संभव हो फ़ाइल अखंडता निगरानी सक्षम करें।.

यदि आप साइट को ऑफ़लाइन नहीं ले जा सकते हैं, तो WAF नियमों को सक्षम करना प्राथमिक तात्कालिक कार्रवाई है क्योंकि यह कार्यक्षमता को तोड़े बिना शोषण को अवरुद्ध कर सकता है। यदि कोई WAF उपलब्ध नहीं है, तो प्लगइन को निष्क्रिय करना सबसे सुरक्षित तात्कालिक कार्रवाई है।.

कंटेनमेंट और सफाई चेकलिस्ट (विस्तृत)

1. अलग करें और बैकअप लें

   फ़ाइलों और DB का पूर्ण बैकअप सुरक्षित स्थान पर लें। यदि संभव हो, तो विश्लेषण के लिए साइट को एक स्टेजिंग वातावरण में क्लोन करें।.

2. प्लगइन को निष्क्रिय/हटाएं

   जब तक आप सफाई की पुष्टि नहीं कर लेते या विक्रेता सुरक्षित अपडेट प्रदान नहीं करता, तब तक कमजोर प्लगइन को निष्क्रिय रखें।.

3. स्थायी XSS के लिए स्कैन करें

   संदिग्ध पेलोड के लिए डेटाबेस की खोज करें। ऑडिट के लिए उदाहरण पढ़ने के लिए केवल क्वेरी (यदि संभव हो तो एक प्रति पर चलाएं):

   • SELECT * FROM wp_options WHERE option_value LIKE ‘%<script%’;
   • SELECT * FROM wp_posts WHERE post_content LIKE ‘%<script%’;
   • Check widget tables and plugin‑specific tables for encoded scripts (%3Cscript%3E).

   बैकअप लेने से पहले लाइव DB पर विनाशकारी अपडेट न करें।.

4. इंजेक्टेड सामग्री को हटा दें

   प्रभावित DB पंक्तियों को साफ करें (स्क्रिप्ट टैग और संदिग्ध विशेषताओं को हटा दें)। यदि परिवर्तन व्यापक हैं, तो समझौते से पहले लिए गए एक साफ बैकअप से पुनर्स्थापित करें। यदि पुनर्स्थापित कर रहे हैं, तो सुनिश्चित करें कि कमजोर प्लगइन को हटाया या पैच किया गया है, इससे पहले कि साइट को उपयोगकर्ताओं से फिर से जोड़ा जाए।.

5. फ़ाइलें साफ करें

   हाल ही में संशोधित फ़ाइलों की पहचान करने के लिए फ़ाइल अखंडता निगरानी का उपयोग करें। विश्वसनीय स्रोतों से ताजा प्रतियों के साथ कोर WP फ़ाइलों और प्लगइन फ़ाइलों को बदलें। अपलोड और लिखने योग्य निर्देशिकाओं में वेबशेल और अपरिचित PHP फ़ाइलों की खोज करें।.

6. रहस्यों को घुमाएं और सत्रों को रद्द करें

   व्यवस्थापक और उच्च-विशेषाधिकार पासवर्ड बदलें। साइट पर संग्रहीत API कुंजियाँ, OAuth टोकन, और तीसरे पक्ष के क्रेडेंशियल्स को रद्द करें। सभी उपयोगकर्ताओं को मजबूर लॉगआउट करें (उपयोगकर्ता मेटा में session_tokens को साफ करें)।.

7. बैकडोर के लिए जांचें

   क्रोन जॉब्स, अनुसूचित क्रियाएँ, नए व्यवस्थापक उपयोगकर्ता, और अनधिकृत .htaccess या nginx कॉन्फ़िगरेशन परिवर्तनों (रीडायरेक्ट या रीलेखनों) की तलाश करें।.

8. सफाई के बाद हार्डनिंग

   2FA सक्षम करें, न्यूनतम विशेषाधिकार लागू करें, wp-config.php में फ़ाइल संपादन को DISALLOW_FILE_EDIT सेट करके अक्षम करें, और लॉगिंग और नियमित मैलवेयर स्कैनिंग लागू करें।.

9. निगरानी करें

   पुनः-इंजेक्शन प्रयासों और संदिग्ध एंडपॉइंट्स पर ट्रैफ़िक के लिए लॉग की निगरानी करते रहें। असफल लॉगिन प्रयासों और असामान्य पहुँच पैटर्न की समीक्षा करें।.

यदि सफाई जटिल है या आप गहरे समझौते (सर्वर क्रेडेंशियल्स, स्थायी बैकडोर) का संदेह करते हैं, तो एक पेशेवर घटना प्रतिक्रिया प्रदाता या आपकी होस्टिंग सुरक्षा टीम से संपर्क करें।.

पहचान: शोषण के संकेत

• सामग्री, विजेट या प्लगइन विकल्प फ़ील्ड में अप्रत्याशित इनलाइन जावास्क्रिप्ट।.
• नए या संशोधित व्यवस्थापक उपयोगकर्ता जिन्हें आपने नहीं बनाया।.
• रीडायरेक्ट विकल्पों, डोमेन सेटिंग्स या कस्टम HTML क्षेत्रों में अस्पष्ट परिवर्तन।.
• स्पैमी फ्रंटेंड सामग्री, SEO स्पैम, या मास-रीडायरेक्ट व्यवहार।.
• संदिग्ध डोमेन के लिए आउटबाउंड कनेक्शन या इंजेक्टेड जावास्क्रिप्ट जो क्रॉस-डोमेन अनुरोध कर रहा है।.
• प्लगइन एंडपॉइंट्स पर लॉग में संदिग्ध POST अनुरोध (विशेष रूप से जो रेफरर की कमी या अजीब उपयोगकर्ता-एजेंट के साथ हैं)।.
• CPU उपयोग में वृद्धि या आगंतुकों को वितरित क्रिप्टोमाइनिंग ट्रैफ़िक।.

यदि आप इनका अवलोकन करते हैं, तो मान लें कि स्टोर किया गया XSS शोषित किया गया है और containment और cleanup के साथ आगे बढ़ें।.

CSRF + स्टोर किया गया XSS विशेष रूप से खतरनाक क्यों है

CSRF एक हमलावर को एक प्रमाणित उपयोगकर्ता को एक क्रिया करने के लिए मजबूर करने की अनुमति देता है; स्टोर किया गया XSS हमलावर-नियंत्रित जावास्क्रिप्ट को आगंतुकों के ब्राउज़रों में चलाने की अनुमति देता है। जब संयुक्त किया जाता है, तो एक हमलावर बिना सीधे क्रेडेंशियल चुराए स्थायी स्क्रिप्ट लगा सकता है। यदि वह स्क्रिप्ट एक व्यवस्थापक संदर्भ में निष्पादित होती है, तो इसका उपयोग व्यवस्थापक क्रियाएँ करने, सत्र टोकन निकालने, खाते बनाने या अतिरिक्त बैकडोर स्थापित करने के लिए किया जा सकता है। कैस्केड प्रभाव अन्यथा मध्यम दिखने वाली भेद्यता को पूर्ण साइट समझौते में तेजी से बढ़ा सकता है।.

प्रतिक्रिया को प्राथमिकता देने का तरीका (जोखिम ट्रायज)

1. क्या प्लगइन स्थापित और सक्रिय है? यदि हाँ → तात्कालिक कार्रवाई (निष्क्रिय करें / आभासी पैच)।.
2. क्या DB या फ़ाइलों में स्टोर किया गया XSS के संकेत हैं? यदि हाँ → इसे घटना के रूप में मानें और सफाई चेकलिस्ट का पालन करें।.
3. क्या आपकी साइट सार्वजनिक रूप से कई आगंतुकों या ईकॉमर्स के साथ है? उच्च प्राथमिकता — स्टोर किया गया XSS ग्राहकों और डेटा को जल्दी प्रभावित कर सकता है।.

व्यावहारिक हार्डनिंग सिफारिशें (रोकथाम)

• WordPress कोर, थीम और प्लगइन्स को अद्यतित रखें।.
• प्रतिष्ठित स्रोतों से प्लगइन स्थापित करें और नियमित रूप से स्थापित प्लगइनों का ऑडिट करें।.
• विशेषाधिकार प्राप्त उपयोगकर्ताओं के लिए मजबूत व्यवस्थापक पासवर्ड और 2FA लागू करें।.
• न्यूनतम विशेषाधिकार का उपयोग करें — व्यवस्थापक खातों को सीमित करें।.
• XSS प्रभाव को कम करने के लिए सामग्री सुरक्षा नीति (CSP) सक्षम करें; एक सही तरीके से कॉन्फ़िगर की गई CSP इनलाइन स्क्रिप्ट को चलने से रोक सकती है।.
• उपयुक्त स्थानों पर कुकीज़ को HttpOnly और SameSite के रूप में सेट करें।.
• wp-config.php में फ़ाइल संपादन अक्षम करें: define(‘DISALLOW_FILE_EDIT’, true);
• अतिरिक्त स्तरित रक्षा के लिए एक WAF और नियमित मैलवेयर स्कैनिंग लागू करें।.
• लॉगिंग और निगरानी सक्षम करें: HTTP एक्सेस लॉग, प्रमाणीकरण लॉग, और फ़ाइल अखंडता जांच।.

डेवलपर मार्गदर्शन (प्लगइन/थीम रखरखाव करने वालों के लिए)

• प्रशासनिक क्रियाओं के लिए क्षमता जांच लागू करें: current_user_can() का उपयोग करें।.
• डेटा बदलने वाले फ़ॉर्म और क्रियाओं के लिए नॉनसेस का उपयोग करें और उन्हें wp_verify_nonce() के साथ सत्यापित करें।.
• उचित वर्डप्रेस फ़ंक्शंस (sanitize_text_field, esc_url_raw, wp_kses_post जहाँ उपयुक्त हो) के साथ इनपुट को साफ करें।.
• सामग्री को रेंडर करते समय संदर्भ के अनुसार आउटपुट को एस्केप करें (esc_attr, esc_html, esc_js)।.
• बिना एस्केप किए प्रशासनिक पृष्ठों में बाद में रेंडर किए जाने वाले विकल्पों में अस्वच्छ HTML को स्टोर करने से बचें।.
• उन प्रशासन-प्रारंभित एंडपॉइंट्स को सीमित करें जो उपयोगकर्ता की मंशा की पुष्टि किए बिना POST स्वीकार करते हैं।.
• उस कोड के लिए सुरक्षा समीक्षाओं और ऑडिट पर विचार करें जो दूरस्थ कॉन्फ़िगरेशन की अनुमति देता है (रीडायरेक्ट सूचियाँ, दूरस्थ URLs, HTML स्निपेट)।.

हितधारकों को क्या संप्रेषित करना है

• पारदर्शी लेकिन मापी हुई रहें: प्लगइन की कमजोरियों, प्रभावित संस्करणों, और उठाए गए कदमों (प्लगइन निष्क्रियता, स्कैन, निगरानी) का वर्णन करें।.
• यदि साइट PII या भुगतान संभालती है और आपको उल्लंघन का संदेह है, तो अपने क्षेत्राधिकार में लागू उल्लंघन सूचना नियमों का पालन करें।.
• सफाई और पुनर्स्थापन के लिए समयसीमा पर नियमित अपडेट प्रदान करें।.

घटना प्रतिक्रिया प्लेबुक (संक्षिप्त चेकलिस्ट)

1. ट्रायेज: कमजोर प्लगइन की उपस्थिति और शोषण के संकेतों की पुष्टि करें।.
2. कंटेन: प्लगइन को निष्क्रिय करें या आभासी पैच लागू करें, वातावरण को अलग करें।.
3. साक्ष्य को संरक्षित करें: फोरेंसिक्स के लिए पूर्ण बैकअप और लॉग की प्रतियाँ लें।.
4. समाप्त करें: फ़ाइलों और DB से दुर्भावनापूर्ण कोड को हटा दें; बैकडोर और अनधिकृत प्रशासनिक उपयोगकर्ताओं को हटा दें।.
5. पुनर्प्राप्त करें: साफ बैकअप को पुनर्स्थापित करें, अपडेट को फिर से लागू करें, वातावरण को मजबूत करें।.
6. घटना के बाद: मूल कारण विश्लेषण करें और गायब नियंत्रणों को लागू करें।.

निगरानी और दीर्घकालिक पहचान

• स्वचालित दैनिक मैलवेयर स्कैन और फ़ाइल अखंडता जांच कॉन्फ़िगर करें।.
• प्लगइन प्रशासन अंत बिंदुओं से संबंधित संदिग्ध POST पैटर्न या बाहरी संदर्भों के लिए HTTP एक्सेस लॉग की निगरानी करें।.
• सफाई के बाद पुनः-इंजेक्शन के प्रयासों पर नज़र रखें - हमलावर अक्सर बार-बार प्रयास करते हैं।.
• एक घटना लॉग बनाए रखें: पहचान की तारीख/समय, उठाए गए कदम, और परिणाम।.

अक्सर पूछे जाने वाले प्रश्न (FAQ)

प्रश्न: क्या मुझे प्लगइन को स्थायी रूप से हटाना होगा?
उत्तर: जरूरी नहीं। यदि विक्रेता एक पैच किया हुआ संस्करण जारी करता है, तो अपग्रेड करें और पुनः सक्षम करने से पहले सुधार की पुष्टि करें। यदि कोई सुधार उपलब्ध नहीं है, तो प्लगइन को हटा दें या एक बनाए रखा विकल्प से बदलें। यदि हटाने में देरी होती है, तो सुनिश्चित करें कि मजबूत निगरानी और सुरक्षा नियम लागू हैं।.

प्रश्न: क्या वर्चुअल पैचिंग (WAF) पर्याप्त है?
उत्तर: वर्चुअल पैचिंग एक शक्तिशाली अस्थायी उपाय है जो तत्काल जोखिम को कम करता है। दीर्घकालिक, आपको पैच किए गए और सक्रिय रूप से बनाए रखे गए प्लगइनों का उपयोग करना चाहिए और केवल वर्चुअल पैचिंग पर निर्भर नहीं रहना चाहिए।.

प्रश्न: क्या मुझे इसे अपने होस्टिंग प्रदाता को रिपोर्ट करना चाहिए?
उत्तर: हाँ - होस्ट सर्वर-स्तरीय स्कैनिंग, स्नैपशॉट, और साफ बैकअप से पुनर्स्थापना में मदद कर सकते हैं, और सर्वर-साइड फोरेंसिक जांच में सहायता कर सकते हैं।.

CVE और स्कोरिंग संदर्भ

इस भेद्यता को CVE-2025-9884 सौंपा गया है। भेद्यता स्कोर (CVSS) तिरछी के लिए उपयोगी होते हैं, लेकिन साइट संदर्भ (उपयोगकर्ताओं की भूमिकाएँ, ट्रैफ़िक, व्यावसायिक कार्य) वास्तविक तात्कालिकता निर्धारित करता है। प्रशासनिक पृष्ठों में चलने वाला स्टोर किया गया XSS विशेष रूप से प्रभावशाली होता है और इसे विशेषाधिकार प्राप्त उपयोगकर्ताओं वाली साइटों के लिए उच्च प्राथमिकता के रूप में माना जाना चाहिए।.

अंतिम विचार

CSRF→स्टोर किया गया XSS श्रृंखलाएँ दिखाती हैं कि क्यों स्तरित रक्षा आवश्यक हैं। कोई एक नियंत्रण हर समस्या को रोकता नहीं है, लेकिन सुरक्षित विकास प्रथाओं, परिचालन स्वच्छता (समय पर अपडेट, न्यूनतम विशेषाधिकार, 2FA), और स्तरित सुरक्षा (WAF/वर्चुअल पैचिंग, स्कैनिंग, निगरानी) को मिलाकर समझौते की संभावना और इसके प्रभाव को काफी कम किया जा सकता है।.

साइट मालिकों के लिए तत्काल चेकलिस्ट:

• सक्रिय प्लगइनों का ऑडिट करें और किसी भी अनावश्यक चीज़ को हटा दें।.
• जहाँ संभव हो, सुरक्षात्मक अनुरोध फ़िल्टरिंग (WAF नियम) लागू करें।.
• 2FA सक्षम करें और प्रशासनिक खातों को न्यूनतम करें।.
• बैकअप बनाए रखें और नियमित रूप से पुनर्स्थापनों का परीक्षण करें।.

यदि आपको घटना प्रतिक्रिया या फोरेंसिक विश्लेषण के लिए तीसरे पक्ष की सहायता की आवश्यकता है, तो अनुभवी प्रदाताओं का चयन करें और संलग्न होने से पहले दायरा, साक्ष्य संरक्षण, और गोपनीयता को स्पष्ट करें।.