看到《坏兔之歌》这个标题第一反应可能是一个循环洗脑的网络神曲但如果把“坏兔”这两个字放到网络安全语境里整句话就变成了一个非常值得重视的提醒快检查你的服务器、你的 Linux 主机、你的个人电脑里是不是已经混进了一只不该出现的“坏兔”。这里的“坏兔”并不是某一个具体病毒的正式名称更不是某个安全厂商的威胁代号你可以把它理解成一个比喻凡是你不认识的可执行文件、自动运行的定时任务、悄悄对外连接的进程、突然多出来的 SSH 公钥、被篡改的系统账号都算得上“坏兔”留下的痕迹。本文以 Linux 服务器为例整理一套从登录记录、账号权限、进程端口、文件计划任务到系统日志的完整自查流程。无论你是运维人员、后端开发还是自己折腾云服务器的独立开发者都可以照着这篇文章把主机从头到尾检查一遍。学完之后你至少能回答三个问题服务器有没有被登录过有没有不明进程在跑有没有被留下后门或计划任务1. 背景为什么要做“坏兔”自查1.1 什么是“坏兔”风险很多开发者对安全事件的第一反应是我的服务器既没有重要数据也没有高并发流量黑客应该看不上。但现实恰恰相反攻击者并不会只挑大公司下手。大量自动化扫描脚本会在全网范围内不断探测 IP 的 22 端口、3306 端口、常见 Web 服务端口一旦发现弱口令或者未修补的漏洞就会在几分钟内完成入侵。入侵后做的事情也很套路植入挖矿程序、添加后门账号、篡改定时任务、挂上 WebShell甚至把服务器变成攻击跳板。“坏兔”这个词在本文中是一个广义的风险代称。安全圈确实出现过以 Bad Rabbit 命名的勒索软件家族但本文并不打算讨论某一个具体的恶意软件样本而是想提醒你建立“不确定就排查”的思维。很多时候服务器性能突然下降、带宽被占满、CPU 长时间 100%不一定是业务高峰也可能是已经有异常程序入驻了。与其等到业务受影响再慌乱处理不如提前学会一套系统化的自查方法。1.2 哪些场景最容易混进“坏兔”结合日常运维经验下面这几类场景最容易出现问题应该作为重点检查对象。第一类是暴露了公网登录入口的服务器。比如 SSH 端口直接暴露在公网且使用弱密码攻击者可以借助暴力破解工具反复尝试一旦成功就获得系统权限。这类攻击在云服务器上非常频繁查看登录失败日志往往能看到大量陌生 IP。第二类是运行开源应用的服务器。很多开源项目安装文档为了省事会让用户以 root 权限运行或者保留默认的管理员密码。攻击者会利用全网指纹扫描快速锁定这类目标再通过已知漏洞或默认凭据进入系统。第三类是长期不更新、不维护的“僵尸服务器”。系统组件和依赖库存在已知漏洞但运维人员担心升级会影响业务于是一拖再拖。漏洞被公开之后对应的利用代码很快会被武器化成为批量扫描的入口。第四类是个人开发机和临时测试主机。很多人认为测试环境不重要密码设置简单、不开启防火墙、也不关注日志。实际上测试环境同样有公网 IP 的话也会成为攻击目标而且一旦被入侵还可能成为内网横向移动的跳板。1.3 自查与应急响应的区别本文介绍的方法属于“主机安全自查”也就是在系统尚未出现明确中毒症状、或者刚刚出现可疑症状时做的信息收集和判断。它和专业的应急响应服务不一样应急响应通常需要由安全团队在已经确认事件的情况下进行溯源、隔离、取证和清除涉及更复杂的流程和工具。对大多数开发者和中小团队来说日常做好自查能尽早发现问题把损失控制在最小范围。如果确认系统已经被入侵尤其是发现勒索病毒提示或关键数据被加密建议立刻断开网络并联系专业安全人员处理不要自己盲目删除文件因为删除操作很可能破坏电子证据。2. 环境准备与安全须知2.1 本文适用的系统环境本文涉及的排查命令基本以 Linux 系统为例常见发行版包括 CentOS、Ubuntu、Debian、Rocky Linux、Alibaba Cloud Linux 等。不同发行版的软件包管理器和部分日志路径会有差异但核心排查思路是通用的。为了便于阅读这里约定如下环境操作系统Linux内核版本建议在 3.10 以上示例以 CentOS 7/8 和 Ubuntu 20.04/22.04 为主。登录方式通过 SSH 远程登录服务器具备 root 权限或拥有 sudo 权限。工具要求无需额外安装复杂工具系统自带的 shell、awk、grep、find、ps、ss、last 等命令即可完成大部分检查。业务要求排查期间不建议停止正在运行的服务所有只读命令不会影响业务进程。如果你使用的是 Windows Server或者容器环境如 Docker/Kubernetes部分命令和路径需要另行调整建议先分清排查对象是宿主机、容器还是云平台控制台。2.2 权限、授权与操作边界在执行任何安全自查命令之前请先明确两个原则一是你要排查的系统必须是你自己拥有或者已经获得合法授权的系统二是所有命令尽量以只读方式运行不要轻易修改、删除或隔离文件。很多日志文件只有 root 用户才能读取比如 Ubuntu 系统的/var/log/auth.log默认权限为 640普通用户无法直接访问。因此推荐使用 root 登录或者在每条命令前加sudo。如果公司有明确的安全规范要求通过跳板机或堡垒机登录务必遵守内部流程不要私自绕过。涉及到可疑进程的结束、可疑用户删除、文件隔离等操作需要经过确认后再执行并且最好提前对系统做快照或备份。2.3 自查前的快照与备份在开始排查之前如果云厂商控制台支持快照功能建议先对整个系统盘做一次快照。快照成本低、操作快一旦排查过程中误判并删除了业务关键文件可以立即回滚。对于数据库服务器还要确认数据库本身有备份机制避免排查时因为重启服务或人工干预导致数据异常。在物理服务器或者本地虚拟机环境中没有云快照功能的话可以先把一些关键配置文件复制到安全目录例如/etc/passwd、/etc/shadow、/etc/ssh/sshd_config、/etc/crontab、/var/spool/cron/下的文件。这样即使后续需要恢复也有参照资料。实际操作中我更推荐把每次排查的命令输出重定向到文件保存到本机或对象存储方便后续对比。比如执行last -n 50 /tmp/login_history.txt既能保留证据又不会污染终端内容。3. 第一梯队自查账号与登录审计3.1 查看成功登录和失败登录记录排查服务器是否被入侵第一步不是去看进程而是先看“谁来过”。Linux 会把用户登录信息记录在日志中通过last、lastb、who、w等命令可以快速还原登录痕迹。先查看最近的成功登录记录# 查看最近 20 条成功登录记录 last -n 20输出中会显示登录用户名、登录终端、来源 IP、登录时间。如果你是个人服务器可以对照自己的常用 IP 和登录时间如果出现凌晨时段、陌生 IP 的登录记录就需要高度警惕。还要注意查看终端类型如果显示类似:0的本地终端记录而服务器明明在机房或云端也属于异常信号。再看失败登录记录。失败记录通常保存在/var/log/btmp中需要使用lastb查看# 查看最近 20 条失败登录记录需要 root 权限 sudo lastb -n 20如果失败记录数量巨大、来源 IP 分散说明服务器正在被暴力破解。不过lastb直接输出的可读性一般更好的方式是统计失败次数最多的 IP# 统计失败登录次数最多的前 20 个 IP sudo lastb | awk {print $3} | sort | uniq -c | sort -nr | head -20这条命令的含义是把lastb输出的每一行取第三列也就是 IP 地址然后排序、去重、统计次数最后按次数倒序显示。除了登录日志/var/log/auth.log或/var/log/secure中也可以看到更详细的认证过程包括是否使用了不存在的用户名、是否通过 SSH 登录成功。建议把可疑登录时间点与业务发布记录做比对确认是否存在合法操作。3.2 排查系统用户与 sudo 权限攻击者获得权限后经常会创建一个新用户并把该用户加入 sudo 组方便后续随时登录。因此检查系统当前存在的账号非常关键。# 查看 /etc/passwd 中所有用户的基本信息 awk -F: {print $1, $3, $6, $7} /etc/passwd这条命令会输出用户名、UID、家目录和登录 Shell。重点关注UID 为 0 的用户因为 UID 0 表示超级用户权限正常情况下应该只有 root。登录 Shell 不是/sbin/nologin或/bin/false的普通账号如果某些系统账号拥有可用 Shell通常是异常。家目录不在/home下但拥有登录 Shell 的账号。查看 UID 为 0 用户的命令可以单独执行# 查找 UID 为 0 的用户 awk -F: $30 {print $1} /etc/passwd我们还可以查看所有可以登录的用户# 查找可以正常登录系统的用户 grep -vE nologin|false /etc/passwd然后检查 sudo 权限。sudo 权限信息在/etc/sudoers和/etc/sudoers.d/目录中建议用visudo -c先检查语法再查看具体内容# 检查 sudoers 语法 sudo visudo -c # 查看 sudoers 中非注释、非空行的内容 sudo grep -vE ^#|^$ /etc/sudoers /etc/sudoers.d/* 2/dev/null如果某个普通用户出现在 sudoers 中且拥有类似ALL(ALL) NOPASSWD:ALL的免密权限需要确认这个用户是否由你自己创建。业务越简单sudo 用户应该越少。3.3 检查 SSH 信任关系与公钥SSH 公钥登录是比密码登录更安全的认证方式但也经常被攻击者利用。当攻击者入侵成功后往往会把自己的公钥写入/root/.ssh/authorized_keys或某个用户的authorized_keys中这样即使你修改了密码对方依然可以通过私钥免密登录。这就是典型的“后门钥匙”。检查所有 authorized_keys 文件# 查找系统中所有 authorized_keys 文件并显示内容 sudo find /root /home -path */.ssh/authorized_keys -type f -exec sh -c echo {} ; cat {} \;重点是确认文件中是否存在你不认识的公钥。公钥内容通常以ssh-rsa、ssh-ed25519、ecdsa-sha2-nistp256等开头如果你发现一条公钥注释部分不是自己的邮箱或主机名就很可疑。还可以对比一下每台服务器公钥数量正常情况下 root 用户的 authorized_keys 应该只有有限几条。除了 authorized_keys还要检查用户目录下是否有陌生的私钥文件# 查找 /root 和 /home 下的私钥文件 sudo find /root /home -type f \( -name id_rsa -o -name id_ecdsa -o -name id_ed25519 \) 2/dev/null如果服务器上从未配置过密钥登录却出现了这些文件说明可能是攻击者留下的工具也可能是其他管理员生成的备份需要人工确认。4. 第二梯队自查进程、端口与网络连接4.1 定位异常高占用进程系统卡顿、CPU 持续跑满、内存耗尽是服务器异常的典型症状。登录服务器后先通过top或htop查看资源占用排行。htop如果没有安装先用自带的top就可以。# 动态查看进程资源占用 top在 top 界面中按P键可以按 CPU 占用排序按M键可以按内存占用排序。重点关注排在前面的进程名称。常见异常包括进程名是随机字符串例如kgxjed、xmrig、kdevtmpfsi大概率是挖矿木马。进程名伪装成系统命令例如/tmp/kthreadd或/usr/bin/sshd出现在奇怪目录。进程占用 CPU 达到 100% 到 400%但你的业务进程名称里找不到对应项。按 CPU 使用率排序并显示进程详情可以使用下面的命令组合# 显示当前 CPU 占用最高的前 10 个进程 ps -eo pid,ppid,user,%cpu,%mem,cmd --sort-%cpu | head -20这里-e表示所有进程-o指定输出列--sort-%cpu表示按 CPU 倒序排序。执行后要特别留意 COMMAND 列中的可执行文件路径比如进程运行在/tmp、/dev/shm、/var/tmp等异常目录基本可以判断是可疑进程。4.2 检查监听端口与外部连接恶意程序为了保持控制或向外传输数据通常会开启一个新的端口或者主动连接远端的 C2 服务器。通过检查端口监听状态和外联连接可以快速发现异常通信。查看当前所有的 TCP 监听端口# 查看监听端口和对应进程 sudo ss -lntp-l表示只看监听-n以数字形式显示地址和端口-t只看 TCP-p显示对应的进程信息。对照你的业务端口清单如果出现未知端口处于 LISTEN 状态就需要进一步确认。查看所有主动外联的连接# 查看 TCP 连接包含进程信息 sudo ss -antp这个输出会很大可以配合 grep 筛选常见的远程端口筛选已经建立的连接# 只看已建立的 TCP 连接 sudo ss -antp | grep ESTAB观察外部地址列。如果某条连接的目标是陌生 IP而且进程路径又来自/tmp基本可以断定存在后门通信。云服务器还可以通过云控制台的“安全组”和“流量监控”功能辅助判断是否存在异常外联。如果系统没有ss命令可以使用netstatsudo netstat -antp不同发行版安装方式不同CentOS 可以执行yum install net-toolsUbuntu 可以执行apt install net-tools。4.3 分析可疑进程的启动链路进程本身不可怕可怕的是你不知道它是由谁启动的、从哪个文件启动的。定位到可疑进程 PID 之后可以查看它的完整启动命令、父进程和可执行文件路径。# 假设可疑进程 PID 为 12345查看详细进程信息 ps -fp 12345 # 查看该进程的父进程 ps -fp $(ps -o ppid -p 12345)查看进程打开的网络连接和文件可以使用lsof# 查看指定 PID 打开的端口和连接 sudo lsof -p 12345 # 查看该进程打开的所有文件 sudo ls -l /proc/12345/cwd /proc/12345/exe/proc/12345/exe是指向可执行文件真实路径的符号链接如果 exe 文件已经被删除但进程依然在运行输出末尾会显示(deleted)这在木马场景中非常常见因为攻击者执行完恶意程序后会把源文件删除试图规避排查。如果确认某个进程是恶意的建议先记录 PID、父进程、启动命令和网络连接信息然后到云控制台对该服务器做快照。之后可以先用kill终止进程但要注意很多挖矿木马有守护进程杀掉主进程后很快会被拉起所以更稳妥的做法是先排查定时任务和启动项再统一清理。5. 第三梯队自查文件、定时任务与日志5.1 找出近期新增或修改的可疑文件文件层面的排查重点是“新文件”。攻击者完成入侵后无论投放木马、脚本还是 WebShell都会在文件系统中留下痕迹。找出最近几天内被修改的文件往往能直接发现异常。# 查找 /tmp、/var/tmp、/dev/shm 等临时目录下最近 3 天内新增的文件 sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls 2/dev/null/dev/shm是 Linux 的共享内存目录普通服务很少使用但很多恶意程序会利用它存放可执行文件因为它默认不清理且可执行。临时目录出现可疑的脚本或二进制文件是很强的异常信号。查找系统目录下最近被修改的可执行文件# 查找 /usr/bin 和 /usr/sbin 下最近 3 天被修改的文件 sudo find /usr/bin /usr/sbin /bin /sbin -type f -mtime -3 -ls 2/dev/null正常情况系统命令文件几乎不会被修改如果出现新文件需要逐个确认。查找 web 目录下新增的脚本文件会在后面单独说明。文件排查时要注意-mtime是按修改时间过滤而不是文件创建时间攻击者有时候会使用touch -r命令把文件时间伪装成旧时间所以这个指标只能作为参考。5.2 检查计划任务与自启动项计划任务是被入侵后最常被利用的持久化手段。攻击者会把恶意脚本写入 crontab让它每隔几分钟重新下载木马或执行挖矿程序这也是为什么单独 kill 进程治标不治本的原因。检查当前用户和 root 的计划任务# 查看当前用户的 crontab crontab -l # 查看 root 的 crontab sudo crontab -l同时查看系统级计划任务# 列出 /etc/cron.d 目录下的任务文件 ls -la /etc/cron.d/ cat /etc/cron.d/* 2/dev/null # 查看 /etc/crontab cat /etc/crontab还要检查 cron 的日常任务目录# 查看每小时的定时任务目录 ls -la /etc/cron.hourly/ ls -la /etc/cron.daily/ ls -la /etc/cron.weekly/正常的计划任务往往有明确的命令路径和注释如果看到类似下面的内容一定要警惕*/5 * * * * /tmp/x.sh /dev/null 21除了 crontabsystemd timer 也常被用来做计划任务。检查当前系统所有 timer# 查看 systemd 定时器列表 systemctl list-timers --all还可以检查是否有开机启动的可疑服务# 查看所有 enabled 状态的服务 systemctl list-unit-files --typeservice | grep enabled重点排查名称随机、描述不清的自启动服务。攻击者会将自己创建的 service 设置为开机启动这样即使服务器重启恶意进程也会自动恢复运行。5.3 排查 Web 目录中的 WebShell如果服务器运行着 NGINX、Apache、Tomcat 或 PHP 环境还要排查 WebShell。WebShell 本质上是一个放在 Web 目录中的脚本文件攻击者通过 Web 漏洞上传后就可以在浏览器中调用它执行系统命令。WebShell 排查并没有绝对可靠的方式最基础的手段是找出最近新增或修改的脚本文件。假设网站根目录是/var/www/html# 查找最近 7 天新增的 PHP 文件 sudo find /var/www/html -type f -name *.php -mtime -7 -ls 2/dev/null如果业务使用了 Java可以检查 jsp 文件sudo find /var/www -type f \( -name *.jsp -o -name *.jspx \) -mtime -7 -ls 2/dev/null不过更有效的做法是下载云厂商的 WebShell 检测工具或者使用开源工具如 ClamAV、YARA 规则进行扫描。人工查看时重点查看脚本中是否有执行系统命令函数例如 PHP 中的eval、system、exec、assert、base64_decode一旦出现务必认真审查。5.4 分析系统日志中的异常信号系统日志是最容易被忽略但最有价值的数据源。Linux 发行版日志路径略有差异CentOS/RHEL 系统的认证日志是/var/log/secureUbuntu/Debian 系统的认证日志是/var/log/auth.log。查看是否有大量 SSH 暴力破解尝试# Ubuntu/Debian sudo grep Failed password /var/log/auth.log | tail -50 # CentOS/RHEL sudo grep Failed password /var/log/secure | tail -50统计破解来源 IP 排名sudo grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -20在 auth.log 中每行格式通常形如Jan 12 03:22:31 host sshd[12345]: Failed password for root from 203.0.113.10 port 54321 ssh2字段位置在不同发行版中可能不同所以$(NF-3)不一定准确更稳妥的做法是用grep提取 IP 之后手工观察或者直接借助grep -oE正则提取 IPsudo grep Failed password /var/log/auth.log | grep -oE ([0-9]{1,3}\.){3}[0-9]{1,3} | sort | uniq -c | sort -nr | head -20除了认证日志还可以查看系统消息日志中是否有异常的服务启动记录。日志被清空本身也是一个严重信号如果/var/log/auth.log或/var/log/secure文件不存在、内容为空、或者最近记录时间异常说明攻击者可能清理过痕迹。6. 一分钟自查脚本一键收集关键信息6.1 脚本内容为了减少人工执行多条命令的遗漏我把上面介绍的检查项整理成一个只读自查脚本。脚本不会修改系统、不会删除文件、不会结束任何进程它只会把关键信息输出到终端并保存到日志文件方便你后续分析。#!/bin/bash # 文件路径/root/security_check.sh # 功能服务器入侵自查信息收集脚本 # 建议执行方式sudo bash /root/security_check.sh OUT/tmp/security_check_$(date %Y%m%d_%H%M%S).log echo 1. 系统基本信息 | tee -a $OUT uname -a | tee -a $OUT uptime | tee -a $OUT date | tee -a $OUT echo | tee -a $OUT echo 2. 当前登录用户 | tee -a $OUT who | tee -a $OUT w | tee -a $OUT echo | tee -a $OUT echo 3. 最近成功登录记录(前30条) | tee -a $OUT last -n 30 | tee -a $OUT echo | tee -a $OUT echo 4. 最近失败登录记录(前30条) | tee -a $OUT lastb -n 30 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 5. UID 为 0 的用户 | tee -a $OUT awk -F: $30 {print $1} /etc/passwd | tee -a $OUT echo | tee -a $OUT echo 6. 可以登录的普通用户 | tee -a $OUT grep -vE nologin|false /etc/passwd | tee -a $OUT echo | tee -a $OUT echo 7. SSH 授权公钥 | tee -a $OUT sudo find /root /home -path */.ssh/authorized_keys -type f -exec sh -c echo --- {} ---; cat {} \; 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 8. CPU 占用前 15 进程 | tee -a $OUT ps -eo pid,ppid,user,%cpu,%mem,comm --sort-%cpu | head -15 | tee -a $OUT echo | tee -a $OUT echo 9. 监听端口 | tee -a $OUT ss -lntp 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 10. 已建立的网络连接 | tee -a $OUT ss -antp 2/dev/null | grep ESTAB | tee -a $OUT echo | tee -a $OUT echo 11. 当前用户计划任务 | tee -a $OUT crontab -l 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 12. root 计划任务 | tee -a $OUT sudo crontab -l 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 13. 系统级计划任务 | tee -a $OUT cat /etc/crontab 2/dev/null | tee -a $OUT ls -la /etc/cron.d/ 2/dev/null | tee -a $OUT cat /etc/cron.d/* 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 14. systemd 定时器 | tee -a $OUT systemctl list-timers --all 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 15. 临时目录最近新增文件 | tee -a $OUT find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 16. 最近修改的系统命令文件 | tee -a $OUT find /usr/bin /usr/sbin /bin /sbin -type f -mtime -3 -ls 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 17. 认证日志最近 30 行 | tee -a $OUT if [ -f /var/log/secure ]; then tail -n 30 /var/log/secure | tee -a $OUT elif [ -f /var/log/auth.log ]; then tail -n 30 /var/log/auth.log | tee -a $OUT else echo 未找到 secure 或 auth.log 日志文件 | tee -a $OUT fi echo | tee -a $OUT echo 排查结果已输出到 $OUT6.2 脚本执行与输出解读将脚本上传到服务器后执行下面的命令sudo bash /root/security_check.sh脚本执行结束后终端会显示完整输出同时一份相同内容的日志会保存在/tmp目录下文件名包含当前时间。建议查看日志时不要只盯着某个模块看而是把所有输出当作一条完整线索链来分析。举个例子如果在第 9 项监听端口中看到陌生端口再到第 8 项进程列表中找对应 PID如果该进程的可执行文件路径又指向/tmp并且第 15 项临时目录中恰好有近期新增文件那么这整条链路就非常可疑了。反过来说只看到某一个指标异常不一定能下结论需要多项交叉验证。6.3 脚本的局限与补充这个脚本本质上只是信息收集工具它不能识别所有木马也不能自动判定某个文件是恶意的。脚本使用的大多是常见命令如果攻击者替换了系统命令比如ps、ss、find本身就存在异常那么获取的信息就不准确。遇到这种高级场景可以尝试使用 busybox 中自带的静态命令来辅助排查或者挂载系统盘到另一台安全的主机上进行离线分析。对于有 Docker 环境的服务器还需要补充检查 Docker 容器中的异常进程和容器挂载目录因为部分攻击者会利用容器逃逸或错误配置进入宿主机。7. 常见问题与排查参考下面整理了一些自查过程中常见的问题现象、可能的含义以及处理方向供大家在遇到具体情况时快速对照。问题现象可能含义处理建议lastb 显示大量陌生 IP 的失败登录服务器正被暴力破解 SSH 密码改用密钥登录、禁止 root 密码登录、配置 Fail2ban并检查是否存在破解成功记录系统出现 UID 为 0 的未知用户攻击者添加了超级权限后门账号记录用户信息后禁用或删除该账号排查 sudoers 和相关文件的创建时间authorized_keys 中出现未知公钥SSH 后门已经被植入立即从 authorized_keys 中删除未知公钥更换 SSH 密钥对并审视服务器上的所有账号CPU 占用极高但 top 中进程名随机大概率是挖矿木马不要只 kill 进程先检查计划任务和自启动脚本做快照后再清理ss 中发现未知监听端口后门程序或未知服务正在监听通过 PID 定位进程文件路径分析是否为业务进程确认后隔离处理临时目录出现可疑可执行文件恶意程序常驻痕迹查看文件创建时间、执行来源结合计划任务和启动项综合判断/etc/cron.d 下有陌生任务文件攻击者利用计划任务做持久化备份后查看任务内容确实可疑则删除并检查是否存在同类文件auth.log 或 secure 日志被清空攻击者可能清理过痕迹结合 last、shell history、文件时间等其他残留信息继续排查避免只依赖单一日志Web 目录出现时间异常的 PHP/JSP 文件可能被上传了 WebShell将可疑文件下载到本机用杀毒引擎扫描同时排查 Web 应用漏洞来源服务器未做任何操作但网络流量异常存在可疑外联或数据回传抓包分析连接目标结合进程和计划任务定位并处理每条问题背后都可能有多种原因不建议只看一个现象就确定结论。规范化排查的价值在于通过多个角度交叉验证减少误判。8. 服务器安全加固与日常预防8.1 SSH 与远程登录加固SSH 是服务器最常用的入口也是暴力破解的主要目标。加固 SSH 是成本最低、效果最明显的安全措施。第一把密码登录改成密钥登录。生成密钥后把公钥放到服务器/root/.ssh/authorized_keys中先用密钥登录验证可用再修改 SSH 配置禁用密码登录。不要在不确认密钥可用的情况下直接关闭密码认证否则会导致自己无法登录。修改配置文件/etc/ssh/sshd_config重点检查以下配置项PermitRootLogin prohibit-password PasswordAuthentication no PubkeyAuthentication yes修改完成后执行sudo sshd -t sudo systemctl restart sshdsshd -t是测试配置语法确认没有报错再重启服务。如果担心断连风险可以保持当前 SSH 会话打开新开一个终端测试登录成功后再关闭原会话。第二对于必须使用密码才能登录的账号尽量配置强密码策略建议密码长度不少于 16 位并包含随机字符。第三有条件的话把 SSH 默认端口 22 改为高位端口虽然不能防住专业定向攻击但可以显著减少自动化扫描噪音。第四使用 Fail2ban 等工具自动封禁多次尝试失败的 IP云服务器还可以通过安全组限制 SSH 的访问来源只允许公司出口 IP 访问。8.2 防火墙与最小暴露面服务器上不需要对公网开放的服务端口越少攻击面就越小。云服务器通常有安全组和系统内部防火墙两层控制建议两者配合使用。查看本机防火墙规则CentOS 系统以 firewalld 为主Ubuntu 系统以 ufw 为主。firewalld 常用命令# 查看 firewalld 状态 sudo systemctl status firewalld # 查看已放行的服务 sudo firewall-cmd --list-all # 移除不需要的服务例如移除 telnet sudo firewall-cmd --permanent --remove-servicetelnet sudo firewall-cmd --reloadufw 常用命令# 查看 ufw 状态 sudo ufw status verbose # 只允许特定 IP 访问 SSH sudo ufw allow from 你的办公IP to any port 22 proto tcp # 启用防火墙 sudo ufw enable使用防火墙的时候要小心不要把自己当前用来连接服务器的那条远程会话端口封禁掉。操作前可以在当前会话中先执行sudo ufw allow 22/tcp或sudo firewall-cmd --add-servicessh确认放行后再启用防火墙避免把自己锁在门外。除了关闭多余端口还要关注服务本身的监听地址。数据库服务如果只允许本机应用访问监听地址应该设置为127.0.0.1而不是0.0.0.0。Redis、MongoDB 这类容易被利用的服务尤其要注意不要在未设置密码的情况下直接监听公网。8.3 系统与应用更新系统漏洞和组件漏洞是入侵的重要入口。优先做好下面几件事操作系统安全补丁要及时更新云服务器可以选择“安全更新”策略尽量不在不做测试的情况下直接升级大版本。Web 中间件、数据库、PHP、Java 等运行时版本要保持在官方支持范围内不要使用已经停止维护的老版本。开源组件要关注已知漏洞比如常用的 Struts2、Fastjson、Log4j2、Spring 框架等历史上都出现过严重远程执行漏洞。弱口令是最大的隐患所有管理员密码、数据库密码、Redis 密码、后台密码都要避免使用默认值或常见词汇。更新命令在 CentOS 系统上是sudo yum update在 Ubuntu 系统上是sudo apt update sudo apt upgrade。生产环境建议先在测试环境验证兼容性再安排变更窗口执行。8.4 日志审计与监控安全自查不能只依靠出现问题时才看日志日常就要让日志形成习惯。至少要做到日志保留周期建议不少于 180 天有条件可以把auth.log、secure、nginx access log定时同步到远程日志服务器或对象存储。配置关键文件变更监控例如/etc/passwd、/etc/shadow、/etc/ssh/sshd_config、/etc/crontab的文件哈希可以使用aide这类工具建立文件完整性基线。把服务器 CPU、内存、带宽、磁盘 IO 指标的监控接入告警云厂商自带的监控服务也能实现类似能力。挖矿木马最典型的特征是 CPU 突然打满越早发现越好。定期登录云控制台查看安全中心或态势感知类的风险报告很多云平台已经内置了异常登录提醒、漏洞扫描等能力。8.5 备份与恢复演练备份是安全体系里的最后一道防线。即使系统被勒索病毒加密只要备份是完整的就可以在清理后恢复数据避免支付赎金。备份至少要满足 3-2-1 原则也就是数据保留 3 份、使用 2 种不同存储介质、其中 1 份存放在异地。不要只把备份放在同一台服务器的另一块磁盘上因为勒索病毒可能连备份一起加密。如果由于业务和数据量限制无法做到全面异地备份至少要确保核心数据库、配置文件、代码仓库有独立备份。备份是否可用要定期演练不能只看到备份成功就放心了真实环境里“备份文件损坏”或“恢复步骤缺失”的情况非常普遍。8.6 最小权限与日常运维习惯最后说一点长期容易被忽略的问题权限控制与运维习惯。对应到技术层面要明确区分 root 和普通账号。日常运维尽量使用普通账号加 sudo 的方式不要所有操作都直接以 root 执行。给开发、测试、运维人员分配账号时也应该按最小权限原则只给完成工作所必需的权限。离职人员账号要及时回收避免账号成为无人管理的僵尸入口。对应到操作习惯不要使用简单密码不要在多台服务器上重复使用同一套密码不要在代码仓库、聊天记录、项目文档中明文保存服务器密码和数据库密码。服务器安全不是一个一劳永逸的任务安全状态会随着新漏洞、新弱口令、新业务上线而动态变化。给自己建立固定的检查节奏例如每周看一眼登录日志、每月跑一次自查脚本、每次业务发布前检查端口和账号变化养成这些习惯比收藏任何一份“终极排查指南”都更管用。回头再看“快检查你家有没有进一只坏兔”这句话放在运维场景中确实是值得认真执行的提醒。排查的重点不是焦虑而是先确认账号没有异常、再确认进程端口没有异常、再确认定时任务和文件没有异常最后用备份和安全基线加固整个系统。把本文的脚本保存到服务器上下次听到类似的玩笑提醒花一分钟跑一遍总比某一天发现服务器被加密后再后悔要好。
Linux服务器安全自查指南：揪出“坏兔”后门与异常进程
看到《坏兔之歌》这个标题第一反应可能是一个循环洗脑的网络神曲但如果把“坏兔”这两个字放到网络安全语境里整句话就变成了一个非常值得重视的提醒快检查你的服务器、你的 Linux 主机、你的个人电脑里是不是已经混进了一只不该出现的“坏兔”。这里的“坏兔”并不是某一个具体病毒的正式名称更不是某个安全厂商的威胁代号你可以把它理解成一个比喻凡是你不认识的可执行文件、自动运行的定时任务、悄悄对外连接的进程、突然多出来的 SSH 公钥、被篡改的系统账号都算得上“坏兔”留下的痕迹。本文以 Linux 服务器为例整理一套从登录记录、账号权限、进程端口、文件计划任务到系统日志的完整自查流程。无论你是运维人员、后端开发还是自己折腾云服务器的独立开发者都可以照着这篇文章把主机从头到尾检查一遍。学完之后你至少能回答三个问题服务器有没有被登录过有没有不明进程在跑有没有被留下后门或计划任务1. 背景为什么要做“坏兔”自查1.1 什么是“坏兔”风险很多开发者对安全事件的第一反应是我的服务器既没有重要数据也没有高并发流量黑客应该看不上。但现实恰恰相反攻击者并不会只挑大公司下手。大量自动化扫描脚本会在全网范围内不断探测 IP 的 22 端口、3306 端口、常见 Web 服务端口一旦发现弱口令或者未修补的漏洞就会在几分钟内完成入侵。入侵后做的事情也很套路植入挖矿程序、添加后门账号、篡改定时任务、挂上 WebShell甚至把服务器变成攻击跳板。“坏兔”这个词在本文中是一个广义的风险代称。安全圈确实出现过以 Bad Rabbit 命名的勒索软件家族但本文并不打算讨论某一个具体的恶意软件样本而是想提醒你建立“不确定就排查”的思维。很多时候服务器性能突然下降、带宽被占满、CPU 长时间 100%不一定是业务高峰也可能是已经有异常程序入驻了。与其等到业务受影响再慌乱处理不如提前学会一套系统化的自查方法。1.2 哪些场景最容易混进“坏兔”结合日常运维经验下面这几类场景最容易出现问题应该作为重点检查对象。第一类是暴露了公网登录入口的服务器。比如 SSH 端口直接暴露在公网且使用弱密码攻击者可以借助暴力破解工具反复尝试一旦成功就获得系统权限。这类攻击在云服务器上非常频繁查看登录失败日志往往能看到大量陌生 IP。第二类是运行开源应用的服务器。很多开源项目安装文档为了省事会让用户以 root 权限运行或者保留默认的管理员密码。攻击者会利用全网指纹扫描快速锁定这类目标再通过已知漏洞或默认凭据进入系统。第三类是长期不更新、不维护的“僵尸服务器”。系统组件和依赖库存在已知漏洞但运维人员担心升级会影响业务于是一拖再拖。漏洞被公开之后对应的利用代码很快会被武器化成为批量扫描的入口。第四类是个人开发机和临时测试主机。很多人认为测试环境不重要密码设置简单、不开启防火墙、也不关注日志。实际上测试环境同样有公网 IP 的话也会成为攻击目标而且一旦被入侵还可能成为内网横向移动的跳板。1.3 自查与应急响应的区别本文介绍的方法属于“主机安全自查”也就是在系统尚未出现明确中毒症状、或者刚刚出现可疑症状时做的信息收集和判断。它和专业的应急响应服务不一样应急响应通常需要由安全团队在已经确认事件的情况下进行溯源、隔离、取证和清除涉及更复杂的流程和工具。对大多数开发者和中小团队来说日常做好自查能尽早发现问题把损失控制在最小范围。如果确认系统已经被入侵尤其是发现勒索病毒提示或关键数据被加密建议立刻断开网络并联系专业安全人员处理不要自己盲目删除文件因为删除操作很可能破坏电子证据。2. 环境准备与安全须知2.1 本文适用的系统环境本文涉及的排查命令基本以 Linux 系统为例常见发行版包括 CentOS、Ubuntu、Debian、Rocky Linux、Alibaba Cloud Linux 等。不同发行版的软件包管理器和部分日志路径会有差异但核心排查思路是通用的。为了便于阅读这里约定如下环境操作系统Linux内核版本建议在 3.10 以上示例以 CentOS 7/8 和 Ubuntu 20.04/22.04 为主。登录方式通过 SSH 远程登录服务器具备 root 权限或拥有 sudo 权限。工具要求无需额外安装复杂工具系统自带的 shell、awk、grep、find、ps、ss、last 等命令即可完成大部分检查。业务要求排查期间不建议停止正在运行的服务所有只读命令不会影响业务进程。如果你使用的是 Windows Server或者容器环境如 Docker/Kubernetes部分命令和路径需要另行调整建议先分清排查对象是宿主机、容器还是云平台控制台。2.2 权限、授权与操作边界在执行任何安全自查命令之前请先明确两个原则一是你要排查的系统必须是你自己拥有或者已经获得合法授权的系统二是所有命令尽量以只读方式运行不要轻易修改、删除或隔离文件。很多日志文件只有 root 用户才能读取比如 Ubuntu 系统的/var/log/auth.log默认权限为 640普通用户无法直接访问。因此推荐使用 root 登录或者在每条命令前加sudo。如果公司有明确的安全规范要求通过跳板机或堡垒机登录务必遵守内部流程不要私自绕过。涉及到可疑进程的结束、可疑用户删除、文件隔离等操作需要经过确认后再执行并且最好提前对系统做快照或备份。2.3 自查前的快照与备份在开始排查之前如果云厂商控制台支持快照功能建议先对整个系统盘做一次快照。快照成本低、操作快一旦排查过程中误判并删除了业务关键文件可以立即回滚。对于数据库服务器还要确认数据库本身有备份机制避免排查时因为重启服务或人工干预导致数据异常。在物理服务器或者本地虚拟机环境中没有云快照功能的话可以先把一些关键配置文件复制到安全目录例如/etc/passwd、/etc/shadow、/etc/ssh/sshd_config、/etc/crontab、/var/spool/cron/下的文件。这样即使后续需要恢复也有参照资料。实际操作中我更推荐把每次排查的命令输出重定向到文件保存到本机或对象存储方便后续对比。比如执行last -n 50 /tmp/login_history.txt既能保留证据又不会污染终端内容。3. 第一梯队自查账号与登录审计3.1 查看成功登录和失败登录记录排查服务器是否被入侵第一步不是去看进程而是先看“谁来过”。Linux 会把用户登录信息记录在日志中通过last、lastb、who、w等命令可以快速还原登录痕迹。先查看最近的成功登录记录# 查看最近 20 条成功登录记录 last -n 20输出中会显示登录用户名、登录终端、来源 IP、登录时间。如果你是个人服务器可以对照自己的常用 IP 和登录时间如果出现凌晨时段、陌生 IP 的登录记录就需要高度警惕。还要注意查看终端类型如果显示类似:0的本地终端记录而服务器明明在机房或云端也属于异常信号。再看失败登录记录。失败记录通常保存在/var/log/btmp中需要使用lastb查看# 查看最近 20 条失败登录记录需要 root 权限 sudo lastb -n 20如果失败记录数量巨大、来源 IP 分散说明服务器正在被暴力破解。不过lastb直接输出的可读性一般更好的方式是统计失败次数最多的 IP# 统计失败登录次数最多的前 20 个 IP sudo lastb | awk {print $3} | sort | uniq -c | sort -nr | head -20这条命令的含义是把lastb输出的每一行取第三列也就是 IP 地址然后排序、去重、统计次数最后按次数倒序显示。除了登录日志/var/log/auth.log或/var/log/secure中也可以看到更详细的认证过程包括是否使用了不存在的用户名、是否通过 SSH 登录成功。建议把可疑登录时间点与业务发布记录做比对确认是否存在合法操作。3.2 排查系统用户与 sudo 权限攻击者获得权限后经常会创建一个新用户并把该用户加入 sudo 组方便后续随时登录。因此检查系统当前存在的账号非常关键。# 查看 /etc/passwd 中所有用户的基本信息 awk -F: {print $1, $3, $6, $7} /etc/passwd这条命令会输出用户名、UID、家目录和登录 Shell。重点关注UID 为 0 的用户因为 UID 0 表示超级用户权限正常情况下应该只有 root。登录 Shell 不是/sbin/nologin或/bin/false的普通账号如果某些系统账号拥有可用 Shell通常是异常。家目录不在/home下但拥有登录 Shell 的账号。查看 UID 为 0 用户的命令可以单独执行# 查找 UID 为 0 的用户 awk -F: $30 {print $1} /etc/passwd我们还可以查看所有可以登录的用户# 查找可以正常登录系统的用户 grep -vE nologin|false /etc/passwd然后检查 sudo 权限。sudo 权限信息在/etc/sudoers和/etc/sudoers.d/目录中建议用visudo -c先检查语法再查看具体内容# 检查 sudoers 语法 sudo visudo -c # 查看 sudoers 中非注释、非空行的内容 sudo grep -vE ^#|^$ /etc/sudoers /etc/sudoers.d/* 2/dev/null如果某个普通用户出现在 sudoers 中且拥有类似ALL(ALL) NOPASSWD:ALL的免密权限需要确认这个用户是否由你自己创建。业务越简单sudo 用户应该越少。3.3 检查 SSH 信任关系与公钥SSH 公钥登录是比密码登录更安全的认证方式但也经常被攻击者利用。当攻击者入侵成功后往往会把自己的公钥写入/root/.ssh/authorized_keys或某个用户的authorized_keys中这样即使你修改了密码对方依然可以通过私钥免密登录。这就是典型的“后门钥匙”。检查所有 authorized_keys 文件# 查找系统中所有 authorized_keys 文件并显示内容 sudo find /root /home -path */.ssh/authorized_keys -type f -exec sh -c echo {} ; cat {} \;重点是确认文件中是否存在你不认识的公钥。公钥内容通常以ssh-rsa、ssh-ed25519、ecdsa-sha2-nistp256等开头如果你发现一条公钥注释部分不是自己的邮箱或主机名就很可疑。还可以对比一下每台服务器公钥数量正常情况下 root 用户的 authorized_keys 应该只有有限几条。除了 authorized_keys还要检查用户目录下是否有陌生的私钥文件# 查找 /root 和 /home 下的私钥文件 sudo find /root /home -type f \( -name id_rsa -o -name id_ecdsa -o -name id_ed25519 \) 2/dev/null如果服务器上从未配置过密钥登录却出现了这些文件说明可能是攻击者留下的工具也可能是其他管理员生成的备份需要人工确认。4. 第二梯队自查进程、端口与网络连接4.1 定位异常高占用进程系统卡顿、CPU 持续跑满、内存耗尽是服务器异常的典型症状。登录服务器后先通过top或htop查看资源占用排行。htop如果没有安装先用自带的top就可以。# 动态查看进程资源占用 top在 top 界面中按P键可以按 CPU 占用排序按M键可以按内存占用排序。重点关注排在前面的进程名称。常见异常包括进程名是随机字符串例如kgxjed、xmrig、kdevtmpfsi大概率是挖矿木马。进程名伪装成系统命令例如/tmp/kthreadd或/usr/bin/sshd出现在奇怪目录。进程占用 CPU 达到 100% 到 400%但你的业务进程名称里找不到对应项。按 CPU 使用率排序并显示进程详情可以使用下面的命令组合# 显示当前 CPU 占用最高的前 10 个进程 ps -eo pid,ppid,user,%cpu,%mem,cmd --sort-%cpu | head -20这里-e表示所有进程-o指定输出列--sort-%cpu表示按 CPU 倒序排序。执行后要特别留意 COMMAND 列中的可执行文件路径比如进程运行在/tmp、/dev/shm、/var/tmp等异常目录基本可以判断是可疑进程。4.2 检查监听端口与外部连接恶意程序为了保持控制或向外传输数据通常会开启一个新的端口或者主动连接远端的 C2 服务器。通过检查端口监听状态和外联连接可以快速发现异常通信。查看当前所有的 TCP 监听端口# 查看监听端口和对应进程 sudo ss -lntp-l表示只看监听-n以数字形式显示地址和端口-t只看 TCP-p显示对应的进程信息。对照你的业务端口清单如果出现未知端口处于 LISTEN 状态就需要进一步确认。查看所有主动外联的连接# 查看 TCP 连接包含进程信息 sudo ss -antp这个输出会很大可以配合 grep 筛选常见的远程端口筛选已经建立的连接# 只看已建立的 TCP 连接 sudo ss -antp | grep ESTAB观察外部地址列。如果某条连接的目标是陌生 IP而且进程路径又来自/tmp基本可以断定存在后门通信。云服务器还可以通过云控制台的“安全组”和“流量监控”功能辅助判断是否存在异常外联。如果系统没有ss命令可以使用netstatsudo netstat -antp不同发行版安装方式不同CentOS 可以执行yum install net-toolsUbuntu 可以执行apt install net-tools。4.3 分析可疑进程的启动链路进程本身不可怕可怕的是你不知道它是由谁启动的、从哪个文件启动的。定位到可疑进程 PID 之后可以查看它的完整启动命令、父进程和可执行文件路径。# 假设可疑进程 PID 为 12345查看详细进程信息 ps -fp 12345 # 查看该进程的父进程 ps -fp $(ps -o ppid -p 12345)查看进程打开的网络连接和文件可以使用lsof# 查看指定 PID 打开的端口和连接 sudo lsof -p 12345 # 查看该进程打开的所有文件 sudo ls -l /proc/12345/cwd /proc/12345/exe/proc/12345/exe是指向可执行文件真实路径的符号链接如果 exe 文件已经被删除但进程依然在运行输出末尾会显示(deleted)这在木马场景中非常常见因为攻击者执行完恶意程序后会把源文件删除试图规避排查。如果确认某个进程是恶意的建议先记录 PID、父进程、启动命令和网络连接信息然后到云控制台对该服务器做快照。之后可以先用kill终止进程但要注意很多挖矿木马有守护进程杀掉主进程后很快会被拉起所以更稳妥的做法是先排查定时任务和启动项再统一清理。5. 第三梯队自查文件、定时任务与日志5.1 找出近期新增或修改的可疑文件文件层面的排查重点是“新文件”。攻击者完成入侵后无论投放木马、脚本还是 WebShell都会在文件系统中留下痕迹。找出最近几天内被修改的文件往往能直接发现异常。# 查找 /tmp、/var/tmp、/dev/shm 等临时目录下最近 3 天内新增的文件 sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls 2/dev/null/dev/shm是 Linux 的共享内存目录普通服务很少使用但很多恶意程序会利用它存放可执行文件因为它默认不清理且可执行。临时目录出现可疑的脚本或二进制文件是很强的异常信号。查找系统目录下最近被修改的可执行文件# 查找 /usr/bin 和 /usr/sbin 下最近 3 天被修改的文件 sudo find /usr/bin /usr/sbin /bin /sbin -type f -mtime -3 -ls 2/dev/null正常情况系统命令文件几乎不会被修改如果出现新文件需要逐个确认。查找 web 目录下新增的脚本文件会在后面单独说明。文件排查时要注意-mtime是按修改时间过滤而不是文件创建时间攻击者有时候会使用touch -r命令把文件时间伪装成旧时间所以这个指标只能作为参考。5.2 检查计划任务与自启动项计划任务是被入侵后最常被利用的持久化手段。攻击者会把恶意脚本写入 crontab让它每隔几分钟重新下载木马或执行挖矿程序这也是为什么单独 kill 进程治标不治本的原因。检查当前用户和 root 的计划任务# 查看当前用户的 crontab crontab -l # 查看 root 的 crontab sudo crontab -l同时查看系统级计划任务# 列出 /etc/cron.d 目录下的任务文件 ls -la /etc/cron.d/ cat /etc/cron.d/* 2/dev/null # 查看 /etc/crontab cat /etc/crontab还要检查 cron 的日常任务目录# 查看每小时的定时任务目录 ls -la /etc/cron.hourly/ ls -la /etc/cron.daily/ ls -la /etc/cron.weekly/正常的计划任务往往有明确的命令路径和注释如果看到类似下面的内容一定要警惕*/5 * * * * /tmp/x.sh /dev/null 21除了 crontabsystemd timer 也常被用来做计划任务。检查当前系统所有 timer# 查看 systemd 定时器列表 systemctl list-timers --all还可以检查是否有开机启动的可疑服务# 查看所有 enabled 状态的服务 systemctl list-unit-files --typeservice | grep enabled重点排查名称随机、描述不清的自启动服务。攻击者会将自己创建的 service 设置为开机启动这样即使服务器重启恶意进程也会自动恢复运行。5.3 排查 Web 目录中的 WebShell如果服务器运行着 NGINX、Apache、Tomcat 或 PHP 环境还要排查 WebShell。WebShell 本质上是一个放在 Web 目录中的脚本文件攻击者通过 Web 漏洞上传后就可以在浏览器中调用它执行系统命令。WebShell 排查并没有绝对可靠的方式最基础的手段是找出最近新增或修改的脚本文件。假设网站根目录是/var/www/html# 查找最近 7 天新增的 PHP 文件 sudo find /var/www/html -type f -name *.php -mtime -7 -ls 2/dev/null如果业务使用了 Java可以检查 jsp 文件sudo find /var/www -type f \( -name *.jsp -o -name *.jspx \) -mtime -7 -ls 2/dev/null不过更有效的做法是下载云厂商的 WebShell 检测工具或者使用开源工具如 ClamAV、YARA 规则进行扫描。人工查看时重点查看脚本中是否有执行系统命令函数例如 PHP 中的eval、system、exec、assert、base64_decode一旦出现务必认真审查。5.4 分析系统日志中的异常信号系统日志是最容易被忽略但最有价值的数据源。Linux 发行版日志路径略有差异CentOS/RHEL 系统的认证日志是/var/log/secureUbuntu/Debian 系统的认证日志是/var/log/auth.log。查看是否有大量 SSH 暴力破解尝试# Ubuntu/Debian sudo grep Failed password /var/log/auth.log | tail -50 # CentOS/RHEL sudo grep Failed password /var/log/secure | tail -50统计破解来源 IP 排名sudo grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -20在 auth.log 中每行格式通常形如Jan 12 03:22:31 host sshd[12345]: Failed password for root from 203.0.113.10 port 54321 ssh2字段位置在不同发行版中可能不同所以$(NF-3)不一定准确更稳妥的做法是用grep提取 IP 之后手工观察或者直接借助grep -oE正则提取 IPsudo grep Failed password /var/log/auth.log | grep -oE ([0-9]{1,3}\.){3}[0-9]{1,3} | sort | uniq -c | sort -nr | head -20除了认证日志还可以查看系统消息日志中是否有异常的服务启动记录。日志被清空本身也是一个严重信号如果/var/log/auth.log或/var/log/secure文件不存在、内容为空、或者最近记录时间异常说明攻击者可能清理过痕迹。6. 一分钟自查脚本一键收集关键信息6.1 脚本内容为了减少人工执行多条命令的遗漏我把上面介绍的检查项整理成一个只读自查脚本。脚本不会修改系统、不会删除文件、不会结束任何进程它只会把关键信息输出到终端并保存到日志文件方便你后续分析。#!/bin/bash # 文件路径/root/security_check.sh # 功能服务器入侵自查信息收集脚本 # 建议执行方式sudo bash /root/security_check.sh OUT/tmp/security_check_$(date %Y%m%d_%H%M%S).log echo 1. 系统基本信息 | tee -a $OUT uname -a | tee -a $OUT uptime | tee -a $OUT date | tee -a $OUT echo | tee -a $OUT echo 2. 当前登录用户 | tee -a $OUT who | tee -a $OUT w | tee -a $OUT echo | tee -a $OUT echo 3. 最近成功登录记录(前30条) | tee -a $OUT last -n 30 | tee -a $OUT echo | tee -a $OUT echo 4. 最近失败登录记录(前30条) | tee -a $OUT lastb -n 30 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 5. UID 为 0 的用户 | tee -a $OUT awk -F: $30 {print $1} /etc/passwd | tee -a $OUT echo | tee -a $OUT echo 6. 可以登录的普通用户 | tee -a $OUT grep -vE nologin|false /etc/passwd | tee -a $OUT echo | tee -a $OUT echo 7. SSH 授权公钥 | tee -a $OUT sudo find /root /home -path */.ssh/authorized_keys -type f -exec sh -c echo --- {} ---; cat {} \; 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 8. CPU 占用前 15 进程 | tee -a $OUT ps -eo pid,ppid,user,%cpu,%mem,comm --sort-%cpu | head -15 | tee -a $OUT echo | tee -a $OUT echo 9. 监听端口 | tee -a $OUT ss -lntp 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 10. 已建立的网络连接 | tee -a $OUT ss -antp 2/dev/null | grep ESTAB | tee -a $OUT echo | tee -a $OUT echo 11. 当前用户计划任务 | tee -a $OUT crontab -l 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 12. root 计划任务 | tee -a $OUT sudo crontab -l 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 13. 系统级计划任务 | tee -a $OUT cat /etc/crontab 2/dev/null | tee -a $OUT ls -la /etc/cron.d/ 2/dev/null | tee -a $OUT cat /etc/cron.d/* 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 14. systemd 定时器 | tee -a $OUT systemctl list-timers --all 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 15. 临时目录最近新增文件 | tee -a $OUT find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 16. 最近修改的系统命令文件 | tee -a $OUT find /usr/bin /usr/sbin /bin /sbin -type f -mtime -3 -ls 2/dev/null | tee -a $OUT echo | tee -a $OUT echo 17. 认证日志最近 30 行 | tee -a $OUT if [ -f /var/log/secure ]; then tail -n 30 /var/log/secure | tee -a $OUT elif [ -f /var/log/auth.log ]; then tail -n 30 /var/log/auth.log | tee -a $OUT else echo 未找到 secure 或 auth.log 日志文件 | tee -a $OUT fi echo | tee -a $OUT echo 排查结果已输出到 $OUT6.2 脚本执行与输出解读将脚本上传到服务器后执行下面的命令sudo bash /root/security_check.sh脚本执行结束后终端会显示完整输出同时一份相同内容的日志会保存在/tmp目录下文件名包含当前时间。建议查看日志时不要只盯着某个模块看而是把所有输出当作一条完整线索链来分析。举个例子如果在第 9 项监听端口中看到陌生端口再到第 8 项进程列表中找对应 PID如果该进程的可执行文件路径又指向/tmp并且第 15 项临时目录中恰好有近期新增文件那么这整条链路就非常可疑了。反过来说只看到某一个指标异常不一定能下结论需要多项交叉验证。6.3 脚本的局限与补充这个脚本本质上只是信息收集工具它不能识别所有木马也不能自动判定某个文件是恶意的。脚本使用的大多是常见命令如果攻击者替换了系统命令比如ps、ss、find本身就存在异常那么获取的信息就不准确。遇到这种高级场景可以尝试使用 busybox 中自带的静态命令来辅助排查或者挂载系统盘到另一台安全的主机上进行离线分析。对于有 Docker 环境的服务器还需要补充检查 Docker 容器中的异常进程和容器挂载目录因为部分攻击者会利用容器逃逸或错误配置进入宿主机。7. 常见问题与排查参考下面整理了一些自查过程中常见的问题现象、可能的含义以及处理方向供大家在遇到具体情况时快速对照。问题现象可能含义处理建议lastb 显示大量陌生 IP 的失败登录服务器正被暴力破解 SSH 密码改用密钥登录、禁止 root 密码登录、配置 Fail2ban并检查是否存在破解成功记录系统出现 UID 为 0 的未知用户攻击者添加了超级权限后门账号记录用户信息后禁用或删除该账号排查 sudoers 和相关文件的创建时间authorized_keys 中出现未知公钥SSH 后门已经被植入立即从 authorized_keys 中删除未知公钥更换 SSH 密钥对并审视服务器上的所有账号CPU 占用极高但 top 中进程名随机大概率是挖矿木马不要只 kill 进程先检查计划任务和自启动脚本做快照后再清理ss 中发现未知监听端口后门程序或未知服务正在监听通过 PID 定位进程文件路径分析是否为业务进程确认后隔离处理临时目录出现可疑可执行文件恶意程序常驻痕迹查看文件创建时间、执行来源结合计划任务和启动项综合判断/etc/cron.d 下有陌生任务文件攻击者利用计划任务做持久化备份后查看任务内容确实可疑则删除并检查是否存在同类文件auth.log 或 secure 日志被清空攻击者可能清理过痕迹结合 last、shell history、文件时间等其他残留信息继续排查避免只依赖单一日志Web 目录出现时间异常的 PHP/JSP 文件可能被上传了 WebShell将可疑文件下载到本机用杀毒引擎扫描同时排查 Web 应用漏洞来源服务器未做任何操作但网络流量异常存在可疑外联或数据回传抓包分析连接目标结合进程和计划任务定位并处理每条问题背后都可能有多种原因不建议只看一个现象就确定结论。规范化排查的价值在于通过多个角度交叉验证减少误判。8. 服务器安全加固与日常预防8.1 SSH 与远程登录加固SSH 是服务器最常用的入口也是暴力破解的主要目标。加固 SSH 是成本最低、效果最明显的安全措施。第一把密码登录改成密钥登录。生成密钥后把公钥放到服务器/root/.ssh/authorized_keys中先用密钥登录验证可用再修改 SSH 配置禁用密码登录。不要在不确认密钥可用的情况下直接关闭密码认证否则会导致自己无法登录。修改配置文件/etc/ssh/sshd_config重点检查以下配置项PermitRootLogin prohibit-password PasswordAuthentication no PubkeyAuthentication yes修改完成后执行sudo sshd -t sudo systemctl restart sshdsshd -t是测试配置语法确认没有报错再重启服务。如果担心断连风险可以保持当前 SSH 会话打开新开一个终端测试登录成功后再关闭原会话。第二对于必须使用密码才能登录的账号尽量配置强密码策略建议密码长度不少于 16 位并包含随机字符。第三有条件的话把 SSH 默认端口 22 改为高位端口虽然不能防住专业定向攻击但可以显著减少自动化扫描噪音。第四使用 Fail2ban 等工具自动封禁多次尝试失败的 IP云服务器还可以通过安全组限制 SSH 的访问来源只允许公司出口 IP 访问。8.2 防火墙与最小暴露面服务器上不需要对公网开放的服务端口越少攻击面就越小。云服务器通常有安全组和系统内部防火墙两层控制建议两者配合使用。查看本机防火墙规则CentOS 系统以 firewalld 为主Ubuntu 系统以 ufw 为主。firewalld 常用命令# 查看 firewalld 状态 sudo systemctl status firewalld # 查看已放行的服务 sudo firewall-cmd --list-all # 移除不需要的服务例如移除 telnet sudo firewall-cmd --permanent --remove-servicetelnet sudo firewall-cmd --reloadufw 常用命令# 查看 ufw 状态 sudo ufw status verbose # 只允许特定 IP 访问 SSH sudo ufw allow from 你的办公IP to any port 22 proto tcp # 启用防火墙 sudo ufw enable使用防火墙的时候要小心不要把自己当前用来连接服务器的那条远程会话端口封禁掉。操作前可以在当前会话中先执行sudo ufw allow 22/tcp或sudo firewall-cmd --add-servicessh确认放行后再启用防火墙避免把自己锁在门外。除了关闭多余端口还要关注服务本身的监听地址。数据库服务如果只允许本机应用访问监听地址应该设置为127.0.0.1而不是0.0.0.0。Redis、MongoDB 这类容易被利用的服务尤其要注意不要在未设置密码的情况下直接监听公网。8.3 系统与应用更新系统漏洞和组件漏洞是入侵的重要入口。优先做好下面几件事操作系统安全补丁要及时更新云服务器可以选择“安全更新”策略尽量不在不做测试的情况下直接升级大版本。Web 中间件、数据库、PHP、Java 等运行时版本要保持在官方支持范围内不要使用已经停止维护的老版本。开源组件要关注已知漏洞比如常用的 Struts2、Fastjson、Log4j2、Spring 框架等历史上都出现过严重远程执行漏洞。弱口令是最大的隐患所有管理员密码、数据库密码、Redis 密码、后台密码都要避免使用默认值或常见词汇。更新命令在 CentOS 系统上是sudo yum update在 Ubuntu 系统上是sudo apt update sudo apt upgrade。生产环境建议先在测试环境验证兼容性再安排变更窗口执行。8.4 日志审计与监控安全自查不能只依靠出现问题时才看日志日常就要让日志形成习惯。至少要做到日志保留周期建议不少于 180 天有条件可以把auth.log、secure、nginx access log定时同步到远程日志服务器或对象存储。配置关键文件变更监控例如/etc/passwd、/etc/shadow、/etc/ssh/sshd_config、/etc/crontab的文件哈希可以使用aide这类工具建立文件完整性基线。把服务器 CPU、内存、带宽、磁盘 IO 指标的监控接入告警云厂商自带的监控服务也能实现类似能力。挖矿木马最典型的特征是 CPU 突然打满越早发现越好。定期登录云控制台查看安全中心或态势感知类的风险报告很多云平台已经内置了异常登录提醒、漏洞扫描等能力。8.5 备份与恢复演练备份是安全体系里的最后一道防线。即使系统被勒索病毒加密只要备份是完整的就可以在清理后恢复数据避免支付赎金。备份至少要满足 3-2-1 原则也就是数据保留 3 份、使用 2 种不同存储介质、其中 1 份存放在异地。不要只把备份放在同一台服务器的另一块磁盘上因为勒索病毒可能连备份一起加密。如果由于业务和数据量限制无法做到全面异地备份至少要确保核心数据库、配置文件、代码仓库有独立备份。备份是否可用要定期演练不能只看到备份成功就放心了真实环境里“备份文件损坏”或“恢复步骤缺失”的情况非常普遍。8.6 最小权限与日常运维习惯最后说一点长期容易被忽略的问题权限控制与运维习惯。对应到技术层面要明确区分 root 和普通账号。日常运维尽量使用普通账号加 sudo 的方式不要所有操作都直接以 root 执行。给开发、测试、运维人员分配账号时也应该按最小权限原则只给完成工作所必需的权限。离职人员账号要及时回收避免账号成为无人管理的僵尸入口。对应到操作习惯不要使用简单密码不要在多台服务器上重复使用同一套密码不要在代码仓库、聊天记录、项目文档中明文保存服务器密码和数据库密码。服务器安全不是一个一劳永逸的任务安全状态会随着新漏洞、新弱口令、新业务上线而动态变化。给自己建立固定的检查节奏例如每周看一眼登录日志、每月跑一次自查脚本、每次业务发布前检查端口和账号变化养成这些习惯比收藏任何一份“终极排查指南”都更管用。回头再看“快检查你家有没有进一只坏兔”这句话放在运维场景中确实是值得认真执行的提醒。排查的重点不是焦虑而是先确认账号没有异常、再确认进程端口没有异常、再确认定时任务和文件没有异常最后用备份和安全基线加固整个系统。把本文的脚本保存到服务器上下次听到类似的玩笑提醒花一分钟跑一遍总比某一天发现服务器被加密后再后悔要好。
