1. 应急响应到底是什么零基础该怎么理解它先说我第一次接到服务器入侵排查任务时的真实状态客户半夜打电话说网站被篡改了首页弹出一堆乱七八糟的内容我当时手边连一份排查流程清单都没有只能一边在服务器上敲命令一边翻文档手忙脚乱地查了几个小时。那种感觉你现在应该能理解——不是不想干活是不知道从哪里下手。应急响应Incident Response说白了就是四个字发现问题、解决问题。当服务器出现被入侵的迹象时我们要做的不是先把系统重装了事而是要搞清楚攻击者是怎么进来的、做了什么、留下了什么后门、怎么把影响降到最低。这套动作规范化以后就叫应急响应。它不是安全工程师的专属技能运维、开发、甚至兼职管服务器的人都迟早会遇上。这篇教程我按最容易上手的路径来写不会一上来就堆吓人的术语。你只要能熟练操作Linux和Windows的基础命令跟着一步步走就能完成一次标准的服务器入侵排查。里面涉及的命令、检查项、判断方法都是我平时在真实项目里验证过的不是教科书上的摆设。先建立一个最基本的认识服务器入侵排查的核心任务只有一个找出异常。系统再怎么复杂攻击者进来了总会留下痕迹要么是多了个账号要么是多了个进程要么是文件时间不对要么是日志里有可疑记录。我们的工作就是把藏在正常事物里的这些不一样找出来。我建议零基础的朋友先记住这个简单的排查顺序网络连接 - 账号 - 进程 - 启动项 - 计划任务 - 日志 - 文件。这套顺序也对应了我后面几章的安排按它走不会漏项。2. 到达现场的第一步隔离和备份千万别急着删东西很多人一发现服务器被入侵第一反应是马上把可疑文件删掉、把木马进程杀掉。这个做法我很理解但对排查来说是大忌。你删掉的不只是攻击者的工具很可能连他最关键的入侵痕迹也一起毁了后面想溯源就难了。正确的顺序是先隔离、再备份、最后才开始查这个顺序能帮你保住最重要的证据。2.1 隔离服务器限制攻击者的活动范围所谓隔离就是让被入侵的服务器和正常业务网络断开通信。具体操作分三步先断外网。如果你用的是云服务器直接在控制台上修改安全组规则把入方向端口全部拒绝只保留你当前用来排查的IP。这一步相当于把攻击者的后门通道给堵住了他还在系统里也没关系出不去就成了瓮中之鳖。再断内网如果这台服务器还需要内部其他机器通信我建议在防火墙上临时限制一下。你可以在Linux上执行iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT这个命令之后外部所有入站连接都会被丢弃但你从服务器往外发起的连接不受影响方便你后续下载工具或做远程排查。注意这条命令只接受已建立的连接可能会影响正常的SSH会话保险起见你在执行前先确认一下自己的连接是不是已经稳定。Windows服务器就在高级防火墙里新建一条阻止所有入站连接的规则同样能达到效果。2.2 做一份完整的证据备份隔离完成之后立刻做备份。这一步的价值在于万一排查过程中误操作破坏了原始现场你还有一份干净的副本可以用来复查。Linux服务器我强烈建议直接用dd命令做磁盘镜像比如dd if/dev/sda of/mnt/backup/sda.img bs4M不过很多情况下来不及挂载备份盘那退而求其次至少把下面这些关键证据复制一份cp -r /var/log /backup/logs cp /etc/passwd /backup/passwd.bak cp /etc/shadow /backup/shadow.bak cp /etc/crontab /backup/crontab.bak crontab -l /backup/root_crontab.txt ps aux /backup/ps_aux.txt netstat -antlp /backup/netstat.txt如果你用的是Windows可以用PowerShell把关键日志导出来wevtutil epl System C:\backup\System.evtx wevtutil epl Security C:\backup\Security.evtx wevtutil epl Application C:\backup\Application.evtx提示备份文件不要存在被入侵的这台机器上应该传到你自己电脑或专用的证据存储位置。攻击者如果还没完全离开你存在本地的备份也可能被他接着篡改。2.3 做好排查记录每一条命令都留痕还有一件很多新手会忽略的事——记录。我开始做应急响应的时候习惯把每一条执行的命令、每一次看到的异常输出都随手记在本地文档里。后来发现这个习惯帮我避免了好几次麻烦客户问你怎么得出这个结论的你能直接列出证据复盘的时候也能清楚还原当时的判断逻辑。你可以把排查现场的所有命令记录在本地终端日志里Linux的script命令可以做到script -a /home/yourname/incident_log.txt之后执行的命令和输出都会被记录到这个文件里。排查结束后把这份记录和前面备份的证据一起归档保存后续写报告和溯源都用得上。3. 从账户和登录日志入手找出攻击者留下的身份线索进入正式排查环节。我之所以把账号和登录日志放在第一位是因为这是目前最普遍、也最容易留下明显痕迹的入侵入口。攻击者通常不会手搓一个漏洞攻击进来更多是拿到了一组合法凭证或者通过漏洞创建了隐藏账号然后再伺机提权。你只需要认真核对一遍账号往往就中奖了。3.1 Linux系统的账号检查方法Linux下检查账号就几个命令的事但要看仔细。查看所有本地账号cat /etc/passwd awk -F: $30 {print $1} /etc/passwd第一条命令看所有用户列表第二条专门找UID为0的用户。正常情况下UID为0的用户只有root一个如果多出来一个admin、web之类的基本可以肯定有问题。攻击者为了好记常常会创建一个看起来像系统账号的名字但UID是0这招骗不过查看UID的命令。检查超级用户组grep -v ^[[:space:]]*# /etc/sudoers如果你发现某个不认识的账号在sudoers里而且权限是NOPASSWD: ALL那就等于对方已经拿到了root权限。我还习惯顺手看看最近有没有新的SSH密钥被写入ls -la /root/.ssh/ cat /root/.ssh/authorized_keys攻击者拿到权限后一个很常见的操作是把自己的公钥写进authorized_keys这样以后就不需要密码直接密钥登录。一旦发现不认识的公钥马上处理这是后门最隐蔽的形式之一。3.2 Windows系统的账号检查操作Windows服务器上新手最快的检查方式是打开命令行执行net user它会列出所有本地用户。仔细看看有没有可疑的新用户比如普通名字带个数字、或者明显不是你们自己创建的那种账号。再检查管理员组和远程桌面用户组net localgroup administrators net localgroup Remote Desktop Users管理员组里多出来的未知用户优先级最高基本是入侵确认信号。Windows的隐藏账号花样更多注册表里也藏着乾坤。你需要查一下这个位置HKEY_LOCAL_MACHINE\SAM\SAM不过默认权限打不开需要借助注册表工具或者提权后的查看方式。日常排查我一般先看net user的输出注册表这层留给有基础的朋友去做深度分析。3.3 登录日志里藏着什么信息Linux最重要的登录日志在/var/log下。我的查看顺序是last -F 100 lastlog cat /var/log/auth.log | grep Acceptedlast显示最近登录记录lastlog看所有账号的最后登录时间。我曾在一次排查中发现一个不活跃的账号pppuser居然在一个月前有过登录记录一查就是从那里进去的。重点看几个特征登录来源IP是否正常、登录时间是否在工作时间之外、失败登录是否特别密集。如果某个IP尝试了几百次登录那就是暴力破解迹象。Windows的登录事件在事件查看器里重点看安全日志事件ID 4624是成功登录、4625是失败登录。打开事件查看器 - Windows日志 - 安全筛选里面4624的事件逐个看登录类型和来源IP。登录类型为3表示网络登录来自内网或外网的异常IP需要提高警惕登录类型为10是远程交互式登录也就是RDP进来的如果有异常的远程登录基本可以锁定入侵途径。4. 追踪进程、启动项和计划任务找到潜伏的木马账号这条线查完没发现异常不要高兴太早。很多攻击手段不会创建账号而是直接利用一个Web漏洞上传Webshell然后执行命令、反弹Shell。这时候就需要往下看进程和启动项了。4.1 检查Linux网络连接和进程先看网络连接攻击者与外部通信必然要建立连接直接看监听端口和外部地址netstat -antlp ss -antlpnetstat -antlp列出所有TCP连接和监听端口显示对应的进程PID和程序名。我一般会重点看ESTABLISHED状态的对端IP如果出现了一个明显不属于你业务范畴的外部IP就需要跟踪相应的PID。举一个真实例子去年我排查的一台Web服务器netstat显示有个进程对外部IP建立了多条连接PID对应的程序在/tmp/.X11-unix/下面名字叫kworker。正常的内核线程不可能在/tmp目录下有可执行文件看到这个路径加名字的组合基本就不用再怀疑了——这就是伪装成内核进程的挖矿木马。接下来查看进程ps auxf ps aux --sort-%cpu ls -l /proc/[可疑PID]/exeps auxf可以看进程的父子关系一些恶意进程为了保持存活会创建子进程从树状结构里能看出异常第二条命令按CPU排序挖矿木马占用CPU极高一上来就很显眼第三条命令查看可疑进程的完整路径如果是/tmp、/var/tmp、/dev/shm这些目录就要高度怀疑。我还习惯启动前先检查一下高占用进程的启动时间ps -p [PID] -o pid,lstart,cmd如果服务器启动了好几个月这个进程却是几天前启动的那多半是入侵后拉起来的。配合它占用的CPU判断会更准确。4.2 Windows进程和网络检查Windows下用任务管理器看进程树或者用命令行netstat -ano tasklist /v wmic process get ProcessId,CommandLine,ExecutablePathnetstat -ano会显示每个连接对应的PID再配合任务管理器反查PID对应的程序。很多恶意程序会伪装成svchost.exe这是Windows系统的正常系统进程新手特别容易看漏。判断标准是看它的实际路径和启动方式正常svchost由系统服务管理器启动如果你在wmic输出中看到svchost的命令行里带奇怪的参数或者路径不在System32目录下就需要追查。wmic输出的CommandLine信息很有用能直接看到进程是凭哪个文件启动的恶意程序的命令行里常带base64编码、PowerShell -enc、下载远程脚本这类特征。4.3 启动项排查攻击者如何实现持久化找到并杀掉一个恶意进程不难难的是防止它重生。攻击者需要设置开机自动运行服务器一重启木马又回来了。排查启动项就是把这个复活机制找出来。Linux下重点看这几个地方cat /etc/crontab cat /var/spool/cron/crontabs/* 2/dev/null ls -la /etc/rc.d/rc*.d/ ls -la /etc/init.d/ cat /etc/rc.local其中/etc/crontab和root的crontab我见过最典型的恶意任务长这样每过5分钟从某个URL下载脚本并执行输出结果写到随便一个日志文件里。这是挖矿木马最爱的持久化方式。Windows系统上新手最快的办法是用微软官方工具Autoruns它能展示注册表启动项、计划任务、服务、驱动等所有开机自启项目。如果你不想装额外工具可以用命令行查看计划任务schtasks /query /fo LIST /v重点看计划任务里的下次运行时间和要运行的任务。如果有个任务每小时执行一次PowerShell脚本但脚本的路径不在任何业务目录里那就明显有问题。4.4 服务与驱动的排查Linux的服务一般放在/etc/systemd/system/目录可以用systemctl检查systemctl list-unit-files --typeservice --stateenabled systemctl cat [可疑服务名]我的习惯是先把最近修改过的服务配置文件列出来find /etc/systemd/system -name *.service -mtime -30这条命令列出30天内被修改的所有service文件。正常部署不会频繁改动服务配置一旦发现异常逐个人工查看内容重点关注ExecStart字段指向的路径。Windows服务排查用sc query type service state all wmic service get name,pathname,startname重点看服务的可执行文件路径是否在奇怪位置以及登录身份是否用了LocalSystem。攻击者很喜欢注册一个看起来像系统名字的服务比如Windows Media Center Service实际指向的却是/tmp或C:\Users\Public下的文件。5. 深入Web目录和后门文件Webshell排查实战技巧账号、进程、启动项都查完了如果还没发现异常接下来就要到Web层面去翻一翻。大多数对外的服务器被入侵都是通过Web应用的漏洞进来的攻击者在Web目录里留下Webshell文件用这个后门做中转执行命令。5.1 Webshell长什么样该怎么识别Webshell就是一个写在服务器上的脚本文件它接收攻击者的HTTP请求然后在服务器上执行命令。常见形式可能是PHP、JSP、ASPX、Python甚至混淆过的JavaScript。对新手来说识别Webshell有两条路径借助搜索引擎搜文件特征或者直接用工具扫。我先说手动识别。Linux下用find /var/www/html -name *.php -mtime -30 -type f find /var/www/html -name *.php -size 10k find /var/www/html -name *.jsp -mtime -30 -type f第一条找30天内被修改过的PHP文件第二条找超过10KB的PHP文件。Webshell通常上传时间就在入侵发生那几天而且为了容纳加密的命令执行代码文件体积比平均的业务脚本大不少。找到可疑文件后用grep搜一些危险函数特征grep -rn eval( /var/www/html/ grep -rn assert( /var/www/html/ grep -rn base64_decode /var/www/html/ grep -rn system( /var/www/html/ grep -rn shell_exec /var/www/html/ grep -rn cmd /var/www/html/ --include*.php搜索时注意把命令放在代码块里。正常的业务代码偶尔也会有system、exec这些函数但如果你在某个不认识的上传文件里看到base64_decode配合eval的组合恭喜你基本等于找到了后门。工具方面我推荐零基础的朋友先使用在线病毒扫描平台或开源工具例如CloudWalker牧云和河马Webshell查杀它们的报告比较友好查杀率高而且有网页版不需要你在服务器上折腾环境。5.2 不放过文件系统的蛛丝马迹Webshell查完了还要看看文件系统里其他异常。攻击者除了放Webshell还可能在各个目录里藏工具、放提权脚本。我常用的几个命令find / -mtime -30 -type f -perm /4000 2/dev/null find / -name *.php -mtime -30 -type f 2/dev/null ls -la /tmp /var/tmp /dev/shm /home /root第一条找最近30天被修改、且带SUID权限的文件。SUID位是Linux的一种特殊权限如果攻击者把一个可执行文件设了SUID普通用户运行它就能以文件所有者的身份执行等于提权后门。正常系统里的SUID文件就那么几个固定位置一旦出现新增的就要立刻处理。第二条配合Web判断新上传的PHP文件第三条是看看临时目录里有啥。攻击者为了不污染正常业务目录很爱把工具放在/tmp、/dev/shm这类可写且看起来不起眼的地方。我遇到过把挖矿程序藏在/dev/shm里的因为那个目录是内存文件系统重启后数据自动消失但运行期间很难被发现。5.3 从Web日志中还原攻击者的操作路径找到Webshell之后还要回答一个问题攻击者是怎么上传这个文件的这个问题需要看Web访问日志。以最常见的Apache为例日志一般在/var/log/apache2/或/var/log/httpd/下。我习惯先用时间定位grep 2024-10-15 /var/log/apache2/access.log | grep -i POST\|upload重点看POST请求尤其是上传文件的接口。如果日志里出现了一个不认识的脚本上传成功比如upload.php带了一个文件参数后面紧跟的请求都是访问那个新文件基本上就是入侵的时间点和途径。Nginx的访问日志在/var/log/nginx/access.log格式类似。查看时注意URL编码攻击者会把恶意代码编码在URL里有些Web日志会显示被解码后的内容方便我们快速判断。如果服务器用的是IIS事件日志和HTTP日志记录位置不同但排查思路一样先定位POST请求再看访问新文件的时间。5.4 日志审计时最容易忽略的几个细节日志审计要有重点不是每一条日志都值得看。我的经验是按这几个维度筛选异常时间段查看业务非高峰期的访问记录比如凌晨两三点。攻击者通常会挑管理员休息的时间动手。异常URLURL里带cmd、exec、base64、eval、passwd这些关键字的请求基本可以确认是扫描或攻击行为。异常状态码一个文件被反复尝试用不同方式请求返回404后突然出现一次200说明攻击者测试成功后成功上传了。上传文件类型检查日志里上传的文件后缀如果出现.php、.jsp、.aspx、.py、.phtml这些可执行脚本类型结合业务看是否合理。一个普通的公司网站如果上传了PHP文件那就是Webshell的最佳证据。6. 常见入侵场景的排查技巧速查我把这些年遇到的高频入侵场景整理成了一张速查表。你按照表中的症状去对应检查效率和准确度会高很多。入侵类型常见症状重点检查位置核心排查命令/方法暴力破解入侵服务器CPU正常但登录日志大量失败记录/var/log/auth.log、Windows安全日志检查4625事件、lastb统计失败IP挖矿木马CPU和内存占用异常高外联矿池IP/tmp、/var/tmp、/dev/shmps aux --sort-%cpu、netstat -antlpWebshell后门Web目录多出可疑脚本文件web目录、access.logfind按修改时间搜索、grep危险函数账号后门新增未知用户、UID异常、管理员组多成员/etc/passwd、net userawk查找UID 0、net localgroup启动项持久化服务器重启后木马复活crontab、systemd、计划任务crontab -l、schtasks /query勒索病毒文件被加密为随机后缀收到勒索提示全盘、挂在启动项的文件检查加密文件后缀、启动项、进程每种场景的排查优先级也不同。挖矿木马先看进程和网络外联勒索病毒先隔离断网再分析加密方式暴力破解先改密码再封禁来源IPWebshell先定位文件再看日志回溯路径。记住这个优先级到现场就不会乱。6.1 一套开箱即用的排查脚本新手没有经验最怕的是漏项。我建议你动手前先做一个自动化信息收集脚本把该看的都先抓出来再人工分析。这段脚本是我平时在Linux上常用的简单整理了一下#!/bin/bash echo 当前登录用户 w echo UID0的账号 awk -F: $30 {print $1} /etc/passwd echo 最近登录记录 last -F 20 echo 失败登录统计 grep -c Failed /var/log/auth.log 2/dev/null || echo 无auth.log echo 计划任务 crontab -l 2/dev/null cat /etc/crontab echo 监听端口 netstat -antlp echo 高CPU进程 ps aux --sort-%cpu | head -20 echo 最近修改的web文件 find /var/www/html -type f -mtime -7 2/dev/null echo tmp目录 ls -la /tmp /var/tmp /dev/shm脚本跑完应急响应七八成的信息都收集到了。剩下的工作就是在输出里找异常。6.2 Windows系统的快速收集命令Windows没有自带类似的批处理脚本但只要组合几条命令也能达到差不多的效果echo off echo 用户列表 net user echo 管理员组 net localgroup administrators echo 网络连接 netstat -ano echo 计划任务 schtasks /query /fo LIST /v echo 启动项 reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run reg query HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run echo 服务列表 wmic service get name,pathname,startname这些命令会花一两分钟跑完把输出保存下来逐行分析。新手用这个方式即使不知道从哪下手也能拿到第一手的排查资料。7. 排查完之后的系统加固阻止下一次入侵找到入侵、清理掉后门只完成了一半的工作。如果不加固攻击者随时可以用同样的方法再进一次。我在每次应急响应结束时都会强制自己完成下面这一套加固动作。7.1 修改所有凭据并启用强认证无论入侵原因是什么先改一波密码再说。范围包括服务器本地管理员/root密码、数据库密码、Web应用后台管理员密码、FTP密码、甚至Redis、MySQL这类中间件账号。如果系统里还有其他服务器用了同一套密码全部改成不同的新密码。有条件的把SSH密钥认证打开禁用密码登录# 修改 /etc/ssh/sshd_config PasswordAuthentication no PubkeyAuthentication yes改完重启SSH服务systemctl restart sshd。这样即使以后攻击者拿到了一个弱口令也没法用密码直接登录。Windows服务器则建议强制启用RDP的网络级别身份验证并使用较复杂的本地密码。7.2 服务最小化不需要的端口和服务全部关掉很多入侵其实是扫端口扫出来的。服务器上开着永远不会用的3389、3306、6379、9200就像窗户忘了关别人只需轻轻一推就能进来。我用Nmap或者云服务商的安全组控制台扫一遍服务器把不用的都关掉。Linux下查看当前监听端口和服务状态ss -tlnp systemctl list-units --typeservice --staterunning看到不认识的端口或者不用的服务直接停掉systemctl stop [服务] systemctl disable [服务]。云服务器的安全组规则也检查一遍把对外暴露的端口缩减到只有业务必须的80/443/22数据库端口、管理端口一律限定来源IP。7.3 部署基础监控和日志告警服务器被人入侵后如果发现得太晚损失就不可控了。所谓发现得早靠的不是运气而是监控。最基本的监控方案免费开源的有PrometheusGrafana简单点可以直接用云厂商自带的云监控或者写定时脚本检查文件变化。日志采集方面我把auth.log、访问日志和系统登录日志统一转发到独立的日志平台上配置一个规则同一个IP在一分钟内出现超过10次失败登录就触发告警发到手机。这样即使我再忙也不会错过入侵的第一时间。7.4 建立应急响应预案并定期演练这是我见过最多的疏漏。很多公司被入侵一次之后过半年又被入侵一次原因就是上次的排查经验没有沉淀成文档。我在每次应急响应结束后都会写一份报告内容包括入侵时间线、入口点、处置过程、加固建议、责任人。然后整理成一份标准预案每季度在测试机上演练一次。新手可以把这个习惯作为自己学习方式的一部分——每排查一台服务器就写成笔记下次遇到类似症状直接翻笔记效率提升不止一倍。8. 新手写给新手我的几条实战心得做了这么多年应急响应有一些话想单独对零基础的朋友说。第一不要怕漏掉什么而不敢动手。排查服务器入侵不是考试没有标准答案。你只要按照我上面的顺序把网络连接、账号、进程、启动项、计划任务、日志、文件全过一遍百分之九十九的常见入侵都能找到痕迹。真正可怕的不是你排查得不够深而是出了问题不去查或者查一半就放弃了。第二多练多积累别只看理论。安全这行实操经验和理论同样重要。你可以自己搭一台测试环境安装一个很老版本的CMS程序故意放一个Webshell进去再模拟登录日志然后从头到尾走一遍排查流程。这个过程走两三次你对命令和判断标准就有肌肉记忆了。第三保持平常心。排查入侵时你可能会紧张担心自己判断错误、影响业务。我也有过这个阶段。我现在的方法是每做一个操作前先想清楚后果确认无损再执行拿不准的操作就先备份或者先在测试环境验证。宁可慢一点也不能凭感觉乱改。第四把没有发现异常当成一次学习机会。我遇到过很多次排查半天什么都没找到的情况后来发现是看漏了某个日志或者攻击者清理了痕迹。从另一个角度想这次排查经验让你更了解这台服务器的正常状态下次再排查时你就能更快地发现哪里不对。最后回到心态上。应急响应这件事经验越丰富处理越从容。你也不需要等到真出事才开始准备完全可以趁现在系统还正常运行的时候先跑一遍排查脚本把服务器该有的样子记在脑子里。等到真需要排查的时候你心里就有数了。反正我现在接到客户的应急响应电话已经习惯先在电话里让客户执行那几条命令绝大多数问题的线索都在第一轮信息收集里现出原形了。