iptables无法直接解析http等应用层内容，但可通过状态跟踪、连接限制、速率控制和行为分析构建纵深防御：基础防护层设默认drop、放行本地回环及已建立连接；web准入层过滤端口、并发连接与异常tcp标志；速率控制层用recent模块限速防cc攻击；可观测层配置log记录、ssh白名单及规则持久化。
iptables 本身工作在网络层和传输层（L3/L4），无法直接解析 HTTP 请求头、URL 或 Cookie 等应用层（L7）内容，因此严格来说，它不能单独实现真正的“七层深度防御”。但通过组合状态跟踪、连接限制、速率控制、IP 行为分析及与日志系统联动，它可以构建一套面向 Web 服务的纵深式、可落地的深度防御策略——不是靠“看内容”，而是靠“识行为”“控节奏”“守边界”。
基础防护层：白名单优先 + 连接状态管控
这是所有策略的前提，确保只放行真正必要的流量，杜绝默认开放风险：
- 设置默认策略为 DROP：
iptables -P INPUT DROP，避免“允许所有”的历史遗留问题 - 无条件放行本地回环：
iptables -A INPUT -i lo -j ACCEPT，保障本地服务通信和健康检查 - 放行已建立连接及关联连接：
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT，保证响应能正常返回 - 仅对可信运维 IP 开放 SSH：
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.5 -j ACCEPT，禁用密码登录、强制密钥认证应同步配置
Web 流量准入层：端口、协议与连接特征过滤
不只开 80/443，而是明确“谁、以何种方式、多快频率”能访问 Web 端口：
- 显式允许 HTTP/HTTPS 新建连接：
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT（同理配 443） - 限制单 IP 并发连接数（防慢速攻击/连接耗尽）：
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 32 -j REJECT - 拒绝明显异常的 TCP 标志组合（如 SYN+FIN）：
iptables -A INPUT -p tcp --tcp-flags ALL SYN,FIN -j DROP - 封禁常见扫描特征（如空 User-Agent、大量 HEAD 请求）需结合 mod_evasive 或 Nginx 日志 + fail2ban，iptables 本身不处理这些
速率控制层：对抗 CC 攻击的核心防线
利用 recent 和 limit 模块，从行为频率切入，区分“人”与“机器”：
- 每秒新建连接限速（防突发洪流）：
iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --set --name httpreqiptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 1 --hitcount 15 --name httpreq -j DROP - 60 秒内总请求数限制（更宽松但覆盖长周期刷量）：
iptables -A INPUT -p tcp --dport 80 -m recent --set --name webuseriptables -A INPUT -p tcp --dport 80 -m recent --update --seconds 60 --hitcount 60 --name webuser -j DROP - 对 HTTPS 同样配置（--dport 443），避免攻击者绕过 HTTP 限速
可观测性与应急响应层：留门、记账、可回滚
防御不是闭门造车，必须保留管理通道、记录异常、支持快速干预：
- 在规则末尾添加 LOG 规则：
iptables -A INPUT -j LOG --log-prefix "BLOCKED: " --log-level 4，配合 rsyslog 将日志写入独立文件便于分析 - 始终把 SSH 白名单规则放在所有 DROP 规则之前，确保被误封时仍有救急入口
- 使用
iptables-save > /etc/iptables/rules.v4持久化，并测试重启后规则是否生效 - 准备一键回滚脚本（如清空规则并恢复 ACCEPT 策略），避免锁死自身
真正有效的 Web 防御，是 iptables 做好“流量初筛”和“行为压制”，再由 Nginx 的 limit_req、mod_security 或专业 WAF 处理语义层逻辑。它不替代应用层防护，但能让后者更专注、更高效。
