solar_Linux后门排查
跳板机疑似被遗留后门,请排查
1、找到可疑进程完整路径
2、找到被横向的服务器IP
3、连接被横向服务器
flag格式为 flag{base64{完整路径}|服务器IP|服务器中flag文本}
root:Solar@2025_05_palu!
在做这道题的时候，其实之前已经做过了，所以知道哪些是后门，但是由于之前是在比赛，所以没能沉下心来仔细分析，今天重新分析之后，有了更多的理解，感谢帕鲁杯的主办方们。
首先下发环境然后远程连接
题目已经给了账号密码了，我们输入账号密码直接进入。
我们查看一下端口连接情况，这里没有安装netstat，我们使用ss命令进行查询
在最下边可以看到有四个ssh连接，其中有三个是被连接，有一个是主动连接，那这个主动连接的IP就很有可能是被横向的IP，我们查看一下主动连接的这个IP
此时我们已经获得第一个flag：ZX0001S，并且根据题目，我们可以确定IP：49.232.112.164就是被横向的IP。
我们重新回到本机上，并且查看端口情况
可以看到，本机开放了33060、3306、6379、80、22、6010、6011端口，其中占用22、6010、6011端口的服务为ssh，80端口则是nginx，33060和3306则很有可能是数据库服务，而且6379这个端口很熟悉，redis的默认端口，我们可以看一下本机是否开了redis服务
可以看到，确实打开了redis服务，此时我们可以从四方面进行猜想攻击者是如何攻击成功的。
第一种可能是nginx服务，通过文件上传等方式写入木马，从而获得控制权限，那么我们可以先查看一下nginx日志
可以看到，日志为空，这种情况要么是网站自启动后就没再访问过，要么就是被攻击者删掉了所有日志，但如果是攻击者删除的话，那他肯定在系统中有其他的后门，我们暂且放一下。
第二种可能是攻击者通过数据库入侵，我们查看一下数据库有没有可能被攻击
可以看到，mysql存在两个服务，也可以对应上3306和33060，我们查看一下数据库日志
可以看到，日志中也无异常信息，我们也可以稍微排除一下数据库的问题。
接下来我们看第三种可能性，攻击者可能通过redis入侵，我们查看一下redis日志
可以发现，redis版本为5.0.7，这个版本存在未授权访问漏洞，我们测试一下看是否存在
我们可以看到，未授权访问漏洞是存在的，那么攻击者很有可能是通过redis进行入侵，从而写入木马和ssh公钥进入系统，我们可以查看一下第四种可能，攻击者通过ssh入侵，我们查看一下ssh的日志
可以看到，我们无法查看到ssh的日志，攻击者可能已经将其删除
结合四种情况，攻击者最有可能发起的攻击方式其实是第三种，通过redis未授权访问漏洞进行攻击
既然攻击者最有可能通过redis入侵，回忆之前查看端口连接时所看到的三个连接情况，首先排查攻击者是否写入了公钥
可以看到，root账户下并无公钥存在，我们可以考虑到两种情况，分别是攻击者已将其删除，第二种是在没有公钥的情况下，攻击者依然进行了ssh连接，那么必然有后门在持续进行连接，我们再次查看进程运行情况
可以看到，/usr/lib/systemd/systemd-login 正在进行ssh连接，而正常情况下，/usr/lib/systemd/systemd-login 是 systemd 系统守护进程 的一部分，主要负责 用户登录会话管理 和 用户级服务的启动与管理。它在 Linux 系统中扮演着关键角色，尤其在处理用户认证、会话生命周期、资源分配等方面。
可以认定，其就是攻击者留在系统的后门，但是/tmp/run.sh也很可疑，我们再次进行排查
可以发现，该文件已被删除，但仍在运行，我们通过之前查看进程时记下的/tmp/run.sh的进程号，尝试对其进行恢复
可以发现，该文件执行了/tmp/assist.sh脚本，而后清理了痕迹，并且持续运行server.js，我们查看一下server.js文件
该文件创建了一个简单的HTTP服务器，并持续监听所有端口，有可能被恶意利用
接下来，我们再查看/usr/lib/systemd/systemd-login
一目了然，作为CTF靶机，自然是到这里就结束了，但我们是进行应急响应，除了找到攻击链及后门外，还应该将其清理。
rm -rf /usr/lib/systemd/systemd-login
nginx -s stop
rm -rf /app/server.js
kill -9 301 #nginx: master process /usr/sbin/nginx
在有防火墙的情况下封堵80、6010端口 #该系统没有且不可安装
强制重启，将PID 1从/tmp/run.sh更换为原来的/usr/lib/systemd/systemd-logind
重启后看还有无不死马存在，若存在，继续查杀（实际上到这一步已经有些不太会了，希望大佬们教教，如何更有效的杀死不死马）/tmp/run.sh更换为原来的/usr/lib/systemd/systemd-logind
重启后看还有无不死马存在，若存在，继续查杀（实际上到这一步已经有些不太会了，希望大佬们教教，如何更有效的杀死不死马）
