★ FEATURED ARTICLE 接手一台被入侵的Linux服务器脑子里该走什么样的排查流程手里该敲哪些命令这篇文章我就把压箱底的东西翻出来梳理成一套可以直接照着做的实战手册。不管你是刚接触应急响应服务器入侵排查、恶意程序定位、异常登录分析的新人还是已经处理过几起事件的老手这篇文章里的思路和命令都能派上用场。这次先聚焦在Linux系统的排查上把我平时处理告警时的完整套路讲清楚。1. 应急响应的整体思路与工作流1.1 应急响应的本质是什么接到服务器疑似被入侵的告警第一反应不是杀进程、删文件而是先搞清楚三件事攻击者从哪进来的、现在正在做什么、留下了哪些后手。我发现很多第一次做应急响应的人看到可疑进程就想着kill掉看到恶意脚本就急着删除结果后面做溯源分析的时候什么都找不到了攻击路径全断甚至过了几天同一台机器又被入侵一次。原因很简单应急响应的本质是止损溯源加固三件事的闭环而不是单纯的杀毒清文件。拿一个生活场景来类比家里进贼了正常人应该先观察贼是从哪个门进来的、偷了哪些东西、在屋里逗留了多久而不是第一时间把门锁换了就继续睡觉。入口没搞清楚换了锁对方照样能从窗户翻进来。应急响应也是这个逻辑先收集现场信息确认入口和攻击路径再动手封堵、清理和加固。这不是一个哪个看起来危险就处理哪个的过程而是一个快速定位、全面体检、彻底治疗的过程。1.2 为什么Linux应急响应往往比Windows更棘手Windows环境下有大量的终端安全软件、EDR产品能帮你做初步筛查很多告警可以直接依托平台日志完成闭环。但Linux服务器大多数时候是纯命令行环境哪怕是装了安全组件排查时最依赖的还是系统原始信息和手工操作习惯。更要命的是很多攻击者在Linux上会同步做反侦察工作替换系统命令、篡改日志、加载内核模块来隐藏进程和文件。你用的ps工具本身可能就是被替换过的查出来的结果自然全是假的。所以做Linux应急响应一定要有一个基本意识不能完全信任你敲进去的命令输出关键结论要交叉验证。这也是为什么我习惯优先查看/proc这样的原始内核接口而不是只看ps和netstat的展示结果。1.3 我用的一套标准流程处理了这么多起事件我把Linux应急响应的流程固定成了下面五步每步都有明确的目标和收尾动作先做现场快照确认系统时间、当前登录用户、运行时长、开机以来的可疑行为排查账号与登录痕迹找到攻击者留下的入口和永久后门排查进程与网络连接定位正在运行的恶意程序和对外通信排查恶意文件与持久化配置清理攻击者的房子和闹钟分析系统日志并串联攻击链还原整个事件的来龙去脉每一步做完我要求自己必须留下记录命令输出、时间点、判断结论。这一步非常关键后面出报告的时候这些记录就是最原始的证据链。现场信息丢了那就真的丢了后面神仙来了也补不回来。我见过太多人在排查时觉得我记得当时看到过但到了写报告时连那个可疑进程叫什么都想不起来的窘境。2. 第一站账号与登录痕迹排查2.1 异常用户账号的快速定位方法攻击者在拿到一台服务器权限后最常做的事情之一就是给自己留一个备用钥匙。这个钥匙通常就是一个新的系统账号方便它随时回来。在Linux上账号信息主要集中在 /etc/passwd 和 /etc/shadow 这两个文件里。前者记录用户基础信息后者保存密码哈希只有root权限能读。所以查账号永远是我排查的第一动作因为这是最直接、最容易发现后门的入口。快速上手命令# 查看所有UID为0的用户正常情况应该只有root awk -F: $30{print $1:$3:$7} /etc/passwd # 找出所有可以登录shell的用户 awk -F: $7!/sbin/nologin $7!/bin/false {print $1:$7} /etc/passwd # 查看账号相关文件是否被修改过 ls -l /etc/passwd /etc/shadow第一条命令非常关键。在Linux中UID为0意味着拥有root级别的系统权限。攻击者新建的后门账号通常都会把UID改成0因为这样它一旦登录进来就自动拥有最高权限。正常情况下这个查询结果应该只有root一行哪怕多出一个你完全不认识的名字基本可以确认这台机器出了问题。第二条命令查的是能登录shell的用户。系统里不少账号是专供服务使用的比如mysql、redis、nginx这些它们的登录shell被设为 /sbin/nologin 或 /bin/false意思是禁止交互式登录。但攻击者可能会把某服务账号的shell改成/bin/bash这样它就能通过这个账号直接登录到系统。我讲过一起实际案例攻击者把redis账号的shell从/sbin/nologin改成/bin/sh然后通过redis漏洞远程拿到一个能登录的shell最后这个账号成了它反复进出的大门。还有一个小细节看 /etc/passwd 文件本身的修改时间。正常运行的服务器这个文件一年半载都不会变动一次。如果你发现它的修改时间正好落在业务出现异常的那几天那就要高度怀疑账号被动了手脚。当然管理员手动加过账号也会改这个文件所以判断时要结合操作记录。2.2 SSH后门比账号更隐蔽的入口账号后门相对容易发现但还有一种更隐蔽的留后门方式往SSH配置里塞公钥。攻击者不需要知道密码只需要把自己的公钥写进目标系统某个用户的authorized_keys文件里之后就能以该用户身份免密登录。这个后门非常隐蔽因为它不产生任何登录失败记录很多安全扫描工具也扫不出来。排查手段# 查找系统里所有的authorized_keys文件 find /home /root -name authorized_keys -type f -exec ls -la {} \; # 查看公钥内容和注释信息 cat /root/.ssh/authorized_keys正常情况下每个用户的authorized_keys里只会有自己主动放进去的公钥数量很少内容一眼能看明白。如果排查时看到陌生的公钥尤其是一长串你从来没见过的base64字符那基本就是后门。再提醒一点攻击者还可能修改sshd_config里的配置比如开启Root登录、增加自定义端口、添加新的AllowUsers条目。所以我在排查SSH后门时还会顺手cat一下 /etc/ssh/sshd_config看看里面有没有异常的配置项。这一步不复杂但能查出很多账号之外的隐藏入口。2.3 登录痕迹分析确认对手是否还在线排查完账号和SSH配置接着看登录记录。这一步要回答两个问题对方有没有正在连接的会话它历史上是怎么登录进来的常用命令# 查看当前在线用户 w # 查看最近登录历史 last # 查看每个用户最近一次登录时间 lastlogw命令输出每个会话对应的IP地址和执行终端如果看到某个IP来自不应该出现的地域或者正在执行一串奇怪的命令优先把这个会话记录下来并立即切断。last输出的是登录历史lastlog输出的是每个用户最近一次登录的时间把它们和业务时间段、业务来源网段对一下就能发现时间异常凌晨操作、IP异常的登录记录。还有一个容易被漏掉的点lastb命令查看失败的登录尝试。如果日志里出现了大量来自同一个IP的Failed password记录说明这台机器很可能正在被暴力破解。虽然暴力破解本身不直接等于入侵成功但结合后面有没有同一IP的登录成功记录就能判断对方是否已经挤进门。我在做登录分析时还有一个原则不要只看成功记录也要统计失败记录的时间分布和源IP是否集中在某个网段。很多时候攻击者是通过劫持合法账号的弱口令进来的而不是新增账号这时候登录成功记录里的源IP反而比账号本身更有价值。3. 第二站进程与网络连接排查3.1 进程异常和伪装手段的识别进程排查是整个应急响应中最紧张刺激的环节因为恶意程序此刻可能正在运行。但要注意不要一发现可疑进程就立刻杀掉先记录下它的PID、启动命令、可执行文件路径再决定下一步。基础命令# 完整进程列表 ps aux # 命令行完整展示 ps -ef # 动态查看系统中CPU和内存占用最高的进程 top排查进程时我习惯盯着三件事看这个进程是谁启动的、启动命令全不全、可执行文件在哪个路径。攻击者留下的恶意程序一般都有一些特征名字看起来像系统服务但是路径明显不对从/tmp目录或/var/tmp目录启动进程所有者是root但是运行的命令很可疑。举一个我实际碰到的例子有一台机器上的恶意进程名字叫update路径是/tmp/update。光看名字很容易误以为是系统更新程序但系统更新程序不会放在/tmp目录。这就是典型的行为混淆手法名字正常路径离谱。再比如说一个叫network的进程它的可执行文件却在/home/xxx/下面这种也要重点怀疑。判断进程是否可疑还有一个实用技巧通过 /proc/[PID]/ 来查看进程的真实信息。 /proc目录是内核直接输出的进程信息比ps的输出更难被伪造。# 查看指定PID的启动命令行 cat /proc/[PID]/cmdline # 查看进程可执行文件实际路径 ls -l /proc/[PID]/exe # 查看进程打开的工作目录和加载的模块 ls -l /proc/[PID]/cwd ls -l /proc/[PID]/maps3.2 网络连接排查揪出外联通信恶意程序要么是向外回连控制端C2要么是在内网横向移动都离不开网络连接。所以查完进程马上要查网络的进出情况。常用命令# 查看所有TCP监听端口及对应进程老牌工具 netstat -antlp # 新系统推荐使用更清晰 ss -antlp排查时重点看两类信息一是系统监听的端口有没有对外开放的异常端口二是正在建立的对外连接有没有连向可疑IP的ESTABLISHED连接。处理方法其实很简单把你看到的每个外联IP和这台服务器本身的业务范围做对照一台只对内提供Web服务的机器如果出现了大量到陌生IP的持久连接那这个通信过程就非常可疑。我还常用一个组合命令把所有外联IP按数量排序异常外联往往表现在连接数突然暴涨ss -ant | awk {print $5} | sort | uniq -c | sort -nr | head -n 20如果看到某个陌生IP排在最前面记得反查一下这个IP归属哪个地区、哪个IDC恶意程序的C2地址通常带有明显的IDC标签而不是常见的家庭宽带IP段。3.3 隐藏进程和rootkit的识别经验老道的攻击者会尝试隐藏自己运行的进程。Linux下查隐藏进程有一个实用的土办法直接比对ps的输出与/proc目录下的进程编号。# 列出/proc里所有的PID和在ps里看到的做对比 for pid in $(ls /proc | grep -E ^[0-9]$); do if ! ps -p $pid /dev/null 21; then echo ps中看不到的PID: $pid fi done如果脚本输出了一堆ps中看不到的PID说明ps的输出被篡改或进程被内核模块隐藏了。接下来要验证系统命令文件的完整性# 查看关键命令的文件大小和修改时间 ls -la /bin/ps /bin/ls /bin/netstat /usr/bin/top /usr/bin/ss # RHEL系列可以用rpm校验文件完整性 rpm -V coreutils procps iproute如果ls、ps这种核心命令的修改时间和系统安装时间对不上或者rpm校验输出了一堆异常标记说明命令被替换过了。至于内核级rootkit常见的检测工具chkrootkit、rkhunter之类的可以试但我个人的习惯是一旦确认系统内核被篡改就不在这台机器上耗时打磨了保全证据后备份业务数据直接重装系统。换来换去安全性不可控。4. 第三站恶意文件与持久化排查4.1 文件时间戳分析和敏感目录检查进程和网络排查完成后基本锁定了可疑程序接下来要到文件系统里抄家——找到恶意文件本体以及它留在系统里的各种配置。攻击者放置恶意文件时习惯挑不引人注意的临时目录比如/tmp、/var/tmp、/dev/shm。这些目录通常有着可写权限而且经常被人忽视。快速定位最近变动的文件# 最近7天内修改过的常见恶意脚本和可执行文件 find / -mtime -7 -type f \( -name *.sh -o -name *.py -o -name *.bin -o -perm -ox \) 2/dev/null | grep -v -E ^/proc|^/sys|^/dev # 重点查看临时目录下的内容 ls -la /tmp /var/tmp /dev/shm按时间筛文件能帮你快速聚焦排查范围但切忌只信时间戳。攻击者完全可以用touch命令伪造文件的修改时间把恶意文件的mtime改成一年前从而躲开时间筛选。判断一个文件是否可疑我的习惯是组合看三个维度存放路径是否常见、文件类型是否符合预期、有没有数字签名或文件属性异常。4.2 清剿持久化机制计划任务与启动项我遇到过不少新手删掉恶意文件后觉得就结束了结果重启后恶意文件又回来了。原因就是没有清掉持久化机制。Linux的持久化方式主要有四种排查时挨个过计划任务# 查看当前用户的计划任务 crontab -l # 查看所有用户的计划任务文件 ls -la /var/spool/cron/ cat /var/spool/cron/* 2/dev/null # 查看系统级计划任务目录 ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/Cron是Linux下最常见的持久化手段攻击者把反弹Shell命令写进计划任务每隔几分钟到指定服务器报到一次。那些藏得很深的恶意文件就是这么被反复启动的。开机启动项# 查看rc.local文件 cat /etc/rc.local # 查看init.d下的所有启动服务 ls -la /etc/init.d/systemd服务# 列出所有启用状态的服务 systemctl list-unit-files --typeservice --stateenabled # 查看systemd目录下是否有可疑的service文件 find /etc/systemd/system -name *.service -exec cat {} \;Systemd服务是现在Linux发行版的主流启动方式攻击者会创建一个小型服务文件指向/tmp下的恶意脚本。查这个目录时重点看那些自己新出现的、文件名看起来像系统组件但不是标准包里的服务。Shell启动文件cat /root/.bashrc /root/.profile /etc/profile如果恶意程序是配合Shell登录触发的攻击者会把启动命令写进bashrc、profile这些文件里root每次登录就会自动执行一次。4.3 恶意文件识别技巧不只靠杀毒引擎杀毒软件在Linux上的覆盖率不高而且很多恶意程序是针对性编译的查杀率并不理想。但是几个简单的文件分析命令就能在绝大多数场景下判断出恶意性。# 查看文件类型 file /tmp/可疑文件 # 查看可执行权限 ls -l /tmp/可疑文件 # 查看动态链接库依赖 ldd /tmp/可疑文件 # 提取文件中可打印字符串并筛选关键特征 strings /tmp/可疑文件 | grep -E http|curl|exec|socket|/bin/sh|password|token正常的系统可执行文件一般链接系统库如果ldd命令发现某个文件没有正常的库依赖、或者依赖了不常见的库路径那可能就是被静态打包或加壳过的恶意程序。很多恶意程序还会使用UPX压缩壳减小体积和对抗分析strings里如果看到UPX标记那基本不用犹豫这就是一个刻意伪装过的可执行程序。再补充一个经验攻击者喜欢给恶意文件起一个正常的名字比如截图、文档、系统库文件的名字却把它们放在临时目录或隐藏目录。所以名正不等于身正关键是看文件类型和它所在的位置是否互相匹配。5. 第四站日志分析串联入侵链5.1 系统日志关键字段和常用查询日志分析是应急响应里最花时间但也是最出成果的环节。前面找到的每一个孤立线索最后靠日志串联起来还原成一条完整的攻击链。先明确日志位置。RHEL/CentOS系列和Debian/Ubuntu系列的日志文件名略有差异但作用是一致的。日志文件主要用途典型分布/var/log/secure认证日志登录成败、sudo操作RHEL/CentOS/var/log/auth.log认证日志同上Debian/Ubuntu/var/log/messages系统整体消息、内核事件RHEL/CentOS/var/log/syslog系统整体消息Debian/Ubuntu/var/log/cron计划任务执行日志常用发行版/var/log/wtmp、btmp登录成功/失败的二进制记录常用发行版查看认证日志里的登录记录# 查看成功登录的记录 grep Accepted /var/log/secure # 统计失败口令的次数 grep -c Failed password /var/log/secure # 提取暴力破解来源IP排行 grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head # 查看某个特定IP的所有登录尝试 grep 1.2.3.4 /var/log/secure这里要注意字段位置。secure日志里Failed password from 1.2.3.4这种格式中IP在倒数第4个字段用awk加偏移量提取时别搞错了。试过的都知道字段数差一个提取出来的就是端口而非IP。5.2 日志被清空或篡改后的补救判断攻击者干完坏事多半会清理日志最粗暴的方式就是直接清空文件内容。判断方法看文件的最后修改时间ls -la /var/log/secure* /var/log/messages*如果这些日志文件在某个时间点突然变小、变空或者最后的写入时间和当前时间相差很远说明那段时间的日志缺失。但空白不等于什么都没发生还有几个间接源头可以捞到信息/var/log/btmp 的反向读取lastb能列出失败登录记录清空secure不一定会清空btmpShell历史文件/root/.bash_history、每个用户的.bash_history攻击者操作过的命令可能留在这里应用访问日志Nginx、Apache、Tomcat等应用日志会用二进制绕过系统层面记录攻击行为系统审计日志如果提前开了auditd日志在/var/log/audit/audit.log里通常比secure更详尽、更难清理日志清空不可怕可怕的是只盯着一个文件查。我排查时习惯同时打开多个日志来源把时间轴对齐能拼出大半真相。5.3 把碎片线索串成完整攻击链最后一步是溯源也就是把前面发现的孤立证据用时间线串联起来。这一步做得好整台机器的入侵路径就清晰了。我拿一起真实处理过的攻击过程举例说明凌晨2点10分secure日志里出现大量来自某IP的Failed password记录持续了大约8分钟凌晨2点18分这个IP出现一次Accepted说明登录成功同时段的lastb记录了同一个IP的多次失败尝试凌晨2点25分cron日志里新增了一条计划任务记录凌晨3点/tmp目录出现一个新的ELF文件PS里多了对应的进程这就是一条非常典型的攻击链暴力破解→登录成功→写入计划任务→植入恶意程序。全程不超过1小时。看到这样一串事件后续该做什么就很明确了封禁这个来源IP、清理后门账号、删除恶意计划任务、移除恶意文件、加固SSH口令策略。串联攻击链的核心思想是时间对齐把所有日志、文件修改时间、进程启动时间放到同一根时间轴上每个证据都要能对上前后逻辑。对不上的地方往往才是攻击者最费心隐藏的地方值得深挖。6. 常见问题与排错技巧实录6.1 现场高频问题速查现象可能原因处理优先级找不到可疑进程和连接进程被rootkit隐藏ps命令被篡改高用/proc对比提权删除恶意文件后重启又出现持久化机制没清干净高重点排查计划任务和systemd服务日志文件为空或时间戳缺失攻击者已清理系统认证日志中查应用日志、btmp、审计日志服务器持续对外发送流量存在主动外联的C2木马高先按最小化网络策略隔离出现不知道的UID 0账号系统被植入后台管理账号立即禁用账号并改密再补充几个我自己总结的硬经验。第一接到告警后先不要急着改密码。改密码会让正在进行的恶意会话中断也会打草惊蛇手动排查还没做完证据就丢了。要先观察和记录确认好现场再统一整改。第二在没有做磁盘快照或日志备份的情况下不要直接断网重装系统。应急响应里最重要的目标之一是追查攻击原因和影响范围重装系统等于把所有现场证据抹掉连攻击者的渗透路径都无法确认下次还会以同样漏洞被打进来。第三排查过程中务必全程截图并保留命令输出到文件。出报告的时候这些原始记录比任何人工描述都有说服力。我不止一次见过排查结论写得很漂亮、但拿不出具体日志记录的尴尬场面。6.2 准备一个应急工具箱我强烈建议在每台Linux服务器上提前放置一套静态编译的排查工具包含busybox整合了常用命令、静态编译的ps、netstat、find、grep、awk等。平时不占多少空间但真遇到系统命令被替换的情况这套静态版本的工具能帮你看到真实的信息。具体存放的位置可以隐蔽一点不要放在/tmp这种目录。安全可控的位置是/opt下某个子目录或root用户自己的目录并且权限设置成root可读可执行。我见过一个反面教材管理员把应急工具箱放在/tool下结果攻击者连这套工具都删了然后篡改了系统/lib库最后排查时连个能用的ps都没有相当被动。6.3 最后再提醒几件事排查日志时输出结果较多不要只看终端跑完的最后几行。把输出保存到本地文件再通过对比时间、IP来归纳。很多关键线索藏在中间部分扫一眼很容易漏掉。整台机器排查完、确认恶意程序清除干净之后建议再做一次全量补强修改所有账号口令、限制SSH来源IP、关闭不必要的端口、给关键日志配置远程备份。Linux应急响应不是一次清完就万事大吉后续的加固工作决定了这台机器会不会在几个月后再次出现在告警列表里。我个人在实战中踩过最深的坑是第一次处理事件时太紧张看到可疑进程就想杀看到可疑文件就想删最后连攻击者是从哪进来的都没搞清楚。后来我给自己立了一条规矩先快照、再排查、最后处置。宁可速度慢几分钟也要保证排查输出的完整和可回溯。应急响应从来不是比谁手快而是比谁信息收集得更全、链条还原得更准。这台Linux处理完还要反推同一个攻击源有没有关联其他机器地址段里有没有同样漏洞的兄弟服务器把整个战场照清楚才算真正处置完一起事件。
阅读完成 · 觉得有帮助？
