Problema: The system detected a possible attempt to compromise security (Parte 1)

  • [アーティクル]

Hoje me deparei com um problema bastante interessante em um servidor SQL e gostaria de compartilhar: o servidor retornava erro ao rodar a stored procedure sp_readerrorlog.

Msg 22004, Level 16, State 1, Line 0
Failed to open loopback connection. Please see event log for more information.
Msg 22004, Level 16, State 1, Line 0
error log location not found

Consultando o Event Log, encontrava-se a seguinte mensagem de erro:

Severity: 16 Error:-2146892976, OS: -2146892976 [Microsoft][SQL Server Native Client 10.0]SQL Server Network Interfaces: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

Nesse momento, o que fazer?

 

Decifrando o Código do Erro

Note que a mensagem de erro do Sistema Operacional é um número negativo (-2146892976). O seu significado está escondido na representação hexadecimal.

O primeiro passo é converter o número –2146892976, que corresponde a 0x80090350 em hexadecimal. A partir daqui fica mais fácil procurar pelo código de erro (https://www.bing.com/search?q=0x80090350) e encontrar a correspondência por SEC_E_DOWNGRADE_DETECTED.

 

Identificando a Origem do Erro

Após a descoberta do erro SEC_E_DOWNGRADE_DETECTED, o próximo passo é isolar qual componente está relacionado com o problema. Basta analisar com calma as mensagens de erro e a resposta aparecerá.

Msg 22004, Level 16, State 1, Line 0
Failed to open loopback connection. Please see event log for more information.

Severity: 16 Error:-2146892976, OS: -2146892976 [Microsoft][SQL Server Native Client 10.0]SQL Server Network Interfaces: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

Captou? Ao executar a procedure sp_readerrorlog, houve a tentativa de abrir uma conexão com o próprio servidor (loopback connection) usando o provider SQL Server Native Client. Essa abertura de conexão falhou, retornando o erro 0x80090350.

O erro ocorreu durante a abertura de uma nova conexão. Por incrível que pareça, houve um erro na autenticação dentro do próprio servidor!

 

Falha de Autenticação

A sequência dos fatos foi assim:

  • DBA chama a stored procedure sp_readerrorlog
  • A procedure inicia uma abertura de um loopback connection
  • Durante o processo de autenticação, ocorre o erro SEC_E_DOWNGRADE_DETECTED

Seria possível ocorrer uma falha de autenticação dentro do próprio servidor? Refiz essa pergunta a colegas que são mestres no assunto e recebi a resposta:

SEC_E_DOWNGRADE_DETECTED means that Kerberos failed with an unexpected error, and will not fall back to NTLM, common causes for this one: #1 domain controller cannot be found? (kerberos UDP?) or fragmentation issues (move to kerberos over TCP), so answering your question: yes could be a transient condition, but if happens regularly, netmon traces will be next step (kerberos logging might be helpful too)

A resposta é SIM, falha de autenticação pode ocorrer. No nosso caso, houve uma falha do Kerberos que causou esse tipo de comportamento.

 

Resolução do Erro

Após poucos minutos, o problema desapareceu. Mas caso continuasse, o próximo passo seria investigar a comunicação com o Domain Controller usando o Network Monitor (ou ferramentas semelhantes para captura de pacotes de rede).

Esse problema foi ocasionado por um fator externo ao SQL Server.

 

Loopback Connection

Por que o comando sp_readerrorlog precisaria abrir uma conexão loopback? Segue uma captura do Profiler com a resposta:

image

Comments

  • Anonymous
    January 11, 2011
    Fabricio você não postou as outras partes? Uma coisa que eu penso é que o protocolo Kerberos não é usado localmente. Só quando se acessa algo remoto, já que esse protocolo precisa acessar o Domain Controller. Não entendo bem o porque isso aconteceu é bem estranho. Vi esse evento no log do meu Log Shipping quando levei uma máquina para outro servidor e ela teve que autenticar em outro domínio.

  • Anonymous
    January 26, 2011
    Pior que não! Esse foi um dos primeiros posts e não tinha me habituado ao jeito de "blogar". Então escrevi várias partes e depois consolidei praticamente tudo na Parte 1. Havia uma parte 2, que era bem mais complexa e acabei desistindo de colocar (na verdade, nem eu tinha entendido direito o que havia escrito). Voce disse certo: NTLM é usado para autenticação local, então, por que o Kerberos? Não sei... existe uma DMV chamada sys.dm_os_ring_buffers, que contém os Return Code referentes à interface de segurança. Acredito que a resposta esteja por lá. Como esse evento parou de acontecer, então não pude testar. Obrigado pelo comentário e mande notíficas se tiver ocorrendo esse problema no seu servidor. Abraços, Fabricio