सवाल "संभावित BREAK-AT ATEMEMPT!" / Var / log / safe में - इसका क्या अर्थ है?


मेरे पास एक वीपीएस मंच पर एक CentOS 5.x बॉक्स चल रहा है। मेरे वीपीएस होस्ट ने कनेक्टिविटी के बारे में एक समर्थन पूछताछ का गलत व्याख्या किया और प्रभावी ढंग से कुछ iptables नियमों को फहराया। इसके परिणामस्वरूप मानक बंदरगाह पर एसएसएच सुनना और बंदरगाह कनेक्टिविटी परीक्षणों को स्वीकार करना पड़ा। कष्टप्रद।

अच्छी खबर यह है कि मुझे एसएसएच अधिकृत कुंजी की आवश्यकता है। जहां तक ​​मैं कह सकता हूं, मुझे नहीं लगता कि कोई सफल उल्लंघन हुआ था। मैं अभी भी / var / log / secure में जो देख रहा हूं उसके बारे में बहुत चिंतित हूं हालांकि:


Apr 10 06:39:27 echo sshd[22297]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:27 echo sshd[22298]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:31 echo sshd[22324]: Invalid user edu1 from 222.237.78.139
Apr 10 06:39:31 echo sshd[22324]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:31 echo sshd[22330]: input_userauth_request: invalid user edu1
Apr 10 13:39:31 echo sshd[22330]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:35 echo sshd[22336]: Invalid user test1 from 222.237.78.139
Apr 10 06:39:35 echo sshd[22336]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:35 echo sshd[22338]: input_userauth_request: invalid user test1
Apr 10 13:39:35 echo sshd[22338]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:39 echo sshd[22377]: Invalid user test from 222.237.78.139
Apr 10 06:39:39 echo sshd[22377]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:39 echo sshd[22378]: input_userauth_request: invalid user test
Apr 10 13:39:39 echo sshd[22378]: Received disconnect from 222.237.78.139: 11: Bye Bye

वास्तव में "संभावित BREAK-ATTEMPT" का क्या अर्थ है? यह सफल रहा था? या यह आईपी पसंद नहीं आया अनुरोध से आ रहा था?


86
2018-04-17 18:17


मूल




जवाब:


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


75
2018-04-17 22:06



धन्यवाद लैन उससे मुझे बेहतर महसूस होता है। मैं वास्तव में खुश हूं कि मुझे एसएसएच के लिए अधिकृत कुंजी की आवश्यकता है। =) - Mike B
"रिवर्स मैपिंग चेकिंग getaddrinfo" के लिए स्रोत आईपी / होस्टनाम तैयार किए गए हैं। एक ही तैयार यातायात खराब उपयोगकर्ता नामों का प्रयास कर रहा है, लेकिन खराब उपयोगकर्ता नाम "संभावित BREAK-IN ATTEMPT" संदेश उत्पन्न नहीं करते हैं। - poisonbit
@ माइकीबी: आप जोड़ना चाहते हैं fail2ban आपके लिए सिस्टम इन स्वचालित रूप से इन हमलावरों के आईपी पते को अवरुद्ध करने के लिए कॉन्फ़िगर किया जा सकता है। - Iain
@poisonbit: आपका अधिकार यह है कि एक रिवर्स लुकअप है जो बदले में एक रिकॉर्ड को हल नहीं करता है लेकिन दौर में यह एक ही स्वचालित हमले का हिस्सा है। - Iain
ध्यान दें कि 'रिवर्स मैपिंग असफल' का अर्थ यह हो सकता है कि उपयोगकर्ता के आईएसपी ने रिवर्स डीएनएस को सही तरीके से कॉन्फ़िगर नहीं किया है, जो काफी आम है। @ गाया का जवाब देखें। - Wilfred Hughes


विशेष रूप से "संभावित BREAK-IN ATTEMPT" भाग "रिवर्स मैपिंग जांच getaddrinfo विफल" भाग से संबंधित है। इसका मतलब है कि जो व्यक्ति कनेक्ट कर रहा था वह आगे नहीं था और DNS को सही तरीके से कॉन्फ़िगर किया गया था। यह काफी आम है, खासकर आईएसपी कनेक्शन के लिए, जहां वह "हमला" शायद आ रहा था।

"संभावित BREAK-IN ATTEMPT" संदेश से असंबंधित, व्यक्ति वास्तव में सामान्य उपयोगकर्ता नामों और पासवर्ड का उपयोग करने में तोड़ने की कोशिश कर रहा है। एसएसएच के लिए सरल पासवर्ड का प्रयोग न करें; वास्तव में पासवर्ड को पूरी तरह से अक्षम करने और केवल एसएसएच कुंजी का उपयोग करने का सबसे अच्छा विचार है।


49
2017-10-23 20:16



यदि यह किसी आईएसपी के माध्यम से एक (वैध) कनेक्शन द्वारा उत्पन्न होता है, तो आप इस रिवर्स मैपिंग त्रुटि से छुटकारा पाने के लिए अपने / etc / hosts फ़ाइल में एक प्रविष्टि जोड़ सकते हैं। जाहिर है आप केवल यह करेंगे अगर आपको पता था कि त्रुटि सौम्य है और आप अपने लॉग को साफ करना चाहते हैं। - artfulrobot


"क्या वास्तव में" संभावित BREAK-ATTEMPT "का अर्थ है?"

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

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

इन अलर्ट को अक्षम करने के लिए, आपके पास दो विकल्प हैं:

1) यदि आपके पास स्थिर आईपी है, अपने / etc / hosts फ़ाइल में अपना रिवर्स मैपिंग जोड़ें (अधिक जानकारी देखें यहाँ):

10.10.10.10 server.remotehost.com

2) यदि आपके पास गतिशील आईपी है और वास्तव में उन चेतावनियों को दूर करना चाहते हैं, अपने / etc / ssh / sshd_config फ़ाइल में "GSSAPIA प्रमाणीकरण हाँ" पर टिप्पणी करें।


30
2018-01-12 10:33



टिप्पणी GSSAPIAuthentication मेरे मामले में मदद नहीं करता है ( - SET


आप अपने लॉग को पढ़ने और जांचने में आसान बना सकते हैं रिवर्स लुकअप-अप बंद करना sshd_config में (UseDNS संख्या)। यह एसएसडीडी को "शोर" लाइनों को लॉग इन करने से रोक देगा, जिसमें "संभावित BREAK-IN ATTEMPT" शामिल है, जिससे आप "आईपीएडीएआरएक्स से अमान्य उपयोगकर्ता उपयोगकर्ता" युक्त कुछ और रोचक लाइनों पर ध्यान केंद्रित कर सकते हैं।


13
2018-04-17 18:23



सार्वजनिक इंटरनेट से जुड़े सर्वर पर एसएसडीडी रिवर्स लुकअप को अक्षम करने का नकारात्मक पक्ष क्या है? क्या इस विकल्प को सक्षम करने के लिए कोई उलझन है? - Eddie
@Eddie मुझे नहीं लगता कि एसएसडीडी द्वारा किए गए DNS लुकअप किसी भी उपयोगी उद्देश्य परोसता है। DNS लुकअप को अक्षम करने के दो अच्छे कारण हैं। लुकअप समय समाप्त होने पर DNS लुकअप लॉगिन को धीमा कर सकता है। और लॉग में "संभावित BREAK-AT ATTEMPT" संदेश भ्रामक हैं। उस संदेश का वास्तव में मतलब यह है कि क्लाइंट ने DNS को गलत कॉन्फ़िगर किया है। - kasperd
@kasperd UseDNS यदि आवश्यक है, तो किसी को होस्टनामों का उपयोग करना / चाहता है from= में निर्देश authorized_keys फ़ाइलें। - gf_
मैं @ ओलाफएम से असहमत हूं - "यूज डीएनएस नो" रिवर्स मैपिंग चेक न करने के लिए एसएसडीडी को बताता है और इसलिए यह सिस्टम लॉग में "संभावित BREAK-IN ATTEMPT" वाली कोई भी लाइन नहीं जोड़ देगा। साइड-इफेक्ट के रूप में यह मेजबान से कनेक्शन प्रयासों को भी तेज कर सकता है, इसके विपरीत रिवर्स डीएनएस सही तरीके से कॉन्फ़िगर नहीं किया गया है। - TimT
हाँ @ ओलाफएम मैंने लगभग 4-5 साल पहले लिनक्स पर किया था। यह मेरे लॉग को काफी छोटा कर दिया और बंद कर दिया logcheck बेकार ईमेल रिपोर्ट के साथ मुझे bugging। - TimT


यह एक सफल लॉगिन आवश्यक नहीं है, लेकिन यह "सकारात्मक" और "प्रयास" कहता है।

कुछ बुरे लड़के या स्क्रिप्ट किड्डी, आपको झूठी उत्पत्ति आईपी के साथ तैयार किए गए यातायात भेज रहे हैं।

आप अपनी एसएसएच कुंजी पर मूल आईपी सीमाएं जोड़ सकते हैं, और fail2ban जैसे कुछ कोशिश कर सकते हैं।


5



धन्यवाद। मेरे पास iptables सेट हैं जो केवल चयनित स्रोतों से एसएसएच कनेक्टिविटी की अनुमति देता है। मैं भी fail2ban स्थापित और चल रहा है। - Mike B