主页 / server / 问题 / 1126639
Accepted
FurretUber
Asked: 2023-03-20 10:50:18 +0800 CST

nftables 限制似乎不适用于某些 STUN 请求

  • 772

我正在使用 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.
nftables

1 个回答

  1. Best Answer

    Netfilter 将您的所有tcpdump捕获视为单个流：每个数据包匹配相同的双向conntrack 5-uple（此处：udp,5.39.71.183,25565,ABCD,3478）。因此，一旦该流的第一个数据包（根据 state 中的定义）new被限制规则接受，同一流的所有其他数据包（在state的 Netfilter conntrackestablished中）将被第一个短路规则接受：

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

    虽然您仅针对 UDP 见证了这一点，但 TCP 的行为应该相同，但我想使用 UDP 执行 DDoS 比使用 TCP 更容易（没有使用 TCP 等进行欺骗）。

    您应该在第一个短路规则之前移动与限制相关的规则。

    • 0

相关问题