Partilhar via

Rastrear o processo de autenticação de rede até o Mecanismo de Banco de Dados

  • Artigo

Este artigo apresenta vários exemplos de um rastreamento de rede que captura vários handshakes e sequências de autenticação durante o processo de estabelecimento de conexão TCP (Transmission Control Protocol) entre um aplicativo cliente e o Mecanismo de Banco de Dados do SQL Server (o servidor).

Para obter informações sobre como fechar conexões, consulte Rastrear a sequência de fechamento da conexão de rede no Mecanismo de Banco de Dados.

Tipos de autenticação

Você pode se conectar ao Mecanismo de Banco de Dados com autenticação do Windows (usando Kerberos ou autenticação NTLM) ou autenticação SQL.

Este artigo também descreve conexões MARS (Multiple Ative Result Sets). O MARS é um recurso do SQL Server, introduzido com o SQL Server 2005 (9.x), que permite que vários comandos sejam executados em uma conexão sem ter que limpar os resultados do primeiro comando, antes de executar o segundo. MARS é alcançado através de multiplexagem de sessões (SMUX).

Este processo descreve um processo de login normal usando autenticação SQL, mostrando cada etapa da conversa entre o cliente e o servidor através de uma análise detalhada de rastreamento de rede. O exemplo de rastreamento de rede delineia as seguintes etapas:

  1. Aperto de mão de três vias TCP
  2. Aperto de mão do motorista
  3. Aperto de mão SSL/TLS
  4. Troca de pacotes de login
  5. Confirmação de login
  6. Execute um comando e leia a resposta
  7. Finalização de conexão TCP em quatro etapas

Exemplo de rastreamento de rede

Esta troca tem uma alocação de 1 segundo, independentemente da configuração da Login Timeout na cadeia de conexão.

  • O endereço IP do cliente é 10.10.10.10
  • O endereço IP do servidor é 10.10.10.120

Passo 1. Aperto de mão de três vias TCP

Todas as conversas TCP começam com um pacote SYN (conjunto de sinalizadoresS) enviado do cliente para o servidor. No Frame 6127, o cliente usa uma porta efêmera (atribuída dinamicamente pelo sistema operacional) e se conecta à porta do servidor, neste caso a porta 1433. O servidor responde com seu próprio pacote de SYN com o sinalizador ACK também definido. Finalmente, o cliente responde com um pacote ACK para informar ao servidor que recebeu seu pacote SYN.

Esta etapa estabelece uma conexão TCP básica, da mesma forma que um comando telnet faria. O sistema operacional medeia essa parte da conversa. Neste ponto, o cliente e o servidor não sabem nada um sobre o outro.

Diagrama do triplo aperto de mão. 

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=

Nesta etapa, os avisos de [Bad CheckSum] são benignos e são um indicador de que o descarregamento de soma de verificação está habilitado. Ou seja, eles são adicionados em um nível mais baixo na pilha de rede do que o rastreamento é feito. Na ausência de outras informações, esse aviso indica se o rastreamento de rede foi feito no cliente ou no servidor. Nesse caso, ele aparece no pacote de SYN inicial, então o rastreamento foi feito no cliente.

Passo 2. Aperto de mão do motorista

Tanto o driver do cliente quanto o SQL Server precisam saber um pouco um sobre o outro. Neste handshake, o driver envia algumas informações e requisitos para o servidor. Essas informações incluem se os pacotes de dados devem ser criptografados, se o MARS (Multiple Ative Result Sets) deve ser usado, seu número de versão, se a autenticação federada deve ser usada, o GUID de conexão e assim por diante.

O servidor responde com suas informações, como se requer autenticação. Essa sequência acontece antes de qualquer tipo de negociação de segurança ser realizada.

Diagrama do aperto de mão do motorista. 

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

Passo 3. Aperto de mão SSL/TLS

O handshake SSL/TLS começa com o pacote Client Hello e, em seguida, o pacote Server Hello, além de alguns pacotes extras relacionados ao Secure Channel. Esta etapa é onde a chave de segurança é negociada para criptografar pacotes. Normalmente, apenas o pacote de login é criptografado, mas o cliente ou o servidor pode exigir que os pacotes de dados também sejam criptografados. A escolha da versão do TLS acontece nesta etapa do login. O cliente ou servidor pode fechar a conexão neste estágio se as versões TLS não estiverem alinhadas ou se não tiverem nenhum conjunto de codificação em comum.

diagrama de aperto de mão 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

Passo 4. Pacote de login

Este pacote é encriptado e pode ser apresentado como SSL Application Data ou TDS:Data, dependendo do seu analisador de rede. Se todos os pacotes após esta etapa também aparecerem como SSL Application Data, a conexão será criptografada.

Diagrama de login 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

Passo 5. Confirmação de login

Caso contrário, você verá um pacote de resposta, que confirma o login (tem o token de login ACK) ou retorna uma mensagem de erro Login Failed para o cliente.

Aqui está um exemplo do que você pode ver nos dados hexadecimais do pacote para um login bem-sucedido:

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

Diagrama de confirmação de login 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

Passo 6. Execute um comando e leia a resposta

Os comandos são enviados como um TDS:SQLBatch ou um pacote TDS:RPCRequest. O primeiro executa instruções Transact-SQL simples e o segundo executa procedimentos armazenados. Você pode ver pacotes de continuação TCP se o comando for longo, ou no pacote de resposta se mais de algumas linhas forem retornadas.

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=

Passo 7. Aperto de mão de fechamento de quatro vias TCP

Os drivers da Microsoft usam o handshake de quatro vias para fechar conexões. Muitos drivers de terceiros apenas reiniciam a conexão para fechá-la, tornando mais difícil distinguir entre um fechamento normal e anormal.

O handshake de quatro vias consiste em o cliente enviar um pacote FIN para o servidor, ao que o servidor responde com um ACK. Em seguida, o servidor envia seu próprio pacote de FIN, que o cliente reconhece (ACK).

Se o servidor enviar primeiro um pacote FIN, trata-se de um encerramento anormal, mais comumente observado no aperto de mão SSL/TLS, caso o cliente e o servidor não consigam negociar o canal seguro.

Diagrama de aperto de mão de fechamento de quatro vias. 

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=

Conteúdo relacionado