Outils paquets quand on ne peut rien installer

L'équipe serveur dit non aux nouveaux binaires. Pas de curl à jour, pas de nmap static. Il faut quand même savoir où va le trafic quand l'appli "n'atteint pas la base."

tcpdump et netcat sont souvent déjà là parce que l'ops les a utilisés avant vous.

tcpdump : capturer moins

Les captures pleine interface remplissent le disque et peuvent mélanger d'autres flux.

DNS cassé :

tcpdump -i any -n udp port 53 -c 50

SYN vers la base suspectée :

tcpdump -i eth0 -n host db.internal and tcp port 1433 -c 20

Rotation :

tcpdump -i eth0 -w /tmp/cap.pcap -C 50 -W 5 'tcp port 443'

Nettoyez après. Les défenseurs voient aussi les pcaps bizarres.

netcat : couteau terne mais présent

Test de connectivité :

nc -vz target.host 443

Relais de port en pivot (selon build et policy) :

nc -lkvp 4444 -c "nc db.internal 1433"

Vérifiez nc -h. OpenBSD, traditional et ncat diffèrent. -e n'existe pas partout.

Banner :

echo "" | nc -w 3 target 25

Si rien n'est installé

Demandez ss ou netstat côté appli. Un socket Python ou PowerShell minimal si interpréteur dispo. L'objectif c'est un ticket avec preuve.

Coordination blue team

Capture passive : mentionnez-la dans le plan de test. Partagez chemins et suppression après revue.

Si ni tcpdump ni nc ne sont installés, demandez la sortie de ss -tlnp ou netstat depuis le compte applicatif. Un test socket minimal en Python ou PowerShell suffit souvent pour ouvrir un ticket réseau avec preuve.

Documentez le nom d'interface (eth0 vs ens192), le namespace réseau si l'appli tourne en conteneur, et si le service écoute seulement sur localhost. "Connection refused" depuis un autre hôte est souvent du binding, pas un firewall mystérieux.

Ces outils sont vieux. C'est pour ça qu'ils survivent aux lockdowns.

Relais de port et banner grab semblent ennuyeux jusqu'à ce que ce soit tout ce que vous avez. Vérifiez le build de nc. Mentionnez la capture passive dans le plan de test et supprimez les pcaps après revue.