क्या यह हैक प्रयास है?

Question

अपने 404 लॉग के माध्यम से मैंने निम्नलिखित दो URL देखे, जो दोनों एक बार हुए:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

तथा

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

प्रश्न में पृष्ठ library.php, typeएक आधा दर्जन विभिन्न स्वीकार्य मूल्यों के साथ एक चर की आवश्यकता है , और फिर एक idचर। तो एक मान्य URL हो सकता है

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

और mysql_real_escape_stringडेटाबेस को क्वेरी करने के लिए उपयोग किए जाने से पहले आईडी सभी के माध्यम से चलाए जाते हैं ।

मैं एक बदमाश हूं, लेकिन मुझे लगता है कि ये दोनों लिंक वेबरोट के खिलाफ सरल हमले हैं?

1) 404 के अलावा इस तरह की चीजों से बचाव करना कितना अच्छा है?

2) क्या मुझे आईपी को अनुमति देना चाहिए?

संपादित करें: यह भी सिर्फ एक ही देखा

/library.php=http://www.basfalt.no/scripts/danger.txt

EDIT 2: सभी 3 हमलों के लिए अपमानजनक आईपी 216.97.231.15जो कि लॉस एंजिल्स के ठीक बाहर स्थित लूनर पेज नामक आईएसपी के लिए था ।

EDIT 3: मैंने आईएसपी को शुक्रवार सुबह स्थानीय समय पर कॉल करने का फैसला किया है और इस मुद्दे पर चर्चा की कि मैं फोन पर किससे मिल सकता हूं। मैं 24 घंटे या तो यहाँ परिणाम पोस्ट करूँगा।

EDIT 4: मैंने उनके प्रवेश को ईमेल किया और उन्होंने पहले जवाब दिया कि "वे इसे देख रहे थे" और फिर एक दिन बाद "इस मुद्दे को अब हल किया जाना चाहिए।" कोई और जानकारी नहीं, दुख की बात है।

Comments

Adnrew, क्या मुझे यह सही है कि यह /library.php स्क्रिप्ट में क्वेरी स्ट्रिंग से कुछ भी शामिल नहीं है? इस स्थिति में आप सुरक्षित हैं

— Col. Shrapnel

Library.php मेरी अपनी साइट द्वारा उत्पन्न लिंक को संभालता है। typeस्क्रिप्ट जो उपयोग करने के लिए शामिल हैं बताता है (हालांकि एक के माध्यम से IF $_GET['type'] == 'thing') {} ESLE..., नहीं की तरह एक सीधा लिंक के रूप में include 'type.php') और idmysql_real_escape_string के माध्यम से चलाने के लिए और है कि प्रश्नों के लिए प्रयोग किया जाता है। यह जानते हुए कि, क्या मैं अभी भी सुरक्षित हूं?

क्या कोई समझा सकता है कि हमलावर वास्तव में क्या पता लगाने की कोशिश कर रहा है? सभी उत्तरों के प्रश्न में एक संक्षिप्त सारांश बहुत अच्छा होगा।

— बेजरो

Answer 1

०) हाँ। बहुत कम से कम, यह आपकी साइट के खिलाफ एक व्यवस्थित जांच है जो यह पता लगाने की कोशिश कर रहा है कि क्या यह असुरक्षित है।

1) यह सुनिश्चित करने के अलावा कि आपका कोड साफ है, ऐसा बहुत कुछ नहीं है जो आप कर सकते हैं, लेकिन यह सुनिश्चित करने के लिए अपने होस्ट के खिलाफ अपने परीक्षण चलाएं कि यह सुरक्षित है। Google स्किपफिश आपको वहां मदद करने वाले कई उपकरणों में से एक है।

2) मैं होता।

Comments

0)संकेतन के बारे में : अच्छा !! मैंने ऐसा कभी नहीं सोचा था।

@polygenelubricants मुझे यकीन है कि आप के बारे में सोचा नहीं होता -1)या 0.5)या π)या 2 + 3i)अंकन या तो। : पी

— मतीन उलहाक

Answer 2

यह एक हमला है, यह यहाँ बहुत समझाया गया है ।

Answer 3

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

उन बॉटनेट्स को हाथ से बनाना सबसे असंभव है, क्योंकि बॉटनेट हजारों यूनिक आईपी एड्रेस का इस्तेमाल कर सकते हैं, इसलिए अगर आप उन पर प्रतिबंध लगाना चाहते हैं, तो आपको किसी तरह के स्वचालित प्रतिबंध कार्यक्रम का उपयोग करना होगा। मेरे दिमाग में fail2ban आता है; mod_security घटनाओं या कुछ अन्य लॉग प्रविष्टियों पर प्रतिक्रिया करने के लिए इसे बनाएं।

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

• mod_security एक अपाचे मॉड्यूल है जो सभी प्रकार के विशिष्ट हैकिंग प्रयासों को फ़िल्टर करता है। यह आउटबाउंड ट्रैफ़िक को भी प्रतिबंधित कर सकता है (यदि आपका सर्वर क्लाइंट को भेज रहा है) तो यह संदिग्ध जावास्क्रिप्ट आदि को देखता है।

• PHP को सख्त करने के लिए सुहोसिन ।

• अपने PHP स्क्रिप्ट को एक उपयोगकर्ता के रूप में चलाएं जो स्क्रिप्ट का मालिक है; suphp और php-fpm जैसी चीजें संभव बनाती हैं।

• अपने वेबरोट और PHP अस्थायी निर्देशिका को noexec, nosuid, नोडव के रूप में माउंट करें ।

• सिस्टम और passthru जैसे अनावश्यक PHP फ़ंक्शन अक्षम करें ।

• अनावश्यक PHP मॉड्यूल अक्षम करें। उदाहरण के लिए, यदि आपको IMAP समर्थन की आवश्यकता नहीं है, तो इसे सक्षम न करें।

• अपने सर्वर को अपडेट रखें।

• लॉग पर नजर रखें।

• सुनिश्चित करें कि आपके पास बैकअप है।

• यदि कोई व्यक्ति आपको हैक करता है या कोई अन्य आपदा आपको मारती है, तो उसकी योजना बनाएं।

यह एक अच्छी शुरुआत है। फिर और भी चरम उपाय हैं जैसे कि स्नॉर्ट और प्रस्तावना , लेकिन वे अधिकांश सेटअपों के लिए बहुत अधिक हो सकते हैं।

Answer 4

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

Answer 5

जैसा कि पहले ही कहा गया है - यह अधिक informations प्राप्त करने के लिए / proc / self / environ फ़ाइल को प्राप्त करने का प्रयास है।

मुझे लगता है यह एक linux मशीन है:

आपको उपयोग करना चाहिए

• suhosin ( http://www.hardened-php.net/suhosin/ ) - php स्क्रिप्ट की सुरक्षा करता है
• PHP ओपनबेडिर प्रतिबंध का उपयोग करें
• fail2ban http://www.fail2ban.org/

आप एक हमलावर सर्वर के आईपी को ब्लॉक कर सकते हैं, लेकिन आपको यह विचार करना चाहिए कि यह सुविधा में गैर-हमलावर हो सकता है।

जब मेरा सर्वर अटैक हो रहा हो तो मैं कुछ सेवाओं को ब्लॉक करता था: http / https / pop / imap / ssh लेकिन smtp को खुला छोड़ दें, ताकि गलती होने पर आपको सूचित किया जा सके।

Comments

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

— सिम्बियन

हमेशा निहितार्थ होते हैं। इसे वैसे ही छोड़ दें और आप हैक हो सकते हैं। अपने सर्वर को सुरक्षित रखें और सुरक्षा कार्यक्रमों के कारण होने वाली समस्याओं का सामना करें। लेकिन किसी भी तरह - एक वेब सुलभ सिस्टम पर सुरक्षा एक बड़ी चिंता है!

— एंड्रियास रेहम

Answer 6

हां यह घुसपैठ की कोशिश है। आपको निश्चित रूप से आईपी पर प्रतिबंध लगाना चाहिए। यदि आप यह निर्धारित करते हैं कि आईपी देश से बाहर है, तो आप बस उसी सबनेट पर प्रतिबंध लगाना चाहते हैं जो उसका है। यह सर्वर की समस्या होने की तुलना में कम कोड समस्या है। इस विशेष घुसपैठ को देखें और सुनिश्चित करें कि आपका होस्टिंग प्रदाता इसे या इसी तरह की स्क्रिप्ट किडी प्रयासों के लिए असुरक्षित नहीं है (जो कि ऐसा दिखता है)।

Answer 7

यह आपके वेब सर्वर के माध्यम से सुलभ सर्वर-साइड स्क्रिप्ट में एक संभावित मनमानी स्थानीय फ़ाइल समावेशन भेद्यता का फायदा उठाने का प्रयास है । एक कमजोर लिनक्स सिस्टम पर /proc/self/environमनमाने कोड सर्वर-साइड को निष्पादित करने के लिए दुरुपयोग किया जा सकता है।

Answer 8

जेने पिक्कारेनेन द्वारा अनुशंसित:

लॉग पर नजर रखें।

सुनिश्चित करें कि आपके पास बैकअप है।

इन लॉग के हिस्से के रूप में, आपकी वेबसाइट सहित किसी भी फाइल के बदलावों की निगरानी करना महत्वपूर्ण है, एक घुसपैठ का पता लगाने वाले सिस्टम के हिस्से के रूप में। एक उदाहरण OpenBSD है जो डिफ़ॉल्ट फ़ाइलों के लिए डिफ़ॉल्ट रूप से ऐसा करता है। मैं इसे ऊपर लाता हूँ क्योंकि:

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