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

Question

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

Comments

जब तक हमने सभी अनावश्यक बाहरी बंदरगाहों को बंद नहीं किया, मुझे याद है कि न केवल हमें बहुत सारे हैक प्रयास मिले थे, लेकिन एक दिन यह इतना बुरा था कि हमें दो अलग-अलग देशों से हैक किया जा रहा था - एक ही समय में! तो हाँ, ब्रेक-इन के 100 प्रयास पूरी तरह से सामान्य हैं।

— Django रेनहार्ड्ट

हमारे पास ऐसे सर्वर हैं जो हर 16 सेकंड में एक बार एक नए हमले "अनुक्रम" का अनुभव करते हैं। एक एकल अनुक्रम आमतौर पर विभिन्न बंदरगाहों में लगभग 100 प्रयासों का एक बैच है। बस एक दिन किक के लिए मैं अपने फ़ायरवॉल के बाहर एक अप्रकाशित सर्वर को चालू करता हूं; इसे उस समय से 10 मिनट से भी कम समय लगा जब इसे पावंड करने के लिए संचालित किया गया था। बिंदु इंटरनेट वास्तव में एक जंगल है; खाने के लिए नहीं की कोशिश करो।

— NotMe

मैं देख सकता हूं कि मैंने अपना प्रश्न गलत साइट पर पोस्ट कर दिया है: superuser.com/questions/200896/…

— जस्टिन सी

जबकि मैं दूसरों के साथ सहमत हूँ यह सामान्य बंदरगाहों पर आवश्यक है (80, 443) मैंने व्यावहारिक रूप से उदाहरण के लिए 6022 जैसे कुछ अस्पष्ट से डिफ़ॉल्ट पोर्ट को बदलकर अपने एसएसएच पोर्ट के खिलाफ इन प्रयासों को समाप्त कर दिया। बस ऐसा करते हुए, अकेले, लगभग 99% उस प्रकार के हमले को समाप्त कर दिया।

— किलो

यदि आप अपने SSH पोर्ट को बदलने जा रहे हैं, तो इसे 1024 के नीचे रखने के लिए सुरक्षा कारण हैं (केवल रूट ही पोर्ट <1024 को खोल सकता है, इसलिए यह आपको SSH अपहरण करने वाले अन्य उपयोगकर्ताओं से बचाता है)।

— ब्रेंडन लॉन्ग

Answer 1

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

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

इसलिए यह इतना महत्वपूर्ण है:

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

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

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

Comments

असफल 2 ऑबन जैसे एप्लिकेशन उन बॉट्स को सुबह में मूर्खतापूर्ण समय पर अपने सर्वर से टकराने से रोकने में बहुत मदद कर सकते हैं :-) मेरे पास 24 घंटे के लिए 3 गलत प्रयासों पर प्रतिबंध लगाने के लिए मेरा सेट है।

— 13 अक्टूबर को रात 8'11

और ssh के पोर्ट को 22 से 222 पर ले जाएं। यह काफी अच्छा काम करता है।

— टॉम ओ'कॉनर

+1, सार्वजनिक-कुंजी प्रमाणीकरण केवल :)

— 0xC0000022L

@STATUS_ACCESS_DENIED: विफल होने वाली कार्रवाइयां केवल चलाने के लिए शेल कमांड की सूची हैं। तो यह वास्तव में लचीला है और किसी भी कस्टम कॉन्फ़िगरेशन के साथ ठीक से काम करना आसान है। सबसे अच्छा संदर्भ इसे डाउनलोड करने और देखने के लिए है action.d/iptables.conf।

— मटमैट

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

— ब्रेंडन लॉन्ग

Answer 2

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

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

Comments

अच्छा नक्शा। मुझे यह जानकर अच्छा लगेगा कि यह कैसे करना है!

— 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(यदि आप डुप्लिकेट की अनुमति देना चाहते हैं तो अंत में यूनीक को हटा दें)। फिर आप उन्हें एक CSV में रख सकते हैं और इसे zeemaps.com पर अपलोड कर सकते हैं। मैंने तब बेहतर नक्शे देखे हैं, मेरा, जहाँ वे गिनती को मैप को रंगने के लिए इस्तेमाल करेंगे (हरेक काउंटी के लिए हरे रंग में लाल) लेकिन मैंने जेट नहीं लगाया है कि एक

— बार्ट दे वोस

'लागू पोर्ट नॉकिंग' से आपका क्या अभिप्राय है? क्या ऐसा कोई ऐप है जिसे मैं एप-गेट के माध्यम से स्थापित कर सकता हूं? 0 पर आने वाली संख्या अच्छी लगती है

अस्पष्टता के माध्यम से सुरक्षा एक खराब लपेट हो जाती है। यह पूरी तरह से ठीक है क्योंकि यह पूरी रणनीति के बजाय समग्र रणनीति का हिस्सा है। आखिर एक अस्पष्ट स्ट्रिंग के अलावा और क्या पासवर्ड है?

— जोएल कोएल

@ जोएल कोएल, यह एक गुप्त स्ट्रिंग है, जो अस्पष्टता के मुद्दों के माध्यम से सबसे अधिक सुरक्षा के विपरीत है - एक अस्पष्ट, लेकिन जरूरी नहीं कि आवश्यक प्रक्रिया हो।

— टोबैडोविज़

Answer 3

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

में 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आईपी द्वारा मॉड्यूल के साथ सूचीबद्ध किया गया है और "टारपीट" नाम के तहत कुछ अन्य सामान (यदि आप उत्सुक हैं, तो देखें /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 तक सीमित करता है। कृपया ध्यान दें कि मौजूदा कनेक्शन वाले उपयोगकर्ता उस सीमा से परेशान नहीं हैं, क्योंकि उनके पास पहले से ही एक स्थापित कनेक्शन है और उन्हें अधिक (यहां तक ​​कि दर सीमा से ऊपर) बनाने की अनुमति है।

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

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

आप अभी भी इसे फेल 2 एबन के साथ जोड़ सकते हैं, हालांकि मैं इसके बिना सिर्फ ठीक चल रहा हूं और केवल उपरोक्त नियम।

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

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

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

Comments

मैं इसका उपयोग करता हूं और कभी-कभी खुद को ब्लॉक करने का प्रबंधन करता हूं, इसलिए एक और पोर्ट सेट करना पसंद करता हूं ताकि आप अपना प्रतिबंध हटाने के लिए "दस्तक" कर सकें।

— बेन्मुले

@benlumley: अच्छी बात है। पोर्ट नॉकिंग डिफ़ॉल्ट पोर्ट को बदलने के लिए समान रूप से उपयोगी हो सकती है - या यहां तक ​​कि उन दोनों के संयोजन में ...

— 0xC0000022L

@benlumley: आपकी टिप्पणी देखी (अब सैम द्वारा हटा दी गई)। अगर जवाब संपादित / बेहतर हो जाता है तो मैं बिल्कुल बुरा नहीं

— मानता

Answer 4

आप असफल IP2 या SSH को अपने IP पर लॉक करने जैसी विधियों को लागू कर सकते हैं । अफसोस की बात है कि हर समय पहुँच को भंग करने का प्रयास किया जाता है इसलिए यह काफी सामान्य है, आपको यह सुनिश्चित करने की ज़रूरत है कि आपके पास एक अच्छा पासवर्ड हो।

Comments

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

— पिस्कोर

Answer 5

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

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

$ ssh-keygen -t dsa

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

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

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

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

में देखो denyhosts और fail2ban दोहराया SSH लॉगिन प्रयास ब्लॉक और देखने के लिए थिरकने यदि आप पूर्ण आईडीएस आईपीएस की आवश्यकता होती है /।

Comments

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

— पंजीकृत उपयोगकर्ता

@ हटाए गए खाते: आप SSH निजी कुंजी के लिए पासफ़्रेज़ सेट कर सकते हैं।

— फिल कोहेन

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

— मार्टिज़न हेमेल्स

ठीक है, व्यवस्थापक की निजी कुंजी को अनएन्क्रिप्टेड स्टोर करने के बारे में भी न सोचें।

— yrk

Answer 6

http://denyhosts.sourceforge.net/ का उपयोग करें

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

Comments

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

— Publiccert

Answer 7

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

Answer 8

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

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

Answer 9

हाँ,

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

डीएनएस से जुड़े आईपी एड्रेस से बचें

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

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

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

SSH पहुँच के लिए IP पता नियम लागू करें

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

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

Answer 10

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

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

Answer 11

इसके अलावा एक स्वचालित लॉकआउट तंत्र का उपयोग करने में विफल 2ban की तरह आपके पास एक और विकल्प है: वास्तव में हमलावर के दुरुपयोग पते आईएसपी से संपर्क करें। यह पूरी तरह से निरर्थक लग सकता है लेकिन स्क्रिप्ट-किडी के मामले में उनकी आईएसपी उन पर कार्रवाई करने के लिए तैयार है।

दुरुपयोग पते को खोजने के लिए, arin.net से शुरू करें और whois का उपयोग करके आईपी पते को देखें। आप किसी अन्य क्षेत्रीय रजिस्ट्री पर पुनर्निर्देशित हो सकते हैं, लेकिन अंततः आप आईपी ब्लॉक के लिए जिम्मेदार आईएसपी पा सकते हैं जिसमें पता शामिल है। दुरुपयोग @ पते के लिए देखें या बस तकनीकी संपर्क मेल करें।

उन्हें संबंधित लॉग फ़ाइल प्रविष्टियों के साथ एक विनम्र संदेश भेजें (किसी भी निजी जानकारी को निकालना सुनिश्चित करें) और उन्हें आक्रामक मेजबान के खिलाफ कार्रवाई करने के लिए कहें।

Comments

हम ऐसा करते थे। हालांकि, प्राप्त लाभ के मुकाबले समय की मात्रा इतनी कम थी कि इससे कोई फर्क नहीं पड़ता।

— NotMe

इस रणनीति का एक प्रकार जो अधिक प्रभावी है, लेकिन बहुत जोखिम भरा है, आईएसपी को मध्यवर्ती नोड को रिपोर्ट करना है। लेकिन आपके पास अपनी रिपोर्ट के सबूत ठोस होने चाहिए । मुझे ऐसा करने में एक बार पूरी ISP गंभीर मुसीबत में पड़ गई, क्योंकि वे अपनी दुर्व्यवहार की रिपोर्टों को नजरअंदाज कर रहे थे।

— स्टेटिक्सन

एक बार मैंने ऐसा किया, दुरुपयोग संदेश सर्वर के प्रभारी के बजाय हैकर तक पहुंच गया। तब से, मैं अब और परेशान नहीं करता, बस बहुत अधिक परेशानी।

— बजे

यह वास्तव में ज्यादातर मामलों में मदद करने वाला नहीं है और इसका समय लग सकता है

— रिचवेल

Answer 12

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

गैर-मानक बंदरगाहों पर विफल लॉगिन कुछ और दूर के बीच होगा और अधिक लक्षित हमलों का संकेत भी दे सकता है।

तुम भी एक कदम आगे जाने के लिए एक SSH honeypot स्थापित कर सकते हैं जैसे कि Kippo को 'bruteforcers' में जाने के लिए और देखें कि वे क्या मौका देंगे।

Comments

हाहा, किप्पो बहुत अच्छा लग रहा है। मैं इसे एक सर्वर पर स्थापित करने जा रहा हूं, यह देखने के लिए कि वे क्या करने की कोशिश कर रहे हैं।

— 15:11 बजे

Answer 13

हां, यह सामान्य है। मैं छोटी वेबसाइटों के साथ आपकी स्थिति में ग्राहकों को क्या बताता हूं।

हमेशा हैक होने के लिए तैयार रहें।

एक देव सर्वर पर अपनी वेबसाइट की एक प्रति है। यह XAMPP का उपयोग करके आपका विंडोज डेस्कटॉप हो सकता है जिसे आप मुफ्त में प्राप्त कर सकते हैं।

हमेशा अपने देव सर्वर में परिवर्तन करें और फिर उन्हें अपनी लाइव वेबसाइट पर अपलोड करें। यदि यह Wordpress की तरह एक CMS है, तो देव सर्वर पर अपनी पोस्ट करें और फिर उन्हें लाइव सर्वर में पेस्ट करें।

कभी भी अपनी लाइव वेबसाइट से अपने देव सर्वर पर कुछ भी डाउनलोड न करें।

अपने वेबपृष्ठों को उन परिवर्तनों के लिए नियमित रूप से मॉनिटर करें जो आपने नहीं किए थे। विशेष रूप से, ड्रग्स या 'एन्हांसमेंट' उत्पादों के लिए छिपे हुए लिंक। आप बहुत सारे ब्राउज़र ऐड इन्स और प्रोग्राम पा सकते हैं जो आपके लिए ऐसा करेंगे।

यदि आप समझौता कर रहे हैं। अपने होस्ट को सूचित करें, सबकुछ हटाएं, सभी पासवर्ड बदलें और अपने खाली वेब सर्वर को अब खाली वेबसर्वर पर अपलोड करें। पुनरावृत्ति को रोकने के लिए अपने होस्ट के साथ काम करें।

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

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

Comments

+1 के लिए "हमेशा हैक होने के लिए तैयार रहें।"

— user78940

Answer 14

इसे रोकने का दूसरा तरीका (जैसा कि मैं व्यक्तिगत रूप से SSH पोर्ट को स्थानांतरित करना पसंद नहीं करता हूं): यह तय करें कि क्या आप उन सभी नेटवर्क को सूचीबद्ध करने में सक्षम हैं जिनसे आप कभी भी लॉगिन करना चाहते हैं, तो केवल इनको अपने SSH पोर्ट तक पहुंचने की अनुमति दें।

स्थानीय ISPs की WHOIS प्रविष्टियों ने मुझे महीने में 1-2 लॉगिन प्रयासों के हमलों को कम करने में मदद की (पीछे तब यह लगभग 1k / दिन था)। मैंने अभी तक denyhosts का उपयोग करके उन लोगों का पता लगाया ।

Answer 15

आपके द्वारा पहले से प्राप्त किए गए अन्य उत्कृष्ट सुझावों के अलावा, मैं दिए गए सर्वर के लिए उपयुक्त होने पर AllowUsers के निर्देश का उपयोग करना भी पसंद करता हूं । यह केवल निर्दिष्ट उपयोगकर्ताओं को SSH के माध्यम से लॉगिन करने की अनुमति देता है जो असुरक्षित रूप से कॉन्फ़िगर किए गए अतिथि / सेवा / सिस्टम खाते के माध्यम से पहुंच प्राप्त करने की संभावना को बहुत कम कर देता है।

उदाहरण:

AllowUsers admin jsmith jdoe

AllowUser विकल्प निर्दिष्ट करता है और नियंत्रित करता है कि कौन से उपयोगकर्ता ssh सेवाओं तक पहुँच सकते हैं। एकाधिक उपयोगकर्ताओं को निर्दिष्ट किया जा सकता है, रिक्त स्थान द्वारा अलग किया जा सकता है।

Answer 16

हां, यह सामान्य है। आप ऐसा कर सकते हैं :

• Fwknop का उपयोग करके हमले के अवसर को कम करें

Fwknop बेहतर बंदरगाह दस्तक कार्यान्वयन में से एक है क्योंकि यह खराब नहीं है और वास्तव में एक कनेक्शन को अधिकृत करने के विपरीत प्रमाणित करता है।

• आप उस पोर्ट को बदल सकते हैं जो Openssh उपयोग करता है लेकिन आप वास्तव में सुरक्षा में सुधार नहीं कर रहे हैं।

• Google-प्रमाणक या विकिड का उपयोग करके ssh प्रमाणीकरण को दृढ़ करें

यह पासवर्ड आधारित हमलों और एक निर्धारित हमलावर / लक्षित हमले की संभावना को नियंत्रित करेगा जो आपके व्यवस्थापक मशीन से समझौता करेगा और आपकी ssh-key और पासवर्ड कॉम्बो को चुराएगा।

बस नवीनतम pwn2own COMP को देखें कि एक कुशल हमलावर के लिए अपने पूर्ण रूप से पैच किए गए व्यवस्थापक बॉक्स से समझौता करना कितना आसान है।

Answer 17

अफसोस की बात है कि यह काफी सामान्य है। आपको स्वचालित रूप से हमलावरों का पता लगाने और उन पर प्रतिबंध लगाने के लिए अपने सिस्टम में कुछ विफलता -2 जैसे जोड़ने पर विचार करना चाहिए । यदि आप पहले से ही ऐसा नहीं करते हैं, तो आपको सार्वजनिक कुंजी के साथ केवल ssh का उपयोग करने पर भी विचार करना चाहिए और ssh पर रूट लॉगिन की अनुमति नहीं देना चाहिए। यदि सिस्टम में फ़ाइलों को स्थानांतरित करने के लिए ftp का उपयोग करते हैं, तो इसके बजाय scp / sftp का उपयोग करने पर विचार करें।

Answer 18

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

अस्थायी रूप से लगातार हमलावरों को ब्लैकलिस्ट करने के लिए मैंने फ़ायरवॉल के रूप में Shorewall के साथ fail2ban भी चलाया है।

यदि आपको SSH को इंटरनेट एक्सेस की आवश्यकता नहीं है, तो उसे अक्षम करें। यदि आपके पास कुछ ज्ञात पते हैं जिन्हें दूरस्थ पहुँच की आवश्यकता है, तो उन पते तक पहुँच सीमित करें।

अधिकृत-कुंजी तक पहुंच सीमित करना भी सहायक हो सकता है।

Answer 19

मैं pam_ablअस्थायी रूप से ब्रूट कैंसर के लिए ब्लैकलिस्ट करता हूं, और यह बहुत अच्छा काम करता है। मुझे लगता है कि PAM पर निर्भर रहने के बजाय hosts.denyया अपने डेटाबेस का उपयोग करने में प्राधिकरण होना बेहतर लगता है iptables।

एक और प्लस यह है कि pam_ablलॉग फ़ाइलों को स्कैन करने पर निर्भर नहीं करता है।

Answer 20

यह इन दिनों पूरी तरह से सामान्य है।
आप SSH पोर्ट पर आने वाले नए कनेक्शनों के लिए फ़ायरवॉल पर "बर्स्ट" सीमा सेट कर सकते हैं,
या कई लॉग पार्स a'la fail2ban को स्थापित कर सकते हैं या SSH पोर्ट बदल सकते हैं;)।

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

-
सादर,
रॉबर्ट

Answer 21

हां यह सामान्य है।

मैंने अभी ssh पोर्ट को मानक 22 से बदल दिया है। मेरा सर्वर, मेरे नियम :) बस संपादित करें / etc / ssh / sshd_config, पोर्ट बदलें और सेवा को पुनरारंभ करें। केवल नीचे की ओर यह है कि आपको अपने उपयोग किए गए प्रत्येक ssh क्लाइंट के लिए उस पोर्ट को जोड़ने के लिए याद रखना चाहिए।

Answer 22

• रूट लॉगिन को अक्षम करें (प्रत्येक लिनक्स सिस्टम रूट उपयोगकर्ता में मौजूद है ताकि बॉट आसानी से उपयोगकर्ता के नाम का अनुमान लगा सकें)। सामान्य उपयोगकर्ता के रूप में लॉग इन करने के बाद आप रूट को su या sudo द्वारा बदल सकते हैं।

• 22 से डिफ़ॉल्ट पोर्ट बदलें

• केवल ज्ञात IP से ssh एक्सेस की अनुमति दें

• उपयोगकर्ता के लिए ssh एक्सेस के साथ एक मजबूत अल्फा-न्यूमेरिक-पासवर्ड का उपयोग करें