☰

nftables 限制似乎对某些 STUN 请求不起作用

tag-icon • tag-icon nftables coturn
nftables 限制似乎对某些 STUN 请求不起作用

我正在使用 coturn 设置一个仅使用 STUN 的服务器（TURN 已禁用）。似乎 STUN UDP 可用于 DDoS，所以我试图设置nftables规则以使其更难，但规则似乎并不总是有效。有时，我可以看到类似这样的情况tcpdump：

21:16:08.006842 IP 5.39.71.183.25565 > A.B.C.D.3478: UDP, length 20
21:16:08.007091 IP A.B.C.D.3478 > 5.39.71.183.25565: UDP, length 72
21:16:08.258386 IP 5.39.71.183.25565 > A.B.C.D.3478: UDP, length 20
21:16:08.258613 IP A.B.C.D.3478 > 5.39.71.183.25565: UDP, length 72
21:16:08.278988 IP 5.39.71.183.25565 > A.B.C.D.3478: UDP, length 20
21:16:08.279229 IP A.B.C.D.3478 > 5.39.71.183.25565: UDP, length 72
21:16:08.475423 IP 5.39.71.183.25565 > A.B.C.D.3478: UDP, length 20
21:16:08.475734 IP A.B.C.D.3478 > 5.39.71.183.25565: UDP, length 72
21:16:08.481217 IP 5.39.71.183.25565 > A.B.C.D.3478: UDP, length 20
21:16:08.481416 IP A.B.C.D.3478 > 5.39.71.183.25565: UDP, length 72
21:16:08.484939 IP 5.39.71.183.25565 > A.B.C.D.3478: UDP, length 20
21:16:08.485211 IP A.B.C.D.3478 > 5.39.71.183.25565: UDP, length 72
21:16:08.490332 IP 5.39.71.183.25565 > A.B.C.D.3478: UDP, length 20
21:16:08.490545 IP A.B.C.D.3478 > 5.39.71.183.25565: UDP, length 72
21:16:08.505617 IP 5.39.71.183.25565 > A.B.C.D.3478: UDP, length 20
21:16:08.505901 IP A.B.C.D.3478 > 5.39.71.183.25565: UDP, length 72
21:16:08.529745 IP 5.39.71.183.25565 > A.B.C.D.3478: UDP, length 20
21:16:08.530020 IP A.B.C.D.3478 > 5.39.71.183.25565: UDP, length 72
21:16:08.819766 IP 5.39.71.183.25565 > A.B.C.D.3478: UDP, length 20
21:16:08.820048 IP A.B.C.D.3478 > 5.39.71.183.25565: UDP, length 72

这高于 上指定的 3/秒限制nft。nft规则如下：

#!/usr/sbin/nft -f
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
        ########################################################################
        ####### These two rules are where it is not behaving as intended #######
        udp dport 3478 log prefix "[STUN UDP]: " limit rate 3/second accept
        udp dport 3478 log prefix "[STUN UDP THIS RULE]: " limit rate over 3/second drop
        ########################################################################
        ip saddr E.F.G.H ct state new log prefix "[Some server that is allowed]: " accept
        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;
    }
}

由于正在运行其他一些服务，因此存在一些附加规则，但是即使使用其他端口的其他服务已停止，我仍然遇到这个问题。

对我来说最奇怪的是，只有一个地方提到了这些数据包dmesg：

[4151543.207466] [STUN UDP]: IN=eth0 OUT= MAC=00:00:00:00:00:00:d4:c1:9e:0b:4d:c0:08:00 SRC=5.39.71.183 DST=A.B.C.D LEN=48 TOS=0x00 PREC=0x00 TTL=241 ID=31022 PROTO=UDP SPT=25565 DPT=3478 LEN=28

很可能我不明白某些内容，无论是关于nftables、STUN、两者还是其他内容。问题：

  1. 规则顺序是否错误？例如，STUN UDP 规则应该位于行之前ct state vmap？

  2. 由于nftables规则设置了 3/秒的限制，而不考虑数据包的状态，难道不应该在端口 3478 上接收到的每个数据包上进行处理吗？

或者也许是其他我还未发现的原因导致该nftables限制无法应用。

系统信息：

OS: Debian 11
coturn version: 4.5.2-3 from the Debian repository.
nftables version: v0.9.8 (E.D.S.) from the Debian repository.

答案1

你所有的tcpdumpNetfilter 将捕获视为单流：每个数据包匹配相同的双向连接跟踪5 组（此处：udp,5.39.71.183,25565,ABCD,3478）。因此，一旦此流的第一个数据包（根据状态 中的定义new）被限制规则接受，则同一流的所有其他数据包（在 Netfilter 的连接跟踪在状态下established，被第一个短路规则接受：

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

虽然您只会在 UDP 中看到这种情况，但 TCP 的行为应该相同，但我猜测使用 UDP 进行 DDoS 比使用 TCP 更容易（没有使用 TCP 进行欺骗等）。

您应该将限制相关的规则移到第一个短路规则之前。

相关内容