Recentemente, no nosso fórum de discussão, o usuário Cristiano Santos nos perguntou como fazer para bloquear o programa UltraSurf, que estava permitindo que um usuário da sua rede local acessasse sites bloqueados pelo proxy.

Para poder respondê-lo, baixei o UltraSurf da Internet e fiz alguns testes em uma estação. A versão que testei funcionava apenas no Windows e com o Internet Explorer, mas vi referências na Internet a outras versões que funcionavam com outros navegadores.

É assustador. Com esse programa podemos acessar qualquer site bloqueado pelo proxy, fazendo parecer que não há nenhum controle de acesso na rede. Neste tutorial, mostraremos como funciona UltraSurf e o que fizemos para detê-lo.

Entendendo o problema

É sabido que a porta padrão utilizada pelos serviços Web é a 80 (http), então, configuramos o proxy para que analise as conexões com destino a essa porta e faça o controle de acesso através de suas ACLs. No proxy transparente, que é usado em nossas soluções, todo o tráfego http da rede local com destino à Internet é desviado automaticamente para o proxy pelo firewall do servidor (Iptables/Shorewall), essa é uma das maneira mais eficientes de se configurar o proxy, pois as aplicações clientes não perceberão que há um proxy na rede, por isso não necessitarão de nenhuma configuração especial. Para elas, é como se estivessem acessando diretamente os serviços da Internet.

No entanto, o tráfego Web não é composto apenas por conexões http, temos também as conexões https (que utiliza a porta 443) que são bastante utilizadas em transações bancárias e de comércio eletrônico devido à segurança proporcionada pela criptografia feita através do protocolo SSL. Ou seja, as conexões https são indispensáveis para os usuários da rede. Devido ao seu uso restrito e à impossibilidade de analisar o conteúdo dessas conexões por serem criptografadas, como regra deixamos a porta 443 (https) aberta para todos os sites da Internet.

UltraSurf em ação

É aí que entra o famigerado UltraSurf, ele faz uso da porta 443, liberada por padrão no servidor, para viabilizar conexões entre as estações da rede local e servidores proxy na Internet, e, através desses servidores, as estações poderão acessar sites que, de outra maneira, estariam bloqueados para a rede local.

Ao ser executado na estação, o UltraSurf fica aguardando conexões do navegador na porta 9666, além disso, faz com que o navegador para o qual foi criado (testamos a versão feita para o IE) passe a usar a porta 9666 da estação para realizar suas conexões, ao invés de utilizar o default gateway da rede local (o servidor). Ou seja, ele funciona como um proxy que fica em execução na própria estação. Então, quando o navegador tentar acessar um site, ele se conectará ao UltraSurf (porta 9666), que estará conectado a vários servidores proxy na Internet. Esses servidores buscarão a página e entregarão para o UltraSurf, que, em seguida, a entregará ao navegador. Tudo isso sem o conhecimento do controle de acesso realizado pelo proxy do servidor, pois o tráfego não foi realizado pela porta 80.

O interessante é que mesmo que as conexões https passassem pelo proxy do servidor, elas não teriam como ser analisadas por serem criptografadas, uma idéia genial para burlar o controle de acesso. Como falei antes, isso é assustador para a administração da rede.

Procurando uma solução

A primeira idéia é bloquear os endereços IP dos servidores proxy da Internet, impedindo essas conexões através da rede local, mas não é possível fazer isso de maneira efetiva, pois há milhares deles espalhados pela Internet, além disso, seus endereços mudam constantemente por serem dinâmicos.

Poderíamos também tentar restringir as conexões https apenas para sites conhecidos, mais isso provocaria a ira dos usuários da rede, que ficariam impedidos de realizar várias transações na Internet, e deixaria o administrador da rede "maluco" na tentativa de descobrir os endereços IP de todos os sites idôneos que quisesse permitir o acesso.

Para encontrar uma solução, começamos a procurar algum detalhe específico nas conexões do UltraSurf que permitisse viabilizar o seu bloqueio. Passamos então a analisar as conexões https geradas por uma estação onde o UltraSurf estava em execução. Em nossos testes, usamos a ferramenta iptstate que mostra todas as conexões estabelecidas entre as estações e servidores externos, no nosso caso filtramos apenas as conexões https da estação analisada:

# iptstate -s 192.168.0.100 -D 443 -l

Observamos que antes de iniciar o UltraSurf, não havia conexões https geradas pela estação (figura 1), mas após a sua execução, foram verificadas diversas conexões https (figura 2), algo em torno de 45 em média. Para se ter uma idéia, numa conexão https típica (www.gmail.com), o número de conexões https é bem inferior a esse (figura 3).

Continuando a nossa análise, fizemos alguns filtros para verificar quais eram os servidores que a estação que executava o UltraSurf estava realizando conexões, já que existiam várias conexões https para um mesmo servidor:

# iptstate -s 192.168.0.100 -D 443 -l -1 | \
> tail -n +4 | awk '{ print $2 }' | sort | uniq | wc -l
10

Após vários testes, concluímos que, em média, o UltraSurf se conectava a 10 servidores proxy diferentes na Internet através do protocolo https, e isso é muito se comparado a uma aplicação típica que utiliza esse protocolo.

Eureka! Encontramos um padrão para diferenciar o UltraSurf de outras aplicações, basta analisar as estações da rede local e aquelas que tiverem um número excessivo de conexões https com servidores distintos (adotamos o valor maior ou igual a 8) devem estar executando o UltraSurf. Mas o que fazer após descobrir quais são as estações estão, supostamente, executando o UltraSurf?

Bloqueando as conexões do UltraSurf

Nossa idéia foi a seguinte, criamos um script de monitoramento que, de tempos em tempos (adotamos 5 minutos), analisará todas as estações da rede local (IPs), aquelas que estiverem com mais de 8 conexões https com servidores distintos, ao mesmo tempo, terá todo o tráfego https bloqueado. Isso mesmo, todo o trafego, não será possível nem mesmo fazer conexões https com outros servidores idôneos. Isso será uma punição para os usuários "espertinhos" que tentarem executar o UltraSurf. O tráfego somente poderá ser liberado novamente pelo administrador da rede, dessa maneira teremos como saber quais os usuários estavam tentando violar as regras de controle de acesso.

Resumindo, as estações que tiverem mais de 8 conexões https com servidores distintos, ao mesmo tempo, terá o acesso ao protocolo https bloqueado. Pense nesse script de monitoramento como um limitador de conexões https para as estações da rede local. Vale lembrar que os acessos através do protocolo https são utilizados apenas em situações específicas (transações bancárias, comércio eletrônico etc.), por isso não devemos ter problemas com essa limitação. Claro que poderão ocorrer falsos positivos, mas, pelos teste que realizamos até então, isso raramente ocorrerá.

Configurando o Shorewall

Antes de instalar e configurar o script responsável pelo monitoramento das conexões https, será necessário fazer algumas alterações na configuração do Shorewall, que será o responsável pelo bloqueio do tráfego https. Primeiro edite o arquivo /etc/shorewall/shorewall.conf e altere para "No" o parâmetro BLACKLISTNEWONLY:

BLACKLISTNEWONLY=No

Depois edite o arquivo "/etc/shorewall/interfaces e adicione a opção blacklist na linha referente à zona loc:

#
# Shorewall version 4 - Interfaces File
#
# For information about entries in this file, type "man shorewall-interfaces"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-interfaces.html
#
###############################################################################
#ZONE	INTERFACE	BROADCAST	OPTIONS
net	eth0		detect		routefilter
loc	eth1		detect		blacklist
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

Instalando e configurando o script stopUltraSurf.sh

Agora baixe, descompacte e mova o script de monitoração stopUltraSurf.sh para o diretório /usr/local/bin, em seguida, torne-o executável:

# wget http://www.opcaolinux.com.br/download/scripts/stopUltraSurf.sh.gz
# gunzip stopUltraSurf.sh.gz
# mv stopUltraSurf.sh /usr/local/bin
# chmod 0775 /usr/local/bin/stopUltraSurf.sh

Para finalizar, faça com que o script seja executado a cada 5 minutos adicionando a linha abaixo no arquivo /etc/crontab:

echo "1-59/5 * * * *	root    /usr/local/bin/stopUltraSurf.sh" >> /etc/crontab

Feitos os procedimentos acima, quando um usuário da rede local tentar executar o UltraSurf em uma estação, o servidor detectará a quantidade excessiva de conexões https e bloqueará o acesso dessa estação (IP) ao protocolo https (porta 443), "quebrando" as conexões feitas pelo UltraSurf (figura abaixo), inviabilizando o seu uso. As demais estações não serão afetadas. Para restabelecer o acesso da estação ao protocolo https, vá em "opl > Firewall > Configurações Avançadas > Blacklist" e remova o seu IP da lista, não esqueça de ativar as alterações do Firewall em seguida.

É muito importante que os usuários façam seus testes e nos retornem os seus resultados, bem como nos dêem sugestões para que possamos aprimorar o script, que pretendemos adicionar nas próximas versões das nossas soluções.

Hoje (31.08.2009), quase dois dias após disponibilizarmos o script de monitoramento, fizemos uma melhoria do seu código que praticamente elimina a possibilidade de falsos positivos. Quem baixou a versão anterior, disponibilizada antes deste aviso ser escrito, aconselhamos baixá-lo novamente.

Saiba sobre a nova versão UltraSurf 9.6 clicando aqui.

Comentários (10)

Percebe-se no artigo a importância de conhecer bem a linha de comandos
escrito por Sérgio Luiz Araújo Silva , 30 de agosto de 09

Sempre digo as pessoas que o estudo das ferramentas, comandos, editores deve se dar previamente. Estudo linha de comando diariamente bem como o vim, é como uma vitamina que se toma diariamente. Estudo, estudo e mais estudo. Outro aspecto interessante é a partilha dessas informações tão importantes, parabéns!

Mais uma vez esse cara mostra a sapiência existente em solucionar..........
escrito por Rodrigo Saraiva , 30 de agosto de 09

Lendo, relendo e lendo novamente, tento entender como a prática em exercitar, traz um solucionar rápido e eficaz, o que o Sérgio cita acima confirma a eficiência dos resultados. Estudo!!! Parabéns chefe!!!!

Estudando e aprendendo
escrito por Tarcísio. , 30 de agosto de 09

E quanto mais estudamos e aprendemos, mais ficamos cientes das nossas limitações, o que nos motiva a estudar e aprender ainda mais, esse ciclo não tem fim...

Valeu!

Ultra Surf
escrito por Kurumin Branco , 30 de agosto de 09

Uma maneira bem simples de resolver esse problema, fecha a porta 443 e não usar o proxy tansparente, por que dai quando o ultra surf tentar altera as configurações do navegador, ele perdera conexão com o servidor, comigo funciona que é uma beleza.

UltraSurg
escrito por Tarcísio. , 31 de agosto de 09

Mas se fecharmos a porta 443 (https), como os usuários da rede local poderão acessar sites bancários e de comércio eletrônico que utilizam essa porta? Praticamente todos os serviços Web que faz uso de algum tipo de autenticação usam (ou deviam usar) o protocolo https (SSL).

Se mesmo assim preferir bloquear a porta 443, não será necessário abrir mão dos benefícios do proxy transparente, que são vários, pois o UltraSurf não funciona com a porta 443 bloqueada.

UltraSurf - The best solution for block!
escrito por Kleber D. Lima , 31 de agosto de 09

Galera testei e aprovei demais a solução, já tinha implementado algo parecido via iptables e funcionava com a mesma linha de raciocinio, bom vou deixar testando mais alguns dias aki no meu "server tester", e assim que eu estiver 100% confiante do funcionamento vou implementar nos meus clientes!

Mais uma vez Dr. Tarcísio nos ajudando a solucionar os problemas que encontramos pelo caminho OPEN da vida!

Obrigado!
Kleber D. Lima

Excelente solução
escrito por Thiago , 04 de setembro de 09

Já vi muitas tentativas de bloquear o ultrasurf, inclusive algumas para serem usadas nas estações windows através de GPO e outras que bloqueavam os ip dos servidores (inviável pela grande quantidade deles), mas nada que se compare a simplicidade e eficiência deste script de monitoramento, simplesmente funciona. O mais interessante é que o tempo da resposta do Tarcísio no forum dizendo que ia conhecer o ultrasurf até a publicação de uma solução no site foi de apenas um dia, que eficiência! Parabéns!!!

Ajuda como Script
escrito por Murilo , 29 de outubro de 09

Bom dia, amigo estou com uns probleminhas poderia me ajudar para eu bloquear de vez esta peste do ultra suft, Eu uso CENT OS , eu instalei o shorewall e o iptstates para que sua técnica de bloqueio do ultra surf funciona-se, mas esta acontecendo quando vou rodar o seu script esta dando um erro assim (iptstate: invalid option -- 1) eu pensei que seria normal, mas pelo que eu entendi significa que o iptstates não esta entendo essa linha no script (iptstate -s "$ip" -D 443 -1 ). Então quando rodo o script esta travando toda minha rede, eu não sei se pode influenciar, mas eu uso iptables como firewall, entao eu acho que o script não esta funcionando comigo, pq quando vejo que a internet de todos esta bloqueada, vou ver se tem alguem na blacklist (vi /etc/shorewall/blacklist) não aparece o ip de ninguém, Amigão ficaria muito grato se pudesse me ajudar, um forte abração e até mais.

Ultrasurf
escrito por Jalmacy Rego , 17 de novembro de 09

Srs,
Notei que o script funciona Blz.
mas observei o seguinte com o UltraSurf versao 95 ele pega blz.
Já com o Ultrusurf 96 nao consegue bloqueiar, e as vezes consegue.
Atentamente,
Jalmacy Rego

Ultrusurf 96, a luta continua
escrito por Tarcísio C. Espínola , 21 de novembro de 09

Na verdade não conhecia ainda o Ultrusurf 9.6. Vou analisá-lo, conhecê-lo e depois tentar detê-lo, essa é a eterna luta do administrador de redes...

Nota: Veja este artigo: http://www.opcaolinux.com.br/g...quear.html

Exibir / Ocultar formulário

Escreva seu Comentário

Nome

E-mail

Website

Titulo

Comentário

smaller | bigger

Escreva os caracteres mostrados

Comentar Prévia