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

时间:2015-04-25 05:13:24

标签: debian dos iptables ddos

过去几周,我的服务器遭到了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个字节,但正如您所看不到的那样。#34;

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

我尝试匹配的规则是:

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

然而,数据包似乎与该规则不匹配,并且它们仍在中断我的端口上的服务。

任何人都可以解释一下我在这里做错了什么吗?

1 个答案:

答案 0 :(得分:0)

我自己解决了这个问题并且认为我发布了解决方案。

我使用-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比十六进制字符串匹配好得多。