Todo administrador de redes que já se viu na eminência de implementar um webproxy restritivo do tipo BlackList (lista negra), recorrendo ao velho e bom (aliás, muito bom) SQUID, já pensou ou mesmo teve que usar algum programa externo de processamento de listas. Na prática, o SQUID é um excelente servidor proxy, com características e recursos fantásticos e que lhe permite não só cachear todo acesso web no servidor local, como estipular diversas políticas restritivas de acesso (as conhecidas ACLs), pelos mais variados critérios.
No entanto, quando a idéia é montarmos um servidor webproxy baseado em listas negras, ou seja, especificando o que NÃO PODE ser acessado na web pela rede interna, estas listas costumam ficar natualmente extensas e, por conseqüente, pesadas a nível de processamento. O aumento exponencial de conteúdos na Internet é inerente à própria web e, estar constantemente atualizado, de modo a garantir ACLs (access list) coerentes com o que se quer bloquear não é uma tarefa simples. Além disso, quanto maiores ficam as ACLs a serem gerenciadas pelo daemon webproxy, mais processamento é requirido e mais lento o sistema acaba se tornando.
Para minimizar estas duas problemáticas, os administradores de sistemas contam tanto com BlackLists pré-definidas, como com programas que se especializaram em processar estas listas, procedendo ou não com a liberação do acesso. Dentre as opções de softwares livres, geralmente utilizados conjuntamente com o SQUID, podemos destacar o: SquidGuard e o DansGuardian (sendo que o segundo caracteriza-se como um software livre apenas para uso não comercial). Resumidamente, toda a configuração de webproxy continua sendo feita no SQUID, mas o processamento das BlackLists (que podem chegar a conter mais de 2 milhões de entradas), bem como, a constante atualização destas listas, são trabalhos “tercerizados” para programas mais competentes neste sentido! 😉
Pois bem… A questão é que até a versão 2.6 do SQUID, no squid.conf (arquivo de configuração do SQUID) era possível encontrar a diretiva (por default comentada) redirect_program. Esta instrução permitia a configuração da tercerização mencionada acima, ou seja, bastava descomentá-la invocando o programa de processamento de listas preferido. A partir da versão 2.6 o SQUID não trás mais esta opção em seu arquivo de configuração. Mas acalme-se, isso não deixou de existir! 🙂
O que acontece é que a diretiva foi sumáriamente substituída por outras duas instruções, que basicamente continuam tendo a mesma sintaxe (forma de manipulação) e filosofia de utilização do redirect_program. Sem mais “delongas” vamos as duas diretivas:
url_rewrite_program – Possui a mesma função que o antigo redirect_program. Sua sintaxe de utilização, no caso do SquidGuard instalado sob um Debian Linux (através dos binários) seria algo assim:
url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
url_rewrite_children – A função desta instrução é definir quantas instâncias do daemon (no caso, do SquidGuard) ficará residente em memória principal gerenciando requisições. Não existe um número mágico, isso depende de caso à caso, mas 5 instâncias numa estrutura pequena é geralmente suficiente:
url_rewrite_children 5
Outra opção incorporada a partir da versão 2.6 do SQUID que pode ser interessante configurar é a url_rewrite_concurrency. Esta instrução delimita o número de requisições paralelas que podem ser enviadas para o redirecionador (no caso, o SquidGuard). O default é “0” identificando o estilo singlethreaded (atendimento requisição à requisição).
Bem, agora é só escolher seu redirecionador padrão, personalizar suas BlackLists e configurar o SQUID conforme acima para trabalhar em parceria com este recurso. Bom trabalho! 😉
