尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

Minecraft服务器“HIM”跟踪事件排查:日志分析与权限审计实战指南

Minecraft服务器“HIM”跟踪事件排查:日志分析与权限审计实战指南 大家可能在游戏社区里看过类似截图某个 Minecraft 服务器里一位名字叫Herobrine或HIM的“玩家”悄悄出现在别人身后不说话、不互动过一会儿又消失。很多新人会把它当成都市传说但如果你是自己搭过服务器、做过服务器运维就会知道这类“神秘跟踪”现象背后百分之九十是技术问题——可能是权限漏洞、可能是恶意插件、可能是后台机器人账号甚至是真实入侵者在服务器上留下的异常记录。本文不聊灵异故事而是把这个热门场景转成一次完整的服务器安全排查实战当你在服务器中发现“不明实体”或“异常账号”在跟踪玩家、执行命令、修改数据时如何通过日志分析、权限审计、进程排查和网络安全手段把问题定位出来并加固到不再发生。整个排查思路不只适用于 Minecraft 服务器也适用于 Linux 服务器、云服务器、应用服务器的日常运维。如果你正被“服务器里是不是进了人”这个问题困扰这篇文章可以给你一套能直接照着操作的排查方案。1. 服务器“神秘跟踪”到底是什么1.1 现象背后的本质先明确一个前提在 Minecraft 这类多人服务器中所有玩家行为都通过服务器端处理。理论上服务器不会凭空生成一个“跟踪者”。当你知道某个玩家正在被跟踪时本质上说明服务器内部存在某段逻辑正在执行“获取目标玩家位置、跟随目标、记录目标行为”的操作。常见的来源有四类权限失控某个普通玩家拥有op权限或teleport、tp、effect等命令权限可以偷偷传送到目标身边观察。这是最常见、最容易排查的方向。恶意插件或模组服务器安装的某个插件、模组、脚本带有跟踪功能例如“假玩家机器人”“隐身追踪”类模组被误安装或夹带在整合包中。后台机器人账号攻击者通过弱密码或漏洞拿到服务器后台账号使用自动化机器人登录服务器持续跟踪某个玩家并记录聊天、坐标、背包信息。控制台或 RCON 操作如果开启了 RCON 远程管理端口即使不在游戏内也能执行命令传送、查询玩家位置。这类操作不会被玩家列表显示但会留下控制台日志。1.2 为什么不能只靠“踢人”解决很多服务器管理员遇到这种情况第一反应是把可疑玩家踢出服务器或者封禁 IP。但“跟踪”往往不是持续在线行为而是间歇性的目标玩家上线后异常实体才出现目标下线后异常实体就消失。如果只做封禁攻击者换一个账号甚至换一台服务器入口就能回来问题无法根除。正确的排查逻辑是先收集证据——日志、命令记录、玩家连接记录。再定位源头——是玩家权限、插件逻辑、后台账号还是网络入口。最后做加固——回收权限、替换插件、修改密码、限制远程管理端口。1.3 适用场景与阅读收益这篇文章适合自己搭建过 Minecraft 服务器、又想搞清楚“跟踪者来源”的服主。负责 Linux 服务器、云服务器安全巡检的运维初学者。对服务器日志分析、权限审计、网络连接排查感兴趣的开发者和安全爱好者。读完你能掌握如何从服务器日志中还原“跟踪者”的行为轨迹。如何检查所有玩家和管理员的真实权限。如何区分“玩家操作”和“后台程序操作”。如何用命令定位可疑进程、网络连接和登录记录。一套适用于大多数服务器的安全加固清单。2. 环境准备与版本说明由于“HIM 跟踪”这类现象绝大多数集中在 Minecraft Java 版服务器中同时排查思路也适用于通用 Linux 服务器本文将同时给出两套环境参考。2.1 Minecraft 服务器端环境项目推荐环境说明操作系统Ubuntu 22.04 LTS 或 CentOS 7大多数云服务器默认系统Java 版本Java 17 或 Java 21高版本 Minecraft 服务端要求 Java 17服务端核心Paper / Spigot / Purpur支持插件且日志结构清晰权限插件LuckPerms社区使用最广权限查询直观反作弊插件Matrix / Vulcan示例可检测飞行、传送、假人行为远程管理不建议开启 RCON如需开启仅绑定内网RCON 是常见入口需要说明具体服务端版本取决于你使用的 Minecraft 大版本。比如 1.20.x 建议用 Paper 1.20 分支1.21.x 建议对应新版本。不要盲目下载高版本插件否则可能不兼容。下面所有示例命令重点演示排查思路根据你的实际版本调整路径即可。2.2 通用 Linux 服务器环境如果你在排查过程中需要登录云服务器或独立服务器本身推荐在本地准备一台 Linux 服务器Ubuntu 20.04/22.04 或 CentOS 7/8。SSH 客户端Windows 下可用 PowerShell 或 MobaXtermmacOS/Linux 直接用终端。基本的grep、awk、ss、last、journalctl命令。root 或具有sudo权限的管理账号。这里强调一个安全底线任何排查和生产操作都应在自己拥有合法管理权限的服务器上进行避免在未经授权的系统上执行命令。修改权限或删除数据前先备份测试环境验证后应用到生产。2.3 需要提前准备的日志文件在开始排查前先确认以下文件是否存在Minecraft 服务端日志logs/latest.logMinecraft 服务端历史日志logs/2024-01-01-1.log.gz玩家连接记录部分服务端会写usercache.json权限插件日志LuckPerms 一般存储在插件数据文件夹中Linux 登录日志/var/log/auth.logUbuntu或/var/log/secureCentOS准备好了就可以进入下一步。3. 排查前的核心概念命令、权限、日志三者的关系3.1 服务器命令是怎么被记录的Minecraft 服务器中命令执行主要有三种入口游戏内玩家执行命令以/开头会写入服务端日志。控制台执行管理员在服务器终端输入命令会以[Server]前缀记录在日志中。RCON 远程执行通过 RCON 协议从外部执行命令会记录远端 IP 和命令内容。以 Paper 服务端为例你在logs/latest.log中会看到类似内容[14:23:45 INFO]: [Not Secure] Steve /tp Alex [14:23:45 INFO]: Steve teleported Alex from (100.0, 64.0, 200.0) to (120.0, 70.0, 180.0) [14:25:10 INFO]: [Server] op Steve第一条说明玩家 Steve 执行了/tp Alex命令第二条是执行结果第三条是控制台给 Steve 添加了 OP 权限。这就是日志的价值它能把“跟踪行为”还原成一条条可验证的命令记录。3.2 权限系统的两个常见误区误区一op权限就是一切。在很多小型服务器中服主为了省事会直接给信得过的朋友开 OP。但 OP 可以执行所有命令包括隐身、传送、查看背包、修改模式。一旦某个 OP 账号被盗或被朋友滥用就会出现“看不见的跟踪者”。误区二普通玩家没有权限就无法造成影响。如果服务器安装了支持传送、跟随、隐身效果的插件而这些插件的默认权限没有正确配置普通玩家可能也拥有/tpa、/follow、/vanish等命令的默认权限。所以排查时必须逐项查清“谁拥有什么权限”而不是只看 OP 列表。3.3 为什么“跟踪者”很难被玩家发现很多“神秘实体”由于使用了隐身效果或假人机器人普通玩家看不到名字只能看到身体轮廓或感受到“背后有人”。这进一步增加了排查难度。但从服务器角度看隐身并不等于消失隐身玩家仍然会出现在玩家列表中除非使用“隐身”插件或vanish功能。隐身玩家仍然会触发监听事件例如走进区块、查看箱子、使用命令。大多数反作弊插件能检测“隐身状态下仍然移动”的异常。因此排查的突破口不是“用眼睛找”而是通过日志和事件记录找。4. 从服务器日志定位“跟踪者”的实战步骤4.1 确认目标玩家的在线行为轨迹假设你的服务器里玩家Alex报告“总觉得被什么东西跟踪”但服务器玩家列表里看不到可疑玩家。第一步就是在日志中搜索 Alex 身边的加载事件、实体交互事件和命令事件。进入服务端目录先看今天的日志cd /home/minecraft/server grep Alex logs/latest.log | tail -n 200如果日志太多可以结合时间过滤grep Alex logs/latest.log | grep 14:2[0-9] | tail -n 100如果发现类似下面这样的事件就说明有玩家或程序在持续关注 Alex 的位置[14:20:01 INFO]: [Not Secure] Herobrine /tp Alex [14:20:02 INFO]: Herobrine teleported Hermobrine to Alexs position [14:21:37 INFO]: Herobrine issued server command: /gamemode spectator这里可以看到一个名为Herobrine的账号在 Alex 在线期间频繁执行传送和旁观模式命令。这就是最直接的证据。4.2 从历史日志中查找规律如果latest.log中没有异常可能跟踪者已经清理过日志或者只在特定时间段出现。用 gzip 解压历史日志并搜索zcat logs/*.log.gz | grep Alex alex_history.txt grep -E tp|teleport|vanish|follow|gamemode alex_history.txt | head -n 50通过时间排序能看出如下规律时间操作账号20:01:15/tp AlexHerobrine20:01:16传送到 Alex 附近Herobrine20:05:44/gamemode spectatorHerobrine21:30:01/vanishHerobrine这一步要回答的问题有三个跟踪者账号是否固定。跟踪行为是否集中在某些时间段。跟踪时是否同时执行了其他高风险命令。4.3 检查玩家列表与在线记录很多管理员不知道Minecraft 服务器会在usercache.json中记录所有曾经登录过的玩家名称和 UUID。如果“Herobrine”这个账号从未真正登录那它的命令来源就更可疑。cat usercache.json | python3 -m json.tool | grep -A2 -B2 Herobrine如果usercache.json中存在该账号说明确实有人用这个账号登录过服务器如果不存在说明命令可能是通过控制台或 RCON 伪造的。这种情况往往比玩家操作更危险。4.4 控制台日志与 RCON 来源排查在 Paper 服务端可以通过启动参数查看是否开启了 RCON。打开server.propertiesenable-rcontrue rcon.passwordyour_strong_password rcon.port25575如果enable-rcontrue你要立刻检查两项内容你的 RCON 密码是否强度足够。rcon.port是否只绑定在内网而不是对所有公网开放。检查端口监听状态ss -lntp | grep 25575如果你看到输出中的地址是0.0.0.0:25575说明 RCON 对所有公网开放这是极其危险的配置。攻击者只要能爆破密码就能远程执行任何服务器命令包括跟踪玩家。排查命令记录时注意控制台输出都会带[Server]前缀。如果发现类似[03:12:55 INFO]: [Server] tp Alex [03:12:55 INFO]: [Server] gamemode spectator Herobrine且时间上你并没有在终端里操作几乎可以断定是 RCON 或后台 API 调用。5. 权限审计彻底查清“谁能执行跟踪命令”5.1 从 OP 列表开始检查在确认日志中的命令来源后必须把所有拥有高权限的账号列出来。查看服务端ops.jsoncat ops.json | python3 -m json.tool如果列表中出现了你不认识、或者你不记得给过权限的玩家名那就是第一个风险点。以下命令可以直接查看带 OP 的账号grep -E name|level ops.json正常情况下输出类似这样{ name: Steve, level: 4 }level为 4 代表最高管理员权限。如果出现多个 level 为 4 的账号要逐一确认是否为本人或信任的管理员。5.2 用 LuckPerms 查看所有权限组如果服务端安装了 LuckPerms建议在控制台执行lp listgroups查看有哪些权限组再查看每个组的权限lp group default info lp group admin info lp group vip info如果发现default组中存在th.crafting.teleport、essentials.tpa、essentials.follow之类权限说明普通玩家拥有传送或跟随能力跟踪者完全不需要 OP 就能靠近目标。重点检查以下几类权限权限作用风险等级minecraft.command.tp传送自己或他人高minecraft.command.gamemode切换游戏模式高essentials.tpa传送到其他玩家身边中essentials.tpall传送到所有玩家身边高essentials.vanish隐身高vanish.*隐身功能高对于不需要这些权限的玩家组直接取消lp group default permission unset essentials.tpa lp group vip permission unset essentials.vanish5.3 检查和清理无效账号有时候跟踪者并非玩家而是后台注册的机器人账号。检查玩家数据库以 LuckPerms 和 Essentials 为例find plugins/Essentials -name *.json | grep userdata或者直接看usercache.json中 UUID 异常的账号。如果一个账号显示的名称全是乱码、从未在聊天频道发言、但频繁执行命令基本可以判定为机器人账号。清理无效账号前先确保你已备份数据库和用户数据然后通过控制台操作luckperms user Herobrine delete删除账号后再重启服务器确认无影响。6. 深入排查通用 Linux 服务器里的“跟踪者”6.1 查看当前的登录会话很多时候“服务器里的神秘跟踪者”不只是 Minecraft 层面的账号可能攻击者已经拿到了 Linux 服务器本身的 SSH 登录权限。这种情况更加严重因为他能看到服务器所有内容包括日志、配置、玩家数据。先用who和w查看当前登录用户who w输出包含用户名、登录终端、登录时间和来源 IP。如果你发现一个来自陌生 IP 的 root 登录要立即警觉。再查看完整登录历史last -n 20last命令读取/var/log/wtmp记录所有成功登录的信息。如果某条记录的 IP 不是你常用 IP说明该账号可能已经泄露。6.2 追踪命令执行历史查看 root 用户和其他管理员的历史命令sudo cat /root/.bash_history | tail -n 100如果你发现.bash_history中出现了cat /etc/shadow、find / -name *.db、tar czf /tmp/backup.tgz /home等命令说明可能有攻击者正在批量收集服务器数据。这比 Minecraft 里的“跟踪”更可怕因为它属于数据窃取行为。你也可以使用auditd审计日志来查看谁执行了特定命令sudo auditctl -w /etc/shadow -p wa -k shadow_watch sudo ausearch -k shadow_watch --start today不过需要注意auditd默认可能未安装。如果未安装建议先安装配置后再使用不建议在生产环境上随意进行未授权的日志审计变更。6.3 检查异常网络连接“跟踪”往往需要回传数据。Minecraft 服务器中的跟踪插件或机器人脚本可能会把玩家坐标发送到外部服务器。检查当前所有对外连接ss -tnp | grep ESTAB重点检查指向陌生 IP 的 ESTABLISHED 连接尤其是 Java 进程和 Python 进程。例如ESTAB 0 0 123.123.123.123:25565 8.8.8.8:443 users:((java,pid1234))这个例子中Minecraft 服务器 Java 进程连接了8.8.8.8:443。如果这不是你的服务器使用的 API 服务就要进一步检查进程启动参数ps aux | grep 1234 sudo ls -l /proc/1234/exe sudo cat /proc/1234/cmdline通过进程路径你能判断 Java 服务端是否被人加了启动参数例如-javaagent:/path/to/malicious.jar。如果有说明服务端本身可能被插入了恶意 agent。6.4 防火墙与端口检查有些“跟踪者”并不在服务器内而是通过公网扫描器获取玩家在线状态再在游戏里建号跟踪。这时你要检查服务器的防火墙规则确认只放行必要端口sudo iptables -L -n如果你是云服务器建议同时也登录云控制台检查安全组规则。不要把 Minecraft 服务端的 25565 端口暴露给全世界尽量通过安全组限制为可信任 IP 或使用代理转发。如果服务器本身开启了防火墙可以直接限制 RCON 端口只能内网访问sudo ufw allow from 127.0.0.1 to any port 25575 sudo ufw deny 25575如果使用云服务器安全组就把 25575 端口从入站规则中删除只保留内网互通规则。7. 常见问题与排查思路7.1 玩家列表里没有可疑玩家但日志中却有传送命令现象可能原因解决思路日志有/tp玩家列表无此人OP 玩家使用了隐身命令查essentials.vanish权限与命令记录日志有[Server]前缀命令控制台或 RCON 执行排查 RCON 是否开启解析对应来源 IP玩家列表偶现名字随即消失机器人账号自动登录又退出查看usercache.json与玩家数据库封禁 UUID处理建议先取消所有玩家组的传送、隐身权限再观察两天。如果日志中仍有类似命令基本可以确定是控制台或后台操作。7.2 服务器卡顿与“跟踪”同时出现某些跟踪插件会频繁读取玩家位置导致服务器 TPS每秒游戏刻数下降。你可以用以下命令查看 TPS 和实体数量tps list如果在list输出中看到“There are 0 of a max of 20 players online”但同时“entities”数量异常偏高建议检查区块内是否存在隐形盔甲架、隐形的假玩家实体。这里的排查方式是在服务端安装Spark插件并生成性能报告spark profiler spark heapdump通过报告可以看到哪些代码路径占用了大量 CPU如果某个插件类名与跟踪、坐标记录有关就优先替换或禁用该插件。7.3 修改密码后“跟踪者”仍然出现如果排查玩家权限和插件后问题依旧则要考虑服务器进程本身是否被替换。很多攻击者在拿到服务器权限后会下载一个修改版服务端让服务端自带“管理员后门”。这个时候建议停止服务器。备份world文件夹和关键配置。重新下载官方服务端或可信镜像中的服务端。对比新旧服务端的 jar 包哈希值sha256sum paper-1.20.4.jar更换服务器系统的 root 密码、数据库密码、FTP 密码。重启后再观察。注意如果服务器上还有你不知道的内部账号只改密码是不够的必须检查所有系统用户sudo awk -F: $30 {print $1} /etc/passwd这个命令列出所有 UID 为 0 的用户UID 为 0 就是超级管理员权限。正常情况下只有root一个用户。7.4 服务器面板中看到陌生文件有些服务端目录下会出现.jar、.sh、.py文件名字类似plugins.jar、Helper.jar、run.sh。检查这些文件的创建时间ls -la plugins/ stat plugins/可疑文件.jar如果创建时间不在你搭建服务器的时间点且文件较大、命名模糊建议先移动到隔离目录不要直接删除然后查看文件内容unzip -l plugins/可疑文件.jar | head -n 50多数跟踪插件会在插件描述文件plugin.yml中声明主类和权限节点。看到异常权限节点时优先在测试环境复现再决定是否删除。7.5 日志文件被人为清空如果logs/latest.log只有少量记录但磁盘空间明明很充足说明有人删除了日志。此时不要慌张按顺序检查服务端进程是否被重启过。系统日志中是否有sudo rm -f logs/的记录。玩家数据文件夹的修改时间。注意日志被清空本身就是一个安全事件说明攻击者已经具有文件操作权限。这时候最稳妥的方案是保存玩家数据、重置服务端、修改所有密码、检查 SSH 公钥文件cat ~/.ssh/authorized_keys如果你发现里面多了一条你从未添加过的公钥那你的 SSH 登录通道已经被持久化控制了。必须立即删除对应公钥并更换密钥对。8. 服务器安全加固与长期监控最佳实践8.1 最小权限原则权限管理的核心原则是能不给的权限坚决不给。对于 Minecraft 服务器可以这样配置普通玩家只有聊天、移动、交互、合成基础权限。VIP 玩家可以增加一部分不影响平衡的指令但不给传送类权限。管理员单独设组不直接给 OP而是给细分权限。只有服主或绝对信任的核心团队成员可以拥有*权限。在 LuckPerms 中创建管理员组并分配单个权限lp creategroup admin lp group admin permission set minecraft.command.gamemode true lp group admin permission set minecraft.command.tp true lp group admin permission set luckperms.* true lp user Steve parent add admin这样就避免了op权限的“一键全部授权”。8.2 配置统一日志与安全审计建议从今天开始每天定时备份日志文件并定期检查。可以写一个简单的 cron 任务0 2 * * * tar czf /backup/logs_$(date \%F).tar.gz /home/minecraft/server/logs /dev/null 21同时把服务器关键配置文件的修改时间记录到独立文件中方便及时发现文件被篡改find /home/minecraft/server -name *.yml -o -name *.properties -newer /home/minecraft/server/banned-players.txt8.3 远程管理安全云服务器、独立服务器的远程管理接口是攻击者的首选入口。以下是必须落实的几点关闭 root 密码登录使用密钥登录。SSH 端口不要使用默认的 22改成高位端口。Minecraft 服务端尽量不开启 RCON必须开启时仅限本机访问。如果你需要远程管理 Minecraft 服务端建议使用 SSH 隧道代替直接暴露 RCON。SSH 隧道方式连接 RCON 的示例ssh -L 25575:127.0.0.1:25575 useryour_server_ip执行后本地127.0.0.1:25575会转发到服务器的127.0.0.1:25575这样公网就无法直接连接 RCON 端口。8.4 插件与依赖管理很多恶意跟踪功能是随着“整合包”或“免费插件”进入服务器的。下载插件时要注意以下几点只从知名插件发布平台下载。安装插件前先解压查看有无额外 jar 或可执行文件。优先使用开源、维护活跃、更新频繁的插件。每次更新服务端或插件前先备份旧版本。如果插件数量很多可以用脚本检查插件目录中的文件哈希与发布版本进行比对。以下是生成当前插件哈希的参考命令sha256sum /home/minecraft/server/plugins/*.jar /root/plugin_hashes.txt把首次生成的哈希保存好之后定期重新生成并对比异常变化一目了然。8.5 建立应急响应流程最后建议每个服务器管理员都准备一份简单的应急响应流程防止真遇到问题时手忙脚乱确认事件发现跟踪行为后先保留证据日志、截图、时间。切断外部管理入口临时关闭 RCON、SSH 端口对外访问或修改防火墙规则。备份关键数据立即备份world文件夹、玩家数据、配置文件。定位和隔离禁用可疑账号、移除可疑权限、隔离可疑插件。排查漏洞检查密码是否泄露、插件是否存在已知漏洞。加固修复修改密码、更新插件、关闭多余端口。持续观察修复后至少观察一周保留日志确认无再次出现。9. 总结与下一步学习方向整个排查过程的核心可以浓缩成一句话不要被“神秘 HIM”这个表象迷惑服务器中任何异常行为都是可记录、可排查、可修复的。只要把命令日志、权限配置、进程状态、网络连接和系统用户检查五件事做好绝大多数跟踪问题都能被定位到具体来源。如果你这次已经按照文章操作成功找到了“跟踪者”的账号或来源接下来可以继续学习的方向包括LuckPerms 的高级权限配置与多服务器同步。Linux 日志分析与auditd审计系统的深入使用。云服务器安全组的精细化配置。Java 服务端进程分析识别恶意 agent 和注入行为。常见 Minecraft 服务端漏洞的原理和修复方式。无论你是第一次搭建服务器的新手还是管理过多台服务器的老手都建议把“跟踪者排查”这件事当成一次完整的安全演练。每一份日志记录、每一条命令记录都是服务器留给你最可靠的话。下次再遇到类似情况冷静下来打开日志一步步查往往比删除重装更有效。希望这篇排查实战对你有帮助。如果你在实践中遇到了其他奇怪的服务器现象也可以按同样的思路自己拆解一遍——多数“神秘事件”都只是还没被分析清楚的技术问题。
返回列表