Isolando Problemas onde o ISA Server Parece ser o Culpado – Sessão 1

Por: Yuri Diógenes

1. Introdução

O ISA Server tem uma função chave em uma organização, pois muitas vezes é dele a responsabilidade de autenticar os usuários que saem para Internet, os usuários que possivelmente entram para acessar recursos internos ou permitir ou não a publicação de recursos internos para a rede externa. Devido a isso muitas vezes existem problemas onde tudo leva a crer que o servidor ISA é o culpado, e a prática vem mostrando que muitas vezes de fato o ISA é uma vítima no processo de interoperabilidade com outros componentes.

Este artigo tem como principal foco a idéia de que é possível você levantar dentro de um cenário de problema que envolva o servidor ISA as questões chave para entender se de fato o ISA é ou não o culpado.

2. Entendendo o que de Fato Está Acontecendo

Um dos principais pontos a ser considerado durante a resolução de um problema que envolva de certa forma o servidor ISA é fazer um levantamento do cenário atual para entender como este serviço porventura poderia estar causando tal problema. Não se deixe envolver pelo pensamento: “o pacote está passando pelo ISA e não funciona, então tem que ser o ISA” . Este pensamento pode levar você a um caminho totalmente errado durante a resolução do problema, por isso é importante acessar o ambiente de forma neutra, entender o que está acontecendo sem tentar de imediato achar culpados.

Muitas vezes deixamos para entender melhor o próprio ambiente que trabalhamos durante uma emergência, o que é totalmente errado em todos os aspectos. É preciso que você mantenha um mapa topológico da sua rede atualizado e contendo todos os dispositivos que estão de fato conectados à rede. Um diagrama de rede deveria conter pelo menos os elementos abaixo:

  • Nome e endereço IP dos hosts (quando falo host estou me referindo a qualquer dispositivo TCP/IP compatível);
  • Esquema de subredes;
  • Dispositivos de rede (Switch, Roteador, Firewall, IDS, etc);

Outros elementos podem ser adicionados, porém pelo menos os componentes acima precisam ser documentados e atualizados sempre que há mudanças que afetem tal estrutura.

Com base neste diagrama é possível entender qual a função do ISA dentro do ambiente e como ele está de fato conectado a rede.

Mesmo que você seja o administrador da rede não menospreze a revisão do ambiente, muitas vezes o excesso de confiança leva a resultados não agradáveis no que tange o isolamento de problemas e posteriormente a determinação da causa raiz. Por isso, revise seu diagrama e procure ver se algo mudou e você não tomou conhecimento. Hoje em dia é muito comum que tenhamos administradores de servidores em uma equipe, administradores de aplicações em outra, administradores de equipamentos de conectividade em outra e pessoal de segurança em outra. Muitas vezes tais equipes até procuram trabalhar de forma sincronizada, mas muitas vezes a “correria” do dia a dia faz com que ações sejam tomadas e nem sempre documentadas.

Agora que você já tem uma idéia do que fazer antes de iniciar a resolução de problemas em situações que envolvem o servidor ISA então podemos iniciar a explicação sobre os cenários. Serão apresentados quatro cenários onde o ISA é acusado de ser a causa raiz para o problema, porém após obtenção dos dados e análise é determinado que o ISA não é o culpado.

Para otimizar a leitura e não estender demasiadamente o tema em um só “post”, irei dividir os cenários em sessões. Esta será a primeira sessão. Semana que vem irei postar mais uma em um total de quatro sessões.

OBS: O cenário abaixo é baseado em um caso real que trabalhei, porém os endereços IP e os nomes foram alterados para preservar a identidade da rede do cliente.

3. Cenário 1 – Não é Possível Acessar Páginas Seguras (HTTPS)

Neste cenário as estações clientes que estão atrás de um servidor ISA não conseguem acessar sites que utilizem HTTPS. Todas às páginas são acessadas com sucesso, porém HTTPS não funciona e retorna um erro de DNS não encontrado. O administrador do servidor ISA fez um levantamento inicial da topologia e apresentou como sendo a mesma mostra a seguir:

 

Figura 1 – Topologia levantada pelo administrador dos servidores Windows

Note que na topologia levantada inicialmente pelo administrador de rede temos um ambiente onde em frente ao servidor ISA temos um outro Firewall. Porém o administrador diz ter feito um teste que foi crucial na determinação que o servidor ISA de fato era o causador do problema. Um notebook foi conectado na switch que está ligada diretamente na placa de rede interna deste Firewall, através deste notebook foi então possível acessar páginas que usam HTTPS sem nenhum problema.

Neste momento os indícios de fato levam a crer que o servidor ISA é o culpado, porém apenas este teste não é suficiente para de fato “bater o martelo” e assegurar que é o ISA que está causando isso. É nessa hora que entra em cena às perguntas que podem lhe ajudar a determinar a causa raiz. Neste cenário podemos listar as seguintes perguntas:

  • Quando este problema começou a ocorrer?
  • O que mudou no ambiente?
  • Este é o único caminho de saída para Internet ou você teria outro?
  • Você teria um outro servidor ISA?
    • Esse problema também ocorre neste servidor ISA?

Estas perguntas servem para você identificar primeiramente se esta é uma implementação nova e nunca funcionou ou se ela estava funcionando perfeitamente e algo ocorreu. Segundo é importante tentar identificar se existe uma outra forma de acessar à Internet que não seja passando por este caminho, pois lembre-se que no diagrama existe um Firewall na frente do ISA, então temos que tentar entender se o mesmo comportamento acontece colocando o ISA diretamente na Internet.

3.1. Testes

Se existir um outro ISA na rede (mesmo que seja remoto) um teste crucial a ser realizado é fazer um “Proxy Chain”, ou seja, conectar o ISA que não funciona a um ISA que funciona para tentar sair para Internet por um outro caminho.

Vejamos então os testes realizados:

Teste

Resultado

Fazer um Proxy Chain com Outro Servidor ISA

Acesso à páginas HTTPS funcionou com sucesso

Usar outro “Default Gateway” para o ISA sair para Internet por outro caminho

Acesso à páginas HTTPS funcionou com sucesso

Apesar dos testes o administrador de rede não estava convencido, então entra o momento da coleta de dados para que seja possível determinar a causa raiz com mais precisão e ter mais argumentos para provar que o ISA não é o culpado.

3.2. Coletas

Uma das melhores formas de obter um conjunto consistente de informações sobre o servidor ISA é usando a ferramenta ISA BPA (Best Practices Analyzer Tool), mas precisamente um utilitário disponível na pasta em que a ferramenta é instalada. Trata-se do ISA BPA Package em modo de reprodução do problema (Repro Mode). Siga os passos abaixo para executar:

  1. Antes de habilitar o BPA Package, habilite também o Log do ISA para o tráfego recebido da estação cliente (Para um exemplo de como fazer isso veja a sessão 3, passo 2 do artigo “Acesso a Páginas Web com Uso de contas Genéricas no ISA”;
  2. Entre no prompt de comando no servidor ISA;
  3. Acesse o local onde a ferramenta foi instalada (neste caso será C:\Program Files\Microsoft ISABPA)
  4. Execute o utilitário Isabpapack.exe
  5. Pressione Y (YES) para habilitar entrar em “Repro Mode”;
  6. Neste momento o utilitário “netcap” vai iniciar uma captura de rede em todas interfaces do servidor ISA;
  7. A partir da estação de trabalho com problema tente acessar o site que usa HTTPS e quando o problema acontecer volte no ISA e pare a captura.

Neste momento os seguintes arquivos serão gerados:

  • ISA BPA Report (Arquivo XML)
  • Regras e Configração do ISA (Arquivo XML)
  • Captura de rede Netmon para todas interfaces do ISA (Arquivo CAP)
  • “Trace” de baixo nível do servidor ISA (Arquivo BIN)
  • Event Viewer – Eventos relacionados ao ISA (Arquivo CSV)
  • Dados de Performance do ISA (Arquivo TXT)

Como você pode ver trata-se de um pacote bastante completo de informações sobre o ISA.

3.3. Análise

Para fazer a leitura das regras de configuração do ISA (arquivo XLM) foi usado a ferramenta ISAInfo (Disponível para download em https://isatools.org/isainfo/isainfo.zip). É uma ferramenta simples, porém apresenta os resultados organizados hierarquicamente facilitando com isso a leitura.

Figura 2 – Exemplo da interface gráfica do ISAInfo

Durante à análise dos dados foi possível observar que na hora do problema o servidor ISA registrava o erro 0x80074e20 no Log que foi capturado. Este erro significa: “A connection was gracefully closed in an orderly shutdown process with a three-way FIN-initiated handshake”. Que em suma significa dizer que o ISA parou a conexão pois um segmento TCP-FIN (finalização) foi recebido da outra ponta. Procurando mais evidências, vimos na captura de rede que a negociação SSL não era finalizada e que a outra ponta é quem mandava o “reset” da comunicação.

Vejamos abaixo um resumo do que foi encontrado:

· Temos inicialmente o TCP 3 Way Handshake:

10.10.9.1 ExternalServer TCP 4559 > https [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460

ExternalServer 10.10.9.1 TCP https > 4559 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460

10.10.9.1 ExternalServer TCP 4559 > https [ACK] Seq=1 Ack=1 Win=65535 Len=0

· Após isso o ISA envia o pacote “SSL Hello” para informar as especificações de Cipher que são suportadas:

10.10.9.1 ExternalServer SSLv2 Client Hello

Secure Socket Layer

SSLv2 Record Layer: Client Hello

Length: 43

Handshake Message Type: Client Hello (1)

Version: SSL 2.0 (0x0002)

Cipher Spec Length: 18

Session ID Length: 0

Challenge Length: 16

Cipher Specs (6 specs)

Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080)

Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0)

Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080)

Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040)

Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080)

Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080)

Challenge

· O servidor Externo envia a resposta e concordando com a versão em uso:

ExternalServer 10.10.9.1 SSLv2 Server Hello

· Logo após isso o servidor externo continua a negociação SSL e em seguida envia um “reset” da comunicação:

ExternalServer 10.10.9.1 SSLv2 Client Master Key

ExternalServer 10.10.9.1 TCP https > 4559 [RST] Seq=1064 Ack=848429151 Win=0 Len=0

Como é possível ver o ISA não se comportando de forma a influenciar diretamente na causa raiz do problema.

OBS: Para maiores informações sobre como funciona o processo de negociação SSL veja o artigo “How TLS/SSL Works” no Microsoft TechNet.

Após tais evidências o administrador ficou convencido e com argumentos suficientes para levar a tema para uma reunião com as outras equipes responsáveis pelos outros elementos de rede.

4. Conclusão

Após esta reunião interna foi possível identificar que a topologia que o administrador Windows pensava ser real, de fato estava errada. O diagrama correto era o mostrado a seguir:

Figura 3 – Real topologia do Ambiente

Foi constatado havia um analisador de conteúdo entre o servidor ISA e o Firewall e este analisador é quem estava causando problemas na negociação SSL. Colocamos a interface externa do ISA diretamente na switch que estava localizada atrás do Firewall e o problema parou de ocorrer.

Neste primeiro cenário ficou claro que muitas vezes o não correto sincronismo entre as equipes internas de uma empresa pode causar situações onde um produto pode parecer o culpado de algo. Note que tecnicamente falando o caso foi mais para provar que nada de errado havia e nenhuma ação técnica e corretiva foi realizada de fato.

Continue acompanhando as sessões, a próxima será sobre um problema de acesso a uma VPN externa usando um cliente VPN de terceiros e passando pelo servidor ISA.