过去几周,我的服务器遭到了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
然而,数据包似乎与该规则不匹配,并且它们仍在中断我的端口上的服务。
任何人都可以解释一下我在这里做错了什么吗?
答案 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比十六进制字符串匹配好得多。