Linux e CIA: iMasters - Como a análise de tráfego salvou meu emprego - Parte 02

terça-feira, julho 28, 2009

iMasters - Como a análise de tráfego salvou meu emprego - Parte 02 - Linux

Segunda-feira, 27/07/2009 - 11:15 - Por Júlio Henrique Conceição
Seções relacionadas:
Como a análise de tráfego salvou meu emprego - Parte 02

Veja o artigo anterior:
Como a análise de tráfego salvou meu emprego - Parte 01
*
Há algum tempo, fui atender a uma empresa que estava com problemas na suíte Websense. Tudo levava a crer que era um bug, já que estava se comportando de maneira estranha. E, se fosse realmente um bug, tudo o que poderíamos fazer seria reportar ao fabricante e aguardar por um patch. Mas, como precisava colher mais informações, resolvi coletar e analisar o tráfego de rede. Logo no início, pude observar que, na verdade, o problema não estava com o Websense.
O problema
Somente para ilustrar, o Websense é uma suíte de monitoração e controle de acesso à Internet, e funciona da seguinte maneira: em sua implementação stand-alone, ele possui um componente chamado Network Agent que nada mais é que um sniffer que fica "ouvindo" o tráfego com destino à Internet; baseado em suas políticas, pode bloquear o acesso, mostrando uma página Web informativa para acessos http ou https; para tentativas de acesso utilizando outros protocolos, o Network Agent encerra a conexão enviando ao cliente solicitante um pacote reset (com a flag RST habilitada). Obviamente, esta é uma descrição mínima do Websense para o entendimento do restante do artigo; para maiores informações, indico o site da Websense.
Porém, para que o Network Agent possa analisar o tráfego que deixa a rede, ele deve estar posicionado "em paralelo" ao gateway; ou seja, deve visualizar o mesmo tráfego que este. Em Switches, conseguimos isso espelhando-se a porta onde o gateway está conectado para uma outra (geralmente chamada de porta de monitoramento), onde conectamos a máquina com o Network Agent. Em Hubs, não é necessário efetuar espelhamento, pois o tráfego já é direcionado a todas as portas.
Mas o que estava acontecendo? Foi reportado que o Websense estava efetuando bloqueios de protocolos, tais como MS-SQL, VNC, RDP, etc, na rede Interna; ou seja, eram bloquedos acessos entre equipamentos que estavam no mesmo range de endereços (e que, teoricamente, não cruzavam o gateway). E, quando o Servidor Websense era desligado, os problemas desapareciam.
A análise
Instalei o Wireshark no Servidor Websense para verificar se era mesmo este quem bloqueava as conexões. Analisei, então, uma tentativa de conexão entre uma estação-cliente e o Servidor MS-SQL da empresa. Abaixo, um dump do pacote número 7978:
O endereço MAC do Servidor MS-SQL era 00:1e:c9:aa:6a:47, e seu IP 10.0.1.32; já o endereço MAC do Servidor Websense era 00:1e:c9:b6:9a:60, e seu IP era 10.0.1.77. Assim, através do dump de pacote acima, verificamos que o reset na conexão parte da máquina do Websense (atentem ao endereço MAC de origem informado na linha Ethernet II) apesar de o endereço IP informado ser o do Servidor MS-SQL.
Agora, temos a certeza de que era o Websense quem estava encerrando a conexão entre o cliente e o Servidor; mas, ainda, restava saber o porquê. Afinal, em uma rede comutada (com swtiches), o Servidor Websense deveria visualizar três tipos de tráfego: aquele enviado para fora da rede (ou seja, o espelho do tráfego destinado ao gateway), destinado a ele mesmo e tráfego de broadcast; porém, o Servidor Websense estava visualizando conexões entre diversos clientes e servidores diferentes, sem que ele (ou o gateway) estivesse diretamente envolvido nesta comunicação.
Como o gateway da empresa era uma máquina Linux, solicitei acesso à ela para realizar a análise do tráfego; o resultado foi o mesmo: também era possível visualizar tráfego que não deveria.
Informando ao pessoal interno do aquele switch estava se comportando como um hub, obtive acesso à console de configuração dele (sob olhares desconfiados). Quando pedi para listar a tabela MAC do Switch, as informações que me foram exibidas, não estavam de acordo com o que realmente deveria aparecer.
Como neste Switch estavam conectados todos os Servidores da empresa, o mesmo não poderia ser reiniciado naquele momento; mas conseguimos outro Switch para onde movemos as conexões do gateway de Internet e do Servidor Websense. Refizemos o espelhamento de portas no Switch, e solicitamos que os clientes realizassem novos testes. Após esta mudança, as conexões deixaram de ser encerradas na LAN.
E o pessoal parou de culpar o Websense. :-)
Conclusão
Mais uma vez, verificamos que a análise de tráfego é um instrumento poderoso para o diagnóstico de problemas de rede; neste caso, também podemos tê-la como aliada para a segurança de rede: o switch passou a se comportar de maneira inadequada, e pode ter sido alvo de um ataque do tipo MAC flood.
Referências
Página da Websense
Curso introdutório de Redes
Instalação do Wireshark no Windows XP