Compartilhar 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 de 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 autenticação Kerberos ou NTLM ) ou autenticação SQL .

Este artigo também descreve várias conexões MARS (Active 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 a necessidade de limpar os resultados do primeiro comando, antes de executar o segundo comando. O MARS é obtido através da multiplexação de sessão (SMUX).

Esse processo descreve um processo de logon normal usando a autenticação SQL, mostrando cada etapa da conversa entre o cliente e o servidor por meio de uma análise detalhada de rastreamento de rede. O rastreamento de rede de exemplo delineia as seguintes etapas:

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

Exemplo de rastreamento de rede

Essa troca é alocada 1 segundo, independentemente da Login Timeout configuração 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

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

Todas as conversas TCP começam com um SYN pacote (S conjunto de sinalizadores) 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 SYN pacote com o ACK sinalizador também definido. Finalmente, o cliente responde com um ACK pacote para informar ao servidor que recebeu seu SYN pacote.

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

Diagrama de aperto de mão de três vias. 

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 são benignos e são um indicador de que o [Bad CheckSum] descarregamento da 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 é tomado. 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 inicial SYN , portanto, o rastreamento foi feito no cliente.

Etapa 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 devem ser usados vários conjuntos de resultados ativos (MARS), seu número de versão, se devem ser usados autenticação federada, o GUID de conexão e assim por diante.

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

Diagrama do handshake do 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

Etapa 3. Handshake 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 também pode exigir que os pacotes de dados sejam criptografados. A escolha da versão do TLS acontece nesta fase do login. O cliente ou servidor pode fechar a conexão neste estágio se as versões TLS não se alinharem ou não tiverem conjuntos de codificação em comum.

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

Etapa 4. Pacote de login

Esse pacote é criptografado e pode ser exibido como SSL Application Data ou TDS:Data, dependendo do analisador de rede. Se todos os pacotes após essa 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

Etapa 5. Confirmação de login

Caso contrário, você verá um pacote de resposta, que confirma o logon (tem o token de login ACK ) ou retorna uma mensagem de Login Failed erro 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

Etapa 6. Execute um comando e leia a resposta

Os comandos são enviados como um TDS:SQLBatch ou um TDS:RPCRequest pacote. O primeiro executa instruções Transact-SQL simples e o segundo executa procedimentos armazenados. Você poderá 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=

Etapa 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 redefinem a conexão para fechá-la, tornando mais difícil distinguir entre um fechamento normal e anormal.

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

Se o servidor enviar um FIN pacote primeiro, trata-se de um fechamento anormal, mais comumente visto no handshake SSL/TLS se o cliente e o servidor não puderem negociar o canal seguro.

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