My brain is engaged in the mining code is not a good thought

I've been attacked

Personal server to the end of the last two days has been attacked, because something did not have time to drag treatment, today could not bear it, record it was found after the attack and repair processes.

2019-12-30 23:39:44 cloud shield warning visiting malicious IP 178.170.189.5
This time there is a warning keyword "kdevtmpfsi"

2019-12-31 04:19:19 cloud shield tank mine warning communication behavior 178.170.189.5
kdevtmpfsi

How to find the root cause

kdevtmpfsiVery good disguise, because it is a system process name is very similar kdevtmpfs, accidentally research center of gravity shifted. I now docker program is running, if the host was attacked a serious problem.

Because in itself it is not a professional operation and maintenance, mine entirely speculation. Cms cloud shield aware there may be a security vulnerability, found no abnormalities after scanning the code, here I feel the problem may be more serious.

There are loopholes in the container? Container also run nmp, which would be a problem with the container it? Awkward. cpu occupancy high, docker look cpu container occupied it?

top

Use topname directly to the next chart you can see, kdevtmpfsialmost 100 percent CPU utilization, causing the server is fully occupied by a malicious program, my own service difficult operating normally.

container

cpu is kdevtmpfsi100% occupied mining program. According to the above problem of positioning of the container, the container using the command to view the status docker statsobtained at FIG.

See that redisthe container is utilized, use the command docker exec -it 容器ID /bin/bashinto the interior look at the specific problem? CTRL + P + Q

使用命令 ls -lrt 可以看到最早下载的 kinsing 文件是去年30日,与最早告警时间也基本在同一天。通过搜索学习到这个文件是挖矿程序的手续进程,后续需要清理掉。

按照云盾报警的情况我们看下文件是否存在 /tmp/kdevtmpfsi ,如果存在也需要清理掉才行。文件肯定是存在的,我还干了一件事情就是 kill -9 ID,CPU 占用明显就降下来了 ,然后手动运行了一下这个程序,发现 CPU 直接就飙升了

它是如何做到的

问题找到了,只要杀掉当前进程以及守护进程,问题也就暂时解决了。没有找到根源,问题还是可能被利用,继续写入挖矿程序,我们先思考一下漏洞在哪里呢?

上面分析出来是因为 redis 的漏洞导致的?想一下我们的 redis 是如何安装的,我当初测试一个需要登录才能使用的应用程序,登录的方式是关注公众号,然后获取授权码去解锁使用。就使用 redis 存放了临时 token ,安装 redis 的时候直接就是裸奔在空气中,没有密码。

可以使用命令检测一下,例如我的公网 IP 是 110.110.110.110。 只需要使用命令 redis-cli -h 110.110.110.110 -p 6379 就直接可以连上我的 redis 服务了。

通过云盾安全预警查看到《【漏洞预警】Redis 4.x/5.x 远程命令执行高危漏洞》,解决这个问题的关键可以设置仅内网访问 redis,特殊对外的 IP 使用密码策略。

version: '3'
services:

  # 使用 command 命令设置一下密码
  redis:
    image: redis:5.0.7
    command: ["redis-server", "--requirepass", "yourpassword"]
    hostname: redis
    networks:
      - redis-net
    volumes:
      - redis-data:/data

networks:
  redis-net:

volumes:
  redis-data:

安全放心上

长呼一口气之后,想起了《亡羊补牢》的故事。

Guess you like

Origin www.cnblogs.com/unofficial/p/12182590.html