वेबसाइट सुरक्षा: साइटें कैसे हैक होती हैं और इसे कैसे रोका जाए

छोटी साइटें क्यों भी हमले का शिकार होती हैं

आइए उस विश्वास के साथ शुरू करें जो हम लगभग हर पहले बैठक में सुनते हैं: "कौन हमारे साथ परेशान होगा? हमारे पास पांच पृष्ठ हैं और हमें सप्ताह में तीन पूछताछ मिलती हैं।" यह उचित लगता है। यह भी ठीक वही कारण है कि ऐसे साइटें सबसे अधिक समझौता होती हैं।

कोई भी आपको नहीं चुनता। छोटे और मध्यम आकार के व्यवसायों के खिलाफ हमलों का विशाल बहुमत व्यक्तिगत नहीं होता। सॉफ़्टवेयर काम करता है: यह डोमेन और आईपी पते की सूचियों को लेता है, उन्हें एक-एक करके देखता है, और ज्ञात कमजोरियों के लिए प्रत्येक का परीक्षण करता है। बॉट को यह नहीं पता होता कि आप एक दंत चिकित्सा क्लिनिक हैं या एक सिरेमिक स्टूडियो। यह सर्वर प्रतिक्रिया में एक संस्करण स्ट्रिंग पढ़ता है, अपनी सूची की जांच करता है, और यदि कोई मेल नहीं है तो आगे बढ़ जाता है। यदि मेल है, तो यह काम पर लग जाता है।

यह एक सड़क पर चलने के समान है और कार के दरवाजों के हैंडल खींच रहा है। किसी ने आपकी कार नहीं चुनी। आपकी बस अनलॉक थी।

एक ब्रोशर साइट का क्या मूल्य है

एक हमलावर लगभग कभी भी आपको नुकसान पहुँचाना नहीं चाहताआपविशेष रूप से। एक समझौता किया गया साइट का बाजार मूल्य होता है, और यह एक साथ कई चीजों से आता है:

• लिंक इक्विटी।कैसिनो, ऋण, या फार्मेसियों के बारे में छिपे हुए लिंक या पूरे छिपे हुए अनुभाग आपके पृष्ठों में चुपचाप इंजेक्ट किए जाते हैं। आप उन्हें नहीं देखते। सर्च इंजन उन्हें देखते हैं।
• ट्रैफ़िक। आपके विज़िटर कहीं और रीडायरेक्ट हो जाते हैं — लेकिन सभी नहीं। अक्सर केवल मोबाइल उपयोगकर्ता, केवल वे जो खोज से आते हैं, और केवल प्रति दिन प्रति व्यक्ति एक बार। यही कारण है कि आप महीनों तक अपने लैपटॉप से अपने स्वयं के साइट पर जा सकते हैं और कुछ भी नहीं देख सकते।
• सर्वर संसाधन। आपकी होस्टिंग स्पैम भेजने, माइनिंग करने, या अन्य साइटों पर हमले करने के लिए एक नोड बन जाती है।
• डेटा। पूछताछ, फोन नंबर, पते, और ईमेल का एक डेटाबेस एक उत्पाद है जिसके खरीदार होते हैं। भले ही आपके पास "सिर्फ एक संपर्क फ़ॉर्म" ही हो।
• जबरन वसूली। फ़ाइलें एन्क्रिप्ट या हटा दी जाती हैं, और आपको उनकी वापसी के लिए भुगतान करने के लिए आमंत्रित किया जाता है।

जिससे यह निष्कर्ष निकलता है कि यह पूरे विषय को कैसे महसूस कराता है: वेबसाइट सुरक्षा किसी जीनियस को हूडी में बचाने के बारे में नहीं है। यह स्वच्छता है जो आपको आसान-लक्ष्य पूल से बाहर ले जाती है। एक बॉट एक अच्छी तरह से रखी गई साइट पर समय नहीं बिताएगा जबकि एक हजार उपेक्षित साइटें बगल में बैठी हैं।

स्वामियों को आमतौर पर कैसे पता चलता है

लक्षण लगभग कभी भी आपसे नहीं आते। आपका होस्ट संदिग्ध गतिविधि के बारे में ईमेल करता है। Google Search Console एक चेतावनी देता है। एक ग्राहक कॉल करता है और कहता है कि उनका ब्राउज़र उन पर चिल्ला रहा है। कंपनी का ईमेल अचानक सभी के स्पैम फ़ोल्डर में पहुँच जाता है। खोज ट्रैफ़िक बिना किसी स्पष्टीकरण के गिरता है। यदि इनमें से कोई भी हुआ है, तो आप देर से पता चले — लेकिन देर होना बहुत देर होने के समान नहीं है।

साइटें वास्तव में कैसे समझौता की जाती हैं

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

पुराना CMS, और प्लगइन्स सबसे ऊपर

यह runaway विजेता है। WordPress, Joomla, OpenCart — प्लेटफ़ॉर्म स्वयं स्वाभाविक रूप से लीक नहीं होते। पारिस्थितिकी ही समस्या है: 2021 में अंतिम बार अपडेट किया गया एक गैलरी प्लगइन, एक थीम जो एक मार्केटप्लेस पर खरीदी गई थी जिसका लेखक सालों पहले चला गया, एक फॉर्म मॉड्यूल जिसे एक ठेकेदार ने स्थापित किया और भूल गया।

यहाँ की मैकेनिक्स को समझें, क्योंकि ये प्रतिकूल हैं। जब एक प्लगइन में एक कमजोर बिंदु पाया जाता है, तो इसे प्रकाशित किया जाता है। यही उद्योग का काम करने का तरीका है, और यह सही है। लेकिन उस क्षण से एक दौड़ शुरू होती है: डेवलपर एक सुधार भेजता है, और स्कैनिंग बॉट्स कमजोर संस्करण का फिंगरप्रिंट कुछ घंटों के भीतर प्राप्त करते हैं। एक साइट जो साल में एक बार अपडेट होती है, उस दौड़ में बिल्कुल भी नहीं है।

कमजोर पासवर्ड, और इससे भी बुरा, पुनः उपयोग किए गए

एक पासवर्ड जैसे Admin2024!मजबूत लगता है — बड़ा अक्षर, अंक, एक विस्मयादिबोधक चिह्न। यह हर क्रैकिंग शब्दकोश में है। लेकिन यह असली नुकसान नहीं है। असली नुकसान वही पासवर्ड है जो आपके होस्टिंग पैनल, आपकी साइट के प्रशासन, आपके ईमेल, और कुछ सेवा पर है जो दो साल पहले breached हो गई थी। किसी और का लीक आपका लॉगिन बन जाता है, और तकनीकी रूप से कोई "हैकिंग" नहीं होती। हमलावर बस एक उपयोगकर्ता नाम और एक पासवर्ड टाइप करता है।

कर्मचारी लैपटॉप से चुराए गए क्रेडेंशियल्स

क्लासिक कोई संदेह नहीं करता। एक डिज़ाइनर के लैपटॉप पर फ़ाइल प्रबंधक में सहेजे गए FTP क्रेडेंशियल्स सामान्य कमोडिटी मैलवेयर द्वारा पढ़े जाते हैं। साइट को एक वैध लॉगिन के माध्यम से "हैक" किया जाता है। पहचानने का संकेत: आप सब कुछ पूरी तरह से साफ करते हैं और संक्रमण दो दिनों के भीतर वापस आ जाता है।

असुरक्षित फ़ॉर्म और खुले एंडपॉइंट्स

हर जगह जहाँ आपकी साइट बाहरी से इनपुट स्वीकार करती है - एक संपर्क फ़ॉर्म, साइट खोज, एक फ़ाइल अपलोड, एक API एंडपॉइंट - एक दरवाजा है। जब इनपुट को इसके प्रकार, आकार और सामग्री की जांच किए बिना स्वीकार किया जाता है, तो दरवाजा दोनों दिशाओं में काम करता है। फ़ाइल अपलोड विशेष डर का हकदार है: किसी को आपके सर्वर पर कुछ रखने की अनुमति देना जिसे सर्वर बाद में निष्पादित करता है, मूल रूप से चाबियाँ सौंपने के समान है।

वेब रूट में पड़े फ़ाइलें

चुपके से मारने वाला, और हम इसे लगातार पाते हैं। सार्वजनिक फ़ोल्डर में रहना: backup.zip पिछले एजेंसी से, dump.sql पूर्ण डेटाबेस के साथ, एक .git पासवर्ड के साथ पूरे प्रोजेक्ट के इतिहास को समाहित करने वाला फ़ोल्डर, एक test.php, एक info.php, एक कॉन्फ़िग कॉपी जिसका नाम है config.php.bak. इनमें से हर एक को कोई भी डाउनलोड कर सकता है जो URL का अनुमान लगाता है। और बॉट अनुमान नहीं लगाते — वे सामान्य नामों की सूचियाँ लेकर चलते हैं और उन्हें सेकंडों में चेक करते हैं।

विशेष रूप से एक शब्द .bak और .पुराना एक्सटेंशन: सर्वर उन्हें कोड के रूप में निष्पादित नहीं करता, यह उन्हें सामान्य पाठ के रूप में प्रदान करता है। इसका मतलब है कि यह आपका डेटाबेस पासवर्ड सीधे ब्राउज़र को सौंपता है।

भूल गए और परित्यक्त प्रोजेक्ट

एक उपडोमेन पर एक पुराना अभियान लैंडिंग पृष्ठ। दो साल पहले बनाया गया एक स्टेजिंग कॉपी और कभी हटाया नहीं गया। एक फोरम जिसे कोई उपयोग नहीं करता। उन्हें कभी अपडेट नहीं किया जाता क्योंकि कोई याद नहीं रखता कि वे मौजूद हैं। और वे आमतौर पर उसी होस्टिंग खाते में रहते हैं - इसलिए एक भूले हुए लैंडिंग पृष्ठ को समझौता करना आपके मुख्य साइट की फ़ाइलों को सौंप देता है। हम हर ऑडिट की शुरुआत "इस खाते में और क्या है?" से करते हैं, और उत्तर नियमित रूप से मालिक को किसी और से अधिक आश्चर्यचकित करता है।

HTTPS और SSL: अब बहस का विषय नहीं

यदि आपके पास HTTPS नहीं है, तो पढ़ना बंद करें और पहले इसे ठीक करें। 2026 में, बिना एन्क्रिप्शन वाली साइट थ्रिफ्ट नहीं है। यह एक दोष है।

एक SSL प्रमाणपत्र वास्तव में क्या करता है

बिना HTTPS के, डेटा आपके आगंतुक के ब्राउज़र और आपके सर्वर के बीच सामान्य पाठ में यात्रा करता है। उस पथ पर कोई भी व्यक्ति इसे पढ़ सकता है और इसे बदल सकता है: कैफे वाई-फाई मालिक, एक ISP, एक मध्यवर्ती नेटवर्क पर उपकरण। इसे पढ़ना पासवर्ड और फॉर्म सामग्री को पढ़ने का मतलब है। इसे बदलना मतलब है कि वे आपके पृष्ठ को फिर से लिख सकते हैं या उसमें अपने स्वयं के विज्ञापन डाल सकते हैं, और आपके आगंतुक को यकीन होगा कि यह आपसे आया है।

एक SSL प्रमाणपत्र एक साथ दो समस्याओं का समाधान करता है। यह चैनल को एन्क्रिप्ट करता है, और यह साबित करता है कि डोमेन उस व्यक्ति का है जो इसे सेवा दे रहा है। दूसरा पहले की तरह ही महत्वपूर्ण है: पहचान के बिना, एन्क्रिप्शन बेकार है, क्योंकि आप एक धोखेबाज के लिए चैनल को एन्क्रिप्ट कर सकते हैं।

वे विवरण जो प्रमाणपत्र से अधिक महत्वपूर्ण हैं

सर्टिफिकेट अब मुफ्त और स्वचालित हैं - Let's Encrypt ने सभी के लिए इस प्रश्न का समाधान कर दिया। इसलिए गलतियाँ अब "एक होना चाहिए या नहीं" के बारे में नहीं हैं। वे कॉन्फ़िगरेशन में हैं:

• रीडायरेक्ट्स। प्रत्येक HTTP अनुरोध को स्थायी रूप से HTTPS पर रीडायरेक्ट करना चाहिए। अन्यथा, पुराना संस्करण बस नए के साथ चलता रहेगा।
• मिश्रित सामग्री। पृष्ठ HTTPS के माध्यम से लोड होता है लेकिन HTTP के माध्यम से एक छवि, फ़ॉन्ट, या स्क्रिप्ट खींचता है। ब्राउज़र शिकायत करता है और ताले का चिह्न गायब हो जाता है। पुराने एनालिटिक्स स्निपेट और तृतीय-पक्ष विजेट सामान्य अपराधी होते हैं।
• स्वचालित नवीनीकरण। सर्टिफिकेट अल्पकालिक होते हैं और एक रोबोट द्वारा नवीनीकरण किया जाता है। जब रोबोट टूटता है, तो आप इसे सबसे खराब संभव दिन में ग्राहकों से सुनेंगे। समाप्ति तिथि की निगरानी करें।
• कैनोनिकल यूआरएल। HTTPS पर जाने के बाद, सुनिश्चित करें कि प्रत्येक पृष्ठ का एक पता हो, न कि www के साथ और बिना चार भिन्नताएँ।

HTTPS क्या नहीं करता

यहां एक खतरनाक गलतफहमी है। पैडलक का मतलब यह नहीं है कि साइट सुरक्षित है। इसका मतलब केवल एक चीज है: सर्वर के लिए चैनल एन्क्रिप्टेड है। एक समझौता किया गया साइट जो दुर्भावनापूर्ण कोड से भरी है, वह HTTPS पर पैडलक के साथ खुशी-खुशी सेवा करती है। फ़िशिंग साइटों के पास भी प्रमाणपत्र होते हैं - ये सभी को मुफ्त और स्वचालित रूप से जारी किए जाते हैं। HTTPS एक नींव है, छत नहीं।

उन साइटों के लिए जो पैसे का लेन-देन करती हैं, मानक बहुत अधिक है। चैनल एन्क्रिप्शन प्रवेश टिकट है; इसके बाद वेबहुक सिग्नेचर सत्यापन, आइडेम्पोटेंट ऑपरेशंस, और एक्सेस का सख्त विभाजन आता है। हमने उस मशीनरी के माध्यम से विस्तार से चलने के लिए Payora भुगतान गेटवेका उपयोग किया, जहां लेन-देन की सुरक्षा निर्माण में हर अन्य विशेषता से अधिक महत्वपूर्ण है।

सुरक्षा हेडर: वह शांत रक्षा जिसे कोई चालू नहीं करता

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

उनकी महान विशेषता यह है कि वे मुफ्त हैं, एक बार कॉन्फ़िगर किए जाते हैं, और आपके सर्वर को लोड किए बिना आगंतुक के पक्ष पर लागू होते हैं। उनकी महान समस्या यह है कि वे लगभग हर जगह डिफ़ॉल्ट रूप से अनुपस्थित होते हैं।

सामग्री-सुरक्षा-नीति (CSP)

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

एक ईमानदार चेतावनी: CSP को जल्दी करने से आपकी साइट टूट जाएगी। सही रास्ता पहले रिपोर्ट-केवल मोड है, उल्लंघनों को इकट्ठा करें, फिर कसें। एक साइट पर जिसमें दर्जनों तृतीय-पक्ष विजेट हैं, यह कई दिनों का काम है, दस मिनट नहीं।

सख्त-परिवहन-सुरक्षा (HSTS)

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

X-फ्रेम-ऑप्शंस

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

X-कंटेंट-टाइप-ऑप्शंस

एक पंक्ति, कोई कॉन्फ़िगरेशन नहीं। यह ब्राउज़र को सर्वर द्वारा घोषित फ़ाइल के प्रकार के खिलाफ अनुमान लगाने से रोकता है। इसके बिना, एक अपलोड की गई छवि, सही परिस्थितियों में, एक स्क्रिप्ट के रूप में व्याख्यायित की जा सकती है और निष्पादित की जा सकती है।

रेफरर-नीति

नियंत्रित करता है कि आपकी साइट के बारे में ब्राउज़र कौन सी जानकारी पास करता है जब एक आगंतुक क्लिक करता है। इसके बिना, पूरा पृष्ठ URL - जिसमें पासवर्ड-रीसेट टोकन या आंतरिक पहचानकर्ता जैसे पैरामीटर शामिल हैं - किसी और के एनालिटिक्स में चला जाता है। यह एक हैक नहीं है। यह एक लीक है: शांत और निरंतर।

अनुमतियाँ-नीति

आपकी साइट को स्पष्ट रूप से आवश्यकता नहीं है: कैमरा, माइक्रोफोन, भू-स्थान, सेंसर। नियम सरल है - जो भी अप्रयुक्त है, वह बंद होना चाहिए।

कोई भी सार्वजनिक ऑनलाइन स्कैनर एक मिनट में आपके हेडर को ग्रेड करेगा, और परिणाम आमतौर पर चौंकाने वाला होता है। हमारे लिए, हेडर हर प्रोजेक्ट पर बेस बिल्ड का हिस्सा हैं - विकास का हिस्सा, बाद में जोड़ा गया एक भुगतान किया गया अतिरिक्त नहीं।

अपडेट और थर्ड-पार्टी कोड: नायकत्व पर अनुशासन

सलाह उबाऊ है: चीजों को अपडेट रखें। समस्या यह है कि यह एकमात्र सलाह है जिसे हर किसी ने सुना है और लगभग कोई भी इसका पालन नहीं करता। आइए देखें कि क्यों - और इसे स्थायी बनाने के लिए कैसे।

अपडेट क्यों टाले जाते हैं

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

लेकिन गणना करें। एक टूटे हुए लेआउट का जोखिम आपको एक घंटा खर्च कराता है। एक समझौते का जोखिम आपको एक पुनर्स्थापना, एक सफाई, ग्राहकों के साथ अजीब बातचीत, और खोज रैंकिंग को वापस पाने के लिए महीनों का खर्च कराता है। दूसरा जोखिम एक क्रम का अधिक महंगा है।

बिना घबराए अपडेट कैसे करें

1. पहले बैकअप लें, बाद में नहीं।पूर्ण बैकअप: फ़ाइलें और डेटाबेस। इस चरण को कभी न छोड़ें, कोई अपवाद नहीं।
2. एक स्टेजिंग कॉपी रखें।एक अलग वातावरण, जो खोज इंजनों और बाहरी लोगों के लिए बंद है, जहाँ अपडेट लाइव होने से पहले परीक्षण किए जाते हैं। किसी भी गंभीर परियोजना पर यह वैकल्पिक नहीं है।
3. महत्वपूर्ण को नियमित से अलग करें।सुरक्षा अपडेट तुरंत लागू करें। छोटे अपडेट एक कार्यक्रम पर। प्रमुख संस्करण कूद अपने स्वयं के प्रोजेक्ट होते हैं जिनके लिए एक योजना होती है।
4. महत्वपूर्ण चीजों की जांच करें।एक फॉर्म सबमिट करें, एक भुगतान करें, एक खाते में लॉग इन करें, इसे फोन पर देखें। तीन मिनट की मैनुअल जांच हफ्तों की बचत करती है।

दूसरों के कोड का ऑडिटिंग

हर तिमाही, अपने प्लगइन सूची को खोलें और दो प्रश्न पूछें। पहला: क्या इसका उपयोग किया जाता है? एक प्लगइन जो "बस मामले में" स्थापित किया गया है, वह एक ऐसा छिद्र है जिसका कोई कार्य नहीं है। और ध्यान दें कि एक निष्क्रिय प्लगइन अभी भी फ़ाइल सिस्टम में बैठा है और अभी भी कमजोर हो सकता है - इसलिए अप्रयुक्त चीजों को हटाना चाहिए, बंद नहीं करना चाहिए।

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

और दीवार पर फ्रेम करने लायक नियम: आपकी साइट पर जितना कम तृतीय-पक्ष कोड होगा, आपका हमला सतह उतनी ही छोटी होगी। हर प्लगइन एक अजनबी है जिसे आपने चुपचाप अपने सर्वर तक पहुंच प्रदान की है।

एक्सेस और होस्टिंग स्वच्छता: कोड से बड़े लाभ

समझौते का सबसे सामान्य वास्तविक कारण एक चालाक शोषण नहीं है। यह बिखरी हुई पहुंच है। यहीं पर आदेश सबसे तेजी से बहाल होता है और लगभग बिना किसी पैसे के।

कम से कम विशेषाधिकार

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

अभी अपने व्यवस्थापक उपयोगकर्ता सूची खोलें। ऑडिट में हम नियमित रूप से उन जीवित खातों को पाते हैं जो उन लोगों के हैं जो चले गए, एक एजेंसी जिसके साथ आप एक साल पहले अलग हो गए, और एक रहस्यमय उपयोगकर्ता जिसे कहा जाता है admin2 जिसे कोई भी नहीं जानता। आखिरी वाला कोई चूक नहीं है - यह एक लक्षण है।

प्रत्येक व्यक्ति के लिए एक खाता

एक साझा व्यवस्थापकएक चैट थ्रेड में बैठे पासवर्ड के साथ लॉगिन करना मतलब है कि कोई भी जिम्मेदार नहीं है। जब कुछ होता है, लॉग कहता है "व्यवस्थापक लॉगिन हुआ", जो आपको बिल्कुल कुछ नहीं बताता। व्यक्तिगत खाते आपको दो चीजें देते हैं: यह कि किसने क्या किया इसका एक पठनीय इतिहास, और एक व्यक्ति की पहुंच को रद्द करने की क्षमता बिना पूरे कंपनी के लिए पासवर्ड बदले।

दो-कारक प्रमाणीकरण

यदि आप इस पूरे लेख में से केवल एक आइटम लागू करते हैं, तो इसे बनाएं। 2FA एक चुराए गए पासवर्ड को बेकार बना देता है। हर ब्रूट-फोर्स प्रयास और हर तीसरे पक्ष का उल्लंघन आपके खिलाफ काम करना बंद कर देता है, क्योंकि केवल पासवर्ड अब पर्याप्त नहीं है। इसे हर जगह चालू करें जहां यह मौजूद है: होस्टिंग पैनल, डोमेन रजिस्ट्रार, साइट व्यवस्थापक, ईमेल, क्लाउडफ्लेयर, गिटहब।

डोमेन रजिस्ट्रार के बारे में एक विशेष शब्द। यह पूरे स्टैक में सबसे कम आंका गया विफलता बिंदु है। अपने डोमेन पर नियंत्रण खोना आपकी साइट खोने से बदतर है: एक साइट एक घंटे में बैकअप से पुनर्स्थापित होती है, जबकि एक डोमेन महीनों के समर्थन टिकटों के माध्यम से वापस आता है — यदि यह वापस आता है।

पासवर्ड के बजाय SSH कुंजी, और कोई FTP नहीं

एक पासवर्ड का अनुमान लगाया जा सकता है या एक लैपटॉप से उठाया जा सकता है। एक कुंजी का किसी भी उपयोगी समय सीमा में अनुमान नहीं लगाया जा सकता। सेटअप एक बार पंद्रह मिनट लेता है, जिसके बाद सर्वर पर पासवर्ड लॉगिन पूरी तरह से अक्षम हो जाता है।

अलग से: सामान्य FTP को छोड़ दें। यह आपके उपयोगकर्ता नाम और पासवर्ड को स्पष्ट पाठ में भेजता है, जैसे कि यह 1998 है। केवल SFTP या SSH का उपयोग करें। यदि आपका होस्ट FTP को प्राथमिक विधि के रूप में पेश करता है, तो यह आपको होस्ट के बारे में कुछ बताता है।

याददाश्त के बजाय एक पासवर्ड प्रबंधक

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

फॉर्म, स्पैम, और दर सीमित करना

संपर्क फ़ॉर्म आपकी वेबसाइट का सबसे सुलभ हिस्सा है। यह सभी के लिए खुला है, बिना लॉगिन के काम करता है, और डेटा की प्रतीक्षा करता है। कोई आश्चर्य नहीं कि इसे सबसे अधिक दुरुपयोग का सामना करना पड़ता है।

क्यों CAPTCHA उत्तर नहीं है

CAPTCHA प्राइमिटिव स्क्रिप्ट्स को पकड़ता है और असली इंसानों को परेशान करता है। आधुनिक स्पैम ट्रैफ़िक तकनीकी रूप से या उन सेवाओं के माध्यम से इसे पार कर जाता है जहाँ असली लोग कैप्चा का उत्तर कुछ सेंट के लिए देते हैं। इस बीच, यह रूपांतरण को मापने योग्य रूप से नुकसान पहुँचाता है: कुछ असली ग्राहक बस विकृत अक्षरों पर हार मान लेते हैं और छोड़ देते हैं।

जो दृष्टिकोण काम करता है वह परतदार और आगंतुक के लिए अदृश्य है:

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

सर्वर-साइड मान्यता अनिवार्य है

ब्राउज़र में सुरुचिपूर्ण फ़ील्ड मान्यता उपयोगकर्ताओं के लिए एक सुविधा है, रक्षा नहीं। आपके सर्वर पर आने वाले डेटा को आपके पृष्ठ को छुए बिना भेजा जा सकता है। इसलिए सब कुछ फिर से सर्वर-साइड पर जांचा जाता है: प्रकार, लंबाई, प्रारूप, अनुमत मान। नियम सरल और सार्वभौमिक है: बाहरी दुनिया से इनपुट कभी भी विश्वसनीय नहीं होता, भले ही आपकी अपनी स्क्रिप्ट ने इसे एक पल पहले मान्य किया हो।

फ़ाइल अपलोड अपने स्वयं के समस्या हैं

यदि एक आगंतुक फ़ाइल अपलोड कर सकता है, तो ऐसा व्यवहार करें जैसे वे कुछ शत्रुतापूर्ण अपलोड कर रहे हैं। असली सामग्री प्रकार की जांच करें, नाम में एक्सटेंशन नहीं। फ़ाइल का नाम स्वयं बदलें। आकार सीमित करें। और सबसे महत्वपूर्ण, अपलोड को कहीं स्टोर करें जहां सर्वर शारीरिक रूप से कोड निष्पादित नहीं करेगा - आदर्श रूप से पूरी तरह से अलग स्टोरेज पर।

रेट लिमिटिंग फॉर्म्स से परे जाती है

यहां तक कि आपके API एंडपॉइंट्स, साइट सर्च, पासवर्ड रीसेट और किसी भी महंगे ऑपरेशन पर भी यही तंत्र लागू होता है। इसके बिना, एक स्थायी बॉट आपके सर्वर को निरंतरता के माध्यम से नीचे ले जा सकता है। यह सबसे महत्वपूर्ण है जहां पैसे शामिल हैं: भुगतान परियोजनाओं पर हम हमेशा यह सीमित करते हैं कि लेनदेन कितनी तेजी से बनाए जा सकते हैं — हमारा लेख क्रिप्टो भुगतान स्वीकार करने परयह बताता है कि यह आपके लेखांकन की सुरक्षा कैसे करता है जैसे कि आपके सर्वर की।

बैकअप: एकमात्र बीमा पॉलिसी जो हमेशा भुगतान करती है

स्पष्ट रूप से: बैकअप इस लेख में सब कुछ से अधिक महत्वपूर्ण हैं। अन्य सभी उपाय आपदा की संभावना को कम करते हैं। बैकअप यह तय करते हैं कि आपदा कैसे समाप्त होती है — एक अप्रिय शाम, या एक बंद व्यवसाय।

3-2-1 नियम

एक क्लासिक जो हमसे बहुत पहले आविष्कार किया गया था और अभी भी अप्रतिम है:

• 3 प्रतियांआपके डेटा की: एक लाइव और दो बैकअप।
• 2 विभिन्न मीडिया या प्लेटफार्म — एक ही टोकरी में सब कुछ नहीं।
• 1 कॉपी ऑफ-साइट, सर्वर से भौतिक और प्रशासनिक रूप से अलग।

यह अंतिम बिंदु है जहाँ अधिकांश सेटअप गिर जाते हैं। एक बैकअप जो उसी सर्वर पर है, या उसी होस्टिंग खाते में है, वह बैकअप नहीं है। एक हमलावर जो अंदर आता है, पहले इसे हटा देता है — यह एक मानक कदम है, कोई दिखावा नहीं। रैंसमवेयर इसे अन्य सभी चीजों के साथ एन्क्रिप्ट करता है। और अगर होस्ट मर जाता है, तो यह भी मर जाता है।

एक अप्रयुक्त बैकअप बैकअप नहीं है

यहाँ वह हिस्सा है जो चुभता है। हम लगातार वही दृश्य देखते हैं: बैकअप दो साल तक faithfully चलते हैं, और जिस दिन इसकी आवश्यकता होती है, आर्काइव भ्रष्ट निकलते हैं। या इनमें फ़ाइलें होती हैं लेकिन कोई डेटाबेस नहीं। या डेटाबेस वहाँ है, लेकिन निर्यात ने एन्कोडिंग को बिगाड़ दिया और पाठ प्रश्न चिह्न बन गया। या आर्काइव 40 किलोबाइट का है क्योंकि स्क्रिप्ट पहले फ़ोल्डर पर मर गई और त्रुटि ईमेल एक इनबॉक्स में गया जिसे कोई नहीं पढ़ता।

निष्कर्ष: पुनर्स्थापना का अभ्यास किया जाना चाहिए। हर तिमाही, एक कॉपी को एक स्टेजिंग वातावरण में तैनात करें और इसे देखें। क्या साइट लोड होती है? क्या डेटाबेस वहाँ है? क्या चित्र मौजूद हैं? क्या ऑर्डर दिखाई देते हैं? यह आपके बैकअप के बारे में सच्चाई जानने का एकमात्र तरीका है, पहले से, न कि किसी आपदा के दौरान।

रिटेंशन आवृत्ति को मात देती है

तीन दिनों की रिटेंशन के साथ दैनिक बैकअप एक शांत संक्रमण के खिलाफ बेकार है। दुर्भावनापूर्ण कोड अक्सर महीनों तक निष्क्रिय रहता है। जब आप इसे खोजते हैं, तो तीनों प्रतियां पहले से ही संक्रमित होती हैं। गहराई बनाए रखें: दो हफ्तों के लिए दैनिक, कुछ महीनों के लिए साप्ताहिक, एक साल के लिए मासिक। डिस्क स्पेस एक साइट की तुलना में बेजोड़ सस्ता है जिसमें पुनर्स्थापित करने के लिए कुछ नहीं है।

क्या बैकअप करें

फाइलें और डेटाबेस स्पष्ट हैं। जो चीजें भुला दी जाती हैं, वे हैं: सर्वर कॉन्फ़िगरेशन, वेब सर्वर नियम, अनुसूचित कार्य, DNS सेटिंग्स, ईमेल। एक अच्छा माप यह सवाल है, "अगर होस्टिंग कंपनी कल गायब हो जाए, तो कहीं और पूरी पुनर्निर्माण में कितना समय लगेगा?" अगर आपके पास इसका उत्तर नहीं है, तो आपका बैकअप अधूरा है।

निगरानी और लॉग: इसे अपने ग्राहक से पहले देखें

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

न्यूनतम सेट

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

लॉग: बोरिंग, और जहाँ सच्चाई रहती है

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

दो चीजें पहले करने के लायक हैं, क्योंकि इन्हें बाद में नहीं किया जा सकता। पहले, पुष्टि करें कि लॉग वास्तव में लिखे जा रहे हैं और कम से कम एक महीने के लिए रखे जा रहे हैं। कई सेटअप में इन्हें 24 घंटे के बाद काट दिया जाता है, और जांचने के लिए कुछ नहीं बचता। दूसरे, व्यवस्थापक लॉगिन लॉगिंग सक्षम करें - सफल और असफल। असफलताओं में वृद्धि पासवर्ड अनुमान लगाने की प्रक्रिया है, और आप इसके सफल होने से पहले प्रतिक्रिया कर सकते हैं।

क्या देखना है

आपको स्पष्ट चीज़ों को पहचानने के लिए विश्लेषक होने की आवश्यकता नहीं है। फ़ाइलों के लिए अनुरोध जो आपके पास नहीं हैं और कभी नहीं थे। एक ऐसे देश से सुबह 3 बजे के प्रशासनिक अनुरोध जहाँ आप किसी को भी नियुक्त नहीं करते। एक पता जो एक मिनट में सैकड़ों अनुरोध करता है। जहाँ पहले कोई त्रुटि प्रतिक्रिया नहीं थी, वहाँ त्रुटि प्रतिक्रियाओं की बाढ़। इनमें से कोई भी अपने आप में प्रमाण नहीं है, लेकिन प्रत्येक को करीब से देखने का एक कारण है।

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

WAF और CDN: क्लाउडफ्लेयर क्या करता है और क्या नहीं करता

Cloudflare और इसके जैसे सेवाएँ वास्तव में उपयोगी परत हैं, यही कारण है कि इनके चारों ओर इतनी मिथक है। आइए हम इस बारे में ईमानदार रहें कि मूल्य कहाँ है और भ्रांति कहाँ शुरू होती है।

वे क्या हैं

एक CDN आपके आगंतुक और आपके सर्वर के बीच दुनिया भर में नोड्स का एक नेटवर्क रखता है। स्थिर फ़ाइलें निकटतम नोड से प्रदान की जाती हैं — साइट तेज़ होती है और आपका सर्वर राहत पाता है। एक WAF (वेब एप्लिकेशन फ़ायरवॉल) एक फ़िल्टर है जो आने वाले अनुरोधों की जांच करता है और उन हमले के आकार के अनुरोधों को आपके कोड तक पहुँचने से पहले हटा देता है।

वास्तविक मूल्य

• DDoS को अवशोषित करना।जंक ट्रैफ़िक प्रदाता के नेटवर्क पर टूटता है न कि आपके सर्वर पर। एक छोटा व्यवसाय अकेले उस हमले से जीवित नहीं रहेगा।
• आपका असली सर्वर आईपी छिपाना।जब लक्ष्य दिखाई नहीं देता, तो सीधे हमले करना कठिन हो जाता है।
• बॉट फ़िल्टरिंग।स्कैनिंग शोर का एक बड़ा हिस्सा स्वचालित रूप से हटा दिया जाता है, और आपकी लॉग रातोंरात पढ़ने योग्य हो जाती है।
• वर्चुअल पैचिंग।एक WAF नियम एक नई कमजोरियों को बंद रख सकता है जबकि आप एक उचित अपडेट तैयार करते हैं। यह उधार का समय है, समाधान नहीं।
• गति।एक सुखद साइड इफेक्ट जो आगंतुकों और खोज इंजनों दोनों को दिखाई देता है।

वे क्या नहीं करेंगे

अब असहज आधा। एक WAF आपको तब नहीं बचाएगा जब:

• आपका पासवर्ड चोरी हो गया। मान्य क्रेडेंशियल्स के साथ लॉगिन एक वैध अनुरोध है। फ़िल्टर इसे पास करता है, और यह सही है।
• आपका वास्तविक IP पहले से ही ज्ञात है और आपका सर्वर सीधे कनेक्शन स्वीकार करता है, फ़िल्टर को बायपास करते हुए। यह एक अत्यंत सामान्य गलत कॉन्फ़िगरेशन है: आपका सर्वर केवल प्रदाता के नेटवर्क से ट्रैफ़िक स्वीकार करना चाहिए।
• कमज़ोरी है आपकी अपनी व्यावसायिक लॉजिक में। यदि आपका कोड एक उपयोगकर्ता को एक अन्य उपयोगकर्ता का ऑर्डर एक संख्या बदलकर लाने की अनुमति देता है, तो यह WAF के दृष्टिकोण से एक पूरी तरह से सही अनुरोध है।
• दुष्ट कोड है पहले से ही अंदर. फ़िल्टर दरवाजे की निगरानी करता है, न कि घर के अंदर क्या हो रहा है।
• एन्क्रिप्शन सेट है "लचीला". फिर Cloudflare से आपके सर्वर तक का डेटा स्पष्ट पाठ में यात्रा करता है जबकि आपका आगंतुक एक पैडलक देखता है और मानता है कि सब कुछ ठीक है। यह सुरक्षा की एक खतरनाक नकल है - प्रमाणपत्र सत्यापन के साथ सख्त मोड का उपयोग करें।

संक्षेप में: एक WAF और CDN एक उत्कृष्ट परिधि बाड़ हैं। एक बाड़ बेकार है जब चाबी चटाई के नीचे है और ग्राउंड-फ्लोर की खिड़की खुली है। यह स्वच्छता को पूरा करता है। यह इसे प्रतिस्थापित नहीं करता।

यदि आप पहले से ही समझौता कर चुके हैं तो क्या करें

शांत रहें। घबराहट हैक से अधिक महंगी होती है: घबराहट में लोग उन चीजों को हटा देते हैं जिनकी जांच को आवश्यकता होती है। प्रक्रिया अच्छी तरह से स्थापित है। इसका पालन करें।

1. अलग करें

साइट को एक रखरखाव पृष्ठ के पीछे रखें जो 503 स्थिति लौटाता है। यह आगंतुकों को संक्रमण से बचाता है और खोज इंजनों को बताता है कि आउटेज अस्थायी है न कि स्थायी। अभी कुछ भी न हटाएं।

2. सबूत को संरक्षित करें

विपरीत लेकिन महत्वपूर्ण। संक्रमित साइट की एक पूर्ण प्रति लें और पिछले महीने के लॉग्ससे पहलेकिसी भी सफाई के। यदि आप बैकअप से पुनर्स्थापित करते हैं बिना प्रवेश बिंदु की पहचान किए, तो आप फिर से उसी तरह से समझौता कर लेंगे, आमतौर पर एक सप्ताह के भीतर। वह प्रति आपकी एकमात्र संभावना है यह समझने के लिए कि वे कैसे अंदर आए।

3. हर क्रेडेंशियल को बदलें

सभी, कोई अपवाद नहीं, कोई "यह निश्चित रूप से लीक नहीं हो सकता" नहीं। होस्टिंग, SSH, डेटाबेस, हर व्यवस्थापक उपयोगकर्ता, FTP, डोमेन रजिस्ट्रार, ईमेल, जुड़े हुए सेवाएं। जहां भी 2FA गायब था, वहां इसे चालू करें। एक चेतावनी जो लोग चूक जाते हैं: यह एक साफ कंप्यूटर से करें। यदि लैपटॉप संक्रमित है, तो आपके नए पासवर्ड ठीक उसी तरह लीक होंगे जैसे पुराने।

4. प्रवेश बिंदु खोजें

संक्रमण की तारीख को संशोधित की गई फ़ाइलों से शुरू करें — वहां सबसे तेज़ ट्रेल है। पहले विदेशी फ़ाइल के प्रकट होने से ठीक पहले कौन सा अनुरोध आया, इसके लिए लॉग्स की खोज करें। होस्टिंग खाते में सब कुछ जांचें, जिसमें भूले हुए उपडोमेन शामिल हैं। सभी लोगों के कंप्यूटर की जांच करें जिनके पास पहुंच है। जब तक प्रवेश बिंदु नहीं मिल जाता, तब तक घटना बंद नहीं होती।

5. पुनर्निर्माण करें

सर्वश्रेष्ठ मार्ग एक साफ पुनर्स्थापना है: ताजा CMS, आधिकारिक स्रोतों से ताजा प्लगइन्स, और केवल आपकी सामग्री और बैकअप से लिया गया डेटाबेस — पहले डेटाबेस की जांच करें, क्योंकि कोड वहां भी इंजेक्ट किया जाता है, आमतौर पर टेम्पलेट्स और सेटिंग्स में। संक्रमित फ़ाइलों को मैन्युअल रूप से साफ़ करना एक लॉटरी है: एक ही फ़ाइल छूट जाए तो पूरा मामला वापस आ जाता है।

6. छिद्र बंद करें और अपनी प्रतिष्ठा को पुनर्प्राप्त करें

जिस कारण की पहचान आपने की है, उसे ठीक करें, या आपने बस घड़ी को रीसेट कर दिया है। फिर: Google Search Console में समीक्षा का अनुरोध करें, अपने डोमेन के मेल रिकॉर्ड की जांच करें (एक समझौता किया गया साइट शायद स्पैम भेज रहा था, और आपका डोमेन पहले से ही ब्लॉकलिस्ट में हो सकता है), और पुष्टि करें कि डेटाबेस में कोई अपरिचित व्यवस्थापक नहीं बचे हैं।

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

एक व्यावहारिक सुरक्षा चेकलिस्ट

आइए उपरोक्त सभी को एक सूची में संकुचित करें जिस पर आप आज शुरू कर सकते हैं। यह प्रयास के सापेक्ष प्रभाव के अनुसार क्रमबद्ध है — शीर्ष से शुरू करें।

आज, एक शाम में

1. चालू करें 2FA होस्टिंग, आपके डोमेन रजिस्ट्रार, ईमेल, और साइट प्रशासक के लिए।
2. सत्यापित करें HTTPSहर जगह काम करता है और सभी HTTP इसे रीडायरेक्ट करते हैं।
3. अपने प्रशासक उपयोगकर्ता सूची को खोलें और उन सभी को हटा दें जो वहां नहीं होने चाहिए: पूर्व कर्मचारी, पुराने ठेकेदार, ऐसे खाते जिन्हें कोई नहीं पहचानता।
4. वेब रूट की जांच करें असामान्य फ़ाइलें: अभिलेखागार, डेटाबेस डंप, एक .git फ़ोल्डर, कॉन्फ़िग कॉपी, परीक्षण स्क्रिप्ट।
5. पुष्टि करें बैकअप मौजूद हैं और एक ही सर्वर पर संग्रहीत नहीं हैं।
6. साइट को गूगल सर्च कंसोल से कनेक्ट करें और सुरक्षा अनुभाग पढ़ें।

इस सप्ताह

1. एक सेट करें पासवर्ड प्रबंधक और हर पुनः उपयोग किए गए पासवर्ड को एक अद्वितीय पासवर्ड से बदलें।
2. अपडेट करें CMS और सभी प्लगइन्स, एक पूर्ण बैकअप लेने के बाद।
3. हटाएं अप्रयुक्त प्लगइन्स और थीम — हटाएं, निष्क्रिय न करें।
4. कॉन्फ़िगर करें सुरक्षा हेडर: X-Content-Type-Options, X-Frame-Options, और Referrer-Policy से शुरू करें, जिन्हें तुरंत सक्षम करना सुरक्षित है।
5. अक्षम करें FTP और SSH कुंजियों पर जाएं।
6. जोड़ें अपटाइम मॉनिटरिंग और SSL और डोमेन समाप्ति के लिए अलर्ट।
7. रेट-सीमा लॉगिन प्रयासव्यवस्थापक पैनल पर।

इस महीने

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

दोहराएँ, ताकि आपको यह लेख फिर से कभी न चाहिए हो

• साप्ताहिक: सुरक्षा अपडेट, लॉगिन लॉग पर एक नज़र।
• मासिक:बैकअप की पुष्टि करें, उपयोगकर्ताओं की समीक्षा करें, लॉग की जांच करें।
• त्रैमासिक:पुनर्स्थापना का परीक्षण करें, प्लगइन्स का ऑडिट करें, कुंजी पासवर्ड बदलें।
• वार्षिक:पूर्ण ऑडिट, यह पुनर्विचार करें कि किसे पहुंच है और क्यों।

आपके साथ ले जाने के लिए एक अंतिम विचार। सुरक्षा एक ऐसी स्थिति नहीं है जिसे आप प्राप्त करते हैं और भूल जाते हैं; यह एक आदत है, जैसे कार्यालय का दरवाजा बंद करना। कोई भी पूर्ण सुरक्षा की गारंटी नहीं दे सकता, और जो कोई ऐसा वादा करता है वह आपको गुमराह कर रहा है। लेकिन उस साइट और उस साइट के बीच का अंतर जहां यह सूची पूरी की गई है और जहां इसका कोई पालन नहीं किया गया है, वह अंतर है "किसी ने कोशिश की और कुछ नहीं मिला" और "हम अपने डेटा को पुनर्प्राप्त करने के तीसरे सप्ताह में हैं"।

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