核查服务器是否被植入恶意脚本，最直接的办法是同时检查文件系统、进程、网络连接和日志四个维度的异常，而不是只依赖某一种安全软件。
怎么快速判断服务器是否被植入恶意脚本
服务器被植入恶意脚本后，通常不会自己跳出来承认，你需要主动去看一些平时不关注的地方，下面这几个动作,可以在10分钟内完成第一轮筛查。
检查最近被修改过的文件
恶意脚本要运行，必须先落盘,在Linux服务器上执行：
find / -type f -mtime -3 2>/dev/null | grep -v -E '(/proc|/sys|/dev)'
这条命令找出三天内被修改的所有文件,重点关注：
/tmp、/var/tmp、/dev/shm目录下是否有可执行文件/etc/cron.d/、/var/spool/cron/里是否有新生成的计划任务- 网站根目录下是否有陌生的
.php、.jsp、.aspx文件，尤其是名字像是随机字符串的那种
如果网站用的是开源CMS，可以用原始安装包里的文件哈希逐一比对，例如WordPress程序，下载同版本官方包，执行find /var/www -type f -exec md5sum {} ;后与官方校验值对比，行业内普遍认为，哈希比对是识别文件被篡改的最可靠手段之一。
看进程和网络连接
执行ps -ef，先看有没有CPU占用率异常高的进程，很多挖矿脚本会用尽CPU，但也会伪装成系统服务，接着用netstat -antp查看外联地址，对于主动连接到海外IP（尤其是不常见端口如4444、6667、8080）的进程要格外留意。
如果进程名很怪，比如一串乱码，或者路径在/tmp下，基本可以判定有问题，可以用lsof -p 进程号查看进程打开的文件,确认它调用的是哪个脚本。
服务器被植入恶意脚本后常见的表现是什么
恶意脚本的目标不同，表现也不同，挖矿脚本会让服务器变卡，数据窃取脚本会让网络流量异常，而勒索脚本往往让文件加密无法访问，以下特征出现越多,中招概率越大。
| 表现 | 说明 |
|---|---|
| CPU持续满载 | 无业务高峰时段CPU也跑满，多半有挖矿进程 |
| 带宽耗尽 | 外发流量远大于入站流量，可能在向外传输数据 |
| 文件被篡改 | 网页被挂马、源文件被加入恶意跳转代码 |
| 账户异常 | 出现陌生用户，或者root密码被改 |
| 日志缺失 | 某个时间段的日志被清空，说明攻击者有清理行为 |
这些表现你可以在云控制台的监控页面直观看到，如果尚未使用云监控，也可以手动运行top和ifstat观察几分钟。
Linux服务器恶意脚本排查命令有哪些
命令行是核查恶意脚本痕迹的主战场,以下命令组合覆盖了绝大多数场景。
文件层面的排查命令
find / -newer /etc/passwd -type f找比系统密码文件更近修改的文件stat查看单个文件的创建、修改、访问时间，恶意脚本通常修改时间和访问时间挨得很近cat /etc/crontab和crontab -l检查计划任务ls -la /etc/init.d/ /etc/rc.d/检查开机自启动项grep -r "eval|base64_decode|gzinflate" /var/www/html/在网页代码中搜索常见危险函数
进程与网络排查命令
top -c按CPU排序显示完整命令行ps auxf以树状格式显示进程，便于发现被劫持的父进程netstat -antpo显示进程PID以及所有TCP/UDP连接ss -tunap是netstat的现代替代品，速度更快lsof +L1显示已被删除但还在运行的进程，攻击者常用unlink隐藏脚本
执行时记得使用root权限，否则很多信息看不到，如果你管理的服务器数量多，建议把上述命令写成脚本一次性执行，脚本内不保存密码,只输出异常项。
如何区分正常脚本与恶意脚本
发现一个可疑脚本后，别急着删，先看清楚它是干什么的,再决定处理方式。
从调用关系判断
使用strace -f -e trace=file,process,network 命令跟踪脚本运行时行为，正常系统管理脚本会访问配置文件和日志，极少主动发起外部连接,恶意脚本则常有以下行为：
- 尝试连接远程IP
- 创建反弹shell
- 修改hosts文件指向钓鱼域名
- 侦察内网其他主机
判断
打开脚本文件,重点看有没有以下特征：
- 整行代码被
base64_encode包裹，结尾带eval - 使用
chr()、hex等函数拼接字符串，人为增加混淆 - 包含定时器逻辑，比如
sleep加循环，用于控制执行频率 - 存在你从未见过的小写字母域名，或者IP地址裸写
如果代码行数极少但对系统影响巨大，大概率是恶意脚本，相比之下,正常脚本往往有完整的注释和错误处理。
清理恶意脚本后如何防止再次被植入
查出痕迹只是第一步，把漏洞补上才是关键，很多服务器被反复植入脚本,就是因为只删了文件没修门。
清理后的紧急操作清单
- 立刻修改所有账户密码，包括root、数据库、FTP、API密钥
- 删除新增的SSH公钥，检查
~/.ssh/authorized_keys - 审查所有计划任务并删除异常项
- 更新Web中间件和CMS到最新版本
- 启用云平台的安全组，只放行业务必须的端口
这五步做完，再考虑业务恢复，如果服务器上有重要数据，建议先做快照再操作,避免误删。
预防植入的基线设置
行业共识认为，定期检查和限制执行权限是有效对抗恶意脚本的底线策略
,具体做法：
- 为网站目录设置
chattr +i不可变属性，防止文件被篡改（注意配置目录要排除） - 使用
apparmor或SELinux限制进程可访问的路径 - 部署免费的文件完整性监控工具，如AIDE，每月生成一次哈希库
- 必要时请专业团队做一次安全评估，服务器安全检测价格按次计算通常在千元级别，但比被勒索后恢复成本低得多
如果你在本地机房维护服务器，也可以参照上述方法，不过还要额外关注物理接入控制,防止有人直接插U盘植入后门。
服务器恶意脚本核查常见问题
如何判断恶意脚本是否已经删除干净？
删除脚本后，把find -mtime的检查范围扩大到7天，同时连续观察24小时网络连接，重点确认没有新的外联进程发起，并且计划任务里不再出现之前删除的条目，若在一次完整重启后依然正常,基本可以放心。
网站被植入恶意脚本，日志文件在哪里看？
对Nginx而言，访问日志在/var/log/nginx/access.log，错误日志在/var/log/nginx/error.log；Apache日志在/var/log/apache2/目录下，查看最近几小时日志中带有eval、base64或者指向可疑IP的请求,就能定位攻击入口。
服务器安全检测多久做一次比较合适？
未出现过异常的系统，建议每月做一次文件哈希比对和日志审计，如果经历过入侵，则前两个月每周查一次，之后恢复正常月度巡检，业务量大的服务器可以借助云监控自动告警,但人工检查仍是不可替代的环节。
核查恶意脚本不是一次性的活，它更像是给服务器做定期体检，记住最核心的思路：文件和进程没有可疑变化，网络连接没有异常目的地，日志没有无故缺失，系统就是相对干净的。 把这套检查流程固化下来,比你安装再多的安全软件都管用。