Como lidar com sites de bancos OU Permitir determinados sites de sairem pela porta 80

gnumoksha
(usa Debian)

Enviado em 02/05/2013 - 19:47h

Saudações livres,

é sabido que o squid e sites de alguns bancos não operam bem em conjunto, normalmente os usuários utilizam proxy transparente e deixam de redirecionar as requisiçoes para o proxy[0] para poderem resolver o problema.

No meu caso utilizo proxy com WPAD, ou seja, nao é transparente.

Gostaria de saber como voces normalmente lidam com a relação do squid e os acessos a sites de bancos, e tambem sugestoes de como melhorar a situação no ambiente de proxy nao transparente.

[0] http://www.vivaolinux.com.br/topico/Squid-Iptables/squid-bloqueia-bancos#3

gnumoksha
(usa Debian)

Enviado em 03/05/2013 - 16:40h

Palpites?

hunter2800
(usa CentOS)

Enviado em 07/05/2013 - 17:34h

Tenho essa dificuldade tambem!!!

Aqui na empresa liberamos os sites de bancos e alguns outros pelo firewall (IPTABLES) e deixamos o IE sem proxy, e com o Firefox para navegar dentro do Squid autenticado...

Se alguem tiver uma dica melhor....

Esse link postado acima faz o que mencionei sem precisar tirar o proxy?

gnumoksha
(usa Debian)

Enviado em 07/05/2013 - 17:54h

Não.

No teu firewall voce redireciona requisições da porta 80 para a o squid, alem de informar o proxy no browser do cliente?

Buckminster
(usa Debian)

Enviado em 07/05/2013 - 19:00h

O problema é que sites de bancos utilizam muitos plug-ins e estão toda hora atualizando, mudando, por questões de segurança. E alguns plug-ins utilizados causam conflito com o Squid.

Uma solução seria liberar os sites de bancos pelo domínio. Criar uma acl url_regex e colocar dentro do arquivo correspondente os domínios dos sites de bancos.
Mas vejam bem, a ordem de colocação dessa acl é extremamente importante e isso depende de cada squid.conf. Para proxy transparente, uma sugestão é colocar o http_access allow dela antes de todos os http_access.

E se for proxy autenticado, deve se liberar essa acl da autenticação (colocá-la antes de http_access allow password). Mas por isso é extremamente importante fazer pelo domínio. Daí no arquivo da acl vai-se acrescentando os domínios dos sites.

Já no IPtables a coisa se inverte.
Em alguns casos é interessante liberar também no IPtables através de regras semelhantes a essa:
iptables -A FORWARD -m string --algo bm --string "www.bb.com.br/portalbb/home29,116,116,1,1,1,1.bb" -j ACCEPT

onde se colocaria entre as aspas a url; e nesse caso se faria uma regra para cada url.

Pela regra acima o IPtables faz uma busca no cabeçalho do pacote, através do algoritmo "bm" (Boyer-Moore), que é um algoritmo de busca, e o que "bater" exatamente com os caracteres ali colocados ele liberará (ACCEPT) ou bloqueará (DROP).

O IPtables utiliza dois algoritmos, o bm e o "kmp" (Knuth-Morris-Pratt); a diferença básica entre eles, além de outras, é que o bm faz a busca da direita para a esquerda e o kmp da esquerda para a direita, no padrão a ser buscado.

Porém, se você colocar muitas dessas regras, o IPtables poderá tornar o servidor lento, pois ele analisará cada pacote, por isso é importante liberar somente os sites de bancos acessados pela rede interna.
Não tenho como colocar aqui um mínimo e um máximo de regras, pois isso depende também da largura de banda do link da rede, da configuração de hardware do servidor, etc.

Mas fica aí essa sugestão.

gnumoksha
(usa Debian)

Enviado em 07/05/2013 - 21:00h

Veja, no meu caso o squid nao bloqueia acessos, mas sim o squidGuard, e nao creio que sites de bancos sofram de algum bloqueio. Porem, acontece do site fazer alguma requisição sem estar autenticado, creio que seja por isso que voce instruiu a liberar o dominio antes da regra que exige autenticação. Mas peguemos como exemplo o site do bradesco (http://www.bradescopessoajuridica.com.br/) que aparentemente sofreu uma atualização ha um tempinho e do nada parou de funcionar com o squid, o site retornava uma mensagem dizendo que o tempo de sessão tinha esgotado. Agora testei o acesso e parece estar normal. Este mesmo site, na primeira fez que o usuario o acessa atraves de um determinado computador, faz um acesso nao autenticado a url verisign.com, mas prontamente o desbloqueei e mesmo assim o primeiro acesso nao era efetivado, somente saindo do squid foi que deu certo. Com o detalhe que os logs no squid nao mostravam nada de anormal.




É boa a dica sobre pesquisa por string, mas eu até poderia fazer o redirecionamento com base no range de ips utilizado pelos bancos, economizando processamento no firewall. Mas a duvida é como fazer isso se o meu proxy nao é transparente, mas sim via WPAD, ou seja, o cliente pega da rede as informações do proxy e faz requisições diretamente na porta 3128. Penso que o melhor seria interceptar as conexões na 3128 e, caso o destino se enquadre como sendo um site de banco, desviar o acesso para a porta 80, porem nao tenho obtido sucesso nisso.

Buckminster
(usa Debian)

Enviado em 07/05/2013 - 23:48h

Sempre nesses casos é bom limpar o cache do navegador antes de testar de novo (ou reiniciar as máquinas). O Squid (e por conseguinte o SquidGuard) atuam na camada de aplicação, ou seja, praticamente atuam diretamente nos navegadores. Às vezes acontece de o problema estar no navegador que não soube lidar com os plug-ins do site do banco e ao tentar de novo eles tentam o acesso com as informações antigas guardadas em cache.

A Verisign é uma empresa que faz certificados SSL. Sempre é bom instalar e/ou compilar o Squid habilitando o SSL nele com a opção: --enable-ssl

Coloque a regra da string do IPtables antes da regra do redirecionamento.

Você pode também fazer um RETURN no IPtables o que seria uma regra assim:
iptables -t nat -A PREROUTING -s 0.0.0.0/0 -d xxx.xxx.xxx.xxx/24 -j RETURN
onde os xxx seriam o endereço de rede dos sites de bancos.


Você está fazendo a auto-configuração WPAD através do DHCP e do Apache?

gnumoksha
(usa Debian)

Enviado em 08/05/2013 - 15:38h

É uma boa dica, mas no caso que citei mesmo apagando todo o cache do navegador o problema nao foi resolvido e durou dias.



Sabe de outras empresas que fazem o mesmo e sob qual url elas disponibilizam os certificados? Tenho a seguinte lista no squid até o momento:

acl sites_certificado_ssl dstdomain .certisign.com.br
acl sites_certificado_ssl dstdomain .verisign.com
acl sites_certificado_ssl dstdomain .startssl.com
acl sites_certificado_ssl dstdomain .icpbrasil.gov.br
acl sites_certificado_ssl dstdomain .acbr.org.br
http_access allow sites_certificado_ssl




Entao, no range de ips que estou tratando nao ha redirecionamento para os clientes visualizarem o proxy. O WPAD faz com que eles obtenham os dados do proxy, é como se eles tivessem preenchido no navegador os dados. O trafego na porta 80 simplesmente nao existe por padrão, para estes clientes.

Tentei fazer a seguinte regra:

iptables -t nat -I PREROUTING -s ip_maquina_que_esta_fazendo_os_acessos -j ACCEPT



iptables -t nat -N SQUIDWPAD

iptables -t nat -A PREROUTING -s $rede_ip/$rede_mascara -p tcp --dport 3128 -j SQUIDWPAD



iptables -t nat -A SQUIDWPAD -d ip_de_teste -j RETURN



iptables -t nat -A SQUIDWPAD -p tcp --dport 3128 -j REDIRECT --to-port 80

 

Mas quando acesso o ip ip_de_teste as requisiçoes nao vao para a 80, mesmo permitindo o forward na 80.



Sim. DHCP e DNS.

Buckminster
(usa Debian)

Enviado em 08/05/2013 - 17:10h

iptables -t nat -I PREROUTING -s ip_maquina_que_esta_fazendo_os_acessos -j ACCEPT
iptables -t nat -N SQUIDWPAD
iptables -t nat -A PREROUTING -s $rede_ip/$rede_mascara -p tcp --dport 3128 -j SQUIDWPAD
iptables -t nat -A SQUIDWPAD -d ip_de_teste -j RETURN
iptables -t nat -A SQUIDWPAD -p tcp --dport 3128 -j REDIRECT --to-port 80

Troca a porta 3128 com a 80 nessa última regra.

A regra com -I, se não for especificado nenhum número, ela é inserida no topo da chain.
E o return funciona mais para situações assim:

##Criando a chain PROXY no PREROUTING
###################################
iptables -t nat -N PROXY
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j PROXY
#
##Retornando cada IP que tentar escapar do proxy
###########################################
iptables -t nat -A PROXY -s 172.16.1.0/24 -j RETURN
#
##Fim: quem não cair no RETURN, vai cair no proxy
##########################################
iptables -t nat -A PROXY -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PROXY –p tcp –dport 443 –j REDIRECT –to-port 3128

Pois o return faz voltar e ser executado na regra anterior a ele. Se não se encaixar para ele a regra, é executada a política padrão.
Veja o manual do iptables traduzido:
http://www.vivaolinux.com.br/artigo/Manual-do-IPtables-Comentarios-e-sugestoes-de-regras/?pagina=1

Se você quiser, posta aqui teu iptables.

gnumoksha
(usa Debian)

Enviado em 08/05/2013 - 21:38h

Entao, se eu inverter as portas, o firewall estaria redirecionando da 80 para a 3128, correto? Não é isso que eu quero porque os clientes fazem a requisição na 3128, no squid, e como o squid nao trata bem os sites de banco, preciso que saia por outro lugar que nao pelo squid, nesse caso pela porta 80.

Cometi um engano postando essa regra aqui, por que ela está errada, seguindo a logica eu deveria fazer return para todos os hosts que nao fossem o ip_de_teste, ficando assim:

iptables -t nat -A SQUIDWPAD ! -d ip_de_teste -j RETURN



Esse caso que voce especificou é o comum, do firewall fazendo com que o proxy seja transparente, redirecionando da 80 para a 3128. Ok. Mas eu preciso do contrario, da 3128 para a 80. Para que as requisições nao passem para o squid. Me compreende?

Em tempo, voce redirecionou as requisições https, porta 443, para o squid, isso nao funciona.



Possivelmente está na minha lista para ser lido, mas vou dar uma olhada mais rapidamente.

gnumoksha
(usa Debian)

Enviado em 08/05/2013 - 22:46h

Bom, cheguei a algumas conclusões:

1 - O ip de destino, quando o proxy nao é transparente, é o proxy mesmo, nao o site de destino. Isso impossibilita criar regras na tabela nat que filtrem o destino;

2 - Ainda que eu pudesse filtrar, na tabela nat, eu nao poderia redirecionar a requisição para o porta 80, pois isso faria a requisição ir para a porta 80 do servidor, quando deveria fazer forwarding. Isso eu posso contornar redirecionando as requisicoes para uma outro proxy (uso tinyproxy) que nao apresente as mesmas deficiencias que o squid ao acessar um site de banco.

Buckminster
(usa Debian)

Enviado em 09/05/2013 - 01:51h

É que o Squid quando instalado por um gerenciador (apt-get, aptitude, etc) não é instalado com a opção --enable-ssl que dá suporte a certificados SSL, além de outras opções. Para isso o correto é baixar os fontes e compilar o Squid manualmente com várias opções habilitadas para o que se quer (transparente ou autenticado). Daí terminam esses problemas.

"Bom, cheguei a algumas conclusões:

1 - O ip de destino, quando o proxy nao é transparente, é o proxy mesmo, nao o site de destino. Isso impossibilita criar regras na tabela nat que filtrem o destino;

2 - Ainda que eu pudesse filtrar, na tabela nat, eu nao poderia redirecionar a requisição para o porta 80, pois isso faria a requisição ir para a porta 80 do servidor, quando deveria fazer forwarding. Isso eu posso contornar redirecionando as requisicoes para uma outro proxy (uso tinyproxy) que nao apresente as mesmas deficiencias que o squid ao acessar um site de banco."

O teu 1 ali depende da chain: INPUT, OUTPUT ou FORWARD ou uma chain criada por você (e uma chain criada por você não se enquadra nas políticas padrões). Uma regra que você faz em uma chain não é acrescentada em outra chain, são coisas distintas.
E o IP de destino (ou origem) a que você se refere, nesse caso, é o IP da placa de rede. E nesse mesmo IP estão o IPtables e o Squid. O IPtables faz a distinção, nesse caso, pelas portas.
Em outros casos, o IP de origem é o IP que gerou o pacote (solicitação de uma máquina cliente, por exemplo, um site) e o IP de destino é o IP para onde vai o pacote dentro da tua rede. E no IPtables você pode alterar tanto o IP de origem quanto o IP de destino (dentro da tua rede), mas não pode alterar esses IPs para fora da tua rede, pois todos os pacotes saem para fora da rede com o IP do roteador.
Lembre-se sempre que o IPtables atua na camada de enlace (camada 2) e o Squid na camada de aplicação (camada 7), ou seja, o IPtables atua antes na entrada dos pacotes e depois na saída dos pacotes, por isso existem as 3 chains.
Visualize o IPtables como um segurança na porta de uma boate: quem entra passa primeiro pelo segurança e se estiver na lista... entra, e esta lista pode conter restrições, por exemplo, o cara ser revistado ou não. E para sair, deve pagar a conta primeiro (o Squid) e depois passa pelo segurança.

Existem 65.536 portas tcp e 65.536 portas udp num computador, porém, existe somente uma única via de entrada e saída (a placa de rede). É como um prédio com suas salas. Para entrar no prédio, passa primeiro pelo IPtables, para sair passa de novo por ele (por isso existem as 3 chains). O Squid seria, grosso modo, o secretário dos navegadores. Se o cara não tem hora marcada para conseguir falar com o navegador, só invadindo a sala. Mas para isso tem que passar pelo IPtables primeiro e o IPtables e o Squid só fazem o que o administrador manda eles fazerem (as regras).

Vamos supor que um cara entre no prédio (passou pelo IPtables), mas só tem acesso a uma determinada sala e essa sala não é a do navegador... como ele irá falar com o navegador? Não tem como. E se ele tiver o acesso liberado à sala do navegador, terá que passar também pelo secretário (o Squid).

O IPtables é um filtro de pacotes (lê basicamente os cabeçalhos) e o Squid é um proxy (proxy do Inglês significa "procuração" em Português), ou seja, ele tem uma procuração dos navegadores para atuar em nome deles através dos protocolos, IPs, etc.

Mantenha o secretário e o segurança sempre bem informados.