सवाल प्रति दिन सैकड़ों ब्रेक-इन प्रयासों को प्राप्त करना सामान्य बात है?


मैंने अभी अपने सर्वर की जांच की है /var/log/auth.log और पाया कि मुझे प्रति दिन 500 से अधिक विफल पासवर्ड / ब्रेक-इन प्रयास अधिसूचनाएं मिल रही हैं! मेरी साइट छोटी है, और इसका यूआरएल अस्पष्ट है। क्या यह सामान्य है? क्या मुझे कोई उपाय करना चाहिए?


196
2018-03-08 11:26


मूल


जब तक हम सभी अनावश्यक बाहरी बंदरगाहों को बंद नहीं करते, मुझे याद है कि हमें न केवल बहुत सारे हैक प्रयास मिलते हैं, लेकिन एक दिन यह इतना बुरा था कि हमें दो अलग-अलग देशों से हैक किया जा रहा था - एक ही समय में! तो हाँ, 100-ब्रेक-इन प्रयास पूरी तरह सामान्य हैं। - Django Reinhardt
हमारे पास ऐसे सर्वर हैं जो प्रत्येक 16 सेकंड में एक बार "नए अनुक्रम" का अनुभव करते हैं। एक एकल अनुक्रम आमतौर पर विभिन्न बंदरगाहों में लगभग 100 प्रयासों का बैच होता है। सिर्फ एक दिन के लिए मैं अपने फ़ायरवॉल के बाहर एक unpatched सर्वर चालू कर दिया; पीडब्ल्यूएन प्राप्त करने के लिए इसे संचालित होने के 10 मिनट से भी कम समय लगता है। प्वाइंट इंटरनेट वास्तव में एक जंगल है; खाने के लिए प्रयास न करें। - NotMe
मैं देख सकता हूं कि मैंने गलत प्रश्न पर अपना प्रश्न पोस्ट किया है: superuser.com/questions/200896/... - Justin C
जबकि मैं दूसरों से सहमत हूं कि सामान्य बंदरगाहों पर यह सामान्य है (80, 443) मैंने व्यावहारिक रूप से 22 से डिफ़ॉल्ट पोर्ट को बदलकर अपने एसएसएच पोर्ट के खिलाफ इन प्रयासों को समाप्त कर दिया है, उदाहरण के लिए 6022 की तरह अस्पष्ट। बस ऐसा करने के लिए, अकेले, लगभग 99% उस प्रकार के हमले को समाप्त कर दिया। - Kilo
यदि आप अपना एसएसएच पोर्ट बदलना चाहते हैं, तो पोर्ट 1024 के नीचे रखने के लिए सुरक्षा कारण हैं (केवल रूट बंदरगाहों को खोल सकता है <1024, इसलिए यह आपको एसएसएच को अपहरण करने वाले अन्य उपयोगकर्ताओं से बचाता है)। - Brendan Long


जवाब:


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

हमले के लक्ष्य Google या DNS प्रविष्टियों के माध्यम से नहीं मिलते हैं, लेकिन हमलावर बस एक निश्चित सबनेट (जैसे ज्ञात रूट-सर्वर होस्टिंग कंपनियों के) में प्रत्येक आईपी पते का प्रयास करते हैं। तो इससे कोई फर्क नहीं पड़ता कि आपका यूआरएल (इसलिए DNS एंट्री) बल्कि अस्पष्ट है।

यही कारण है कि यह इतना महत्वपूर्ण है:

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

इसके अतिरिक्त, आप स्थापित कर सकते हैं fail2ban जो ऑथलॉग को स्कैन करेगा और यदि उसे किसी आईपी से असफल लॉगिन प्रयासों की एक निश्चित राशि मिलती है, तो वह उस आईपी को जोड़ देगा /etc/hosts.deny या कुछ मिनटों के लिए हमलावर को लॉक करने के लिए iptables / netfilter।

एसएसएच हमलों के अलावा, कमजोर वेब-एप्लिकेशन (कुछ ब्लॉगिंग ऐप्स, सीएमएस, phpmyadmin, आदि) के लिए अपने वेबसर्वर को स्कैन करना भी आम हो रहा है। तो सुनिश्चित करें कि उन अद्यतित और सुरक्षित रूप से कॉन्फ़िगर भी रखें!


207
2018-03-08 11:35



Fail2ban जैसे अनुप्रयोग सुबह में मूर्खतापूर्ण समय पर आपके सर्वर को मारने से उन अस्थायी रूप से 'अस्थायी रूप से' रोकने में मदद कर सकते हैं :-) मैंने 24hours के लिए 3 गलत प्रयासों को प्रतिबंधित करने के लिए अपना सेट अप किया है। - emtunc
और एसएसएच पोर्ट को 22 से 222 तक ले जाएं। यह काफी अच्छा काम करता है। - Tom O'Connor
+1, केवल सार्वजनिक कुंजी प्रमाणीकरण :) - 0xC0000022L
@STATUS_ACCESS_DENIED: कार्रवाइयां विफल 2ban ले जाने के लिए खोल कमांड की सूचियां हैं। तो यह वास्तव में किसी भी कस्टम कॉन्फ़िगरेशन के साथ काम करने के लिए वास्तव में लचीला और आसान है। सबसे अच्छा संदर्भ इसे डाउनलोड करना और देखना है action.d/iptables.conf। - mattdm
इस तरह हमलावरों को अवरुद्ध करना समय की बर्बादी है। यदि आप रूट लॉगिन अक्षम करते हैं, तो एक अच्छा मौका है कि कोई भी आपके सही लॉगिन नाम का अनुमान लगाएगा, अकेले पासवर्ड दें। एसएसएच स्वयं ही पासवर्ड अनुरोधों को सीमित करने की दर से पहले ही है, भले ही वे आपके उपयोगकर्ता नाम (यादृच्छिक बॉट नहीं) जानते हों, भले ही आपके पास एक सभ्य पासवर्ड है, तो वे इसे कभी अनुमान नहीं लगाएंगे। - Brendan Long


कुछ 100 ठीक है ... पिछले महीने मैंने पाया कि मेरे सर्वरों में से एक को 40k विफल प्रयास हुए थे। मैं उन्हें साजिश करने में परेशानी हुई: नक्शा

एक बार जब मैंने एसएसएच पोर्ट बदल दिया और पोर्ट नॉकिंग लागू किया, तो संख्या 0 :-) तक गिर गई


58
2018-03-08 11:36



अच्छा नक्शा मुझे यह जानना अच्छा लगेगा कि यह कैसे करें! - jftuga
@jftuga मुझे पहले लॉग से सभी आईपी मिल गया। grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq(यदि आप डुप्लिकेट की अनुमति देना चाहते हैं तो अंत में uniq को हटाएं)। फिर आप उन्हें एक CSV में डाल सकते हैं और इसे zeemaps.com पर अपलोड कर सकते हैं। मैंने अपने नक्शे को बेहतर नक्शा देखा है, जहां वे मानचित्र को रंग देने के लिए गिनती का उपयोग करेंगे (काउंटी प्रति प्रयासों की संख्या के लिए लाल से हरा) लेकिन मुझे जेट नहीं लगा है कि एक बाहर - Bart De Vos
'लागू पोर्ट नॉकिंग' से आपका क्या मतलब है? क्या ऐसा कोई ऐप है जिसे मैं एपीटी के माध्यम से इंस्टॉल कर सकता हूं? 0 पर जाने वाली संख्या अच्छी लगती है
अस्पष्टता के माध्यम से सुरक्षा एक खराब लपेट जाती है। यह पूरी तरह से ठीक है जब तक यह है अंश पूरी रणनीति के बजाय समग्र रणनीति का। आखिरकार, एक अस्पष्ट स्ट्रिंग के अलावा पासवर्ड क्या है? - Joel Coel
@ जोएल कोयल, यह एक है गुप्त स्ट्रिंग, अस्पष्टता के मुद्दों के माध्यम से अधिकांश सुरक्षा के विपरीत - एक अस्पष्ट, लेकिन जरूरी नहीं कि गुप्त प्रक्रिया। - tobyodavies


मैं केवल सार्वजनिक कुंजी प्रमाणीकरण और रूट लॉग इन को अस्वीकार करने के अलावा एक "tarpit" का उपयोग करता हूं।

में netfilter वहां एक है recent मॉड्यूल, जिसका आप उपयोग कर सकते हैं (INPUT जंजीर):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

ऐसा क्या होता है, कि पोर्ट 22 से कनेक्ट करने का हर प्रयास सूचीबद्ध है recent "tarpit" नाम के तहत आईपी और कुछ अन्य सामान के साथ मॉड्यूल (यदि आप उत्सुक हैं, तो देखो /proc/net/xt_recent/tarpit)। जाहिर है आप अन्य नामों का उपयोग कर सकते हैं।

आईपी ​​का उपयोग या सूची देने के लिए:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

यह 300 सेकंड में 5 के प्रयासों को सीमित करता है। कृपया ध्यान दें कि मौजूदा कनेक्शन वाले उपयोगकर्ता उस सीमा से परेशान नहीं हैं, क्योंकि उनके पास पहले से ही एक स्थापित कनेक्शन है और उन्हें और अधिक (दर सीमा से ऊपर) बनाने की अनुमति है।

नियमों को अपनी पसंद के अनुसार समायोजित करें लेकिन सुनिश्चित करें कि उन्हें उस क्रम में जोड़ा जायेगा (यानी जब जोड़ते हैं तो उन्हें क्रम में क्रम में डालने पर, इस क्रम में उनका उपयोग करें)।

यह शोर को बहुत कम कर देता है। यह बंदरगाह को बदलने की अनुमानित सुरक्षा के विपरीत वास्तविक सुरक्षा (ब्रूट-फोर्सिंग के खिलाफ) भी प्रदान करता है। हालांकि, अगर आप अपने पर्यावरण में व्यवहार्य हैं तो भी मैं बंदरगाह को बदलने की सिफारिश करता हूं। यह शोर स्तर को भी बहुत कम कर देगा ...

आप अभी भी fail2ban के साथ इसे गठबंधन कर सकते हैं, हालांकि मैं इसके बिना ठीक और केवल उपर्युक्त नियम चला रहा हूं।

संपादित करें:

ऐसा करने से स्वयं को लॉक करना संभव है, इसलिए आप निम्न की तरह कुछ जोड़ सकते हैं जो आपको किसी विशेष पोर्ट पर दस्तक देकर प्रतिबंध लगाने देता है:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

29
2018-03-08 14:24



मैं इसका उपयोग करता हूं और कभी-कभी खुद को अवरुद्ध करने का प्रबंधन करता हूं, इसलिए एक और बंदरगाह सेट करना चाहते हैं कि आप अपने प्रतिबंध को साफ़ करने के लिए "दस्तक" दे सकें। - benlumley
@ बेंलमले: अच्छा बिंदु। पोर्ट नॉकिंग डिफ़ॉल्ट बंदरगाह को बदलने के लिए समान रूप से उपयोगी हो सकता है - या यहां तक ​​कि दोनों संयोजन में ... - 0xC0000022L
@ बेंलमले: आपकी टिप्पणी देखी (अब सैम द्वारा हटा दी गई)। अगर जवाब संपादित / सुधार हो जाता है तो मुझे बिल्कुल कोई फर्क नहीं पड़ता;) - 0xC0000022L


आप कार्यान्वित कर सकते हैं fail2ban, या इसी तरह के तरीकों जैसे एसएसएच को आपके आईपी में लॉक करना। अफसोस की बात है कि हर समय ब्रूटफोर्स पहुंच का प्रयास करते हैं, इसलिए यह काफी सामान्य है, आपको यह सुनिश्चित करना होगा कि आपके पास एक अच्छा पासवर्ड है।


15
2018-03-08 11:32



यदि आप एसएसएच का उपयोग कर रहे हैं, तो सार्वजनिक कुंजी प्रमाणीकरण पर विचार करें। यह पासवर्ड प्रमाणीकरण से थोड़ा अधिक सुरक्षित है। - Piskvor


हाँ। आजकल यह काफी सामान्य है।

यदि संभव हो तो प्रशासनिक उद्देश्यों के लिए केवल सार्वजनिक कुंजी प्रमाणीकरण का उपयोग करें। वर्कस्टेशन पर एक निजी कुंजी जेनरेट करें:

$ ssh-keygen -t dsa

की सामग्री को कॉपी करें ~ / .Ssh / id_dsa.pub आप सर्वर के लिए ~ / .Ssh / authorized_keys (और /root/.ssh/authorized_keys, क्या आपको प्रत्यक्ष रूट लॉगिन की आवश्यकता होनी चाहिए)।

अपने सर्वर को कॉन्फ़िगर करें / Etc / ssh / sshd_config केवल सार्वजनिक कुंजी प्रमाणीकरण स्वीकार करने के लिए:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

यदि आपके पास बहुत सारे सर्वर हैं, तो आप इसका उपयोग कर सकते हैं कठपुतली उन्हें सार्वजनिक कुंजी और विन्यास चलाने के लिए।

इस पर गौर करें denyhosts तथा fail2ban बार-बार एसएसएच लॉगिन प्रयासों को अवरुद्ध करने और देखने के लिए फक - फक करना अगर आपको पूर्ण आईडीएस / आईपीएस की आवश्यकता है।


12
2018-03-09 23:32



मैं आपके सर्वर पर खोल पहुंच के लिए एसएसएच में सार्वजनिक कुंजी प्रमाणीकरण का उपयोग करने की अनुशंसा नहीं करता। यदि आपके वर्कस्टेशन से समझौता किया गया है या इससे भी बदतर चोरी हो गई है, तो किसी के पास अब पासवर्ड की आवश्यकता के बिना आपके सर्वर पर खुली पहुंच है। सार्वजनिक कुंजी प्रमाणीकरण उन परिस्थितियों के लिए अधिक है जहां आपको किसी स्क्रिप्ट या प्रोग्राम की तरह कुछ चाहिए, ताकि पासवर्ड की आवश्यकता के बिना किसी अन्य सिस्टम में एसएसएच पहुंच प्राप्त हो सके ताकि आपको अपनी स्क्रिप्ट / प्रोग्राम में सादा-पाठ पासवर्ड एम्बेड न करना पड़े। - Registered User
@ हटाया गया खाता: आप एसएसएच निजी कुंजी के लिए पासफ्रेज सेट कर सकते हैं। - Phil Cohen
"पंजीकृत उपयोगकर्ता की" टिप्पणी गुमराह है। बस स्पष्ट करने के लिए: हमेशा अपनी निजी कुंजी पर एक अच्छा पासवर्ड सेट करें, और किसी भी सर्वर पर निजी कुंजी को स्टोर न करें। निजी कुंजी को अपने वर्कस्टेशन पर रखें। एक बार जब आप एक एसएसएच-एजेंट प्रोग्राम में कुंजी जोड़ते हैं, और अपना पासवर्ड दर्ज कर लेते हैं, तो आप अपने सिस्टम को दोबारा दर्ज करने के बिना, प्रत्येक कुंजी में लॉग इन कर सकते हैं जिसमें सार्वजनिक कुंजी स्थापित है। अपने एसएसएच क्लाइंट में एजेंट-अग्रेषण सक्षम करें ताकि आप सर्वर से सर्वर में लॉग इन कर सकें। अपनी निजी कुंजी चोरी करना खराब है, लेकिन उस पर एक सभ्य पासवर्ड के साथ यह चोरी पासवर्ड के रूप में बुरा नहीं है। - Martijn Heemels
ठीक है, व्यवस्थापक की निजी कुंजी को अनएन्क्रिप्टेड स्टोर करने के बारे में भी सोचें। - yarek


उपयोग http://denyhosts.sourceforge.net/

और हां, आपको सार्वजनिक कुंजी प्रमाणीकरण का उपयोग करना चाहिए और पासवर्ड ऑथ अक्षम करना चाहिए।


8
2018-03-09 09:37



पासवर्ड ऑथ अक्षम करना हमेशा एक व्यवहार्य समाधान नहीं होता है। - Publiccert


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


6
2018-03-08 11:33





मैं कहूंगा कि केवल 500 ही कम हो रहा है।

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


6
2018-03-08 17:06





हाँ,

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

DNS संबंधित आईपी पते से बचें

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

सभी एसएसएच एक्सेस के लिए एक वीपीएन का प्रयोग करें

यदि आप ऐसे माहौल में हैं जहां आप कार्यान्वित कर सकते हैं IPsec/ वीपीएन आपके सर्वर पर्यावरण के भीतर एक निजी नेटवर्क के लिए, यह आदर्श है। सभी एसएसएच इंटरनेट एक्सेस को अक्षम करें, सुनिश्चित करें कि आपके पास एक एकीकृत रोशनी समाधान है। अपना वीपीएन सेटअप करें, और केवल अपने वीपीएन से एसएसएच एक्सेस की अनुमति दें।

एसएसएच एक्सेस के लिए आईपी एड्रेस नियम लागू करें

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

यदि आप इन चरणों का पालन करते हैं तो आप रात में सोते रहेंगे कि किसी को एसएसएच के माध्यम से सर्वर तक पहुंच प्राप्त करने के लिए अपने होस्टिंग कंपनियों नेटवर्क से समझौता करना होगा।


6
2018-03-08 21:56





सैकड़ों असफल एसएसएच कनेक्शन देखने के लिए बहुत सामान्य है।

यदि आपके पास विकल्प है, तो मैं बस अपने एसएसएच पोर्ट को गैर-मानक में बदल देता हूं। यह आपके सर्वर को और अधिक सुरक्षित नहीं बनाता है, लेकिन यह निश्चित रूप से लॉग साफ़ करता है (और आपको किसी को जानबूझकर तोड़ने की कोशिश करने देता है!)


5
2018-03-08 11:43