Implementação de um proxy web com Squid - Revista Infra Magazine 8

Com o crescimento da tecnologia e a conectividade entre as empresas e a internet, cada vez mais um administrador de sistemas se preocupa com as informações que estão dentro da sua rede.

A internet traz facilidades para comunicação e transmissão de informações entre empresas ou mesmo para uso pessoal, porém, existe a preocupação com vírus, roubo de informações, má utilização de recursos e outros tipos de incidentes de segurança.

Dessa forma, entende-se que o acesso à web é algo que necessita ser controlado, seja por questões de segurança ou de produtividade. Aos administradores, é designada a tarefa de implantar soluções com o objetivo de garantir a segurança da rede através de ações como: bloqueio de acesso a sites inadequados, controle de navegação dos usuários, cache (armazenamento) de páginas mais acessadas para otimizar o uso de recursos, bem como emitir relatórios de navegação para análise posterior.

Diante desse cenário, a Figura 1 demonstra o total de incidentes reportados espontaneamente ao CERT.br (Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil), no período de 1999 a março de 2012, onde é possível constatar que o número de incidentes reportados é crescente, com destaque para os anos 2009 e 2011, em relação ao ano anterior, tendo um aumento considerável em 2011.

Figura 1. Total de incidentes reportados ao CERT.br por ano.

No que diz respeito à segurança de rede, com o crescimento de incidentes, a configuração e utilização de um proxy cache é importante para auxiliar o administrador a ter um controle no acesso a recursos como Web, FTP e outros, de um modo seguro, além de estar em conformidade com a orientação da NBR ISO/IEC 27002:2005, no item 11.4, onde diz que o acesso aos serviços de rede internos e externos devem ser controlados, sendo que para este último, o controle pode ser feito pelo proxy.

A função básica de um proxy na rede é servir como um ponto intermediário entre a rede local e a internet, atuando na otimização da velocidade de acesso a conteúdos web através de cache, filtro de sites indesejados e controle de acessos.

Firewall versus Proxy

O firewall é composto por um conjunto de componentes tais como filtros de pacotes, autenticação, proxies e outros, cada um com uma funcionalidade diferente e desempenhando um papel que influi diretamente no nível de segurança do sistema. O filtro de pacotes e o proxy são configurados no perímetro da rede, atuando como intermediários entre a rede local e a internet, filtrando o tráfego através de regras para determinar se certos tipos de pacote terão autorização para passar pelo servidor ou se serão descartados.

O filtro de pacotes realiza o roteamento de forma seletiva, aceitando ou descartando os pacotes com base no conteúdo do seu cabeçalho ou com base no estado das conexões. Isso quer dizer que, por exemplo, é possível filtrar o tráfego por serviço, através de uma regra que descarte todo tráfego destinado a portas como Telnet e FTP, ou ainda, filtrar pacotes ICMP por tipo ou código, com o objetivo de auxiliar na proteção contra ataques de negação de serviços distribuídos (DDoS – Distributed Denial of Service).

Proxies são soluções que permitem ganho de desempenho e economia de banda implementando um sistema de cache no acesso a sites, armazenando localmente o conteúdo requisitado de forma que, em uma segunda requisição, não precise buscar novamente na internet. Além disso, também é possível trabalhar com alguns filtros de origem e destino, permitindo um controle na navegação web, bem como bloqueio de conteúdos indesejados.

O proxy atua como um intermediário de conexões: o usuário se conecta a uma porta no firewall que, através de outra porta, estabelece a conexão com o destino. Além disso, o proxy não permite conexões diretas e mascara os usuários internos das conexões externas.

A Figura 2 ilustra o funcionamento de um proxy.

Figura 2. Funcionamento de um Proxy - Fonte: MELO et al, 2006.

Requisitos do Sistema

O Squid é uma solução Open Source que roda em plataformas Unix, Linux e Windows. É utilizado no mercado como acelerador e filtro de conteúdo web para diversos tipos de protocolos como, por exemplo, HTTP, HTTPS, FTP e outros. Originalmente baseado no projeto Harvest Cache Daemon, desenvolvido no início da década de 90, suporta operações de redirecionamento de URL, controle de banda para protocolos (traffic shaping), lista de controle de acesso (ACL), módulos de autenticação e opções para armazenamento em disco.

Em relação aos requisitos de hardware para o Squid, disco e memória são recursos que devem ser levados em consideração, pois são utilizados para armazenamento de objetos e resposta em cache. Uma página web é formada por vários objetos, tais como textos, imagens e sons. O tempo em que um objeto será mantido em disco depende de fatores como, por exemplo, a frequência dos acessos a essa página, espaço disponível, entre outros; assim, quanto menor o espaço em disco, menor será o tempo de vida de cada página.

O Squid utiliza uma pequena quantidade de memória para cada resposta em cache, assim, existe uma relação entre o espaço em disco e os requisitos de memória. Como regra geral, é necessário ter 32 MB de memória para cada Giga de espaço em disco. Por exemplo, um sistema com 512 MB de RAM pode suportar um cache de disco de 16 GB.

Diretivas do arquivo de configuração

As configurações do Squid são feitas em seu arquivo squid.conf, localizado no diretório /etc/squid. Este arquivo possui cerca de 4900 linhas, mas isto se deve ao fato do arquivo possuir para cada opção a sua sintaxe e um breve resumo. A Listagem 1 apresenta um exemplo do squid.conf.

Listagem 1. Exemplo de configuração do squid.conf.

http_port 3128 cache_mem 8 MB cache_dir ufs /var/spool/squid 100 16 256 cache_access_log /var/log/squid/access.log cache_log /var/log/squid/cache.log cache_store_log /var/log/squid/store.log pid_filename /var/run/squid.pid visible_hostname proxy.myhostname.com.br cache_effective_user squid cache_effective_group squid reference_age 1 week no_cache deny SSL_ports acl MyNetwork src 192.168.x.x/24 acl gateway src 192.168.x.254 acl International dstdomain .com acl Google dstdomain .google.com http_access allow MyNetwork Google http_access deny MyNetwork International http_access allow MyNetwork

Antes de partir para a configuração em si, vejamos as principais diretivas do arquivo squid.conf:

● visible_hostname – Nome do host em rede para exibição em possíveis erros ou informações nas solicitações dos clientes. Caso a opção seja utilizar o nome completo da máquina, este deverá ser colocado conforme a configuração no arquivo /etc/hosts. A Listagem 2 demonstra um exemplo;

Listagem 2. Exemplo do arquivo /etc/hosts.

# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 squid-lab 192.168.1.5 squid-lab.org squid-lab

● http_port – Essa diretiva é responsável por especificar em qual porta o servidor irá escutar as requisições. A porta padrão é a 3128, porém, pode ser especificada outra porta, como por exemplo, a 8080, sem nenhuma complicação. Ao manter essa configuração, o serviço estará disponível em todas as interfaces de rede da máquina. Para limitar o serviço a apenas uma interface, basta configurar o IP e a porta, conforme o exemplo:

http_port 192.168.0.1:3128

● cache_mem – Quantidade de memória RAM disponibilizada para o proxy (valor em MB). É ideal para armazenar arquivos pequenos, como páginas HTML e imagens, que serão entregues instantaneamente para os clientes;

● cache_dir – Diretório que especifica o tipo de armazenamento que o proxy irá utilizar. O cache na memória RAM é quase sempre menor do que o do cache em disco, que é usado para armazenar arquivos maiores, tais como downloads, arquivos do Windows Update e pacotes baixados via aptitude (Nota do DevMan 1). A sintaxe padrão dessa diretiva é:

cache_dir ufs /var/spool/squid 100 16 256

Nota do DevMan 1 - Vias de Download

O apt-get é uma ferramenta prática que se encontrado não apenas no Debian, Ubuntu e no Kurumin, mas em outras distribuições baseadas no Debian, como o Xandros, Memphis e até mesmo no Linspire. Ferramentas como o urpmi, do Mandrake, o synaptic, do Conectiva e o yum, do Fedora também são baseados nele.

O apt-get utiliza um conceito de fontes de atualização. Ele pode obter pacotes de praticamente qualquer lugar, incluindo CD-ROMs do Debian, unidades de rede, etc. Mas o meio mais usado é justamente baixar os pacotes via internet, o que permite obter sempre as versões mais recentes dos programas.

Embora o apt-get seja a ferramenta mais tradicional e a mais usada, ele disputa o posto com o aptitude, um "sucessor" que se propõe a resolver os mesmos problemas, mas oferece algumas vantagens técnicas sobre o apt-get. OAptitudeé uma interface em modo texto para osistemade pacotes doDebianGNU/Linux. Ele permite que o usuário/administrador veja as listas de pacotes e realize operações como instalação, atualização e remoção de pacotes.

A Tabela 1 ilustra os parâmetros dessa diretiva.

Tabela 1. Parâmetros da diretiva cache_dir.

● cache_access_log – Determina a localização do arquivo de log de acesso. Pode ser utilizado para fins de auditoria como, por exemplo, verificar quem acessou o que e quando;

● cache_store_log – Armazena o log detalhado sobre o processo de armazenamento em disco, podendo fornecer informações como quais arquivos foram removidos do cache, quais foram mantidos e por quanto tempo;

● cache_log – Arquivo responsável pelo log de informações relacionadas ao proxy, sendo útil para depuração de eventuais erros que possam impedir a inicialização do serviço;

● pid_filename – No Linux, todos os processos são identificados por um número. Essa diretiva guarda o número do processo do Squid em execução;

● cache_effective_user – Usuário dono do processo do Squid. Por questões de segurança, o Squid não deve ser executado como root. Se o processo for iniciado como root, o Squid irá mudar o ID do usuário efetivo para um usuário sem privilégios, que deve ter permissão de escrita nos diretórios de cache e do arquivo de log. Por padrão, o usuário sem privilégios usado é o nobody, mas é possível criar um usuário chamado squid, para iniciar o serviço:

useradd -g squid -s /dev/null squid

● cache_effective_group – Grupo dono do processo do Squid. Por padrão, o ID do grupo do Squid está relacionado com o do usuário que iniciou o serviço. Se o usuário for o root, ele irá mudar para o grupo do usuário especificado na diretiva cache_effective_user, porém é possível configurar o Squid para usar o ID de outro grupo. Isso só é necessário caso o Squid seja iniciado como root, se não for o caso, essa diretiva será ignorada. Para criar o grupo do squid:

groupadd squid

● reference_age – Determina que a limpeza automática do cache seja semanal. Caso essa diretiva não esteja habilitada, o padrão é que isso ocorra mensalmente;

● no_cache deny SSL_ports – Impede a realização de cache de páginas seguras para evitar que informações dinâmicas sejam consultadas posteriormente;

● acl – Regras de acesso. As ACLs – Access Control Lists ou Listas de Controle de Acesso – constituem a grande flexibilidade e eficiência do Squid. Através delas são criadas as regras para controlar o acesso ou ainda otimizar a utilização da Internet;

● http_access – Permite ou nega clientes (browsers) a acessarem o serviço HTTP baseado na lista de acesso (acl) definida.

Instalação

Em função do que foi exposto acima, é possível ter uma ideia do arquivo de configuração do Squid e de suas diretivas. A próxima etapa a ser realizada é a instalação dos pacotes utilizados para uma configuração funcional do servidor, que será baseado em Debian GNU/Linux 6.0. Vale ressaltar que o Squid também é encontrado para formato em compilação ou em outras distribuições, sendo recomendado o conhecimento no gerenciamento de pacotes para configuração na distribuição preferida pelo usuário. O mesmo vale para o Windows.

No Debian, o gerenciamento de pacotes será feito via aptitude e poderá ser utilizado qualquer repositório que contenha o pacote do servidor Squid abordado nessa configuração. Para instalar, execute:

# aptitude install squid

Um procedimento de verificação em um sistema Debian GNU/Linux para saber se um pacote foi ou não instalado pode ser realizado através do comando dpkg. A Figura 3 demonstra como verificar se o pacote está instalado corretamente.

Figura 3. Verificando se o pacote squid foi instalado corretamente.

Configurações iniciais

Antes de serem iniciadas as configurações, é importante fazer um backup do arquivo de configuração do Squid. Assim, será possível retornar ao original, caso apague alguma linha indevidamente, ou simplesmente queira fazer uma consulta. No Debian GNU/Linux que será configurado, o arquivo squid.conf encontra-se no diretório /etc/squid, porém, dependendo da distribuição, pode estar localizado diretamente sob o /etc. Para fazer uma cópia, basta utilizar o comando cp:

# cd /etc/squid/ # cp squid.conf squid.conf.original

O arquivo de configuração do Squid é bem extenso devido à documentação e pode ser um pouco confuso para trabalhar. Uma vez que foi feito o backup do original, é recomendado criar um arquivo limpo, sem comentários. Para isso, pode-se utilizar o comando egrep para remover linhas que são iniciadas por um comentário (^#), linhas em branco (^$) e colocar a saída dentro do arquivo que será utilizado para configurar o Squid.

# egrep -v "^#|^$" squid.conf.original > squid.conf

Agora sim, iremos analisar a configuração do arquivo limpo e aplicar as configurações iniciais para um servidor proxy cache funcional, sem nenhuma restrição. Neste artigo, o editor de textos utilizado será o vim, porém, o usuário poderá editar o arquivo através de outros editores de texto. A Listagem 3 demonstra o arquivo limpo que será utilizado.

Listagem 3. Arquivo squid.conf.

# vim /etc/squid/squid.conf acl all src all http_port 192.168.1.5:3128 visible_hostname squid-lab.org cache_dir ufs /var/spool/squid 512 128 256 cache_mem 16 MB acl all src all acl manager proto cache_object acl localhost src 127.0.0.1/32 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 acl localnet src 10.0.0.0/8 # RFC1918 possible internal network acl localnet src 172.16.0.0/12 # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl SSL_ports port 443 # https acl SSL_ports port 563 # snews acl SSL_ports port 873 # rsync acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https 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 631 # cups acl Safe_ports port 873 # rsync acl Safe_ports port 901 # SWAT acl purge method PURGE acl CONNECT method CONNECT 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 all icp_access allow localnet icp_access deny all hierarchy_stoplist cgi-bin ? access_log /var/log/squid/access.log squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880 refresh_pattern . 0 20% 4320 acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9] upgrade_http0.9 deny shoutcast acl apache rep_header Server ^Apache broken_vary_encoding allow apache extension_methods REPORT MERGE MKACTIVITY CHECKOUT hosts_file /etc/hosts coredump_dir /var/spool/squid

Dentro do arquivo squid.conf, a primeira diretiva a ser configurada é a http_port, onde se estabelece que o Squid irá trabalhar como servidor de cache apenas na rede local, que no nosso caso é a 192.168.1.0. Para isso, deve-se especificar o IP e também a porta que o Squid irá ouvir as requisições (por padrão, é a 3128):

http_port 192.168.1.5:3128

Outra diretiva a ser alterada é a visible_hostname, que está relacionada com o nome que será exibido no rodapé da página para o usuário quando o Squid retornar algum tipo de informação ou erro. Aqui pode ser colocado o nome completo do servidor, que deve ser o mesmo que está configurado no arquivo /etc/hosts:

visible_hostname squid-lab.org

Nessa configuração inicial, também serão informadas as diretivas referentes ao cache em disco e cache em memória. Para a diretiva cache_dir, o armazenamento será em /var/spool/squid com 512MB de espaço, 128 diretórios e 256 subdiretórios. Para a diretiva cache_mem é definido 16 MB, ficando o arquivo da seguinte forma:

cache_dir ufs /var/spool/squid 512 128 256 cache_mem 16 MB

A configuração padrão do Squid faz com que o serviço esteja no ar, porém todas as requisições são negadas. Como nesse primeiro momento o objetivo é deixar o Squid funcional, é necessário localizar a diretiva http_access que nega (deny) as conexões para permitir o acesso (allow):

http_access deny all

Para permitir que todos tenham acesso à internet através do Squid, essa linha deve ser alterada para:

http_access allow all

Nesse primeiro momento, somente essas alterações são necessárias para se configurar o Squid como um servidor Proxy cache básico. Quando o pacote do Squid é instalado, automaticamente o serviço é iniciado. Assim, após salvar o arquivo, o próximo passo é parar o serviço, verificar a sintaxe do arquivo de configuração, gerar o cache e reiniciar o Squid. A Listagem 4 apresenta os comandos para esses procedimentos.

Listagem 4. Procedimentos para iniciar o serviço.

Parando o serviço: # invoke-rc.d squid stop Stopping Squid HTTP proxy: squid. Verificando a sintaxe do arquivo: # squid -k parse Obs.: Caso o comando não retorne nada, a sintaxe está correta. Criando a estrutura de cache: # squid -z 2012/07/22 00:10:18| Creating Swap Directories Iniciando o serviço: # invoke-rc.d squid start Starting Squid HTTP proxy: squid.

Para conferir se o serviço está no ar, é possível adicionar a opção ‘status’ ao comando invoke-rc.d:

# invoke-rc.d squid status squid is running.

Configuração dos navegadores

Com as configurações realizadas, o Squid está atuando apenas como um servidor proxy cache, ou seja, as estações de trabalho da rede 192.168.1.0 irão utilizar o servidor Proxy 192.168.1.5 como um intermediário para o acesso à internet. Para isso, a próxima etapa é configurar os navegadores das estações clientes.

Internet Explorer

De uma maneira geral, os passos para configurar o Internet Explorer para acessar a internet utilizando o servidor proxy configurado consistem em acessar o menu Tools (Ferramentas) e selecionar a opção Internet Options (Opções de Internet), conforme apresentado na Figura 4.

Figura 4. Configurando o Internet Explorer – Etapa 1.

Ao abrir a janela de configuração, é necessário clicar na aba Connections (Conexões) e em seguida, no botão LAN Settings (Configurações da LAN), que irá apresentar uma janela que permite que seja realizada a configuração de acesso através de um servidor proxy (ver Figura 5).

Figura 5. Configurando o Internet Explorer – Etapa 2.

Neste momento, selecione a caixa Use a proxy server for your LAN... (Usar um servidor proxy para a rede local...) e digite o endereço IP do servidor e a porta na qual o serviço é oferecido. Marque também a caixa Bypass proxy Server for local address (Não usar proxy para endereços locais), conforme demonstrado na Figura 6.

Figura 6. Configurando o Internet Explorer – Etapa 3.

Ao finalizar a configuração, clique em OK em todas as telas. Em seguida, feche e abra novamente o navegador.

Para verificar se o Squid está funcionando, ao abrir o navegador, realize o acesso a algum site. Em seguida, no servidor, verifique os logs de acesso. A Figura 7 demonstra um trecho do access.log. Note que algumas solicitações de acesso já estão sendo tratadas.

Figura 7. Trecho do log access.log.

ACL – Access Control List (Lista de Controle de Acesso)

Até este momento, a configuração do Squid está restrita a um servidor proxy cache, porém, uma das funcionalidades dessa ferramenta é o controle das requisições feitas pelos usuários através do uso de ACLs de acordo com a configuração da regra, permitem bloquear, registrar e autorizar os acessos com diversos parâmetros como:

● Origem/Destino da requisição;

● Horário da requisição;

● Endereço MAC;

● Disponibilidade de banda de acesso;

● Filtros personalizados baseados em strings ou expressões regulares.

As listas de acesso oferecem flexibilidade no momento de classificar os usuários e definir as políticas de segurança para utilização. Elas são definidas em uma seção específica do arquivo squid.conf, combinadas com as diretivas http_access, que serão demonstradas mais a frente.

Sintaxe da ACL

Um dos itens mais importantes do arquivo de configuração squid.conf são as listas de controle de acesso, ou ACLs. É sobre elas que abordaremos neste tópico.

É possível criar ACLs com padrões diferentes de restrição e acesso como, por exemplo, liberação e/ou bloqueio de acesso à internet para um determinado computador, rede de computadores ou sites indesejados. Neste artigo, serão demonstrados exemplos para as seguintes listas de controle:

● ACLs de origem: são as regras que definem os IPs que poderão ter acesso ou restrição às regras definidas;

● ACLs de destino: definem qual destino poderá ser ou não acessado. Este controle pode ser realizado informando um site, uma rede ou fazendo uso de expressões regulares;

● ACLs de horário: permitem liberar ou bloquear o acesso de acordo com horários definidos nas regras;

● ACLs utilizando blacklist: permite controle granular no bloqueio de acessos através de palavras específicas;

● ACLs utilizando whitelist: permite controle granular na liberação de domínios que contenham palavras da blacklist.

A sintaxe para criação de uma ACL é:

acl nomeacl tipoacl argumento

Onde:

● acl: nome padrão para iniciar a regra;

● nomeacl: nome para identificação;

● tipoacl: tipo de acl que será criada;

● argumento: opções que podem ser adicionadas.

A Tabela 2 demonstra alguns exemplos de filtros.

Tabela 2. Exemplos de filtro de conteúdo.

O arquivo squid.conf original traz uma seção para que o administrador adicione as suas próprias ACLs, indicada pelo comentário # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS. Como demonstrado anteriormente, o arquivo utilizado neste artigo está sem os comentários. Assim, as listas de controle personalizadas devem ser inseridas abaixo da linha http_access deny CONNECT !SSL_ports.

Configuração de ACL

ACL de Origem

Esse tipo de ACL tem por objetivo criar regras que irão se basear no endereço IP ou rede de origem do cliente que solicitou a requisição de acesso. Para configurar, é necessário abrir o arquivo squid.conf, localizar a seção das ACLs e inserir as linhas:

acl MyNetwork src 192.168.1.0/24 acl gateway src 192.168.1.1

Seguindo essa sintaxe, foi criada uma ACL que terá como origem de acessos os IPs da rede 192.168.1.0/24. Na segunda linha, foi definido o IP do gateway que essa rede utiliza.

ACL de Destino

Na ACL de destino, as regras irão se basear no endereço IP do servidor solicitado (destino) na requisição do cliente. Nessa configuração, é possível restringir o acesso a outras redes, endereços de domínio ou partes de um domínio.

Para isso, será necessário inserir as ACLs conforme demonstrado abaixo:

acl MyNetwork src 192.168.1.0/24 acl International dstdomain .com acl Google dstdomain .google.com

Na primeira linha é informada a rede de origem que será usada como base para a regra de acesso. Na segunda linha, a ACL International terá como domínios somente os endereços que tiverem na URL o final .com. Finalmente, na terceira linha, é definido que a ACL Google terá como destino o site .google.com.

Essa estrutura foi criada com o intuito de restringir o acesso da rede a um site com o domínio .com, exceto para o google.com. Isso quer dizer que, se o usuário tentar abrir o site www.amazon.com, por exemplo, não irá conseguir.

Configuração da diretiva http_access

Através das ACLs são definidos os tipos de controles para a rede onde, por exemplo, o Squid é configurado para analisar tudo que se origina na rede 192.168.1.0. Porém, ainda nessa etapa, as requisições não são tratadas, sendo necessário configurar a diretiva http_access.

Uma vez que as ACLs de origem e destino foram criadas, é necessário definir o que será liberado (allow) e/ou o que será bloqueado (deny) para a rede 192.168.1.0. Para isso, basta localizar a diretiva http_access no arquivo squid.conf e adicionar as linhas:

http_access allow MyNetwork Google http_access deny MyNetwork International http_access allow MyNetwork

Na primeira linha do http_access é permitido que a rede interna tenha acesso ao Google. Já na segunda linha é negado o acesso aos domínios .com que foram definidos na ACL International e, por fim, na terceira linha, é permitido o acesso normal à rede interna.

Testando a configuração

Após realizar as configurações, é hora de testar as regras que foram adicionadas carregando as novas configurações com os comandos:

# squid -k parse # squid -k reconfigure

Antes de efetuar os testes, é interessante deixar no terminal o comando tail rodando. Ele serve para acompanhar o log de acessos e verificar se as regras foram aplicadas:

# tail -f /var/log/squid/access.log

Com o browser configurado, acesse o site www.google.com e em seguida www.amazon.com. O log mostrará os testes e o que foi liberado ou bloqueado conforme a Figura 8.

Figura 8. Trecho do log de acesso.

No browser, o site www.google.com abrirá normalmente, mas ao tentar acessar o www.amazon.com ou qualquer outro site com final .com, deverá ser exibida uma mensagem de erro, como demonstrado na Figura 9.

Figura 9. Erro na tentativa de acesso a site não permitido.

Para ter certeza de que as regras do Squid estão sendo aplicadas, pode-se fazer um teste invertendo o cenário: será permitido o acesso a todos os sites com final .com definido na ACL Internacional, e bloqueado o acesso ao www.google.com definido na ACL Google.

Para isso, as linhas no arquivo squid.conf deverão ser alteradas conforme o exemplo:

Após a alteração, analise se existe algum erro de sintaxe no arquivo, carregue as novas configurações e verifique os logs. Isso é feito conforme a sequência de comandos a seguir:

# squid -k parse # squid -k reconfigure # tail -f /var/log/squid/access.log

Na Figura 10 é possível observar que as regras de acesso foram realmente ajustadas.

Figura 10. Novo erro na tentativa de acesso a site não permitido.

Restrições específicas: bloqueio de acesso por horário

A configuração de uma ACL de horário segue a mesma sintaxe das ACLs demonstradas anteriormente e permite determinar dias e horários em que os acessos serão liberados ou bloqueados.

Como exemplo, serão criadas três ACLs que irão definir o horário da manhã, almoço e parte da tarde:

acl manha time 08:00-11:59 acl almoco time 12:00-14:00 acl tarde time 14:01-19:00

As ACLs de horário podem ser combinadas com outras, permitindo que os usuários acessem alguns sites somente em determinados horários como, por exemplo, a rede MyNetwork terá acesso ao Facebook somente no horário de almoço.

A Listagem 5 apresenta a configuração de uma ACL por horário.

Listagem 5. Exemplo de ACL por horário.

acl Facebook dstdomain .facebook.com http_access deny MyNetwork Facebook manha http_access allow MyNetwork Facebook almoco http_access deny MyNetwork Facebook tarde

No exemplo, foi criada uma ACL para referenciar o domínio .facebook.com e, em seguida, esta foi combinada com as ACLs de horário para que a rede tenha acesso ao site somente em horários específicos.

Gerenciando ACLs com BlackLists e WhiteLists

É possível criar muitas combinações entre as ACLs e, com essa diversidade de informações, o arquivo de configuração pode crescer em termos de quantidade de linhas e ficar desorganizado. Com o objetivo de evitar esse problema, o administrador pode utilizar listas (lists) no Squid reunindo um grupo de palavras ou domínios em um arquivo para liberação e outro para bloqueio.

Esses arquivos podem ser definidos como blacklist e whitelist. Na blacklist são adicionados todos os termos que devem ser bloqueados, enquanto na whitelist entram tanto os domínios que devem ser liberados, quanto os que podem entrar em conflito com a blacklist, como será demonstrado mais a frente.

Para criar a whitelist, execute:

echo -e “xxx\nsexy\nplayboy\ngirls” > /etc/squid/blacklist echo "www.planetgirls.com.br" > /etc/squid/whitelist

Na primeira linha, no comando echo foi utilizado o recurso -e para ativar o modo de edição para que ele entenda que a cada \n é necessário fazer uma quebra de linha dentro do arquivo /etc/squid/blacklist. Na segunda linha foi apenas adicionada a URL no arquivo /etc/squid/whitelist.

O próximo passo é criar as ACLs com o nome das listas e depois definir as regras com o http_access, conforme o exemplo:

acl blacklist url_regex -i “/etc/squid/blacklist” acl whitelist url_regex -i “/etc/squid/whitelist” http_access deny MyNetwork blacklist !whitelist

As linhas acl blacklist e acl whitelist indicam o caminho no qual está o arquivo da lista e a opção -i faz com que o Squid não leve em consideração o case sensitive das palavras. Já no http_access, tudo o que estiver na blacklist será bloqueado, com exceção (representada pelo ponto de exclamação) do que estiver na whitelist.

É importante observar que a palavra girls foi adicionada na blacklist, porém foi liberada a URL www.planetgirls.com.br na whitelist, porque são palavras conflitantes, isto é, uma página pode ser bloqueada porque contém a palavra ‘girl’. Daí a necessidade de criar uma exceção para determinadas URLs.

Após as alterações, da mesma forma como foi demonstrado anteriormente, é necessário realizar a etapa de atualização das configurações do Squid e acompanhar no terminal o registro nos logs dos resultados de acesso a dois sites que tenham a palavra girls.

A Figura 11 apresenta um trecho do log de acesso após a configuração das ACLs blacklist e whitelist.

Figura 11. Resultado de acessos após a configuração de blacklist e whitelist.

O uso de listas pode facilitar o gerenciamento da configuração de restrições no Squid. É recomendado que o administrador analise e teste as regras antes de disponibilizá-las efetivamente na rede.

Logs no Squid

Os arquivos de log são as fontes primárias de informações sobre o funcionamento do Squid. Isto inclui URIs solicitadas pelos usuários, objetos que foram salvos em disco, mensagens de advertências e erros.

No que diz respeito a registros das atividades dos usuários na rede, a configuração do Squid tem vínculo com as orientações da NBR ISO/IEC 27002:2005 no item 10.10.1, onde é recomendado que sejam gerados registros (log) de atividades dos usuários e que sejam mantidos por um período de tempo determinado pela empresa com o objetivo de auxiliar auditorias, investigações e monitoramento de controle de acesso. Assim, para cumprir essa orientação, são configuradas as diretivas cache_access_log, cache_store_log e cache_log, que indicam os locais onde os logs serão armazenados.

Os arquivos cache.log e store.log contêm informações sobre o funcionamento do Squid e objetos que entraram e saíram do cache, respectivamente. Já o arquivo access.log registra ações dos usuários que podem produzir relatórios de quais sites foram acessados, horários, quantos bytes foram baixados, quantas conexões foram feitas, quais sites foram negados, falha de autenticação, entre outros.

Auditoria de acesso com SARG

O SARG – Squid Analysis Report Generator – é uma ferramenta que tem como objetivo analisar o arquivo /var/squid/log/access.log e, com base nessa análise, gerar um relatório de acesso baseado no acesso dos usuários.

O pacote SARG não está presente no repositório padrão do Debian. Para instalá-lo utilizando o aptitude, é necessário alterar o arquivo /etc/apt/sources.list, atualizá-lo e instalar a ferramenta conforme demonstrado na Listagem 6.

Listagem 6. Instalação do SARG.

# echo deb http://backports.debian.org/debian-backports squeeze-backports main >> /etc/apt/sources.list # aptitude update # aptitude install sarg

Podemos verificar se o pacote sarg foi instalado corretamente conforme a Figura 12.

Figura 12. Verificação de instalação de pacote.

O arquivo de configuração do SARG também é bem detalhado e com muitos comentários, assim como o do Squid. Dessa forma, é interessante fazer um backup do arquivo original e retirar os comentários para ficarmos somente com as linhas do arquivo de configuração:

# cp /etc/sarg/sarg.cof /etc/sarg.conf.original # egrep -v “^#|^$” sarg.conf.original > sarg.conf # vim /etc/sarg/sarg.conf

Não é necessário fazer alterações no arquivo. Mas vale a pena conferir as linhas dos arquivos de configuração como, por exemplo, a linha output_dir /var/lib/sarg, que é a linha na qual ele definirá qual o caminho que irá usar para gerar o relatório e apresentar as informações no SARG.

Os relatórios do SARG são visualizados a partir de uma interface web. Assim, antes de iniciar o serviço, é necessário também configurar o Apache conforme demonstrado na Listagem 7.

Listagem 7. Configuração do Apache para visualização dos relatórios.

# vim /etc/apache2/httpd.conf Alias /squid-reports “/var/lib/sarg/” DirectoryIndex index.html Reiniciando o serviço do Apache # /etc/init.d/apache2 restart Iniciando o SARG # sarg

A linha de Alias define a ligação entre os relatórios gerados em /var/lib/sarg que serão visualizados via browser na URL http://localhost/squid-reports. Já a segunda linha serve apenas para manter como padrão o index.html da página. Após adicionar as informações, reinicie o Apache e inicie o SARG.

Para visualizar os relatórios, basta acessar o endereço no próprio servidor Squid e ver o conteúdo. O endereço utilizado neste exemplo é http://localhost/squid-reports. As Figuras 13, 14 e 15 apresentam alguns relatórios gerados, onde é possível visualizar a lista dos IPs de cada host analisado, as URLs que foram acessadas por este, bem como os acessos negados.

Figura 13. Listagem dos IPs analisados.

Figura 14. Listagem das URLs acessadas pela máquina.

Figura 15. Listagem das URLs que foram bloqueadas pelo Squid.

Conclusão

Utilizar o Squid como ferramenta de proxy/cache na rede permite que seja criado um controle sobre o acesso dos usuários ao conteúdo web ou de outras redes. Esse controle consegue ser limitado através de dias e horários e controlado através de logs.

Para uma melhor auditoria do processo de gerenciamento da rede, podemos utilizar o SARG, um software que utilizará os recursos de log do Squid para criar relatórios que facilitam a visualização e controle do administrador de redes.

O Squid é um software que está continuamente em desenvolvimento, com o objetivo de adicionar novas funcionalidades e manter a estabilidade e compatibilidade em várias plataformas, além da possibilidade de integração de ferramentas como firewall e antivírus.

Neste artigo, o Squid foi configurado para atuar como servidor de cache e proxy, com exemplos de regras para controle através de ACLs de origem, destino, horário e criação de listas de acesso. Também foi demonstrado como configurar o SARG para análise de logs e extração de relatórios para fins de auditoria.

Por fim, vale ressaltar que a configuração do Squid não se esgota com as informações apresentadas neste artigo, sendo um interessante estudo, a integração dessa poderosa ferramenta com firewall, antivírus e serviços de autenticação.

Links

ACLs no Squid
http://wiki.squid-cache.org/SquidFaq/SquidAcl

CERT.br. Sobre o CERT.br
http://www.cert.br/

Squid – Site Oficial
http://www.squid-cache.org/

Livros

MELO, S.; DOMINGOS, C.; CORREIA, L. et al. BS7799 – Da tática a prática em servidores Linux. Alta Books. Rio de Janeiro. 2006.

RICCI, B.; MENDONÇA, N. Squid: Solução Definitiva. Editora Ciência Moderna. Rio de Janeiro. 2006.

WESSELS, D. Squid: The Definitive Guide. O'Reilly Media. 2004.