Em 2 de maio de 2012 20:39, Paulo Henrique BSD Brasil < paulo.rd...@bsd.com.br> escreveu:
> > > Em 2/5/2012 09:32, Marcus Vinicius. escreveu: > >> > >> Ainda assim para bloqueio dos messengers/gtalks/skype, será necessário > >> bloquear as portas utilizadas por essas aplicações forçando elas a > usarem > >> http e ai é que entra o a vez do proxy. > >> > >> Em resumo longo seria o seguinte. > >> > >> Bloquear via firewall qualquer porta utilizada pelos messengers/gtalk > >> Como resposta a indisponibilizade de conexão tais programas irão tentar > >> primeiramente encapisular os datagramas sobre mensagens do protocolo > http > >> sem criptografia ( porta 80 ) > >> deixei essa porta explicitamente liberada para destinos conhecidos ( > redes > >> de bancos e caixa economica em especial ), e barra todo o restante, se o > >> navegar estiver com proxy configurado ele utilizará de imediato o proxy, > >> sugestão cadastre as redes acima como excessão na utilização do proxy, > tive > >> problemas com aplicações bancarias sobre java. > >> Como os messengers não terão exito na porta 80 apelaram para o ultimo > >> recurso, protocolo https ( porta 443 ) quando o proxy trabalha de modo > >> transparente o mesmo não pode interferir em trafego interceptado por ser > >> inelegivel para ele, porem quando configurado no navegador ele entra em > >> cena sobre um estilo de ataque tipo man-int-the-middle, visto que na > >> realidade não é a estação do usuário que se conecta no servidor remoto > mais > >> sim o proxy e para que o proxy saiba onde o usuário queira se conectar a > >> estação usuária é obrigada e permitir que o proxy compreenda a > informação. > >> > >> Em resumo breve, > >> O Software não consegue estabelecer conexão sobre suas portas definidas > nos > >> socket padrões da aplicação ( bloqueio via firewall ) > >> O Software recorre a mensagens encapsuladas no http ( bloqueio via > firewall > >> ). > >> O software apela para protocolos criptografados, enterceptação do proxy > ( > >> bloqueio via proxy ). > >> O Software não consegue conexão com seus gateways de autenticação, > exastão > >> dos recursos por parte do softwares. > >> > >> A unica forma de bular isso tudo é utilizando software tais com o Thor e > >> ultrasurf, e um conhecimento significativo para conseguir configurar > essas > >> aplicações, porem ainda é possivel dar um fim nessas aplicações atraves > de > >> proxy autenticados munidos de comunicação com IDS/IPS onde se bloqueia > >> dinamicamente os proxy de interconexão utilizado por tais softwares, se > a > >> rede é corporativa a maneira mais simples é configurar o anti-virus para > >> não permitir a execução desses softwares, ainda procuro um modo menos > >> intrusivo e complexo para dar cabo nisso se alguem tiver um caminho > para me > >> guiar sou todo ouvidos. > > > > > > Paulo, pegando carona na sua excelente explicação (diga-se de passagem, > > muito boa) sobre o funcionamento da comunicação desses aplicativos que > nos > > atormentam, queria saber como o proxy consegue ler esse conteúdo, uma vez > > que ele encontra-se criptografado, logo, ilegível pra ele. > > > > Abraços. > > > > > > PS: Se eu estiver sendo muito inconveniente, por favor, me perdoe. > > > > -- > > Att, > > Marcus Vinicius. > > ------------------------- > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > Perdão pela demora de respostas, só vi a mensagem agora... > Bom a informação no caso encontra-se citado na explicação acima, o > trecho em especifico é o seguinte. > > ________________________________________________________________________ > >> Como os messengers não terão exito na porta 80 apelaram para o ultimo > >> recurso, protocolo https ( porta 443 ) quando o proxy trabalha de modo > >> transparente o mesmo não pode interferir em trafego interceptado por > ser > >> inelegivel para ele, porem quando configurado no navegador ele entra em > >> cena sobre um estilo de ataque tipo man-int-the-middle, visto que na > >> realidade não é a estação do usuário que se conecta no servidor > remoto mais > >> sim o proxy e para que o proxy saiba onde o usuário queira se conectar > a > >> estação usuária é obrigada e permitir que o proxy compreenda a > informação. > _______________________________________________________________________ > > Em uma analogia mais próxima da compreensão humana, quando é definido no > navegador para que o mesmo utilize explicitamente um serviço proxy se > equipara com a conversa de um turista em paises que falam outra língua. > > Por exemplo: > Se o turista em visita ao Brasil não souber falar o português e não quer > pagar um tradutor ele simplesmente fica apenas como espectador de > qualquer dialogo próximo ao mesmo ( proxy transparente ), o trafego > criptografado passa por ele porem ele só repete o que ouviu. > > Agora se o turista pagar um tradutor, ele delega confiança explicita > para o tradutor falar em nome dele, assim confia ainda mais no que o > tradutor fala, através da relação de confiança o turista consegue se > comunicar ao seu redor. no caso quando se especifica no browser o proxy > o que se esta fazendo é simplesmente dizendo para o browser ( seu > turista ) confiar no tradutor ( seu proxy ), pois você está apresentando > o turista ( browser ) ao tradutor ( proxy ). > > Bom com essa relação de confiança que o browser delega ao proxy, a > conexão https na verdade é originada pelo servidor proxy sobre explicita > orientação do browser, em resumo quem de fato se conecta no servidor na > web é o servidor proxy e o cliente obtem os dados através do proxy com > delegação de confiança. > > > Espero ter ajudar a compreender o conceito. > > Att. > > > > > > > -- > "Quando a Morte decide contar uma historia, > A melhor ação que possa fazer é ouvi-la, > e torcer por não ser a sua própria a tal história." > > Flames > /dev/null ( by Irado !! ). > RIP Irado! > > Paulo Henrique. > Analista de Sistemas / Programador > BSDs Brasil. > Genuine Unix/BSD User. > Fone: (21) 9683-5433. > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Bom pessoal. Paulo, impecável a sua explicação. Muito obrigado mesmo!!! Você já foi professor? rs.. Brincadeiras a parte, terei de ver alguma solução que automatize a descoberta do proxy (como o WPAD faz), já que não posso fazer isso em quase 400 equipamentos. rs.. No mais, a lógica de funcionamento é sensacional, só dará trabalho pra configurar. Uma ideia me veio a cabeça enquanto eu digitava a frase de cima: como o proxy vai sair pela 3128, eu poderia redirecionar qualquer pessoa que tentasse sair pela porta 80 para uma página qualquer e que nessa página tivesse um "redir" em html que a fizesse baixar o script de configuração de proxy? Desse modo, a opção "detectar automaticamente as configurações" na área de proxy do navegador agiria? Enfim, idéias! Abraços. -- Att, Marcus Vinicius. ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd