🅰️ 🧔🏿 👩🏿‍🚀 साइट किस छेद से गुज़री? 👩🏼‍🤝‍👩🏻 🐉 👩‍👩‍👧‍👧

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

इस क्षेत्र में कुछ अनुभव होने पर (औसतन, हमारा तकनीकी समर्थन सप्ताह में एक बार साइट हैक होने के कारणों की खोज कर रहा है), हमने संचित जानकारी को व्यवस्थित किया।

तो आखिर क्यों हैक करें साइटें? और अगर साइट हैक हो गई है, तो इसका कारण कैसे पता करें और बाद के हमलों से खुद को बचाएं?

क्यों हैक साइटों?

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

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

यही है, पटाखे की कार्रवाई का उद्देश्य बॉट के आगे वितरण, एक नेटवर्क (बॉटनेट) का निर्माण और अपने स्वयं के प्रयोजनों के लिए इसका आगे उपयोग करना है।

हैक कारण खोज एल्गोरिथम

एल्गोरिथ्म अपने आप में बहुत सरल है:

हैकिंग के निशान मिलते हैं।
हैकिंग का सही समय निर्धारित करें।
लॉग से पता करें कि साइट कैसे टूटी थी।

जटिलता पैराग्राफ 1 और 3 का कार्यान्वयन है। हम उन पर अधिक विस्तार से ध्यान देंगे।

हैक के निशान की खोज कैसे करें

हैकिंग लगभग हमेशा निशान छोड़ देती है: फाइलें जो हमलावर काम करती थीं, उदाहरण के लिए, PHP शेल। CMS हैक करने का क्लासिक तरीका:

एक भेद्यता के माध्यम से एक PHP शेल डाउनलोड करें (या एक भेद्यता के माध्यम से एक सीएमएस व्यवस्थापक तक पहुंच प्राप्त करें और एक फ़ाइल प्रबंधक के माध्यम से PHP शेल डाउनलोड करें)।
PHP शेल के माध्यम से, बाकी काम करें।

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

wzxp.php
gwd.php
a10881d.php.2046

सर्वर को हैक करने के लिए शुरू किए गए कारनामे का नतीजा कुछ इस तरह हो सकता है:

./w.sh
./env
./env.c
./program.c
./program.o
./w00t.so.1.0
/ tmp / श
/ tmp / sh2

ये फाइलें साइट के रूट में और tmp / या cache / folder दोनों में स्थित हो सकती हैं। आपको चित्र, / अपलोड, /, user_files /, आदि जैसे फ़ोल्डरों में भी देखना चाहिए - अक्सर, संपादकों या फोटो पुस्तकालयों में कमजोरियों के माध्यम से, स्क्रिप्ट को उस स्थान पर डाउनलोड किया जाता है जहां तस्वीरें आमतौर पर डाउनलोड की जाती हैं या अस्थायी फ़ाइलों को संग्रहीत किया जाता है।

साइट फ़ाइलों के अलावा, आपको सामान्य / tmp सर्वर की भी जांच करनी चाहिए - इसमें हैकिंग के लिए या बॉट लॉन्च के लिए उपयोग की जाने वाली अस्थायी फाइलें हो सकती हैं।

.Htaccess फ़ाइल पर गौर करना सुनिश्चित करें - वायरस फैलाने वाली अन्य साइटों पर पुनर्निर्देशित किया जा सकता है। इस स्थिति में, .htaccess फ़ाइल साइट के रूट और ऊपर दोनों में स्थित हो सकती है, इसलिए अपने खाते की सभी निर्देशिकाओं को देखने के लिए आलसी न हों।

दूसरे शब्दों में, आपको सब कुछ असामान्य / समझ से बाहर देखने और सभी संदिग्ध फाइलों के अंदर देखने की जरूरत है। PHP शेल इस तरह दिख सकता है:

<?php #v2.3 //Version
$auth_pass = ""; //75b43eac8d215582f6bcab4532eb854e
$color = "#00FF66"; //Colour
$default_action = "FilesMan";
$default_charset = "Windows-1251";
preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65
\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'7b1tVxs50jD8OXvO9R9Er3fanhhjm2Q2Y7ADIZCQSSAD5
GUC3N623bZ7aLs93W0Mk+W/31Wll5b6xZhkdq/7OedhJtDdKpVKUkkqlapK3rDM1tzJLL4tl7qn+ycf90/
// ... base64

PHP स्क्रिप्ट में ध्यान देने के लिए मुख्य बिंदु:

पाठ लिखने की Co0lHaZZkeR शैली।
एक्सप्लॉइट और शैल शब्दों की उपस्थिति।
बेस 64 में बड़ी मात्रा में कोड की उपस्थिति।
पहले तर्क में / ई स्विच के साथ eval () या preg_replace () फ़ंक्शन की उपस्थिति।

अंत में, आप बस अपने ब्राउज़र पर जा सकते हैं और देख सकते हैं कि यह स्क्रिप्ट क्या करती है।

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

# find ./public_html -mtime -3d
# find ./public_html -mtime -10h

(ढूँढें सिंटैक्स FreeBSD के लिए निर्दिष्ट किया गया है)। ये कमांड क्रमशः पिछले तीन दिनों और पिछले 10 घंटों में बदल चुकी फाइलों को दिखाएंगे।

यदि अन्य सभी विफल हो जाते हैं, तो आप बस बेस 64 एनकोडेड सामग्री वाली सभी फाइलों को खोज सकते हैं, उदाहरण के लिए इस तरह:

# find ./ -name '*.php' | xargs grep -E '[0-9a-zA-Z/]{80}'

यह कमांड उन सभी PHP लिपियों को पाएगी जिनमें कम से कम 80 वर्णों की लंबाई के साथ बेस 64 के समान तार होते हैं।

हैकिंग समय का पता लगाने

जब फाइलें मिल जाती हैं, तो हैकिंग के समय को निर्धारित करना बहुत आसान है - बस जल्द से जल्द फाइल के संशोधन के समय को देखें।

यदि कोई संदिग्ध फाइलें नहीं मिलीं, लेकिन साइट वायरस से संक्रमित है, तो उस तारीख को देखें जिसमें index.php, index.html या वायरस का पता लगाया गया हो। इस मामले में सबसे अधिक संभावना एफ़टीपी से पासवर्ड चोरी करके साइट को हैक किया गया था।

खोज साइट हैकिंग लॉग

अब सबसे महत्वपूर्ण बात यह है कि ये पत्रिकाएँ उपलब्ध हैं!

यदि साइट को केवल हटा दिया गया है या सभी index.html फ़ाइलों में वायरस जोड़ दिया गया है, तो संभवत: साइट को एफ़टीपी पासवर्ड (या, बहुत कम आमतौर पर, एसएसएच) की चोरी के माध्यम से हैक किया गया था। हैक के दौरान एफ़टीपी और एसएसएच कनेक्शन लॉग को देखें - अज्ञात आईपी पते की उपस्थिति या बड़ी संख्या में विभिन्न आईपी पते जो साइट से सफलतापूर्वक जुड़े हुए हैं इसका मतलब है कि पासवर्ड चोरी हो गया है।

इस मामले में, यह उन कंप्यूटरों की जांच करने के लिए पर्याप्त है जिनसे साइट को वायरस के लिए एक्सेस किया गया था, एफ़टीपी पासवर्ड बदल सकते हैं और एफ़टीपी क्लाइंट्स में कभी भी पासवर्ड सेव नहीं करते।

यदि साइट में PHP शेल या दुर्भावनापूर्ण स्क्रिप्ट हैं (उदाहरण के लिए, स्पैम भेजने के लिए), सबसे अधिक संभावना है कि साइट को सीएमएस या इसके कुछ प्लग-इन में भेद्यता के माध्यम से हैक किया गया था। इस मामले में, आपको वेब सर्वर लॉग का विश्लेषण करने की आवश्यकता है।

यह समझने के लिए कि आपको सीएमएस हैकिंग कैसे होती है, इस पर विचार करने की आवश्यकता है।

एक हमलावर यह निर्धारित करता है कि साइट में CMS या उसके प्लगइन्स हैं, या अन्य सॉफ़्टवेयर (अप्रचलित Joomla, phpMyAdmin, WYSIWYG संपादक, फोटो गैलरी, आदि) जो संभावित रूप से असुरक्षित हैं।
वह इस सॉफ्टवेयर के लिए जाने-माने कारनामों को सुलझाना शुरू कर देता है। लक्ष्य किसी तरह से आपकी फ़ाइल को साइट पर अपलोड करना है।
जब एक भेद्यता पाई जाती है, तो पटाखा PHP शेल को लोड करता है।
PHP शेल से कनेक्ट करके, पटाखा साइट तक पूरी पहुंच प्राप्त करता है और किसी भी उद्देश्य के लिए इसका उपयोग करना जारी रख सकता है।

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

यदि यह आईपी पते को निर्धारित करना संभव था

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

यदि IP पता निर्धारित नहीं किया जा सका

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

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

यदि साइट की हैकिंग का समय ज्ञात है (और हम पहले से ही जानते हैं), तो आपको उन सभी POST अनुरोधों के लिए वेब सर्वर लॉग में देखना होगा जो हैकिंग के समय के करीब हैं। कोई विशिष्ट सलाह नहीं है - वे पूरी तरह से अलग दिख सकते हैं, लेकिन वे किसी भी मामले में असामान्य दिखेंगे। उदाहरण के लिए, यह '../../../../' या फ़ाइल नाम या SQL क्वेरी वाले लंबे क्वेरी वाले प्रश्न हो सकते हैं।

अगर कुछ नहीं मिला

ऐसा भी हो सकता है। इस स्थिति में, आप केवल सीएमएस और उसके एक्सटेंशन और डेटा के बाद के आयात की एक साफ पुनर्स्थापना की सिफारिश कर सकते हैं। यह सुनिश्चित करना सुनिश्चित करें कि सीएमएस और उसके एक्सटेंशन का नवीनतम संस्करण।

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

ठीक है, निश्चित रूप से, उन सभी पासवर्ड को बदल दें जिनका साइट से कोई लेना-देना है।

हाउसकीपिंग टिप

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

साइट किस छेद से गुज़री?