直接封死端口不能物理闭合漏洞，但iptables可实现网络层彻底阻断，让攻击流量在到达服务前被丢弃；需先放行本地回环和运维通道，再设默认drop策略，对3306等高危端口显式drop，叠加ip黑白名单，并保存规则、验证超时效果。
直接封死端口本身不能“物理闭合”漏洞，但通过 iptables 配置可实现网络层彻底阻断——让攻击流量在到达服务进程前就被丢弃，等效于将该端口对公网“不可见”。关键不是简单加一条 -j DROP，而是构建一套防绕过、防误伤、可持续生效的防御链。
一、确认漏洞端口与协议特征
以 CVE-2023-38545（MySQL 相关 curl 堆溢出）为例，其攻击入口是 TCP 3306 端口，且初始握手含固定字节序列（如 05 01 00）。但 iptables 无法深度解析应用层载荷，所以防御必须聚焦在端口+源IP+连接行为三重控制上：
- 明确目标端口：如 3306（MySQL）、27017（MongoDB）、6379（Redis）等默认高危服务端口
- 确认协议类型：绝大多数数据库漏洞走 TCP，极少数用 UDP（如 DNS 反射类），需分开处理
- 识别可信来源：仅允许内网管理段（如 10.0.1.0/24）、跳板机 IP 或云平台 LB 回源段访问，禁止 0.0.0.0/0
二、执行“零信任式”端口封锁流程
顺序不能错，否则会锁死自己。所有操作建议在控制台或带串口的环境执行，避免纯 SSH 操作：
-
先放行本地回环和运维通道：
iptables -A INPUT -i lo -j ACCEPTiptables -A INPUT -p tcp -s 192.168.10.0/24 --dport 22 -j ACCEPT -
再设置默认拒绝策略（必须在放行之后）：
iptables -P INPUT DROPiptables -P FORWARD DROP -
对高危端口做显式 DROP（非 REJECT）：
iptables -A INPUT -p tcp --dport 3306 -j DROPiptables -A INPUT -p tcp --dport 27017 -j DROP
注意：用 DROP 而非 REJECT，避免向攻击者暴露端口存在；且规则要放在所有 ACCEPT 规则之后，靠默认策略兜底
三、增强防护：IP 层级精准过滤
单封端口不够，攻击者可能伪造源 IP 或利用内网横向移动。需叠加黑白名单机制：
-
黑名单优先匹配（立即生效）：
iptables -I INPUT -s 203.0.113.45 -j DROPiptables -I INPUT -s 185.143.224.0/22 -j DROP
使用-I插入顶部，确保恶意 IP 在任何 ACCEPT 前就被拦截 -
白名单严格限定（最小权限）：
iptables -A INPUT -p tcp -s 10.0.5.10 --dport 3306 -j ACCEPTiptables -A INPUT -p tcp -s 10.0.5.11 --dport 3306 -j ACCEPT
不写-j DROP，靠默认 INPUT DROP 自动覆盖其他所有 IP
四、持久化与验证闭环
重启后规则消失等于没配。必须保存并验证实际效果：
-
保存规则（按发行版选择）：
CentOS/RHEL：service iptables save
Debian/Ubuntu：iptables-save > /etc/iptables.rules && echo "iptables-persistent install" | sudo sh -
验证是否生效：
执行iptables -L INPUT -n --line-numbers，确认 DROP 规则位置正确、无重复
从外部用telnet your-server-ip 3306测试——应超时（DROP 表现），而非 Connection Refused（REJECT 表现） -
日志辅助审计（可选但推荐）：
iptables -I INPUT -p tcp --dport 3306 -j LOG --log-prefix "BLOCKED-MYSQL: "
日志会输出到/var/log/messages或journalctl -k | grep BLOCKED，便于溯源扫描行为
