腾讯云服务器被黑了，想知道怎么做到的，谁能提供排查思路？不能浪费这次机会感觉

[kirito41dd]

我已经强密码了，除了 root 谁都不能登录，今天/var/www/httpd 还是出现了陌生文件

服务器有以下服务： frp nginx

有没有大手子能告诉我怎么找原因

[JefferyWang]

也可能是 PHP 程序有漏洞

[LeeReamond]

1. 密码登录和 root 登录不是好习惯
2. 虽然但是，root 强密码几乎不认为有安全问题，前提是你确定你的密码足够强，局域网的暴力破解速度也不慢。
3. 如果遇到 sshd 的暴力破解 varlog 和 history 里应该会有明显特征，大概
4. frp 业务比较单纯，另外最近似乎没听说有什么漏洞爆出。
5. 所以照楼主描述反正我是感觉基本上是 web 业务的问题，可能也用了数据库的权限。

[littlefishcc]

如果不是 root 弱密码就是 web 漏洞，查看自己网站日志，看哪些执行 shell （奇怪请求路径），找一些关键词就能找到对应漏洞了然后进行分析验证。
同时你可以用云服务商安全中心查看自己服务器有哪些漏洞，查看这些漏洞攻击方法，进行验证即可，可以用 Histroy 看自己执行命令（如果记录没有被清除的话）。

[asdfg17718]

是不是没关 22 端口，目前挺多做漏扫的，大批量扫服务器，没关的话可以试试。smb 破解攻击也有可能，但这个是针对性的，这种情况比较少见，而且你设置了强密码其实没这么容易的。

[asdfg17718]

或者你搭建的项目是不是买的源码二开的，目前挺多源码都有漏洞，这种的话你在服务器上做策略就没用了，只有一种办法就是后台 0 信任。

[testonly]

WEB 漏洞？
给这些没用，你要详细说清楚，自安装系统后，你具体安装过什么程序，你的 WEB 又具体安装什么系统和插件。

[lbp0200]

root:123456
这是啥？ MySQL ？ MySQL 端口对外没？

[kirito41dd]

@JefferyWang 图里的 php 是黑客起的端口扫描程序。 我 nginx 里就一个 tiddly wiki ，里面倒是有 php

[kirito41dd]

@lbp0200 黑客的端口扫描，用密码本在试别的 ssh

[cxh116]

php 也是 root 用户运行的？ 那别人拿到 Web Shell 就拿到 root 权限。

一般服务都是非特权用户启动，防止有漏洞的时候，拿到的也是一个低权限用户，做不了什么事。

[kirito41dd]

@testonly 服务上有个 frp 给我内网机器用，nginx 里有个 tiddly wiki
之前有个 sudo 权限的用户，密码不是很强，我的常用密码
知道被黑后我改了 root 密码，sudo 用户也禁止登陆了
昨天腾讯云报警，我上去把可疑程序，httpd 文件夹删了
今天又出现了新的

[lstz]

除了楼上几位说的，还有一点就是要确保你的私钥和密码不存储在任何一台联网的机器，特别是你本地 Windows

如果你本地装了很多破解软件，或者来路不明的软件，你本机很有可能作为跳板，被搜集.ssh 下的所有密钥，直接爆破 over

我这里推荐用开源软件 tabby ，它可以让你用一个主密码加密存储所有密钥信息，非常好用

[testonly]

@kirito41dd 问题是你被黑后有没有重做系统？没有的话人家已经做好后门了吧？
至于第一次被黑，要么被爆要么漏洞，如果你重做系统后，安装回一样东西，密码改强的，还能再黑的话就是你安装的某样东西有漏洞再排查了。

[lstz]

还有，能上 docker 就上 docker

如果我要维护一个老旧的程序，我没详细读过它的源码，那我会用 docker 给它包一层，并且数据库用户也按照最小权限配置

[zeusho871]

redis ？

[kirito41dd]

root@PlayHome:/var/log# netstat -nplt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1/init
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1706020/nginx: mast
tcp 0 0 0.0.0.0:30033 0.0.0.0:* LISTEN 2173629/docker-prox
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 737/sshd: /usr/sbin
tcp 0 0 0.0.0.0:41144 0.0.0.0:* LISTEN 2173609/docker-prox
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1200/exim4
tcp 0 0 0.0.0.0:10011 0.0.0.0:* LISTEN 2173651/docker-prox
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 1706020/nginx: mast
tcp 0 0 0.0.0.0:444 0.0.0.0:* LISTEN 1706020/nginx: mast
tcp6 0 0 :::10443 :::* LISTEN 2651693/./frps
tcp6 0 0 :::7500 :::* LISTEN 2651693/./frps
tcp6 0 0 :::111 :::* LISTEN 1/init
tcp6 0 0 :::80 :::* LISTEN 1706020/nginx: mast
tcp6 0 0 :::30033 :::* LISTEN 2173634/docker-prox
tcp6 0 0 :::22 :::* LISTEN 737/sshd: /usr/sbin
tcp6 0 0 :::7000 :::* LISTEN 2651693/./frps
tcp6 0 0 :::41144 :::* LISTEN 2173617/docker-prox
tcp6 0 0 ::1:25 :::* LISTEN 1200/exim4
tcp6 0 0 :::10011 :::* LISTEN 2173657/docker-prox
tcp6 0 0 :::443 :::* LISTEN 1706020/nginx: mast
tcp6 0 0 :::10080 :::* LISTEN 2651693/./frps
tcp6 0 0 :::2017 :::* LISTEN 1562/v2raya

[kirito41dd]

找不到线索了，我觉得唯一可能是我之前留了一个 sudo 用户，密码强度一般，可能它被爆破了，11 位纯英文，可能泄露过在密码本有

[hefish]

你这怎么找线索啊，跑了啥都不说清楚，估计 op 是认定是从 ssh 里进来的了。 实际进来的方式多得是。

[JKOR]

禁止密码登陆，改为秘钥验证；查看 nginx 日志；用 fail2ban 限制 ip