2012-10-18 20 views
5

ठीक है, इसलिए मेरी वेबसाइटों में से एक (जूमला पर) 6 वें समय की तरह हैक किया जा रहा है ...जूमला हैक किया गया। कैसे बचाना है?

मैं आपको कोई कहानियां नहीं बताऊंगा। केवल तथ्य:

सबसे पहले, मैंने पाया कि टेम्पलेट इंडेक्स फ़ाइल में कुछ विदेशी कोड छपी:

<div id='hideMe'> <p>Every person knows the large quan...|...ur cure Viagra <a href="xxxxx">Viagra</a> </div><script type='text/javascript'>if(document.getElementById('hideMe') != null){document.getElementById('hideMe').style.visibility = 'hidden';document.getElementById('hideMe').style.display = 'none';}</script> 

तब मैं tmp फ़ोल्डर सामग्री के साथ

asd.php नाम की एक फ़ाइल में पाया: http://www.codr.cc/bb027a

मुझे लगता है कि डिकोड करने की कोशिश की और कुछ ऐसा हो गया है: http://www.codr.cc/97c183

यह कैसे हुआ? फाइल बनाने के लिए हैकर को कैसे एक्सेस मिला? सभी फ़ोल्डर perms थे 755 और फ़ाइलों - 644.

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

और क्या मैं भविष्य हैक्स को रोकने के लिए क्या करना चाहिए?

उत्तर

3

यह 6 बार के लिए काट दिया नहीं गया है। आपको दर्जनों बॉट्स द्वारा हैक किया गया है और आपकी प्रणाली का बैकडोर्ड है। आप संक्रमण को हटा देते हैं और एक बॉट बस इसे बहाल कर देगा।

ऐसा इसलिए हुआ क्योंकि अपने सॉफ़्टवेयर पुराना हो चुका है। यह संभवतः कुछ प्लगइन या यहां तक ​​कि जूमला भी स्वयं बहुत पुराना है।

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

यदि आपको अभी भी समस्याएं हैं, तो एक पेशेवर किराए पर लें।

+0

लेकिन हर हैक अलग है। यह प्रत्येक .php फ़ाइल में eval (base64_decode()) के साथ शुरू हुआ। क्या ऐसा करने में सक्षम बॉट है? वैसे, जूमला नवीनतम, टेम्पलेट भी है। वास्तव में सब कुछ अद्यतित है। – Trajektorijus

+2

@Trajektorijus या तो हर बार एक अलग हैकर या आपका सिस्टम एक वेश्या की तरह किसी अन्य हैकर प्रकार को बेचा जा रहा है। आपके सिस्टम को लगभग हर नए हैकर द्वारा पिछड़ा हुआ है जो टूट जाता है, मैं इसके बारे में 100% निश्चित हूं। इसलिए इससे कोई फर्क नहीं पड़ता कि आप मूल भेद्यता को ठीक करते हैं, आपको स्क्रैच से शुरुआत करना है। – rook

11
  1. आपकी वेबसाइट बहुत पुराने एक्सटेंशन स्थापित है: यह ऊपर और एक काट दिया जूमला वेबसाइट के पीछे सबसे आम कारण है। आपको हमेशा अपने एक्सटेंशन को अद्यतित रखना चाहिए, और यदि आप एक्सटेंशन का उपयोग कर रहे हैं जो अब समर्थित नहीं है, तो वैकल्पिक खोजने का प्रयास करें। यदि नहीं है, तो डेवलपर यह सुनिश्चित करने के लिए उस एक्सटेंशन को देखें कि कोई भेद्यता समस्या नहीं है।
  2. आप जूमला के एक पुराने संस्करण का उपयोग कर रहे: हम जानते हैं कि यह मुश्किल है अपने जूमला वेबसाइट रखने अप-टू-डेट नवीनतम संस्करण के साथ, खासकर यदि आप एक्सटेंशन (घटकों, मॉड्यूल का एक बहुत है, प्लगइन्स) यदि आप जूमला को अपग्रेड करते हैं तो टूटा जाएगा। लेकिन आपको करना होगा, आप हमेशा के लिए पुराने संस्करण का उपयोग नहीं कर सकते हैं। विशेष रूप से जब आप SEF का उपयोग कर रहे हैं डिफ़ॉल्ट रूप से, अपने .htaccess फाइल उस पर लिखने की अनुमति नहीं है, क्योंकि जूमला इसे अद्यतन करने की है,:
  3. आप अपने .htacess फ़ाइल पर लिखने की अनुमति। समस्या यह है कि यह आपके .htaccess को उन हमलों के लिए कमजोर छोड़ देगा जो को बदलते हैं। आपको हमेशा अपना सेट करना चाहिए।444 (आर-आर-आर-) या शायद 440 (आर-आर--) के लिए htaccess अनुमति।
  4. आप अपने * .php फाइलों पर लिखने की अनुमति: न तो वेब सर्वर और न ही दुनिया को अपनी जूमला * .php फाइलों पर लिखने की अनुमति होनी चाहिए। आप यह सुनिश्चित करना चाहिए कि आपके सभी * .php की अनुमति 444.
  5. उपयोगकर्ताओं स्क्रिप्ट अपलोड करने के लिए अनुमति दे की तैयारी में हैं: उदाहरण के लिए, यदि एक घटक छवियों को स्वीकार करता है, तो आप यह सुनिश्चित करना चाहिए कि केवल छवियों अपलोड होने की अनुमति दी जाती है । इस संदर्भ में, सार्वजनिक निर्देशिका उन निर्देशिकाओं जहाँ उपयोगकर्ताओं करने में सक्षम हैं इसका मतलब यह उनकी फाइलों पर अपलोड करें: उपयोगकर्ता (जैसे कि * .php फ़ाइलें)
  6. सार्वजनिक निर्देशिकाओं पर अनुमतियों को अंजाम देते हुए स्क्रिप्ट अपलोड करने में सक्षम नहीं होना चाहिए। कल्पना करें कि कोई व्यक्ति आपकी अपलोड निर्देशिका (एक तरफ या किसी अन्य तरीके से) में से किसी एक फ़ाइल को अपलोड कर रहा है। यदि वह फ़ाइल स्क्रिप्ट है, और यदि वह निर्देशिका स्क्रिप्ट चलाने के लिए अनुमति देती है, तो व्यक्ति आसानी से दुर्भावनापूर्ण स्क्रिप्ट चला सकता है। सार्वजनिक (अपलोड) निर्देशिकाओं को सभी को 766 की अनुमति दी जानी चाहिए (मालिक पढ़ सकते हैं, लिखें, और निष्पादित करें। शेष केवल पढ़ और लिख सकते हैं)।
  7. गैर-प्रमुख एक्सटेंशन का उपयोग करना: आपको हमेशा एक्सटेंशन का उपयोग करना चाहिए जो कई लोगों द्वारा उपयोग और परीक्षण किया जाता है। बहुत कम लोगों द्वारा उपयोग किए जाने वाले का एक एक्सटेंशन का उपयोग करना एक अच्छा अभ्यास नहीं है, और आपकी वेबसाइट हैक की गई हो सकती है (हमलावर XSS, SQL इंजेक्शन आदि जैसे कई तकनीकों का उपयोग कर सकता है ...)। यदि आप इस तरह के एक्सटेंशन का उपयोग करने के लिए बाध्य महसूस करते हैं,
  8. क्या कोई डेवलपर सुरक्षा के लिए इसकी समीक्षा करता है। अविश्वसनीय डेवलपर्स को प्रमाण पत्र देना: आपको अविश्वसनीय डेवलपर्स को अपनी वेबसाइट प्रमाण-पत्र नहीं देना चाहिए। और, यदि आपको वास्तव में करना है, तो डेवलपर काम करने के बाद सभी अपने पासवर्ड बदलें।
  9. डेटाबेस उपयोगकर्ता के लिए सभी संभव अनुमतियाँ देते: एक बार आपके जूमला वेबसाइट सेटअप है, डेटाबेस उपयोगकर्ता केवल पंक्तियां सम्मिलित करना चाहिए, अद्यतन पंक्तियाँ, पंक्तियों हटा देगा, और टेबल बना। उसे टेबल या डेटाबेस को डीआरओपी नहीं करना चाहिए। सुनिश्चित करें कि जूमला डेटाबेस उपयोगकर्ता के लिए केवल आवश्यक अनुमतियां दी गई हैं।
  10. आश्वस्त लग रहा है कि आपकी वेबसाइट को हैक कर लिया नहीं कर सकते हैं या नहीं एक अपनी वेबसाइट हैक होता है कि: क्या आप एक छोटा सा दान वेबसाइट या एक विशाल स्कूल वेबसाइट हो या न, अपनी वेबसाइट हैकिंग के लिए अतिसंवेदनशील है। कई हैकर कमजोरियों वाली वेबसाइटों के लिए इंटरनेट स्कैन करने के लिए सॉफ़्टवेयर का उपयोग करते हैं और उन पर हमला करते हैं, बस क्योंकि वे कर सकते हैं! हमेशा अपनी वेबसाइट की सुरक्षा को गंभीरता से लें, ऐसा मत सोचें कि यदि आप बहुत छोटे हैं तो कोई भी आपकी वेबसाइट हैकिंग पर विचार करेगा, या यदि आप बहुत बड़े हैं तो आप पर्याप्त सुरक्षित हैं और कोई भी आपकी हैक करने में सक्षम नहीं होगा वेबसाइट।

जांचें कि कौन सा आपको प्रभावित करता है और आपके द्वारा की गई गलतियों को सही करता है।

अद्यतन

Security Checklist/You have been hacked or defaced

Joomla Security

Vulnerable Extensions List

+0

+1 अच्छी पोस्ट। आपका # 9 MySQL पर लागू नहीं होता है, एमएस-एसक्यूएल, एक्सेस और SQLite को छोड़कर सभी डेटाबेस पर क्वेरी स्टैकिंग प्रतिबंधित है। हालांकि MySQL में file_priv है, जो कि MySQL के तहत अब तक की सबसे खतरनाक अनुमति है क्योंकि आप फ़ाइलों को पढ़ने और बनाने के लिए इसका उपयोग कर सकते हैं और इसे क्वेरी स्टैकिंग की आवश्यकता नहीं है। – rook