A server of mine has been under dos attacks for the past few weeks. They've just now starting randomizing the source so I can't simply drop the packets by source IP anymore.
Here are a few of the packets from 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.&.........
Commonly the packets have a length of 42 bytes, but as you can see not "always."
The other commonality is at offset 0x010, I see the same pattern - 17eb f72a
The rule I've put in place to try and match this is:
-A INPUT -i eth1 -p udp --dport 44463 -m string --to 42 --algo kmp --hex-string '|17ebf72a|' -j DROP
However the packets do not seem to be matched against that rule and they are still disrupting service on my port.
Can anyone perhaps explain what I might be doing incorrectly here?
I solved this myself and figured I'd post the solution.
I used the -u32 module instead of hex string matching. For this particular issue I used the following rule:
-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
This seems to drop most of the traffic. It's not perfect (as you can see in the dump above that the uint at offset 22 is different in one packet), however these packets are basically masquerading as legit data.
But I digress, in the context of the question posed, u32 worked much better then hex string matching.