Como Fazer para Bloquear o UltraSurf, Solução Definitiva (iptables + fail2ban)

Por Rodrigo Luis Silva em 16 de janeiro de 2012

Fazendo a revisão do firewall de um cliente eu consegui bloquear o acesso as redes BitTorrent e ao terrível UltraSurf.
Vou descrever como fiz para bloquear o UltraSurf.

Em um primeiro momento eu acreditei que seria fácil bloquear o UltraSurf, porém o uso de proxy transparente obriga que a porta 443 (HTTPS) fique liberada. Já o BitTorrent foi bloqueado sem dificuldades.

Com o uso do tcpdump eu identifiquei que todo o acesso do UltraSurf sai pela porta 443, logo a solução mais óbvia seria bloqueá-la, porém não é possível. Bloquear o IP ou range de IP do servidor de destino seria outra opção.

Quando fiz o bloqueio pelo range de IP, descobri que o UltraSurf tenta uma centena de IPs diferentes até conseguir o acesso que ele precisa, e certamente devem existir novos IPs a cada nova versão.

Pesquisei pelo Google e não encontrei nenhuma forma eficiente de bloquear o UltraSurf, foi então que tive pensei em criar uma regra no iptables e fazer log dos acesso ao IP do UltraSurf para depois criar um daemon para ler esse log e fazer um bloqueio em tempo real.

Íntegra em Dicas-L

Leia Mais ►

Aprenda a como fazer "Twice Nat" (Nat Overlapping)

As boas práticas recomendam que as mudanças no ambiente de produção sejam planejadas, documentadas e testadas antes de serem implementadas. Estes testes, quando possível, são realizados em um ambiente de homologação, ou pré-produção, para evitar qualquer impacto na qualidade dos serviços disponibilizados. Uma das características importantes de um bom ambiente de homologação é a sua semelhança com a produção. Quanto maior esta semelhança, mais problemas poderão ser detectados antes de afetar os usuários.

Um dos pontos interessantes para ser replicado é a configuração de rede. Assim, uma máquina poderia migrar entre o ambiente de produção e homologação sem mudanças, nem mesmo na configuração da rede. Alguém pode perguntar: os endereços IP e, ainda mais, as redes não deveriam ser únicos dentro de uma mesma rede local? Sim, caso contrário, o roteador não saberia para qual das duas redes enviar os pacotes. Deixar as duas redes desconectadas uma da outra também não é uma boa solução. Não é muito prático enviar dados pelo protocolo PPCPPL (pendrive para cá, pendrive para lá). Vejamos o problema de duas redes com endereços conflitantes. O roteador, ao receber um pacote do computador 10.1.2.2 para 10.1.1.2, não teria como escolher entre as duas redes 10.1.1.0/24:

Leia esse excelente artigo em Luizluca

Leia Mais ►