1. 项目概述当Linux服务器被“敲门”之后干运维或者安全这行的最怕半夜手机响。不是系统挂了就是服务器被黑了。前者还好说重启大法、回滚备份总有个盼头后者尤其是Linux服务器被入侵那感觉就像家里进了贼你不仅得把他揪出来还得搞清楚他偷了什么、破坏了什么、有没有留后门最后还得把门锁修好。这个过程就是我们常说的“应急响应”。今天要聊的就是针对Linux系统入侵排查的一份实战工作记录也就是圈内人常说的“WP”。这份WP不是纸上谈兵的理论而是基于真实或高度仿真的应急响应场景一步步记录从接到告警到完成初步处置的全过程。它的核心价值在于提供一套可复现、可操作的排查思路和命令集相当于一份“现场勘查指南”。无论你是初入行的安全工程师还是需要兼顾安全的运维人员手头有这样一份详实的WP在真正面对安全事件时心里能稳得多。它帮你理清头绪告诉你先看哪里、用什么命令、怎么分析结果避免在紧急情况下像无头苍蝇一样乱撞。接下来我会结合常见的入侵场景拆解这份Linux入侵排查WP的完整逻辑和实操细节。我们会从最紧急的“止损”动作开始深入到进程、网络、文件、日志等各个维度的蛛丝马迹中最后还会分享一些加固建议和我在实战中踩过的坑。目标很简单让你看完之后能独立完成一次基础的Linux入侵应急响应。2. 应急响应核心流程与首要动作接到服务器可能被入侵的告警后切忌慌张更不要第一时间登录上去就乱删文件或重启系统。鲁莽的操作会破坏现场证据让后续的溯源和分析变得极其困难。一个专业的应急响应必须遵循有序的流程。2.1 应急响应生命周期模型一个完整的应急响应通常包含几个阶段准备、检测、遏制、根除、恢复、总结。我们当前聚焦的“入侵排查”主要覆盖的是“检测”和初步的“遏制”阶段。在开始任何技术操作前必须完成以下管理动作信息收集与确认第一时间联系报告人确认告警来源是IDS/IPS报警、异常流量监控还是业务异常反馈、时间点、受影响的主机IP或域名。尽可能获取更多上下文信息。授权与合规确保你的操作拥有合法授权。如果是客户服务器需获得客户书面或邮件授权如果是公司内部资产需遵循内部安全事件响应流程。组建响应小组如果事件影响重大应立即召集安全、运维、业务负责人成立临时响应小组明确沟通渠道和决策链。完成上述步骤后我们才进入技术排查环节。而技术排查的第一步永远是保护现场收集易失性数据。2.2 现场保护与易失性数据收集系统内存、当前网络连接、进程列表等信息在断电或重启后会丢失这些就是“易失性数据”是入侵者活动最直接的证据。因此登录可疑服务器的第一要务不是杀毒而是取证。登录注意事项避免使用可疑服务器上的已知用户入侵者可能已经替换了ssh、bash等二进制文件或添加了键盘记录器。如果条件允许最好通过带外管理如IPMI、ILO或从已知干净的跳板机使用一次性密钥或临时密码登录。创建隔离的调查环境登录后立即将当前Shell的输入输出记录到文件同时复制一份可信的命令行工具到临时目录备用。# 记录所有后续操作用于审计和复盘 script -a -q /tmp/forensic_log.$(date %Y%m%d%H%M%S).txt # 将/bin下的核心工具拷贝到临时目录防止使用被篡改的命令 mkdir -p /tmp/trusted_bin cp /bin/ps /bin/netstat /bin/lsof /bin/ss /tmp/trusted_bin/ export PATH/tmp/trusted_bin:$PATH关键易失性数据收集命令 以下命令的输出应尽快重定向到文件中并传输到安全的分析平台。系统概况与运行时间uptime who -a lastuptime看负载和运行时间突然的高负载可能意味着加密挖矿。who和last查看当前和近期的登录记录寻找异常IP或用户名。网络连接与监听端口# 优先使用ss它比netstat更高效且不易被木马替换 ss -tulnp # 查看所有TCP/UDP连接 netstat -antup # 查看路由表 route -n # 查看ARP缓存 arp -a重点查看LISTEN状态的端口是否有不熟悉的端口开放如6666,4444,31337等常见后门端口。查看ESTABLISHED连接寻找与可疑IP的通信。进程信息ps auxf # 或更详细的格式 ps -eo pid,ppid,user,ni,pri,pcpu,pmem,vsz,rss,tty,stat,start,time,cmd --forest查看进程树--forest入侵者进程往往会被隐藏或伪装。注意无终端控制的进程?、高CPU/内存占用进程、奇怪进程名如随机字符串、与系统进程名相似但字母被替换。系统内存信息free -h cat /proc/meminfo如果物理内存几乎用尽但Swap使用率不高可能是遇到了消耗内存的恶意软件或攻击。注意在极端情况下高级攻击者会部署“内核级rootkit”能够隐藏进程、网络连接和文件。此时上述命令的输出可能被篡改。需要结合其他手段如使用静态编译的、来自可信介质的取证工具如busybox静态版进行检查或者直接进行内存取证分析。3. 入侵痕迹深度排查四个核心维度收集完易失性数据后我们需要对系统进行更深入的静态分析寻找入侵者留下的持久化痕迹、被篡改的文件以及攻击活动的日志证据。主要从四个维度展开进程与自启动、文件系统、网络与用户、系统日志。3.1 进程与系统自启动项排查入侵者为了保持访问权限一定会设法让自己的恶意进程在系统重启后能自动运行。3.1.1 检查系统服务# Systemd 系统 systemctl list-unit-files --typeservice --stateenabled systemctl list-units --typeservice --staterunning # 重点关注状态为 enabled 和 running 的服务 # 查看某个可疑服务的详细信息 systemctl status suspicious_service_name # 查看服务文件内容 cat /usr/lib/systemd/system/suspicious_service_name.service # 或 cat /etc/systemd/system/suspicious_service_name.service3.1.2 检查经典自启动位置# 检查用户级自启动 (注意替换username) ls -la /home/username/.config/autostart/ ls -la ~/.config/autostart/ # 检查系统级自启动脚本 ls -la /etc/init.d/ ls -la /etc/rc.d/rc[0-6].d/ # 检查 rc.local (虽然很多新系统已不推荐) cat /etc/rc.local # 检查 cron 任务 (重点) crontab -l # 当前用户 crontab -u username -l # 指定用户 ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.monthly/ /etc/cron.weekly/ cat /etc/crontabCron是攻击者最常用的持久化手段之一他们会添加一个每分钟或每几分钟执行的任务用于下载并执行恶意脚本、维持反向Shell等。3.1.3 检查动态链接库劫持检查/etc/ld.so.preload文件如果此文件存在且非空它会在程序启动时优先加载其中指定的库常被用于注入恶意代码。cat /etc/ld.so.preload3.2 文件系统异常排查入侵者会上传工具、篡改系统文件、创建隐藏后门。文件系统排查是体力活也是技术活。3.2.1 查找近期被修改的文件# 查找过去24小时内被修改的文件从根目录开始可能需要sudo find / -type f -mtime -1 2/dev/null | head -50 # 查找过去2小时内被修改的文件 find / -type f -mmin -120 2/dev/null # 更精确地结合时间点。如果知道大概入侵时间比如3天前下午2点 find / -type f -newermt 2023-10-24 14:00 ! -newermt 2023-10-24 15:00 2/dev/null3.2.2 查找可疑文件SUID/SGID文件具有SetUID或SetGID权限的文件运行时可以临时获得文件所有者或组的权限。攻击者可能利用此权限提升为root。find / -type f -perm /6000 2/dev/null检查结果排除已知的合法文件如/bin/passwd,/bin/su。隐藏文件与目录以点开头的文件/目录以及名称异常的文件。find / -name .* -type f 2/dev/null | grep -v /proc\|/sys find / -name *.php -o -name *.jsp -o -name *.war -o -name *.py 2/dev/null | grep -v /usr\|/var/www # 在web目录外寻找web shell查找大文件攻击者可能上传了打包的日志、工具集或挖矿程序。find / -type f -size 50M 2/dev/null | xargs ls -lh3.2.3 检查系统关键文件完整性对比重要二进制文件使用rpm、dpkg等包管理器验证或与干净系统对比哈希值。# CentOS/RHEL rpm -Va | grep ^..5 # Debian/Ubuntu debsums -c重点关注/bin,/sbin,/usr/bin,/usr/sbin下的ls,ps,netstat,ss,find,top等命令是否被替换。检查/etc/passwd和/etc/shadow查看是否有异常用户、UID为0的用户除root外。awk -F: $30 {print $1} /etc/passwd grep -E :/bin/bash|:/bin/sh /etc/passwd3.3 网络与用户活动排查3.3.1 深入分析网络连接使用lsof命令可以查看进程打开的文件和网络连接功能强大。# 查看所有网络连接 lsof -i # 查看某个端口被谁占用 lsof -i:8080 # 查看某个进程的所有网络活动 lsof -p PID3.3.2 检查用户历史与登录# 查看所有用户最近登录情况 lastlog # 查看当前登录用户 w # 查看所有用户的命令历史需root for user in $(ls /home); do echo History for $user ; sudo -u $user tail -n 50 ~/.bash_history 2/dev/null; done # 注意高手会清空.bash_history或设置HISTSIZE0。3.4 系统日志分析寻找攻击者的足迹日志是还原攻击时间线的最重要依据。关键日志文件包括/var/log/auth.log或/var/log/secure认证相关日志记录SSH登录成功/失败、sudo使用等。/var/log/syslog或/var/log/messages系统通用日志。/var/log/audit/audit.log如果开启了auditd审计服务这里有更详细的系统调用记录。/var/log/nginx/access.log或/var/log/apache2/access.logWeb访问日志。/var/log/cronCron任务执行日志。日志分析常用命令# 1. 聚焦SSH暴力破解 grep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -nr | head -20 # 查看成功登录的IP grep Accepted password /var/log/secure | awk {print $11} | sort | uniq -c # 2. 查看某个时间段的日志假设入侵发生在10月25日10点左右 sed -n /Oct 25 09:50:00/,/Oct 25 10:10:00/p /var/log/secure # 3. 使用journalctl (Systemd系统) journalctl --since 2023-10-25 09:00:00 --until 2023-10-25 11:00:00 -u ssh journalctl -k | grep -i error\|warning # 查看内核日志 # 4. 如果日志量巨大可以使用工具如 lnav 或 goaccess (针对web日志)进行交互式分析。4. 典型入侵场景的排查实战理论说再多不如看实战。下面我们模拟两个最常见的入侵场景串联使用上述命令进行排查。4.1 场景一服务器疑似被植入挖矿木马症状CPU使用率长期100%风扇狂转top命令发现一个名为kinsing或kdevtmpfsi的陌生进程占用大量CPU。排查步骤定位进程ps aux | grep -E kinsing|kdevtmpfsi记下PID。查看进程详细信息ls -la /proc/PID/exe # 查看进程的可执行文件路径 cat /proc/PID/cmdline # 查看进程的完整启动命令 ls -la /proc/PID/cwd # 查看进程的工作目录结束进程并删除文件kill -9 PID # 找到文件路径后彻底删除 rm -f /tmp/kinsing /var/tmp/kdevtmpfsi # 挖矿木马通常有守护进程和多个相关文件需仔细查找 find / -name *kinsing* -o -name *kdevtmpfsi* 2/dev/null检查持久化# 检查cron crontab -l cat /etc/crontab ls /etc/cron.d/ # 检查systemd服务 systemctl list-unit-files | grep -i miner # 检查特定用户的定时任务 ls /var/spool/cron/crontabs/挖矿木马几乎一定会通过cron或systemd实现持久化。清理持久化项# 删除cron任务 crontab -r # 删除当前用户的cron谨慎确认是恶意任务 # 或编辑crontab文件删除对应行 # 删除systemd服务文件并重载 systemctl stop malicious_service systemctl disable malicious_service rm /etc/systemd/system/malicious_service.service systemctl daemon-reload4.2 场景二网站被上传WebShell症状网站出现异常内容流量异常服务器上发现陌生.php或.jsp文件。排查步骤定位Web目录确定网站根目录如/var/www/html,/usr/share/nginx/html。查找可疑Web文件# 查找最近修改的php文件 find /var/www/html -name *.php -mtime -1 # 查找包含特定危险函数的文件如eval, system, shell_exec grep -r eval\|system\|shell_exec\|passthru\|pcntl_exec /var/www/html --include*.php # 查找文件大小异常的小文件WebShell通常不大 find /var/www/html -type f -size -10k -name *.php | xargs ls -lh分析Web访问日志# 在nginx/apache日志中寻找上传行为 grep POST.*upload\|POST.*\.php /var/log/nginx/access.log | tail -50 # 寻找访问可疑文件的记录 grep shell\.php\|cmd\.php\|wso\.php /var/log/nginx/access.log # 寻找攻击者IP grep shell.php /var/log/nginx/access.log | awk {print $1} | sort -u检查文件权限# Web目录不应有777权限 find /var/www/html -type d -perm 777 find /var/www/html -type f -perm 666Web目录和文件权限过松是导致被上传WebShell的常见原因。处置删除WebShell文件修补导致上传的漏洞如文件上传功能未校验、CMS漏洞重置相关数据库密码并清理可能被篡改的网页文件。5. 排查后的加固与反思完成入侵排查和初步清理后工作只完成了一半。必须进行系统加固防止再次被同一方式入侵并总结事件。5.1 立即加固措施更新与升级立即更新所有软件包尤其是已知存在漏洞的组件。# CentOS/RHEL yum update -y # Debian/Ubuntu apt update apt upgrade -y修改密码更改所有用户密码特别是root和具有sudo权限的用户。检查/etc/passwd和/etc/shadow删除无用账户。加固SSH禁用root直接登录PermitRootLogin no禁用密码认证改用密钥对PasswordAuthentication no修改默认端口Port 2222使用AllowUsers限制可登录用户。重启ssh服务systemctl restart sshd配置防火墙使用firewalld或iptables只开放必要的端口。# firewalld 示例 firewall-cmd --permanent --remove-servicessh # 移除默认ssh服务对应22端口 firewall-cmd --permanent --add-port2222/tcp # 添加新端口 firewall-cmd --permanent --add-servicehttp --add-servicehttps firewall-cmd --reload安装并配置入侵检测系统如fail2ban防暴力破解、rkhunter/chkrootkitRootkit检测、lynis安全审计扫描。5.2 建立持续监控与响应机制集中化日志使用rsyslog或syslog-ng将重要日志发送到独立的日志服务器避免攻击者擦除本地日志。部署HIDS考虑部署基于主机的入侵检测系统如OSSEC、Wazuh能够监控文件完整性、异常登录、可疑进程等。定期安全扫描使用Nessus,OpenVAS等工具定期进行漏洞扫描。制定并演练应急预案让团队熟悉响应流程定期进行红蓝对抗演练。5.3 个人实操心得与避坑指南保持冷静先取证后处置这是铁律。慌乱中重启服务器内存证据就全没了。任何删除、停止操作前先保存好证据命令输出、文件副本、内存镜像。不要完全信任受害系统攻击者可能替换了ps、netstat、ls等命令。使用事先准备好的静态编译工具或从光盘等只读介质启动进行排查是最可靠的方式。时间线是关键将收集到的各种日志系统日志、Web日志、命令历史按时间排序能清晰还原攻击路径。auditd审计日志在这方面价值巨大建议在重要服务器上启用。假设失陷范围更大不要以为只找到一处后门就万事大吉。攻击者常采用“打点-横向移动”的策略。检查同一网段的其他机器检查数据库、缓存等关联服务。善用自动化脚本但不依赖网上有很多应急响应检查脚本如linux-check.sh可以快速给出检查结果。但它们只是辅助工具不能替代人工分析。脚本可能过时也可能被rootkit绕过。理解每条命令背后的原理更重要。沟通与记录整个响应过程所有操作、发现、决策都要详细记录。这既是事后写报告的需要也是团队协作和知识沉淀的关键。入侵排查就像侦探破案需要耐心、细心和系统的思维。每一次应急响应都是对系统安全状况的一次深度体检也是提升个人技术能力的绝佳机会。把这份WP的思路和命令变成你的肌肉记忆当下一次警报响起时你就能从容应对。
1. 项目概述当Linux服务器被“敲门”之后干运维或者安全这行的最怕半夜手机响。不是系统挂了就是服务器被黑了。前者还好说重启大法、回滚备份总有个盼头后者尤其是Linux服务器被入侵那感觉就像家里进了贼你不仅得把他揪出来还得搞清楚他偷了什么、破坏了什么、有没有留后门最后还得把门锁修好。这个过程就是我们常说的“应急响应”。今天要聊的就是针对Linux系统入侵排查的一份实战工作记录也就是圈内人常说的“WP”。这份WP不是纸上谈兵的理论而是基于真实或高度仿真的应急响应场景一步步记录从接到告警到完成初步处置的全过程。它的核心价值在于提供一套可复现、可操作的排查思路和命令集相当于一份“现场勘查指南”。无论你是初入行的安全工程师还是需要兼顾安全的运维人员手头有这样一份详实的WP在真正面对安全事件时心里能稳得多。它帮你理清头绪告诉你先看哪里、用什么命令、怎么分析结果避免在紧急情况下像无头苍蝇一样乱撞。接下来我会结合常见的入侵场景拆解这份Linux入侵排查WP的完整逻辑和实操细节。我们会从最紧急的“止损”动作开始深入到进程、网络、文件、日志等各个维度的蛛丝马迹中最后还会分享一些加固建议和我在实战中踩过的坑。目标很简单让你看完之后能独立完成一次基础的Linux入侵应急响应。2. 应急响应核心流程与首要动作接到服务器可能被入侵的告警后切忌慌张更不要第一时间登录上去就乱删文件或重启系统。鲁莽的操作会破坏现场证据让后续的溯源和分析变得极其困难。一个专业的应急响应必须遵循有序的流程。2.1 应急响应生命周期模型一个完整的应急响应通常包含几个阶段准备、检测、遏制、根除、恢复、总结。我们当前聚焦的“入侵排查”主要覆盖的是“检测”和初步的“遏制”阶段。在开始任何技术操作前必须完成以下管理动作信息收集与确认第一时间联系报告人确认告警来源是IDS/IPS报警、异常流量监控还是业务异常反馈、时间点、受影响的主机IP或域名。尽可能获取更多上下文信息。授权与合规确保你的操作拥有合法授权。如果是客户服务器需获得客户书面或邮件授权如果是公司内部资产需遵循内部安全事件响应流程。组建响应小组如果事件影响重大应立即召集安全、运维、业务负责人成立临时响应小组明确沟通渠道和决策链。完成上述步骤后我们才进入技术排查环节。而技术排查的第一步永远是保护现场收集易失性数据。2.2 现场保护与易失性数据收集系统内存、当前网络连接、进程列表等信息在断电或重启后会丢失这些就是“易失性数据”是入侵者活动最直接的证据。因此登录可疑服务器的第一要务不是杀毒而是取证。登录注意事项避免使用可疑服务器上的已知用户入侵者可能已经替换了ssh、bash等二进制文件或添加了键盘记录器。如果条件允许最好通过带外管理如IPMI、ILO或从已知干净的跳板机使用一次性密钥或临时密码登录。创建隔离的调查环境登录后立即将当前Shell的输入输出记录到文件同时复制一份可信的命令行工具到临时目录备用。# 记录所有后续操作用于审计和复盘 script -a -q /tmp/forensic_log.$(date %Y%m%d%H%M%S).txt # 将/bin下的核心工具拷贝到临时目录防止使用被篡改的命令 mkdir -p /tmp/trusted_bin cp /bin/ps /bin/netstat /bin/lsof /bin/ss /tmp/trusted_bin/ export PATH/tmp/trusted_bin:$PATH关键易失性数据收集命令 以下命令的输出应尽快重定向到文件中并传输到安全的分析平台。系统概况与运行时间uptime who -a lastuptime看负载和运行时间突然的高负载可能意味着加密挖矿。who和last查看当前和近期的登录记录寻找异常IP或用户名。网络连接与监听端口# 优先使用ss它比netstat更高效且不易被木马替换 ss -tulnp # 查看所有TCP/UDP连接 netstat -antup # 查看路由表 route -n # 查看ARP缓存 arp -a重点查看LISTEN状态的端口是否有不熟悉的端口开放如6666,4444,31337等常见后门端口。查看ESTABLISHED连接寻找与可疑IP的通信。进程信息ps auxf # 或更详细的格式 ps -eo pid,ppid,user,ni,pri,pcpu,pmem,vsz,rss,tty,stat,start,time,cmd --forest查看进程树--forest入侵者进程往往会被隐藏或伪装。注意无终端控制的进程?、高CPU/内存占用进程、奇怪进程名如随机字符串、与系统进程名相似但字母被替换。系统内存信息free -h cat /proc/meminfo如果物理内存几乎用尽但Swap使用率不高可能是遇到了消耗内存的恶意软件或攻击。注意在极端情况下高级攻击者会部署“内核级rootkit”能够隐藏进程、网络连接和文件。此时上述命令的输出可能被篡改。需要结合其他手段如使用静态编译的、来自可信介质的取证工具如busybox静态版进行检查或者直接进行内存取证分析。3. 入侵痕迹深度排查四个核心维度收集完易失性数据后我们需要对系统进行更深入的静态分析寻找入侵者留下的持久化痕迹、被篡改的文件以及攻击活动的日志证据。主要从四个维度展开进程与自启动、文件系统、网络与用户、系统日志。3.1 进程与系统自启动项排查入侵者为了保持访问权限一定会设法让自己的恶意进程在系统重启后能自动运行。3.1.1 检查系统服务# Systemd 系统 systemctl list-unit-files --typeservice --stateenabled systemctl list-units --typeservice --staterunning # 重点关注状态为 enabled 和 running 的服务 # 查看某个可疑服务的详细信息 systemctl status suspicious_service_name # 查看服务文件内容 cat /usr/lib/systemd/system/suspicious_service_name.service # 或 cat /etc/systemd/system/suspicious_service_name.service3.1.2 检查经典自启动位置# 检查用户级自启动 (注意替换username) ls -la /home/username/.config/autostart/ ls -la ~/.config/autostart/ # 检查系统级自启动脚本 ls -la /etc/init.d/ ls -la /etc/rc.d/rc[0-6].d/ # 检查 rc.local (虽然很多新系统已不推荐) cat /etc/rc.local # 检查 cron 任务 (重点) crontab -l # 当前用户 crontab -u username -l # 指定用户 ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.monthly/ /etc/cron.weekly/ cat /etc/crontabCron是攻击者最常用的持久化手段之一他们会添加一个每分钟或每几分钟执行的任务用于下载并执行恶意脚本、维持反向Shell等。3.1.3 检查动态链接库劫持检查/etc/ld.so.preload文件如果此文件存在且非空它会在程序启动时优先加载其中指定的库常被用于注入恶意代码。cat /etc/ld.so.preload3.2 文件系统异常排查入侵者会上传工具、篡改系统文件、创建隐藏后门。文件系统排查是体力活也是技术活。3.2.1 查找近期被修改的文件# 查找过去24小时内被修改的文件从根目录开始可能需要sudo find / -type f -mtime -1 2/dev/null | head -50 # 查找过去2小时内被修改的文件 find / -type f -mmin -120 2/dev/null # 更精确地结合时间点。如果知道大概入侵时间比如3天前下午2点 find / -type f -newermt 2023-10-24 14:00 ! -newermt 2023-10-24 15:00 2/dev/null3.2.2 查找可疑文件SUID/SGID文件具有SetUID或SetGID权限的文件运行时可以临时获得文件所有者或组的权限。攻击者可能利用此权限提升为root。find / -type f -perm /6000 2/dev/null检查结果排除已知的合法文件如/bin/passwd,/bin/su。隐藏文件与目录以点开头的文件/目录以及名称异常的文件。find / -name .* -type f 2/dev/null | grep -v /proc\|/sys find / -name *.php -o -name *.jsp -o -name *.war -o -name *.py 2/dev/null | grep -v /usr\|/var/www # 在web目录外寻找web shell查找大文件攻击者可能上传了打包的日志、工具集或挖矿程序。find / -type f -size 50M 2/dev/null | xargs ls -lh3.2.3 检查系统关键文件完整性对比重要二进制文件使用rpm、dpkg等包管理器验证或与干净系统对比哈希值。# CentOS/RHEL rpm -Va | grep ^..5 # Debian/Ubuntu debsums -c重点关注/bin,/sbin,/usr/bin,/usr/sbin下的ls,ps,netstat,ss,find,top等命令是否被替换。检查/etc/passwd和/etc/shadow查看是否有异常用户、UID为0的用户除root外。awk -F: $30 {print $1} /etc/passwd grep -E :/bin/bash|:/bin/sh /etc/passwd3.3 网络与用户活动排查3.3.1 深入分析网络连接使用lsof命令可以查看进程打开的文件和网络连接功能强大。# 查看所有网络连接 lsof -i # 查看某个端口被谁占用 lsof -i:8080 # 查看某个进程的所有网络活动 lsof -p PID3.3.2 检查用户历史与登录# 查看所有用户最近登录情况 lastlog # 查看当前登录用户 w # 查看所有用户的命令历史需root for user in $(ls /home); do echo History for $user ; sudo -u $user tail -n 50 ~/.bash_history 2/dev/null; done # 注意高手会清空.bash_history或设置HISTSIZE0。3.4 系统日志分析寻找攻击者的足迹日志是还原攻击时间线的最重要依据。关键日志文件包括/var/log/auth.log或/var/log/secure认证相关日志记录SSH登录成功/失败、sudo使用等。/var/log/syslog或/var/log/messages系统通用日志。/var/log/audit/audit.log如果开启了auditd审计服务这里有更详细的系统调用记录。/var/log/nginx/access.log或/var/log/apache2/access.logWeb访问日志。/var/log/cronCron任务执行日志。日志分析常用命令# 1. 聚焦SSH暴力破解 grep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -nr | head -20 # 查看成功登录的IP grep Accepted password /var/log/secure | awk {print $11} | sort | uniq -c # 2. 查看某个时间段的日志假设入侵发生在10月25日10点左右 sed -n /Oct 25 09:50:00/,/Oct 25 10:10:00/p /var/log/secure # 3. 使用journalctl (Systemd系统) journalctl --since 2023-10-25 09:00:00 --until 2023-10-25 11:00:00 -u ssh journalctl -k | grep -i error\|warning # 查看内核日志 # 4. 如果日志量巨大可以使用工具如 lnav 或 goaccess (针对web日志)进行交互式分析。4. 典型入侵场景的排查实战理论说再多不如看实战。下面我们模拟两个最常见的入侵场景串联使用上述命令进行排查。4.1 场景一服务器疑似被植入挖矿木马症状CPU使用率长期100%风扇狂转top命令发现一个名为kinsing或kdevtmpfsi的陌生进程占用大量CPU。排查步骤定位进程ps aux | grep -E kinsing|kdevtmpfsi记下PID。查看进程详细信息ls -la /proc/PID/exe # 查看进程的可执行文件路径 cat /proc/PID/cmdline # 查看进程的完整启动命令 ls -la /proc/PID/cwd # 查看进程的工作目录结束进程并删除文件kill -9 PID # 找到文件路径后彻底删除 rm -f /tmp/kinsing /var/tmp/kdevtmpfsi # 挖矿木马通常有守护进程和多个相关文件需仔细查找 find / -name *kinsing* -o -name *kdevtmpfsi* 2/dev/null检查持久化# 检查cron crontab -l cat /etc/crontab ls /etc/cron.d/ # 检查systemd服务 systemctl list-unit-files | grep -i miner # 检查特定用户的定时任务 ls /var/spool/cron/crontabs/挖矿木马几乎一定会通过cron或systemd实现持久化。清理持久化项# 删除cron任务 crontab -r # 删除当前用户的cron谨慎确认是恶意任务 # 或编辑crontab文件删除对应行 # 删除systemd服务文件并重载 systemctl stop malicious_service systemctl disable malicious_service rm /etc/systemd/system/malicious_service.service systemctl daemon-reload4.2 场景二网站被上传WebShell症状网站出现异常内容流量异常服务器上发现陌生.php或.jsp文件。排查步骤定位Web目录确定网站根目录如/var/www/html,/usr/share/nginx/html。查找可疑Web文件# 查找最近修改的php文件 find /var/www/html -name *.php -mtime -1 # 查找包含特定危险函数的文件如eval, system, shell_exec grep -r eval\|system\|shell_exec\|passthru\|pcntl_exec /var/www/html --include*.php # 查找文件大小异常的小文件WebShell通常不大 find /var/www/html -type f -size -10k -name *.php | xargs ls -lh分析Web访问日志# 在nginx/apache日志中寻找上传行为 grep POST.*upload\|POST.*\.php /var/log/nginx/access.log | tail -50 # 寻找访问可疑文件的记录 grep shell\.php\|cmd\.php\|wso\.php /var/log/nginx/access.log # 寻找攻击者IP grep shell.php /var/log/nginx/access.log | awk {print $1} | sort -u检查文件权限# Web目录不应有777权限 find /var/www/html -type d -perm 777 find /var/www/html -type f -perm 666Web目录和文件权限过松是导致被上传WebShell的常见原因。处置删除WebShell文件修补导致上传的漏洞如文件上传功能未校验、CMS漏洞重置相关数据库密码并清理可能被篡改的网页文件。5. 排查后的加固与反思完成入侵排查和初步清理后工作只完成了一半。必须进行系统加固防止再次被同一方式入侵并总结事件。5.1 立即加固措施更新与升级立即更新所有软件包尤其是已知存在漏洞的组件。# CentOS/RHEL yum update -y # Debian/Ubuntu apt update apt upgrade -y修改密码更改所有用户密码特别是root和具有sudo权限的用户。检查/etc/passwd和/etc/shadow删除无用账户。加固SSH禁用root直接登录PermitRootLogin no禁用密码认证改用密钥对PasswordAuthentication no修改默认端口Port 2222使用AllowUsers限制可登录用户。重启ssh服务systemctl restart sshd配置防火墙使用firewalld或iptables只开放必要的端口。# firewalld 示例 firewall-cmd --permanent --remove-servicessh # 移除默认ssh服务对应22端口 firewall-cmd --permanent --add-port2222/tcp # 添加新端口 firewall-cmd --permanent --add-servicehttp --add-servicehttps firewall-cmd --reload安装并配置入侵检测系统如fail2ban防暴力破解、rkhunter/chkrootkitRootkit检测、lynis安全审计扫描。5.2 建立持续监控与响应机制集中化日志使用rsyslog或syslog-ng将重要日志发送到独立的日志服务器避免攻击者擦除本地日志。部署HIDS考虑部署基于主机的入侵检测系统如OSSEC、Wazuh能够监控文件完整性、异常登录、可疑进程等。定期安全扫描使用Nessus,OpenVAS等工具定期进行漏洞扫描。制定并演练应急预案让团队熟悉响应流程定期进行红蓝对抗演练。5.3 个人实操心得与避坑指南保持冷静先取证后处置这是铁律。慌乱中重启服务器内存证据就全没了。任何删除、停止操作前先保存好证据命令输出、文件副本、内存镜像。不要完全信任受害系统攻击者可能替换了ps、netstat、ls等命令。使用事先准备好的静态编译工具或从光盘等只读介质启动进行排查是最可靠的方式。时间线是关键将收集到的各种日志系统日志、Web日志、命令历史按时间排序能清晰还原攻击路径。auditd审计日志在这方面价值巨大建议在重要服务器上启用。假设失陷范围更大不要以为只找到一处后门就万事大吉。攻击者常采用“打点-横向移动”的策略。检查同一网段的其他机器检查数据库、缓存等关联服务。善用自动化脚本但不依赖网上有很多应急响应检查脚本如linux-check.sh可以快速给出检查结果。但它们只是辅助工具不能替代人工分析。脚本可能过时也可能被rootkit绕过。理解每条命令背后的原理更重要。沟通与记录整个响应过程所有操作、发现、决策都要详细记录。这既是事后写报告的需要也是团队协作和知识沉淀的关键。入侵排查就像侦探破案需要耐心、细心和系统的思维。每一次应急响应都是对系统安全状况的一次深度体检也是提升个人技术能力的绝佳机会。把这份WP的思路和命令变成你的肌肉记忆当下一次警报响起时你就能从容应对。
 获取与实战)
双梁正问题 【 torch 实战】（Python代码实现）)
