Sua aplicação está pronta para um ambiente seguro?
Sua aplicação está pronta para um ambiente seguro?
Por Yuri Diógenes
1. Introdução
À medida que aumentamos as camadas de segurança de um ambiente estamos propenso a cair em cenários de incompatibilidades com aplicações legado, performance com aplicações que não foram desenhadas com segurança em mente entre outros problemas. Há um tempo atrás trabalhei em um caso aqui na Microsoft onde tínhamos problemas de performance de uma aplicação que rodava no Windows para acessar arquivos no Mainframe. A aplicação basicamente permitia que o usuário navegasse em uma estrutura semelhante a do Windows Explorer, porém os arquivos presentes na interface gráfica da aplicação estavam localizados fisicamente no Mainframe.
Bem, até aí tudo bem, na realidade a aplicação tinha muita serventia, porém após a implantação do Windows XP SP2 na rede e ativação do Windows Firewall, a cópia de um arquivo que antes demorava alguns segundos, passou há demorar alguns minutos.
Primeiro foi necessário um trabalho manual para detecção das portas que a aplicação usava isso porque não havia documentação do fornecedor recomendando as portas necessárias para que aplicação funcionasse com êxito. Após este trabalho, conseguimos ter a aplicação funcionando, porém com este desempenho degradante, o que tornava inviável.
Este artigo mostra uma breve discussão sobre este cenário e qual foi o resultado final do mesmo.
2. Windows Firewall
É comum ouvirmos a frase: “Há, mas isso só aconteceu depois que habilitei o Firewall!!” e isso é comum e muitas vezes até esperado. Se antes você tinha uma casa, com a porta aberta onde todos entravam e saiam sem pedir nem licença, agora você tem uma casa com porta e um porteiro, onde para tudo que entra ou sai é necessário que o porteiro confira se é permitido ou não. Isso é uma premissa básica e ao se habilitar o Windows Firewall pode esperar comportamentos do tipo:
· Programas clientes que param de acessar o servidor;
· Programas que não mais conseguem transmitir dados pela rede;
· Acessos à sua estação que antes funcionavam e agora não funciona mais.
Tudo isso e muito mais faz parte do custo de se ter um ambiente seguro. Neste momento não se deve desligar o Firewall achando que essa é a solução, deve-se sim procurar checar o que é preciso fazer no que diz respeito à configuração para permitir que sua aplicação funcione com o Windows Firewall habilitado.
A Microsoft publicou no artigo 842242 uma lista de programas que podem parar de funcionar quando se habilita este recurso no Windows XP SP2. Veja esta listagem antes de achar que o seu programa não é adequável ao Windows Firewall.
Para ter mais detalhes de como o Windows Firewall funciona veja o white paper abaixo:
Understanding Windows Firewall
https://www.microsoft.com/windowsxp/using/security/internet/sp2_wfintro.mspx
3. Obtendo Informações
Como dito anteriormente, apesar de termos as devidas regras e exceções criadas no Windows Firewall continuávamos com o problema principal, que era a lentidão na hora da cópia de arquivos.
Para obtermos dados a fim de se diagnosticar a causa raiz usamos então:
· Network Monitor – instalamos o network monitor no Windows XP, com isso poderíamos fazer uma captura dos pacotes e verificar com precisão o que estava acontecendo. Você pode baixar o Network Monitor do link ftp://ftp.microsoft.com/PSS/Tools/NetMon/
· Habilitamos o Log de pacotes que foram descartados pelo firewall. Você pode habilitar esse log através do comando “netsh firewall set logging droppedpackets = enable”, ou através da interface gráfica em Painel de Controle / Windows Firewall / Advanced / Security Logging;
Com estas duas opções habilitadas só precisávamos agora simular o problema para que pudéssemos ter a captura e o log de pacotes que foram descartados.
4. Analisando os Dados
Comecemos então pelo log do Firewall, que por sua vez está localizado como padrão no caminho %Windir%\pfirewall.log. Esse log terá o seguinte cabeçalho:
#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
Para mais informações sobre como interpretar cada campo deste log veja o artigo abaixo:
Troubleshooting Windows Firewall settings in Windows XP Service Pack 2
https://support.microsoft.com/?id=875357
Dica: Importe este log no Excel e use a opção de auto filtro do Excel, isso permitirá que você, por exemplo, filtre todos os pacotes do com o protocolo = TCP e o a ação = DROP.
Usando esta simples dica, foi possível verificar com facilidade que o haviam diversos pacotes descartados (Action = DROP), cujo campo TCPFLAGS era igual a R, que significa RST (Reset the Connection). O que continuou sendo estranho, pois o “RST” é um flag que é aceitável e utilizado normalmente na pilha TCP/IP. Na realidade o TCP utiliza o bit R (RST ou Reset) para reiniciar uma conexão TCP, seu uso é empregado, por exemplo, como resposta para uma tentativa de conexão a um serviço inexistente, conforme mostra a figura abaixo:
Com este bit configurado para “R” tínhamos a primeira pista para verificar a causa raiz do problema, neste momento surgiram duas perguntas chave: porque o Windows está recebendo este pacote do host (mainframe) e porque o pacote está sendo descartado.
Para respondermos estes “porquês” foi necessário analisar a captura de rede. No resultado da captura de pacote com o Network Monitor, o cabeçalho TCP foi semelhante ao mostrado abaixo:
Note que neste caso não estamos recebendo o convencional RST, ACK na realidade estamos recebendo um RST, PUSH. O flag PUSH é usado para assegurar que o dado está sendo entregue com a devida prioridade, porém ele afeta totalmente a forma com que o dado é tratado em ambos os lados da comunicação.
Neste caso tínhamos um pacote vindo do mainframe com essa seqüência, que por sua vez era descartada pelo Windows Firewall, tendo em vista que não era o tipo de seqüência esperada.
5. Conclusão
Este artigo foi na realidade apenas um exemplo de como as coisas podem ficar complicadas quando não temos documentação suficiente da aplicação com seus devidos requisitos de comunicação. A tendência é que cada vez mais o Firewall do Windows ser algo presente tanto nos computadores pessoais quanto em computadores corporativos. Além disso muitas melhorias de segurança vão estar presentes no Windows Vista, o que também vai requerer que aplicações de terceiros sejam precisas em suas documentações de forma não tenhamos tanto efeito colateral no uso do Firewall.
Neste caso específico não tínhamos documentação suficiente acerca desta aplicação ficava difícil realmente prever se ela requeria somente às portas que detectamos ou se era preciso abrir mais portas. Também não foi possível obter a resposta do porque a aplicação no lado do servidor enviava RST, PUSH – tínhamos a hipótese desta aplicação esta reiniciando a conexão devido ao Windows está enviando uma tentativa de acesso em uma porta não disponível, mas se isso era verdade, porque estava sendo enviado o PUSH ao invés do ACK.
Lembre-se, a utilização do Windows Firewall é algo que depende muito da forma em que as aplicações funcionam para abrir conexões de rede. Nada adianta termos um Firewall se a aplicação precisa de todas 65.534 portas para se comunicar.
6. Referências
Microsoft Windows 2000 TCP/IP Implementation Details
https://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx
Manually Configuring Windows Firewall in Windows XP Service Pack 2
https://www.microsoft.com/technet/community/columns/cableguy/cg0204.mspx
Inappropriate TCP Resets Considered Harmful
ftp://ftp.rfc-editor.org/in-notes/rfc3360.txt
Explanation of the
Three-Way
Handshake via TCP/IP
https://support.microsoft.com/kb/172983/EN-US/
The Basics of Reading TCP/IP Traces