一叶扁jiang服务器安全这件事，说大不大，说小不小。我做过很多次线上环境的加固，最深的感受是：大部分人不是不想配安全策略，而是不知道从哪个环节下手——装个防火墙怕把自己挡在门外，开个 SELinux 怕业务直接跑不起来。结果往往是服务器裸奔上线，等日志里出现异常才想起来补课。实际上，只要把 iptables 和 SELinux 这两条链路理清楚，大部分针对 Linux 服务器的常规风险都能被挡在入口之外。这篇文章不聊虚的，直接拆解这两套系统的底层逻辑、配置思路和排障方法，帮你把防御策略落到命令行里。
无论你是刚接手第一台云主机的运维新人，还是准备给现有业务做一次系统性加固的工程师，这篇文章的核心目标就三个：把 iptables 的表、链、规则顺序搞明白，把 SELinux 从不知道到敢碰，最后掌握一套遇到拦截时不会慌的排查路径。我会用大量实际操作中的例子来讲，有些步骤甚至可以直接复制过去用。
1. 安全防线全貌：为什么需要 iptables 和 SELinux 双剑合璧
很多刚接触服务器安全的人会有一个误解：装了防火墙就安全了，或者开启了 SELinux 就万事大吉。这其实是把两道不同维度的防御机制混为一谈。理解它们各自的职责边界，比记住无数条具体命令更值钱。
1.1 传统权限模型的短板与 DAC/MAC 概念
Linux 系统默认的权限模型叫DAC，也就是自主访问控制。在这种模型下，文件的属主可以自行决定谁能读、谁能写、谁能执行。日常你敲的 chmod、chown、chattr，都是在 DAC 的范畴里操作。
DAC 有个天然的毛病：只要进程拿到了用户身份，它就继承了这个用户对文件的所有权限。假设你以 root 运行了一个 Nginx，Nginx 一旦被漏洞利用，攻击者就直接获得了 root 级别的文件访问权，后续基本是畅通无阻。这就好比你请了一个家政人员，然后把家里所有房间的钥匙都给了他，他自己又没法分辨哪些房间是该进的、哪些不该进。
SELinux 解决的就是这个“进程越权”问题。它引入了 MAC，也就是强制访问控制。在 MAC 模型下，系统里每个进程、每个文件、每个端口、甚至每个网络连接都带有一个安全上下文。进程能不能访问某个文件，不取决于进程以什么用户身份运行，而取决于它的安全上下文和文件的安全上下文是否匹配。即便你是 root，也不能随便违反策略系统里定义的规则。这等于在 root 权限之上又加了一道锁，攻击者拿到了 root 身份，也拿不到完整的系统控制权。
1.2 iptables 和 SELinux 的分工边界
搞清楚 DAC 和 MAC 的区别后，iptables 和 SELinux 的分工就清楚了。
iptables 工作在 Linux 内核的 Netfilter 框架上，属于网络层的访问控制。它决定的是数据包能不能进出这台机器，或者说网络流量能不能到达某个端口。来源 IP 是攻击者的 IP，直接丢弃；目的端口不是业务端口，直接拒绝。这种拦截发生在 TCP/IP 协议栈处理过程中，对上层应用是透明的。
而 SELinux 工作在系统调用层和文件系统层，属于应用层的访问控制。它决定的是某个进程能不能读某个文件、能不能绑定某个端口、能不能执行某个二进制程序。即使数据包已经通过了防火墙，顺利到达了 Nginx 的 80 端口，SELinux 仍然可以把 Nginx 拦在读取网站根目录的环节上。
用一个不严谨但很好理解的类比：iptables 是大楼的保安，负责检查每一位访客能不能进大门；SELinux 是楼层里的门禁，负责检查进入大楼的人有没有权限进入具体的房间。两者缺一不可。只装 iptables，能挡掉大部分网络攻击，但挡不住应用层漏洞导致的越权行为；只开 SELinux，能限制进程权限，但挡不住端口扫描和 DDoS 这类纯网络攻击。真正稳妥的生产环境，这两层一定都是开启状态，并且策略配置到位。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. iptables 规则设计与实战配置
iptables 本身命令不复杂，难的是理解数据包的流向和规则的命中顺序。很多人配完规则不生效，问题十有八九出在“规则顺序写错了”或者“搞混了链的方向”。
2.1 先搞清楚 iptables 的数据包流转路径
iptables 里的核心概念是“表”和“链”。新手接触最多的表是 filter（过滤表）和 nat（地址转换表）。filter 表负责放行、拒绝、丢弃，nat 表负责源头和目的的地址改写。每个表里有若干条链，最常见的链是 INPUT、OUTPUT、FORWARD。
理解数据包路径的关键就三个问题：