Re: Bloquear orkut com eficiencia - SQUID + IPTABLES?
Olá
Cássio Rosas escreveu:
Olá pessoal, bom dia, tudo bem!?
Acredito que esse assunto ja deve ter sido discutido aqui, pesquisei e
testei algumas confs porem ainda sem sucesso, o usuário é sempre muito
criativo :).
Gostaria de saber como os demais colegas teem feito para bloquear com
eficiencia o danado do orkut.
Aqui em minha rede faço uso de iptables com squid funcionando como
proxy transparente e alguma coisa em algum lugar não esta dando certo.
No Squid pelo pouco que vie e pesquisei temos mesmo probpemas para
bloquear https, isso confere!? Pois ele é proxy https não é!?
Não, não confere, a diferença é que utilizando https não há como
verificar o conteúdo da conexão e não faz sentido fazer cache de
páginas, o trabalho do squid é limitado nestas situações mas é possível
bloquear o domínio para onde a conexão será feita.
Sendo assim, bloqueiei a palavra orkut atraves da acl regex para o
bloqueio normal. Foi então que os usuarios descobriram que https
passava. Bom dai pensei comigo, facil, bloqueio isso no iptables e
pronto. e foi o que fiz. Porém ainda é possivel conseguir o acesso via
https. Onde posso estar errando!? Será que tem algo no squid que
quando é feito o redirecionamento ele deixa passar o https!? Se for
isso, alguem sabe como resolver!?
1.
Sim existe algo que deixa passar https e existe algo que deixa passar TUDO.
Se você está utilizando proxy transparente qual a porta de destino que
você está redirecionando para a porta 3128 do squid? 80? https utiliza a
porta 443, pelas regras do iptables colocadas abaixo você já deve saber
disso.
E... se a porta 443 está passando, provavelmente junto com o proxy você
configurou um o nat no iptables no estilo "aceita tudo por padrao".
2.
"facil, bloqueio isso no iptables e pronto"
Mais ou menos, tanto no squid quanto no iptables a PRIMEIRA regra que
libere ou negue uma conexão é utilizada e o resto é ignorado. (obs.: no
iptables, em algumas ocasiões a conexão deve ser liberada ou bloqueada
em várias cadeias INPUT, OUTPUT, FORWARD, mas isso não vem ao caso).
abaixo segue as regras do iptables:
iptables -A INPUT -d www.orkut.com -j DROP
iptables -A INPUT -s www.orkut.com -j DROP
A cadeia INPUT processa pacotes PARA ESTA MAQUINA, nesta caso se os
clientes acessam a internet via nat, esta regra é inútil.
iptables -A FORWARD -d www.orkut.com -j DROP
iptables -A FORWARD -s www.orkut.com -j DROP
OK. De certa forma isso faz sentido, pacotes roteados utilizando nat são
processados pela cadeia FORWARD, isso funciona SE NENHUMA REGRA LIBERAR
O PACOTE ANTES.
iptables -A INPUT -s www.orkut.com -p tcp -m multiport --dport
443,80 -j DROP
iptables -A INPUT -d www.orkut.com -p tcp -m multiport --dport
443,80 -j DROP
Idem ao input anterior.
iptables -A FORWARD -s www.orkut.com -p tcp -m multiport --dport
443,80 -j DROP
iptables -A FORWARD -d www.orkut.com -p tcp -m multiport --dport
443,80 -j DROP
Idem ao forward anterior.
Sei que poderia fazer tudo numa linha só, mas foi para ter certeza de
que estava fazendo de forma correta, rs.
E no squid:
acl blockedsites url_regex -i "/etc/squid/bloqueados/block.txt"
acl unblockedsites url_regex -i "/etc/squid/bloqueados/unblock.txt"
acl malware_block_list url_regex -i "/etc/squid/malware_block_list.txt"
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
acl acesso_total src 192.168.10.38
acl acesso_total src 192.168.10.19
always_direct allow all
http_access allow acesso_total
Não vou entrar em detalhes em sintaxe e testar suas configurações, mas
digamos que neste ponto 192.168.10.38 e 192.168.10.19 já tenham acesso a
Internet, se estas forem estações onde nunca será feito nenhum bloqueio
tudo bem.
http_access allow manager localhost
http_access deny manager
http_access deny blockedsites !unblockedsites
Aqui as conexões que você deseja seriam bloqueadas, SE ELAS ESTIVEREM
PASSANDO PELO SQUID.
Se elas estiverem sendo roteadas para fora por nat o squid não está
sendo utilizado.
http_access deny malware_block_list
deny_info http://malware.hiperlinks.com.br/denied.shtml
malware_block_list
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
acl redelocal src 192.168.10.0/24
http_access allow redelocal
Se recomenda colocar um allow ou deny all por ultimo, porque se nenhuma
regra bater, se não me engano vale o inverso da última, apenas para
evitar ambiguidade.
Se alguem souber de algo pu puder dar alguma dica, agradeço.
Abraços e obrigado desde já.
Resumindo. Apesar de algumas "adivinhações" que eu fiz a respeito da
sua configuração não posso garantir isso, isso depende de como você
configurou TODAS as regras do iptables e como você fez o proxy
transparente e nat, a posição das regras pode fazer diferença, elas
podem liberar algo antes de você ter colocado um regra de bloqueio.
Eu pessoalmente prefiro utilizar regras de firewall no estilo "negar
tudo por padrão" e liberar somente as máquinas/destinos/portas
necessários através da cadeia forward para utilizarem nat (sistemas da
receita federal e bancos necessitam disso, por exemplo), assim não há
como outras conexões indesejáveis passarem e inclusive programas p2p
acabam bloqueados também.
Atenciosamente.
Edmundo Valle Neto
Reply to: