[FUG-BR] Bloqueio HTTPS

[Paulo Henrique]

Em 30 de abril de 2012 10:31, Saul Figueiredo <saulfelipecf em gmail.com>escreveu:

> Em 30 de abril de 2012 10:24, Marcus Vinicius. <surfinhu em gmail.com
> >escreveu:
>
> > >
> > > Não Marcus.
> > > Este é um problema que ocorre apenas quando se usa proxy transparente.
> > >
> > > Você pode der um proxy setado no navegador e não necesariamente usar
> > > autenticação. Pode continuar usando controle por ip.
> > > Proxy autenticado é uma maneira de falar. Na realidade o que você
> > precisa é
> > > de alguma maneira setar o proxy no navegador dos seus clientes.
> > >
> > > Como já falaram por aí, o mais indicado no seu caso seria usar o wpad;
> >
> >
> > Então, Saul.. o bloqueio ficaria por parte do firewall ou pelo bloqueio
> de
> > redes completas (tipo facebook) nas acls do squid, é isso? Pq uma vez
> > configurado o proxy no navegador (manual ou automático), não tenho ainda
> > como filtrar aonde o usuário navega se for https. Ou tenho?
> >
> > --
> > Att,
> > Marcus Vinicius.
> > -------------------------
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >
>
>
>
> Ficaria por parte do seu proxy mesmo. A partir do momento que você
> configura ele no navegador, você passa a ter controle
>
> --
> "Deve-se aprender sempre, até mesmo com um inimigo."
> (Isaac Newton)
>
> Atenciosamente,
> Saul Figueiredo
> Analista FreeBSD/Linux
> Linux Professional Institute Certification Level 2
>
>
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.


Att.


-- 
:=)><(=:

Flamers > /dev/null !!!