企业官网建设流程全解析

搞安全的兄弟们都知道，Linux 是我们日常排查、应急、加固的主战场。不管是处理入侵痕迹、排查异常连接，还是给服务器做一波基础安全自查，命令行都是绕不过去的坎。这篇手册我就不整那些虚的，直接把我实际干活时最常用的 Linux 网络安全命令、关键参数、使用场景和踩坑记录都放出来，主要围绕系统安全排查、网络连接分析、防火墙规则调整、日志审计这几个角度展开。适合刚接触安全运维的读者，也适合有基础的朋友拿来当速查手册，遇到对应场景直接对号入座。

1. 实战手册的整体思路：先搞清楚命令能给什么答案

网上的命令清单很多，但大多数只是把man手册搬了一遍，看着全，实际遇到问题还是不知道用哪条。这套手册的设计思路是倒过来的：从安全排查的实际问题出发，再去匹配命令。比如你怀疑服务器被入侵，问题链是这样的：先看有没有异常连接，再看进程有没有可疑外联，接着看启动项和计划任务有没有被改过，最后翻日志找入侵痕迹。不同环节对应不同命令组合，而不是背一串孤立命令。

还有一点很关键，就是命令选型要考虑系统环境。现在主流厂商的服务器系统有两大分支：sysvinit体系的老系统和systemd体系的新系统，命令差异不小。比如网络连接查看，老系统常用的netstat在部分新版系统里已经不预装了，而ss是 iproute2 包带的，几乎不会缺失。写脚本做自动化排查时，我一般优先用ss，因为它的依赖更少、输出更稳定。如果非要netstat，在 Debian 系可以临时用apt install net-tools补装，但生产环境不建议为了一条命令去装整个包，没必要。

另一点是权限意识。安全相关的命令里头有相当一部分需要 root 权限才能看到完整信息，比如ss -s查看 socket 统计摘要没问题，但想看进程级详细信息就得有权限；tcpdump抓包如果用户不是 root，大概率报权限错误。我的做法是能用sudo精准提权就提，不要整个切换成 root 干活，降低误操作风险。下面所有命令的示例，我都默认你是当前登录用户配合sudo来执行。

这套手册还有一层思路：命令本身不是重点，命令输出的解读才是。很多新手栽在“命令敲了、输出看不懂”这一步。所以我后面写每个板块时，会把常见的输出现象和对应的安全风险一起讲，比如ss -tunp看到状态为ESTAB的外网连接持续增多，就要警惕是不是在向外回传数据，这就比死记-t代表 TCP、-u代表 UDP 有用得多。

2. 网络链路排查：连接、监听与进程身份一网打尽

遇到安全事件，第一步永远是搞清楚这台机器当前和外面有什么联系。这里的核心命令是ss、netstat和lsof，三者的侧重点不同。ss看连接状态和 socket 统计效率高，输出清楚；lsof擅长把占用某个端口的进程揪出来；netstat是传统工具，兼容性最好。实际排查时我通常先用ss做全景扫描，再用lsof精确定位进程。

2.1 ss 命令：查看连接与监听的标配

ss常用组合，我基本上背得滚瓜烂熟：

sudo ss -tunlp

拆解一下参数：-t只看 TCP，-u只看 UDP，-n不做反向域名解析（避免卡在 DNS 上浪费时间），-l只看监听状态的端口，-p显示进程信息。这个组合的输出能看到当前所有监听的端口以及谁来监听的，属于日常巡检第一步。

排查异常外连时，去掉-l，改成：

sudo ss -tunp | grep ESTAB

再配合排序工具把连接数最多的 IP 找出来：

sudo ss -tunp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn

这几条命令可以快速看出哪些远程地址占比异常。做过一次真实排查，就是靠这个组合发现某个进程持续向固定海外 IP 发包，顺着进程 PID 查下去，找到了被种下的后门脚本。iproute2 版本的ss输出的Peer列是IP:端口，awk 按冒号切第一段就是 IP。

2.2 lsof 和 netstat：定位进程身份的老搭档

ss -p虽然能显示进程 PID，但有时进程名不直观，需要看这个进程的完整启动命令行。这时候用：

sudo lsof -i :8080

能直接看到占用 8080 端口的进程 PID、所属用户、进程命令完整路径。这在判断“这个进程是不是正常的”时非常关键。比如某个目录下的临时脚本监听了一个高端口，lsof一查就能看出程序路径在/tmp下，基本可以判定异常。

netstat在一些旧系统或者习惯脚本里仍然常见：

sudo netstat -antlp | grep LISTEN

输出里头Recv-Q和Send-Q的值如果长期异常高，说明连接可能存在积压或异常读写，也值得注意。另外补充一个我自己常用的排查小技巧：把当前所有 TCP 连接按状态统计一下：

sudo ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

正常服务器上ESTAB和TIME_WAIT状态最多，如果见到大规模的SYN_RECV，极可能是被 SYN 洪水攻击了；看到特别多的CLOSE_WAIT，则要想到业务程序可能没正确关闭连接，属于应用层问题，不一定和入侵直接相关，但会拖垮服务器资源。

2.3 实战经验：为什么我习惯先看监听端口

我每次接手一台新服务器做安全检查，第一件事一定是看机器上到底开了哪些对外服务。很多开发同学自己都不清楚装软件时随带启动了哪些监听，等到出问题时才来排查，监听端口一列出来，问题原因基本就浮出水面。通常把ss -tunlp的输出和服务配置核对一遍：数据库应该只监听内网 IP，SSH 不建议暴露到公网（能改端口最好），Redis 这类服务如果监听在0.0.0.0且没有密码认证，那基本就是裸奔，被提权入侵只是时间问题。

这里给新手一个建议：看到0.0.0.0监听别慌，并不代表一定有漏洞，但要确认这个服务是否真的需要对所有网卡开放。很多加固清单的第一项就是“收敛监听地址”，比如 MySQL 从0.0.0.0改成127.0.0.1，意义在于减少攻击面，而不是修复某个具体漏洞。

3. 端口扫描与脆弱点摸底：nmap 的正确打开方式

排查完本机网络状态之后，下一步通常是对目标主机（可能是内网其他机器）做端口扫描，搞清楚暴露了哪些服务，找出可能被利用的薄弱点。这里nmap是我最常用的工具，没有之一。它功能强、脚本生态好，但如果参数用错，轻则扫描结果跑偏，重则把目标机器网络打瘫，尤其是生产环境的内网机器，要格外谨慎。

3.1 扫描强度和速度怎么选

先记住一个原则：默认全局扫描是-sS（TCP SYN 半开扫描），这种方式不建立完整 TCP 连接，速度快，对目标产生的日志相对较少，但在没有 root 权限时不能用，得改用-sT全连接扫描。参数组合参考：

nmap -sS -sV -p 1-65535 -T4 <目标IP>

拆开讲：-sS是 SYN 扫描；-sV探测服务版本，这个是我最看重的能力，因为只有知道服务具体版本，才能对号入座找对应漏洞；-p指定端口范围，全端口扫一定比默认的 1000 个常见端口更全面，但时间成本翻倍；-T4是时间模板，取值 0 到 5，越高越快，但更容易造成丢包或触发目标防护策略。

给不同场景的建议：内网资产盘点用-T4没问题，跨公网扫描对端重要业务系统时，我一般用-T3，宁可慢一点，也不要把目标扫出故障。还有一个参数容易被忽略：--open，只显示开放的端口。默认输出会把 filtered 状态端口也列出来，过滤后看到的结果精简很多，适合直接对着报告处理。

3.2 服务识别与漏洞脚本的实用套路

-sV拿到了服务版本号之后，下一步是查已知漏洞。常见做法是到漏洞库按 CVE 编号查，但很多人会忽略 nmap 自带的 NSE 脚本库。比如针对 SMB 服务，可以用：

nmap -p 445 --script smb-vuln-* <目标IP>

nmap 会自动把名字匹配smb-vuln-前缀的所有脚本跑一遍，这些脚本会检测一些已知的 SMB 漏洞。类似的还有针对 MySQL、SSH、HTTP 服务的脚本组。实际体验下来，内网扫描时这个功能效率相当高，能一次性把常见高危问题暴露出来，省去手动查漏洞库的功夫。

不过要注意，NSE 脚本里有一部分属于主动漏洞验证，比如尝试利用某个漏洞拿到目标权限，这在没有授权的情况下属于法律风险，绝对不能乱跑。我做授权范围内的渗透测试时，会先和客户确认好测试边界，只跑检测类脚本。

另外，nmap 还有一个输出格式值得养成习惯：

nmap -sS -sV -oA scanresult <目标IP>

-oA会同时生成三种格式的结果文件：.nmap（可读输出）、.gnmap（grep 可用格式）、.xml（结构化数据）。XML格式在写报告或二次解析时非常方便，也能把结果导入漏洞管理平台。我以前因为没留-oA吃过亏，扫完没保存结果，后面回看某个端口具体开了什么服务时还得重扫，白白浪费时间。

3.3 被安全设备干扰时的排查思路

扫描时经常遇到一种情况：某些端口显示filtered，目标主机明明在线，但端口死活探测不到。这不一定代表端口真的关闭，更多时候是防火墙规则或安全设备把探测包丢了。处理思路：一是换扫描方式，比如 SYN 被丢就试 TCP connect 扫描或 UDP 扫描；二是加-Pn参数，跳过主机发现阶段，默认 nmap 会先发 ICMP 检查主机是否存活，有些防火墙不回应 ICMP，如果不开-Pn就会把活主机误判成宕机。

还有一种常见干扰是速率限制。目标机器上有安全软件做连接频率限制时，-T4的高并发反而容易导致大量端口被误报为 filtered。这时候把时间模板降下来，或者直接用--min-rate和--max-rate手动控制发包速率：

nmap -sS -sV -p 1-65535 --min-rate 500 --max-rate 2000 <目标IP>

意思是每分钟最少发包数不低于 500，不超过 2000。这块没有标准答案，要根据网络延迟和目标性能动态调整。我一般先从一个中等速率开始，如果看到大量filtered和超时，再逐步降速。

4. 流量嗅探与分析：tcpdump 抓包实战

连接和端口只是“静态”视角，要想了解业务的真实通信内容，比如某个进程是不是在向外发送敏感数据、有没有可疑的 DNS 查询，必须上抓包工具。Linux 环境下tcpdump是王者，它轻量、灵活、几乎在所有发行版里都能装。虽然现在有tshark这类带解析功能的工具，但tcpdump的过滤能力和系统级效率无可替代。

4.1 基础抓包与保存文件

最简单的抓包命令：

sudo tcpdump -i eth0 -nn -s0 -w /tmp/capture.pcap

-i指定网卡，-nn不做域名和端口反解，-s0表示抓取完整数据包而不是默认截断到 96 字节，-w直接写 pcap 文件。抓 pcap 文件的好处是可以事后用 Wireshark 或者 tshark 分析，也可以在保持现场的同时不干扰线上业务。生产服务器上我一般尽量避免在图形化终端操作，所以把所有抓包结果写文件，再拉回本地分析。

分析文件时常用的组合：

sudo tcpdump -r /tmp/capture.pcap -nn | head -50

如果想直接看 HTTP 请求内容，加-A，把数据包内容以 ASCII 形式打印出来，但注意如果抓包里有敏感信息比如密码或 token，输出时就要注意别传到公共平台。

4.2 只关心目标的精准过滤

抓包最容易犯的错是不加过滤条件直接抓，导致文件迅速膨胀，几秒就是几百 MB，分析效率极低。所以抓包前一定要想清楚要回答什么问题，再设计过滤器。

看某个 IP 和本机的所有通信：

sudo tcpdump -i eth0 -nn host 10.10.10.5

只看特定端口（比如怀疑某个木马在连 4444 端口）：

sudo tcpdump -i eth0 -nn tcp port 4444

组合条件用and或者&&连接：

sudo tcpdump -i eth0 -nn src host 10.10.10.5 and dst port 80

这条命令表示只看源 IP 为指定地址且目标是 80 端口的包。实际排查中我会先用宽泛条件确认是否存在可疑连接，再逐步缩小范围精准定位，不要一上来就猜端口。

4.3 从抓包结果判断异常行为

抓到包后如果看到大量 DNS 请求指向不明域名，就要警惕是不是被域名劫持或者木马在做 DNS 隧道通信。常见的判断方法是抓 DNS 流量：

sudo tcpdump -i eth0 -nn udp port 53

看查询的域名是否符合业务特征。如果出现长字符串子域名，比如xxx.abcdef12345.example.com这类随机子域名，极可能是 DNS 隧道工具的特征。另外还有一点，检查抓包中的 TLS 证书信息也能判断出流量走向，但 tcpdump 本身不解析证书，要配合 tshark 增强分析。抓包属于技术手段，必须强调使用边界：只能抓自己有权检查的服务器流量，或者已经获得明确授权的目标系统，否则就越过合法边界了。

5. 防火墙规则：从 iptables 到 nftables/firewalld

排查出异常后，通常需要阻断恶意 IP 或者限制服务暴露范围。Linux 下最传统、最底层的就是iptables，新一代系统很多用nftables作为底层框架，而上层又有firewalld这样的管理工具。它们之间的层级关系容易把人绕晕，我用一个比喻讲清楚：nftables是内核里的一套过滤框架，iptables和firewalld是管理这些规则的两种前端工具，只不过iptables命令本身也能直接操作规则。很多教程只讲iptables，但在新版 Debian/Ubuntu 和 CentOS/RHEL 环境下，直接写 iptables 规则可能因为兼容层没启用而报错。

5.1 临时添加规则与持久化

我日常用得最多的场景：发现某个 IP 在疯狂尝试 SSH 登录，先临时封锁，再持久化规则。

sudo iptables -I INPUT -s 203.0.113.66 -j DROP

-I INPUT表示把规则插入到 INPUT 链最前面，优先级最高。-j DROP直接丢弃，比REJECT更“安静”，目的是不让对方感知到端口是存在还是不存在。临时封禁后，确认无误再持久化。不同系统的持久化方式差异很大：

Debian/Ubuntu 传统上是：

sudo apt install iptables-persistent sudo netfilter-persistent save

RHEL/CentOS 7 上是：

sudo service iptables save

CentOS 8+ 默认用 firewalld，直接改 iptables 规则后如果没做持久化，重启就丢。所以做安全操作时，务必确认当前系统的默认防火墙管理工具，再选择对应的持久化方式。我经常在应急响应结束时听到同事说“我加了规则了”，结果过几天再查发现规则早就没了，根源就是只改内存态没有写持久化配置。

5.2 firewalld 管理常用命令

在 CentOS 8+、Rocky Linux 等系统上，firewalld 是默认方案，常用命令要单独记一份：

sudo firewall-cmd --add-rich-rule='rule family=ipv4 source address=203.0.113.66 drop' --permanent sudo firewall-cmd --reload

--permanent表示写入永久配置，--reload重新加载配置后生效。如果不想让现有连接断掉，可以用：

sudo firewall-cmd --reload

而不是--complete-reload，后者会短暂中断所有连接。线上操作时我一般优先用--reload。查看当前所有规则：

sudo firewall-cmd --list-all sudo firewall-cmd --list-rich-rules

5.3 加固配置文件避免端口裸奔

除了应急封禁，防火墙更重要的作用是日常收敛端口暴露面。我见过太多服务器把 3306、6379、27017 这些数据库端口直接暴露在公网，宛如把家门钥匙挂在门锁上。正确的做法是在防火墙层做白名单：

如果使用 firewalld，把默认 zone 设为 drop：

sudo firewall-cmd --set-default-zone=drop sudo firewall-cmd --permanent --zone=drop --add-service=ssh sudo firewall-cmd --permanent --zone=drop --add-port=8080/tcp sudo firewall-cmd --reload

这样默认丢弃所有入站流量，再逐个放行需要的服务和来源 IP。这里有个实际教训：曾经有台测试服务器按照默认配置安装了 MySQL，结果忘了它默认监听0.0.0.0，防火墙又没配规则，等于把数据库裸奔在公网。后来我在每次装数据库类软件后都会做一步检查：ss -tunlp | grep 3306，确认只监听内网地址，并同步更新防火墙配置。

6. 日志审计与入侵痕迹捕捉

网络和进程层面能发现的异常，往往已经是攻击进行时或完成后。要还原攻击路径、判断数据是否泄露，还得靠日志。Linux 的日志体系比较分散，系统日志、认证日志、应用日志各自为政，排查时要先确认日志文件路径，再按时间窗口检索。

6.1 系统日志和认证日志的重点检索

主流系统的系统日志现在由 systemd 管理，传统路径在/var/log/syslog或/var/log/messages，认证日志通常在/var/log/auth.log（Debian/Ubuntu）或/var/log/secure（RHEL/CentOS）。

查看登录成功和失败记录，最直接的方式：

sudo grep "Accepted password" /var/log/auth.log sudo grep "Failed password" /var/log/auth.log

统计分析有多少个 IP 在尝试暴力破解：

sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

注意auth.log的格式在不同发行版上略有差异，有些系统记录里 IP 字段的位置不同，所以这条 awk 命令不一定通用。我建议先看两行原始日志再写过滤规则，而不是直接套网上抄来的命令，否则可能过滤出来的根本不是 IP。

6.2 journalctl 的按时间精确检索

用 systemd 的系统上，journalctl功能更强大。排查某个时间段内的所有系统日志：

sudo journalctl --since "2025-01-10 10:00:00" --until "2025-01-10 11:00:00"

只看 SSH 服务相关的日志：

sudo journalctl -u ssh --since "2025-01-10 10:00:00"

按 PID 过滤某进程的所有日志，在追踪可疑进程行为时非常有用：

sudo journalctl _PID=12345

一个重要提醒：journal 日志如果不做持久化，默认存在内存里，重启后只剩本次开机后的日志。排查历史入侵事件时，如果系统已经重启过，journalctl可能查不到攻击发生时刻的日志。我在做基线检查时都会确认/var/log/journal是否存在，如果没持久化，会把日志存储方式改成持久化。这个配置在/etc/systemd/journald.conf里，把Storage=auto改成Storage=persistent，然后重启 systemd-journald 服务。

6.3 日志文件被篡改的识别技巧

攻击者拿到权限后，第一件事往往就是清理日志，但清理动作本身会留下痕迹。日志文件被删除或清空后，文件状态会有表现。我一般用下面几个维度判断：

ls -la /var/log/ sudo stat /var/log/auth.log

stat输出里的Modify时间如果异常新，而里面最早的日志时间又接不上，就有被清理的嫌疑。还有一个容易被忽略的点：日志文件如果被删除，但进程还持有文件句柄，磁盘空间不会立刻释放，可以用：

sudo lsof | grep deleted

看到大量 deleted 状态的文件句柄时，十有八九就是日志被删了。这时候应尽快把进程持有的文件内容复制出来，比如/proc/<PID>/fd/<数字>，再做进一步分析。还有更隐蔽的篡改方式是只删除特定几条日志而不是清空整个文件。这种场景下，单纯看文件大小很难判断，需要通过日志连续性来识别：时间戳断档，或者同一条日志内容里前一行和后一行来源 IP 突变成攻击 IP，都算可疑信号。虽然攻击者可以精确编辑日志文件，但在没有完整文件系统审计的情况下，想完全抹掉痕迹并非易事，总有蛛丝马迹可以追。

7. 主机层安全加固：权限、文件与异常进程排查

网络排查和日志审计之外，主机自身的文件完整性和权限配置也需要检查。很多攻击者的核心动作就是在文件系统里落地东西：改启动项、写计划任务、替换系统命令、添加后门账号。这部分的命令要做到“快、准、狠”。

7.1 异常启动项与计划任务排查

计划任务是最常见的持久化方式之一。查看当前用户的计划任务和系统级计划任务：

crontab -l sudo ls -la /etc/cron.d/ sudo cat /etc/crontab

重点关注：路径是否在/tmp、/var/tmp等可写目录下，脚本文件名是否看着像正常系统服务。比如我曾经见过一个计划任务，每分钟执行一次/tmp/.update.sh，文件名刻意伪装成系统更新脚本。对这种文件，第一步是查看内容，第二步是确认文件创建时间，第三步就是删除计划任务和脚本，并按这个线索追查是谁创建的。

systemd 服务也是持久化常用渠道。检查新出现或可疑的服务单元：

sudo systemctl list-unit-files --type=service | grep enabled sudo ls -la /etc/systemd/system/

重点看/etc/systemd/system/下有没有近期创建的文件，正常软件安装生成的服务文件时间通常和安装时间一致，如果出现一个创建时间很新的服务然后指向一个陌生路径，那基本可以确定有问题。

7.2 账号安全与权限审查

添加后门账号是老套路，但依然有效，因为很多管理员根本不查。下面这组命令用来核对系统里有哪些可登录账号：

sudo cat /etc/passwd | grep -v nologin | grep -v /bin/false sudo cat /etc/shadow | awk -F: '$2 != "!" && $2 != "*" {print $1}'

重点核查：UID 为 0 的账号是否只有 root：

sudo awk -F: '$3==0 {print $1}' /etc/passwd

如果有非 root 账号的 UID 也是 0，那这个账号就拥有和 root 等同的权限，极可能是后门。另外看/etc/sudoers里有没有异常提权配置：

sudo cat /etc/sudoers | grep -v "^#" | grep -v "^$"

我处理过一起事件就是攻击者创建了一个 UID 0 账号，表面上看/etc/passwd里多了一行，但管理员平时只看登录日志，压根没注意到账号列表变化。所以建议每隔一段时间就做一次账号清单基线对比，早发现早处理。

7.3 文件系统层面的可疑文件排查

查找最近修改的可执行文件，尤其是/tmp、/var/tmp、/dev/shm这些目录：

sudo find /tmp /var/tmp /dev/shm -type f -mtime -7 -exec ls -la {} \;

查找 root 用户拥有的可疑脚本：

sudo find / -type f -perm /4000 2>/dev/null

这个命令是找 SUID 文件。SUID 是 Linux 的一种特殊权限位，普通用户执行带 SUID 的程序时可以以程序所有者的身份运行。攻击者如果给/bin/bash或某个二进制文件设置了 SUID 位，就能提权。所以定期审计系统里有哪些 SUID 文件、有没有出人意料的新增项，属于主机加固的关键动作。

还可以用rkhunter这类工具做 rootkit 检测：

sudo rkhunter --check --skips /dev/stdin

这类工具通过比对系统命令的哈希值和已知 rootkit 特征码来发现异常，但要记得先更新特征库，否则对新出现的恶意程序基本无效。我一般是把它作为辅助手段，重点还是靠前面那些手工排查命令，因为新式 rootkit 越来越会藏，单纯依赖特征库不够。

8. 组合实战：一次典型异常外联事件排查

前面把命令按模块拆开了，但实际安全事件从来不是单独某一种现象，而是要组合使用。我模拟一个很典型的场景：监控报警说某台服务器持续有可疑外联，需要确认是否为入侵行为，并给出处置建议。

8.1 第一步：确认外联主体

先用 ss 找出可疑连接：

sudo ss -tunp | grep 10.0.0.8 | head -30

发现 PID 是 27891，接着查看这个进程完整信息：

sudo ps -ef | grep 27891 sudo ls -la /proc/27891/exe sudo cat /proc/27891/cmdline

/proc/<PID>/exe是符号链接，指向进程实际的二进制文件路径。如果路径在/tmp、/var/tmp这类目录，基本可以认定为可疑程序。再看这个进程的网络连接对方地址，交叉验证是否对外发送数据。

8.2 第二步：追踪持久化与日志痕迹

确认进程可疑后，先不要急于 kill，保留现场用于分析。接着排查持久化方式：

sudo crontab -l sudo ls -la /etc/cron.d/ sudo systemctl list-unit-files --type=service | grep 27891 sudo grep -r "27891" /etc/systemd/system/ 2>/dev/null

同时提取日志证据，确认攻击者来源和进入方式：

sudo journalctl --since "2025-01-09 00:00:00" --until "2025-01-09 23:59:59" | grep -i "Accepted\|Failed"

8.3 第三步：封禁与清理

确认恶意 IP 后，先封禁再清理。这一步“先封禁、后清理”是有讲究的：如果先杀进程，恶意程序可能通过守护进程立刻拉起一个新实例，甚至反制；而先封禁 IP 可以在网络层阻断它的回连能力。用 iptables 进行封禁，同时用 firewalld 在也做一层规则，双保险：

sudo iptables -I OUTPUT -d 203.0.113.66 -j DROP sudo iptables -I INPUT -s 203.0.113.66 -j DROP

然后按第 7 节的步骤把计划任务、启动项、恶意账号、可疑文件逐一清理。清理完成后再做一次完整的ss检查，确认没有新的外联出现。这套流程下来，大部分基础入侵事件都能处置干净。再高级的情况，比如攻击者通过了内核级 rootkit，那就需要专用检测工具甚至镜像取证了，超出本文范围，不在这一步讨论。

9. 常见问题与排查技巧实录

最后把我在实际执行这些命令时经常遇到的问题集中整理一下，很多坑不是安全知识不够，而是对命令环境理解不透导致的。

9.1 为什么 tcpdump 显示 permission denied

没有用 root 权限抓包是最常见的原因。tcpdump需要访问网络接口的 promiscuous 模式，普通用户默认没权限。解决办法：一是用sudo，二是给当前用户加CAP_NET_RAW能力：

sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump

这种方式适合有特定安全监测需求的进程，免得每次都要 sudo。不过要小心，给 tcpdump 加这个能力之后，任何能调用 tcpdump 的用户都能抓包，所以要确保 tcpdump 二进制本身没有被篡改，最好对它的哈希做记录。

9.2 为什么 netstat 命令不存在

新版系统默认没有 net-tools 包，这属于正常现象。两个解决思路：一个是改用ss（推荐，几乎必装），另一个是按需安装 net-tools。但生产环境装包要慎重，尤其涉及编译依赖时，不要因为顺手就把一大包工具链带上。我的原则是：能用 iproute2 解决的一律优先，非不得已不额外装 net-tools。

9.3 防火墙规则加了为什么连不上

这个问题的原因通常是把规则插到了错误的链，或者没有放行回程流量（比如 INPUT 链没有允许 ESTABLISHED,RELATED）。排查时加一条状态放行规则：

sudo iptables -I INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

这条规则放行所有已建立连接和关联连接的回程包，是保证网络业务稳定的兜底规则。如果不清楚当前系统用 iptables 还是 nftables 作为底层，可以先执行：

sudo iptables -L -n

能正常列出就是兼容层可用，报错说明要么没装包，要么需要改用nft命令。顺便提一个更隐蔽的问题：很多云服务器厂商的安全组和 Linux 防火墙是两层独立访问控制，光在系统里加了规则不够，还要去云控制台的安全组同步放行或拒绝。我做过一次排查，发现系统防火墙明明已经放行了端口，但业务还是不通，绕了一圈才发现是云安全组出方向限制，和系统层没关系。

9.4 为什么日志文件里查不到攻击记录

有两个方向值得检查：一是日志轮转了，攻击时间的日志已经被覆盖或者归档。归档文件通常在/var/log/*.gz，用zcat或zgrep查询。二是 journald 没持久化，重启后旧日志丢了，前面提过这个坑。另外还要注意系统时间是否被攻击者篡改过，如果改过时间，日志排序和关联分析都会错乱。

9.5 抓包文件太大打不开怎么办

抓包时没控制流量或者没加过滤条件，文件可能大到几十 GB。拉回本地分析前先用 tshark 做一次预过滤：

tshark -r capture.pcap -Y "tcp.port==8080" -w filtered.pcap

-Y用的是 Wireshark 的显示过滤器语法，比 tcpdump 的过滤语法更灵活。直接把大包文件压缩传输也会省不少时间。但这里有个细节，压缩 pcap 文件时最好保留原始文件的完整性校验，防止传输过程中损坏影响分析。

9.6 误封合法 IP 怎么办

应急时手快加规则，可能误封了正常业务 IP。所以封禁一定要有记录，最好准备一个小脚本，封禁时自动把规则写入一个带时间戳的文件，并周期性复查。解除封禁的命令同样要写清楚：

sudo iptables -D INPUT -s 203.0.113.66 -j DROP

-D就是删除指定规则。如果之前用-I插入，删除时必须和插入时的规则完全一致，否则序号匹配不上。也可以查行号再删：

sudo iptables -L INPUT -n --line-numbers sudo iptables -D INPUT <行号>

这套手册里的命令覆盖了 Linux 网络安全排查的常用场景，但工具只是基础。我在实际工作中最大的体会是：命令的输出需要放到完整上下文里去解读，孤立看一条日志、一个连接都很正常，组合起来再看才能发现真实问题。建议大家把这些命令练成肌肉记忆，并整理一套自己的排查脚本，把ss、journalctl、find、iptables这些模块串起来，遇到告警时能在几分钟内完成初步定性。后续有空我再写一篇如何把这些命令封装成自动化巡检脚本的文章，把日常安全运维真正从手工变成半自动。