INTRODUÇÃO E CONFIGURAÇÕES
MOTIVAÇÃO
Há pouco tempo, precisei realizar a implantação de um proxy Squid transparente, que realizasse a filtragem da navegação em HTTP (80) e navegação segura – SSL (443).
Ao procurar literatura especializada, verifiquei um grande quantitativo de documentação para esta implementação do Squid, mas também observei que para a navegação segura (SSL- 443), os artigos e fontes de pesquisa, praticamente não existiam.
Neste artigo, demonstro o passo a passo para a criação de certificados e chaves que serão utilizados no Squid, recompilação do Squid com suporte a SSL (em um Debian Squeeze) e implementação do redirecionamento de portas para direcionar o tráfego de HTPS e HTTP, para o Squid.
OPENSSL – CRIANDO CERTIFICADOS E CHAVES PARA O SQUID
Para a criação do certificado e geração da chave pública e chave privada, utilizaremos os comandos abaixo:
# openssl genrsa -des3 -out empresa. Key 1024
# openssl req -new –key -out empresa.csr
# openssl req -new -key server. Key -out server.csr
Após a criação das chaves, temos que remover a senha da chave:
# cp empresa. Key empresa. Key.old
# openssl rsa -in empresa. Key.old -out empresa. Key
Criar certificado da empresa:
# openssl x509 -req -days 365 -in empresa.csr -sign.key -out empresa.crt
Ao fim, copiaremos a chave e o certificado para pasta onde o Squid realizará a leitura:
# cp empresa. Key /etc/squid/certificados/
# cp empresa. csr /etc/squid/certificados/
Obs.: A pasta “certificados” é opcional, e a criação foi meramente para efeito de organização.
RECOMPILANDO O SQUID COM SUPORTE A CONEXÕES SSL
Primeiro, devemos adicionar os repositórios abaixo na sources.list do seu Debian Squeeze, editando o arquivo: /etc/apt/sources.list:
deb-src http://backports.debian.org/debian-backports squeeze-backports main contrib non-free
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free
Depois, execute o comando:
# apt-get update
Para atualizar a base de dados do APT, com base nos novos repositórios.
PROCESSO DE RECOMPILAÇÃO DO SQUID
Entre no diretório /usr/src:
# cd /usr/src
Baixe os fontes do Squid:
# apt-get source squid
Baixe as dependências de compilação do Squid:
# apt-get build-dep squid
Baixe as dependências de compilação do OpenSSL:
# apt-get build-dep openssl
Baixe e instale dependências necessárias para o recompilação:
# apt-get install devscripts build-essential fakeroot
Entre no diretório dos fontes:
# cd squid-<versão>
# cd debian/
Acesse o arquivo “rules”, e adicione a linha de opção:
…No arquivo, para recompilarmos o Squid com suporte a SSL:
# vim rules
Configure a nova opção (não execute o make, ou make install):
# ./configure
Compile e gere os pacotes para instalação:
# debuild -us -uc -b
Instale os dois pacotes gerados:
# dpkg –i squid-(versão).deb squid-comon-(versão).deb
CONFIGURAÇÃO DO SQUID.CONF PARA SUPORTE À SSL + PROXY TRANSPARENTE
O intuito do arquivo é adicionar a funcionalidade de SSL proxy ao Squid, e neste, já pressuponho que seu Squid esteja funcional, sendo que adicionaremos apenas as novas funcionalidades.
No “squid.conf”, adicione as linhas para ativar o funcionamento da filtragem do HTTP e HTTPS no proxy:
https_port 3129 transparent cert=/etc/squid/certificados/empresa.crt Key=/etc/squid/certificados/empresa.key
Obs.: Verifique que a adição da linha que faz referência à “HTTPS_PORT”, é o momento que incorporamos a funcionalidade de suporte a SSL ao Squid. Assim, para o funcionamento pleno como argumentos, indicamos onde está localizado o certificado e a chave da empresa.
IPTABLES – REDIRECIONANDO OS PACOTES HTTP E HTTPS PARA O SQUID
Adicione ao seu firewall, o redirecionamento de portas de acesso 80 (http – navegação) e 443 (https- navegação segura):
Obs.: eth0 – Interface de LAN
# iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 443 -j REDIRECT –to-port 3129
CONCLUSÃO
A utilização de filtragem da navegação segura é muito importante, e por desconhecimento, ou até mesmo por falta de literatura que indique os meios para esta implementação, muitos administradores de rede continuam a utilizar o NAT para estes acessos, de forma a não aproveitarem toda a potencialidade do seu proxy.
Espero que este artigo contribua para toda comunidade do VOL, na busca por uma literatura mais coesa e direta sobre este assunto.