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
