记一次Redis被入侵（被黑）处理过程

通常作为一名后端程序员，并没有系统的学习过关于服务器安防相关的知识，遇到服务器被黑的情况往往比较迷茫，不知道从何下手。服务器可能遭受的攻击多种多样，以下主要讲述的是我本次遇到的一次服务器被黑客拿来当矿机的处理过程。

攻击的发现

之所以发现服务器被攻击了是因为有用户反馈系统卡顿非常严重，我知道一般用户反馈描述的那个时间点不应该会有这么高的延迟的，所以就登录服务器查看以下CPU等资源的消耗情况。（挖矿非常消耗CPU性能）

处理步骤

首先登录服务器，使用‘top’命令查看以下资源的消耗情况（不知道每一列的含义百度一下就好了），看到有一个进程id为15437的进程它消耗了200%的cpu，而且这个进程很陌生，所以非常可疑。
由于确定这个进程不是我系统服务所需的进程，所以可以使用‘kill -9’命令把它杀掉（例如上一步已知进程id为15437，所以kill -9 15437），杀掉之后我以为大患已除，但没过多久（还不到一分钟）我再次使用top命令查看，发现这个进程又重新起来了（新起了一个进程，进程id变了，但还是那个叫kdevtmpfsi的程序）。照这样看来被我杀死的那个进程应该是有一个父进程的，这个父进程在我杀死这个子进程后又重新把这个子进程拉起。
使用以下命令可以查看它的父进程id，第三列就是。

ps -ef | grep 'kdevtmpfsi'

4. 知道了父进程的进程id，可以通过以下命令查看这个父进程id对应的程序时哪个，这里我们可以发现，原来时redis服务拉起了这个可疑进程。

cd /proc/进程id
ll

5. 于是我把redis服务停止掉，再次杀掉那个可疑进程，这个可疑进程就不能再起来了。

但是我不能永远把redis服务停掉啊，我的应用需要redis服务。既然知道是redis被入侵了，那么我的想法就是加固redis，加固reids主要从以下两个方面入手：
a. 设置reids只运行本地访问
b. 为redis添加访问密码

redis的配置文件如下。

神奇的是，我的redis配置是需要密码登录，并且只能在宿主机进行访问的。但是我自己尝试了一下在本地使用6379端口竟能直接访问。

netstat -tlunp
ps:通过netstat查看的是处于监听状态的应用（可以理解为已经启动的应用），和安全组没有任何关系，只有在安全组放行的端口才能在公网访问

找到端口对应的进程id，直接kill掉这个进程，端口就关闭了

最终的解决办法，在阿里云控制台配置安全组，关闭了对6379端口的开放。
c. 不对外开放6379端口