Linux服务器木马排查实战：从进程、网络到日志的完整链路

你先想一个场景：一台运行得好好的Linux服务器，突然某个时刻CPU飙到了90%多，网络连接数暴涨，你手里只有一台终端，这时候你敢不敢跑一条top看一眼？看完之后，敢不敢拍着胸脯说，现在屏幕上这一堆进程里，哪一个该杀、哪一个不该杀？

我见过不少刚接触Linux的同事，ls、cd、rm这些基础命令背得滚瓜烂熟，真到服务器出问题的时候，手忙脚乱地翻网页搜"Linux进程太多怎么办"。说到底，Linux基础不是背命令清单，而是建立一套"系统是怎么跑起来、进程之间怎么关联、异常会暴露在哪里"的认知框架。这篇文章我就用排查木马这件事当线索，把Linux系统基础从头捋一遍——包括权限模型、进程机制、网络连接、日志审计，以及一套完整的手工排查流程。适合刚入门想建立系统观的Linux新手，也适合配服务器但没正经学过安全的运维同学，哪怕你暂时不搞安全，这套思路对日常故障排查一样通用。

1. 为什么要从"排查木马"的角度重新过一遍Linux基础

1.1 大多数人的Linux学习路径出了什么问题

很多人学Linux是这么学的：今天记三个命令，明天装个软件，后天把文件权限改了，遇到报错就搜答案，复制粘贴跑通就算完事。这套打法应付日常操作没问题，但是在系统异常面前会直接失效。原因在于：日常操作是"你给我什么我就用什么"，而排查问题是"你必须自己判断哪个环节出了问题"。

举个例子。你用scp传文件，慢得像蜗牛。直觉反应是网络不好，可实际原因可能是服务器上有个进程在疯狂占CPU，或者磁盘I/O已经饱和，甚至是对端的防火墙在做流量整形。没有系统级的观察能力，你只能靠猜。而木马排查恰恰是要求最高的状态——攻击者故意隐藏痕迹，所有表面现象都可能撒谎，你必须同时掌握用户权限、进程生命周期、网络状态、文件时间戳、日志记录这几块知识，才能拼出完整画面。

这就像你平时开车只负责踩油门刹车，突然有天仪表盘所有灯一起亮，你总得知道哪个灯代表发动机、哪个灯代表刹车油，才能判断该不该靠边停车。

1.2 安全排查能帮你建起哪些基本盘

把木马排查当成学习线索，是因为它天然逼着你把所有基础知识点串起来。一个木马要在系统里存活，至少要做四件事：落地文件、启动进程、建立网络连接、尝试持久化。每一件事都对应一类Linux基础知识点，也是排查时的入手点。

这个表格基本就是一个排查手册的目录。把这五块吃透，你不光能排查木马，日常遇到"端口被占用""进程杀不掉""磁盘空间明明删了文件却没释放"这类问题，也会顺手很多。因为这些问题本质上都在同一个知识网络里，只是换了件马甲。

2. 权限与进程：排查木马前必须建立的两个基础认知

2.1 文件权限模型：r/w/x与特殊位

排查木马的时候，第一眼看的往往是文件本身的属性。ls -l输出的第一列，比如-rwxr-xr-x，这一串字符很多人能背出含义，但未必理解它和安全的关联。

从左到右拆开看：第1个字符是文件类型，-表示普通文件，d表示目录，l是软链接。后面9个字符分成三组，依次是属主、属组、其他人的权限。每组三个字符对应r读、w写、x执行，没有权限用-表示。

为什么木马排查要盯权限位？因为攻击者为了提高存活率，一定会给自己留后门，最常见的手法就是改某个文件的权限或者属主。比如把/etc/shadow（存放密码哈希的文件）改成全局可读，那这台机器的账户体系就彻底裸奔了。所以排查的时候，凡是发现系统关键目录下出现属主异常、权限异常的文件，都要多留个心眼。

比普通权限位更隐蔽的是特殊权限位。ls -l里如果看到rws而不是r-x，说明这个文件被设置了SUID位。SUID的作用是：当普通用户执行这个文件时，进程会临时获得文件属主的权限。如果属主是root，那就相当于任何用户执行这个程序都变成了root权限。这是Linux提权的经典路径，也是木马最爱利用的机制之一。排查时用这条命令扫一下全盘的SUID文件：

bash复制find / -perm -4000 -type f 2>/dev/null

正常情况下SUID文件数量有限，基本集中在/usr/bin/passwd、/usr/bin/sudo这些系统程序。如果多出几个不认识的，或者出现/tmp目录下的SUID文件，这基本就是被入侵的铁证。同样的思路也适用于SGID（-perm -2000）和粘滞位（-perm -1000，通常用于/tmp目录）。

2.2 进程不是孤立运行的

文件只是静态证据，进程才是木马真正活着的样子。Linux的进程模型有个特点：每个进程都有父进程，整个系统从PID 1的systemd开始，像一棵倒挂的树一样层层派生。ps -ef可以看进程列表，pstree可以直接看到树形结构。

排查的时候，我习惯先看进程的"出身"——它的父进程是谁、启动时的工作目录在哪、可执行文件路径是什么。正常进程的出身是清晰且合理的，比如你用SSH登录后敲命令，那个命令的父进程就是你的sshd会话；你用systemd启动的Nginx，父进程就是systemd。

木马的出身往往经不起追问。我之前排查过一台被入侵的机器，进程列表里有一个名字叫kworker的进程，表面看起来人畜无害（kworker是内核工作线程，正常情况下会出现在进程列表里）。但用ps -fp <PID>一查，好家伙，父进程是nginx，而且可执行文件路径在/tmp/.X11-unix/下面。内核线程的父进程怎么可能是Nginx？这就像你看到一个穿着警察制服的人，在超市里跟你要钱——制服是真的，但行为逻辑对不上。

所以排查进程的时候，别只看进程名，要看三个信息：

bash复制# 查看进程基本信息，包括父进程PID、用户、启动时间
ps -fp <PID>

# 查看进程的可执行文件真实路径
ls -l /proc/<PID>/exe

# 查看进程的启动命令行（有时攻击者会在这里隐藏参数）
cat /proc/<PID>/cmdline | tr '\0' ' '; echo

/proc目录是Linux特有的"进程之窗"。这是内核为每个运行中的进程暴露的虚拟目录，里面存着进程的所有运行时信息。/proc/<PID>/exe是个软链接，指向这个进程的可执行文件；/proc/<PID>/cmdline存的是完整的启动命令；/proc/<PID>/cwd指向进程当前的工作目录。这些信息比ps输出可靠得多，因为它是从内核视角直接读出来的，一个恶意进程可以在进程列表里伪装名字，但在/proc目录下很难完整造假。

顺带提一个排查时容易踩的坑：top命令默认按CPU占用排序，木马进程如果疯狂挖矿会排在最前面，一眼就能看到。但有些木马会限制自己的CPU占用率，保持在5%以下慢慢耗，这种在top里很容易被忽略，我的做法是定期用ps aux看完整列表，排序时关注CPU、内存和进程名的组合，而不是只看前几行。

2.3 一个例子：伪装成系统进程的木马如何露出马脚

把上面两个基础认知串起来看一个完整案例。假设进程列表里有这么一行：

bash复制root       14567  0.0  0.1  12756  7816 ?        S    03:14   0:00 /usr/lib/update-notifier/apt-check --enable-update

apt-check是个正常的系统更新检查程序，很多Ubuntu系统上都会周期运行。注意，我上面说的是"正常程序"，但如果这个进程出现的时间是凌晨3点14分、运行用户是root、而且你用了systemctl去看定时任务却找不到谁拉起的它，那就值得深挖了。

此时我会做三件事：用ls -l /proc/14567/exe看真实路径；用cat /proc/14567/cmdline看完整参数；用cat /proc/14567/status看这个进程的PPid和Uid。如果真实路径不在/usr/lib/update-notifier/下面，而是跑到了/tmp/.font/这种地方，或者父进程是个陌生的进程，那基本可以盖棺定论了——名字是抄的，壳子是自己画的。

这就是为什么我说基础很重要：你得先知道正常系统长什么样，才看得出异常。很多人看不清异常，不是因为命令不熟，而是脑子里没有"正常基线"这个概念。

3. 排查木马时最常用到的Linux检查命令

3.1 看网络：ss命令的完整用法

木马要干活就得和外部通信，要么主动连出去（反弹shell、下载指令、回传数据），要么开个端口等人连上来（远控后门）。所以排查网络连接是抓木马最直接的手段。

netstat是老牌命令，但我更推荐ss，它性能更好，而且现在的发行版基本都自带。排查木马时我几乎只用一个组合参数：

bash复制ss -tunap

拆开讲一下每个字母的含义，这不是凑参数，而是方便你按需裁剪：

• -t：只看TCP协议连接
• -u：只看UDP协议连接
• -n：不做域名反解析，直接显示IP和端口（省时间，避免DNS阻塞）
• -a：显示所有状态，包括监听（LISTEN）和已建立（ESTABLISHED）
• -p：显示占用连接的进程PID和名称（需要root权限）

输出的每一行信息量很大。重点看两个方向：State是ESTABLISHED的连接，代表这台机器正在主动或被动跟外部通信；Local Address:Port里的监听地址，代表这台机器对外暴露了哪些服务。

排查时要重点关注以下几种情况：

如果有人搜"linux的9090端口什么再用"，其实就是在用这种思路排查——先查到本地哪个进程占用了9090端口，再顺着进程去看它是不是合理的。具体命令就是ss -tlnp | grep 9090，或者lsof -i:9090。

3.2 看进程：ps、top、lsof的配合

网络连接只是线索，最终要落到进程上才能动手。排查进程我常用的套路是三个命令配合：

bash复制# 第一次摸底：按CPU排序看整体
top -c

# 动态刷新看实时状态，按内存排序
top -o %MEM

# 查看某个PID的详细信息
ps -fp <PID>

top的-c参数挺重要，它能显示完整的命令路径而不是只显示进程名。很多木马就是把进程名伪装成正常名字，但完整路径暴露了它在/tmp或者用户目录下的事实。

lsof（list open files）排查利器，它列出进程打开的文件。之所以说它强，是因为它能建立"端口-进程-文件"三者之间的关联：

bash复制# 查看某个PID打开了哪些文件
lsof -p <PID>

# 查看哪个进程占用了指定端口
lsof -i:8080

# 查看被删除但仍在运行的文件句柄（木马常这样隐蔽自己）
lsof +L1

最后一条值得单独说。攻击者有个常见操作：把木马文件删掉，但进程还在内存里跑着。这样在磁盘上找不到证据，ps里却能看到进程。lsof +L1能列出那些文件已被删除但仍然打开的进程，一旦发现这类进程，基本可以断定有情况，而且这种进程必须连根杀掉再排查启动项，不然会反复复活。

3.3 看文件：按时间找落地文件和可疑目录

木马终归要有个文件在磁盘上（内存马除外，但那是另一个话题），而且这些文件大多会落在特定目录。排查文件的核心逻辑是：正常系统里的文件都有合理的"出身"，异常文件往往集中出现在可写目录、临时目录或隐藏路径里。

优先检查这几个目录，可以说是木马的"兵家必争之地"：

• /tmp：全局可写，回收策略宽松，木马最爱
• /dev/shm：共享内存目录，同样是全局可写，而且很多杀毒软件默认不扫
• /var/tmp：备用的临时目录，容易被忽略
• /var/spool/cron/：计划任务目录，用于持久化
• /usr/lib/：系统库目录，容易被鱼目混珠
• /etc/init.d/、/etc/systemd/system/：服务启动脚本目录

在这些目录里看到可疑名称后，用find按时间精确打击：

bash复制# 找最近3天内修改过的文件
find /tmp /dev/shm /var/tmp -mtime -3 -type f 2>/dev/null

# 找最近5天内新增的二进制文件（排除/usr和/etc这种正常更新频繁的目录）
find / -mtime -5 -type f -not -path "/proc/*" -not -path "/sys/*" \
  -not -path "/usr/*" -not -path "/etc/*" 2>/dev/null

# 找所有隐藏目录（文件名以点开头的），木马经常藏在里面
find / -name ".*" -type d 2>/dev/null | grep -v -E "^/proc|^/sys|^/usr|^/home/[^/]+/\."

find配合时间戳是个非常有效的排查手段。攻击者植马的时间点大概率和你发现异常的时间点接近，所以-mtime -3（3天内修改过）在紧急排查时有奇效。但要注意，攻击者可以用touch -r命令把文件时间改成和系统文件一样，这一招叫时间戳伪造。怎么识别？偶尔用stat看文件的Birth time（创建时间），如果修改时间很老但创建时间很新，一样有嫌疑。

3.4 看启动项与计划任务：揪出持久化后门

木马最核心的需求是"活着"，而且最好是重启后还能活着。要实现这个目标就必须给自己设置持久化机制。排查的重点就是启动项和定时任务。

Linux的持久化位置非常多，我按优先级从高到低列一下：

bash复制# 1. systemd服务是近年最常见的持久化方式
systemctl list-unit-files | grep enabled

# 查看所有服务里可疑的
cat /etc/systemd/system/*.service
ls -lt /etc/systemd/system/            # 按时间排序，最近的可能是木马

# 2. crontab计划任务
crontab -l                             # 当前用户的计划任务
cat /var/spool/cron/*                  # 所有用户的计划任务
cat /etc/crontab                       # 系统级计划任务
ls -l /etc/cron.d/                     # cron.d目录，谨慎审核

# 3. rc.local（老系统常用）
cat /etc/rc.local

# 4. Shell配置文件（这个容易被忽略但非常致命）
cat ~/.bashrc
cat /etc/profile.d/*.sh

排查计划任务时有个细节容易被忽视：crontab -l只能看到当前用户的任务，如果木马是root起的，就得看/var/spool/cron/root或者/var/spool/cron/crontabs/目录下所有文件。更隐蔽的招数是写在/etc/cron.d/下，文件名可以伪装成syslog、tmpwatch这种看着正常的名字，所以这个目录我每次都会逐个打开看一眼。

还有一类后门藏在Shell配置里。攻击者往/root/.bashrc里加一行alias ssh=/usr/local/bin/fake_ssh，用户每次敲ssh命令实际执行的都是木马，输入的用户名密码直接被盗走。这种后门平时不显山露水，只能靠定期检查配置文件内容才能发现。

3.5 看日志：auth.log里的入侵痕迹

日志是最后的证据链，也是最容易被新手忽略的排查入口。Linux下最常看的几个日志文件：

最常用的排查命令：

bash复制# 看最近的登录历史
last -20

# 看每个用户最后一次登录时间
lastlog

# 看SSH登录失败最多的IP（爆破来源）
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr | head -20

# 看成功登录的记录
grep "Accepted" /var/log/auth.log | awk '{print $9, $11}'

日志的价值在于时间线和来源IP。配合你刚才在文件排查里发现的木马文件时间，如果时间线能对得上——比如某个陌生IP在凌晨2点成功登录，然后凌晨2点05分/tmp下出现了新文件——那整条入侵链路就清楚了。

4. 完整复盘：一台可疑服务器的排查流程与判断链路

理论讲了这么多，下面用一台真实环境里常见的"被入侵"服务器做一次完整复盘，把整个排查链路串起来。你们以后遇到类似情况，可以按这个顺序走。

4.1 现象描述与初始怀疑

监控告警显示：服务器CPU从平时的5%突然飙升到80%以上，持续了十几分钟没有回落。同时外网出口流量异常，每秒上行流量从几十KB涨到了好几MB。

这个现象非常典型。CPU高+上行流量大，大概率是挖矿木马在干活，或者机器被当成跳板在对外扫描/发包。我登录服务器后的第一反应不是跑任何高深工具，而是先用一条命令稳住自己——记录当前时间，然后开始排查。

4.2 逐步排查的完整链路

第一步：看进程，锁定CPU大户

bash复制top -c

屏幕上CPU列第一行有个进程，PID是23394，占用CPU 750%，进程名显示为kworker。表面看像是内核线程，但-c参数让它露了馅——完整命令行是/tmp/.../.x/kswapd0。kswapd0是内核内存回收线程的名字，出现在/tmp目录下，用户是root，这个组合肉眼可见地不对劲。

有时候光看命令行还不够确信，我继续验证：

bash复制ls -l /proc/23394/exe
cat /proc/23394/cmdline | tr '\0' ' '

/proc/23394/exe软链接指向/tmp/.x/kswapd0，实锤。正常的kswapd0是内核线程，它的exe软链接根本不存在（内核线程没有用户态可执行文件），这里却指向一个/tmp下的文件，说明这是个伪造的内核线程名的木马。

第二步：看网络连接，确认通信行为

bash复制ss -tunap | grep 23394

发现这个进程建立了两条外连，目标IP是185.220.xxx.xxx:4444，连接状态是ESTABLISHED。到这里基本能判断出这是矿池连接或者远控连接。4444端口是常用的控制端口，加上外连的高端口，木马的通信行为已经非常明确。

第三步：看同党，排查关联进程

确认了一个木马后，不能急着杀，先看有没有同伙：

bash复制pstree -ap 23394
ls -l /proc/23394/cwd

cwd指向/tmp/.x目录，直接用ls -la去翻这个目录，结果发现里面不止一个文件，还有一个init脚本和一个cleaner.sh。cleaner.sh这个文件名字很讽刺，我打开一看，内容是清理其他竞争木马和删除日志，也就是说这个木马会自己删除别的木马，独吞这台机器的资源。这是个很典型的多木马竞争生态。

第四步：看启动项，找出持久化机制

bash复制crontab -l
cat /var/spool/cron/*
ls -lt /etc/cron.d/

/etc/cron.d/下多了个文件叫update，打开一看：

code复制* * * * * root /tmp/.x/init

每分钟执行一次，重启后也会自动拉起。这就是为什么不能只杀进程，你不把这个cron任务删掉，进程被杀了也会在一分钟内复活。

第五步：看登录日志，还原入侵路径

bash复制last -20
grep "Accepted" /var/log/auth.log | tail -20

日志显示，三天前的凌晨，一个来自103.56.xxx.xxx的IP用root账号密码登录成功，前后尝试了几十次失败后才成功——典型的SSH口令爆破。这说明服务器的root密码太弱，而且SSH允许root直接远程登录，攻击者一次爆破就进来了。

第六步：兜底检查，确认无遗漏

bash复制find /tmp /dev/shm /var/tmp -mtime -3 -type f 2>/dev/null
find / -perm -4000 -type f 2>/dev/null
ss -tunap

扫了一圈没发现其他异常SUID文件和陌生监听端口，确认入侵范围相对可控。到这里，整个排查链路就完整了：从高CPU现象出发，先识别异常进程，再确认网络连接和持久化机制，最后通过日志还原入侵路径。整个流程不用任何商业化工具，纯靠Linux基础命令就能完成。

4.3 总结：排查判断的几个经验

1. 排查顺序不要颠倒。先看进程和网络（活的证据），再看文件和日志（静态证据）。如果先删文件，进程还跑着，它可能会自己把文件重新写回来，反而打草惊蛇。
2. 不要看到进程名正常就放松警惕。判断进程是否正常，最可靠的方法是看/proc/<PID>/exe指向哪里。进程名可以伪装成任意字符串，但可执行文件的真实路径会说话。
3. 杀木马前先断它的"生路"。把cron任务删掉、启动项清掉，让木马死亡后无法复活，再去杀进程。顺序反了就会陷入"杀了又活、活了再杀"的死循环。
4. 完整取证后再清理。可以先tar打包可疑文件留作证据，再处理。不然文件被删了，后续做溯源报告没素材。

5. 木马是怎么进来的：常见入口与Linux加固实践

排查完一台机器，最重要的不是庆幸"抓到了"，而是想清楚一个问题：它到底怎么进来的？不堵住入口，今天清了木马，明天还会再来一波。下面按我的经验把常见的入侵入口和对应的加固措施列一下，这些都是自己踩过坑之后总结出来的。

5.1 SSH加固：最重要的一步

SSH是全球Linux服务器默认开放的服务，也是被爆破最多的入口。基础加固就三步，但效果立竿见影：

第一步，禁用root密码登录。编辑/etc/ssh/sshd_config，把PermitRootLogin改成no，或者改为prohibit-password（仅允许密钥登录）。攻击者爆破root账号的路径直接被堵死。

第二步，改用密钥认证。本地生成密钥对，把公钥传到服务器的~/.ssh/authorized_keys里：

bash复制ssh-keygen -t ed25519 -a 100
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server_ip

然后在sshd_config里设置PasswordAuthentication no，彻底关闭密码认证。这样即使有人拿到了密码也无法登录，因为服务器根本不接受密码登录。

第三步，配置fail2ban对爆破IP自动封禁。这个工具的原理是监控认证日志，同一IP在指定时间内失败超过阈值就自动加防火墙规则封禁。配置好后可以大幅提高爆破成本。

5.2 用户与权限管理：最小权限原则

用户管理是Linux基础里最容易被忽视的部分。很多运维图省事，所有服务都用root跑，所有账号都是sudo权限——这等于给攻击者铺好了路。

我的建议是：运行服务的账号单独建，不给sudo权限；管理操作通过具有sudo权限的独立账号完成；长期不用的账号直接删除或锁定。具体命令：

bash复制# 新建一个普通用户，用于日常操作
useradd -m -s /bin/bash ops

# 把它加入sudo组（Debian系）
usermod -aG sudo ops

# 查看当前所有用户的UID和登录Shell
awk -F: '{print $1, $3, $7}' /etc/passwd

/etc/passwd文件里每一行是一个用户，第三列是UID，UID为0的账号拥有root权限。排查的时候扫一眼有没有陌生UID为0的用户，这一步很多时候比扫木马更关键——因为有些攻击者会直接创建一个新root用户，一劳永逸。

5.3 防火墙与文件权限基线

防火墙的理念是"默认拒绝，按需放行"。用ufw或firewalld只放行业务需要的端口（比如80、443，或自定义的SSH端口），其他端口一律关闭，可以大幅压缩攻击面：

bash复制# 以ufw为例
ufw default deny incoming
ufw default allow outgoing
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 2222/tcp   # 如果SSH改到了2222
ufw enable

文件权限基线这一点，很多人可能觉得麻烦，但基础排查里真用得着。简单说就是：系统关键文件该只读的别给写权限，该限制用户的别放全局可写。一个实用检查命令：

bash复制# 找出所有全局可写的文件（排除符号链接）
find / -perm -0002 -type f 2>/dev/null

全局可写意味着任何用户都能改这个文件。如果这个文件属于root且是系统脚本，普通用户就能往里面塞命令，下次root执行时自动成为提权通道。

5.4 日常监控与审计：不给自己留盲区

基础加固做得再好，也不能保证永不失手，所以日常监控必须有。我的建议是最小可用的三件套：

• 日志集中管理：把多台服务器的/var/log/auth.log、/var/log/secure统一收集到日志服务器，防止攻击者清理单机日志后彻底无法溯源。
• 文件完整性监控：定期对/bin、/usr/bin、/etc等目录做hash快照，比如用aide，跑完发现hash变化就告警。这样即使木马改了系统文件也能及时发现。
• 基线巡检：每天扫一遍ss -tunap、crontab -l、systemctl list-unit-files | grep enabled，确认新增的服务、任务、连接都是自己认识的。把基线搞清楚，比任何高价安全设备都靠谱。

我在实际运维中还有一个习惯：每条SSH登录都开journalctl -u ssh -f挂着看，虽然平时有点吵，但它能让我第一时间感知到异常登录尝试。如果嫌吵，至少要在安全组/防火墙层面把SSH的访问IP白名单限制到办公网络，这比一切登录加固都简单粗暴有效。

最后再分享一个我自己踩过的坑。有次我排查一台服务器，折腾了大半天，top里看到一个进程CPU占用很高，路径在/usr/lib下，名字伪装的跟系统库函数一样，查了半天没查出问题。后来无意中用stat看了下文件的时间戳，才发现这个文件的创建时间正好是系统被爆破成功那天，而进程的父进程是sshd的子进程。一查auth.log，当天确实有一个陌生IP登录成功。整条证据链一下就串起来了。

Linux基础说到底是"理性"的系统观。你不需要提前预知木马长什么样，只需要知道正常系统该怎么运转，然后把那些"说不通"的疑点一个一个揪出来，剩下的答案自然就浮出来了。希望这篇整理出来的排查链路和基础知识点，能帮你在面对一台陌生服务器时，少一点焦虑，多几条清晰的思路。