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:
Entrada |
Descrição |
IP_VALIDO_ISA |
Endereço externo do servidor ISA |
10.10.10.20 |
Endereço IP do antigo servidor SMTP Relay |
Failed Connection Attempt |
Resultado da Ação |
SMTP IN |
Nome da Regra |
0x8007274d |
Código da ação |
DMZ |
Interface de rede de destino |
SRVISA1 |
Nome do servidor |
Firewall |
Tipo de Log (web Proxy ou Firewall) |
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.
Comments
- Anonymous
July 13, 2007
Pois é Yuri, mais um de seus artigos que nos fazem entender o quanto o entendimento do cenário como um todo é importante. Valeu por mais esta aula!!!