Match de chaîne hexadécimal IPTables pour atténuer l'attaque DOS

Question

Un de mes serveurs a été victime d'attaques ces dernières semaines. Ils commencent maintenant à randomiser la source, donc je ne peux plus simplement laisser tomber les paquets par source IP.

Voici quelques-unes des paquets de 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.&......... 

Généralement les paquets ont une longueur de 42 octets, mais comme vous pouvez le voir pas « toujours ».

L'autre point commun est à l'offset 0x010, je vois le même schéma - 17eb f72a

La règle que je l'ai mis en place pour essayer de correspondre à c'est:

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

Cependant, les paquets font ne semblent pas correspondre à cette règle et perturbent toujours le service sur mon port. Est-ce que quelqu'un peut peut-être expliquer ce que je ne fais pas correctement ici?

Answer 1

J'ai résolu cela moi-même et j'ai pensé que je posterais la solution. J'ai utilisé le module -u32 au lieu de la chaîne hexadécimale correspondante. Pour ce problème particulier, j'ai utilisé la règle suivante:

-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 

Ceci semble réduire la plus grande partie du trafic. Ce n'est pas parfait (comme vous pouvez le voir dans la sauvegarde ci-dessus que l'uint au décalage 22 est différent dans un paquet), cependant ces paquets sont fondamentalement déguisés en données légitimes.

Mais je m'égare, dans le contexte de la question posée, u32 a fonctionné beaucoup mieux que l'appariement hexadécimal.