Foi publicado na primeira edição da Infra Magazine um artigo sobre como instalar o sistema operacional FreeBSD para atuar como um gateway. O gateway é o host que atua como um concentrador de tráfego, situado na fronteira entre a rede interna e a externa, sendo por meio dele que as máquinas da rede interna acessam a internet.

Para complementar o artigo da primeira edição, será mostrado como adicionar um servidor proxy ao gateway com o intuito de controlar o acesso e manter a correta utilização da internet, em função do uso a que esta se destina.

Outra utilidade propiciada por seu uso é o controle de acesso, que se baseia em diferentes métodos de autenticação, como: fornecimento de usuário e senha, pelo domínio da rede, pela estação de trabalho, em função do horário do acesso, por agrupamento de regras, entre outros.

Além dos benefícios citados, o Squid aumenta a economia da largura de banda, o que melhora a velocidade de entrega do conteúdo solicitado pelo cliente, permite a criação de regras de controle de acesso à internet e autenticação do usuário, e armazena o conteúdo solicitado para que futuras solicitações não necessitem buscar as mesmas informações na internet, fazendo a leitura diretamente de seu cache. Neste caso, quando é requisitado um conteúdo que sofreu atualização após seu armazenamento em cache, o Squid atualiza tais dados e entrega-os ao cliente, garantindo economia de banda.

Todas as funcionalidades do Squid geram logs que possibilitam ao proxy a disponibilização de relatórios completos, tornando mais fácil a identificação de possíveis problemas, bem como o acompanhamento do desempenho da rede.

O proxy Squid

O Squid é um servidor proxy, open source (código aberto), empregado em atividades relacionadas ao tráfego de pacotes na rede. Dentre as funcionalidades disponíveis, destacam-se: o filtro de conteúdo, que registra em arquivo todo o conteúdo acessado pelas estações da rede; o bloqueador de conteúdo, cuja funcionalidade é restringir o acesso a informações consideradas indesejadas pelo administrador; o autenticador de acesso, que concede acesso à internet somente a usuários conhecidos; e, uma de suas principais características, o cache de conteúdo, que armazena conteúdos recentemente visitados, proporcionando menor tempo de resposta às solicitações do usuário e diminuindo o tráfego entre a rede local e a internet. Cada uma das features destacadas pode ser utilizada individualmente ou em conjunto. Dessa forma, é mantido o controle e registro das atividades dos usuários que fazem uso da internet, permitindo investigações futuras e o próprio monitoramento de acesso em tempo real.

Tantos serviços oferecidos e a disponibilidade de suas versões para os sistemas operacionais das famílias Unix e Windows, além do suporte aos navegadores mais utilizados no mundo, como: Firefox, Internet Explorer e Google Chrome, e a facilidade que o usuário tem em configurar seu browser para o uso deste proxy, fazem do Squid uma excelente escolha para gerenciar a internet como recurso de rede.

O cenário

Como ferramenta para a elaboração deste artigo, foi utilizada uma rede de microcomputadores contendo um host com a funcionalidade de gateway e os demais hosts para atuarem como clientes deste gateway.

O servidor proxy foi instalado no gateway com o objetivo de disponibilizar o acesso à internet mantendo certo nível de controle quanto aos conteúdos acessados.

As solicitações de acesso à internet feitas pelos clientes acontecem de forma controlada, e possíveis tentativas de acesso indevido aos recursos da rede são negadas e registradas em arquivos de log, objetivando a identificação do usuário.

Neste contexto, cabe aos administradores a definição das regras que serão aplicadas ao Squid, sejam eles profissionais ou educacionais, a fim de restringir determinados acessos, a exemplo de conteúdo pornográfico.

Para tanto, será utilizado um microcomputador com o sistema operacional FreeBSD, conforme a Figura 1, compilado com parâmetros do kernel, para atuar como gateway (na primeira edição da Infra Magazine foi mostrado como realizar esta compilação). Após este procedimento, o proxy Squid será instalado e configurado com algumas de suas funcionalidades básicas.

Para atuar como gateway e possivelmente como um proxy, um microcomputador bem modesto atenderá aos requisitos de hardware. Porém, é indicado o uso de um que o disco rígido esteja em bom estado, já que ele será altamente exigido pelo cache do proxy.

 O microcomputador usado no cenário foi um Intel(R) Atom(TM) CPU 330 @ 1.60GHz, 1GB de RAM, HD Maxtor 80GB, com duas placas de rede, sendo uma onboard e outra offboard: sis 900 e RT8139(A/B/C/810x/813x/C+) Fast Ethernet Adapter. A conexão com a internet é via cable modem, onde o provedor fornece o endereço IP automaticamente via DHCP (Dynamic Host Configuration Protocol).

Vale ressaltar que o tráfego das estações será direcionado ao gateway que, por sua vez, redirecionará, por meio do firewall IPFW (Firewall padrão do FreeBSD), todo o tráfego destinado à web pela porta padrão do Squid (3128), que aplicará suas regras – chamadas de ACL (Lista de Controle de Acesso).

A instalação

A versão do sistema operacional utilizada foi a FreeBSD 7.2-RELEASE i386 (veja a seção Links), e a versão do Squid foi a 2.6.STABLE23 (veja seção Links).

Neste exemplo, a instalação do proxy será a partir do código fonte do Squid, para que seja possível realizar os passos aqui descritos também em outras distribuições Linux, tais como Red Hat, Slackware, dentre outras, já que o processo de instalação e configuração é idêntico. Há administradores que optam por realizar a instalação através dos ports (/usr/ports), no entanto, ambas as formas levam a resultados idênticos.

Instalando o Squid

Após fazer o download do Squid em www.squid-cache.org/Versions/v2/2.6/, deve-se acessar o diretório onde foi salvo o arquivo referente a seu código fonte, por exemplo /home/dmedia/squid-2.6.STABLE23.tar.gz e descompactá-lo com o utilitário tar (tar -jxvf squid-2.6.STABLE23.tar.gz). Feito isso, será criado um diretório chamado squid-2.6.STABLE23.

Deve-se logar com o super usuário do sistema (su - ) e, em seguida, executa-se o script de configuração do Squid. Em função da grande quantidade de parâmetros e funcionalidades, este artigo mostrará os mais utilizados para um servidor proxy simples, porém funcional.

O script de pré-configuração do Squid chama-se configure. Através dele serão realizadas as configurações básicas de pré-instalação, como a localização do diretório raiz para instalação, tipo de sistema de arquivos que será reconhecido pelo Squid, dentre outras. Porém, algumas funções não estão disponíveis através do arquivo de configuração (squid.conf), a exemplo dos tipos de sistema de arquivos reconhecidos, que deverá ser informado neste ponto, através do script de configuração, da seguinte maneira:

 

./configure --prefix=/usr --exec-prefix=/usr --sbindir=/usr/sbin --sysconfdir=/etc --mandir=/usr/share/man --bindir=/usr/sbin --libexecdir=/usr/lib/squid --enable-snmp –enable-storeio=aufs,ufs,null --enable-auth=basic --enable-basic-auth-helpers=NCSA --enable-ident-lookups --with-large-files --enable-arp-acl

 

Quando executado, uma longa lista de arquivos e procedimentos de pré-compilação será exibida, estando inclusos nela a verificação de todos os requisitos necessários para o Squid funcionar com os parâmetros indicados. Então, para que sejam evitados problemas com dependência de arquivos, a instalação do FreeBSD foi feita no modo standard.

Conforme mostrado no comando “./configure...”, foi passada como parâmetro uma lista de informações de configuração, cuja sintaxe a ser seguida é a seguinte: variável=parâmetro, onde variável é uma palavra reservada do script de configuração do Squid, e parâmetro pode ser um caminho completo para um diretório ou o nome de um protocolo, assim como mostrado na Tabela 1, onde se tem uma breve explicação sobre cada parâmetro utilizado.

 Com estas configurações, será possível que o Squid faça o cache, filtre os pacotes por endereço MAC, reconheça arquivos grandes, permita autenticação básica com nome de usuário e senha, realize a identificação pelo nome do usuário logado no sistema operacional, habilite o uso do protocolo de gerenciamento SNMP, e habilite o reconhecimento dos sistemas de arquivos mais comuns e utilizados.

Após executar o script configure, será necessário compilar o Squid com o comando make e posteriormente fazer sua instalação com o comando make install.

Para agilizar este processo, os comandos serão utilizados de forma sequencial, make && make install. O símbolo && diz que só se deve executar o comando mais a direita se o da esquerda for bem sucedido, ou seja, se seu retorno for 0. Se tudo ocorrer bem com o comando acima, haverá um retorno em tela semelhante à Figura 2.

 A configuração do Squid

Toda configuração do Squid é feita através de arquivos em formato texto, e o principal arquivo é o squid.conf . Nesta instalação, ele deve estar situado no local informado como parâmetro na variável sysconfdir, logo, estará em /etc/squid/squid.conf.

Configurando o Squid

Como boa prática, deve-se fazer uma cópia do arquivo original antes de iniciar as modificações, pois caso aconteça qualquer tipo de problema com o arquivo manipulado o arquivo original continua à disposição para restauração. Para proceder com as configurações, é imprescindível criar um usuário e grupo para que o processo do Squid o utilize, pois não é seguro deixá-lo com usuários root ou nobody. Usuários com privilégios além do necessário podem ser explorados em falhas/bugs por pessoas maliciosas para causar danos ao sistema.

Ao especificar um usuário, deve-se delimitar seu acesso somente aos recursos necessários para o funcionamento do sistema. Pensando nisso, será criado um grupo com o comando pw groupadd squid e, em seguida, um usuário, já o inserindo no grupo e com o shell (programa que interpreta comandos e os repassa ao kernel do sistema operacional) inválido (Squid não utiliza o shell), através do comando pw adduser squid -g squid -s /dev/null. Feito isso, deve-se modificar o dono dos arquivos de configuração com o comando chown, a fim de que o usuário squid possa acessá-los.

Conforme observado na Figura 3, o usuário não necessita de um shell válido (-s /dev/null), o que melhora a segurança, uma vez que foi restringido que este não terá como executar qualquer comando referente ao sistema operacional, caso ele venha a ser utilizado para fins maliciosos.

Criando a estrutura de diretórios para o cache

É possível criar os diretórios necessários ao funcionamento do Squid em discos separados, o que aumenta a performance em função de os discos trabalharem em paralelo, e a segurança. Contudo, para este artigo, o disco será apenas particionado, técnica conhecida como slice, que divide um disco físico logicamente fazendo com que o sistema operacional trabalhe como se houvesse tantos discos quanto as partições que foram criadas.

O Squid faz uso do disco proporcionalmente à quantidade de usuários e acessos. Logo, quanto maior o número de usuários e seus acessos, maior será o número de registros escritos em disco, o que demanda especial atenção à área em disco destinada ao cache.

O Squid necessita que o administrador crie uma estrutura de diretórios para que ele possa utilizar durante suas operações. Esta estrutura servirá para armazenamento de dados de cache, registros de log, entre outros, conforme mostrado abaixo:

·         Para o cache deve haver o diretório /var/spool. Para tanto os comandos: cd /var/spool e, em seguida, mkdir squid devem ser utilizados;

·         Para arquivos de registros/log, onde serão mantidos os históricos de acesso, deve-se criar o diretório /var/log/squid, através dos comandos cd /var/log e mkdir squid. Após sua criação, deve-se alterar o dono dos diretórios recém-criados para que o Squid possa escrever nos mesmos, conforme os comandos mostrados na Figura 4.

Editando o squid.conf

Em princípio, será mostrada a configuração básica do Squid, o que permitirá o uso de seu cache, bem como o acesso total pelos usuários, ou seja, sem qualquer restrição, mantendo todo registro de quem, onde e quando foi realizado cada acesso, porém forçando a configuração do proxy no navegador do usuário.

Para tal configuração é necessário editar o arquivo squid.conf, inserindo as linhas descritas na Listagem 1. Nos próximos tópicos serão atribuídas mais configurações ao Squid.

 

Listagem 1. Squid.conf básico.

http_port 3128

cache_mem 256 MB

hierarchy_stoplist cgi-bin ?

maximum_object_size_in_memory 8 KB

minimum_object_size 0 KB

maximum_object_size 250 MB

dns_nameservers endereço1 endereço2

error_directory /usr/share/errors/Portuguese

visible_hostname filtro.de.conteudo.FreeBSD.DevMedia

shutdown_lifetime 1 second

 

cache_dir aufs /var/spool/squid 5000 32 512

coredump_dir /var/spool/squid

 

cache_effective_user squid

cache_effective_group squid

 

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

 

acl all src 0.0.0.0/0.0.0.0

acl redeInterna src 10.0.0.0/255.255.0.0

acl localhost src 127.0.0.1/255.255.255.255

 

acl QUERY urlpath_regex cgi-bin \?

no_cache deny QUERY

 

acl manager proto cache_object

acl SSL_ports port 443 563                # https,snews

acl Safe_ports port 80                    # http

acl Safe_ports port 21         # ftp

acl Safe_ports port 443 563          # 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 purge method PURGE

acl CONNECT method CONNECT

no_cache deny SSL_ports

 

http_access allow manager localhost

http_access deny manager all

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 redeInterna

http_access deny all

 

Para melhor entendimento, segue uma breve descrição sobre os parâmetros do arquivo Squid.conf:

·         http_port 3128: Define a porta que será utilizada pelo Squid, sendo 3128 a porta padrão. Pode-se mudá-la desde que as portas sejam acima de 1024 e, no máximo, 65535, pois abaixo dessa faixa é reservada para outros serviços. Para verificar portas e serviços, consulte o arquivo /etc/services. Nele existe o número, protocolo e descrição de cada serviço;

·         cache_mem 256 MB: É a quantidade de memória utilizada para manter os objetos mais recentes, chamados de objetos quentes, e objetos em transição (por exemplo, dados de páginas web). Desta forma o Squid consulta a memória ao invés do disco, o que melhora seu desempenho, já que o acesso a memória é muito mais rápido que o acesso em disco.

·         Para especificar o tamanho ideal, deve-se considerar que para sistemas de 32 bits o Squid usa aproximadamente 10MB de memória por GB no total dos diretórios de cache físico cache_dir. Logo, recomenda-se ter o dobro de memória RAM física com relação à especificada, e como os dados são armazenados em blocos de 4 KB, deve-se sempre especificar o tamanho como múltiplo de 4.

·         O cache_mem nunca deve ser maior que o tamanho físico do cache_dir. Para um cache_mem de 128MB, tem-se um cache_dir de 512MB, dada a fórmula 128 x 4 = 512.

·         Caso o cálculo seja feito em função do tamanho destinado ao cache_dir, por exemplo, 5GB, tem-se acréscimo à fórmula de 10MB por GB, ou seja, 50MB, e o cálculo é dado pelos seguintes valores: ((128 MB + 50 MB) * 4 KB = 712 MB), logo o valor ideal, neste caso, será de 712MB.

·         Como a memória deve ser utilizada também pelo sistema operacional, tem-se como boa prática configurar o dobro. Portanto, este servidor deve ter 1,5GB de memória para não gerar transtornos ou lentidão. Nota-se que ter um cache em disco grande com pouca memória não é vantajoso, uma vez que o Squid fará muito swap comprometendo o desempenho;

·         hierarchy_stoplist cgi-bin ?: Define quais palavras que, quando encontradas em uma URL, não devem ser armazenadas em cache, pois possuem poucas chances de serem novamente requisitadas, o que fará com que esta configuração poupe o cache, aumentando o desempenho do Squid;

·         maximum_object_size_in_memory 8 KB: Tamanho máximo de um objeto em memória. Objetos maiores não ficarão no cache de memória. Logo, o parâmetro deve ter um valor razoável e múltiplo de quatro, conforme mostrado anteriormente. O valor de 8 KB é o padrão, sendo ideal para servidores com bastantes requisições e com a quantidade de memória especificada acima;

·         minimum_object_size 0 KB: Define que os objetos menores que o tamanho configurado não serão salvos em disco. O valor 0 (zero) indica que não há limite. Neste caso todos os objetos serão salvos;

·         maximum_object_size 250 MB: Define que os objetos maiores que o tamanho determinado não serão salvos em disco. Manter esse valor alto exigirá muito da largura de banda. Portanto, deve-se ajustar de acordo com o ambiente, sendo interessante que seja um valor médio referente à largura de banda;

·         dns_nameservers endereco1 endereco2: Determina os servidores DNS utilizados pelo Squid. Os endereços devem ser separados por espaço. O DNS configurado no sistema operacional (/etc/resolv.conf) será ignorado se essa opção for encontrada no Squid. Logo, deve-se inserir tanto o DNS configurado no resolv.conf quanto os adicionais no Squid.conf ou remover essa linha para que seja usado apenas o DNS configurado no resolv.conf;

·         error_directory /usr/share/errors/Portuguese: Decide onde o Squid deve procurar as páginas de erro a serem exibidas quando uma regra for aplicada. Existem páginas próprias para cada tipo de erro que foram traduzidas em várias línguas, sendo possível customizá-las ou desenvolver novas páginas que devem ser visualizadas quando regras específicas forem aplicadas, o que melhora o entendimento do usuário sobre o correto uso da rede;

·         visible_hostname filtro.de.conteudo.FreeBSD.DevMedia: Define o nome do host/servidor que o Squid exibirá, quando solicitado;

·         shutdown_lifetime 1: Define quanto tempo o Squid deve aguardar até que as requisições sejam finalizadas para encerrar seu próprio processo. Deve-se definir um valor baixo para que a ação seja rápida e não cause transtornos por demora na restauração;

·         cache_dir ufs /var/spool/squid 5000 32 512: Um dos parâmetros fundamentais ao funcionamento do Squid (o parâmetro de instalação --enable-storeio afeta diretamente esta opção). É ele quem define como será o cache, e sua sintaxe é explicada na Tabela 2.

Sendo assim, foi definido que o tipo de armazenamento é o aufs (Assíncrono Unix File System), a localização do diretório raiz do cache será /var/spool/squid, e o tamanho máximo do disco, que pode ser usado para os diretórios /cache, será de 5GB.

O parâmetro seguinte se refere ao número de subdiretórios a partir do diretório raiz. Por último, o número de diretórios de nível 2, criados a partir dos subdiretórios de nível 1, ou seja, definiu-se 32 diretórios, sendo que cada um conterá 512 subdiretórios. Tal diretiva pode ser definida múltiplas vezes, para múltiplos caches.

 

·         coredump_dir /var/spool/squid: Quando o Squid é iniciado são criados alguns arquivos chamados de core-dump, que em princípio são armazenados no próprio diretório do Squid. Com este parâmetro é possível alterar a localização padrão dos arquivos core-dump, indicando apenas o novo caminho;

·         cache_effective_user squid: Conta de usuário utilizado pelo processo do Squid;

·         cache_effective_group squid: Identifica o grupo de usuários que será utilizado pelo processo do Squid;

·         cache_access_log /var/log/squid/access.log: Define onde será armazenado o arquivo que mantém todos os registros de acesso. É uma boa prática manter este arquivo em uma partição diferente da que está o sistema operacional e o Squid para que se possa melhorar o desempenho de acesso ao disco.

·         Há a possibilidade de desativar os registros usando a diretiva cache_access_log none. O Squid também disponibiliza um comando específico para rotacionar o arquivo de log, e este pode ser usado juntamente com o agendador de tarefas, como o cron por exemplo, para rotacionar os arquivos a cada período de tempo, através do comando squid -k rotate;

·         cache_log /var/log/squid/cache.log: Determina em que local será armazenado o arquivo que mantém todos os registros referentes ao cache e informações como número de objetos carregados, expirados, requisições inválidas, dentre outros. Também pode ser desabilitado;

·         cache_store_log /var/log/squid/store.log: Decide onde será armazenado o arquivo que mantém todos os registros referentes ao processo de manipulação de disco e que contém informações completas referentes a quais objetos foram salvos, por quanto tempo e quais foram expirados. Aqui podem ser encontradas as informações em caso de falha de leitura e escrita no disco. Esse registro também pode ser desativado (cache_store_log none);

·         pid_filename: Define onde será criado o arquivo que contém o PID do Squid, que será configurado mais adiante no script de manipulação do serviço do Squid.

 

Após a configuração do cache deve-se ajustar as ACLs (Access Control List), que são as regras utilizadas para liberar ou bloquear os acessos.

As ACLs permitem manipular os pacotes de dados, isto é, os acessos, por meio de endereços de origem e/ou destino, usuários, domínios, portas e expressões regulares. Ainda, admite a definição dos horários de acesso e métodos de autenticação.

O Squid é bastante flexível quanto às suas configurações de controle de acesso. Por isso, vale uma consulta ao material oficial (veja a seção Links). A ACL, quando definida, é utilizada pela diretiva http_access, permitindo ou negando o tráfego de pacotes entre origem e destino caso coincidam com alguma de suas regras.

O formato da ACL é: acl <nome_acl> <tipo_acl> <"argumento ou arquivo">, e o formato da diretiva é: http_access <nome_da_acl_a_que_se_aplica> <permissão ou negação>.

Embora existam vários tipos de ACL, a forma de uso é a mesma para todos. O próprio arquivo squid.conf contém exemplos e explicações para cada tipo. Vejamos alguns deles:

·         acl all src 0.0.0.0/0.0.0.0: Define a ACL de nome all, do tipo src (IP de clientes/origem), cujo IP e faixa abrangem todas as faixas de rede A, B, C, D e E. Esta regra será utilizada com a diretiva http_access para negar todo o acesso e bloquear toda a rede;

·         acl redeInterna src 10.0.0.0/255.255.0.0: Determina uma ACL de nome redeInterna, do tipo src, pertencente à faixa de IPs utilizada na rede interna. Esta regra com a diretiva http_access servirá para bloquear todo o tráfego da rede, com exceção dos IPs da rede definida aqui;

·         acl localhost src 127.0.0.1/255.255.255.255: Define uma ACL de nome localhost, do tipo src, cuja faixa de IP/rede é a interface loopback, servindo para permitir os pacotes gerados pelo próprio servidor;

·         acl QUERY urlpath_regex cgi-bin \?: Determina uma ACL de nome QUERY, do tipo urlpath_regex, que será utilizada juntamente com o recurso de expressão regular para procurar ocorrências das palavras cgi-bin ou ? em uma URL;

·         no_cache deny QUERY: Define uma regra de negação (deny), do tipo no_cache, para a ACL de nome QUERY. Ela determina que não deve ser feito cache para conteúdos cgi, pois como normalmente são conteúdos dinâmicos, é importante evitar que informações inválidas ou antigas sejam mantidas e possivelmente acessadas no futuro;

·         acl manager proto cache_object: Cria uma ACL de nome manager, do tipo proto, que define uma regra para o gerenciador de objetos em cache, como por exemplo o squidclient, usando um protocolo especial (cache_object);

·         acl SSL_ports port 443 563# https,snews: Define uma ACL de nome SSL_ports, do tipo port, e seus elementos confiáveis que são as portas seguras;

·         acl Safe_ports port 80#http: Define ACLs chamadas Safe_ports, do tipo port, que são as portas permitidas pelo proxy Squid. Por exemplo: acl Safe_ports port 21# ftp;

·         acl purge method PURGE: Define uma ACL de nome purge, do tipo method. purge é um método específico do Squid que permite que o administrador force a remoção dos objetos do cache. Esta regra será utilizada para permitir apenas solicitações de origem do próprio servidor;

·         acl CONNECT method CONNECT: Determina uma ACL de nome CONNECT, do tipo method, utilizada para permitir conexões diretas através do proxy;

·         no_cache deny SSL_ports: Define uma ACL de negação, do tipo no_cache, às portas seguras, ou seja, não permite que seja feito cache dos objetos, evitando que informações inválidas ou antigas sejam consultadas no futuro, como por exemplo, dados dinâmicos em portas https;

·         http_access allow manager localhost: Cria uma nova diretiva (http_access) que permite (allow) à ACL chamada manager aceitar todas as solicitações referentes ao gerenciamento dos objetos em cache, desde que elas sejam originadas da rede configurada através da ACL localhost (127.0.0.1/255.255.255.255, o próprio servidor);

·         http_access deny manager all: Cria uma diretiva que nega (deny) o conteúdo da ACL manager, ou seja, proíbe ao restante da rede o gerenciamento dos objetos em cache configurados na ACL all;

·         http_access allow purge localhost: Cria uma diretiva que aceita a ACL purge, ou seja, permite que os IPs configurados na ACL localhost possam gerenciar os objetos em cache do Squid através do método purge;

·         http_access deny purge all: Cria uma diretiva que nega a ACL purge para o restante da rede através de seus próprios hosts;

·         http_access deny !Safe_ports: Cria uma diretiva que nega as portas que não estão definidas na ACL Safe_ports. O símbolo de exclamação (“!”) inverte a lógica, ou seja, tudo que for diferente do definido na ACL Safe_ports, como por exemplo, negando as portas de número 81 e 82. Logo, é preciso observar se existem aplicativos na rede que utilizem portas especificas, sendo necessário liberá-las para que eles funcionem corretamente;

·         http_access deny CONNECT !SSL_ports: Cria uma diretiva negando conexões diretas às portas que não estão definidas na ACL SSL_ports;

·         http_access allow localhost: Cria uma diretiva que permite a ACL localhost, ou seja, libera todo o tráfego ou requisição cuja origem seja o próprio host, uma vez que a ACL localhost aponta para o IP de loopback;

·         http_access allow redeInterna: Cria uma diretiva que permite o que foi definido na ACL redeInterna, ou seja, libera todo o tráfego ou requisição proveniente da rede definida na mesma ACL (desde que atenda às regras definidas anteriormente);

·         http_access deny all: Cria uma diretiva que nega todo o tráfego de qualquer origem para qualquer destino, com exceção da rede definida na ACL redeInterna, pois, como o Squid lê as regras de forma sequencial e a ACL redeInterna está posicionada antes desta, logo, já foi liberada. Então, lê-se a regra assim: a rede interna foi liberada e houve bloqueio de todas as outras faixas de endereços possíveis.

 

Após a realização das configurações deve-se executar o binário do Squid para que este leia as configurações e então possa construir o cache/swap e, por fim, inicializar o Squid.

Para construir ou reconstruir o cache é necessário parar o Squid e utilizar o comando /usr/sbin/squid –z. Sua inicialização é feita através do comando /usr/sbin/squid, conforme a Figura 5.

Para quaisquer alterações no arquivo de configuração (squid.conf) é preciso fazer com que o Squid releia o referido arquivo e aplique as novas alterações. Para realizar essa tarefa, deve-se utilizar o comando /usr/sbin/squid -k reconfigure. Assim as conexões ativas não serão interrompidas.

 

Figura 5. Criando cache e inicializando o Squid.

 

Neste ponto o Squid deve estar funcionando, como indicado na Figura 5. Caso contrário, deve-se verificar os caminhos e as permissões dos diretórios: tanto os configurados no squid.conf, quanto os próprios diretórios e arquivos de configuração, incluindo as contas e os grupos de usuários.

Contudo, apesar do Squid estar configurado e funcionando, não implica dizer que o tráfego esteja sendo filtrado, pois é necessário que todas as requisições que passem pelas portas HTTP (80), HTTPS (443) e 8080 (as mais utilizadas) sejam redirecionadas para a porta em que o Squid foi configurado, o que é possível através do parâmetro http_port (3128) existente no mesmo arquivo de configuração. O redirecionamento será feito pelo IPFW (Firewall padrão do FreeBSD).

Para fazer o monitoramento dos logs do Squid (vide arquivo /var/log/squid/access.log) será utilizado o comando tail –f /var/log/squid/access.log. Este comando monitora o arquivo passado como parâmetro e, a partir deste momento, quaisquer alterações sofridas pelo arquivo serão exibidas em tempo real.

Para finalizar o processo de monitoramento do arquivo /var/log/squid/access.log deve-se pressionar ctrl + c. É importante lembrar que o arquivo de log do Squid permanecerá vazio até que o redirecionamento do tráfego das portas citadas seja feito.

Redirecionando o tráfego

Para redirecionar o tráfego serão utilizadas regras de firewall do IPFW, o firewall padrão do FreeBSD.

É importante ressaltar que a política adotada pelo firewall é a totalmente aberta, onde todo o tráfego é permitido através do gateway em qualquer porta e em qualquer direção (entrada e saída).

O próximo passo consiste na criação de um script de firewall cujo objetivo é ajustar as regras para que todo o tráfego das portas 80, 443 e 8080 sejam redirecionados à porta 3128 do Squid. Este script deve estar localizado em /usr/local/etc/rc.d/rc.firewall, conforme mostrado na Figura 6.

 

Figura 6. Script com regras para o IPFW.

 

Como podemos observar, as regras são simples e servem para redirecionar o tráfego. As regras são: de número 500, que nega requisições de qualquer origem para qualquer destino que forem realizadas diretamente na porta 3128, através da interface de rede rl0; a regra de número 501, que faz com que todo o tráfego destinado às portas 80, 443 e 8080, desde que a origem não seja o próprio servidor (not me), sejam redirecionadas à porta 3128 do próprio servidor – 3128 é a porta onde o Squid está “escutando/aguardando” o tráfego; e a última regra, de número 502, que realiza o NAT (Network Address Translation ) através da interface rl0 – o NAT irá mascarar os endereços dos microcomputadores da rede local de maneira que seja possível a comunicação entre a rede interna LAN (Local Area Network) com a rede externa WAN (Wide Area Network, ou rede).

É importante enfatizar a regra de número 501, pois ela é responsável por forçar o uso da configuração do proxy no navegador. Se o proxy não for informado, configurado, não será permitido a navegação, uma vez que requisições diretamente nas portas especificadas (80, 443 e 8081) não serão aceitas.

Esta configuração de firewall aumenta a segurança, já que se algum browser/navegador for desconfigurado pelo usuário, este não conseguirá navegar. Em contrapartida, quando o parque de máquinas é amplo ou existe um fluxo muito grande de dispositivos móveis e não há mecanismos como servidor DHCP (Dynamic Host Configuration Protocol) configurados para atribuir o proxy de modo automático para os dispositivos, poderá exigir maior esforço por parte dos administradores e aos usuários leigos.

Adicionadas as regras de firewall, será necessário ativá-las com o script ou reiniciando o micro. Após o servidor ter sido configurado, será necessária a configuração do proxy nos navegadores dos clientes. A partir deste momento pode-se verificar novamente o arquivo de log do Squid com o comando tail -f /var/log/squid/access.log (veja Figura 7), pois os logs serão registrados durante os acessos.

É importante mostrar aos usuários leigos que tenham necessidade de conectar seus dispositivos em outras redes como remover as configurações de proxy.

Como complemento, vale a pena estudar sobre proxy automático, através dos scripts PAC (Proxy Auto-Configuration) e/ou WPAD (Windows Proxy Auto Discovery) juntamente com o DHCP.

 

 Figura 7. Realizando um acesso e verificando o arquivo de log.

 

Com o proxy já configurado no navegador, conforme se observa na Figura 7, foi possível fazer a simulação do retorno do browser informando ao usuário que o proxy não está configurado, o que pode ser visto na Figura 8.

É possível perceber que a página de erro exibida (Figura 8) está no idioma português, pois o caminho para as páginas foi configurado através do arquivo squid.conf, por meio do parâmetro error_directory, e o nome do host configurado através do parâmetro visible_hostname, o que demonstra facilidade em personalizar as páginas de erros. Para tanto, é necessário apenas um modesto conhecimento de HTML (HyperText Markup Language) para que se possa editar as páginas existentes ou mesmo criar novas páginas de erro.

 

Figura 8. Tentativa de acesso sem proxy configurado.

 

Neste ponto tem-se então um gateway com proxy funcional, surgindo agora a necessidade de se adicionar novas regras a fim de controlar o acesso por endereço IP, por endereço MAC, bloquear palavras contidas em URL e domínios. Mas antes é preciso fazer com que o Squid seja inicializado junto ao sistema operacional.

Iniciar o Squid automaticamente junto ao FreeBSD

Embora o Squid tenha sido configurado corretamente, é necessário fazer com que ele fique disponível automaticamente a cada nova inicialização do sistema operacional. Reiniciar o sistema operacional não é uma atividade rotineira, mas causa transtornos à empresa, por isso, quanto mais rápido e automatizado este processo acontecer, menor será seu impacto.

Sendo assim, será utilizado o sistema de inicialização rc.d do FreeBSD para fazer do Squid um serviço que possa ser iniciado automaticamente através de script e do arquivo rc.conf, assim como feito com outros serviços, a exemplo do firewall. Para tal, será criado um arquivo dentro do diretório /usr/etc/rc.d com o nome squid. Seu conteúdo pode ser visto na Listagem 2.

 

Listagem 2. Script para inicialização do Squid no boot.

#!/bin/sh

#

# PROVIDE: squid

# REQUIRE: ipfw

# KEYWORD: shutdown

 

. /etc/rc.subr

name="squid"

rcvar=`set_rcvar`

command="/usr/sbin/squid"

load_rc_config $name

squid_enable=${squid_enable-"NO"}

squid_pidfile=${squid_pidfile-"/var/run/squid.pid"}

pidfile="${squid_pidfile}"

run_rc_command "$1"

 

Após a criação do arquivo squid, deve-se ajustar suas permissões de modo a torná-lo executável, alterar seu dono para o usuário root e seu grupo para Wheel através dos seguintes comandos:

 

# chown -R root:wheel /etc/rc.d/squid

# chmod 755 /etc/rc.d/.squid.

 

Feito este procedimento, deve-se adicionar a variável squid_enable=”YES” no arquivo rc.conf localizado em /etc/rc.conf.

Logo após, deve-se executar o comando /etc/rc.d/squid rcvar com o intuito de verificar se a configuração está correta, pois a partir deste ponto pode-se manipular o Squid com os comandos /etc/rc.d/squid start|stop|status. Como o foco deste artigo não é o sistema de inicialização do FreeBSD, mais detalhes sobre este assunto podem ser obtidos através da seção Links.

Vale ressaltar que a variável squid_pidfile possui o seguinte conteúdo: “/var/run/squid.pid”, e que este deve ser o mesmo caminho e arquivo de PID que é ajustado no arquivo de configuração do Squid, através da diretiva pid_filename. É através dele que será possível finalizar o processo do Squid com a opção stop.

Outra diretiva que sofre influência direta da opção stop é a diretiva shutdown_lifetime, que configura o tempo de finalização do processo. Quanto maior o valor para shutdown_lifetime, maior será o tempo para finalização do Squid.

Para um teste efetivo, deve-se reiniciar o FreeBSD e verificar se o Squid foi iniciado automaticamente.

Este teste pode ser feito realizando-se um simples acesso a algum site pelo navegador, através do comando ps aux | grep squid no console do servidor ou verificando o arquivo de log do Squid /var/log/messages.

O arquivo messages contém as mensagens referentes a todo o processo de inicialização. Logo, é mais indicado verificá-lo, pois se houver qualquer tipo de erro, é através dele que será possível identificar o maior número de detalhes para se atuar na correção.

Caso tudo esteja correto, o arquivo messages deverá conter o registro da inicialização do Squid, semelhante à Figura 9.

 

Figura 9. Registro de inicialização correta do Squid no /var/lo/messages e a verificação do processo.

 

Neste ponto o Squid está instalado e configurado de modo a registrar todos os acessos da rede, porém ele está aberto, o que quer dizer que todo e qualquer conteúdo poderá ser acessado sem qualquer restrição. Por isso, em edições posteriores da Infra Magazine serão publicados novos artigos que detalharão como podem ser adicionados mais controles e regras no Squid.

Conclusão

Redes empresariais, escolares e de acesso público, requerem o controle do conteúdo acessado através da rede de dados (Internet).

Neste contexto a utilização de um servidor proxy é conveniente e vantajosa quando é preciso manter os registros de identificação do usuário, datas e horários em que foram realizados os acessos, além do registro do que foi acessado ou da tentativa de acesso.

Tais informações possibilitam ao administrador a identificação do perfil de seus usuários, e a restrição do acesso ao tipo de uso a que a rede se destina. Além disso, auxilia no dimensionamento da rede, quanto à largura de banda, uma vez que se pode mensurar o número de acessos, e ajuda a restringir o tempo de conexão dos usuários, quando apropriado.

Sendo assim, o Squid se mostra eficiente na realização das tarefas cotidianas, bastante aderente ao sistema operacional, com baixo custo de implantação, além de ser confiável e robusto, como o FreeBSD.

 

 Foi publicado na primeira edição da Infra Magazine um artigo sobre como instalar o sistema operacional FreeBSD para atuar como um gateway. O gateway é o host que atua como um concentrador de tráfego, situado na fronteira entre a rede interna e a externa, sendo por meio dele que as máquinas da rede interna acessam a internet.

Para complementar o artigo da primeira edição, será mostrado como adicionar um servidor proxy ao gateway com o intuito de controlar o acesso e manter a correta utilização da internet, em função do uso a que esta se destina.

Outra utilidade propiciada por seu uso é o controle de acesso, que se baseia em diferentes métodos de autenticação, como: fornecimento de usuário e senha, pelo domínio da rede, pela estação de trabalho, em função do horário do acesso, por agrupamento de regras, entre outros.

Além dos benefícios citados, o Squid aumenta a economia da largura de banda, o que melhora a velocidade de entrega do conteúdo solicitado pelo cliente, permite a criação de regras de controle de acesso à internet e autenticação do usuário, e armazena o conteúdo solicitado para que futuras solicitações não necessitem buscar as mesmas informações na internet, fazendo a leitura diretamente de seu cache. Neste caso, quando é requisitado um conteúdo que sofreu atualização após seu armazenamento em cache, o Squid atualiza tais dados e entrega-os ao cliente, garantindo economia de banda.

Todas as funcionalidades do Squid geram logs que possibilitam ao proxy a disponibilização de relatórios completos, tornando mais fácil a identificação de possíveis problemas, bem como o acompanhamento do desempenho da rede.

O proxy Squid

O Squid é um servidor proxy, open source (código aberto), empregado em atividades relacionadas ao tráfego de pacotes na rede. Dentre as funcionalidades disponíveis, destacam-se: o filtro de conteúdo, que registra em arquivo todo o conteúdo acessado pelas estações da rede; o bloqueador de conteúdo, cuja funcionalidade é restringir o acesso a informações consideradas indesejadas pelo administrador; o autenticador de acesso, que concede acesso à internet somente a usuários conhecidos; e, uma de suas principais características, o cache de conteúdo, que armazena conteúdos recentemente visitados, proporcionando menor tempo de resposta às solicitações do usuário e diminuindo o tráfego entre a rede local e a internet. Cada uma das features destacadas pode ser utilizada individualmente ou em conjunto. Dessa forma, é mantido o controle e registro das atividades dos usuários que fazem uso da internet, permitindo investigações futuras e o próprio monitoramento de acesso em tempo real.

Tantos serviços oferecidos e a disponibilidade de suas versões para os sistemas operacionais das famílias Unix e Windows, além do suporte aos navegadores mais utilizados no mundo, como: Firefox, Internet Explorer e Google Chrome, e a facilidade que o usuário tem em configurar seu browser para o uso deste proxy, fazem do Squid uma excelente escolha para gerenciar a internet como recurso de rede.

O cenário

Como ferramenta para a elaboração deste artigo, foi utilizada uma rede de microcomputadores contendo um host com a funcionalidade de gateway e os demais hosts para atuarem como clientes deste gateway.

O servidor proxy foi instalado no gateway com o objetivo de disponibilizar o acesso à internet mantendo certo nível de controle quanto aos conteúdos acessados.

As solicitações de acesso à internet feitas pelos clientes acontecem de forma controlada, e possíveis tentativas de acesso indevido aos recursos da rede são negadas e registradas em arquivos de log, objetivando a identificação do usuário.

Neste contexto, cabe aos administradores a definição das regras que serão aplicadas ao Squid, sejam eles profissionais ou educacionais, a fim de restringir determinados acessos, a exemplo de conteúdo pornográfico.

Para tanto, será utilizado um microcomputador com o sistema operacional FreeBSD, conforme a Figura 1, compilado com parâmetros do kernel, para atuar como gateway (na primeira edição da Infra Magazine foi mostrado como realizar esta compilação). Após este procedimento, o proxy Squid será instalado e configurado com algumas de suas funcionalidades básicas.

Para atuar como gateway e possivelmente como um proxy, um microcomputador bem modesto atenderá aos requisitos de hardware. Porém, é indicado o uso de um que o disco rígido esteja em bom estado, já que ele será altamente exigido pelo cache do proxy.

 

Figura 1. O cenário da rede.

 

O microcomputador usado no cenário foi um Intel(R) Atom(TM) CPU 330 @ 1.60GHz, 1GB de RAM, HD Maxtor 80GB, com duas placas de rede, sendo uma onboard e outra offboard: sis 900 e RT8139(A/B/C/810x/813x/C+) Fast Ethernet Adapter. A conexão com a internet é via cable modem, onde o provedor fornece o endereço IP automaticamente via DHCP (Dynamic Host Configuration Protocol).

Vale ressaltar que o tráfego das estações será direcionado ao gateway que, por sua vez, redirecionará, por meio do firewall IPFW (Firewall padrão do FreeBSD), todo o tráfego destinado à web pela porta padrão do Squid (3128), que aplicará suas regras – chamadas de ACL (Lista de Controle de Acesso).

A instalação

A versão do sistema operacional utilizada foi a FreeBSD 7.2-RELEASE i386 (veja a seção Links), e a versão do Squid foi a 2.6.STABLE23 (veja seção Links).

Neste exemplo, a instalação do proxy será a partir do código fonte do Squid, para que seja possível realizar os passos aqui descritos também em outras distribuições Linux, tais como Red Hat, Slackware, dentre outras, já que o processo de instalação e configuração é idêntico. Há administradores que optam por realizar a instalação através dos ports (/usr/ports), no entanto, ambas as formas levam a resultados idênticos.

Instalando o Squid

Após fazer o download do Squid em www.squid-cache.org/Versions/v2/2.6/, deve-se acessar o diretório onde foi salvo o arquivo referente a seu código fonte, por exemplo /home/dmedia/squid-2.6.STABLE23.tar.gz e descompactá-lo com o utilitário tar (tar -jxvf squid-2.6.STABLE23.tar.gz). Feito isso, será criado um diretório chamado squid-2.6.STABLE23.

Deve-se logar com o super usuário do sistema (su - ) e, em seguida, executa-se o script de configuração do Squid. Em função da grande quantidade de parâmetros e funcionalidades, este artigo mostrará os mais utilizados para um servidor proxy simples, porém funcional.

O script de pré-configuração do Squid chama-se configure. Através dele serão realizadas as configurações básicas de pré-instalação, como a localização do diretório raiz para instalação, tipo de sistema de arquivos que será reconhecido pelo Squid, dentre outras. Porém, algumas funções não estão disponíveis através do arquivo de configuração (squid.conf), a exemplo dos tipos de sistema de arquivos reconhecidos, que deverá ser informado neste ponto, através do script de configuração, da seguinte maneira:

 

./configure --prefix=/usr --exec-prefix=/usr --sbindir=/usr/sbin --sysconfdir=/etc --mandir=/usr/share/man --bindir=/usr/sbin --libexecdir=/usr/lib/squid --enable-snmp –enable-storeio=aufs,ufs,null --enable-auth=basic --enable-basic-auth-helpers=NCSA --enable-ident-lookups --with-large-files --enable-arp-acl

 

Quando executado, uma longa lista de arquivos e procedimentos de pré-compilação será exibida, estando inclusos nela a verificação de todos os requisitos necessários para o Squid funcionar com os parâmetros indicados. Então, para que sejam evitados problemas com dependência de arquivos, a instalação do FreeBSD foi feita no modo standard.

Conforme mostrado no comando “./configure...”, foi passada como parâmetro uma lista de informações de configuração, cuja sintaxe a ser seguida é a seguinte: variável=parâmetro, onde variável é uma palavra reservada do script de configuração do Squid, e parâmetro pode ser um caminho completo para um diretório ou o nome de um protocolo, assim como mostrado na Tabela 1, onde se tem uma breve explicação sobre cada parâmetro utilizado.

 

Parâmetro

Descrição

...