当前位置：首页 > wzjs >正文

python做网站步骤网站建设专业的

wzjs 2025/9/15 13:19:04

python做网站步骤,网站建设专业的,.net asp可以外链其它网站吗,感叹号分销系统solar_Linux后门排查跳板机疑似被遗留后门,请排查 1、找到可疑进程完整路径 2、找到被横向的服务器IP 3、连接被横向服务器 flag格式为 flag{base64{完整路径}|服务器IP|服务器中flag文本} root:Solar2025_05_palu! 在做这道题的时候，其实之前已经做过了&#xf…

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
重启后看还有无不死马存在，若存在，继续查杀（实际上到这一步已经有些不太会了，希望大佬们教教，如何更有效的杀死不死马）

在这里插入图片描述