Je vois très régulièrement arriver des paquets étranges sur mon serveur. Ils ne posent pas de problème particulier, mais je me demande tout de même à quoi ça peut bien correspondre.
 
Ce sont des paquets TCP SYN reçus sur le port 443, mais avec un payload, toujours le même : exactement 60800 lettres ASCII "X" (0x58). Je les reçois sous la forme de 42 paquets IP fragmentés. Il arrivent d'IP randoms, d'un peu partout dans le monde, chacune envoyant un seul paquet (enfin, 42 paquets fragmentés, réassemblés en 1 paquet). Ils ne répondent pas à mon SYN ACK. Je vois environ 5 SYN de ce type par minute, et ce rythme est très stable est régulier. Cependant il y a des périodes où je n'en reçois aucun, mais les phases où j'observe ces paquets durent plusieurs heures.
 
Ca ressemble à quelque chose qui pourrait être utilisé pour du DDoS, sauf que le rythme est évidement bien trop faible. J'imagine que ça pourrait être des probes à la recherche d'un service vulnérable, peut-être en provenance d'un botnet ? Il n'est pas impossible non plus que tous ces paquets proviennent en fait d'un machine unique, avec des IP spoofées.
 
En tout cas je ne trouve aucune référence à ce genre de paquet, et je me demande bien quelle peut être leur finalité.

Je suis pas pro du réseau, mais ça me fait bien penser à une tentative de provoquer un buffer overflow. 0x58 ne serait pas un opcode x86 comme le - de mémoire - 0x90 pour les "toboggan NOP"?

Edit: https://en.wikipedia.org/wiki/X86_instruction_listings me dit que c'est un POP data from stack. Sur le stack y'a potentiellement des choses "utiles" pour un attaquant... Après faut "juste" trouver un moyen de faire exécuter ce code et d'avoir le résultat...

Si tu veux faire un buffer overflow tu envoies pas que des X mais tu as un payload utile.
 
C'est en effet étrange. Une attaque TCP SYN c'est en général plein de petits paquets SYN pas des gros en petite quantité.
SYN ne doit pas contenir de data sauf si Fast Open est activé mais même là c'est pas ça qui va épuiser ton système.
 
Donc là comme ça mis à part des probe je vois pas trop ce que ça peut être.
 
Si tu as moyen de changer d'IP voir si ça cesse ça peut être pas mal.

En fait TCP permet l'envoi de données dans un paquet SYN, même en dehors de Fast Open. Dans la rfc7413 :

Donc si tu envoies un SYN avec des data et que tu ne finis jamais le handshake, a priori les données devraient rester en mémoire (dans le kernel) un certain temps. Je me demande s'il n'y a pas là un moyen, peut-être sur certains systèmes, de saturer la mémoire destinée aux connexions en cours d'ouverture.

Pas avec ce flow rate  

Je dirais ça dépend si le but c'est du RCE ou du (d)DOS.

Pour du DoS ok mais pour du RCE c'est justement là que tu as besoin d'un payload très spécifique.

Oui c'est vrai. Après y'a tellement de paquets bizarres qui transitent sur le net, qui sait, peut-être ton truc c'est une "IA" qui cherche des films X?  
 
Non je plaisante, mais sérieusement, qui sait ce que c'est... Intéressant en tout cas de creuser.

A mon humble avis, le SYN en TCP/443 c'est pour passer les firewall. TCP/443 fait parti des ports les plus ouvert du net et le SYN c'est qui permet de passer (le reste est drop si il n'y a pas déjà une entrée dans la conntrack du firewall). Pour le reste ça ressemble a une attaque utilisant la fragmentation IP comme vecteur (genre Teardrop). Pourquoi des "X" ? Ben pourquoi pas ? Si le bidule qui sert a forgé l'exploit demande une grosse payload, et qu'on peut y mettre n'importe quoi, alors, pourquoi ne pas remplir le truc avec des X ?
 
L'avantage des attaques teardrop, c'est que lorsque tu fait une recherche dessus, on tombe rapidement sur un chouette morceau de Massive Attack. .
 
Blague à part, ce n'est pas la seule attaque utilisant la fragmentation IP, il y a un peu de variété : https://en.wikipedia.org/wiki/IP_fragmentation_attack  
 
Peut-être qu'en analysant les entête, on pourrait trouver des indices. Genre, si y a de l'overlap, wireshark doit le détecter.
 

 
(chopé sur le premier com de ce post reddit : https://www.reddit.com/r/wireshark/ [...] n_packets/ )
 
 
 
 
 
 
 
 
 

Pas d'overlap, les paquets sont cleans sans grand chose de remarquable si ce n'est la TCP window qui est à 512.
 
Finalement je suis à peu près certain que les IP sont spoofées. Du coup j'ai essayé de voir si une IP particulière essayer de vérifier si ma machine a crashé, mais non, rien de particulier.
 
Sinon il semble que ce trafic ait cessé depuis hier.