Tracciare il processo di autenticazione di rete al motore di database

Questo articolo presenta diversi esempi di traccia di rete che acquisisce varie sequenze di handshake e di autenticazione durante il processo di definizione della connessione TCP (Transmission Control Protocol) tra un'applicazione client e sql Server motore di database (il server).

Per informazioni sulla chiusura delle connessioni, vedere Tracciare la sequenza di chiusura della connessione di rete nel motore di database.

Tipi di autenticazione

È possibile connettersi al motore di database con l'autenticazione di Windows (usando l'autenticazione Kerberos o NTLM) o l'autenticazione SQL.

Questo articolo descrive anche le connessioni MARS (Multiple Active Result Sets). MARS è una funzionalità di SQL Server, introdotta con SQL Server 2005 (9.x), che consente l'esecuzione di più comandi in una connessione senza dover pulire i risultati dal primo comando, prima di eseguire il secondo comando. MARS viene ottenuto tramite multiplexing di sessione (SMUX).

Questo processo descrive un normale processo di accesso tramite l'autenticazione SQL, che mostra ogni passaggio della conversazione tra il client e il server tramite un'analisi dettagliata della traccia di rete. La traccia di rete di esempio delinea i passaggi seguenti:

  1. Handshake a tre vie TCP
  2. Handshake driver
  3. Handshake SSL/TLS
  4. Scambio di pacchetti di accesso
  5. Conferma dell'accesso
  6. Eseguire un comando e leggere la risposta
  7. Handshake di chiusura a quattro vie TCP

Traccia di rete di esempio

Questo scambio viene allocato 1 secondo indipendentemente dall'impostazione Login Timeout nel stringa di connessione.

  • L'indirizzo IP del client è 10.10.10.10
  • L'indirizzo IP del server è 10.10.10.120

Passaggio 1: Handshake a tre vie TCP

Tutte le conversazioni TCP iniziano con un SYN pacchetto (S set di flag) inviato dal client al server. In Frame 6127il client usa una porta temporanea (assegnata dinamicamente dal sistema operativo) e si connette alla porta del server, in questo caso la porta 1433. Anche il server risponde con il proprio SYN pacchetto con il ACK flag impostato. Infine, il client risponde con un ACK pacchetto per comunicare al server che ha ricevuto il pacchetto SYN .

Questo passaggio stabilisce una connessione TCP di base, allo stesso modo di un telnet comando. Il sistema operativo media questa parte della conversazione. A questo punto, il client e il server non sanno nulla tra loro.

Diagramma dell'handshake a tre vie.

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=

In questo passaggio, gli avvisi sono benigni e sono un indicatore che l'offload [Bad CheckSum] checksum è abilitato. Ovvero, vengono aggiunti a un livello inferiore nello stack di rete rispetto all'analisi eseguita. In assenza di altre informazioni, questo avviso indica se la traccia di rete è stata eseguita sul client o sul server. In questo caso, viene visualizzato nel pacchetto iniziale SYN , quindi la traccia è stata eseguita sul client.

Passaggio 2. Handshake driver

Sia il driver client che SQL Server devono conoscere un po' l'uno sull'altro. In questo handshake, il driver invia alcune informazioni e requisiti al server. Queste informazioni includono se crittografare i pacchetti di dati, se usare mars (Multiple Active Result Sets), il relativo numero di versione, se usare l'autenticazione federata, il GUID di connessione e così via.

Il server risponde con le relative informazioni, ad esempio se richiede l'autenticazione. Questa sequenza si verifica prima dell'esecuzione di qualsiasi tipo di negoziazione di sicurezza.

Diagramma dell'handshake del driver.

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

Passaggio 3. Handshake SSL/TLS

L'handshake SSL/TLS inizia con il pacchetto Client Hello e quindi il pacchetto Server Hello, oltre ad alcuni pacchetti aggiuntivi correlati a Secure Channel. Questo passaggio consente di negoziare la chiave di sicurezza per crittografare i pacchetti. In genere, solo il pacchetto di accesso è crittografato, ma anche il client o il server potrebbe richiedere la crittografia dei pacchetti di dati. La scelta della versione di TLS avviene in questa fase dell'account di accesso. Il client o il server può chiudere la connessione in questa fase se le versioni TLS non sono in linea o non hanno pacchetti di crittografia in comune.

Diagramma dell'handshake 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

Passaggio 4. Pacchetto di accesso

Questo pacchetto è crittografato e può essere visualizzato come SSL Application Data o TDS:Data, a seconda del parser di rete. Se anche tutti i pacchetti dopo questo passaggio vengono visualizzati come SSL Application Data, la connessione viene crittografata.

Diagramma dell'account di accesso 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

Passaggio 5. Conferma dell'accesso

In caso contrario, viene visualizzato un pacchetto di risposta che conferma l'accesso (con il token di accesso ACK ) o restituisce un Login Failed messaggio di errore al client.

Di seguito è riportato un esempio di ciò che è possibile visualizzare nei dati esadecimali dei pacchetti per un account di accesso riuscito:

.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'

Diagramma della conferma dell'accesso 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

Passaggio 6. Eseguire un comando e leggere la risposta

I comandi vengono inviati come pacchetto TDS:SQLBatch o TDS:RPCRequest . Il primo esegue istruzioni Transact-SQL semplici e quest'ultimo esegue stored procedure. È possibile che vengano visualizzati pacchetti di continuazione TCP se il comando è lungo o nel pacchetto Response se vengono restituite più righe.

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=

Passaggio 7. Handshake di chiusura a quattro vie TCP

I driver Microsoft usano l'handshake a quattro vie per chiudere le connessioni. Molti driver di terze parti reimpostano semplicemente la connessione per chiuderla, rendendo più difficile distinguere tra una chiusura normale e anomala.

L'handshake a quattro vie consiste nell'inviare un FIN pacchetto al server, a cui il server risponde con un oggetto ACK. Il server invia quindi il proprio FIN pacchetto, che il client riconosce (ACK).

Se il server invia prima un pacchetto, si tratta di una FIN chiusura anomala, più comunemente visualizzata nell'handshake SSL/TLS se il client e il server non possono negoziare il canale sicuro.

Diagramma dell'handshake di chiusura a quattro vie.

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=