Analyse TCP RST et réinitialisation de la connexion PCAP : qui a fermé la connexion et pourquoi
Comment analyser TCP RST, la réinitialisation de la connexion par un homologue, la réinitialisation après SYN, la réinitialisation pendant TLS, la réinitialisation du pare-feu, la fermeture de l'application et les preuves de capture de paquets.
La « réinitialisation de la connexion par un homologue » est une erreur courante dans les clients HTTP, les bases de données, les outils TLS, les proxys et les applications TCP personnalisées. Les utilisateurs recherchent « Analyse TCP RST pcap », « réinitialisation de la connexion par un homologue Wireshark », « RST après SYN », « réinitialisation de la connexion TLS » et « réinitialisation TCP du pare-feu », car ils ont besoin de savoir qui a mis fin à la connexion et si la réinitialisation provient de l'application, du système d'exploitation, du pare-feu, de l'équilibreur de charge ou du serveur.
Un TCP RST est explicite. Il est écrit "abandonner cette connexion". Le plus difficile est l’attribution.
La chirurgie PCAP est utile car les investigations de réinitialisation nécessitent une trace propre et ciblée avec la direction, les horodatages, les numéros de séquence et suffisamment de paquets avant la réinitialisation.
Modèles de réinitialisation courants
La TVD peut arriver :
- Immédiatement après SYN.
- Après SYN-ACK.
- Après ClientBonjour.
- Après requête HTTP.
- Pendant le délai d'inactivité.
- Après des données de protocole invalides.
- Lorsqu'une application ferme un socket avec des données non lues.
- Lorsqu'un pare-feu rejette une politique.
- Lorsqu'un équilibreur de charge n'a pas de backend sain.
- Lorsqu'un processus serveur plante ou refuse l'état.
Le timing vous indique où chercher.
Qui a envoyé la TVD
Identifiez d’abord l’IP source, le port source, l’IP de destination et le port de destination du paquet de réinitialisation. Si l'adresse IP du serveur envoie RST, le côté serveur ou quelque chose se faisant passer pour ce côté y a mis fin. Si l'adresse IP du client envoie RST, le côté client y met fin. Si le comportement TTL, MAC ou du chemin suggère un boîtier de médiation, la réinitialisation peut être injectée.
Ne vous fiez pas uniquement au libellé de la demande. La « réinitialisation par un homologue » peut être signalée par le côté qui a reçu le RST.
Réinitialiser après SYN
RST après SYN signifie souvent que le port est fermé ou que la politique rejette la connexion. Si SYN reçoit RST immédiatement, l'application n'a jamais atteint TLS ou HTTP.
Rechercher:
- SYN -> RST,ACK
- Pas de serveurBonjour
- Aucune donnée de candidature
- Comportement cohérent à travers les tentatives
Il ne s'agit pas d'un échec de certificat ou d'une erreur HTTP ; il s'agit d'un échec d'accessibilité/état de service TCP.
Réinitialiser pendant TLS
RST après ClientHello peut être dû à un port incorrect, à un TLS non pris en charge, à une incompatibilité SNI, à une stratégie de boîtier de médiation ou à un rejet du serveur. Conservez les métadonnées DNS et ClientHello afin que vous puissiez voir le nom d'hôte, les versions ALPN, TLS et la synchronisation.
Si la réinitialisation arrive après une alerte TLS, l'alerte est plus informative que la réinitialisation. S’il n’y a pas d’alerte, la réinitialisation peut être de niveau inférieur ou pilotée par une politique.
Réinitialiser après demande
RST après une requête HTTP, une requête de base de données ou une commande de protocole signifie souvent que l'application est suffisamment comprise pour rejeter ou planter la requête. Cela peut également signifier qu'un proxy a été fermé car l'amont n'était pas disponible.
Corrélatif:
- Derniers octets d’application envoyés.
- Réponse du serveur ou absence de réponse.
- Temps d'inactivité avant la réinitialisation.
- Journaux du backend/de l’équilibreur de charge.
- Si la réinitialisation se produit uniquement pour certaines tailles de requêtes.
Checklist
Utilisez ce flux de travail :
- Identifiez le premier RST de la conversation.
- Identifiez qui l'a envoyé.
- Inspectez ce qui s’est passé juste avant.
- Vérifiez si la négociation TCP est terminée.
- Vérifiez si TLS a commencé ou terminé.
- Vérifiez si les données de candidature ont été envoyées.
- Vérifiez le délai d'attente d'inactivité.
- Comparez les indices TTL/MAC/path pour l'injection dans le middlebox.
- Préservez les octets DNS, TCP, TLS et d’application autour de la réinitialisation.
- Utilisez les journaux du serveur/de l'équilibreur de charge pour confirmer l'attribution.
Diagnostic final
TCP RST est un abandon de connexion, mais la raison dépend du timing et de l'expéditeur. Un pcap peut distinguer un port fermé, un rejet de pare-feu, un rejet TLS, une fermeture d'application, un délai d'inactivité, une défaillance de l'équilibreur de charge et une réinitialisation du boîtier de médiation.
PCAP Surgery aide à préserver la séquence de paquets qui répond à la question la plus importante : qui a réinitialisé la connexion et que s’est-il passé juste avant ?