首页/资讯中心/详情

挖矿木马攻击路径转向：Redis、Docker等非Web服务漏洞防御实战

挖矿木马攻击路径转向：Redis、Docker等非Web服务漏洞防御实战
📅 发布时间：2026/6/24 7:44:10

1. 项目概述：当挖矿木马不再走“寻常路”

提起挖矿木马，很多安全从业者或运维工程师的第一反应往往是：检查Web服务器，看看是不是哪个应用有漏洞被植入了后门。这确实是过去几年最常见、最“主流”的攻击路径。攻击者利用Web应用（如CMS、框架、中间件）的远程代码执行漏洞，一键上传脚本，然后开矿。但如果你还只盯着Web端口，可能已经错过了真正的战场。

我最近处理了几起安全事件，发现一个明显的趋势：攻击者正在大规模转向利用非Web漏洞进行初始入侵和挖矿木马植入。这些漏洞存在于数据库、缓存服务、远程管理协议、甚至是一些企业内部的协作软件中。它们往往被默认开放，但安全配置薄弱，甚至被管理员遗忘在角落。攻击者利用这些“侧门”悄无声息地进入，其隐蔽性和危害性有时远超传统的Web攻击。

这篇文章，我就结合近期的实战案例，深入解析挖矿木马如何利用这些非Web漏洞“另辟蹊径”。我们会拆解几种典型漏洞的攻击链，从漏洞原理、利用手法，到入侵后的行为特征、排查思路和加固建议，提供一个完整的防御视角。无论你是安全工程师、运维人员，还是对系统安全感兴趣的技术爱好者，理解这些“非主流”攻击路径，对于构建更立体的防御体系都至关重要。

2. 核心攻击向量：四大典型非Web漏洞场景解析

为什么攻击者要转向非Web漏洞？核心原因在于“攻其不备”。随着云原生、微服务架构的普及，以及企业对Web应用安全意识的提升，直接攻击80/443端口的成本在增加。相反，许多用于支撑业务的后端服务，其安全水位却参差不齐。攻击者通过扫描全网，可以轻易发现大量暴露在公网且存在已知漏洞的非Web服务。

2.1 Redis未授权访问与主从复制漏洞

Redis作为高性能的内存数据库，在缓存、会话存储等场景应用极广。但其默认配置（无密码、绑定0.0.0.0）如果暴露在公网，就是一场灾难。

攻击原理与利用链：攻击者扫描到开放6379端口的Redis服务后，首先尝试无密码连接。一旦成功，便拥有了在Redis服务器上执行命令的能力。经典的攻击手法是使用Redis的CONFIG SET命令修改持久化文件路径和文件名，将一个恶意的SSH公钥写入到目标服务器的/root/.ssh/authorized_keys文件中，从而直接获取root权限的SSH访问。

更隐蔽的是一种利用Redis主从复制机制的攻击。攻击者将自己伪装成“主节点”，命令受害Redis服务器作为“从节点”同步数据。而同步的“数据”，实际上是一个精心构造的.so共享库文件（即Redis模块）。当从节点加载这个恶意模块后，攻击者便能通过模块提供的命令在服务器上执行任意系统命令，整个过程无需向磁盘写入任何文件，更加难以被基于文件行为的检测手段发现。

注意：很多管理员认为内网的Redis服务是安全的，但一旦边界被突破（例如通过一个脆弱的Web应用），内网的Redis就会成为攻击者横向移动的跳板。因此，内网Redis的安全配置同样不能松懈。

实操排查要点：

  1. 端口与进程检查：netstat -tlnp | grep 6379查看Redis监听地址。如果绑定在0.0.0.0或公网IP上，风险极高。
  2. 配置审计：检查Redis配置文件redis.conf，确认requirepass是否设置了强密码，bind是否限定为必要的内网IP，protected-mode是否设置为yes。
  3. 命令历史与日志：检查Redis的慢查询日志或使用redis-cli连接后执行INFO commandstats，观察是否有异常的CONFIG、SLAVEOF、MODULE等命令执行记录。
  4. 文件与进程监控：检查/root/.ssh/authorized_keys文件是否有未授权的公钥新增。使用ps aux或top命令查看是否有异常进程（如minerd、xmrig、sysupdate等挖矿进程或其变种）。

2.2 Docker Daemon API未授权访问

Docker的便利性使得其API接口（默认监听2375端口）有时会被不当暴露。获得此API访问权限的攻击者，等同于获得了宿主机的root控制权。

攻击原理与利用链：攻击者通过HTTP请求直接与Docker Daemon通信，可以执行创建容器、操作镜像等所有Docker命令。一个典型的挖矿木马植入流程如下：

  1. 攻击者通过http://<target_ip>:2375/version验证API可访问。
  2. 创建一个容器，并使用-v /:/host参数将宿主机的根目录挂载到容器内。
  3. 在容器内执行命令，例如chroot /host切换到宿主机环境，然后下载并执行挖矿脚本。
  4. 或者，直接运行一个包含挖矿程序的镜像（攻击者事先上传到公共仓库或私有仓库）。

由于容器技术本身具有隔离性，通过容器运行的挖矿进程，在宿主机上ps查看时，进程名可能就是容器本身的进程（如docker-proxy或容器ID），伪装性极强。

实操排查要点：

  1. 端口暴露检查：netstat -tlnp | grep 2375或2376。任何非本地回环地址（127.0.0.1）的监听都是高风险信号。
  2. Docker配置审计：检查Docker服务启动参数（systemctl cat docker）或配置文件（/etc/docker/daemon.json），确认是否设置了-H tcp://0.0.0.0:2375这类危险参数。正确的做法是仅使用Unix Socket（/var/run/docker.sock）或为TCP连接配置TLS证书认证。
  3. 容器审查：运行docker ps -a查看所有容器，特别关注那些使用--privileged（特权模式）、挂载了宿主机敏感目录（如/、/etc、/root）的容器。检查其镜像来源是否可信。
  4. 资源监控：挖矿会消耗大量CPU。使用docker stats命令可以查看各个容器的资源使用情况。一个持续占用高CPU的陌生容器极其可疑。

2.3 SSH弱口令与密钥泄露

这可以算是最“古典”却依然有效的攻击方式。虽然SSH是Web之外的管理协议，但因其普遍性，依然是攻击者暴力破解的重点目标。

攻击原理与利用链：攻击者通过扫描22端口，利用自动化工具（如Hydra、Medusa）对root或常见用户名（如admin, ubuntu, ec2-user等）进行字典爆破。一旦成功，便获得了一个完整的系统shell。此外，服务器上的SSH私钥如果泄露（例如通过代码仓库意外提交），攻击者同样可以无需密码直接登录。

入侵后，攻击者通常会进行一系列“维稳”操作：下载挖矿木马、修改计划任务（crontab）实现持久化、清除命令历史（history -c或清空~/.bash_history）、可能还会安装rootkit或后门以维持访问。

实操排查要点：

  1. 认证日志分析：首要检查/var/log/auth.log（Debian/Ubuntu）或/var/log/secure（RHEL/CentOS）。大量来自不同IP的失败登录尝试（特别是针对root用户）是正在遭受暴力破解的明确迹象。成功的异常登录记录（如非管理IP、非工作时间）则可能意味着已失陷。
  2. 用户与密钥检查：检查/etc/passwd是否有新增的陌生用户，检查/root/.ssh/authorized_keys以及/home/*/.ssh/authorized_keys是否有未授权的公钥。
  3. 进程与网络连接：使用ps auxf或pstree查看进程树，寻找挖矿进程。使用netstat -antp或ss -antp查看异常的外联IP和端口，挖矿木马通常会连接矿池（如stratum+tcp协议的3333、4444、5555端口或自定义高端口）。
  4. 持久化位置排查：重点检查系统计划任务：crontab -l（当前用户），ls -la /etc/cron*，/var/spool/cron/。同时检查系统服务（systemctl list-units --type=service）、开机启动项（/etc/rc.local）以及用户profile文件（~/.bashrc,~/.profile）是否被注入了恶意命令。

2.4 其他常见非Web服务漏洞

除了上述三者，攻击面还有很多：

  • Elasticsearch未授权访问：暴露9200端口，攻击者可利用其脚本功能（如Groovy）执行命令，或直接写入恶意数据。
  • Memcached未授权访问：暴露11211端口，虽不能直接执行命令，但可用于发起DRDoS放大攻击，或作为数据中转站。在某些配置下，结合其他漏洞也可能导致问题。
  • Jenkins、GitLab等CI/CD工具漏洞：这些工具通常拥有较高的执行权限。攻击者利用其RCE漏洞（如反序列化、脚本执行），可以在构建节点或主控机上直接运行挖矿脚本。
  • SMB/RDP协议漏洞：如永恒之蓝（MS17-010），攻击者可以利用其在Windows系统间传播，并最终投放挖矿木马。

3. 入侵后的行为分析与深度排查

当攻击者通过上述任一漏洞进入系统后，其后续行为有很强的模式化特征。理解这些特征，能帮助我们更快地从海量日志和进程中找到蛛丝马迹。

3.1 挖矿木马的常见行为特征

  1. 高CPU占用：这是最直观的表现。使用top或htop命令查看，通常会发现一个或多个进程长期占用接近100%或一个核心100%的CPU。进程名可能经过伪装，如kworkerds、sysguard、kinsing等。
  2. 异常网络连接：挖矿进程需要与矿池通信。使用netstat -antp | grep ESTABLISHED或lsof -i查看，寻找连接到非常见端口（非80、443、22、3306等业务端口）或陌生国外IP的连接。矿池域名或IP可以在威胁情报平台查询。
  3. 文件与路径特征：木马通常会被下载到临时目录（/tmp、/dev/shm）、用户家目录或隐藏目录中。常见文件名有.bashrc的变体、.ssh下的奇怪文件、以.开头的隐藏文件等。使用find / -name "*minerd*" -o -name "*xmrig*" -o -name "*sysupdate*" 2>/dev/null进行搜索。
  4. 进程隐藏手段：
    • 进程名伪装：改名成类似系统进程，如kthreadd、ksoftirqd。
    • 进程文件被删除：木马执行后，删除磁盘上的本体文件，只存在于内存中，增加排查难度。此时需通过ls -la /proc/<PID>/exe查看进程的实际可执行文件路径（可能会显示(deleted)）。
    • 定时任务持久化：通过crontab定时从远程服务器下载并执行脚本，实现“复活”。

3.2 系统级深度排查命令与脚本

单纯的ps和top可能被篡改或绕过。我们需要多维度交叉验证。

CPU与进程排查：

# 1. 使用不可变动的系统工具查看进程 busybox top cat /proc/loadavg # 查看系统平均负载，持续高负载可疑 # 2. 按CPU使用率排序查看进程 ps aux --sort=-%cpu | head -20 # 3. 查看所有进程的完整命令行，过滤常见挖矿关键词 ps auxf | grep -E '(minerd|xmrig|cpuminer|kinsing|sysupdate|kworkerds|\./\.)' | grep -v grep

网络连接排查：

# 1. 查看所有TCP连接，并解析对应进程 ss -antp # 或使用更详细的netstat netstat -antp | grep ESTABLISHED # 2. 检查异常的外联IP（可结合威胁情报） # 例如，查看连接到非内网地址的进程 netstat -anp | awk '$5 ~ /^[0-9]/ {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

文件与定时任务排查：

# 1. 全盘搜索可能的挖矿程序（耗时，可在怀疑时进行） find / -type f \( -name "*minerd*" -o -name "*xmrig*" -o -name "*cpuminer*" -o -name "*kinsing*" \) 2>/dev/null # 2. 检查所有用户的crontab for user in $(cut -f1 -d: /etc/passwd); do echo "=== Crontab for $user ==="; crontab -u $user -l 2>/dev/null; done # 3. 检查系统定时任务目录 ls -la /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly /etc/cron.d/ cat /etc/crontab # 4. 检查最近被修改的可执行文件 find / -type f -perm /111 -mtime -7 2>/dev/null | head -30 # 查找7天内修改过的可执行文件

4. 防御加固与应急响应方案

“治未病”胜于“治已病”。针对这些非Web漏洞，预防和加固是第一道防线。

4.1 针对性的加固措施

  1. Redis：

    • 强制认证：在redis.conf中设置requirepass一个强密码。
    • 网络隔离：通过bind指令限制只监听内网IP或127.0.0.1。绝对不要绑定在0.0.0.0。
    • 禁用高危命令：使用rename-command配置项，将CONFIG、FLUSHALL、MODULE等危险命令重命名为随机字符串或直接禁用（重命名为""）。
    • 以非root用户运行：使用useradd -r redis创建专用用户，并以该用户身份运行Redis服务。

  2. Docker：

    • 禁用TCP监听：除非必要，否则移除-H tcp://...的Docker启动参数。默认只使用Unix Socket/var/run/docker.sock。
    • 启用TLS认证：如果必须远程访问Docker API，务必配置TLS客户端证书认证。这是官方推荐的安全方式。
    • 限制容器能力：运行容器时，避免使用--privileged，并通过--cap-drop移除不必要的Linux能力。
    • 使用用户命名空间映射：启用用户命名空间隔离，避免容器内root等于宿主机root。

  3. SSH：

    • 禁用密码登录，使用密钥对：在/etc/ssh/sshd_config中设置PasswordAuthentication no，PubkeyAuthentication yes。
    • 禁止root直接登录：设置PermitRootLogin no或prohibit-password。
    • 更改默认端口：将端口从22改为其他高端口，能减少大量自动化扫描。
    • 使用Fail2ban：安装配置Fail2ban，自动封禁多次尝试失败登录的IP地址。
    • 密钥管理：对私钥加密，并定期更换。

  4. 通用原则：

    • 最小化暴露：所有非必需对公网开放的服务，一律通过防火墙（如iptables, firewalld）或安全组策略进行限制，只允许特定的管理IP访问。
    • 及时更新：建立补丁管理流程，及时更新操作系统、数据库、中间件等所有软件，修复已知漏洞。
    • 安全基线检查：定期使用像Lynis、OpenSCAP这样的安全基线检查工具对服务器进行审计。

4.2 应急响应流程（当发现疑似挖矿时）

如果已经发现系统异常，请按以下步骤冷静处理：

  1. 隔离与取证（首要）：

    • 网络隔离：立即将受害服务器从网络中断开（拔网线或通过交换机/防火墙隔离），防止其继续感染内网其他机器或对外通信。
    • 镜像备份：在可能的情况下，对系统磁盘创建完整镜像或快照，以备后续法律取证和深度分析。切忌在分析前直接重启或修复，会丢失内存中的关键证据。

  2. 初步分析与遏制：

    • 记录现场：在不影响证据的前提下，快速执行第3.2节中的排查命令，将进程、网络连接、可疑文件路径、crontab内容等截图或保存到本地。
    • 终止进程：找到挖矿进程PID，使用kill -9 <PID>终止。注意，如果存在守护进程或定时任务，单纯杀进程可能很快会复活。
    • 清除持久化：根据排查结果，清理被篡改的crontab、系统服务、启动项文件。

  3. 根因溯源与修复：

    • 分析入侵路径：检查系统日志（auth.log,secure,redis.log,docker.log等），结合可疑文件的创建时间、进程启动时间，推断攻击者最初利用的漏洞。查看last、lastb命令输出，检查登录历史。
    • 修复漏洞：确认入侵路径后，立即按照4.1节的加固措施修复对应的漏洞。例如，如果是Redis未授权，马上设置密码并限制绑定IP。
    • 全面查杀：使用chkrootkit、rkhunter等工具进行rootkit检测。考虑使用专业的EDR（端点检测与响应）工具进行全盘扫描。

  4. 恢复与监控：

    • 恢复业务：在确认系统已清理干净且漏洞已修复后，恢复网络连接，启动业务。
    • 加强监控：部署或增强监控系统，对CPU使用率、异常进程、异常外联网络流量、关键文件改动等设置告警阈值。
    • 复盘总结：对整个事件进行复盘，更新安全策略和运维规范，避免同类事件再次发生。

挖矿木马的攻击方式在不断演进，从Web到非Web，从粗暴到隐蔽。作为防御方，我们的视野也必须从单一的Web应用层，扩展到整个系统暴露面。安全是一个持续的过程，没有一劳永逸的银弹。建立“最小权限”、“纵深防御”的安全理念，保持对系统日志和异常行为的敏感度，定期进行安全评估和加固，才能在这场攻防对抗中占据主动。我个人的经验是，与其在失陷后疲于奔命地排查，不如花时间把上述这些非Web服务的默认配置“收紧”，这往往能挡住绝大部分自动化攻击脚本，性价比极高。