nftables速率限制规则对部分STUN UDP请求未生效的问题排查咨询

嘿，我来帮你捋捋这个问题——从你贴的tcpdump和规则来看，核心问题出在连接跟踪（conntrack）和规则顺序的配合上，咱们一步步拆解：

首先搞懂为什么你的limit规则没生效 #

你规则最顶部的这条：

ct state vmap { established : accept, related : accept, invalid : drop }

是关键！对于UDP流量来说，当你的coturn服务器回复了第一个STUN请求后，这个源IP+源端口+目标IP+目标端口的五元组就会被conntrack标记为established状态。后续来自同一个五元组的所有包，都会直接匹配这条规则被直接放行，根本不会走到你后面的udp dport 3478 limit规则里！

看你的tcpdump输出，攻击者一直在用5.39.71.183.25565这个固定源端口发请求，第一个包是new状态，触发了你的limit规则（所以dmesg里只有一条日志），但之后的所有重复包都属于established状态，直接被顶部的规则放行了，完全绕过了速率限制。

回答你的几个疑问 #

1. 规则顺序是不是错了？
   不是说要把STUN规则放到ct state前面——如果那样做，会对所有STUN包（包括正常的established交互包）做全局速率限制，反而会影响正常用户的STUN功能。问题出在你没区分new和established状态下的STUN流量限制。

2. 为什么limit规则没处理每个收到的包？
   因为只有new状态的包会走到你的limit规则，established状态的包被顶部的ct规则直接accept了。nftables是按规则顺序从上到下匹配的，匹配到第一条符合的规则就会执行动作，不会继续往下走。

怎么修复这个问题？ #

你需要针对不同状态的STUN流量分别设置限制：

1. 先限制新发起的STUN UDP请求（ct state new），可以选择全局限制或者按源IP限制（更合理，避免单个攻击者占满全局配额）；
2. 再对已建立的STUN连接也设置速率限制，防止攻击者用同一个五元组疯狂发包；

给你一个调整后的规则示例：

flush ruleset

table inet filter {
chain input {
type filter hook input priority 0; policy drop;

ct state vmap { established : accept, related : accept, invalid : drop }

iifname lo accept

# 其他服务规则保持不变...
tcp dport 1935 ct state new log prefix "[RTMP]: " accept
tcp dport 443 ct state new log prefix "[HTTPS]: " accept
tcp dport 3478 ct state new log prefix "[STUN TCP]: " limit rate 5/second accept
tcp dport 5349 ct state new log prefix "[STUN TLS]: " limit rate 5/second accept

########################################################################
# 修改后的STUN UDP规则
# 1. 限制新的STUN请求：每个源IP每秒最多3个
udp dport 3478 ct state new log prefix "[STUN UDP NEW]: " limit rate 3/second ip saddr accept
# 2. 限制已建立的STUN连接：每个连接每秒最多2个（可根据需求调整）
udp dport 3478 ct state established log prefix "[STUN UDP ESTAB]: " limit rate 2/second accept
########################################################################

ip saddr E.F.G.H ct state new log prefix "[Some server that is allowed]: " accept
# 其他SIP/RTP规则保持不变...
udp dport 5060 ct state new log prefix "[SIP UDP]: " accept
tcp dport 5060 ct state new log prefix "[SIP TCP]: " accept
tcp dport 5061 ct state new log prefix "[SIP TLS]: " accept
udp dport { 5000-31000 } ct state new log prefix "[RTP]: " accept

ip saddr 0.0.0.0 ip daddr 255.255.255.255 udp dport { 67, 68 } ct state new drop
}

chain forward {
type filter hook forward priority 0;
}

chain output {
type filter hook output priority 0;
}
}

另外，你原来的那条limit rate over 3/second drop规则是多余的——因为nftables默认是不匹配就继续往下走，最终会被policy drop处理，而且这条规则本来也不会被触发，所以可以删掉。

额外提醒 #

STUN协议本身确实容易被用来做DDoS反射攻击，除了速率限制，你还可以考虑：

• 启用coturn的认证功能（即使只开STUN，也可以设置用户名密码，过滤无效请求）；
• 限制STUN请求的包大小（正常STUN请求不会只有20字节这么小？可以添加udp length 大于某个值的规则过滤异常小包）；

备注：内容来源于stack exchange，提问作者FurretUber