0 继续篇章
在上一篇中，从防御的角度详细描述了应急响应以及流程。本篇继续从日志等入侵痕迹中分析，寻求突破，以一个攻击者的角度还原redis攻击，从未授权访问到写入ssh公钥直至控制整台服务器，进一步确定此次勒索事件的根本原因。
1 入侵痕迹
查看最近一个月更改的文件
使用root账号登录x.x.x.x，在根目录下查看ssh相关的可疑文件。
进入ssh文件夹，查看ssh文件内容：
2 漏洞排查
从执行命令记录分析，可疑操作：测试bash远程解析命令执行漏洞的poc语句。
因此对该主机进行漏洞扫描，未发现存在bash漏洞。
2.2 redis未授权访问漏洞验证
使用redis客户端尝试连接x.x.x.x成功，且发现ssh公钥
执行服务器操作指令，获取redis以及服务器基本信息：
获取cat:
设置redis备份路径（以此说明redis权限过大，具有root权限）
3 攻击过程
通过结合服务器被入侵痕迹与漏洞情况进行分析，判定：主机x.x.x.x由于Redis未授权访问漏洞，造成SSH免密码登录。
为了更好地理解该主机如何被入侵至沦陷，现将模拟黑客手法还原整个攻击过程。
sectest写入成功
有时候在利用redis写公钥后依然不能空密码登录，可能是由于authorized_keys的权限问题，可通过linux任务计划来设置权限为600
4 修复建议
<1>权限设置
将redis权限设置为最小化权限，禁止使用root权限运行。区分普通用户和admin权限，普通用户将会被禁止运行某些命令，如config。
<2>端口设置
配置bind选项，限定可以连接Redis服务器的IP，修改 Redis 的默认端口6379。
<3>强口令设置
对redis设置强口令，禁止未授权访问。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/177318.html