我自己解决了这个问题,并认为我会发布解决方案。
我使用-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比十六进制字符串匹配好得多。