Buenas!

>-----Original Message-----
>From: Rodrigo Soares
>
>Quando incluo um domínio ou IP, em Services --> SQUID -- Cache Mgtm, no 
>campo Do not cache Isso automaticamente implica em ter que liberar o 
>acesso no firewall, já que não vai passar pelo squid?
>
>Pergunto isso, pois você mesmo me sugeriu duas opções: primeira 
>descrita na pergunta e a segunda não fazer proxy para tais domínios. 
>Seria uma ou outra? tanto uma quanto a outra tem a mesma finalidade?
>

Bem, como diria o meu xará, o "estripador", vamos por partes... :)

Existem basicamente 2 formas de você trabalhar com Proxy (Squid):

1) Proxy transparente

2) Proxy Autenticado

No Proxy autenticado você deve configurar no cliente (manualmente ou
automaticamente - existem vários métodos para se fazer isso) que tipo de
conexão passará por dentro do Proxy. Por default, o Squid não trata (nem
cachê, nem ACLs) de conexões HTTPS - Somente HTTP.

Mas no seu caso, por exemplo, onde o browser estava configurado para
encaminhar ao Squid conexões HTTPS e, o serviço no pfSense estava
configurado para rodar de forma "não transparente", o cachê acontece (ou ao
menos tentar acontecer). Em outras palavras, ele vai tentar armazenar
localmente os últimos dados transmitidos em conexões HTTPS. Isso, em vários
CGIs e aplicações web é um problema - Já que, por questões de segurança,
estas aplicações não admitem cópias locais em cachê (querem que os
clientes/browsers sempre busquem conteúdo da fonte - gerando novas
conexões).

Quando você utiliza Squid e SquidGuard, por exemplo, a sequencia de
checagens e processamento da conexão é basicamente:

1) O Squid pega a conexão e tenta aplicar as configurações das ACLs (Proxy
Server -> ACLs) e opções de cachê (Proxy Server -> Local Cache);

2) Se existir alguma exceção na seção "Do not cache", ele tenta seguir (não
executando cachê);

3) Se houver alguma configuração em "White Lists" ou "Black Lists" que
satisfaça aquela URL (quando de conexões HTTP), ele as aplica;

4) Depois das checagens acima, se configurado, ele chama o SquidGuard ou
Dansguardian, por exemplo. Ambos são uma espécie de "acessório" para o Squid
e são invocados automaticamente pelo serviço normalmente apenas para aplicar
ACLs (não se metem com o cachê em si). Novamente aqui estamos falando apenas
de conexões HTTP. Nós, na ConexTI, estamos desenvolvendo (na prática já está
pronto) e implementando sob consultoria um *Filtro de Navegação SSL* para o
pfSense. Neste caso, você consegue aplicar as ACLs do SquidGuard ou
DansGuardian em conexões HTTPS também e, portanto, *não precisa mais
bloquear por default conexões saíntes TCP/443* para aumentar o nível de
segurança. ;-)

A questão é que normalmente você acessa o site do banco via HTTP, então
todas as regras acima para HTTP são executadas. Só depois, durante o login é
que você inicia uma seção HTTPS. Por isso, normalmente, quando você cadastra
o site do banco ou suas redes em "Do not cache", há boas chances de resolver
um problema como o seu. No entanto, alguns sistemas na web, conseguem
"perceber" que a conexão não veio diretamente do cliente (mesmo sem fazer
cachê, ela foi encaminha para o Squid) e podem dropá-la. Nestes casos, o
ideal num Proxy autenticado, é você criar a exceção diretamente no cliente
(no browser - também é possível se automatizar isso, pra não precisar fazer
manualmente em cada PC). Aí a conexão se quer será enviada para qualquer
análise do Squid.

Liberar a porta TCP/443 nas regras de firewall costuma ser uma tática mais
comum no uso de Proxy transparente - Onde o HTTPS nunca é enviado ao Squid
por default. Como a conexão não passa pelo Squid, não há chance de cachê,
então liberando a conexão no firewall os problemas se resolvem. Isso também
vale para os casos em que você marca manualmente no browser para que ele não
use o Squid quando de conexões HTTPS (em todas elas).

Em suma, Proxy e Cache são coisas diferentes. Alguns sites não admitem
nenhum dos dois entre cliente e servidor!~

Bem, sei que ficou meio longa e generalista a resposta... Mas espero ter
conseguido responder sua pergunta. :)


Abraços!

Jack
http://www.jack.eti.br
http://www.conexti.com.br


_______________________________________________
Pfsense-pt mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/pfsense-pt

Responder a