企业官网建设流程全解析

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（系统态占用）异常升高，有可能是内核层面被注入或驱动异常
• wa（I/O等待）居高不下，不一定是安全问题，可能是磁盘坏了或日志疯狂写入——而日志疯狂写入本身也可能因为某个死循环进程

排查命令是：

top -bn1 | grep "Cpu(s)"

-b是批处理模式，-n1是只采样一次，适合在脚本里抓CPU状态。我建议运维同学练好这一条，安全巡检脚本里非常常用。

3. 日志审计：还原事故现场最重要的证据链

很多新手处理安全事件时第一反应是"先杀进程、改密码"，这是大忌。进程可以死、服务可以停、IP可以封，但日志一旦被覆盖或者你没来得及留存，这个事故就永远讲不清了。正确的顺序一定是：先保全证据，再处理问题。

3.1 关键日志文件优先级：先看这几个，基本够用

Linux系统上的日志文件分布在/var/log/目录下，但并不是每个文件都同等重要。按照安全排查的优先级，我的阅读顺序是这样：

一个常见的误区是把/var/log/messages当万能日志。实际上很多应用的日志输出到syslog之后会被企业自建日志平台采集，本机的messages往往不全。排查安全问题时，先确认系统的日志服务是rsyslog还是journald：

systemctl 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 _PID=1357 # 查看SSH服务的全部日志 journalctl -u sshd

journalctl的好处是自动关联了时间、用户、服务名，排查的时候直接按PID过滤，信息链是完整的，比自己在文本里grep半天高效得多。

3.2 SSH登录审计：last、lastb、auth.log的组合用法

SSH暴力破解是互联网上最常见的攻击类型，几乎每一台暴露到公网的服务器每天都会收到大量尝试。审计登录行为的命令组合，是我要求自己团队所有人都要背下来的：

# 最近成功登录的记录 last -20 # 最近失败登录的记录（暴力破解看这个） lastb -20 # 查看utmp格式的当前登录用户 who

last读的是/var/log/wtmp，lastb读的是/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 HISTSIZE=10000 export HISTFILESIZE=10000

这样后续所有用户的历史命令都会带时间戳，对事后回溯帮助极大。

另外，很多人忘了看root的历史命令以外的隐藏文件。攻击者喜欢把自己的操作脚本放在/tmp目录或者家目录下的隐藏目录里，所以排查时可以顺手看看这些位置：

ls -la /tmp | head -50 ls -la /home/*/.* | grep -v ".bash" find / -name "*.sh" -mtime -3 -type f 2>/dev/null

find按修改时间查最近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 :8080

4.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 ~/.profile

5.3 关键文件完整性校验：用rpm校验和du判断

如果怀疑系统文件被篡改，rpm自带校验能力特别好用（Debian系可以用debsums，或者直接用find+md5sum）：

# 校验全部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/null

6. 快速加固三板斧：从检查到动作

排查只是第一步，发现问题之后要能马上处置。下面这三板斧是我在每次安全事件里都要反复用到的操作，简洁、有效、不打草惊蛇。

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 wheel

PasswordAuthentication 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各派系的写法不太一样，但日常最快的封禁命令是：

# 立即封禁某个攻击IP（iptables系） 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-rule='rule family=ipv4 source address=192.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: '$3>=1000' /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，添加执行权限，再注册一个crontab：

chmod +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命令清单，与其说是"大全"，不如说是一条完整的排查路径。建议你把命令逐个在测试机上跑一遍，不需要背，跑熟了自然就记住了。等哪天真遇到告警，你会发现手比脑子还快。