Debian IPTables十六进制字符串匹配以减轻dos攻击

我的一台服务器在过去几周一直受到拒绝服务攻击。他们刚刚开始对源进行随机分组，所以我不能再简单地按源IP丢弃数据包了

以下是来自tcpdump的一些数据包：

23:58:32.229878 IP (tos 0x0, ttl 242, id 21915, offset 0, flags [none], proto UDP (17), length 42)
    31.196.24.4.23360 > x.44463: [udp sum ok] UDP, length 14
        0x0000:  4500 002a 559b 0000 f211 2c4a 1fc4 1804  E..*U.....,J....
        0x0010:  17eb f72a 5b40 adaf 0016 2e87 0001 0000  ...*[@..........
        0x0020:  0002 58b0 26ca 0000 01f0 0000 0000       ..X.&.........

00:09:46.648582 IP (tos 0x0, ttl 119, id 31037, offset 0, flags [none], proto UDP (17), length 35)
    98.165.122.244.64929 > x.44463: [udp sum ok] UDP, length 7
        0x0000:  4500 0023 793d 0000 7711 dddd 62a5 7af4  E..#y=..w...b.z.
        0x0010:  17eb f72a fda1 adaf 000f 393f 0015 cf4f  ...*......9?...O
        0x0020:  082b 5700 0000 0000 0000 0000 0000       .+W...........

00:15:26.680685 IP (tos 0x0, ttl 242, id 50739, offset 0, flags [none], proto UDP (17), length 42)
    93.187.72.7.15772 > x.44463: [udp sum ok] UDP, length 14
        0x0000:  4500 002a c633 0000 f211 4db7 5dbb 4807  E..*.3....M.].H.
        0x0010:  17eb f72a 3d9c adaf 0016 de30 0001 0000  ...*=......0....
        0x0020:  0002 58b0 26ca 0000 01f0 0000 0000       ..X.&.........


00:30:52.615474 IP (tos 0x0, ttl 242, id 14833, offset 0, flags [none], proto UDP (17), length 42)
    73.183.53.2.22109 > x.44463: [udp sum ok] UDP, length 14
        0x0000:  4500 002a 39f1 0000 f211 0103 49b7 3502  E..*9.......I.5.
        0x0010:  17eb f72a 565d adaf 0016 ec78 0001 0000  ...*V].....x....
        0x0020:  0002 58b0 26ca 0000 01f0 0000 0000       ..X.&.........

00:30:45.109025 IP (tos 0x0, ttl 242, id 30860, offset 0, flags [none], proto UDP (17), length 42)
    88.155.91.9.24065 > x.44463: [udp sum ok] UDP, length 14
        0x0000:  4500 002a 788c 0000 f211 8d7c 589b 5b09  E..*x......|X.[.
        0x0010:  17eb f72a 5e01 adaf 0016 afe9 0001 0000  ...*^...........
        0x0020:  0002 58b0 26ca 0000 01f0 0000 0000       ..X.&.........

00:30:41.614592 IP (tos 0x0, ttl 242, id 65181, offset 0, flags [none], proto UDP (17), length 42)
    72.178.45.8.56959 > x.44463: [udp sum ok] UDP, length 14
        0x0000:  4500 002a fe9d 0000 f211 4555 48b2 2d08  E..*......EUH.-.
        0x0010:  17eb f72a de7f adaf 0016 6d55 0001 0000  ...*......mU....
        0x0020:  0002 58b0 26ca 0000 01f0 0000 0000       ..X.&.........


00:49:40.533446 IP (tos 0x0, ttl 242, id 43365, offset 0, flags [none], proto UDP (17), length 42)
    35.154.12.7.44781 > x.44463: [udp sum ok] UDP, length 14
        0x0000:  4500 002a a965 0000 f211 e0a6 239a 0c07  E..*.e......#...
        0x0010:  17eb f72a aeed adaf 0016 e300 0001 0000  ...*............
        0x0020:  0002 58b0 26ca 0000 01f0 0000 0000       ..X.&.........

通常，数据包的长度为42字节，但正如您所看到的，并不总是这样

另一个共同点是偏移量0x010，我看到相同的模式-17eb f72a

我制定的规则是：

-A INPUT -i eth1 -p udp --dport 44463 -m string --to 42 --algo kmp --hex-string '|17ebf72a|' -j DROP

然而，这些数据包似乎不符合该规则，它们仍然在中断我端口上的服务

---

有人能解释一下我在这里可能做得不正确吗？

我自己解决了这个问题，并决定发布解决方案

我使用了-u32模块而不是十六进制字符串匹配。对于这个特殊问题，我使用了以下规则：

-A INPUT -i eth1 -p udp -d x -m u32 --u32 "16 & 0xFFFFFFFF = 0x17ebf72a" -m u32 --u32 "22 & 0xFFFFFFFF = 0xadaf0016" -m u32 --u32 "34 & 0xFFFFFFFF = 0x58b026ca" -j DROP

这似乎减少了大部分流量。正如您在上面的转储中所看到的，偏移量22处的uint在一个数据包中是不同的，这并不完美，但是这些数据包基本上伪装成合法数据

---

但我离题了，在提出的问题中，u32比十六进制字符串匹配更有效。

也许你有兴趣用u32回答这个问题。厚度