मेरी वेबसाइट हैक हो गई है, क्या करें?

अपनी साइट को सुरक्षित रखने के लिए यहां कुछ सुझाव दिए गए हैं। यह मुख्य रूप से हैक हुई साइट के संदर्भ में लिखा गया था:

1. सबसे पहले, अपने अकाउंट में उपयोग की जा रही सभी वेब स्क्रिप्ट/एप्लिकेशन की संबंधित विक्रेता/डेवलपर साइटों पर जाकर देखें कि कोई अपडेट उपलब्ध तो नहीं है, इसमें किसी भी वेब एप्लिकेशन में उपयोग किए जा रहे मॉड भी शामिल हैं। यदि आप कोई ओपन सोर्स वेब एप्लिकेशन उपयोग कर रहे हैं, तो सबसे पहले संदेह उसी पर जाएगा। फिर भी, आपको सभी की जांच करनी चाहिए और उन्हें अपडेट रखना चाहिए। सार्वजनिक रूप से जारी किसी भी ज्ञात एक्सप्लॉइट के लिए www.secunia.com पर मौजूद डेटाबेस भी देखें।

2. जब आप सुनिश्चित कर लें कि इंस्टॉल की गई 100% स्क्रिप्ट नवीनतम स्थिर संस्करण की हैं, तब आपको अपने अकाउंट की सभी फ़ाइलों की जांच करनी होगी कि कोई फ़ाइल आपके ऑडिट से पहले हैकरों द्वारा अपलोड तो नहीं की गई, या किसी पुराने इंस्टॉल से आपके यहां छूट तो नहीं गई। संदिग्ध फ़ाइलें ऐसे फ़ोल्डरों में भी हो सकती हैं जिनके बारे में आप सोच भी नहीं सकते, और कई स्तर नीचे के फ़ोल्डरों में भी। आप ftp या cPanel फ़ाइल मैनेजर से public_html के अंतर्गत सभी फ़ाइलें देखकर उन्हें अपनी लोकल कॉपी से मिला सकते हैं। [इस तुलना के लिए, और बैकअप के रूप में भी, आपके पास हमेशा एक लोकल कॉपी होनी चाहिए।]

3. सुनिश्चित करें कि सभी पासवर्ड अक्षरों और अंकों का मिश्रण हों और शब्दकोश का कोई शब्द न हों। शब्दकोश से कोई कठिन शब्द चुन लेने भर से आप सुरक्षित नहीं हो जाते। कृपया बड़े और छोटे दोनों अक्षरों का उपयोग करें और कम से कम 8 अक्षर रखें।

4. सभी वेब एप्लिकेशन के लिए MySQL डेटाबेस एक्सेस अलग-अलग डेटाबेस यूज़र से होना चाहिए। इसके लिए अपने मुख्य अकाउंट का यूज़र/पासवर्ड कभी उपयोग न करें। आपका मुख्य यूज़र/पासवर्ड आपके अकाउंट की किसी भी फ़ाइल में संग्रहीत नहीं होना चाहिए।

5. अपने कंट्रोल पैनल में Raw Log Manager के अंदर अपने वेब लॉग का आर्काइव विकल्प चालू करें। इससे आप यह जांच सकेंगे कि हैकर ने किसी स्क्रिप्ट का फ़ायदा कैसे उठाया। अन्यथा आंकड़े तैयार होने के बाद सभी रॉ लॉग मिटा दिए जाते हैं। यदि आप पहले ही हैक हो चुके हैं, तो अब बहुत देर हो चुकी है, लेकिन आप भविष्य के हमलों के लिए लॉग आर्काइव कर सकते हैं।

6. यदि आपने किसी वेब एप्लिकेशन को मॉड के साथ कस्टमाइज़ किया है, तो सुनिश्चित करें कि वह भी नवीनतम स्थिर संस्करण का हो। कई लोकप्रिय वेब एप्लिकेशन स्थिर हो सकते हैं, लेकिन उनके ऐडऑन मॉड में से कोई एक असुरक्षित हो सकता है और संभव है कि अब उसका रखरखाव भी न हो रहा हो।

7. यदि आपने स्वयं कुछ कोड लिखा है, तो सुनिश्चित करें कि सभी इनपुट वेरिएबल सैनिटाइज़ किए गए हों (उपयोग से पहले मान्य डेटा के लिए जांचे गए हों)। अन्यथा खराब कोड की एक ही पंक्ति आपके पूरे अकाउंट तक पहुंच दे सकती है। आम गलती उपयोगकर्ता के इनपुट के आधार पर कोई फ़ाइल शामिल करना है। दोबारा कहें तो, सुनिश्चित करें कि स्क्रिप्ट को दिया गया हर इनपुट मान्य डेटा के लिए जांचा जाए। सभी एक्सप्लॉइट इनपुट डेटा पर आधारित होते हैं। यदि आपकी साइट कोई इनपुट नहीं लेती, तो आप वेब एक्सप्लॉइट से 100% सुरक्षित हैं, यानी यदि आप 100% स्टैटिक HTML साइट चलाते हैं जिसमें आपके अकाउंट में कहीं भी कोई स्क्रिप्ट न हो।

8. PHP के लिए, जो भी एप्लिकेशन register_globals के सक्रिय होने पर निर्भर करता है, उसके असुरक्षित होने की संभावना अधिक होती है। ऐसे एप्लिकेशन से बचें।

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

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

11. यदि आपकी साइट वर्षों से ठीक चल रही है, तो इसका अर्थ यह नहीं कि उसमें सुरक्षा खामियां नहीं थीं। वास्तव में इसका मतलब यह है कि वह एक्सप्लॉइट अज्ञात था, या आप भाग्यशाली थे कि पहले किसी ने उसका फ़ायदा नहीं उठाया।

12. अतिरिक्त सुरक्षा के लिए, अपनी कॉन्फ़िगरेशन फ़ाइलों (जिनमें डेटाबेस क्रेडेंशियल आदि हों) की परमिशन 660 कर दें। आप यह FTP या फ़ाइल मैनेजर के माध्यम से कर सकते हैं। यह सुविधा शेयर्ड होस्टिंग सर्वर पर, या तब काम कर सकती है जब आपके VPS/डेडिकेटेड सर्वर पर cPanel के ज़रिए phpsuexec उपलब्ध हो।

13. अतिरिक्त सुरक्षा के लिए, यदि आप अपनी साइट के कुछ एडमिनिस्ट्रेटिव सेक्शन तक पहुँच को रोक सकते हैं, तो केवल अधिकृत IP एड्रेस को पहुँच दें और बाकी सभी के लिए पहुँच बंद कर दें, या उसे पासवर्ड से सुरक्षित करें।

14. यदि आपके अकाउंट में फ़ाइल अपलोड करने की कोई सुविधा है, तो सुनिश्चित करें कि केवल अधिकृत सदस्य ही उसका उपयोग कर सकें।

साथ ही, अपलोड की गई फ़ाइल वेब URL के ज़रिए सीधे उपलब्ध नहीं होनी चाहिए (यानी public_html के बाहर संग्रहीत हो), जब तक कि

क) वह केवल साइट एडमिन (ज़िम्मेदार व्यक्ति) द्वारा ही अपलोड की गई हो
ख) जाँच और सत्यापन करके यह सुनिश्चित न कर लिया गया हो कि उसका दुरुपयोग नहीं किया जा सकता

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

16. यदि आप केवल कुछ टेस्ट कर रहे हैं या आज़मा रहे हैं, जिसकी ज़रूरत सिर्फ़ आपको है और जिसे आप नियमित रूप से अपडेट नहीं रखेंगे, तो उसे तुरंत पासवर्ड के पीछे लॉक कर दें।

17. चूँकि शेयर्ड/sdx/रीसेलर सर्वर suPHP के साथ आते हैं, इसलिए आपको किसी भी ऐसी फ़ाइल या फ़ोल्डर की ज़रूरत नहीं है जिसकी वर्ल्ड राइट परमिशन हो। सामान्य फ़ोल्डर परमिशन 755 से अधिक नहीं होनी चाहिए। PHP/HTML फ़ाइलें 644 (या ssh के ज़रिए इससे कम) हो सकती हैं। CGI/Perl स्क्रिप्ट 755 होनी चाहिए।

18. वेब एप्लिकेशन कोड लिखने वाले हर व्यक्ति को सुरक्षा की जानकारी होनी चाहिए। मुझे अपनी स्थानीय लाइब्रेरी में यह पुस्तक मिली, जो विशेष रूप से PHP पर है: http://www.oreilly.com/catalog/phpsec/ मैं इसे सभी को पढ़ने की सलाह देता हूँ। इसमें आज वेब एप्लिकेशन में पाई जाने वाली कमज़ोरियों के सभी पहलुओं को शामिल किया गया है। इस पुस्तक से मुझे यह साइट भी मिली: http://phpsec.org