Informática e Afins: Configurando um Servidor Proxy Squid com SquidGuard e Atualização de Blacklist no Ubuntu 14.10

Escrito por Francies Silva de Lima.

Olá a todos.

Hoje quero trazer mais um tema que foi um dos tópicos do meu trabalho de conclusão do curso técnico em redes de computadores, Servidor Proxy.

A abordagem deste assunto aqui vai ser mais simples. Pois o foco deste tutorial é para pequenos escritórios, servidores domésticos com fins acadêmicos. Mas nada impede de você melhorar as configurações e torná-lo mais robusto e adequá-lo as suas necessidades. Afinal, estamos tratando de um software livre.

O objetivo principal deste tutorial é:

Criar um servidor de cache para “acelerar” a navegação;
Filtragem de conteúdo indesejado;
Atualização da blacklist em poucos passos.

Vou utilizar o Ubuntu Server 14.10 rodando no VirtualBox e utilizando apenas 512 MB de RAM e 9 GB de HD para o laboratório.

Após a instalação do sistema, faço uma atualização geral como é de praxe.

# apt-get update && apt-get dist-upgrade -y

Após reiniciar o sistema, vamos ao que interessa. Como estamos falando de um servidor, é recomendando, pra não dizer obrigatório, fixar um endereço IP para o mesmo. Se você já sabe como fazê-lo, então faça-o antes de instalar os pacotes. Caso não saiba, veja o meu tutorial sobre o Samba4 que possui as instruções de como fixar o endereço IP e os endereços de DNS.

Instalando os pacotes

Vamos precisar dos pacotes para ativar o serviço de proxy com filtro de conteúdo no servidor. Então vamos instalá-los.

# apt-get install squid3 squidguard

Configurando o Servidor Proxy

Nesta etapa, vou mostrar uma configuração básica com ativação do cache de páginas e filtro de conteúdo.

Primeiro, vamos renomear o arquivo de configuração do Squid e vamos criar outro do zero.

# mv /etc/squid3/squid.conf /etc/squid3/squid.conf.original

Agora vamos criar um arquivo de acordo com a base abaixo.

# vim /etc/squid3/squid.conf

###Configuração básica do squid

http_port 3128

visible_hostname fcfsl #Nome do servidor

redirect_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf

redirect_children 10

###Configuração do Cache

#Tamanho total do cache na RAM

cache_mem 64 MB

#Tamanho do maior arquivo em cache na memória

maximum_object_size_in_memory 64 KB

#Tamanho do maior e do menor arquivo em cache no HD

maximum_object_size 128 MB

minimum_object_size 0 KB

#Quando o cache atinge o limite, estas duas opções excluem os arquivos mais antigos.

#Evitando que o serviço pare.

cache_swap_low 90

cache_swap_high 95

#Tamanho total do cache em disco. No meu caso, 1 GB

cache_dir aufs /var/spool/squid3 1024 16 256

cache_access_log /var/log/squid3/access.log

refresh_pattern ^ftp: 15 20% 2280

refresh_pattern ^gopher: 15 0% 2280

refresh_pattern . 15 20% 2280

#Configuração das regras de acesso

acl all src 0.0.0.0/0.0.0.0

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 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 Safe_ports port 1025-65535 # portas altas

acl purge method PURGE

acl CONNECT method CONNECT

acl redelocal src 192.168.1.0/24

#Validação das regras

http_access allow manager localhost

http_access deny manager

http_access allow purge localhost

http_access deny purge

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localhost

http_access allow redelocal

http_access deny all

Ativando o Filtro de Conteúdo

Conforme a configuração acima, o tráfego de rede passa antes pelo SquidGuard. Mas para que ele funcione, é necessário incluir uma blacklist (lista negra). Mas antes disso, vamos desativar o serviço do Squid antes de começar a configurar o SquidGuard.

# service squid3 stop

A Blacklist funciona como uma base dados contendo vários sites que são classificados em categorias. E é baseado nestas categorias que o filtro trabalha. Pode-se filtrar uma grande variedade de conteúdos.

Exemplos: Jogos, redes sociais, pornografia, audio e vídeo, proxys anônimos, sites contendo conteúdos sobre violência e drogas.

Quanto maior a base da blacklist, maior é a quantidade de sites contidas nele. O Squidguard sugere 4 opções de blacklist de acordo com o link → http://www.squidguard.org/blacklists.html

A melhor de todas é a URLBlacklist.com, mas optei pela Shalla's Blacklist. A URLBlacklist tem limite de downloads por IP, o que pode ser um problema caso haja queda no download. Como eu tive esse problema, resolvi trocar. Mas nada impede de você tentar usá-la, assim como as outras opções disponíveis.

Link para download da blacklist → http://www.shallalist.de/Downloads/shallalist.tar.gz

Após descompactar o arquivo, será criada uma pasta BL. Dentro dela haverá subpastas, cada uma delas representando uma categoria de sites. Estas subpastas devem ser copiadas para o diretório db do SquidGuard.

# cp -R BL/* /var/lib/squidguar/db

Aplique as permissões na pasta para que o Squid e o SquidGuard possam acessar o seu conteúdo.

# chown -R proxy.proxy /var/lib/squidguard/db/*

Configurando o filtro de conteúdos

Agora vamos personalizar o filtro de conteúdo. Mas antes, renomeie o arquivo de configuração do SquidGuard para criarmos um novo.

# mv /etc/squidguard/squidGuard.conf /etc/squidguard/squidGuard.conf.original

Montei um arquivo de exemplo.

# vim /etc/squidguard/squidGuard.conf

dbhome /var/lib/squidguard/db

logdir /var/log/squidguard

src redelocal {

ip 192.168.1.0/24

}

src redewifi {

ip 192.168.0.0/24

}

dest internet {

}

dest pornografia {

domainlist porn/domains

urllist porn/urls

log squidGuard_blocks.log

}

dest spyware {

domainlist spyware/domains

urllist spyware/urls

log squidGuard_blocks.log

}

dest warez {

domainlist warez/domains

urllist warez/urls

log squidGuard_blocks.log

}

dest anonvpn {

domainlist anonvpn/domains

urllist anonvpn/urls

log squidGuard_blocks.log

}

acl {

default {

pass !pornografia !spyware !warez !anonvpn internet

redirect http://www.google.com.br

}

Traduzindo a linha pass, quero dizer o acesso à internet pode ser feito mas que sites pornográficos, com spyware, warez e vpns anônimas sejam bloqueadas e o acesso seja redirecionado para o site do Google.

Após salvar o arquivo, vamos ativar a base de dados da blacklist. Com este comando abaixo, o squidguard lê a lista de domínos e urls cadastradas e gera os arquivos domains.db e urls.db de cada categoria que setamos no arquivo de configuração.

# squidGuard -d -b -P -C all

Em caso de erros, ele mostra a linha onde está o erro e desativa o SquidGuard e trava o terminal, precisando usar CTRL+C para sair. Verifique a saída do log de erro para efetuar as devidas correções.

Você pode cadastrar mais categorias, basta visualizar o conteúdo do diretório /var/lib/squidguard/db/

Concluindo com sucesso o comando anterior, basta ativar novamente o Squid e testar as funções ativadas.

# service squid3 start

Configure as opções de proxy do navegador com o endereço IP e a porta escolhida. No meu caso seria:

Endereço: 192.168.1.190

Porta: 3128

Informações adicionais

Submetendo sites ao serviço de Blacklist

Sabemos que por maior que seja uma blacklist, também devemos levar em conta que milhares de sites são criados diariamente, principalmente pornográficos. E com isso, a blacklist que escolhemos pode não ter na lista o site que queremos bloquear.

Mas existe uma maneira de ajudar o provedor da blacklist que é sugerindo o cadastro de sites em sua base de dados. Eu escolhi a Shalla's Blacklist como base para este laboratório, e no site da mesma há o recurso de submissão de sites pelo seguinte link: http://www.shallalist.de/submissions.html

Nesta página você pode sugerir a adição, remoção e realocação de sites para as categorias disponíveis. É possível até sugerir uma nova categoria. Mas é claro que o site se reserva ao direito de avaliar as propostas, aceitando-as ou não. Então, escreva o link do site corretamente, sem o http:// ou https://, selecionar a categoria a qual ele se encaixa e submetê-lo.

Atualizando a Blacklist

Uma base de dados que não é atualizada, acaba ficando obsoleta e sem utilidade com o tempo. Um exemplo disso são os softwares antivírus que se não forem atualizados, como vão manter o sistema a salvo de novas ameaças ?

Como citado anteriormente, novos sites são criados diariamente. Deste modo, precisamos atualizar constantemente a nossa blacklist.

Antigamente, essa atualização era feita manualmente. A cada novo site acessado por um usuário no local de trabalho que não era permitido, era adicionado em um arquivo de texto que era lido pelo Squid. Mas esse método era bastante cansativo, demandava tempo e paciência para estudar os relatórios de acesso do Squid. Fora que o administrador de rede tem outras funções além de ficar monitorando o acesso ao servidor.

Com o surgimento de ferramentas como o Dansguardian e o SquidGuard, o serviço de filtro de conteúdo vem facilitando bastante o trabalho de quem apenas quer bloquear ou permitir sites por categorias, sem precisar inserir os domínios um a um.

Após fazer algumas pesquisas, resolvi criar um script para automatizar a atualização da blacklist. Ele pode ser adaptado para atualizar outras blacklists.

Nomeei arquivo como updateblacklist.sh

#!/bin/sh

cd /tmp

wget -c http://www.shallalist.de/Downloads/shallalist.tar.gz -O BL.tar.gz

tar -zxf BL.tar.gz

cd BL

rsync -a . /var/lib/squidguard/db/

service squid3 stop

squidGuard -d -b -P -C all

chown -R proxy.proxy /var/lib/squidguard/*

service squid3 start

cd /

rm -rf /tmp/BL*

Desta forma, consegui reduzir o tempo de atualização da blacklist. Caso você queira que atualize automaticamente, utilize o cron para agendar a execução do script em uma determinada hora.

É possível aumentar o desempenho do Squid ?

Essa foi a pergunta que eu mais encontrei nos fóruns sobre fazer cache com o Squid. Lembrando que a performance do servidor depende de alguns fatores importantes:

Velocidade de throughput (largura de banda real) das conexões dos discos rígidos, Hds, com a placa mãe. Os discos e a placa mãe são SATA I, II, III, SCSI, SAS ?

Quantidade de memória RAM do servidor.

Um arquivo de configuração bem escrito e otimizado.

Sabemos que é possível reaproveitar hardware antigo utilizando Gnu/Linux. Mas em qual contexto realmente devemos reaproveitar este equipamento “obsoleto” ?

No caso de um servidor proxy com vários acessos simultâneos, fica inviável você usar uma máquina antiga com Hds IDE ou SATA I com anos de uso. Com certeza o acesso ficará lento com o tempo e estes discos não vão aguentar o tranco ao ponto de deixar o administrador de rede na mão.

Também não podemos esquecer da placa de rede. Uma coisa é usar uma placa Fast Ethernet (10/100 Mbps) em uma rede com poucos computadores, e outra é usar essa mesma placa de rede para servir uma rede com 30, 50, 100 ou 200 computadores, incluindo dispositivos móveis.
Nesse caso, você acha que uma placa Realtek xing-ling vai dar conta do recado ?
Se você não quer gargalos na sua rede, pense pelo menos em equipar o servidor com uma placa de rede que aguente o tranco.

Quanto maior a importância do serviço de rede, maior é a preocupação com a qualidade do hardware que será utilizado. Então pense bem antes de ativar um servidor proxy num Celeron com 1GB de RAM, 80 GB de HD IDE ou SATA I e placas de rede de péssima procedência.

Em se tratando de servidores, sempre digo que memória nunca é demais. Ainda mais que as memórias estão mais baratas do que antigamente. Então vale a pena colocar 4 GB de RAM num servidor proxy. Aumentando o cache de memória para 2 GB e o tamanho dos objetos (arquivos) de 64 KB para 512 ou 1024 KB, por exemplo. Com isso, já dá pra acelerar bastante o serviço, já que a memória RAM é mais rápida que o HD. E quanto maior o cache RAM, mais páginas podem ser armazenadas nela.

Falo que dá até pra iludir o usuário fazendo ele pensar que o link aumentou. Mas o que acontece é que se você acessa os mesmos sites várias vezes ao dia, o cache só verifica o que mudou no site. Se a atualização não for grande, então o site carrega mais rápido e utiliza menos o link de internet.

Após algumas pesquisas, também descobri que é possível melhorar a performance do cache dividindo-o em pequenas partes em vez de usar uma única pasta.

Nas configurações do Squid usadas neste laboratório, usei apenas um cache de 1 GB.

cache_dir aufs /var/spool/squid3 1024 16 256

Usando o exemplo que eu encontrei, a configuração ficaria desta forma:

cache_dir aufs /var/spool/squid3/1/ 256 16 256

cache_dir aufs /var/spool/squid3/2/ 256 16 256

cache_dir aufs /var/spool/squid3/3/ 256 16 256

cache_dir aufs /var/spool/squid3/4/ 256 16 256

Com isso, o cache ficou dividido em partes de 256 MB que vão trabalhar de forma paralela, pelo menos é o que citaram nos fóruns. As sub-pastas 1, 2, 3 e 4 terão de ser criadas e não esqueça de trocar o dono das pastas de root para proxy.

# chown -R proxy.proxy /var/spool/squid3/*

Utilizei apenas 1 GB do HD mas o mesmo conceito funciona com 10, 50 ou 100 GB. Depende do que você vai disponibilizar para o cache.

Outra forma de melhorar o serviço é adicionando os endereços de DNS diretamente no arquivo de configuração do Squid com a diretiva “dns_nameservers”. Pois, sempre que o Squid precisa consultar o DNS, ele dá uma pequena parada. E quanto maior a quantidade de acessos, maior será esse delay.

dns_nameservers 8.8.8.8 8.8.4.4

Também podemos ajudar o Squid a fechar as conexões TCP que não estão mais em atividade. As portas TCP para comunicação externa (internet), possuem um número limitado. Numa empresa com 10 máquinas não é tão perceptível, mas em uma empresa com 300 estações e todas com acesso à internet, pode se tornar um gargalho.

Para solucionar esta questão, utilizamos a diretiva “half_closed_clients”. O Squid não tem como detectar se o cliente terminou de transmitir/receber os dados de um site qualquer no exato momento que o usuário fechou o aplicativo. Isso demanda alguns segundos. Com a diretiva acima, no momento que o cliente parar de transmitir/receber os dados e ficar ocioso, ele encerra a conexão e libera as portas de serviço TCP para outros, otimizando os recursos da melhor forma.

half_closed_clients off

Nas minhas pesquisas vi uma frase comum nos fóruns: “O Squid é um devorador de RAM.” E isso é um fato. Realmente, ele demora para “liberar” a memória que não está sendo utilizada para o sistema operacional, mesmo quando seu uso não é tão alto.

Outra diretiva que ajuda nessas situações é a “memory_pools” que força o Squid a devolver parte da memória não utilizada para o sistema. Mesmo que não seja muito em algumas situações, mas é bem melhor do que usar a memória Swap.

memory_pools off

Considerações Finais

Agradeço a todos por terem lido até o fim e espero que ajude na compreensão deste serviço.

Fazia um bom tempo que eu não utilizava o Squid sem a ajuda de front-ends como o Endian Firewall. E foi ótimo escrever sobre ele porque o serviço sofreu uma grande atualização e é sempre bom estar a par das novidades.

Agradeço aos meus amigos Gilberto Alves, Rajiv Sousa e Emerson Sales por terem me incentivado a escrever sobre esta ferramenta.

Se vocês acharam relevante e útil o que foi escrito, não se importam de clicar no +1 para ajudar na divulgação da matéria ?! =D

Muito obrigado e até a próxima.