我的MySQL服务器被攻破！黑客层层设防，双重权限锁定手动破解全过程

云服务器搭载MySQL数据库，是中小业务最常用的架构组合，但3306（尤其Redis 6379等））端口暴露、弱密码、防护缺失，极易成为黑客入侵的首要目标。

近期我的阿里云MySQL生产服务器遭遇恶意入侵，黑客植入持久化定时木马，通过文件特殊属性锁定、系统命令权限篡改、安全软件强制卸载、防火墙封禁等多重手段，锁住Crontab等目录、禁止权限修改、拦截解锁命令，常规清理操作全部失效。

本文完整记录本次入侵故障现象、排障踩坑全过程、手动破解修复步骤，并深度拆解黑客后门守护脚本，附上MySQL+服务器双重安全加固方案，给所有运维、DBA同行避坑参考。

一、入侵核心故障现象

服务器被入侵后，出现大量反常问题，层层限制系统修复操作：

• 服务器load很高

• 定时任务被植入恶意计划，持续执行挖矿/远控木马脚本
• /var/spool/cron目录及 root定时任务文件权限锁定，chmod/chown修改全部提示Operation not permitted
• 核心解锁命令chattr权限被篡改，默认只读无法执行，无法清除文件保护属性
• crontab无法编辑保存，修改定时任务直接报错重命名失败
• 系统临时目录、SSH密钥被加锁保护，防止后门被清理
• curl/wget等系统下载工具被恶意改名替换，劫持网络下载行为
• 自动卸载阿里云安骑士、关闭防火墙与SELinux，销毁系统安全防线

二、常规修复全面失效

最初尝试常规权限修复、定时任务清理，全部被黑客限制拦截，关键操作报错如下：

[root@alidb var]# chmod -R 755 spool/
chmod: changing permissions of ‘spool/cron’: Operation not permitted
chmod: changing permissions of ‘spool/cron/root’: Operation not permitted
# 尝试直接解除文件锁定
[root@alidb var]# chattr -i /var/spool/cron
-bash: /usr/bin/chattr: Permission denied
# 编辑定时任务清理木马，保存失败
[root@alidb var]# crontab -e
crontab: error renaming /var/spool/cron/
#tmp
.XXXX to /var/spool/cron/root
rename: Operation not permitted

通过lsattr核查文件属性，发现核心定时任务文件被添加ia双重锁定属性：

• i：不可修改、不可删除、不可重命名
• a：仅允许追加写入，禁止覆盖修改

[root@alidb var]# lsattr /var/spool/cron/root
----ia-------e-- /var/spool/cron/root

这也是所有权限修改、文件删除、定时任务清理全部失效的核心原因。

三、逐层手动完整修复

1. 修复chattr命令执行权限

黑客恶意将chattr设置为只读权限，阻断解锁操作，首先恢复命令执行权限：

# 查看当前chattr权限
ll -h /usr/bin/chattr
# 赋予执行权限
chmod 755 /usr/bin/chattr
chmod 755 /bin/chattr

2. 批量解除Crontab目录锁定属性

递归清除i、a特殊保护属性，解除文件防删、防改限制：

chattr -R -i -a /var/spool/cron

3. 查看并清理恶意定时任务

# 查看植入的恶意计划任务
crontab -l
# 进入编辑模式，删除全部恶意定时规则
crontab -e
# 清理crontab临时残留文件
rm -rf /tmp/crontab.*

本次入侵植入恶意任务：

*/50 * * * * sh /etc/kworker >/dev/null 2>&1

每50分钟执行一次木马守护脚本。

4. 恢复系统默认目录权限与属主

# 重置cron目录标准权限
chmod -R 755 /var/spool/cron
# 还原属主为root
chown -R root:root /var/spool/cron

5. 最终修复验证

重新编辑、查看定时任务无报错，权限修改正常，锁定属性彻底清除，服务器基础权限恢复正常，修复完成。

另外，authorized_keys文件也用同上的方式进行修复。

四、黑客恶意守护脚本深度拆解

黑客植入持久化守护脚本，一旦服务器重启或被手动清理，会自动还原后门、加固权限、破坏安全防护。本次完整脚本及危害解析如下：

脚本核心危害总结如下：

• 权限自锁：锁定临时目录、SSH密钥，防止后门被删除
• 安全阉割：关闭防火墙、SELinux、系统监控，卸载云安全防护
• 命令劫持：替换curl/wget，后续可恶意下载病毒、挖矿程序
• 痕迹清除：清空系统日志、缓存，规避溯源排查
• 云防护针对性破坏：精准识别阿里云服务器，强制卸载安骑士

复盘本次安全事件，漏洞根源全部来自日常运维疏忽：

• 数据库端口裸奔：MySQL 3306端口公网全开，未配置IP白名单
• 弱密码漏洞：MySQL root账号使用简单密码，被暴力破解直接提权
• 防护工具被忽视：阿里云安骑士、云防火墙未正常启用，或被恶意卸载
• 系统权限放任：服务器高危目录、定时任务无定期巡检
• 长期未补丁：系统、MySQL版本长期未更新，存在已知提权漏洞

因为涉及修改的内容较多，因此对应的写了个脚本修复，过程如下：

五、总结

MySQL作为核心业务数据载体，一旦服务器被入侵，不仅会遭遇挖矿算力占用、服务器卡顿、数据泄露，还会被植入多层持久化后门，反复感染、极难彻底清除。

本次入侵案例可以看出，黑客攻击已经高度精细化：针对性阉割云厂商防护、系统命令劫持、文件属性锁定、定时任务守护，大幅提升运维清理难度。

对于所有DBA和运维人员而言，最小权限、端口收敛、防护加固、定期巡检，永远是抵御服务器入侵的第一道防线。不要抱有“不会被盯上”的侥幸心理，裸奔上线的服务器，被入侵只是时间问题。需要对应修复脚本的，请联系我获取。