As regras de firewall do ISA Server não são aplicadas como deveriam

Por: Yuri Diógenes

1. Introdução

Na semana passada trabalhei em um caso de ISA que foi bem interessante e resolvi criar este artigo para descrever o que aconteceu e qual foi a solução. Pela inicial descrição do problema parecia ser algo simples, algo que teoricamente na primeira hora de trabalho seria resolvida. Por fim foram 4 horas de trabalho e muita colaboração interna para chegar ao final, que por sua vez foi um final feliz. Quando o caso foi aberto a descrição do problema era: “Não conseguimos receber email externo devido o servidor ISA não estar respondendo na porta 25”.

Vejamos então o que foi feito...

2. O Cenário

O ambiente era semelhante ao mostrado a seguir:

Figura 1 – Topologia do ambiente.

O cliente antes usava um SMTP Relay que fica localizado na rede DMZ, porém ele não queria mais usar este servidor SMTP, então o que ele fez foi deletar a regra antiga e criou uma nova regra de publicação de correio apenas para o protocolo SMTP apontando para o servidor Exchange que está na rede interna.

O servidor Exchange por sua vez recebe mensagens internas sem problema, consegue enviar para Internet também sem nenhum problema. Em suma o erro era apenas na entrada de conexões de fora para dentro na porta TCP 25.

2.1. Testes Iniciais

Para comprovar que de fato o problema era no ISA alguns testes foram realizados previamente. Foram eles:

· Telnet na porta 25 a partir de um host na Internet – não houve resposta;

· Telnet na porta 25 a partir do próprio ISA Server – não houve resposta;

· Executar o comando netstat -nao a partir da console do ISA para verificar qual processo estava ouvindo na porta 25 – corretamente foi mostrado que o processo do ISA ouvia na porta 25;

· Checagem do registro MX para verificar se apontava corretamente para o ISA – o registro MX estava correto.

Após estes erros iniciais partimos então para a captura de dados, pois estava claro que o ISA estava tendo problemas para responder na porta 25.

3. Coletando e Analisando os Dados

Para iniciar a coleta de dados a seguinte configuração foi feita:

· Habilitar o network monitor na placa externa do servidor ISA;

· Habilitar o log (monitoramento) para porta de destino igual a 25;

Após configurar o ambiente desta forma então fizemos um telnet na porta 25 de fora do ISA e o resultado foi bem interessante.

O resultado da captura de rede apenas mostrou o host remoto tentando estabelecer conexão na porta 25 e não obtinha resposta. Já o log do ISA, este sim foi de extrema utilidade. Vejamos o resultado:

IP_VALIDO_ISA 10.10.10.20 25 SMTP Server Failed Connection Attempt SMTP IN 0x8007274d External DMZ - SRVISA1 Firewall

Vejamos o que significa este log:

Este log foi extremamente importante, pois note que o ISA tenta enviar a requisição SMTP para o servidor que não é mais responsável por esta tarefa (10.10.10.20) e tenta usar uma regra antiga, que nem existe mais.

Sabendo disso fazia sentido a ocorrência do erro 0x8007274d, que por sua vez significa:

“No connection could be made because the target machine actively refused it.”

A partir disso já sabíamos que o ISA não estava interpretando a nova regra que foi criada e com isso continuava mandando pacotes para o servidor antigo, como o servidor antigo não tinha mais serviço SMTP então o estabelecimento da conexão nunca terminava.

4. Entendendo Melhor o Ambiente

O cenário inicial descrito pelo cliente estava bem explicado, porém algumas informações não foram totalmente repassadas. Para entender melhor foi preciso perguntar mais sobre o ambiente e eis as respostas para tais questionamentos:

· O Servidor ISA está em Array com mais de um nó?

o Sim

· Quantos servidores no total?

o 2

· Eles usam NLB Integrado?

o Sim.

· Quem é o CSS (Configuration Storage Server)?

o Este servidor onde as capturas foram feitas SRVISA1.

· Estes servidores são membros do domínio a qual os usuários estão efetuando o logon de rede?

o Não. Estes servidores estão em um “workgroup”.

Com base nestas respostas já ficou claro entender que:

· Caso tenhamos um problema no CSS então é possível que as políticas não estejam corretamente sendo interpretadas.

· Quando se usa ISA Server em um ambiente de “workgroup” é preciso ter um certificado válido entre os membros do array para fins de autenticação intra-array.

Para maiores informações sobre a diferença entre a instalação de um servidor ISA no domínio e em workgroup veja o artigo Deployment Recommendations for ISA Server 2004 in a Workgroup or Domain no Microsoft Technet.

5. Revisando os Pré-Requisitos

Revisando os pré-requisitos do ambiente foi possível verificar que o servidor SRVISA2 não estava de fato comunicando com o servidor SRVISA1 no aspecto de verificação CSS. Para chegar até este ponto os passos 1 até o passo 5 do artigo abaixo foram utilizados:

Troubleshooting Configuration Storage Servers in ISA Server 2004 and ISA Server 2006 Enterprise Edition

https://www.microsoft.com/technet/isa/2004/plan/ts_css.mspx

Chegando no passo 5 verificamos que o certificado que autentica os usuários estava expirado e isso era o motivo pelo qual o erro abaixo estar aparecendo no log de eventos:

Event Type: Warning

Event Source: Microsoft ISA Server Control

Event Category: None

Event ID: 21238

Date: 27-04-2007

Time: 16:44:19

User: N/A

Computer: SRVISA2

Description:

ISA Server cannot connect to the Configuration Storage server srvisa1.ctest.com for one of the following reasons:

- The Configuration Storage server is not available.

- General networking or authentication issues.

- A policy misconfiguration on the array.

Para resolver este problema acessamos o site da entidade certificadora (CA) e requisitamos um novo certificado. Para mais informações de como importar um certificado para o CSS do ISA veja o artigo Obtain a server certificate (Enterprise Edition) no Microsoft Technet.

Fizemos o procedimento, reiniciamos o CSS e nos deparamos com um novo erro. Agora o erro durante a replicação era 0x8009030d, que por sua vez significa: “The credentials supplied to the package were not recognized” .

Como utilizamos o procedimento manual para importar o novo certificado o mesmo não foi corretamente registrado. Para corrigirmos este problema foi utilizado a ferramenta ISACertTool que foi criada justamente para estes cenários. Após executarmos este utilitário a replicação entre os membros do array pôde ser feita com sucesso e a nova regra foi interpretada.

6. Conclusão

Este foi um caso bem interessante, pois o problema que inicialmente parecia ser de criação de regra e publicação da mesma tornou-se um problema muito mais sério que isso. O fato é que o certificado estava expirado desde o começo do mês de Abril, porém, como o ambiente estava estável e nenhuma regra tinha sido alterada, não era notório que o problema já existia no ambiente a muito mais tempo.

Com isso fica mais do que claro a importância de um sistema de monitoramento ativo, como por exemplo o Microsoft Operations Manager, pois através de um sistema destes seria possível mitigar possíveis paradas no ambiente como esta onde o cliente ficou praticamente um dia inteiro sem receber email da Internet.