★ FEATURED ARTICLE 值班群里炸锅的那一刻我正坐在电脑前整理上周的安全巡检报告。告警标题写得很直白某业务服务器出现反弹shell网络外连。看到“反弹shell”三个字我心里已经下意识做出了判断——这多半不是误报这台机器大概率已经被攻击者控制了一小段时间。反弹shell是攻击者最常用的手段之一不挑操作系统不挑权限高低只要目标机器能执行命令攻击者就能把它变成一把远程遥控器。这段记录写给同样在一线做运维、做安全或者兼着两摊活的同学接到这种告警后第一步干什么、为什么这么干、有哪些容易踩的坑我都写清楚。先说结论反弹shell告警不是“查一下”就行的事它属于应急响应场景处理顺序至关重要——先确认、再切断、后溯源、最后加固顺序反了会让事情越来越难收场。下面我按一次实际处理流程完整展开。1. 收到告警先别慌先确认再动手1.1 告警里藏着哪些关键信息安全设备弹出来的告警一般包含源IP、目的IP、源端口、目的端口、协议类型、进程路径和命中时间。对反弹shell场景来说特征是相当明显的服务器内网IP主动向外网IP发起TCP连接目标端口通常不是常规的80、443而是4444、5566、7000这类随机端口也有攻击者会伪装成HTTPS流量走443所以不能只看端口。“主动外连”这四个字是重点。正常服务器的对外连接一般是有明确业务逻辑的比如调用支付接口、拉取镜像更新、上报监控数据。如果一台对内提供服务的Web服务器突然主动连了一个从未出现过的境外IP那基本可以判定为异常行为。还有一个细节值得留意告警里出现的进程路径。反弹shell往往由bash、python、perl、nc这类解释器进程发起如果进程路径是/tmp、/dev/shm、/var/tmp下面带点号开头的隐藏目录那基本就是恶意样本没跑了。1.2 登录服务器后的第一组命令确认告警信息后马上登录服务器。建议直接开一个临时终端按下面几步来# 查看当前所有TCP连接重点关注ESTABLISHED和SYN-SENT ss -antp | grep -E ESTAB|SYN-SENT # 查看指定PID对应的完整进程信息 ps aux | grep -E [p]id_of_suspect # 查看进程打开的文件和可执行文件真实路径 lsof -p pid_of_suspect实际操作中我看到的是一个指向203.0.113.10:4444的ESTABLISHED连接源端口是高位的随机端口PID对应的是一个bash进程。这个组合几乎可以直接定性为反弹shell。还有一条命令很实用读进程的可执行文件链接确认脚本或者二进制到底存在于磁盘哪个位置。ls -l /proc/PID/exe readlink -f /proc/PID/exe这一步做完不要急着杀进程。先记录现场时间、连接四元组、PID、PPID、进程完整命令行、可执行文件路径。这些信息后面溯源和取证都要用。2. 紧急隔离与阻断先把攻击者踢下线2.1 为什么第一反应不是删文件反弹shell是一条活着的通道。攻击者现在持有的不是一个恶意文件而是一个可以交互的shell他随时能在这个会话里执行命令下载更多工具、提权、读取配置、横向扫描甚至把整个内网摸一遍。如果第一反应是去删脚本文件攻击者仍然可以在当前会话里重新把文件写回来等于白忙一趟。所以应急响应的第一优先级是切断连接让攻击者失去对机器的控制。这就像家里进了贼第一步是把贼赶出去锁上门而不是先打扫房间。2.2 正确的操作顺序我的建议顺序是先封IP再杀进程最后清理文件。封IP的目的是防止攻击者重新发起第二次甚至第三次连接。先看一个封禁示例# 临时阻断立即生效 iptables -I OUTPUT 1 -d 203.0.113.10 -j DROP iptables -I INPUT 1 -s 203.0.113.10 -j DROP # 如果用的是 firewalld firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -d 203.0.113.10 -j DROP firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -s 203.0.113.10 -j DROP firewall-cmd --reload这里我不建议只做服务器本机防火墙条件允许的话应该在云安全组、硬件防火墙或者IDC出口防火墙上同步封禁。本机防火墙重启就没了安全组策略才是更持久的保障。封完IP之后再杀进程kill -9 PID杀进程之前一定把进程全部信息备份到本地可以用screen记录也可以直接复制到自己的终端存档。杀完之后再次检查ss -antp确认外连已经消失。还有一个新手特别容易犯的错看到一个进程就杀杀完觉得完事了。可是攻击者的C2工具往往有守护机制可能是父进程拉起子进程也可能是计划任务每隔几分钟重新执行一次。所以封IP和杀进程必须配套光杀不封过几分钟告警又响光封不杀会话还挂在那里。两种操作缺一不可。3. 深挖后门反弹shell从来不会自己出现3.1 追踪进程的来龙去脉连接切断之后攻击者已经断线但后门文件还在机器上。这时候开始追根溯源先看这个恶意进程是怎么被拉起来的。用进程树查父子关系ps -ef --forest | grep -A 5 -B 5 PID systemctl status PID 2/dev/null常见的启动方式有这么几类计划任务、systemd服务、开机自启脚本、WebShell调用执行、被替换的二进制文件。每一类都要查一遍# 检查当前用户的计划任务 crontab -l # 检查系统计划任务和定时目录 cat /etc/crontab ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ # 检查systemd服务重点看最近新增或修改的service文件 systemctl list-units --typeservice --staterunning ls -lt /etc/systemd/system/ # 检查开机启动项 cat /etc/rc.local我在处理的时候发现恶意脚本藏在/var/tmp/.X11-unix/这个伪装目录下路径看起来像是系统的X11套接字目录实际上是一个纯恶意的Python脚本。计划任务里有一条每天凌晨执行的记录每隔一段时间就会尝试外连C2服务器。这种隐藏方式在真实攻击中非常常见临时目录和伪装名字是重灾区。3.2 恶意样本的静态检查与保留找到样本后不要急于删除。先把样本复制到一个隔离目录压缩打包记录哈希值。这在后续溯源和写报告时都是重要的证据。# 保存哈希 md5sum /var/tmp/.X11-unix/.evil.py sha256sum /var/tmp/.X11-unix/.evil.py # 备份样本注意不要在原路径直接执行 mkdir -p /tmp/quarantine cp -a /var/tmp/.X11-unix/.evil.py /tmp/quarantine/ chmod 000 /tmp/quarantine/.evil.py然后静态看一眼脚本逻辑file /tmp/quarantine/.evil.py head -100 /tmp/quarantine/.evil.py strings /tmp/quarantine/.evil.py | less常见的内容会包括反向连接地址、伪装通信方式、下载并执行远程文件的代码、修改authorized_keys的代码、还有的会直接内置一个挖矿程序下载链接。把关键行为列出来就能确认这个样本的破坏面。这里有一个实操经验样本备份后原路径的恶意文件先留一留不要立刻删除。因为当前可能还有其他攻击者会话或者联动后门没暴露等整体排查完了再一次性清理。4. 溯源攻击路径搞清入口才算真的解决4.1 先排查认证日志切断和清样只是止血真正的难题是搞清攻击者从哪里进来的。如果这个问题不解决清理再干净也没用攻击者还会从原路进来第二次。首选检查系统认证日志。CentOS/RHEL系看/var/log/secureDebian/Ubuntu系看/var/log/auth.log。# 查看所有成功登录记录 grep Accepted /var/log/secure | tail -200 # 查看失败登录判断是否有暴力破解 grep Failed password /var/log/secure | wc -l grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -rn重点观察三个信息成功登录的时间戳、来源IP、登录用户名。如果看到一个不认识的IP在深夜用root账号成功登录那基本就是入侵入口。还要看当前在线用户和最近登录记录who last lastlog有一个很容易忽略的点如果日志里的记录戛然而止或者某个时间段内的登录记录缺失那说明攻击者具备反侦察意识很可能手工清理过日志。日志被人动过本身就是一个危险信号。4.2 Web日志与中间件排查很多反弹shell是通过Web应用漏洞打入的最常见的路径是上传WebShell、远程命令执行漏洞、反序列化漏洞。这时候需要翻中间件日志。# Nginx日志常见路径 tail -500 /var/log/nginx/access.log grep -Ei cmd|exec|shell|eval|upload /var/log/nginx/access.log | tail -100 # Apache日志常见路径 tail -500 /var/log/httpd/access_log grep -Ei cmd|exec|shell|eval|upload /var/log/httpd/access_log | tail -100把告警时间点和Web日志中的可疑请求对应起来找出那个时间窗口内出现了哪些异常POST请求、上传动作、奇怪的参数拼接。同时检查Web目录中最近新增的可执行脚本find /var/www -type f -mtime -7 -name *.php -o -name *.jsp -o -name *.jspx 2/dev/null find /usr/local/tomcat/webapps -type f -mtime -7 2/dev/nullWebShell的特点是文件时间戳与正常发版时间不符、文件名带随机字符串、代码里包含eval、base64_decode、ProcessBuilder这类危险函数。4.3 用户、密钥、权限后门排查攻击者进来之后往往会留几个后门除了计划任务和WebShell最常见的是添加系统用户和植入SSH公钥。# 检查是否有新增用户重点关注UID为0的账号 cat /etc/passwd | grep -E :0:0: awk -F: $3 0 {print $1} /etc/passwd # 检查所有用户的SSH公钥 cat /root/.ssh/authorized_keys 2/dev/null find /home -name authorized_keys -exec cat {} \; 2/dev/null # 检查sudoers配置 cat /etc/sudoers ls -la /etc/sudoers.d/攻击者添加的隐藏用户通常不会直接出现在正常系统用户列表里但通过UID为0的检测一定能揪出来。SSH公钥后门最隐蔽很多入侵事件发生后光看进程和文件都查不到结果一看authorized_keys里面躺着一个陌生的公钥——这才是攻击者的真正后门。5. 清理后门与系统加固5.1 按顺序完成清理动作溯源完成之后才开始进入清理环节。清理不是简单删文件而是把所有攻击者留过的东西一次性清干净。需要执行的清理动作包括删除恶意脚本与相关文件包括临时目录、Web目录、隐藏目录下的所有相关样本移除计划任务和相关cron文件注意检查/etc/cron.d/和/var/spool/cron/下的所有用户任务停用并删除恶意systemd服务删除攻击者添加的系统账号从authorized_keys中移除陌生公钥清理SSH登录缓存中的异常条目清理时有一条底线每一步操作前先确认不会影响业务。比如有些恶意文件伪装成正常业务脚本的同名文件删除前先对比哈希拿不准就先备份再删。5.2 把漏洞缺口补上清理完之后接下来是加固。加固的优先级取决于刚才溯源的结果如果是弱口令被爆破立即修改所有服务器密码包括root、业务账号、数据库账号密码必须达到复杂度要求如果是Web应用漏洞升级中间件版本、安装安全补丁、给上传目录关闭执行权限如果是SSH配置问题关闭密码登录改为密钥登录禁止root远程登录限制SSH来源IP如果服务器上有不必要的公网端口一律收敛能不开就不开有一个要点多说一句SSH密钥登录启用前先把公钥统一部署到运维跳板机上再用配置管理工具批量下发避免把自己锁在门外。5.3 后续观察不能省加固完成不代表可以收工。攻击者的工具可能还有备份藏在某个没发现的位置也可能隔几天再次尝试连接。后续48小时是重点观察期。持续观察以下几类指标网络外连记录、计划任务变更、系统用户变更、Web目录文件新增、日志中的异常登录。如果条件允许在该服务器上临时开启文件完整性监控对关键目录和关键配置文件的变更进行追踪。同时要把这次事件中的C2地址加入威胁情报黑名单在边界防火墙上保持封禁。安全组策略中不要着急把封禁规则删除至少保留一周观察期。6. 常见问题与排查技巧实录6.1 哪些情况容易被误判为反弹shell反弹shell告警不等于真的被入侵我在日常工作中遇到过不少误报场景。常见场景判断要点处理建议监控Agent上报数据进程路径在正常安装目录目标IP是监控服务商固定地址核对进程特征后放行软件更新下载连接目标为官方更新源端口443时间规律查看进程启动参数确认为更新程序业务回调接口连接时间与业务行为强相关目标IP有历史连接记录与开发确认后加入放行白名单恶意进程伪装连接不规律目标IP为境外或云主机进程路径异常按应急流程处理判断的核心逻辑是看三点进程是不是合理的、连接的目标是不是业务相关的、发起时间是不是符合业务规律。如果三点全部异常基本可以定性只要有一点对不上先把进程信息拿到再说。6.2 这次应急中踩过的坑和总结的技巧我把这次处理和之前几次类似事件的经验一并整理一下每条都是真金白银换来的教训。第一没有确认现场就杀进程。很多新手看到告警后第一反应是kill掉可疑进程结果进程消失的同时PID对应的文件被删除或者连接信息消失导致后续溯源完全没法做。正确的做法是先记录一切证据再动手。第二只封服务器本地忘了边界封禁。反弹shell告警出现后攻击者随时可能换一个IP再次连进来。只封本机的单条规则不够必须在出口防火墙和安全组上同步封禁封禁范围覆盖整个C2网段。第三只查root用户的计划任务。攻击者完全可以在www用户、mysql用户等低权限账号下创建计划任务而系统管理员默认只查crontab -l也就是当前用户的这样会漏掉一堆后门。正确做法是逐个用户检查/var/spool/cron/目录别偷懒。第四忽略了多台机器之间的关联。如果一台服务器被入侵攻击者往往会在同一网段内重复利用相同漏洞或相同密码登录其他机器。处理完一台就收工可能第二天另一台机器就弹出同样的告警。所以处理完当前机器后一定要做同网段排查至少检查一下网段内其他机器是否有相同的弱口令和相同版本的漏洞。其实做安全应急这件事最考验人的不是单一技术能力而是冷静和条理。确认、切断、溯源、清理、加固、观察这六个环节顺序不能乱每一步都要留证据、留记录。处理完这台服务器之后我养成了一个习惯把每次应急的过程整理成笔记包括告警截图、命令执行记录、恶意样本哈希、排查时间线统统归档。下次再遇到类似告警翻一翻笔记就能节省不少时间。希望这次的记录对正在面对同样告警的你也有用。
阅读完成 · 觉得有帮助？
