मेरी पहुंच लॉग में अचानक इतने सारे 400 अनुरोध क्यों थे?

Question

नीचे मेरे एक्सेस_लॉग का बहुत कम हिस्सा है

118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
05
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
06
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
07
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
08
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
09
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
10
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
11
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
12
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
13
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
14
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"

और आयतन बहुत बड़ा था, कुछ इस तरह के एक सौ हजार प्रति सेकंड का अनुरोध। और मुझे पूरा यकीन है कि उस समय की अवधि में मेरी साइट पर कोई त्रुटि नहीं है। (कोई त्रुटि रिपोर्ट नहीं है और मैंने स्रोत कोड नहीं बदला है)

Answer 1

कोई व्यक्ति आपके सर्वर को फज कर रहा था । विकिपीडिया भी देखें ।

मूल रूप से यह देखने के लिए कि क्या कुछ टूटता है, अवैध डेटा के तेजी से ब्लॉक भेजना शामिल है।

जब कोई अनुरोध डेटा नहीं भेजा जाता है, तो Nginx एक 400 त्रुटि त्रुटि वापस करने के लिए सेट है।

इसके बारे में चिंता मत करो। Nginx सिर्फ एक पसीने को तोड़ने के बिना उन्हें हमेशा के लिए शेख़ी कर सकते हैं।

Comments

केवल एक चीज के बारे में उसे चिंता होगी कि लॉग फाइल डिस्क स्थान को अवशोषित करती है। यह वह जगह है जहाँ उचित लॉग रोटेशन सहायक होता है।

— जस्टिन पीयर्स

यहां भी यही समस्या। अलग-अलग आईपी पते की मात्रा मेरे विचार में एक हमले (फ़ज़िंग) को बहुत संभावित नहीं बनाती है। फिर भी बेहतर स्पष्टीकरण की तलाश में।

— ओलिवर

Answer 2

जांचें और देखें कि क्या 400 के कारण आईपी पता Google Chrome का उपयोग कर रहा है। क्रोम सर्वर के साथ कई कनेक्शन स्थापित करने के लिए प्री-कनेक्शन का उपयोग करता है, और उपयोग न होने पर उन्हें बंद कर देता है।

चूंकि कनेक्शन में कोई अनुरोध नहीं किया गया है, इसलिए nginx इस त्रुटि को रिकॉर्ड करेगा।

Comments

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

— ओलिवर

उपयोगकर्ता एजेंट को अनुरोध हेडर के रूप में भेजा जाता है, जब तक कि अनुरोध नहीं किया जाता है, तब तक उपयोगकर्ता एजेंट स्ट्रिंग को जानने और लॉग इन करने के लिए nginx का कोई मतलब नहीं है। हालाँकि, आप उस IP पते से आए अन्य लॉग रिकॉर्ड्स की जाँच कर सकते हैं और यदि कोई वास्तविक अनुरोध वास्तव में उस क्लाइंट द्वारा किया गया है, तो यह जानें कि वह क्रोम था या नहीं।

— इवान अनिशचुक