अच्छे दिन, प्रिय हब उपयोगकर्ताओं। अंत में, मुझे एक और ग्राहक मिला जिसने मुझे नाम न छापने की शर्त पर उसकी समस्या के समाधान का वर्णन करने की अनुमति दी। कटौती के तहत एक कहानी है कि एक ही समय में कई तरीकों से ग्राहक की साइटों पर दिखाई देने वाले दुर्भावनापूर्ण कोड के खिलाफ लड़ाई कैसे हुई। इस तथ्य के कारण कि बहुत से लोग बड़ी मात्रा के लेख पसंद नहीं करते हैं, इस बार मैंने यथासंभव संक्षेप में सब कुछ बताने की कोशिश की।
प्रारंभिक डेटा इस प्रकार थे। एक वर्चुअल सर्वर है जो Ubuntu 10.04 चल रहा है। ग्राहक इसे अपने दम पर प्रशासित करता है। सर्वर में 13 साइटें हैं, जिनमें से 12 वर्डप्रेस पर तैनात हैं, और एक में स्थैतिक एचटीएमएल-पेज हैं। उनकी फ़ाइल सामग्री एफ़टीपी के माध्यम से प्रबंधित की जाती है, और केवल 2 कंप्यूटर से। एक मैक, Win7 के साथ एक दूसरा पीसी और KAV लाइसेंस प्राप्त है।
नियमित रूप से, प्रत्येक 1-2 सप्ताह में, वे संक्रमित हो जाते हैं - php स्क्रिप्ट कोड में obfuscated आवेषण दिखाई देते हैं। पहली बातचीत के दौरान, क्लाइंट ने कहा कि समान आइफ्रेम-कोड लगातार स्क्रिप्ट में दिखाई देता है, लेकिन, जैसा कि बाद में पता चला, कई मैलवेयर थे। अंत में, साइटें Google और यैंडेक्स के जारी होने से बाहर हो गईं, और धीरे-धीरे आगंतुकों की संख्या शून्य के बराबर हो गई।
पहले निरीक्षण के बाद, कई और दिलचस्प विवरण सामने आए:
- सभी ब्लॉगों ने रूट के रूप में MySQL के साथ काम किया।
- अंदर से साइटों को प्रबंधित करने के लिए, VDS पर एक एकल उपयोगकर्ता बनाया गया था, जिसके होम फोल्डर में सभी वेब निर्देशिकाएं एक ही बार में स्थित थीं।
- PHP एक अपाचे मॉड्यूल के रूप में स्थापित किया गया था, जिसके कारण बाद वाले ने एक तरफ सभी साइटों के साथ काम किया - www-data। इसलिए, प्रत्येक संसाधन को प्रभावित करने के लिए उनमें से कम से कम एक में एक दोष खोजने के लिए पर्याप्त था।
- प्रत्येक ब्लॉग पर, कई सुरक्षा-संबंधित प्लग इन स्थापित किए गए थे - कुछ WP स्कैनर, चेकसम और बहुत कुछ।
- कई फाइलों में, दुर्भावनापूर्ण कोड ने मूल निवासी की तुलना में अधिक जगह ले ली - बार-बार संक्रमण के दौरान, रोबोट ने स्क्रिप्ट में अपने कोड की उपस्थिति की जांच नहीं की।
इस सब ने गंभीरता से जोड़ा। इस स्तर पर, यह स्पष्ट हो गया कि समस्या सरल नहीं है, और क्लाइंट को इस परेशानी से बचाने के लिए, न केवल एफ़टीपी पासवर्ड और क्लाइंट मशीनों की सुरक्षा के साथ काम करना आवश्यक है (जैसा कि ऐसी स्थितियों में अक्सर होता है)।
इसके बाद, संक्रमण के संभावित मार्गों की एक सूची तैयार की गई थी, जिनमें से प्रत्येक की जाँच की जानी थी। सबसे पहले, बस इसकी व्यापकता के कारण, रिमोट एक्सेस सेवाओं से पहले चुराए गए पासवर्ड की मदद से संक्रमण के विकल्प पर विचार किया गया था। बेशक, विन-मशीन पर ताजा केएवी एक अच्छा तर्क है, लेकिन एंटीवायरस स्थापित होने से पहले पासवर्ड चोरी हो सकते हैं। और इस तथ्य को नहीं कि व्यवस्थापक तुरंत उन्हें बदल देगा।
दूसरे स्थान पर सभी प्रकार के बैकडोर के माध्यम से संक्रमण था। मान लीजिए कि एक बार व्यवस्थापक ने समय पर WP को अपडेट नहीं किया था और कुछ शेल साइट पर अपलोड किया गया था, जिसके माध्यम से अब दुर्भावनापूर्ण कोड लगातार खुद को महसूस करता है।
और तीसरे विकल्प के रूप में, साइट स्क्रिप्ट में भेद्यता के माध्यम से संक्रमण पर विचार किया गया था। तकनीकी कारणों से अद्यतन करने की असंभवता के कारण, कुछ संसाधनों पर WP 2.9.2 स्थापित किया गया था। इस संस्करण के लिए काम के समय, केवल TrackBack फ़ंक्शन में SQL इंजेक्शन ज्ञात था, जिसका उपयोग क्लाइंट द्वारा किसी भी साइट पर नहीं किया गया था। लेकिन प्लगइन्स और थीम के बारे में मत भूलना। वे अक्सर त्रुटियां भी पाते हैं। इसके अलावा, साइटों में से एक पर एक phpBB फोरम संस्करण 3.0.8 स्थापित किया गया था। यह काम नहीं कर रहा था (डेटाबेस से कोई संबंध नहीं, कॉन्फ़िगरेशन फ़ाइल में गलत डेटा), लेकिन फिर भी इसे जांचने का निर्णय लिया गया। इस संस्करण की भेद्यताओं के बारे में जानकारी के सार्वजनिक स्रोतों में मुझे नहीं मिला, लेकिन आधिकारिक मंच पर एक विषय है (
http://www.phpbb.com/community/viewtopic.php?f=46&t=2119662 ) इसकी हैकिंग के बारे में बताता है। हालाँकि, कोई दोष नहीं हैं, क्योंकि इस बात की कोई गारंटी नहीं है कि डेटाबेस से कोई संबंध नहीं होने पर इस संस्करण के मंच को हैक नहीं किया जा सकता है।
उसके बाद, पिछले कुछ दिनों में वेब और एफ़टीपी सर्वर लॉग की जाँच की गई थी। जिज्ञासु बातें निकलीं। एक बार, एक रोबोट ने दिन में एक बार एफ़टीपी प्राधिकरण पारित किया और तुरंत बंद कर दिया। जाहिरा तौर पर खाते की वैधता की जाँच की। एक अन्य दैनिक एफ़टीपी गया, 12 हमेशा अलग-अलग स्क्रिप्ट डाउनलोड किया और, अगर उनके पास कोई दुर्भावनापूर्ण आवेषण नहीं था, तो स्थिति को ठीक किया। द्वार वेब सर्वर लॉग में जलाया गया था, जहां लोग मुख्य रूप से यांडेक्स से आए थे। साइटों के विभिन्न बिंदुओं से उत्पन्न होने वाले मोबाइल ब्राउज़रों के उपयोगकर्ताओं का एक अजीब पुनर्निर्देश भी था। इसे रूट .htaccess के माध्यम से लागू किया गया था। इसके अलावा, 3 वेब गोले पाए गए, जिनके लिए POST अनुरोध कभी-कभी जाते थे। सामान्य तौर पर, सभी 12 साइटें सभी प्रकार के मैलवेयर के साथ बस Teeming थीं।
सबसे पहले, क्लाइंट को वर्तमान खतरनाक आवेषणों को नहीं छूने और बस एक साफ रोल करने के लिए कहा गया था, जैसा कि उसने सोचा था, बैकअप प्रतिलिपि, जो इन सभी परेशानियों को देखने से पहले भी बनाई गई थी। लेकिन एक विस्तृत अध्ययन के बाद, यह पता चला कि वह भी अपने आप में उपरोक्त सभी है, बस थोड़ी मात्रा में। इसलिए, प्रत्येक समस्या से अलग से निपटने का निर्णय लिया गया।
यहां पीछे हटना और यह कहना आवश्यक है कि यदि संक्रमण के स्रोतों को समाप्त नहीं किया जाता है तो ऐसी लड़ाई बेकार है। आप कोड को यथासंभव साफ कर सकते हैं - दुर्भावनापूर्ण आवेषण अभी भी वापस आ जाएंगे। इसलिए, निम्नलिखित कार्य किया गया था:
- प्रत्येक साइट के लिए, एक अलग MySQL उपयोगकर्ता केवल अपने डेटाबेस तक पहुँच अधिकार के साथ बनाया गया था।
- ओएस में प्रत्येक साइट के लिए एक अलग उपयोगकर्ता बनाया गया था और इसके निर्देशिका पर संबंधित अधिकार निर्धारित किए गए थे। WP स्थापना प्रलेखन में निर्दिष्ट निर्देशिकाओं के लिए किसी भी 777 का कोई सवाल नहीं था। केवल मालिक के पास अधिकतम लिखने की अनुमति थी।
- उपयोगकर्ता-स्वामियों की ओर से साइट स्क्रिप्ट के साथ अलग php.ini और दुभाषिया कार्य प्रदान करने के लिए Apache और PHP बंडल को mod_php से php-cgi + suPHP पर फिर से तैयार किया गया था।
- क्लाइंट द्वारा उपयोग किए गए प्रदाता के नेटवर्क से केवल एफ़टीपी एक्सेस की अनुमति थी।
- प्रत्येक साइट के डेटाबेस में, प्रशासक कहां से आए हैं, यह जानने की उपस्थिति के लिए खातों के साथ तालिकाओं की जांच की गई थी।
- निष्कासित होने के कारण, WP सुरक्षा से संबंधित सभी प्लगइन्स।
- उपर्युक्त फोरम तक पहुंच बंद है।
- माईएसक्यूएल रूट के लिए नए पासवर्ड सेट किए गए हैं, ओएस उपयोगकर्ता के लिए जो पहले प्रशासनिक उद्देश्यों के लिए उपयोग किया जाता था, साथ ही साथ प्रत्येक 12 साइटों के व्यवस्थापक खातों के लिए।
गणना, इन सभी कार्यों के बाद, इस प्रकार थी। जैसे ही दुर्भावनापूर्ण कोड और गोले को साफ किया जाएगा, हम बस इंतजार करेंगे। यदि कुछ याद किया गया था और संक्रमण फिर से होता है, तो इसके स्रोत की गणना तुरंत की जा सकती है, क्योंकि सभी साइटें फ़ाइल सिस्टम और डेटाबेस में एक दूसरे से अलग-थलग हैं।
अब सफाई का समय था। सबसे पहले, एक सरल स्क्रिप्ट बनाई गई थी, जो कोड का एक हस्ताक्षर स्कैनर है। एक के बाद एक, मोटे आवेषणों को एक के बाद एक एकत्र किया गया और इसके आधार में रखा गया। बदले में, स्क्रिप्ट को कमांड पर सभी क्षतिग्रस्त फ़ाइलों को तुरंत साफ़ करना पड़ा। इस काम के लिए धन्यवाद, पुनर्निर्देशकों के लिए कई विकल्प पाए गए (उन्होंने खोज इंजन से आए लोगों के लिए काम किया) और एक iframe, जिसके बारे में ग्राहक ने शुरुआत में ही बात की थी। फिर मुकुट लिखा गया था, नियमित रूप से "सिस्टम (", "बेस 64_डॉस्क" (", इत्यादि)" "जैसे वाक्यांशों के लिए कंसोल उपयोगिताओं का उपयोग करने वाले साइटों के स्रोत कोड की जांच कर रहा था। यदि वे पाए गए थे, तो उन्हें व्यवस्थापक और मुझे मेल द्वारा रिपोर्ट करना था। यह कहने के लिए कि सभी वायरस बाधित नहीं हैं। WP थीम में (और प्रत्येक साइट पर वे मानक नहीं थे), ऐसे कई आवेषण पाए गए थे। उन्होंने कॉपीराइट हटाने के खिलाफ एक प्रकार की सुरक्षा का प्रतिनिधित्व किया था। झूठी सकारात्मकता से बचने के लिए मुझे उन्हें अपने सामान्य रूप में पुनर्स्थापित करना पड़ा।
उसके बाद, साइट कोड एक बार में साफ किए गए थे, दरवाजे और गोले हटा दिए गए थे ।htaccesss तय किए गए थे। कई दिनों के बाद, फ़ाइलों में कोई परिवर्तन नहीं देखा गया था, इसलिए समस्या को बंद माना जा सकता है।
और एक बात। दरवाजे के शोध की प्रक्रिया में, एक मेजबान पाया गया था जिसमें से उनकी सामग्री को http के माध्यम से लोड किया गया था। इस होस्ट पर, वेब सर्वर पर, अन्य हैक की गई साइटों के नामों के नाम पर कई निर्देशिकाएं थीं। त्वरित रूप से यह सुनिश्चित करने के लिए कि पहचाने गए डोमेन में भी द्वार हैं, मैंने उन्हें वेबमास्टर्स और प्रशासकों को लिखा। दुर्भाग्य से, मुझे एक भी उत्तर नहीं मिला है। उन पर दरवाजे के भरने को अभी भी संरक्षित किया गया है। लेकिन मैं वितरण सर्वर के साथ सामना करने में कामयाब रहा। यह वीडीएस निकला, जो एक यूक्रेनी कंपनी से किराए पर लिया गया था, जिसे एक शिकायत मिली थी, एक दो दिनों के लिए इसकी जांच की, और फिर नेटवर्क से इस सर्वर को काट दिया।
उपरोक्त सभी के आधार पर, मैं वेबमास्टर्स, साथ ही वेब संसाधन प्रशासकों को निम्नलिखित सिफारिशें देना चाहूंगा:
- डेटाबेस और ओएस स्तर दोनों में एक-दूसरे से अलग साइटें - संक्रमण के मामले में आप तुरंत संवेदनशील साइट की पहचान करेंगे, जिसका अर्थ है कि प्रारंभिक दोष तेजी से मिल जाएगा जिसके माध्यम से सर्वर को दुर्भावनापूर्ण कोड मिला।
- यदि आप Apache2 + PHP बंडल में काम करते हैं, तो इसे स्थापित करें ताकि प्रत्येक साइट की स्क्रिप्ट उसके मालिक (fcgi, cgi + suPHP, apache2-mpm-itk, आदि) की ओर से चलाए जाएं - इस तरह दुर्भावनापूर्ण कोड एक साइट पर नहीं जा सकेगा। दूसरों को संक्रमित करना।
- FTP को केवल उन पतों के लिए उपयोग करने की अनुमति दें जिनसे आप सर्वर के साथ काम करते हैं। यदि आप अचानक किसी यात्रा पर जाते हैं या अपने प्रदाता को बदलते हैं, तो आप हमेशा एसएसएच द्वारा आईपी श्वेतसूची को समायोजित कर सकते हैं।
- मजबूत पासवर्ड याद रखें। बहुत से रोबोट लगातार नेटवर्क पर काम कर रहे हैं, मानक लिंक का उपयोग करके एफ़टीपी सर्वर तक पहुंच के विवरण का चयन कर रहे हैं - व्यवस्थापक: व्यवस्थापक, site_name: ftppassword, आदि।
- वेब एप्लिकेशन इंस्टॉल करते समय, डॉक्यूमेंटेशन में निर्दिष्ट निर्देशिकाओं पर 777 को ध्यान से न रखें। यदि वेब सर्वर स्वामी की ओर से स्क्रिप्ट चलाता है, और इन निर्देशिकाओं में कुछ लिखता है, तो उन्हें लिखने की अनुमति हर किसी के लिए आवश्यक नहीं है, लेकिन केवल स्क्रिप्ट के स्वामी के लिए (एक नियम के रूप में, यह निर्देशिकाओं का मालिक भी है, इसलिए 700 भी हो सकता है पर्याप्त)।
- ठीक है, एक मानक वाक्यांश (वे कहते हैं कि यदि एक ही शब्द को किसी व्यक्ति को कई बार दोहराया जाता है, तो वे अवचेतन मन में गिर जाएंगे) - अपनी साइटों पर स्थापित वेब अनुप्रयोगों के अपडेट के लिए बने रहें। यदि संभव हो, तो उनकी सुरक्षा मेलिंग या समर्थन मंच के संबंधित अनुभागों की सदस्यता लें। वहाँ आप पैच की तुलना में बहुत पहले आ रही समस्या के बारे में पता लगा सकते हैं।
आपके समय के लिए धन्यवाद। मुझे उम्मीद है कि आपने इस लेख से कुछ उपयोगी सीखा है।