गैर-मौजूद URL के साथ बड़े पैमाने पर 404 हमला। इसे कैसे रोका जाए?

Question

समस्या 404 त्रुटियों का एक संपूर्ण भार है, जैसा कि Google वेबमास्टर टूल्स द्वारा रिपोर्ट किया गया है, ऐसे पृष्ठ और क्वेरी के साथ जो कभी नहीं रहे। उनमें से एक है viewtopic.php, और मैंने यह भी जांचने के प्रयासों की एक डरावनी संख्या पर गौर किया है कि क्या साइट एक वर्डप्रेस साइट ( wp_admin) है और cPanel लॉगिन के लिए है। मैं पहले से ही TRACE को ब्लॉक करता हूं, और सर्वर स्कैनिंग / हैकिंग के खिलाफ कुछ बचाव से लैस है। हालाँकि, यह रोक नहीं लगता है। Google वेबमास्टर के अनुसार, रेफ़रर है totally.me।

मैंने इसे रोकने के लिए एक समाधान की तलाश की है, क्योंकि यह निश्चित रूप से गरीब वास्तविक वास्तविक उपयोगकर्ताओं के लिए अच्छा नहीं है, अकेले एसईओ चिंताओं को छोड़ दें।

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

क्या किसी और को भी यही समस्या है, या क्या मैं यह देख रहा हूँ? क्या मुझे ऐसा लगता है, यानी किसी तरह का हमला? क्या इसे ठीक करने का एक तरीका है, या बेहतर है, इस बेकार संसाधन को रोकें?

EDIT मैंने उत्तर के लिए धन्यवाद करने के लिए प्रश्न का उपयोग नहीं किया है, और आशा है कि यह किया जा सकता है। आपके सभी सुखद जवाब के लिए धन्यवाद, जिसने मुझे इससे बाहर निकलने का रास्ता खोजने में मदद की। मैंने सभी के सुझावों का पालन किया है और निम्नलिखित को लागू किया है:

• एक हनीपोट
• एक स्क्रिप्ट जो 404 पृष्ठ में संदिग्ध यूआरएल सुनता है और मानक 404 हेडर लौटाते हुए मुझे उपयोगकर्ता एजेंट / आईपी के साथ एक ईमेल भेजता है।
• एक स्क्रिप्ट जो वैध उपयोगकर्ताओं को पुरस्कृत करती है, उसी 404 कस्टम पेज में, यदि वे उन यूआरएल में से किसी एक पर क्लिक करते हैं। 24 घंटे से कम समय में मैं कुछ संदिग्ध आईपी को अलग करने में सक्षम हो गया हूं, जो सभी स्पैमहास में सूचीबद्ध हैं। अब तक लॉग किए गए सभी आईपी स्पैम वीपीएस होस्टिंग कंपनियों के हैं।

आप सभी को फिर से धन्यवाद, मैं सभी उत्तरों को स्वीकार करता अगर मैं कर सकता था।

Comments

जब Google वेबमास्टर टूल कहता है कि रेफ़रर पूरी तरह से आप हैं, तो क्या आपका मतलब है कि वे संकेत कर रहे हैं कि आपकी साइट के पेज रेफ़र किए गए पेज हैं?

— स्टीफन Ostermiller

माफ कीजिएगा यह मेरी गलती है। मेरे पास ये पृष्ठ हैं जो कभी भी वेबमास्टर टूल पर मौजूद नहीं थे, और Google कहता है कि वे नहीं मिले हैं। उनमें से एक mysite.com/viewtopic.php?forget_the_value=1 है और पूरी तरह से जुड़ा हुआ है। मैंने भी क्लिक किया ... कुछ भी नहीं मिला।

— ततवमासी

गैर-मौजूद पृष्ठों के लिए आपके प्रवेश लॉग में 404 का बहुत अधिक होना आम है, कमजोरियों की जांच करना (जैसे। WP व्यवस्थापक) आदि - आपको यह सुनिश्चित करने की आवश्यकता है कि आपकी साइट सुरक्षित है। हालाँकि, इनके लिए GWT द्वारा सूचित किया जाना है, या तो इन पृष्ठों के लिंक हैं या आपके डोमेन पर पिछली साइट (जैसे वर्डप्रेस) होस्ट की गई थी?

— MrWhite

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

— tattvamasi

जब मैं कहता हूं "इन पृष्ठों के लिंक", मेरा मतलब अन्य साइटों से है । आपकी प्रत्येक 404 त्रुटियों के लिए (GWT में) आपको यह दिखाने के लिए नीचे ड्रिल करने में सक्षम होना चाहिए कि यह "कहां से जुड़ा हुआ है"।

— मृ

Answer 1

मैं अक्सर एक और साइट देखता हूं जो मेरी साइट पर उन टन पृष्ठों के लिंक है जो मौजूद नहीं हैं। भले ही आप उस पृष्ठ पर क्लिक कर रहे हों और लिंक न देख रहे हों:

• साइट पहले उन लिंक हो सकता है
• साइट केवल Googlebot को और आगंतुकों को नहीं, उन लिंक को क्लोकिंग और सेवारत किया जा सकता है

यह संसाधनों की बर्बादी है, लेकिन यह Google को भ्रमित नहीं करेगा और यह आपकी रैंकिंग को नुकसान नहीं पहुंचाएगा। यहाँ Google के जॉन मुलर (जो वेबमास्टर टूल और साइटमैप पर काम करता है) को 404 त्रुटियों के बारे में कहना है जो वेबमास्टर टूल में दिखाई देती हैं :

मदद! मेरी साइट 939 क्रैवल इरर्स !! 1 है

मैं सप्ताह में कई बार इस तरह का प्रश्न देखता हूं; आप अकेले नहीं हैं - कई वेबसाइटों में क्रॉल त्रुटियां हैं।

1. अमान्य URL पर 404 त्रुटियां किसी भी तरह से आपकी साइट की अनुक्रमण या रैंकिंग को नुकसान नहीं पहुंचाती हैं । इससे कोई फर्क नहीं पड़ता कि अगर 100 या 10 मिलियन हैं, तो वे आपकी साइट की रैंकिंग को नुकसान नहीं पहुंचाएंगे। http://googlewebmastercentral.blogspot.ch/2011/05/do-404s-hurt-my-site.html
2. कुछ मामलों में, क्रॉल त्रुटियां आपकी वेबसाइट या सीएमएस के भीतर एक वैध संरचनात्मक मुद्दे से आ सकती हैं। तुम बताओ कैसे? क्रॉल त्रुटि की उत्पत्ति को दोबारा जांचें। यदि आपके पृष्ठ के स्थिर HTML में आपकी साइट पर कोई टूटी हुई कड़ी है, तो वह हमेशा ठीक करने योग्य है। (धन्यवाद + मार्टिनो मोस्ना )
3. कायरतापूर्ण URL के बारे में क्या है जो "स्पष्ट रूप से टूट गया है?" जब हमारे एल्गोरिदम आपकी साइट को पसंद करते हैं, तो वे उस पर और अधिक महान सामग्री खोजने की कोशिश कर सकते हैं, उदाहरण के लिए जावास्क्रिप्ट में नए URL की खोज करने का प्रयास करके। यदि हम उन "URL" को आज़माते हैं और 404 पाते हैं, तो यह बहुत अच्छा और अपेक्षित है। हम बस कुछ भी महत्वपूर्ण याद नहीं करना चाहते हैं (सम्मिलित करें Googlebot मेम यहां डालें)। http://support.google.com/webmasters/bin/answer.py?answer=1154698
4. आपको वेबमास्टर टूल्स में क्रॉल त्रुटियों को ठीक करने की आवश्यकता नहीं है। यदि आप अपनी प्रगति पर नज़र रखना चाहते हैं तो "निशान के रूप में तय" सुविधा केवल आपकी मदद करने के लिए है; यह हमारी वेब-खोज पाइपलाइन में कुछ भी नहीं बदलता है, इसलिए यदि आपको इसकी आवश्यकता नहीं है, तो इसे अनदेखा करने के लिए स्वतंत्र महसूस करें। http://support.google.com/webmasters/bin/answer.py?answer=2467403
5. हम प्राथमिकता के आधार पर वेबमास्टर टूल्स में क्रॉल त्रुटियों को सूचीबद्ध करते हैं, जो कई कारकों पर आधारित है। यदि क्रॉल त्रुटियों का पहला पृष्ठ स्पष्ट रूप से अप्रासंगिक है, तो संभवतः आपको आगे के पृष्ठों पर महत्वपूर्ण क्रॉल त्रुटियां नहीं मिलेंगी। http://googlewebmastercentral.blogspot.ch/2012/03/crawl-errors-next-generation.html
6. आपकी वेबसाइट पर त्रुटियों को "ठीक" करने की कोई आवश्यकता नहीं है। 404 की खोज सामान्य है और एक स्वस्थ, अच्छी तरह से कॉन्फ़िगर की गई वेबसाइट से अपेक्षित है। यदि आपके पास एक नया URL है, तो इसके लिए पुनर्निर्देशन एक अच्छा अभ्यास है। अन्यथा, आपको नकली सामग्री नहीं बनानी चाहिए, आपको अपने होमपेज पर रीडायरेक्ट नहीं करना चाहिए, आपको रोबोट्स नहीं करना चाहिए। उन यूआरएल को अस्वीकार नहीं करना चाहिए - इन सभी चीजों से हमें आपकी साइट की संरचना को पहचानने और इसे ठीक से प्रोसेस करने में मुश्किल होगी। हम इन "नरम 404" त्रुटियों को कहते हैं। http://support.google.com/webmasters/bin/answer.py?answer=181708
7. जाहिर है - यदि ये क्रॉल त्रुटियां उन URL के लिए दिखाई दे रही हैं, जिनकी आप परवाह करते हैं, शायद आपकी साइटमैप फ़ाइल में URL हैं, तो यह वह चीज है जिस पर आपको तुरंत कार्रवाई करनी चाहिए। यदि Googlebot आपके महत्वपूर्ण URL को क्रॉल नहीं कर सकता है, तो वे हमारे खोज परिणामों से हटाए जा सकते हैं, और हो सकता है कि उपयोगकर्ता उन्हें एक्सेस न कर सकें।

Comments

धन्यवाद, हालांकि मैंने यह दावा करते हुए किसी के बारे में पढ़ा है कि 404 के हमले ने उनके पेज रैंक (Google वेबमास्टर फोरम पर चर्चा को नकारात्मक रूप से प्रभावित किया था, जैसे ही मैं इसे पुनः प्राप्त करूँगा मैं इसे यहाँ पोस्ट करूँगा), और कुछ का दावा है कि 404 त्रुटियां गिनाती हैं (Google सब कुछ नहीं कहता है, ये लोग दावा करते हैं), इसलिए यह मेरी चिंताओं में से एक है, और दूसरा सवाल यह है कि कौन व्यक्ति बड़े पैमाने पर मेरी साइट पर गलत लिंक ट्वीट कर रहा है, और क्यों, अगर यह एसईओ के लिए कुछ भी नहीं करना चाहिए? उत्तर स्वीकार किया :)

— ततवमासी

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

— क्लोजनेटॉक

एक "404 हमला" निश्चित रूप से आपकी साइट के पेजरैंक को प्रभावित नहीं करेगा, न ही इसकी रैंकिंग। (यदि आपके प्रतियोगी 404 पृष्ठों को जोड़ने के लिए समय व्यतीत कर रहे हैं, तो यह कम समय है कि वे कुछ उपयोगी काम करने में खर्च कर रहे हैं, इसलिए खुश रहें :))। साइटें माना जा रहा है कि 404s हैं, यह एक संकेत है कि आपने सर्वर ठीक से सेट किया है , तो अगर कुछ भी, यह हमारे लिए एक अच्छा संकेत होगा।

— जॉन म्यूलर

Answer 2

वहाँ बाहर लिपियों के टन कर रहे हैं कि इंटरनेट पर विभिन्न प्रकार के सॉफ्टवेयर में ज्ञात कमजोरियों को खोजने के लिए इंटरनेट पर यादृच्छिक आईपी पते स्कैन करते हैं। 99.99% समय, वे कुछ भी नहीं पाते हैं (जैसे कि आपकी साइट पर), और उस 0.01% समय के साथ, स्क्रिप्ट मशीन को pwn करेगी और स्क्रिप्ट कंट्रोलर को जो भी करना है वह करेगी। आमतौर पर, इन लिपियों को उन मशीनों से बेनामी बोटनेट द्वारा चलाया जाता है जो पूर्व में मूल स्क्रिप्ट किडी की वास्तविक मशीन से नहीं, बल्कि pwnd की गई हैं।

आपको क्या करना चाहिये?

1. सुनिश्चित करें कि आपकी साइट असुरक्षित नहीं है। इसके लिए निरंतर सतर्कता की आवश्यकता है।
2. यदि यह इतना लोड उत्पन्न करता है कि सामान्य साइट का प्रदर्शन प्रभावित होता है, तो विशेष साइट से कनेक्शन स्वीकार करने से बचने के लिए एक आईपी-आधारित ब्लॉकिंग नियम जोड़ें।
3. CMD.EXE या cPanel या phpMyAdmin या अन्य कमजोरियों के टन के लिए स्कैन को फ़िल्टर करना सीखें जब आपके सर्वर लॉग के माध्यम से देखते हैं।

आप ऐसा मानते हैं कि आपके सर्वर से किसी भी व्यक्ति के लिए लौटाया गया कोई भी 404 प्रभाव पड़ेगा कि Google आपकी साइट के बारे में क्या सोचता है। यह सच नहीं है। Google क्रॉलर और शायद क्रोम उपयोगकर्ताओं द्वारा लौटाए गए केवल 404, आपकी साइट को प्रभावित करेंगे। जब तक आपकी साइट के सभी लिंक उचित लिंक हैं, और आप उन लिंक को अमान्य नहीं करते हैं जिन्हें आपने पहले दुनिया के सामने उजागर किया है, तो आपको कोई प्रभाव नहीं दिखेगा। स्क्रिप्ट बॉट Google से किसी भी तरह से बात नहीं करते हैं।

यदि आपको वास्तविक तरीके से हमला हो रहा है, तो आपको कुछ प्रकार की DoS शमन प्रदाता सेवा के लिए साइन अप करना होगा। Verisign, Neustar, CloudFlare, और Prolexic सभी विक्रेता हैं जिनके पास विभिन्न प्रकार के हमलों के लिए विभिन्न प्रकार की योजनाएं हैं - साधारण वेब प्रॉक्सिंग (जो कुछ प्रदाताओं से मुक्त भी हो सकते हैं) से लेकर DNS तक ऑन-डिमांड फ़िल्टरिंग, पूर्ण BGP पर आधारित आधारित बिंदु-की-उपस्थिति झूलों जो हमलों को कम करने वाले नियमों के साथ "स्क्रबिंग" डेटा केंद्रों के माध्यम से आपके सभी ट्रैफ़िक को भेजता है।

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

Comments

बहुत बहुत धन्यवाद - मैं कुछ अतिरिक्त फिल्टर की तलाश करूंगा, हालांकि सर्वर और साइट की सुरक्षा इतनी अधिक है कि कभी-कभी एक वैध उपयोगकर्ता पहले से ही निषिद्ध पृष्ठ पर समाप्त होता है। "Google क्रॉलर, और शायद क्रोम उपयोगकर्ताओं द्वारा लौटाए गए केवल 404" के जवाब में, मुझे यह जोड़ना होगा कि मुझे Google वेबमास्टर टूल में वे लिंक मिले, इसलिए मुझे लगता है कि मैं सुरक्षित रूप से मान सकता हूं कि उन्हें क्रॉल किया जा रहा है ...

— tattvamasi

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

— जॉन वाट ने

Answer 3

यह वास्तव में एक हमला नहीं है, लेकिन एक स्कैन या जांच है।

स्कैनर / प्रोबेर के आधार पर, यह सौम्य हो सकता है, जिसका अर्थ है कि यह केवल कुछ प्रकार की अनुसंधान क्षमता में मुद्दों की तलाश कर रहा है या यदि यह एक उद्घाटन पाता है तो स्वचालित रूप से हमला करने के लिए एक फ़ंक्शन हो सकता है।

वेब ब्राउज़र वैध रेफ़रर जानकारी डालते हैं, लेकिन अन्य प्रोग्राम्स को केवल जो भी रेफ़र पसंद करते हैं, कर सकते हैं।

रेफ़रलकर्ता केवल जानकारी का एक टुकड़ा है जो वैकल्पिक रूप से आपके वेब साइट तक पहुंचने वाले कार्यक्रमों द्वारा प्रदान किया जाता है। यह कुछ भी हो सकता है वे इसे इस तरह सेट करना पसंद करते हैं totally.meया random.yu। यह एक वास्तविक वेब साइट भी हो सकती है जिसे उन्होंने अभी चुना है।

आप वास्तव में इसे ठीक नहीं कर सकते या इसे रोक नहीं सकते। यदि आपने इस प्रकार के प्रत्येक अनुरोध को अवरुद्ध करने का प्रयास किया है, तो आप एक बहुत बड़ी सूची बनाए रखने के लिए समाप्त हो गए हैं और यह इसके लायक नहीं है।

जब तक आपका मेजबान पैच के साथ रहता है और कमजोरियों को रोकता है, इससे आपको कोई वास्तविक समस्या नहीं होनी चाहिए।

Comments

यदि Google WMT में 404 का प्रदर्शन होता है, तो यह कहीं न कहीं एक वास्तविक लिंक से है। पूरी तरह से .me एक वास्तविक साइट है।

— क्लोजनेटॉक

हाँ पूरी तरह से। एक वास्तविक साइट है, और वहाँ से आने वाले कुछ गलत लिंक मेरी गलती (ट्वीट बटन में टाइपो) थे। अब इस द्रव्यमान को एक viewtopic.php / से लिंक किया जा रहा है? मेरी साइट पर जो भी पेज है, जो मैं कसम खाता हूं वह कभी नहीं रहा। मैं उस उपयोगकर्ता की पहचान भी कर सकता हूं जिसने ट्वीट किया था कि (उस पृष्ठ पर अब कुछ भी नहीं है, लेकिन मुझे लगता है कि बहुत कुछ था)। ट्रेंडिंग टैग भी एक जानबूझकर गलत यूआरएल था। मुझे चिंता का विषय यह है कि उपयोगकर्ता अनुभव, संसाधन उपयोग, और यह देख रहा है कि Google उन नकली 404 को क्रॉल कर रहा है। मैं पूरी दुनिया को एक नहीं मिल रहे पृष्ठ के लिए प्रतिबंधित कर सकता हूं, दूसरी ओर। क्या करना है, यह सुनिश्चित नहीं है।

— तत्त्वमसि

Answer 4

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

प्रश्न: आप अपनी साइट से ४०४ को पूरे Google वेबमास्टर टूल में कैसे देख रहे हैं? GWT Googlebots निष्कर्षों का आउटपुट है, अन्य बॉट्स का आउटपुट नहीं। इसके अलावा, जो अन्य बॉट जेएस एनालिटिक्स के लिए नहीं चलते हैं ... क्या आपके पास GWT के लिए कुछ थोड़े एपीआई चीज़ हैं जहां आप अपने सर्वर आँकड़े देख सकते हैं? यदि नहीं, तो यह अलार्म का कारण हो सकता है क्योंकि यह googlebot स्वयं त्रुटियां ढूंढ रहा है।

• यदि यह सिर्फ Googlebot की त्रुटियां हैं, तो यह संकेत दे सकता है कि किसी ने आपकी साइट पर लिंक लगाए थे और दुर्भावनापूर्ण वास्तविक-मानव-पीसी बॉट के लक्ष्यों के लिए इसे मार दिया था। कुछ शोषित सर्वर पर चलने वाले हार्सस्टोर + प्लानर के बारे में सोचें, जिससे भविष्य में "स्पैम कॉन्ट्रैक्ट्स" के लिए एक टन का लक्ष्य पोर्टल के माध्यम से स्थापित हो सके।

• यदि आप वास्तव में जानते हैं कि इसकी रिपोर्टिंग आपके पूर्ण सर्वर आँकड़े हैं, तो आपको कुछ टूल की आवश्यकता है। कुछ ऐप और सेवाएं आपको इसे ट्रिम करने में मदद कर सकती हैं। मान लें कि आप एक लिनक्स सर्वर चला रहे हैं:

1) एक htaccess ब्लैकलिस्ट करने के लिए अपमानजनक आईपी जोड़ने शुरू। ऐसा लगता है कि "192.168.1.1 से इनकार" और 403 उन्हें मना करेंगे। न सिर्फ दूर biggens ब्लॉक किया जाता है। चरण 4 में साइटों के खिलाफ उनकी जाँच करें) यह सुनिश्चित करने के लिए कि वे आईएसपी के असली खूंटे हैं। आप इस फ़ाइल को कॉपी कर सकते हैं और इसे फ़ायरवॉल से परे किसी भी खाते / ऐप पर चिपका सकते हैं।

2) APF इंस्टॉल करें। लिनक्स में SSH के माध्यम से फ़ायरवॉल का प्रबंधन करना आसान है। जैसा कि आप ht का निर्माण करते हैं, उन्हें एपीएफ में जोड़ें जैसे "एपीएफ-डी 192.168.1.1"। APF की वजह से Ht बेमानी लगता है, लेकिन Ht पोर्टेबल है।

3) cPanel हल्क स्थापित करें और अपने आईपी को श्वेतसूची में सुनिश्चित करें ताकि यदि आप एक पास भूल जाते हैं तो यह आपको कभी भी लॉक न करें। यह भी ht + apf में जोड़ने के लिए आईपी का एक अच्छा स्रोत होगा। यह करने के लिए कुछ होशियार है तो यह समझदारी से जानवर बल लॉगिन प्रयासों को कम कर सकते हैं।

4) stopforumspam.com और projecthoneypot.org के साथ हुक अप करें और अपने मॉड्यूल को चलाएं। दोनों को ज्ञात अनुरोधों को अस्वीकार करने और नए ब्रूट्स / नेट / चिनस्पैम की पहचान करने में मदद करने के लिए बहुत मदद मिलती है। ऐसे ईमेल फ़िल्टर हैं जिनका आप भी उपयोग कर सकते हैं, लेकिन स्पैम फ़िल्टर की बात आने पर जीमेल इसका मालिक है।

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

• कैप्चा के बारे में एक नोट, यदि आप एक उच्च वॉल्यूम साइट पर अपना स्वयं का कैप्चा चलाते हैं और फ़ायरवॉल / ht स्तर पर बॉट उन्माद को अस्वीकार नहीं करते हैं, तो वे उन सभी "एंटीस्पैम" विजेट में छवि निर्माण के कारण आपके सीपीयू चक्र को हथौड़ा दे सकते हैं।

• लोड के बारे में एक नोट, यदि आप अपने सर्वर पर CentOS चलाते हैं, और VPS क्षमताएं हैं, तो CloudLinux सख्त और लोड नियंत्रण के लिए शानदार है। कहते हैं कि एक बॉट के माध्यम से हो जाता है, CageFS इसे एक खाते में सीमित करने के लिए है। कहते हैं कि वे DDoS को तय करते हैं .... LVE खाता (साइट) लोड को अपने सर्वर को क्रैश न करने के लिए रखने के लिए है। इसका एक अच्छा जोड़ "गलत निकाय प्रबंधन" की पूरी प्रणाली का उच्चारण करना है :)

बस कुछ विचार, मुझे आशा है कि आपकी मदद करता है

Comments

धन्यवाद। तथ्य यह है कि मैं Google वेबमास्टर्स पर उन त्रुटियों को देखता हूं मुझे लगता है - जैसा कि आप सही ढंग से बताते हैं - कि "एनएसईओ" तकनीक के कुछ प्रकार हैं (मेरी साइट पर सैकड़ों लिंक लगाए हैं जो कभी नहीं रहे हैं)। साइट सुरक्षित है, क्योंकि उन प्रकार के हमले कुछ भी नहीं करते हैं। मुझे यकीन नहीं है कि मैं एसईओ / उपयोगकर्ता अनुभव के लिए सुरक्षित हूं (यदि Google कोई भी पृष्ठों को अनुक्रमित नहीं करना शुरू करता है जो मैं दोहरे में हूं। यह त्रुटियां पहले ही साइट को रैंक, बीडब्ल्यूटी में गिरा चुकी हैं)। एक बार फिर धन्यवाद।

— तत्त्वमसि

Gbot अभिप्राय 404 पृष्ठों पर नहीं है, तो यह वास्तव में आपके SEO को प्रभावित नहीं करेगा। यह ट्रैफ़िक भेजने वाले अन्य पृष्ठों को कैश कर सकता है, लेकिन आपका नहीं। अगर यह वास्तविक मनुष्यों के लिए एक मुद्दा बन जाता है, तो wp-admin जैसे बंक लिंक के लिए एक बड़ा पुनर्निर्देशक बनाएं, उन सभी को मनुष्यों के लिए एक अच्छा लेखन में भूमि दें, क्योंकि वे इस पृष्ठ को क्यों देख रहे हैं। यदि आप ईकॉम करते हैं, तो उन्हें "404 के लिए क्षमा करें" कूपन दें। बस उन सभी को GWT में तय करने के लिए याद रखें ताकि यह आपके नए लैंडर को कैश / इंडेक्स करेगा। वैकल्पिक रूप से इस पर badbots के लिए एक ब्लैकहोल डाल दिया। भले ही, डायरेक्ट हिट के लिए तैयार रहें अगर इस स्पैमनेट में आपके लिए लिंक हैं।

— dhaupin

धन्यवाद। अभी के लिए मैं यह देखने की कोशिश कर रहा हूं कि क्या त्रुटियों के मामले में एक नरम 404 मैंने उत्पन्न किया है जो गंदगी को थोड़ा कम करता है। 404 पृष्ठ पहले से ही एक कस्टम है और आपको उपयोगी संबंधित लिंक देगा (यदि यह उन्हें मिल सकता है)। मेरे द्वारा गलत वर्तनी के मामले में, मैं 301 रीडायरेक्ट को सही पृष्ठ पर फेंक रहा हूं (Google उन्हें नरम 404 मुझे लगता है) के रूप में देखता है। इस कबाड़ के मामले में /RK=0/RS=YkUQ9t4mR3PP_qt7IW8Y2L36PFo-/, /blog/wp-login.php/, /user/create_form/, /m/, /RK=0/RS=lznPhspsSDFHMiuIUDmmo01LA7w-/(आदि ...) मैं उपयोगकर्ता प्रवेश करने कर रहा हूँ और लौटने 404. आशा मैं इसे सही कर रहा हूँ

— tattvamasi

Answer 5

समस्या का स्पष्टीकरण

सबसे पहले आप केवल इस समस्या वाले नहीं हैं - हर कोई है। आपने जो देखा है वह हर आईपी को रेंगने वाले स्वचालित बॉट का परिणाम है और आम कमजोरियों की तलाश है। इसलिए वे मूल रूप से यह जानने की कोशिश करते हैं कि आप किन चीजों का उपयोग कर रहे हैं और यदि आप phpmyadmin का उपयोग करते हैं तो वे बाद में मानक उपयोगकर्ता नाम पासवर्ड संयोजनों का एक गुच्छा करने का प्रयास करेंगे।

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

एसईओ प्रभाव

इसका कोई असर नहीं हुआ। इसका सीधा सा मतलब है कि किसी ने आपके कंप्यूटर पर कुछ एक्सेस करने की कोशिश की और वह वहां नहीं था

क्या यह वास्तव में मायने रखता है?

निश्चित रूप से, ये लोग आपको कुछ समस्याओं के लिए जाँच करने का प्रयास करते हैं। इसके अलावा वे आपके संसाधनों को बर्बाद कर रहे हैं (आपके सर्वर को किसी तरह से प्रतिक्रिया करने की आवश्यकता है) और आपकी लॉग फ़ाइल को विचलित कर रहा है

मैं इसे कैसे ठीक करूं

मुझे वही समस्या थी जिसे मैंने ठीक करने की कोशिश की और सबसे अच्छा उपकरण (उपयोग करने के लिए सरलता बनाम मैं इसके साथ क्या कर सकता हूं) मुझे असफलता मिली

आप काफी भाग्यशाली हैं क्योंकि मुझे पहले से ही उसी समस्या को ठीक करने का एक तरीका मिल गया है और यहां तक ​​कि इसे दस्तावेज भी किया गया है (इसलिए आपको यह पता लगाने की आवश्यकता नहीं है कि इसे कैसे स्थापित किया जाए और इसे कैसे काम किया जाए)। ServerFault पर मेरे सवाल की जाँच करें । लेकिन कृपया यह जानने के लिए कि क्या यह काम कर रहा है, कृपया विफल 2ban के बारे में थोड़ा पढ़ें।

Answer 6

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

आप क्लाउड आधारित DNS WAF या समर्पित उपकरणों का उपयोग कर सकते हैं। मैं व्यक्तिगत रूप से विभिन्न ग्राहक साइटों के लिए इनकैप्सुला और एफ 5 एएसएम का उपयोग करता हूं। लागत $ 500 प्रति माह के रूप में कम है और काफी मदद करता है। यह आपके ग्राहकों को बेहतर सुरक्षा भी देता है और खुद को वेब सर्वर पर संसाधनों को कम करता है जो आपको पैसे बचाने और गति बढ़ाने में मदद करता है, साथ ही ये डिवाइस पीसीआई 6.6 अनुपालन और रिपोर्ट के साथ समीक्षा करते हैं।

उम्मीद है की यह मदद करेगा।

Comments

यदि यह केवल "जांच करने का प्रयास" था, तो आप इस तथ्य को कैसे समझाते हैं कि इन 404 को जाहिरा तौर पर GWT में रिपोर्ट किया गया था?

— Mrhhite