1. 项目概述与核心价值最近在安全圈子里一个叫“easy溯源”的靶场热度挺高很多朋友都在讨论。这个靶场模拟的是一个典型的Linux服务器入侵场景核心目标不是让你去攻击而是让你扮演“安全分析师”或“应急响应工程师”的角色去分析攻击者留下的蛛丝马迹完成一次完整的攻击溯源。听起来就很有意思对吧它把反弹Shell、内网穿透、WebShell上传、日志清理这些攻击者常用的“组合拳”都打包在了一个环境里让你能在一个受控的沙箱中亲手触摸到真实的攻击痕迹。我花了点时间在自己的Ubuntu 22.04 LTS系统上完整复现了这个靶场并且把整个分析过程从头到尾捋了一遍。这篇文章我就来当一回“保姆”手把手带你走通从环境搭建到痕迹分析的全过程。无论你是刚入门安全的新手想了解应急响应到底在干什么还是有一定基础想通过实战巩固技能的朋友这篇教程都能给你提供一条清晰的路径。我们不止要“复现”更要深挖每一步“为什么”要这么做以及在实际工作中遇到类似痕迹你的排查思路应该是什么。准备好了吗我们这就开始。2. 环境准备与靶场部署2.1 系统与基础环境配置复现的第一步是准备好我们的“实验台”。我选择的是Ubuntu 22.04 LTS这是一个长期支持版本系统稳定软件源丰富非常适合做这种实验。当然20.04或者更新的版本也完全没问题。关键在于我们需要一个干净的、最好是刚安装好的系统或者至少是一个你确定没有运行其他复杂服务的环境这样可以避免无关进程和日志的干扰。首先确保系统更新到最新并安装一些必要的工具。打开终端执行以下命令sudo apt update sudo apt upgrade -y sudo apt install -y docker.io docker-compose vim curl wget net-tools lsof这里解释一下为什么装这些docker.io和docker-compose这是本次复现的核心。靶场环境通常被打包成Docker镜像用容器技术可以快速搭建、一键还原非常方便。vim一个高效的文本编辑器查看和编辑配置文件必备。curl和wget用于从网络下载文件。net-tools包含netstat等老牌网络工具虽然ss命令更现代但很多场景下netstat的显示格式更直观。lsof列出打开文件的工具在排查进程、端口占用时极其有用。安装完Docker后记得将当前用户加入docker组这样以后就不用每次都sudo了sudo usermod -aG docker $USER操作后需要重新登录系统或开启一个新的终端会话这个改动才会生效。这是一个很容易被忽略的细节很多人加了组后直接操作发现还是权限不够问题就出在这里。2.2 获取与部署“easy溯源”靶场“easy溯源”靶场的具体部署文件通常来自开源社区或一些安全学习平台。由于靶场镜像可能涉及模拟攻击行为务必在你自己可控的虚拟机或隔离环境中进行绝对不要在生产环境或公有云主机上尝试。假设我们已经获取到了靶场的docker-compose.yml文件和相关的Docker镜像。部署过程非常简单创建一个专属目录例如easy_trace并将所有部署文件放入其中。进入该目录运行部署命令。mkdir ~/easy_trace cd ~/easy_trace # 假设你已经把 docker-compose.yml 文件放到了这里 docker-compose up -ddocker-compose up -d这个命令会以后台模式启动所有在配置文件中定义的服务。-d参数代表“detached”即后台运行。执行后你可以用docker-compose ps查看容器是否正常启动。一个关键的实操心得在启动容器后我习惯立刻用docker-compose logs快速扫一眼启动日志看看有没有明显的错误比如端口冲突、依赖服务启动失败等。Ubuntu系统上常见的端口如80、3306MySQL、6379Redis可能被其他软件占用。如果遇到端口冲突你需要修改docker-compose.yml文件中的端口映射规则比如将80:80改为8080:80这样外部就通过8080端口来访问了。等待片刻当所有容器状态显示为“Up”时靶场环境就搭建好了。你可以通过浏览器访问http://你的服务器IP:端口来确认Web服务是否正常。至此我们的“犯罪现场”已经准备就绪接下来就是深入现场开始勘查。3. 攻击痕迹分析与溯源实战靶场启动后它本身已经模拟了一次完整的入侵。我们的任务就是抽丝剥茧找出攻击者干了什么怎么干的。整个分析流程可以遵循一个基本的应急响应顺序先现象后进程和网络再文件与日志最后串联线索。3.1 初始现象与入口点分析通常靶场会给你一些初始提示比如“网站首页被篡改”或“服务器运行异常缓慢”。我们假设第一个发现的异常是网站首页比如index.php被替换成了一句话木马或挑衅语句。首先登录到靶场对应的Web容器内部。我们需要先找到容器的名称或ID。docker ps # 列出所有运行中的容器找到运行Web服务可能是Apache或Nginx的容器记下它的CONTAINER ID或NAMES。然后进入容器docker exec -it 容器ID或名称 /bin/bash进入容器后第一时间检查Web根目录下的文件。以常见的/var/www/html为例cd /var/www/html ls -la重点查看index.php等默认首页文件的修改时间、文件大小和权限。使用cat或head命令快速查看文件内容确认是否被植入恶意代码。这里有一个技巧攻击者为了隐藏可能会将原始文件备份或重命名比如index.php.bak同时留一个看起来正常的index.php作为后门。所以要用ls -la仔细查看所有文件特别是隐藏文件以.开头和最近修改的文件结合ls -lt按时间排序。如果发现可疑文件立即检查其内容。一句话木马通常特征明显如eval($_POST[‘cmd’])或assert($_REQUEST[‘x’])。找到它就找到了第一个确凿的证据也往往是攻击的入口点——很可能是通过文件上传漏洞传上来的。3.2 反弹Shell痕迹排查攻击者获得WebShell后为了获得一个更稳定、功能更完整的交互式Shell通常会尝试反弹Shell。这是内网渗透中非常关键的一步也是我们排查的重点。反弹Shell会在服务器上留下哪些痕迹呢主要是网络连接和进程。1. 网络连接排查即使在容器内我们也可以使用netstat或ss命令。退出容器输入exit在宿主机上我们可以直接查看所有容器的网络连接情况这有时比进入容器看更全面。# 在宿主机上执行 sudo netstat -tunlp | grep -E ‘(ESTABLISHED|LISTEN)’ # 或者使用更现代的 ss 命令 sudo ss -tunlp重点关注异常的出站连接。反弹Shell是服务器主动连接攻击者的控制端所以你会看到一个从服务器IP的某个高端口或Web服务进程到外部某个IP的特定端口如4444, 5555的ESTABLISHED状态的TCP连接。在靶场环境中这个外部IP可能就是你的攻击机IP或者另一个容器IP。2. 进程排查反弹Shell会对应一个持续运行的进程。在宿主机上我们可以用pstree或ps auxf以树形结构查看进程寻找可疑的父进程如Web服务器进程apache2或nginx派生出的奇怪子进程比如/bin/bash、/bin/sh、python、perl、ncnetcat等。# 查找与bash、sh、python、perl、nc相关的进程排除掉你自己的终端进程 ps aux | grep -E “(bash|sh|python|perl|nc)” | grep -v grep一个非常重要的注意事项高明的攻击者会进行进程隐藏或伪装。他们可能将反弹Shell的进程名改为一个看起来像系统进程的名字或者使用LD_PRELOAD等注入技术。此时查看/proc目录下进程的详细信息如/proc/PID/exe指向的真实可执行文件/proc/PID/cmdline的完整命令行就非常必要了。这也是为什么我推荐同时使用lsof命令它可以列出指定进程打开的所有文件、网络连接等信息非常全。# 假设你怀疑进程ID为1234的进程 sudo lsof -p 12343.3 内网穿透痕迹挖掘攻击者在获得一个立足点反弹Shell后如果目标服务器处于内网他们下一步往往就是进行内网穿透将内网的服务如数据库、管理后台映射到公网方便自己访问。常见的工具如frp、ngrok、reGeorg等。这类工具的痕迹比反弹Shell更隐蔽但仍有迹可循异常的网络监听端口内网穿透客户端需要在受害服务器上开启一个额外的端口用于接收来自穿透工具服务端的流量。使用netstat -tunlp或ss -tunlp仔细检查所有LISTEN状态的端口看看有没有非系统常规服务如22, 80, 443, 3306的端口在监听。一个在10000以上的随机端口监听TCP连接就非常可疑。新增的陌生进程同上检查进程列表寻找陌生的、持续运行的进程其名称或路径可能包含frp、client、agent等关键词或者就是一个简单的二进制文件放在/tmp、/dev/shm等临时目录下。计划任务Cron与系统服务攻击者为了持久化会把内网穿透客户端配置成系统服务或计划任务。务必检查crontab -l # 查看当前用户的计划任务 sudo crontab -l # 查看root的计划任务 ls -la /etc/cron* /var/spool/cron/crontabs/ # 查看系统cron目录 systemctl list-unit-files --typeservice | grep enabled # 查看所有已启用的服务 ls -la /etc/systemd/system/ # 查看用户定义的系统服务文件系统痕迹在/tmp、/dev/shm、/var/tmp等临时目录以及Web目录的隐蔽子目录下搜索最近创建的、可疑的可执行文件或配置文件。可以使用find命令sudo find / -type f -name “*frp*” -o -name “*ngrok*” 2/dev/null sudo find / -type f -iname “*.ini” -o -iname “*.conf” -o -iname “*.json” 2/dev/null | xargs grep -l “server_addr\|tunnel” 2/dev/null第二条命令是寻找配置文件中含有“server_addr”或“tunnel”等关键词的文件这很可能是穿透工具的配置文件。3.4 日志分析与线索串联日志是溯源的“时间机器”。即使攻击者清理了日志也可能有遗漏或者我们可以从其他系统的日志中找到关联证据。核心日志源检查Web访问日志/var/log/apache2/access.log或/var/log/nginx/access.log。在这里寻找文件上传请求POST到upload.php等、访问可疑WebShell的请求带?cmd参数的GET/POST请求。Web错误日志/var/log/apache2/error.log或/var/log/nginx/error.log。可能记录了一些攻击payload触发的错误信息。系统认证日志/var/log/auth.log。记录所有认证相关事件包括SSH登录成功/失败、sudo提权等。如果攻击者尝试了SSH爆破或登录这里会有记录。历史命令检查用户特别是Web服务用户和root的命令历史。攻击者可能忘了清理。# 查看当前用户的history history # 查看root的history如果在容器内是root或宿主机有权限 sudo cat /root/.bash_history # 查看其他用户如www-data sudo cat /home/www-data/.bash_history 2/dev/null || sudo cat /var/www/.bash_history 2/dev/null日志分析技巧不要被海量日志吓到。使用grep进行关键词过滤是最高效的方法。针对我们已发现的线索进行反向搜索。例如我们发现了反弹Shell连接到的外部IP是192.168.1.100那么就在所有日志里搜索这个IPsudo grep -r “192.168.1.100” /var/log/ 2/dev/null或者我们发现了可疑的WebShell文件/var/www/html/shell.php那么就搜索访问过这个文件的请求sudo grep “shell.php” /var/log/apache2/access.log时间线梳理将各个线索文件创建时间、进程启动时间、网络连接建立时间、日志记录时间按照时间顺序排列可以清晰地还原出攻击链条何时通过何种方式上传漏洞上传了什么文件WebShell何时执行了该WebShell建立了何种连接反弹Shell何时下载并运行了什么工具内网穿透客户端进行何种操作端口转发。4. 常用排查命令与工具速查在实际应急响应中时间紧迫记住所有命令不现实。我整理了一个速查表涵盖了从信息收集到深度分析的关键命令你可以把它存下来遇到情况时对照使用。4.1 系统信息与用户检查命令作用关键查看点whoami查看当前用户确认执行环境id查看当前用户UID/GID确认权限who -a/w查看当前登录用户有无异常登录会话last/lastb查看成功/失败登录历史异常IP、时间、用户名cat /etc/passwd查看系统所有用户有无新增的陌生用户cat /etc/shadow查看用户密码哈希需root检查密码强度有无空密码sudo cat /etc/sudoers查看sudo权限配置有无普通用户被意外提权4.2 进程与网络深度排查命令作用关键查看点ps aux --sort-%cpu按CPU使用率排序进程消耗资源异常的进程ps aux --sort-%mem按内存使用率排序进程消耗内存异常的进程pstree -p树形显示进程关系可疑的父子进程关系lsof -i列出所有网络连接所有ESTABLISHED/LISTEN连接lsof -i :端口号查看特定端口占用定位监听端口的进程netstat -antp/ss -antp查看TCP连接和进程同lsof -i格式不同ls -la /proc/PID/exe查看进程真实执行文件进程是否被替换cat /proc/PID/cmdline查看进程完整命令行隐藏的命令行参数4.3 文件系统与日志审查命令作用关键查看点find / -type f -mtime -1查找1天内修改的文件快速定位近期活动find / -type f -name “*.php” -exec grep -l “eval|assert” {} \;查找含危险函数的php文件搜索WebShellfind / -perm -4000 -type f 2/dev/null查找SUID权限文件可能的提权点lsattr /path/to/file查看文件特殊属性有无i不可修改或a只可追加属性保护后门stat /path/to/file查看文件详细属性访问、修改、变更时间journalctl -xe --since “1 hour ago”查看系统日志systemd近期的系统级错误或事件grep -E “FailedInvalidfailure” /var/log/auth.log4.4 自动化与辅助工具除了手动命令一些自动化脚本能极大提升效率。在获得授权的前提下可以在应急响应现场使用。LinPEASLinux本地提权审计脚本功能极其强大能自动检查系统信息、用户、进程、服务、计划任务、SUID文件、文件权限、容器逃逸点等几乎所有常见弱点。直接从GitHub下载运行即可。chkrootkit/rkhunter经典的Rootkit检测工具可以检查系统是否被植入Rootkit。ClamAV开源杀毒引擎可以用来扫描系统中的恶意文件。重要提示在真实应急响应中取证优先。在运行任何自动化工具或进行大量写操作前如果条件允许应先对系统内存和磁盘进行镜像备份以防破坏现场证据。在像“easy溯源”这样的靶场环境中我们可以放开手脚练习。5. 复盘总结与防御思考通过一遍完整的“easy溯源”靶场复现和分析我们实际上模拟了一次小型的应急响应演练。攻击者的路径非常经典Web漏洞利用 - 文件上传获取WebShell - 反弹Shell获得稳定控制 - 内网穿透扩大战果。而我们的溯源过程则是逆向工程从异常现象入手 - 排查网络和进程发现反弹Shell - 搜索文件系统发现攻击工具 - 分析日志还原时间线。我个人在实际操作中的体会是排查时一定要有“发散思维”和“关联思维”。不能只盯着一个点。比如发现了一个可疑进程不仅要看它本身还要看它打开了哪些文件、连接了哪个IP、是哪个父进程启动的、有没有对应的计划任务或服务。多个维度的证据互相印证才能形成牢固的证据链。从防御的角度看这个靶场也给了我们很多启示强化Web安全这是第一道防线。做好输入验证、过滤文件上传、及时更新框架和组件漏洞能挡住大部分自动化攻击。最小权限原则Web服务进程如www-data应该以最低必要权限运行并限制其执行系统命令的能力如禁用危险PHP函数system,exec,shell_exec等。网络隔离与监控对服务器设置严格的出站防火墙规则禁止服务器主动向外发起非常用端口的连接可以有效阻断反弹Shell和内网穿透。同时部署网络IDS/IPS监控异常连接。完善的日志与审计确保所有关键操作登录、文件修改、命令执行等都被记录并将日志集中存储到安全的、攻击者难以触及的日志服务器上。定期审计日志。主机入侵检测可以考虑部署HIDS主机入侵检测系统监控文件完整性、异常进程行为等。最后再分享一个小技巧在分析像“easy溯源”这类靶场时不妨在每一步自己发现痕迹后先不要看官方Writeup尝试自己推测攻击者的下一步行动是什么然后去验证。这种“红队思维”与“蓝队思维”的切换练习能让你对攻防的理解更加深刻。安全之路道阻且长但每一次这样的实战复现都是向前扎实的一步。希望这篇超详细的保姆级教程能成为你路上的有用参考。
1. 项目概述与核心价值最近在安全圈子里一个叫“easy溯源”的靶场热度挺高很多朋友都在讨论。这个靶场模拟的是一个典型的Linux服务器入侵场景核心目标不是让你去攻击而是让你扮演“安全分析师”或“应急响应工程师”的角色去分析攻击者留下的蛛丝马迹完成一次完整的攻击溯源。听起来就很有意思对吧它把反弹Shell、内网穿透、WebShell上传、日志清理这些攻击者常用的“组合拳”都打包在了一个环境里让你能在一个受控的沙箱中亲手触摸到真实的攻击痕迹。我花了点时间在自己的Ubuntu 22.04 LTS系统上完整复现了这个靶场并且把整个分析过程从头到尾捋了一遍。这篇文章我就来当一回“保姆”手把手带你走通从环境搭建到痕迹分析的全过程。无论你是刚入门安全的新手想了解应急响应到底在干什么还是有一定基础想通过实战巩固技能的朋友这篇教程都能给你提供一条清晰的路径。我们不止要“复现”更要深挖每一步“为什么”要这么做以及在实际工作中遇到类似痕迹你的排查思路应该是什么。准备好了吗我们这就开始。2. 环境准备与靶场部署2.1 系统与基础环境配置复现的第一步是准备好我们的“实验台”。我选择的是Ubuntu 22.04 LTS这是一个长期支持版本系统稳定软件源丰富非常适合做这种实验。当然20.04或者更新的版本也完全没问题。关键在于我们需要一个干净的、最好是刚安装好的系统或者至少是一个你确定没有运行其他复杂服务的环境这样可以避免无关进程和日志的干扰。首先确保系统更新到最新并安装一些必要的工具。打开终端执行以下命令sudo apt update sudo apt upgrade -y sudo apt install -y docker.io docker-compose vim curl wget net-tools lsof这里解释一下为什么装这些docker.io和docker-compose这是本次复现的核心。靶场环境通常被打包成Docker镜像用容器技术可以快速搭建、一键还原非常方便。vim一个高效的文本编辑器查看和编辑配置文件必备。curl和wget用于从网络下载文件。net-tools包含netstat等老牌网络工具虽然ss命令更现代但很多场景下netstat的显示格式更直观。lsof列出打开文件的工具在排查进程、端口占用时极其有用。安装完Docker后记得将当前用户加入docker组这样以后就不用每次都sudo了sudo usermod -aG docker $USER操作后需要重新登录系统或开启一个新的终端会话这个改动才会生效。这是一个很容易被忽略的细节很多人加了组后直接操作发现还是权限不够问题就出在这里。2.2 获取与部署“easy溯源”靶场“easy溯源”靶场的具体部署文件通常来自开源社区或一些安全学习平台。由于靶场镜像可能涉及模拟攻击行为务必在你自己可控的虚拟机或隔离环境中进行绝对不要在生产环境或公有云主机上尝试。假设我们已经获取到了靶场的docker-compose.yml文件和相关的Docker镜像。部署过程非常简单创建一个专属目录例如easy_trace并将所有部署文件放入其中。进入该目录运行部署命令。mkdir ~/easy_trace cd ~/easy_trace # 假设你已经把 docker-compose.yml 文件放到了这里 docker-compose up -ddocker-compose up -d这个命令会以后台模式启动所有在配置文件中定义的服务。-d参数代表“detached”即后台运行。执行后你可以用docker-compose ps查看容器是否正常启动。一个关键的实操心得在启动容器后我习惯立刻用docker-compose logs快速扫一眼启动日志看看有没有明显的错误比如端口冲突、依赖服务启动失败等。Ubuntu系统上常见的端口如80、3306MySQL、6379Redis可能被其他软件占用。如果遇到端口冲突你需要修改docker-compose.yml文件中的端口映射规则比如将80:80改为8080:80这样外部就通过8080端口来访问了。等待片刻当所有容器状态显示为“Up”时靶场环境就搭建好了。你可以通过浏览器访问http://你的服务器IP:端口来确认Web服务是否正常。至此我们的“犯罪现场”已经准备就绪接下来就是深入现场开始勘查。3. 攻击痕迹分析与溯源实战靶场启动后它本身已经模拟了一次完整的入侵。我们的任务就是抽丝剥茧找出攻击者干了什么怎么干的。整个分析流程可以遵循一个基本的应急响应顺序先现象后进程和网络再文件与日志最后串联线索。3.1 初始现象与入口点分析通常靶场会给你一些初始提示比如“网站首页被篡改”或“服务器运行异常缓慢”。我们假设第一个发现的异常是网站首页比如index.php被替换成了一句话木马或挑衅语句。首先登录到靶场对应的Web容器内部。我们需要先找到容器的名称或ID。docker ps # 列出所有运行中的容器找到运行Web服务可能是Apache或Nginx的容器记下它的CONTAINER ID或NAMES。然后进入容器docker exec -it 容器ID或名称 /bin/bash进入容器后第一时间检查Web根目录下的文件。以常见的/var/www/html为例cd /var/www/html ls -la重点查看index.php等默认首页文件的修改时间、文件大小和权限。使用cat或head命令快速查看文件内容确认是否被植入恶意代码。这里有一个技巧攻击者为了隐藏可能会将原始文件备份或重命名比如index.php.bak同时留一个看起来正常的index.php作为后门。所以要用ls -la仔细查看所有文件特别是隐藏文件以.开头和最近修改的文件结合ls -lt按时间排序。如果发现可疑文件立即检查其内容。一句话木马通常特征明显如eval($_POST[‘cmd’])或assert($_REQUEST[‘x’])。找到它就找到了第一个确凿的证据也往往是攻击的入口点——很可能是通过文件上传漏洞传上来的。3.2 反弹Shell痕迹排查攻击者获得WebShell后为了获得一个更稳定、功能更完整的交互式Shell通常会尝试反弹Shell。这是内网渗透中非常关键的一步也是我们排查的重点。反弹Shell会在服务器上留下哪些痕迹呢主要是网络连接和进程。1. 网络连接排查即使在容器内我们也可以使用netstat或ss命令。退出容器输入exit在宿主机上我们可以直接查看所有容器的网络连接情况这有时比进入容器看更全面。# 在宿主机上执行 sudo netstat -tunlp | grep -E ‘(ESTABLISHED|LISTEN)’ # 或者使用更现代的 ss 命令 sudo ss -tunlp重点关注异常的出站连接。反弹Shell是服务器主动连接攻击者的控制端所以你会看到一个从服务器IP的某个高端口或Web服务进程到外部某个IP的特定端口如4444, 5555的ESTABLISHED状态的TCP连接。在靶场环境中这个外部IP可能就是你的攻击机IP或者另一个容器IP。2. 进程排查反弹Shell会对应一个持续运行的进程。在宿主机上我们可以用pstree或ps auxf以树形结构查看进程寻找可疑的父进程如Web服务器进程apache2或nginx派生出的奇怪子进程比如/bin/bash、/bin/sh、python、perl、ncnetcat等。# 查找与bash、sh、python、perl、nc相关的进程排除掉你自己的终端进程 ps aux | grep -E “(bash|sh|python|perl|nc)” | grep -v grep一个非常重要的注意事项高明的攻击者会进行进程隐藏或伪装。他们可能将反弹Shell的进程名改为一个看起来像系统进程的名字或者使用LD_PRELOAD等注入技术。此时查看/proc目录下进程的详细信息如/proc/PID/exe指向的真实可执行文件/proc/PID/cmdline的完整命令行就非常必要了。这也是为什么我推荐同时使用lsof命令它可以列出指定进程打开的所有文件、网络连接等信息非常全。# 假设你怀疑进程ID为1234的进程 sudo lsof -p 12343.3 内网穿透痕迹挖掘攻击者在获得一个立足点反弹Shell后如果目标服务器处于内网他们下一步往往就是进行内网穿透将内网的服务如数据库、管理后台映射到公网方便自己访问。常见的工具如frp、ngrok、reGeorg等。这类工具的痕迹比反弹Shell更隐蔽但仍有迹可循异常的网络监听端口内网穿透客户端需要在受害服务器上开启一个额外的端口用于接收来自穿透工具服务端的流量。使用netstat -tunlp或ss -tunlp仔细检查所有LISTEN状态的端口看看有没有非系统常规服务如22, 80, 443, 3306的端口在监听。一个在10000以上的随机端口监听TCP连接就非常可疑。新增的陌生进程同上检查进程列表寻找陌生的、持续运行的进程其名称或路径可能包含frp、client、agent等关键词或者就是一个简单的二进制文件放在/tmp、/dev/shm等临时目录下。计划任务Cron与系统服务攻击者为了持久化会把内网穿透客户端配置成系统服务或计划任务。务必检查crontab -l # 查看当前用户的计划任务 sudo crontab -l # 查看root的计划任务 ls -la /etc/cron* /var/spool/cron/crontabs/ # 查看系统cron目录 systemctl list-unit-files --typeservice | grep enabled # 查看所有已启用的服务 ls -la /etc/systemd/system/ # 查看用户定义的系统服务文件系统痕迹在/tmp、/dev/shm、/var/tmp等临时目录以及Web目录的隐蔽子目录下搜索最近创建的、可疑的可执行文件或配置文件。可以使用find命令sudo find / -type f -name “*frp*” -o -name “*ngrok*” 2/dev/null sudo find / -type f -iname “*.ini” -o -iname “*.conf” -o -iname “*.json” 2/dev/null | xargs grep -l “server_addr\|tunnel” 2/dev/null第二条命令是寻找配置文件中含有“server_addr”或“tunnel”等关键词的文件这很可能是穿透工具的配置文件。3.4 日志分析与线索串联日志是溯源的“时间机器”。即使攻击者清理了日志也可能有遗漏或者我们可以从其他系统的日志中找到关联证据。核心日志源检查Web访问日志/var/log/apache2/access.log或/var/log/nginx/access.log。在这里寻找文件上传请求POST到upload.php等、访问可疑WebShell的请求带?cmd参数的GET/POST请求。Web错误日志/var/log/apache2/error.log或/var/log/nginx/error.log。可能记录了一些攻击payload触发的错误信息。系统认证日志/var/log/auth.log。记录所有认证相关事件包括SSH登录成功/失败、sudo提权等。如果攻击者尝试了SSH爆破或登录这里会有记录。历史命令检查用户特别是Web服务用户和root的命令历史。攻击者可能忘了清理。# 查看当前用户的history history # 查看root的history如果在容器内是root或宿主机有权限 sudo cat /root/.bash_history # 查看其他用户如www-data sudo cat /home/www-data/.bash_history 2/dev/null || sudo cat /var/www/.bash_history 2/dev/null日志分析技巧不要被海量日志吓到。使用grep进行关键词过滤是最高效的方法。针对我们已发现的线索进行反向搜索。例如我们发现了反弹Shell连接到的外部IP是192.168.1.100那么就在所有日志里搜索这个IPsudo grep -r “192.168.1.100” /var/log/ 2/dev/null或者我们发现了可疑的WebShell文件/var/www/html/shell.php那么就搜索访问过这个文件的请求sudo grep “shell.php” /var/log/apache2/access.log时间线梳理将各个线索文件创建时间、进程启动时间、网络连接建立时间、日志记录时间按照时间顺序排列可以清晰地还原出攻击链条何时通过何种方式上传漏洞上传了什么文件WebShell何时执行了该WebShell建立了何种连接反弹Shell何时下载并运行了什么工具内网穿透客户端进行何种操作端口转发。4. 常用排查命令与工具速查在实际应急响应中时间紧迫记住所有命令不现实。我整理了一个速查表涵盖了从信息收集到深度分析的关键命令你可以把它存下来遇到情况时对照使用。4.1 系统信息与用户检查命令作用关键查看点whoami查看当前用户确认执行环境id查看当前用户UID/GID确认权限who -a/w查看当前登录用户有无异常登录会话last/lastb查看成功/失败登录历史异常IP、时间、用户名cat /etc/passwd查看系统所有用户有无新增的陌生用户cat /etc/shadow查看用户密码哈希需root检查密码强度有无空密码sudo cat /etc/sudoers查看sudo权限配置有无普通用户被意外提权4.2 进程与网络深度排查命令作用关键查看点ps aux --sort-%cpu按CPU使用率排序进程消耗资源异常的进程ps aux --sort-%mem按内存使用率排序进程消耗内存异常的进程pstree -p树形显示进程关系可疑的父子进程关系lsof -i列出所有网络连接所有ESTABLISHED/LISTEN连接lsof -i :端口号查看特定端口占用定位监听端口的进程netstat -antp/ss -antp查看TCP连接和进程同lsof -i格式不同ls -la /proc/PID/exe查看进程真实执行文件进程是否被替换cat /proc/PID/cmdline查看进程完整命令行隐藏的命令行参数4.3 文件系统与日志审查命令作用关键查看点find / -type f -mtime -1查找1天内修改的文件快速定位近期活动find / -type f -name “*.php” -exec grep -l “eval|assert” {} \;查找含危险函数的php文件搜索WebShellfind / -perm -4000 -type f 2/dev/null查找SUID权限文件可能的提权点lsattr /path/to/file查看文件特殊属性有无i不可修改或a只可追加属性保护后门stat /path/to/file查看文件详细属性访问、修改、变更时间journalctl -xe --since “1 hour ago”查看系统日志systemd近期的系统级错误或事件grep -E “FailedInvalidfailure” /var/log/auth.log4.4 自动化与辅助工具除了手动命令一些自动化脚本能极大提升效率。在获得授权的前提下可以在应急响应现场使用。LinPEASLinux本地提权审计脚本功能极其强大能自动检查系统信息、用户、进程、服务、计划任务、SUID文件、文件权限、容器逃逸点等几乎所有常见弱点。直接从GitHub下载运行即可。chkrootkit/rkhunter经典的Rootkit检测工具可以检查系统是否被植入Rootkit。ClamAV开源杀毒引擎可以用来扫描系统中的恶意文件。重要提示在真实应急响应中取证优先。在运行任何自动化工具或进行大量写操作前如果条件允许应先对系统内存和磁盘进行镜像备份以防破坏现场证据。在像“easy溯源”这样的靶场环境中我们可以放开手脚练习。5. 复盘总结与防御思考通过一遍完整的“easy溯源”靶场复现和分析我们实际上模拟了一次小型的应急响应演练。攻击者的路径非常经典Web漏洞利用 - 文件上传获取WebShell - 反弹Shell获得稳定控制 - 内网穿透扩大战果。而我们的溯源过程则是逆向工程从异常现象入手 - 排查网络和进程发现反弹Shell - 搜索文件系统发现攻击工具 - 分析日志还原时间线。我个人在实际操作中的体会是排查时一定要有“发散思维”和“关联思维”。不能只盯着一个点。比如发现了一个可疑进程不仅要看它本身还要看它打开了哪些文件、连接了哪个IP、是哪个父进程启动的、有没有对应的计划任务或服务。多个维度的证据互相印证才能形成牢固的证据链。从防御的角度看这个靶场也给了我们很多启示强化Web安全这是第一道防线。做好输入验证、过滤文件上传、及时更新框架和组件漏洞能挡住大部分自动化攻击。最小权限原则Web服务进程如www-data应该以最低必要权限运行并限制其执行系统命令的能力如禁用危险PHP函数system,exec,shell_exec等。网络隔离与监控对服务器设置严格的出站防火墙规则禁止服务器主动向外发起非常用端口的连接可以有效阻断反弹Shell和内网穿透。同时部署网络IDS/IPS监控异常连接。完善的日志与审计确保所有关键操作登录、文件修改、命令执行等都被记录并将日志集中存储到安全的、攻击者难以触及的日志服务器上。定期审计日志。主机入侵检测可以考虑部署HIDS主机入侵检测系统监控文件完整性、异常进程行为等。最后再分享一个小技巧在分析像“easy溯源”这类靶场时不妨在每一步自己发现痕迹后先不要看官方Writeup尝试自己推测攻击者的下一步行动是什么然后去验证。这种“红队思维”与“蓝队思维”的切换练习能让你对攻防的理解更加深刻。安全之路道阻且长但每一次这样的实战复现都是向前扎实的一步。希望这篇超详细的保姆级教程能成为你路上的有用参考。
