iptables无法直接匹配User-Agent，但可通过xtables-addons的string模块在明文HTTP中实现拦截；需加载xt_string模块，用--algo bm匹配关键词，仅适用于HTTP且存在伪造失效、性能开销等局限。

iptables 本身不能直接匹配 HTTP 请求头里的 User-Agent 字段，因为它工作在网络层和传输层（L3/L4），而 User-Agent 属于应用层（L7）内容。但可以通过结合内核模块 xtables-addons 中的 string 模块，在满足一定前提条件下实现基于 User-Agent 的拦截。

确认系统支持 string 匹配功能

执行以下命令检查是否已加载 string 模块：

iptables -m string --help

若提示“Unknown arg”，说明未安装或未启用 xtables-addons。常见解决方式：

• CentOS/RHEL：安装 xtables-addons-common 和 kernel-devel，然后编译加载模块
• Ubuntu/Debian：安装 xtables-addons-common 和 xtables-addons-dkms，自动构建内核模块
• 验证加载：lsmod | grep xt_string，有输出表示可用

编写针对恶意 User-Agent 的拦截规则

假设你要拦截含 nmap、sqlmap、gobuster 或 python-requests（非业务场景下高频出现）的请求，可添加如下规则：

iptables -A INPUT -p tcp --dport 80 -m string --algo bm --from 0 --to 65535 --string "nmap" -j DROP

iptables -A INPUT -p tcp --dport 443 -m string --algo bm --from 0 --to 65535 --string "sqlmap" -j DROP

说明：

• --algo bm：使用 Boyer-Moore 算法，性能优于 kmp
• --from 0 --to 65535：限定搜索范围为整个 TCP 载荷（实际中可缩小至前 2048 字节，提升效率）
• 规则需放在 ESTABLISHED/RELATED 规则之后、通用 ACCEPT 规则之前，避免误伤正常连接

注意事项与局限性

这类拦截不是万能的，需清楚它的边界：

• 仅对明文 HTTP 有效；HTTPS 流量中 User-Agent 在加密载荷内，iptables 无法解密识别
• 字符串匹配会消耗 CPU，高并发时慎用多条或长 pattern 规则
• 攻击者可轻易伪造或省略 User-Agent（如四无请求），此时该方式完全失效
• 建议配合 Nginx 的 map + if 或 if ($http_user_agent ~* "(nmap|sqlmap|gobuster)") { return 403; } 做二次校验
• 日志层：用 fail2ban 监控 access.log，自动封禁高频异常 UA 的 IP