Asimov escreveu:Hola Eugenio, tal vez pueda ayudar, me podrias decir cuales son los peligros de ultrasurf?
Saludos.
baiev escreveu:Pelo que eu li nos post acima e alguns mais atuais, essas regras já não funcionam mais para as versões mais novas do UltraSurf não tenho muita certeza...
baiev escreveu:Eu acho que vai ter que mudar a Politica de acesso no IPTABLES primeiramente... e começar a implementar a partir dai...
Eduardo escreveu:O ideal seria um addon que desse DROP na porta 443 com opções de liberação de IPs (DIretores e privilegiados) e principalmente de sites HTTPS (lista com bancos, sites GOV como receita, etc..).
Assim resolveriamos também o problema de acesso as paginas HTTPS do Facebook, Orkut e outras qeu bloqueamos no Squid mas passam na porta 443.
Seria algo similar a um Dansguardian para porta HTTPS 443.
Creio que um script relativamente simples com entradas pelo Webadmin resolveria isso, mas o problema é algum por a mão na massa.
Nenhum desses dois links mostra uma solução conforme você quer.almalves escreveu:Abaixo receita que segundo autor e comentários resolve o problema, porém teria que usar proxy manual e o ambiente testado foi o FreeBSD.
http://www.vivaolinux.com.br/artigo/UltraSurf-Bloqueio-definitivo/?pagina=1
outra dica é essa : http://biapsia.blogspot.com.br/2010/08/bloqueio-de-ultrasurf-usando-apenas.html
brunovescovi escreveu:Bom dia, pessoal.
Na minha opinião, uma empresa ter que usar muitos controles de conteúdo é uma derrota na liderança da empresa, porque está consciente de que existem maus funcionários e fica por isso mesmo. Um funcionário que usa o facebook mesmo sabendo que a empresa proíbe, é esse mesmo funcionário que rouba uma caneta, que imprime 20 folhas na impressora da empresa para fins pessoais, que chega atrasado sem falar nada, que quebra um copo e esconde os cacos para ninguém saber que foi ele, enfim, quem quebra uma regra dentro do computador também quebra na vida real. A vantagem é que no computador podemos saber quem foi de forma simples: verificando os logs.
brunovescovi escreveu:Bom dia, pessoal.Nenhum desses dois links mostra uma solução conforme você quer.almalves escreveu:Abaixo receita que segundo autor e comentários resolve o problema, porém teria que usar proxy manual e o ambiente testado foi o FreeBSD.
http://www.vivaolinux.com.br/artigo/UltraSurf-Bloqueio-definitivo/?pagina=1
outra dica é essa : http://biapsia.blogspot.com.br/2010/08/bloqueio-de-ultrasurf-usando-apenas.html
O primeiro link resolveu o problema do ultrasurf, mas além do servidor, também houve a necessidade de instalar o WPAD em todas as mãquinas windows para receber o proxy automaticamente, e nas estações linux teve que configurar o proxy na mão mesmo. Só isso já não seria como você quer porque você precisa de uma solução transparente.
baiev escreveu:A gente sabe que existe casos e casos, a explanação do caro colega Bruno tem mais um tom de desabafo mesmo...
A unica solução para o Ultrasuf é fazer o que ele disse mesmo, fecha a porta 443 para tudo e vai abrindo conforma a necessidade vai aparecendo
ai resolve mas demora um pouco mas fica bom...
almalves escreveu:Sim entendi, como citado também já me questionei e procurei soluções alternativas com os clientes, mas infelizmente a conscientização é um processo, até pretendo bloquear em alguns cases e se possível liberar em horário de almoço, etc...
Vc teria o procedimento que eu deveria realizar? inclusive para deixar alguns pc´s fora dessa regra? com 100% de liberação?
baiev escreveu:almalves escreveu:Sim entendi, como citado também já me questionei e procurei soluções alternativas com os clientes...
Vou criar umas regras básica pra você começar a fazer testes ai...
[brazilfw]/partition/custom# chmod +x https.sh
#!/bin/sh
#Limpa regras da tabela FORWARD
iptables -F FORWARD
#Recoloca as Regras do /etc/rc.d/rc.firewall
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state established,related -j ACCEPT
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
#Nossa regras de Https Anti-Ultrasurf
micros_liberados=`cat /etc/brazilfw/custom/micros_liberados | xargs | sed 's/\ /,/g' `
micros_bloqueados=`cat /etc/brazilfw/custom/micros_bloqueados | xargs | sed 's/\ /,/g' `
https_liberados=`cat /etc/brazilfw/custom/https_liberados | xargs | sed 's/\ /,/g' `
iptables -I FORWARD -s $micros_bloqueados -p tcp --dport 443 -j DROP
iptables -I FORWARD -s $micros_bloqueados -d $https_liberados -j ACCEPT
iptables -L FORWARD
192.168.0.20
192.168.0.21
192.168.0.50
192.168.0.51
174.129.195.250
177.69.194.66
186.228.82.233
23.32.112.60
www.live.com
www.bradesco.com.br
www.ib2.bradesco.com.br
wwwss.bradesco.com.br
[brazilfw]/partition/custom# ./https.sh
C:\>netstat -n
Conexões ativas
Proto Endereço local Endereço externo Estado
TCP 127.0.0.1:40455 127.0.0.1:40456 ESTABLISHED
TCP 127.0.0.1:40456 127.0.0.1:40455 ESTABLISHED
TCP 192.168.19.22:1032 23.9.135.117:80 CLOSE_WAIT
TCP 192.168.19.22:16085 186.228.82.233:443 ESTABLISHED
TCP 192.168.19.22:16087 186.228.82.233:443 ESTABLISHED
TCP 192.168.19.22:17229 23.9.135.117:80 CLOSE_WAIT
TCP 192.168.19.22:18402 177.69.194.66:443 CLOSE_WAIT
TCP 192.168.19.22:18567 200.98.211.122:443 CLOSE_WAIT
TCP 192.168.19.22:18876 200.98.205.86:443 ESTABLISHED
TCP 192.168.19.22:18975 192.168.19.10:22 ESTABLISHED
TCP 192.168.19.22:18985 184.85.247.240:443 CLOSE_WAIT
TCP 192.168.19.22:18995 91.190.216.7:443 SYN_SENT
TCP 192.168.19.22:18997 65.55.223.24:40032 ESTABLISHED
TCP 192.168.19.22:19004 193.120.199.17:12350 ESTABLISHED
TCP 192.168.19.22:19052 65.55.71.42:443 ESTABLISHED
TCP 192.168.19.22:19818 177.69.194.65:443 ESTABLISHED
TCP 192.168.19.22:19845 186.228.82.233:443 SYN_SENT
TCP 192.168.19.22:19879 199.59.150.39:443 SYN_SENT
TCP 192.168.19.22:19880 199.59.150.39:443 SYN_SENT
TCP 192.168.19.22:26154 121.156.66.106:80 CLOSE_WAIT
TCP 192.168.19.22:49446 192.168.19.3:445 ESTABLISHED
TCP 192.168.19.22:52697 23.32.112.60:443 CLOSE_WAIT
/partition/custom/https.sh
baiev escreveu:Aqui tem uma solução mais ou menos que eu achei, caso seja Imprescindível bloquear o UltraSurf...
Na pasta "/etc/brazilfw/custom" crie os seguintes arquivos:
baiev escreveu:Pra iniciar a conexão com o servidor ele usa somente a 443, localmente na estação ele usa qualquer porta...
Tõ usando o ultrasurf aqui e não passa mesmo...
iptables -I FORWARD -m string -s $micros_liberados --algo bm --string "facebook.com" -j ACCEPT
iptables -I FORWARD -m string -s $micros_bloqueados --algo bm --string "facebook.com" -j DROP
Obrigado pela correção, baiev. Desculpe minha informação desencontrada.baiev escreveu:Pra iniciar a conexão com o servidor ele usa somente a 443, localmente na estação ele usa qualquer porta...
Tõ usando o ultrasurf aqui e não passa mesmo...
Eu sempre achei que o ultrasurf usasse somente a porta 443 mesmo, mas depois de ler um dos tutoriais que o colega almalves passou, eu pensei que estava desatualizado e mudei minha mente em relação ao ultrasurf.almalves escreveu:Abaixo receita que segundo autor e comentários resolve o problema, porém teria que usar proxy manual e o ambiente testado foi o FreeBSD.
http://www.vivaolinux.com.br/artigo/UltraSurf-Bloqueio-definitivo/?pagina=1
Fonte: http://www.vivaolinux.com.br/artigo/UltraSurf-Bloqueio-definitivo/?pagina=2Ao 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.
Voltar para BrazilFW 2.x - Ayuda en general
Usuários navegando neste fórum: Nenhum usuário registrado e 14 visitantes