Que tal passar horas planejando e configurando o controle de acesso a conteúdo de uma rede, ir dormir feliz da vida com o gostinho do dever cumprido e acordar no dia seguinte, com o pesadelo de saber que foi tudo em vão, pois os usuários estão acessando o conteúdo bloqueado normalmente?

O objetivo aqui não é entrar na discussão se o controle de acesso a conteúdo deve ou não ser realizado na navegação WEB de uma empresa, instituições de ensino, residências ou onde quer se seja.

O fato é que, se por algum motivo, determinado conteúdo teve que ser bloqueado ou monitorado, este deve ser bloqueado, ou monitorado, de forma que os usuários da rede não consigam burlar tais controles. Sendo necessário assim, prever e tratar todos os possíveis desvios que, eventualmente, os usuários tentem utilizar para burlar os controles estipulados.

Muitas são as técnicas que os usuários de uma rede de computadores acabam recorrendo na tentativa, em geral com sucesso, de burlar os controles impostos. Entre essas técnicas, podemos citar como exemplo:

• https;
• tunneling;
• socks;
• proxy anônimo;
• webproxy;
• ferramentas como HotSpot Shield, HideIpPlatinum, JAP ou o implacável UltraSurf.

Sendo o UltraSurf, atualmente, a grande dor de cabeça de muitos administradores de redes, e o grande motivador deste trabalho.

O foco aqui não é detalhar o comportamento ou uso de todas as técnicas ou ferramentas acima citadas, afinal, facilmente você encontra este conteúdo na Internet.

Aqui vamos bater de frente com o grande vilão da vez, o UltraSurf, indo na sequência vendo os meios utilizados, já com sucesso, para banir em definitivo, esta e todas as técnicas e ferramentas citadas da rede.

Pense, se existisse um aplicativo executável, não instalável, com menos de 1.4 MB, que ao ser executado, por exemplo de um pendrive, passasse dando ‘risada’ pelos bloqueios de conteúdo configurados em sua rede, sem sequer deixar rastros, ou então te dar tchau!

Pois é, esse aplicativo já existe, e se chama UltraSurf!

O UltraSurf, desenvolvido pela empresa UltraReach, foi desenvolvido para burlar qualquer bloqueio de conteúdo configurado na rede.

Ao ser executado, conecta-se com seus servidores e cria uma espécie de proxy local na máquina do usuário, saindo toda a navegação realizada pelo usuário por esse proxy local, passando assim, por cima de qualquer controle de conteúdo imposto.

Ao rodar o UltraSurf, ele inicia sua busca incansável por uma brecha no firewall, por onde possa passar e estabelecer a conexão com seus servidores externos. Inicialmente, tenta estabelecer a conexão via porta 443 em um dos endereços IP de seus infinitos servidores, não conseguindo via porta 443, passa a tentar a conexão em uma série de outras portas, e incansavelmente, segue esta rotina de ir trocando porta e IP, até conseguir estabelecer a conexão.

Confesso aqui, que chega a ser divertido ficar monitorando todo esse processo via tcpdump.

Caso não tenha êxito na conexão padrão, vamos imaginar que você já tenha realizado bloqueios que o impediram de conectar, o usuário vai ao UltraSurf e facilmente configura o IP e porta de um servidor proxy, que pode ser o próprio proxy da sua rede, ou então um externo, conseguindo dessa forma, fazer a conexão com um de seus servidores por dentro do proxy informado.

Aproveito, e deixo aqui meus parabéns à equipe por trás desta respeitável ferramenta!

Problemas comuns na tentativa do bloqueio

Na busca por meios de bloqueio do UltraSurf na Internet, é comum cair em alternativas que sugerem bloquear uma relação interminável de endereços IP, tidos como sendo os servidores utilizados para conexão, bloquear a porta 443, liberando esta somente para os IPs necessários para uso na rede, utilizar o Snort etc…

Sendo comum ver nos comentários dos posts, coisas do tipo: “comigo funcionou perfeitamente!”, “testando com a versão X funciona, mas com a Y não”, “comigo continua acessando normalmente”, “rodo o UltraSurf e o Snort não detecta que ele está rodando”.

Isto se deve ao fato de que a cada nova versão lançada do UltraSurf, novas faixas de IP e portas são utilizadas, o padrão de conexão é redefinido, anulando assim, todos os bloqueios antes configurados, tornando a tentativa de bloqueio do UltraSurf, por este paradigma, totalmente impraticável, trabalhosa e ineficaz.

Como podemos observar na descrição do comportamento do UltraSurf, é comum que técnicas e ferramentas utilizadas para burlar os controles de uma rede façam uso de comportamentos e portas de uso padrão e necessário em uma rede, conseguindo com isso, dificultar bastante as tentativas de bloqueio.

A solução aqui demostrada foi estudada, configurada, colocada em produção e amplamente testada na rede acadêmica do Senac Lages/SC, onde o objetivo principal foi possibilitar aos alunos do Curso Técnico em Redes de Computadores, turma que se forma no final do primeiro semestre de 2012, a possibilidade de vivenciar problemas reais de campo, possibilitando desta forma, uma construção significativa do conhecimento, e deixando-os preparados para a cruel realidade do mundo do trabalho.

Para resolver o problema, entrou na ‘jogada’ o Mutley, servidor rodando FreeBSD que fornece com exclusividade para toda a rede acadêmica, os serviços: DHCP, DNS, Gateway e Proxy.

O bloqueio do UltraSurf e das outras técnicas relacionadas é relativamente simples, bastando ter as portas corretas fechadas no firewall e o uso de um proxy não transparente.

Na sequência, veremos a estrutura/características do servidor Mutley, as regras aplicadas e as implicações que cada ação reflete.

Estrutura/Características do servidor Mutley

FreeBSD 9 configurado como gateway da rede disponibilizando os seguintes serviços:

• DHCP
• DNS
• PROXY
• FIREWALL

PF utilizado como firewall, configurado dentro do conceito de politicas Default Deny, onde somente são abertas as portas que realmente são utilizadas na rede.

Portas SSH, 80, 53 e 3128 abertas somente para acesso ao próprio servidor, porta 443 fechada para qualquer uso.

Com isso, já evitamos que seja possível utilizar técnicas de tunneling, socks, proxy anônimo, além de já impedir que o UltraSurf e similares consigam conectar.

Exemplo da regra no PF

Squid configurado como proxy NÃO transparente, onde toda navegação, sem exceção, de http, https e ftp, somente será permitida via proxy, estando as respectivas portas devidamente fechadas no firewall.

O Dquid tem sua configuração padrão e dentro da sua necessidade, a única coisa adicionada se deu ao fato de que ferramentas como UltraSurf permitem que seja configurado o endereço de proxy da rede, conseguindo desta forma, funcionar por dentro do proxy mesmo.

Para impedir que isso aconteça, foi criada uma ACL para não permitir a navegação direta por IP.

Exemplo da ACL

Revisando a solução

• Firewall configurado dentro dos padrões de Default Deny;
• Liberar somente as portas necessárias para funcionamento da rede;
• Portas SSH, 80, 53 e 3128 liberadas exclusivamente para acesso ao IP da LAN do servidor;
• Proxy não transparente, atuando como saída exclusiva de HTTP, HTTPS e FTP;
• Bloqueio no proxy de navegação por IP.

Com estes passos simples, conseguimos com mínimo esforço, eliminar por completo o uso do UltraSurf e das ferramentas, ou técnicas, mencionadas para burlar os controles de conteúdo da rede.

Claro que toda ação gera um reação, e com o Mutley rodando a todo vapor e os bloqueios funcionando perfeitamente, acabaram surgindo alguns pontos, já devidamente resolvidos, que mereceram um pouco mais de estudo.

Seguem abaixo os problemas detectados e as soluções já implementadas para resolvê-los.

Problemas detectados com a aplicação do Mutley na rede:

Como está sendo utilizado proxy NÃO transparente, há a necessidade de configurar o endereço do proxy nos navegadores para poder navegar, o que pode ser considerado um problema para alguns usuários.

Solução: Para resolver isso, foi implementado no Mutley, a solução de configuração automática de proxy, WPAD.

O WPAD permite que os navegadores, rodando em máquinas Windows, consigam obter, de forma 100% automática, a configuração de proxy da rede via DHCP ou DNS.

Como a base de funcionamento da nossa rede é Windows, com a implantação do WPAD, já ficou resolvido o problema da configuração de proxy nos navegadores.

Nos clientes não-Windows, como por exemplo GNU/Linux, se faz necessária a configuração manual do proxy no navegador.

* A configuração de proxy foi automatizada via WPAD para os navegadores, mas temos uma serie de aplicações que usam as portas 80, HTTPS ou FTP, e que não permitem configuração de proxy automática ou manual em suas interfaces. O Windows Update é um desses casos.

Solução: Para resolver este problema, foram utilizados aplicativos do próprio Windows (proxycfg, netsh winhttp set proxy) para realizar a configuração do proxy a nível de sistema operacional.

Criada uma ACL para liberar a navegação por IP para casos específicos, por exemplo, a realização de FTP.

Exemplo:

Considerações finais

É isso pessoal, espero que as dicas aqui passadas possam ser úteis.

Reforço que a solução aqui proposta já se encontra em uso a mais de um ano!