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 da 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 seqüê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 a autenticação Kerberos ou NTLM ) ou autenticação SQL .

Este artigo também descreve conexões MARS (Conjuntos de Resultados Múltiplos Ativos). 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 por meio de multiplexação de sessão (SMUX).

Esse processo descreve um processo de login normal usando 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 exemplo de rastreamento de rede delineia as seguintes etapas:

  1. Handshake 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. Handshake de fechamento de quatro vias TCP

Exemplo de rastreamento de rede

Essa troca é alocada por 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. Handshake 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 que o servidor saiba que recebeu seu SYN pacote.

Esta etapa estabelece uma conexão TCP básica, da mesma forma que um telnet comando 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 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 inferior 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 inicial SYN , portanto, o rastreamento foi feito no cliente.

Etapa 2. Aperto de mão do motorista

Tanto o driver cliente quanto o SQL Server precisam saber um pouco um sobre o outro. Nesse 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 MARS (Vários Conjuntos de Resultados Ativos), seu número de versão, se devem ser usados a autenticação federada, o GUID da conexão e assim por diante.

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

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

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 neste estágio do login. O cliente ou servidor pode fechar a conexão neste estágio se as versões do TLS não se alinharem ou não tiverem nenhum conjunto de criptografia em comum.

Diagrama do 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 esta etapa também forem exibidos 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 login (tem o token de login ACK ) ou retorna uma mensagem de Login Failed erro ao 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 da confirmação de login do 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 último executa procedimentos armazenados. Você poderá ver pacotes de continuação TCP se o comando for longo ou no pacote de resposta se mais do que 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. Handshake de fechamento de quatro vias TCP

Os drivers da Microsoft usam o handshake de quatro vias para fechar as 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 envio de um FIN pacote ao servidor pelo cliente, ao qual o servidor responde com um ACK. O servidor então envia seu próprio FIN pacote, que o cliente reconhece (ACK).

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

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