iptables无法可靠过滤非法HTTP方法，因其工作在网路层和传输层，不解析HTTP协议内容，无法识别请求行中的方法字段；替代方案应在应用层或代理层实现，如Nginx的limit_except、Apache的mod_security、WAF等。
iptables 本身无法可靠过滤非法 HTTP 方法（如 PUT、DELETE、TRACE、CONNECT 等），因为它工作在网络层和传输层，不解析 HTTP 协议内容。它看不到请求行中的方法字段，也无法区分 GET / HTTP/1.1 和 PUT /admin.php HTTP/1.1 —— 这些都只是 TCP 载荷里的字节流，而 iptables 不重组 TCP、不跳过头部、不识别协议结构。
为什么 --string 匹配 HTTP 方法不可靠
有人尝试用 -m string --string "PUT " --algo bm 之类规则拦截，但实际效果极差，原因包括：
- TCP 分片：一个 HTTP 请求可能被拆成多个包，“PUT ”可能落在第二个包开头，iptables 只查单包，完全错过
- HTTP 头部长度不固定：Cookie、User-Agent、Referer 等导致请求行偏移位置动态变化，
--from/--to手动指定偏移极易错位 - URL 编码干扰：攻击者可用
%50%55%54%20（即 "PUT " 的编码）绕过明文匹配 - HTTPS 流量完全不可见：TLS 加密后载荷是密文，
--string扫不到任何有意义的 HTTP 字符 - 误杀正常响应：若未加连接状态限制，规则可能匹配服务器返回的 HTTP 响应包（含 "HTTP/1.1 200 OK"），导致页面空白
真正有效的替代方案
要限制非法 HTTP 方法，必须在应用层或代理层实现。以下是生产环境推荐做法：
-
Nginx 配置拦截：在 server 或 location 块中使用
limit_except，例如：limit_except GET HEAD POST { deny all; }
这能精确控制哪些方法允许，且支持 HTTPS、压缩、分块等全部 HTTP 特性 -
Apache mod_rewrite 或 mod_security：用
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$拒绝其他方法；或启用 ModSecurity 规则集（如 OWASP CRS），自动识别并阻断危险方法 - 透明反向代理 + Lua/JS 插件：如 Nginx + lua-resty-waf，可在请求进入业务逻辑前解析完整 HTTP 报文，做方法白名单校验
- 专用 WAF 设备或云服务：如 Cloudflare、阿里云WAF、OpenResty-based WAF，内置 HTTP 协议栈解析能力，支持方法、Header、Body 多维度策略
iptables 可配合做的基础加固
虽然不能过滤 HTTP 方法，iptables 仍可为 Web 服务提供外围防护：
- 仅放行必要端口：
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT - 限制连接速率防扫描：
iptables -A INPUT -p tcp --dport 80 -m limit --limit 50/minute --limit-burst 100 -j ACCEPT - 封禁高频异常源 IP（配合 fail2ban）：
iptables -A INPUT -s 203.0.113.45 -j DROP - 确保已建立连接放行：
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
归根结底，HTTP 方法控制属于应用层职责。把这件事交给 iptables，就像让门卫去审查信封里每一页的内容——他只管收发，不拆信。该做的事，得由真正“读信”的组件来完成。
