Partage via

Tracez le processus d’authentification réseau vers le Moteur de base de données

  • Article

Cet article présente plusieurs exemples de trace réseau qui capture différentes liaisons et séquences d’authentification pendant le processus d’établissement de connexion TCP (Transmission Control Protocol) entre une application cliente et sql Server Moteur de base de données (le serveur).

Pour plus d’informations sur la fermeture des connexions, consultez Tracer la séquence de fermeture de connexion réseau sur le Moteur de base de données.

Types d’authentification

Vous pouvez vous connecter au Moteur de base de données avec l’authentification Windows (à l’aide de l’authentification Kerberos ou NTLM) ou de l’authentification SQL.

Cet article décrit également plusieurs connexions MARS (Active Result Sets). MARS est une fonctionnalité de SQL Server, introduite avec SQL Server 2005 (9.x), qui permet l’exécution de plusieurs commandes sur une connexion sans avoir à nettoyer les résultats de la première commande, avant d’exécuter la deuxième commande. MARS est obtenu via le multiplexage de session (SMUX).

Ce processus décrit un processus de connexion normal à l’aide de l’authentification SQL, montrant chaque étape de la conversation entre le client et le serveur via une analyse détaillée des traces réseau. L’exemple de trace réseau délimite les étapes suivantes :

  1. Liaison tcp tridirectionnel
  2. Établissement d’une liaison de pilote
  3. Liaison SSL/TLS
  4. Échange de paquets de connexion
  5. Confirmation de connexion
  6. Exécuter une commande et lire la réponse
  7. Négociation fermante TCP à quatre voies

Exemple de trace réseau

Cet échange est alloué 1 seconde, quel que soit le Login Timeout paramètre de la chaîne de connexion.

  • L’adresse IP du client est 10.10.10.10
  • L’adresse IP du serveur est 10.10.10.120

Étape 1. Liaison tcp tridirectionnel

Toutes les conversations TCP commencent par un paquet (Sjeu d’indicateursSYN) envoyé du client au serveur. Dans Frame 6127, le client utilise un port éphémère (affecté dynamiquement par le système d’exploitation) et se connecte au port du serveur, dans ce cas le port 1433. Le serveur répond avec son propre SYN paquet avec l’indicateur ACK également défini. Enfin, le client répond avec un ACK paquet pour informer le serveur qu’il a reçu son SYN paquet.

Cette étape établit une connexion TCP de base, de la même façon qu’une telnet commande. Le système d’exploitation médiate cette partie de la conversation. À ce stade, le client et le serveur ne connaissent rien les uns des autres.

Diagramme de l’établissement d’une négociation tridirectionnel. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6127  116.5776698 10.10.10.10  10.10.10.120 TCP:Flags=......S., SrcPort=60123, DstPort=1433, PayloadLen=0, Seq=4050702293, Ack=0, Win=8192 ( Ne
6128  116.5776698 10.10.10.120 10.10.10.10  TCP:Flags=...A..S., SrcPort=1433, DstPort=60123, PayloadLen=0, Seq=4095166896, Ack=4050702294, Win=
6129  116.5786458 10.10.10.10  10.10.10.120 TCP:Flags=...A...., SrcPort=60123, DstPort=1433, PayloadLen=0, Seq=4050702294, Ack=4095166897, Win=

Dans cette étape, les [Bad CheckSum] avertissements sont bénins et sont un indicateur indiquant que le déchargement de somme de contrôle est activé. Autrement dit, ils sont ajoutés à un niveau inférieur dans la pile réseau que la trace est effectuée. En l’absence d’autres informations, cet avertissement indique si la trace réseau a été effectuée sur le client ou le serveur. Dans ce cas, il apparaît sur le paquet initial SYN , de sorte que la trace a été effectuée sur le client.

Étape 2. Établissement d’une liaison de pilote

Le pilote client et SQL Server doivent connaître un peu les uns les autres. Dans cette négociation, le pilote envoie des informations et des exigences au serveur. Ces informations incluent s’il faut chiffrer les paquets de données, s’il faut utiliser plusieurs jeux de résultats actifs (MARS), son numéro de version, s’il faut utiliser l’authentification fédérée, le GUID de connexion, et ainsi de suite.

Le serveur répond avec ses informations, par exemple s’il nécessite une authentification. Cette séquence se produit avant toute négociation de sécurité effectuée.

Diagramme de l’établissement d’une liaison de pilote. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6130  116.5786458 10.10.10.10  10.10.10.120 TDS:Prelogin, Version = 7.1 (0x71000001), SPID = 0, PacketID = 0, Flags=...AP..., SrcPort=60123, Ds
6131  116.5805998 10.10.10.120 10.10.10.10  TDS:Response, Version = 7.1 (0x71000001), SPID = 0, PacketID = 1, Flags=...AP..., SrcPort=1433, Dst

Étape 3. Liaison SSL/TLS

L’établissement d’une liaison SSL/TLS commence par le paquet Client Hello, puis le paquet Server Hello, ainsi que certains paquets supplémentaires liés au canal sécurisé. Cette étape consiste à négocier la clé de sécurité pour le chiffrement des paquets. Normalement, seul le paquet de connexion est chiffré, mais le client ou le serveur peut également nécessiter le chiffrement des paquets de données. Le choix de la version de TLS se produit à ce stade de la connexion. Le client ou le serveur peut fermer la connexion à ce stade si les versions TLS ne s’alignent pas ou n’ont pas de suites de chiffrement en commun.

Diagramme de la négociation SSL/TLS. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6132  116.5835288 10.10.10.10  10.10.10.120 TLS:TLS Rec Layer-1 HandShake: Client Hello. {TLS:328, SSLVersionSelector:327, TDS:326, TCP:325, IP
6133  116.5845058 10.10.10.120 10.10.10.10  TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Hello Done. {TLS:328, SSLVersionSe
6134  116.5864588 10.10.10.10  10.10.10.120 TLS:TLS Rec Layer-1 HandShake: Client Key Exchange.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec La
6135  116.5923178 10.10.10.120 10.10.10.10  TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message. {TL

Étape 4. Paquet de connexion

Ce paquet est chiffré et peut s’afficher en fonction SSL Application Data de TDS:Datal’analyseur réseau. Si tous les paquets après cette étape s’affichent également comme SSL Application Data, la connexion est chiffrée.

Diagramme de connexion SQL. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6136  116.5932948 10.10.10.10  10.10.10.120 TLS:TLS Rec Layer-1 SSL Application Data {TLS:328, SSLVersionSelector:327, TDS:326, TCP:325, IPv4:3

Étape 5. Confirmation de connexion

Sinon, vous voyez un paquet de réponse, qui confirme la connexion (a le jeton de connexion ACK ) ou retourne un Login Failed message d’erreur au client.

Voici un exemple de ce que vous pouvez voir dans les données hexadécimales de paquets pour une connexion réussie :

.C.h.a.n.g.e.d. .d.a.t.a.b.a.s.e. .c.o.n.t.e.x.t. .t.o. .'.A.d.v.e.n.t.u.r.e.W.o.r.ks'

Diagramme de confirmation de connexion SQL. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6137  116.5962248 10.10.10.120 10.10.10.10  TDS:Response, Version = 7.1 (0x71000001), SPID = 96, PacketID = 1, Flags=...AP..., SrcPort=1433, Ds

Étape 6. Exécuter une commande et lire la réponse

Les commandes sont envoyées sous la forme d’un TDS:SQLBatch ou d’un TDS:RPCRequest paquet. L’ancien exécute des instructions Transact-SQL simples, et celui-ci exécute des procédures stockées. Vous pouvez voir des paquets de continuation TCP si la commande est longue ou dans le paquet réponse si plusieurs lignes sont retournées.

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6138  116.5991538 10.10.10.10  10.10.10.120 TDS:SQLBatch, Version = 7.1 (0x71000001), SPID = 0, PacketID = 1, Flags=...AP..., SrcPort=60123, Ds
6139  116.5991538 10.10.10.120 10.10.10.10  TDS:Response, Version = 7.1 (0x71000001), SPID = 96, PacketID = 1, Flags=...AP..., SrcPort=1433, Ds
6266  116.8032558 10.10.10.10  10.10.10.120 TCP:Flags=...A...., SrcPort=60123, DstPort=1433, PayloadLen=0, Seq=4050702956, Ack=4095168204, Win=

Étape 7. Négociation fermante TCP à quatre voies

Les pilotes Microsoft utilisent l’établissement d’une liaison bidirectionnel pour fermer les connexions. De nombreux pilotes tiers réinitialisent simplement la connexion pour la fermer, ce qui rend plus difficile la distinction entre une fermeture normale et anormale.

La négociation bidirectionnel se compose du client qui envoie un FIN paquet au serveur, auquel le serveur répond avec un ACK. Le serveur envoie ensuite son propre FIN paquet, que le client reconnaît (ACK).

Si le serveur envoie d’abord un FIN paquet, il s’agit d’une fermeture anormale, le plus souvent observée dans l’établissement d’une liaison SSL/TLS si le client et le serveur ne peuvent pas négocier le canal sécurisé.

Diagramme de l’établissement d’une liaison fermante à quatre voies. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6362  116.9097008 10.10.10.10  10.10.10.120 TCP:Flags=...A...F, SrcPort=60123, DstPort=1433, PayloadLen=0, Seq=4050702956, Ack=4095168204, Win=
6363  116.9097008 10.10.10.120 10.10.10.10  TCP:Flags=...A...., SrcPort=1433, DstPort=60123, PayloadLen=0, Seq=4095168204, Ack=4050702957, Win=
6364  116.9097008 10.10.10.120 10.10.10.10  TCP:Flags=...A...F, SrcPort=1433, DstPort=60123, PayloadLen=0, Seq=4095168204, Ack=4050702957, Win=
6366  116.9106778 10.10.10.10  10.10.10.120 TCP:Flags=...A...., SrcPort=60123, DstPort=1433, PayloadLen=0, Seq=4050702957, Ack=4095168205, Win=

Contenu connexe