1. 为什么运维老手的安全排查命令清单值得你抄一遍先说一个反直觉的结论在安全事件发生的时候真正能救命的往往不是各种商业扫描器也不是图形化管理平台反而是你手头这一台Linux服务器上自带的那些不起眼的命令。我见过太多次这样的场景了——某公司的一台业务服务器深夜告警CPU直接飙到100%业务方急得跺脚。运维A打开商业监控平台拉了一堆图表越看越迷糊运维B只是不慌不忙地登进服务器敲了一条ps -ef、一条ss -anp五分钟内就定位到是哪一个进程在和哪一台外部主机通信。差距就在这儿工具只能告诉你出事了而命令能告诉你到底是谁干的、现在在哪、下一步应该看什么。这款网络安全常用Linux命令大全本质上就是把这些能直接定位问题的命令整理成了一份可查、可抄、可练的清单。它解决的核心痛点是很多运维或者初级安全工程师遇到异常时脑子里一团浆糊不知道该先看哪里、后看哪里甚至不知道该用哪条命令去探查什么维度的信息。我自己早期也吃过这个亏——明明lastb就在那里我却要手动一行行翻/var/log/auth.log浪费了大量黄金排查时间。所以这篇内容适合这几类读者刚接手服务器运维、对安全日志还不太敏感的普通运维想要补足Linux排查基础、为后面做安全防护打地基的测试开发同学以及那些接了监控告警但不知道下一步怎么落地的值班工程师。我挑选命令的标准很简单场景驱动——不是把所有命令罗列一遍就完事而是每一条命令都能对应到一个真实的安全排查场景比如疑似被爆破登录CPU突然打满发现陌生端口在监听登录记录被人删了等等。下面这份清单全部基于我日常维护真实业务服务器时踩过的坑、用过的招。没有花哨的东西每一条拿出来都能直接落到终端上去跑。2. 系统异常时的第一反应从进程和资源里找蛛丝马迹服务器异常第一现场永远是系统资源。CPU被打满、内存被吃光、负载居高不下——表面上看着是性能问题但相当比例其实是安全事件的马脚。攻击者拿到权限之后最常做的事之一就是跑挖矿木马或者搭代理这些程序都是吃CPU的大户。2.1 top和ps的进阶用法不只看还得会看很多人用top就是进去看一眼就退出其实top在排查安全问题时有几个非常实用的交互操作进入top后按P键按CPU占用率降序排列按M键按内存占用率降序排列。这一步能快速把最可疑的进程揪到最前面。按c键可以展示进程的完整命令行路径避免一堆截断路径迷惑视线。按H键可以切换到线程视图对多线程应用排查特别有用——有些木马是通过单线程占满单个核心的进程级别看起来不高切到线程视角就原形毕露。但如果要留证据、写报告top的交互界面就不够用了。这时候ps才是做记录的利器# 按CPU使用率降序查最耗CPU的前20个进程 ps aux --sort-%cpu | head -20 # 按内存使用率降序查最耗内存的前20个进程 ps aux --sort-%mem | head -20 # 查看某个PID的完整启动命令注意环境变量也能看到 cat /proc/1357/cmdline | tr \0 # 查看某个PID的可执行文件真实路径 ls -l /proc/1357/exe这里重点说下最后两条。/proc/1357/cmdline和/proc/1357/exe是我在排查中几乎必看的东西。为什么因为恶意程序非常喜欢伪装进程名——你看到进程列表里挂着一个java或者nginx以为是自己人的服务实际上可执行文件真实路径是/tmp/.X11-unix/xxx这就有问题了。/proc/[PID]/exe会直接带你找到它真正跑起来的二进制文件这一招能戳穿九成以上的进程伪装。还有一个细节很多木马会在命令行参数里做手脚比如-c参数后面跟一大段混淆过的命令。ps查看时如果命令行特别长、特别怪、充斥着Base64片段基本可以判定不是正常业务进程立刻ls -l /proc/[PID]/exe确认。2.2 谁动了我的CPU一次疑似挖矿的排查思路分享一个实际场景。某公司的一台闲置测试机突然CPU跑满值班同学看着很迷茫不知道从哪查起。我的排查链路是固定的第一步确认现象uptime看load average是不是明显高于CPU核心数。如果1分钟负载是5、15分钟负载是1说明事情是最近才发生的大概率是新启动的恶意进程。第二步找元凶ps aux --sort-%cpu | head -5看到一个陌生的kdevtmpfsi进程乍一看名字还挺像系统进程但这名字其实是常见挖矿木马的特征。进入/proc看它的启动来源ls -l /proc/[PID]/exe ls -la /proc/[PID]/cwd cat /proc/[PID]/cmdline | tr \0 第三步查关联ls -l /proc/[PID]/fd | head -20 cat /proc/[PID]/maps | head -20通过文件描述符能看出它打开了哪些文件通过内存映射可以初步判断二进制是否被加密或注入过。这一套组合拳打下来恶意进程基本无从遁形。2.3 load average和CPU状态的准确解读load average三个数字是多数人最不会看的指标。记住一句话它反映的是等待队列中的进程数不是CPU利用率。所以即使你的CPU利用率只有30%只要大量进程处于不可中断睡眠比如在等磁盘I/O负载照样能冲到很高。排查安全问题时还需要分开看CPU的几项指标us用户态占用突然升高配合陌生进程排查多半是应用层有问题sy系统态占用异常升高有可能是内核层面被注入或驱动异常waI/O等待居高不下不一定是安全问题可能是磁盘坏了或日志疯狂写入——而日志疯狂写入本身也可能因为某个死循环进程排查命令是top -bn1 | grep Cpu(s)-b是批处理模式-n1是只采样一次适合在脚本里抓CPU状态。我建议运维同学练好这一条安全巡检脚本里非常常用。3. 日志审计还原事故现场最重要的证据链很多新手处理安全事件时第一反应是先杀进程、改密码这是大忌。进程可以死、服务可以停、IP可以封但日志一旦被覆盖或者你没来得及留存这个事故就永远讲不清了。正确的顺序一定是先保全证据再处理问题。3.1 关键日志文件优先级先看这几个基本够用Linux系统上的日志文件分布在/var/log/目录下但并不是每个文件都同等重要。按照安全排查的优先级我的阅读顺序是这样日志文件作用什么时候必须看/var/log/auth.log登录认证日志Debian系核心怀疑被爆破、账号登录异常/var/log/secure登录认证日志RedHat系核心同上CentOS等系统用这个/var/log/syslog系统整体运行日志Debian系应用崩溃、系统级异常/var/log/messages系统整体运行日志RedHat系同上/var/log/cron计划任务执行日志怀疑被写了定时任务后门/var/log/btmp错误登录日志二进制查看暴力破解记录/var/log/wtmp已登录用户日志二进制查看历史上谁登录过一个常见的误区是把/var/log/messages当万能日志。实际上很多应用的日志输出到syslog之后会被企业自建日志平台采集本机的messages往往不全。排查安全问题时先确认系统的日志服务是rsyslog还是journaldsystemctl status rsyslog systemctl status systemd-journald如果是CentOS 7或者现在的Ubuntu版本journald默认是启用的这时候journalctl命令比翻/var/log日志文件更靠谱# 查看今天的全部系统日志 journalctl --since today # 查看某个时间段内的日志 journalctl --since 2026-02-18 00:00:00 --until 2026-02-18 06:00:00 # 查看某个PID的所有日志 journalctl _PID1357 # 查看SSH服务的全部日志 journalctl -u sshdjournalctl的好处是自动关联了时间、用户、服务名排查的时候直接按PID过滤信息链是完整的比自己在文本里grep半天高效得多。3.2 SSH登录审计last、lastb、auth.log的组合用法SSH暴力破解是互联网上最常见的攻击类型几乎每一台暴露到公网的服务器每天都会收到大量尝试。审计登录行为的命令组合是我要求自己团队所有人都要背下来的# 最近成功登录的记录 last -20 # 最近失败登录的记录暴力破解看这个 lastb -20 # 查看utmp格式的当前登录用户 wholast读的是/var/log/wtmplastb读的是/var/log/btmp。这两个文件都是二进制格式直接cat是乱码必须通过这些命令去看。lastb的输出会直接列出尝试登录的用户名和来源IP。如果看到同一个IP在反复尝试不同用户名基本可以判定是自动化扫描程序。确认攻击者行为后接下来要深挖auth.log的细节# 查看今天认证相关的全部日志 grep Failed password /var/log/auth.log | tail -50 # 查看某个攻击IP的完整动作链 grep 192.0.2.66 /var/log/auth.log # 查看被接受的公钥登录可能是攻击者植入了自己的密钥 grep Accepted publickey /var/log/auth.log # 查看账号创建相关记录 grep useradd /var/log/auth.log这里有个细节必须注意攻击者拿到权限后往往会清理登录痕迹——删/var/log/btmp、删/var/log/auth.log。但journald的日志如果没被权限覆盖journalctl仍然能查到记录。所以遇到攻击者清痕的迹象时优先journalctl去拉记录不要指望文本日志还在。3.3 命令历史与用户行为追踪从history和时间线找异常每个用户家目录下的.bash_history是另一条重要的证据线。攻击者执行过的命令会在这里留下痕迹前提是没被清理。不过有几个实用小技巧# 查看某个用户的历史命令例如临时账户 cat /home/username/.bash_history # 历史命令带时间戳默认不记录时间需要环境变量支持 export HISTTIMEFORMAT%F %T 如果系统还没配置HISTTIMEFORMAT顺手建议在/etc/profile.d/history.sh里加上这段export HISTTIMEFORMAT%F %T export HISTSIZE10000 export HISTFILESIZE10000这样后续所有用户的历史命令都会带时间戳对事后回溯帮助极大。另外很多人忘了看root的历史命令以外的隐藏文件。攻击者喜欢把自己的操作脚本放在/tmp目录或者家目录下的隐藏目录里所以排查时可以顺手看看这些位置ls -la /tmp | head -50 ls -la /home/*/.* | grep -v .bash find / -name *.sh -mtime -3 -type f 2/dev/nullfind按修改时间查最近3天内被创建或修改的脚本是我在排查中非常依赖的手段经常能找出攻击者留下的下载脚本或者横向移动工具。4. 网络连接与监听端口快速定位异常通信进程只是现象网络通信才是本质。任何被攻陷的机器几乎都会产生外连行为——不是把数据传出去就是接收攻击者控制指令。所以看网络连接是判断机器是否失陷的关键一环。4.1 ss命令的现代用法netstat的替代者很多人还停留在netstat -an但现在的Linux发行版已经默认不带netstat了需要单独装net-tools。而ss命令不仅原生自带性能更好、信息更全是当之无愧的现代替代方案# 查看所有TCP连接 ss -anpt # 查看所有监听端口 ss -lntp # 查看所有UDP连接 ss -anup参数含义解释下-a表示所有连接包括监听和已建立-n表示不做域名解析直接显示IP不做解析速度会快很多-p表示显示进程信息-t只显示TCP-u只显示UDP-l只显示监听端口。我几乎每次都带上-p因为纯粹看连接没有任何意义关键是把端口和进程关联起来。如果不带-p你看到一个陌生端口连接还得再执行一条命令去查进程浪费时间。# 手动关联端口和进程如果不小心没加-p lsof -i :80804.2 连接数统计识别扫描和暴力破解的常用手段对安全排查来说最值得关注的是连接数量异常。正常业务服务器的连接分布相对稳定如果某个IP的连接数突然爆发要么是扫描行为要么是暴力破解要么是业务被刷。# 统计所有TCP连接中各个状态的数量 ss -an | awk {print $1} | sort | uniq -c # 统计有多少个不同IP在连接本机按数量降序排列 ss -an | grep ESTAB | awk {print $4} | sort | uniq -c | sort -nr # 查看某个IP跟本机建立的连接详情 ss -an | grep 192.0.2.66对ss -an的输出可以做awk加工。这种管道命令在处理海量连接时非常有效——比如临时看到几万个连接不加工肉眼根本看不过来。我还用过一招判断是不是扫描看SYN-SENT状态的数量。如果机器上有一大堆SYN-SENT说明它正在主动向外发起连接——这通常意味着本机已经成为攻击源要么被种了扫描器要么被当作跳板机。一旦发现这种迹象别犹豫立刻断外网先隔离再说。4.3 监听端口排查陌生端口背后的进程检查所有开放的监听端口是确认有没有开后门的必修课# 列出所有TCP/UDP监听端口及对应的进程 ss -lntup # 找出非标准端口常见端口之外的 ss -lntup | grep -vE :22|:80|:443|:3306|:6379|:8080业务上正常开放的端口无非就那么几个如果你发现一个很不常见的端口在监听比如4444、6666、31337等等就要警惕反弹Shell后门。立刻用ss -lntup找到监听这个端口的进程PID然后按照之前说的/proc/[PID]/exe去看它的真实路径。还有一个隐藏偏门——时间戳。正常长时间运行的服务Socket的建立时间不会过分集中而被植入的后门通常有一个明确的启动时间点。可用ls -ld /proc/[PID] | stat来看进程启动时间我一般用ps -p [PID] -o lstart如果启动时间恰好和告警时间吻合基本就能确认问题。5. 文件权限与隐藏后门排查藏在增量数据里的问题攻击者不可能只做网络连接这一条腿的事。他们要维持权限就要在文件系统里动手脚——写计划任务、加用户、放SUID文件、改关键文件。这些痕迹都留在这台机器的文件系统里只能靠命令一层层扒。5.1 SUID/SGID排查隐藏提权通道SUID是Linux的一个特殊权限位它允许文件执行时以文件所有者的权限运行。如果攻击者把一个自己的脚本或二进制置上SUID位放到某个目录里普通用户执行它就能获得root权限——这是非常经典的留后门手法。# 查找所有SUID/SGID文件 find / -perm -4000 -o -perm -2000 -type f 2/dev/null # 更直观一点显示权限详情 find / -perm -4000 -type f -exec ls -la {} \; 2/dev/null正常情况下系统中的SUID文件是有限的find出来的结果一般是ping、passwd、mount、su这些标准程序。如果你在结果里发现/tmp/xxx或者某个不认识的路径立刻用ls -l确认是否为恶意文件再用file看文件类型、用sha256sum算哈希去威胁情报平台核验。5.2 计划任务与启动项检查持久化后门最常见的家攻击者要持久化控制最长用的招就是写crontab。每周执行一次下载脚本、每天执行一次更新程序——这些看起来规律的任务恰恰是后门的立足点。检查计划任务要覆盖多个位置不能只看crontab -l# 查看当前用户的crontab crontab -l # 查看root的crontab文件 cat /var/spool/cron/root # 查看系统crontab配置 cat /etc/crontab cat /etc/cron.d/* 2/dev/null # 查看用户级cron目录下的内容 ls -la /var/spool/cron/ # 查看cron相关日志确认任务执行情况 grep CMD /var/log/cron 2/dev/null除此之外systemd timer是现代Linux上另一套计划任务机制很多人不知道# 查看所有systemd定时器 systemctl list-timers我遇到过几次这种案例crontab里干干净净计划任务日志也没异常最后是在systemd timer里找到的。攻击者不走老路用新机制做持久化不查这一层就会被漏掉。启动项方面下面这些位置都要检查# rc.local虽然有systemd之后用得少了但很多老套路还在用 cat /etc/rc.local # systemd服务中最近被新增或修改过的 find /etc/systemd/system/ -name *.service -mtime -30 -type f # 用户登录自启文件 ls -la /etc/profile.d/ ls -la ~/.bashrc ~/.profile5.3 关键文件完整性校验用rpm校验和du判断如果怀疑系统文件被篡改rpm自带校验能力特别好用Debian系可以用debsums或者直接用findmd5sum# 校验全部rpm包文件的权限和MD5时间稍久但可靠 rpm -Va # 只校验某个可能被篡改的命令 rpm -Va /bin/ls /bin/ps /bin/ss这个命令很有价值。攻击者为隐藏行迹经常替换ps、ls、netstat这些排查工具本身让你查不到它。用rpm -Va对比包里的原始文件被替换过的一眼就能看出来输出会标注S.5....T这类变更标志——其中S是大小变了5是MD5变了T是时间戳变了。任何一项异常都值得深挖。顺带一个排查大文件的思路很多恶意文件体积不小藏在某个目录里用du扫一遍能发现明显异常# 查/tmp目录下最大的文件 du -ah /tmp | sort -rh | head -20 # 查整个系统最近7天内被修改过大文件 find / -type f -size 100M -mtime -7 -exec ls -lh {} \; 2/dev/null6. 快速加固三板斧从检查到动作排查只是第一步发现问题之后要能马上处置。下面这三板斧是我在每次安全事件里都要反复用到的操作简洁、有效、不打草惊蛇。6.1 SSH加固先掐死最容易进的门SSH是服务器被攻破的头号入口。暴力破解成熟的互联网环境里一台公网服务器开放22端口密码稍微弱点几分钟就会被尝试一轮。以下是省时省力的SSH加固配置# 修改SSH配置文件前先备份 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) # 推荐关键配置项 vim /etc/ssh/sshd_config关键配置项PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes ChallengeResponseAuthentication no MaxAuthTries 3 LoginGraceTime 30 AllowUsers 你的运维账号 AllowGroups wheelPasswordAuthentication no是关键中的关键——只允许密钥登录以后密码爆破基本就失效了。但注意如果你是第一次远程服务器上操作不要一改完就退出当前SSH会话先开一个新的终端测试能登录成功再退出不然配置写错可能导致你被锁在外面。我吃过这个亏全公司都在隔天追问我为什么业务全断了。如果必须要保留密码登录至少加上fail2ban它可以自动检测暴力破解并封禁IP# 安装并启动fail2ban apt install fail2ban -y # Debian系 yum install fail2ban -y # RedHat系 # 自定义SSH防护规则 cat /etc/fail2ban/jail.local EOF [sshd] enabled true port ssh filter sshd maxretry 5 bantime 3600 EOF systemctl restart fail2ban systemctl enable fail2ban打个比方fail2ban就像小区门口的门卫——看到同一个人反复按门铃还不说暗号就直接把他拉黑一小时不管后面他换什么说法都不放进来。6.2 防火墙规则调整临时封禁与最小放行发现问题IP后第一时间封锁它是底线动作。iptables和nftables各派系的写法不太一样但日常最快的封禁命令是# 立即封禁某个攻击IPiptables系 iptables -I INPUT -s 192.0.2.66 -j DROP ip6tables -I INPUT -s 2001:db8::66 -j DROP # 如果使用firewalld firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.0.2.66 reject firewall-cmd --reload # 查看当前防火墙规则 iptables -L -n -v如果机器上默认装了ufw更直白ufw deny from 192.0.2.66 ufw status verbose要注意的是封IP属于止血不能替代后续的彻底排查——攻击者可能已经留下了多个后门入口单纯封一个IP解决不了根本问题。6.3 日常巡检命令自动化把手工检查变成定时任务这些命令不能总在出事的时候才想起来用更靠谱的方式是做成一个巡检脚本每天自动跑一遍输出到本地文件。我可以分享一个简化版本#!/bin/bash REPORT/var/log/security_check_$(date %F).log echo 安全巡检报告 $(date) $REPORT echo --- 近期登录用户 --- $REPORT last -10 $REPORT echo --- 失败登录统计 --- $REPORT lastb | wc -l $REPORT echo --- 当前监听端口 --- $REPORT ss -lntup $REPORT echo --- 近期新增用户 --- $REPORT awk -F: $31000 /etc/passwd $REPORT echo --- SUID异常文件白名单之外的 --- $REPORT find / -perm -4000 -type f 2/dev/null | grep -vE /(bin|usr/bin|usr/sbin|sbin)/ $REPORT echo --- 计划任务 --- $REPORT cat /var/spool/cron/root 2/dev/null $REPORT systemctl list-timers --no-pager $REPORT把脚本放在/usr/local/bin/security_check.sh添加执行权限再注册一个crontabchmod x /usr/local/bin/security_check.sh echo 0 8 * * * /usr/local/bin/security_check.sh | crontab -每天早上8点自动生成一份安全快照。这样即便日后来查事件还能翻出攻击发生前的记录比对哪里有变化这种对比往往比当前状态更能说明问题。7. 实战中容易忽略的三个小细节最后再分享几个我在实操中反复遇到、但常规教程很少提到的细节。第一个是命令本身的信任链问题。如果你的系统已经被攻破那么你执行的ps、ls、ss可能是被替换过的假命令——它们会帮你隐藏攻击者的痕迹。所以真正的排查顺序应该是先看/proc下的真实内核接口再对照rpm -Va校验标准工具最后再信任命令输出。这也是为什么我在前面反复强调/proc/[PID]/exe和rpm -Va——它们是基于内核的直接读取不容易被应用层伪装欺骗。第二个是时间戳相关的坑。攻击者在清理日志时会想方设法混淆时间线但/var/log/wtmp登录记录和/var/log/auth.log认证日志的文件修改时间本身会暴露问题——如果这些日志文件的修改时间早于你期望的写入时间说明有人动过它们。ls -la /var/log/auth.log一眼就能发现问题。第三个是在处置前先截图留证。原理很简单你执行iptables -I INPUT -s ... -j DROP之前先要把当前的连接信息、进程信息、文件列表保存下来。万一后面发现漏了什么翻旧账能翻回来。我在紧急处置时一定会先跑一遍ss -anpt /tmp/net_before.txt ps aux /tmp/ps_before.txt ls -la /tmp /tmp/tmp_before.txt等处理完毕再进行对比。对比前后差异比单纯看当前状态更容易发现问题源头这也是我长期实践下来觉得最实用的安全习惯。我自己在这个领域踩过的坑比吃过的盐还多最大的体会是命令本身不值钱值钱的是你知道在什么场景下该调哪一条命令以及命令输出之后下一步要做什么。这份Linux命令清单与其说是大全不如说是一条完整的排查路径。建议你把命令逐个在测试机上跑一遍不需要背跑熟了自然就记住了。等哪天真遇到告警你会发现手比脑子还快。 
长河君 · 2026/10/21 21:54:50 · 阅读 1.2k Linux安全排查命令实战：从进程、日志到网络定位入侵痕迹
1. 为什么运维老手的安全排查命令清单值得你抄一遍先说一个反直觉的结论在安全事件发生的时候真正能救命的往往不是各种商业扫描器也不是图形化管理平台反而是你手头这一台Linux服务器上自带的那些不起眼的命令。我见过太多次这样的场景了——某公司的一台业务服务器深夜告警CPU直接飙到100%业务方急得跺脚。运维A打开商业监控平台拉了一堆图表越看越迷糊运维B只是不慌不忙地登进服务器敲了一条ps -ef、一条ss -anp五分钟内就定位到是哪一个进程在和哪一台外部主机通信。差距就在这儿工具只能告诉你出事了而命令能告诉你到底是谁干的、现在在哪、下一步应该看什么。这款网络安全常用Linux命令大全本质上就是把这些能直接定位问题的命令整理成了一份可查、可抄、可练的清单。它解决的核心痛点是很多运维或者初级安全工程师遇到异常时脑子里一团浆糊不知道该先看哪里、后看哪里甚至不知道该用哪条命令去探查什么维度的信息。我自己早期也吃过这个亏——明明lastb就在那里我却要手动一行行翻/var/log/auth.log浪费了大量黄金排查时间。所以这篇内容适合这几类读者刚接手服务器运维、对安全日志还不太敏感的普通运维想要补足Linux排查基础、为后面做安全防护打地基的测试开发同学以及那些接了监控告警但不知道下一步怎么落地的值班工程师。我挑选命令的标准很简单场景驱动——不是把所有命令罗列一遍就完事而是每一条命令都能对应到一个真实的安全排查场景比如疑似被爆破登录CPU突然打满发现陌生端口在监听登录记录被人删了等等。下面这份清单全部基于我日常维护真实业务服务器时踩过的坑、用过的招。没有花哨的东西每一条拿出来都能直接落到终端上去跑。2. 系统异常时的第一反应从进程和资源里找蛛丝马迹服务器异常第一现场永远是系统资源。CPU被打满、内存被吃光、负载居高不下——表面上看着是性能问题但相当比例其实是安全事件的马脚。攻击者拿到权限之后最常做的事之一就是跑挖矿木马或者搭代理这些程序都是吃CPU的大户。2.1 top和ps的进阶用法不只看还得会看很多人用top就是进去看一眼就退出其实top在排查安全问题时有几个非常实用的交互操作进入top后按P键按CPU占用率降序排列按M键按内存占用率降序排列。这一步能快速把最可疑的进程揪到最前面。按c键可以展示进程的完整命令行路径避免一堆截断路径迷惑视线。按H键可以切换到线程视图对多线程应用排查特别有用——有些木马是通过单线程占满单个核心的进程级别看起来不高切到线程视角就原形毕露。但如果要留证据、写报告top的交互界面就不够用了。这时候ps才是做记录的利器# 按CPU使用率降序查最耗CPU的前20个进程 ps aux --sort-%cpu | head -20 # 按内存使用率降序查最耗内存的前20个进程 ps aux --sort-%mem | head -20 # 查看某个PID的完整启动命令注意环境变量也能看到 cat /proc/1357/cmdline | tr \0 # 查看某个PID的可执行文件真实路径 ls -l /proc/1357/exe这里重点说下最后两条。/proc/1357/cmdline和/proc/1357/exe是我在排查中几乎必看的东西。为什么因为恶意程序非常喜欢伪装进程名——你看到进程列表里挂着一个java或者nginx以为是自己人的服务实际上可执行文件真实路径是/tmp/.X11-unix/xxx这就有问题了。/proc/[PID]/exe会直接带你找到它真正跑起来的二进制文件这一招能戳穿九成以上的进程伪装。还有一个细节很多木马会在命令行参数里做手脚比如-c参数后面跟一大段混淆过的命令。ps查看时如果命令行特别长、特别怪、充斥着Base64片段基本可以判定不是正常业务进程立刻ls -l /proc/[PID]/exe确认。2.2 谁动了我的CPU一次疑似挖矿的排查思路分享一个实际场景。某公司的一台闲置测试机突然CPU跑满值班同学看着很迷茫不知道从哪查起。我的排查链路是固定的第一步确认现象uptime看load average是不是明显高于CPU核心数。如果1分钟负载是5、15分钟负载是1说明事情是最近才发生的大概率是新启动的恶意进程。第二步找元凶ps aux --sort-%cpu | head -5看到一个陌生的kdevtmpfsi进程乍一看名字还挺像系统进程但这名字其实是常见挖矿木马的特征。进入/proc看它的启动来源ls -l /proc/[PID]/exe ls -la /proc/[PID]/cwd cat /proc/[PID]/cmdline | tr \0 第三步查关联ls -l /proc/[PID]/fd | head -20 cat /proc/[PID]/maps | head -20通过文件描述符能看出它打开了哪些文件通过内存映射可以初步判断二进制是否被加密或注入过。这一套组合拳打下来恶意进程基本无从遁形。2.3 load average和CPU状态的准确解读load average三个数字是多数人最不会看的指标。记住一句话它反映的是等待队列中的进程数不是CPU利用率。所以即使你的CPU利用率只有30%只要大量进程处于不可中断睡眠比如在等磁盘I/O负载照样能冲到很高。排查安全问题时还需要分开看CPU的几项指标us用户态占用突然升高配合陌生进程排查多半是应用层有问题sy系统态占用异常升高有可能是内核层面被注入或驱动异常waI/O等待居高不下不一定是安全问题可能是磁盘坏了或日志疯狂写入——而日志疯狂写入本身也可能因为某个死循环进程排查命令是top -bn1 | grep Cpu(s)-b是批处理模式-n1是只采样一次适合在脚本里抓CPU状态。我建议运维同学练好这一条安全巡检脚本里非常常用。3. 日志审计还原事故现场最重要的证据链很多新手处理安全事件时第一反应是先杀进程、改密码这是大忌。进程可以死、服务可以停、IP可以封但日志一旦被覆盖或者你没来得及留存这个事故就永远讲不清了。正确的顺序一定是先保全证据再处理问题。3.1 关键日志文件优先级先看这几个基本够用Linux系统上的日志文件分布在/var/log/目录下但并不是每个文件都同等重要。按照安全排查的优先级我的阅读顺序是这样日志文件作用什么时候必须看/var/log/auth.log登录认证日志Debian系核心怀疑被爆破、账号登录异常/var/log/secure登录认证日志RedHat系核心同上CentOS等系统用这个/var/log/syslog系统整体运行日志Debian系应用崩溃、系统级异常/var/log/messages系统整体运行日志RedHat系同上/var/log/cron计划任务执行日志怀疑被写了定时任务后门/var/log/btmp错误登录日志二进制查看暴力破解记录/var/log/wtmp已登录用户日志二进制查看历史上谁登录过一个常见的误区是把/var/log/messages当万能日志。实际上很多应用的日志输出到syslog之后会被企业自建日志平台采集本机的messages往往不全。排查安全问题时先确认系统的日志服务是rsyslog还是journaldsystemctl status rsyslog systemctl status systemd-journald如果是CentOS 7或者现在的Ubuntu版本journald默认是启用的这时候journalctl命令比翻/var/log日志文件更靠谱# 查看今天的全部系统日志 journalctl --since today # 查看某个时间段内的日志 journalctl --since 2026-02-18 00:00:00 --until 2026-02-18 06:00:00 # 查看某个PID的所有日志 journalctl _PID1357 # 查看SSH服务的全部日志 journalctl -u sshdjournalctl的好处是自动关联了时间、用户、服务名排查的时候直接按PID过滤信息链是完整的比自己在文本里grep半天高效得多。3.2 SSH登录审计last、lastb、auth.log的组合用法SSH暴力破解是互联网上最常见的攻击类型几乎每一台暴露到公网的服务器每天都会收到大量尝试。审计登录行为的命令组合是我要求自己团队所有人都要背下来的# 最近成功登录的记录 last -20 # 最近失败登录的记录暴力破解看这个 lastb -20 # 查看utmp格式的当前登录用户 wholast读的是/var/log/wtmplastb读的是/var/log/btmp。这两个文件都是二进制格式直接cat是乱码必须通过这些命令去看。lastb的输出会直接列出尝试登录的用户名和来源IP。如果看到同一个IP在反复尝试不同用户名基本可以判定是自动化扫描程序。确认攻击者行为后接下来要深挖auth.log的细节# 查看今天认证相关的全部日志 grep Failed password /var/log/auth.log | tail -50 # 查看某个攻击IP的完整动作链 grep 192.0.2.66 /var/log/auth.log # 查看被接受的公钥登录可能是攻击者植入了自己的密钥 grep Accepted publickey /var/log/auth.log # 查看账号创建相关记录 grep useradd /var/log/auth.log这里有个细节必须注意攻击者拿到权限后往往会清理登录痕迹——删/var/log/btmp、删/var/log/auth.log。但journald的日志如果没被权限覆盖journalctl仍然能查到记录。所以遇到攻击者清痕的迹象时优先journalctl去拉记录不要指望文本日志还在。3.3 命令历史与用户行为追踪从history和时间线找异常每个用户家目录下的.bash_history是另一条重要的证据线。攻击者执行过的命令会在这里留下痕迹前提是没被清理。不过有几个实用小技巧# 查看某个用户的历史命令例如临时账户 cat /home/username/.bash_history # 历史命令带时间戳默认不记录时间需要环境变量支持 export HISTTIMEFORMAT%F %T 如果系统还没配置HISTTIMEFORMAT顺手建议在/etc/profile.d/history.sh里加上这段export HISTTIMEFORMAT%F %T export HISTSIZE10000 export HISTFILESIZE10000这样后续所有用户的历史命令都会带时间戳对事后回溯帮助极大。另外很多人忘了看root的历史命令以外的隐藏文件。攻击者喜欢把自己的操作脚本放在/tmp目录或者家目录下的隐藏目录里所以排查时可以顺手看看这些位置ls -la /tmp | head -50 ls -la /home/*/.* | grep -v .bash find / -name *.sh -mtime -3 -type f 2/dev/nullfind按修改时间查最近3天内被创建或修改的脚本是我在排查中非常依赖的手段经常能找出攻击者留下的下载脚本或者横向移动工具。4. 网络连接与监听端口快速定位异常通信进程只是现象网络通信才是本质。任何被攻陷的机器几乎都会产生外连行为——不是把数据传出去就是接收攻击者控制指令。所以看网络连接是判断机器是否失陷的关键一环。4.1 ss命令的现代用法netstat的替代者很多人还停留在netstat -an但现在的Linux发行版已经默认不带netstat了需要单独装net-tools。而ss命令不仅原生自带性能更好、信息更全是当之无愧的现代替代方案# 查看所有TCP连接 ss -anpt # 查看所有监听端口 ss -lntp # 查看所有UDP连接 ss -anup参数含义解释下-a表示所有连接包括监听和已建立-n表示不做域名解析直接显示IP不做解析速度会快很多-p表示显示进程信息-t只显示TCP-u只显示UDP-l只显示监听端口。我几乎每次都带上-p因为纯粹看连接没有任何意义关键是把端口和进程关联起来。如果不带-p你看到一个陌生端口连接还得再执行一条命令去查进程浪费时间。# 手动关联端口和进程如果不小心没加-p lsof -i :80804.2 连接数统计识别扫描和暴力破解的常用手段对安全排查来说最值得关注的是连接数量异常。正常业务服务器的连接分布相对稳定如果某个IP的连接数突然爆发要么是扫描行为要么是暴力破解要么是业务被刷。# 统计所有TCP连接中各个状态的数量 ss -an | awk {print $1} | sort | uniq -c # 统计有多少个不同IP在连接本机按数量降序排列 ss -an | grep ESTAB | awk {print $4} | sort | uniq -c | sort -nr # 查看某个IP跟本机建立的连接详情 ss -an | grep 192.0.2.66对ss -an的输出可以做awk加工。这种管道命令在处理海量连接时非常有效——比如临时看到几万个连接不加工肉眼根本看不过来。我还用过一招判断是不是扫描看SYN-SENT状态的数量。如果机器上有一大堆SYN-SENT说明它正在主动向外发起连接——这通常意味着本机已经成为攻击源要么被种了扫描器要么被当作跳板机。一旦发现这种迹象别犹豫立刻断外网先隔离再说。4.3 监听端口排查陌生端口背后的进程检查所有开放的监听端口是确认有没有开后门的必修课# 列出所有TCP/UDP监听端口及对应的进程 ss -lntup # 找出非标准端口常见端口之外的 ss -lntup | grep -vE :22|:80|:443|:3306|:6379|:8080业务上正常开放的端口无非就那么几个如果你发现一个很不常见的端口在监听比如4444、6666、31337等等就要警惕反弹Shell后门。立刻用ss -lntup找到监听这个端口的进程PID然后按照之前说的/proc/[PID]/exe去看它的真实路径。还有一个隐藏偏门——时间戳。正常长时间运行的服务Socket的建立时间不会过分集中而被植入的后门通常有一个明确的启动时间点。可用ls -ld /proc/[PID] | stat来看进程启动时间我一般用ps -p [PID] -o lstart如果启动时间恰好和告警时间吻合基本就能确认问题。5. 文件权限与隐藏后门排查藏在增量数据里的问题攻击者不可能只做网络连接这一条腿的事。他们要维持权限就要在文件系统里动手脚——写计划任务、加用户、放SUID文件、改关键文件。这些痕迹都留在这台机器的文件系统里只能靠命令一层层扒。5.1 SUID/SGID排查隐藏提权通道SUID是Linux的一个特殊权限位它允许文件执行时以文件所有者的权限运行。如果攻击者把一个自己的脚本或二进制置上SUID位放到某个目录里普通用户执行它就能获得root权限——这是非常经典的留后门手法。# 查找所有SUID/SGID文件 find / -perm -4000 -o -perm -2000 -type f 2/dev/null # 更直观一点显示权限详情 find / -perm -4000 -type f -exec ls -la {} \; 2/dev/null正常情况下系统中的SUID文件是有限的find出来的结果一般是ping、passwd、mount、su这些标准程序。如果你在结果里发现/tmp/xxx或者某个不认识的路径立刻用ls -l确认是否为恶意文件再用file看文件类型、用sha256sum算哈希去威胁情报平台核验。5.2 计划任务与启动项检查持久化后门最常见的家攻击者要持久化控制最长用的招就是写crontab。每周执行一次下载脚本、每天执行一次更新程序——这些看起来规律的任务恰恰是后门的立足点。检查计划任务要覆盖多个位置不能只看crontab -l# 查看当前用户的crontab crontab -l # 查看root的crontab文件 cat /var/spool/cron/root # 查看系统crontab配置 cat /etc/crontab cat /etc/cron.d/* 2/dev/null # 查看用户级cron目录下的内容 ls -la /var/spool/cron/ # 查看cron相关日志确认任务执行情况 grep CMD /var/log/cron 2/dev/null除此之外systemd timer是现代Linux上另一套计划任务机制很多人不知道# 查看所有systemd定时器 systemctl list-timers我遇到过几次这种案例crontab里干干净净计划任务日志也没异常最后是在systemd timer里找到的。攻击者不走老路用新机制做持久化不查这一层就会被漏掉。启动项方面下面这些位置都要检查# rc.local虽然有systemd之后用得少了但很多老套路还在用 cat /etc/rc.local # systemd服务中最近被新增或修改过的 find /etc/systemd/system/ -name *.service -mtime -30 -type f # 用户登录自启文件 ls -la /etc/profile.d/ ls -la ~/.bashrc ~/.profile5.3 关键文件完整性校验用rpm校验和du判断如果怀疑系统文件被篡改rpm自带校验能力特别好用Debian系可以用debsums或者直接用findmd5sum# 校验全部rpm包文件的权限和MD5时间稍久但可靠 rpm -Va # 只校验某个可能被篡改的命令 rpm -Va /bin/ls /bin/ps /bin/ss这个命令很有价值。攻击者为隐藏行迹经常替换ps、ls、netstat这些排查工具本身让你查不到它。用rpm -Va对比包里的原始文件被替换过的一眼就能看出来输出会标注S.5....T这类变更标志——其中S是大小变了5是MD5变了T是时间戳变了。任何一项异常都值得深挖。顺带一个排查大文件的思路很多恶意文件体积不小藏在某个目录里用du扫一遍能发现明显异常# 查/tmp目录下最大的文件 du -ah /tmp | sort -rh | head -20 # 查整个系统最近7天内被修改过大文件 find / -type f -size 100M -mtime -7 -exec ls -lh {} \; 2/dev/null6. 快速加固三板斧从检查到动作排查只是第一步发现问题之后要能马上处置。下面这三板斧是我在每次安全事件里都要反复用到的操作简洁、有效、不打草惊蛇。6.1 SSH加固先掐死最容易进的门SSH是服务器被攻破的头号入口。暴力破解成熟的互联网环境里一台公网服务器开放22端口密码稍微弱点几分钟就会被尝试一轮。以下是省时省力的SSH加固配置# 修改SSH配置文件前先备份 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) # 推荐关键配置项 vim /etc/ssh/sshd_config关键配置项PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes ChallengeResponseAuthentication no MaxAuthTries 3 LoginGraceTime 30 AllowUsers 你的运维账号 AllowGroups wheelPasswordAuthentication no是关键中的关键——只允许密钥登录以后密码爆破基本就失效了。但注意如果你是第一次远程服务器上操作不要一改完就退出当前SSH会话先开一个新的终端测试能登录成功再退出不然配置写错可能导致你被锁在外面。我吃过这个亏全公司都在隔天追问我为什么业务全断了。如果必须要保留密码登录至少加上fail2ban它可以自动检测暴力破解并封禁IP# 安装并启动fail2ban apt install fail2ban -y # Debian系 yum install fail2ban -y # RedHat系 # 自定义SSH防护规则 cat /etc/fail2ban/jail.local EOF [sshd] enabled true port ssh filter sshd maxretry 5 bantime 3600 EOF systemctl restart fail2ban systemctl enable fail2ban打个比方fail2ban就像小区门口的门卫——看到同一个人反复按门铃还不说暗号就直接把他拉黑一小时不管后面他换什么说法都不放进来。6.2 防火墙规则调整临时封禁与最小放行发现问题IP后第一时间封锁它是底线动作。iptables和nftables各派系的写法不太一样但日常最快的封禁命令是# 立即封禁某个攻击IPiptables系 iptables -I INPUT -s 192.0.2.66 -j DROP ip6tables -I INPUT -s 2001:db8::66 -j DROP # 如果使用firewalld firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.0.2.66 reject firewall-cmd --reload # 查看当前防火墙规则 iptables -L -n -v如果机器上默认装了ufw更直白ufw deny from 192.0.2.66 ufw status verbose要注意的是封IP属于止血不能替代后续的彻底排查——攻击者可能已经留下了多个后门入口单纯封一个IP解决不了根本问题。6.3 日常巡检命令自动化把手工检查变成定时任务这些命令不能总在出事的时候才想起来用更靠谱的方式是做成一个巡检脚本每天自动跑一遍输出到本地文件。我可以分享一个简化版本#!/bin/bash REPORT/var/log/security_check_$(date %F).log echo 安全巡检报告 $(date) $REPORT echo --- 近期登录用户 --- $REPORT last -10 $REPORT echo --- 失败登录统计 --- $REPORT lastb | wc -l $REPORT echo --- 当前监听端口 --- $REPORT ss -lntup $REPORT echo --- 近期新增用户 --- $REPORT awk -F: $31000 /etc/passwd $REPORT echo --- SUID异常文件白名单之外的 --- $REPORT find / -perm -4000 -type f 2/dev/null | grep -vE /(bin|usr/bin|usr/sbin|sbin)/ $REPORT echo --- 计划任务 --- $REPORT cat /var/spool/cron/root 2/dev/null $REPORT systemctl list-timers --no-pager $REPORT把脚本放在/usr/local/bin/security_check.sh添加执行权限再注册一个crontabchmod x /usr/local/bin/security_check.sh echo 0 8 * * * /usr/local/bin/security_check.sh | crontab -每天早上8点自动生成一份安全快照。这样即便日后来查事件还能翻出攻击发生前的记录比对哪里有变化这种对比往往比当前状态更能说明问题。7. 实战中容易忽略的三个小细节最后再分享几个我在实操中反复遇到、但常规教程很少提到的细节。第一个是命令本身的信任链问题。如果你的系统已经被攻破那么你执行的ps、ls、ss可能是被替换过的假命令——它们会帮你隐藏攻击者的痕迹。所以真正的排查顺序应该是先看/proc下的真实内核接口再对照rpm -Va校验标准工具最后再信任命令输出。这也是为什么我在前面反复强调/proc/[PID]/exe和rpm -Va——它们是基于内核的直接读取不容易被应用层伪装欺骗。第二个是时间戳相关的坑。攻击者在清理日志时会想方设法混淆时间线但/var/log/wtmp登录记录和/var/log/auth.log认证日志的文件修改时间本身会暴露问题——如果这些日志文件的修改时间早于你期望的写入时间说明有人动过它们。ls -la /var/log/auth.log一眼就能发现问题。第三个是在处置前先截图留证。原理很简单你执行iptables -I INPUT -s ... -j DROP之前先要把当前的连接信息、进程信息、文件列表保存下来。万一后面发现漏了什么翻旧账能翻回来。我在紧急处置时一定会先跑一遍ss -anpt /tmp/net_before.txt ps aux /tmp/ps_before.txt ls -la /tmp /tmp/tmp_before.txt等处理完毕再进行对比。对比前后差异比单纯看当前状态更容易发现问题源头这也是我长期实践下来觉得最实用的安全习惯。我自己在这个领域踩过的坑比吃过的盐还多最大的体会是命令本身不值钱值钱的是你知道在什么场景下该调哪一条命令以及命令输出之后下一步要做什么。这份Linux命令清单与其说是大全不如说是一条完整的排查路径。建议你把命令逐个在测试机上跑一遍不需要背跑熟了自然就记住了。等哪天真遇到告警你会发现手比脑子还快。