Hping3 options et usages pour tester pare-feu et TCP/IP

Hping3 options et usages pour tester pare-feu et TCP/IP

hping3 forge des paquets TCP/IP (Transmission Control Protocol / Internet Protocol) à la main et observe ce qui revient. Là où un scanner classique décide pour l’opérateur, hping3 laisse choisir chaque drapeau, chaque champ d’en-tête, chaque intervalle d’envoi, ce qui en fait l’outil de référence pour comprendre comment un pare-feu réagit vraiment.

Explication de la marmotte

Imagine que tu envoies des cartes postales à une maison pour deviner ce qu’il y a dedans, selon qu’on te répond, qu’on t’ignore ou qu’on te renvoie la carte. hping3 fait pareil avec un ordinateur sur le réseau : il envoie des messages taillés sur mesure et écoute poliment la réaction.

→ Lire l’explication complète de la marmotte

Modes de paquets et drapeaux TCP dans hping3

hping3 choisit d’abord un mode, qui fixe le protocole du paquet envoyé. Par défaut, c’est du TCP. Les autres se sélectionnent par un chiffre : -0 pour du IP brut (raw IP), -1 pour ICMP (Internet Control Message Protocol), -2 pour UDP (User Datagram Protocol), -8 pour le mode scan et -9 pour le mode écoute (listen). Un seul mode à la fois : combiner -1 et -2 n’a aucun sens et hping3 retient le dernier.

En TCP, chaque drapeau d’en-tête s’active indépendamment : -S (SYN), -A (ACK), -F (FIN), -R (RST), -P (PUSH), -U (URG). Rien n’interdit les combinaisons illégales, et c’est précisément l’intérêt. Un paquet sans aucun drapeau (paquet NULL), un FIN seul, ou un SYN+FIN violent la machine à états de TCP : certains pare-feu les laissent passer parce que leur table d’états ne les reconnaît pas, d’autres les jettent. Le comportement observé renseigne sur le filtrage plus que sur la cible elle-même.

Les champs fins se forcent aussi : -p fixe le port destination (-p ++80 l’incrémente à chaque paquet), -s le port source, -t le TTL (Time To Live), -w la fenêtre TCP, -M le numéro de séquence, -L le numéro d’acquittement, -d la taille de charge utile et -E injecte le contenu d’un fichier comme données. Ces deux options suffisent à transformer un ping en déménageur, usage moins avouable décrit dans l’exfiltration de données via ICMP. Le cadencement se règle avec -i (intervalle, -i u100 pour 100 microsecondes) et --flood qui envoie aussi vite que la pile le permet, sans attendre de réponse. --flood désactive l’affichage : on ne voit plus rien revenir, ce qui est logique mais surprend toujours le débutant pressé.

Scan de ports et cartographie du pare-feu

Le mode -8 prend une plage de ports (-8 1-1024) et renvoie, pour chaque port, le drapeau reçu en réponse. C’est utile, mais la vraie valeur de hping3 est ailleurs : interpréter le silence. Un scanner ordinaire conclut « filtré » sans dire pourquoi. Avec hping3, on contrôle le paquet émis et on lit la réponse exacte, ce qui distingue trois situations que le réseau ne confond jamais, même si les rapports de scan les mélangent souvent.

Un SYN vers un port ouvert ramène un SYN/ACK. Vers un port fermé mais atteignable, un RST/ACK. Un rejet explicite par le pare-feu se traduit par un ICMP de type « destination unreachable » (code 1, 2, 3, 9, 10 ou 13 selon la règle). Et le drop silencieux ne ramène rien du tout : aucune réponse, aucune différence visible entre une machine éteinte et une règle DROP. Ce schéma résume l’arbre de lecture.

Ce qu’il faut lire ici : la différence entre REJECT (le pare-feu répond ICMP) et DROP (il ne répond rien) est invisible côté client sauf à mesurer l’absence de réponse. Tester un SYN puis un ACK vers le même port affine le diagnostic : un pare-feu à états jette un ACK non sollicité (pas de connexion établie) alors qu’un filtre sans état le laisse souvent passer et déclenche un RST de la cible. Comparer les deux réponses révèle si le filtrage garde un état de session, information qu’aucun drapeau isolé ne donne.

Deux options complètent la panoplie de reconnaissance. --traceroute combiné à -S suit le chemin en TCP plutôt qu’en ICMP ou UDP, ce qui franchit les routeurs qui bloquent le traceroute classique mais laissent passer le trafic TCP applicatif. --tcp-timestamp récupère l’horodatage TCP de la cible et permet d’estimer son temps de fonctionnement, donc la date du dernier redémarrage, donc la probabilité qu’un correctif récent soit appliqué. Vingt ans de reconnaissance réseau apprennent qu’une machine affichant 600 jours d’uptime n’a pas vu un noyau à jour depuis longtemps.

Usurpation de source, inondation et détection

hping3 réécrit l’adresse source avec -a (une adresse fixe) ou --rand-source (une adresse aléatoire par paquet). Combiné à --flood et -S, c’est la recette du SYN flood avec sources usurpées, qui remplit la table de connexions semi-ouvertes de la cible. C’est aussi la démonstration la plus directe qu’un réseau sans filtrage d’égress laisse sortir des paquets dont l’adresse source n’appartient pas à son plan d’adressage, faiblesse que le BCP 38 (anti-usurpation) adresse et que beaucoup d’infrastructures oublient encore.

Un point que l’usurpation rend concret : dès que la source est falsifiée, les réponses partent vers l’adresse usurpée, pas vers la machine qui émet. hping3 ne verra donc jamais le SYN/ACK. L’usurpation sert à générer du trafic, pas à diagnostiquer, parce qu’elle coupe par construction le canal de retour. Confondre les deux usages mène à lancer un flood en croyant scanner, puis à s’étonner que l’affichage reste vide.

Côté détection, un flood hping3 est tout sauf discret. Le cadencement régulier au microseconde près, l’absence de poignée de main complète, des numéros de séquence qui ne progressent pas comme une vraie pile le ferait : autant de signatures qu’un système de détection d’intrusion repère sans effort. hping3 est un outil d’analyse et de test autorisé, pas un outil de furtivité, et le présenter autrement relève du folklore de salon. Le test de charge ou de règles de filtrage se mène sur un périmètre dont on a l’autorisation écrite, point final.

Voici le placement typique lors d’un test de règles de pare-feu depuis un segment maîtrisé.

À regarder dans ce schéma : l’opérateur se place en amont du pare-feu et observe ce qui franchit FW vers la DMZ (Zone démilitarisée). La comparaison entre le paquet émis et la réponse reçue (ou son absence) valide chaque règle individuellement, ce qu’une lecture de la configuration seule ne prouve jamais, puisque l’ordre des règles et les états cachés changent le résultat réel.

Exemple de commandes hping3 commentées

Quelques invocations reproductibles, à lancer avec les privilèges root (la forge de paquets bruts exige l’accès aux sockets raw).

# Sonder un port en SYN, 3 paquets, lecture de la réponse (SYN/ACK, RST ou rien)
hping3 -S -p 443 -c 3 203.0.113.20

# Scan d'une plage de ports en mode scan, drapeau SYN
hping3 -8 1-1024 -S 203.0.113.20

# Tester un pare-feu à états : ACK non sollicité vers un port
# (un filtre à états le jette, un filtre sans état laisse souvent remonter un RST)
hping3 -A -p 80 -c 2 203.0.113.20

# Traceroute TCP qui franchit les routeurs bloquant l'ICMP
hping3 -S -p 80 --traceroute -V 203.0.113.20

# Estimer l'uptime de la cible via l'horodatage TCP
hping3 -S -p 80 --tcp-timestamp -c 3 203.0.113.20

# Charge utile forcée : 120 octets de données dans un paquet UDP
hping3 -2 -p 53 -d 120 -c 1 203.0.113.20

L’option -V (verbose) affiche l’en-tête complet de chaque réponse, dont la fenêtre TCP et le TTL de retour, deux indices pour l’empreinte de pile. Le -c borne le nombre de paquets : l’oublier avec un envoi continu et sans --flood sature quand même les journaux de la cible, ce qui transforme un test rapide en incident à expliquer.

🐝 Ce qui arrive si on s’en passe

Sans sondage actif par paquets forgés, les règles d’un pare-feu restent des lignes de configuration jamais confrontées au trafic réel. L’ordre des règles, les états cachés d’une table de connexions et l’écart entre un DROP silencieux et un REJECT explicite ne se vérifient pas par relecture : une règle réputée bloquante peut laisser passer un ACK non sollicité ou un drapeau illégal sans que personne le constate. L’absence de filtrage d’égress contre l’usurpation de source passe également inaperçue, puisque rien ne teste la sortie de paquets à adresse falsifiée. Enfin, l’empreinte de pile et l’estimation d’uptime d’une cible exposée restent accessibles à quiconque les cherche, sans qu’on mesure soi-même ce qui fuit.

Sources

• hping3 manual page (hping.org), Salvatore Sanfilippo.
• RFC 793, IETF.
• BCP 38 (RFC 2827), IETF.

🦫 Explication de la marmotte 🍫

hping3 est un programme qui fabrique des messages réseau pièce par pièce, au lieu d’utiliser les messages tout faits que ton ordinateur envoie d’habitude. Un message réseau, c’est une petite boîte avec une adresse d’expéditeur, une adresse de destinataire et des étiquettes qui disent quel genre de message c’est. Normalement, pour ouvrir une conversation, une machine envoie un premier signal, la machine d’en face répond, et ainsi de suite dans un ordre précis.

Avec hping3, on décide de tout : à quel ordinateur on parle, sur quelle « porte » numérotée, quelles étiquettes on coche, et même quelle fausse adresse d’expéditeur on met. Ensuite on regarde ce qui revient. Si la machine répond « d’accord », la porte est ouverte. Si elle répond « non », la porte est fermée mais joignable. Si un gardien renvoie un message d’erreur, c’est qu’il bloque exprès et le dit. Et si rien ne revient du tout, c’est qu’un gardien a jeté le message en silence, sans prévenir : impossible de distinguer ça d’une machine éteinte.

C’est très utile pour vérifier qu’un pare-feu, le gardien du réseau, bloque bien ce qu’il doit bloquer, car relire ses réglages ne prouve pas qu’ils marchent. Mais si on triche sur l’adresse d’expéditeur, les réponses partent ailleurs et on ne voit plus rien. Et envoyer des milliers de messages très vite se remarque immédiatement : ce n’est pas un outil discret, et on ne s’en sert que là où on a le droit.

Pour aller plus loin : nmap, le scanner de référence et les comportements de TCP et UDP.

À lire aussi

• Empoisonnement de cache DNS de Kaminsky à SAD DNS et paradesComment une réponse forgée entre dans le cache d'un résolveur DNS, de l'attaque de Kaminsky de 2008 aux variantes récentes, et ce qu'arrêtent réellement la randomisation des ports, le codage 0x20, les cookies et DNSSEC.
• Suivre un flux de bout en boutApprendre à raconter un échange complet depuis une action utilisateur jusqu’au service distant, en distinguant nom, adresse, chemin, transport, chiffrement et réponse applicative.
• Menaces réseau, détection et réponse opérationnelleRelier attaques réseau, détection, triage, réponse à incident, DDoS et exploitation SOC sans transformer le site en manuel offensif.
• Captures, observabilité et diagnostic multi-coucheFournir une méthode de dépannage structurée, du câble à l’application, avec outils système, captures paquet, logs, flux, géolocalisation et investigation.

Pages voisines

La citent

• Filtrage, segmentation, NAC et Zero Trust

Hping3 options et usages pour tester pare-feu et TCP/IP

Elle cite

• ⇄Lien dans les deux sens :Exfiltration de données via ICMP avec hping3
• ⇄Lien dans les deux sens :Nmap pour cartographier un réseau, des hôtes aux services exposés
• UDP, TCP et comportements de transport

⇄ : les deux pages se citent l’une l’autre.