Configurando Um Proxy Squid

Instituto Federal de Ciência e Tecnologia do Tocantins

Campus Araguatins

CONFIGURANDO O PROXY SQUID

PROFESSOR: VILSON SOARES DE SIQUEIRA

DISCIPLINA: REDES II

2

Sumário 1. INSTALANDO E CONFIGURANDO O SQUID ................................................................................... 3

1.1 CONSIDERAÇÕES ........................................................................................................................ 3

1.2 CONCEITOS DE SERVIDORES PROXY .......................................................................................... 3

1.3 PROXY CACHING ........................................................................................................................ 3

1.4 NAT - TRADUÇÃO DE ENDEREÇOS DE REDE. ............................................................................. 4

1.5 DIFERENÇA ENTRE UM FILTRO DE PACOTES E UM SERVIDOR PROXY ...................................... 5

1.6 O SQUID ..................................................................................................................................... 6

1.7 REQUISITOS DE SISTEMA ESPECÍFICOS PARA O PROXY CACHING ............................................. 7

2. INSTALANDO O SQUID .................................................................................................................. 7

2.1 DEBIAN/UBUNTU ....................................................................................................................... 7

2.2 CONFIGURANDO O SQUID ......................................................................................................... 8

2.3 CACHE ........................................................................................................................................ 9

2.4 CONTROLE DE ACESSO ............................................................................................................. 10

2.5. ANEXO: ARQUIVO DE CONFIGURAÇÃO DO SQUID ................................................................. 14

3

1. INSTALANDO E CONFIGURANDO O SQUID

1.1 CONSIDERAÇÕES

Os testes para configuração e utilização foram realizados utilizando a distribuição

Debian Squeeze (versão 6.0);

1.2 CONCEITOS DE SERVIDORES PROXY

O objetivo principal de um servidor proxy é possibilitar que máquinas de uma rede privada

possam acessar uma rede pública, como a Internet, sem que para isto tenham uma ligação

direta com esta. O servidor proxy costuma ser instalado em uma máquina que tenha acesso

direto à Internet, sendo que as demais efetuam as solicitações através desta. Justamente por

isto este tipo de servidor é chamado de proxy, pois é um procurador, ou seja, sistema que

faz solicitações em nome dos outros.

Um servidor proxy para o protocolo http, por exemplo, pode ter outras funcionalidades

implementadas. Visto que todas as solicitações de páginas efetuadas pelas máquinas da rede

privada serão feitas através dele, é muito útil armazenar localmente as páginas que foram

solicitadas, permitindo que os próximos acessos, efetuados por quaisquer máquinas da rede,

possam ser otimizados. Este conceito é chamado de caching, e vários servidores proxy na

verdade são servidores proxy cache. Pelo mesmo motivo, também é possível implementar

uma funcionalidade que permita controlar o que os clientes podem acessar e em que

momento. Um servidor proxy também pode implementar o NAT (Network Address

Translation – Tradução de Endereços de Rede). O NAT é tecnicamente a função de um

portal de nível de rede, mas alguns fornecedores também incluem este recurso em seus

produtos e servidores proxy.

1.3 PROXY CACHING

Os servidores de proxy cache são implementados na camada de aplicativo e processam

protocolos Internet específicos, tais como http e FTP. São definidas regras no servidor proxy

para determinar como um pedido de estação de trabalho deve ser processado.

Uma das principais tarefas de um servidor proxy cache é armazenar temporariamente

páginas da Web e arquivos de FTP para clientes proxy. Esses tipos de servidores proxy são

chamados de servidores de cache proxy. O cache aumenta o desempenho da rede ao reduzir

a quantidade de dados que são transferidos de fora da rede local.

Para implementar o proxy caching, cada estação de trabalho da rede é configurada como um

cliente proxy para um determinado serviço. Por exemplo, um cliente proxy Web iria

configurar seu navegador (browser) para reconhecer o servidor proxy. Quando um cliente

fizer um pedido no navegador para baixar uma certa página, o navegador fará o pedido ao

servidor proxy. O servidor proxy contém armazenadas as páginas visitadas recentemente.

Este cache contém as páginas Web que as estações de trabalho em toda a rede baixaram

recentemente.

4

O servidor proxy verifica o seu cache para ver se a página está disponível. Se a página

estiver disponível no cache será enviada ao cliente a página armazenada. Se a página não

estiver no cache, o servidor proxy baixará do site em questão, armazenará essa página no seu

cache e a enviará à estação de trabalho.

Para garantir que as páginas no cache não estejam desatualizadas, os dados do cache proxy

expiram após um tempo pré-determinado. No squid, esta configuração é chamada de tempo

de renovação de objeto (som, vídeo, arquivos texto, etc... ).

Este processo aumenta o desempenho da rede porque a página é baixada imediatamente para

o cliente a partir do servidor proxy, evitando ter de baixá-la da Internet.

1.4 NAT - TRADUÇÃO DE ENDEREÇOS DE REDE.

Muitos servidores proxy são distribuídos com a função de NAT. O NAT permite que o

endereço de rede interno de uma empresa seja ocultado da Internet. A empresa é

representada na Internet como um endereço de IP não relacionado com os endereços de IP

internos.

Utilizando um servidor proxy, todo o tráfego de dentro da empresa destinado à Internet é

enviado para o servidor proxy. O proxy dá para cada pacote um outro endereço de IP antes

transmiti-lo pela Internet. Quando o pacote de resposta chega, o servidor proxy o envia ao

servidor apropriado da empresa que havia feito o pedido. Este procedimento protege os

endereços verdadeiros da rede interna da Internet, dificultando o ataque de um cracker ao

sistema, já que o endereço do sistema protegido não é conhecido e não fica diretamente

acessível a partir da Internet.

Navegador da estação de

trabalho

Servidor Proxy

Pedido de página de Internet

Tem um página de Internet no

cache ?

SIM Enviar página de internet para a estação de trabalho.

Carregar página de Internet do cache

NÃO

5

1.5 DIFERENÇA ENTRE UM FILTRO DE PACOTES E UM SERVIDOR PROXY

Os 2 serviços são colocados no perímetro da rede. Ambos funcionam como um

intermediário entre uma LAN e a Internet. Ambos possuem a capacidade de filtrar o tráfego

transmitido para dentro e para fora da rede. Ambos utilizam regras para determinar se certos

tipos de tráfego terão autorização para passar pelo servidor ou se serão descartados.

O que acontece é que o filtro de pacotes não penetra tão fundo no pacote como o servidor

proxy. O filtro de pacotes analisa o tráfego nas camadas de rede (camada 3) e de transporte

(camada 4) do modelo OSI. Por exemplo, um filtro de pacotes determinará se autoriza a

passagem de um endereço ou de uma certa faixa de endereços IP. Se a sua rede é atacada a

partir de uma faixa constante de endereços de IP, você pode criar uma regra para descartar

todos os pacotes que se originarem dessa faixa. Você pode filtrar o tráfego por serviço ou

número de porta (por exemplo), criando uma regra que descarte todo o tráfego direcionado a

certas portas de escuta, tais como FTP, rlogin e tráfego Telnet, ou dentro de uma faixa de

números de portas. Você pode filtrar pacotes ICMP por tipo ou código, o que permite

descartar somente certos tipos de tráfego ICMP. Isto ajuda na sua proteção contra ataques

comuns de denial-of-service distribuídos (DDOS). Como os filtros de pacotes trabalham

nessas camadas, são muitas vezes implementados em roteadores no perímetro da rede.

O servidor proxy é capaz de analisar pacotes na camada de aplicativo (camada 7). Isto

oferece uma flexibilidade muito maior, porque permite que o tráfego dentro de um serviço,

como o tráfego da porta 80 (http) possa ser filtrado. Como mencionado anteriormente, isto

permite que os servidores proxy analisem o tráfego http ou FTP, e determinem se deve ou

não passar. Se houver uma regra que impeça a passagem de qualquer endereço WEB que

contiver a palavra “sexo”, então qualquer pedido de URL http que contiver “sexo” será

descartado.

Ethernet da empresa

176.168.11.25

176.168.11.35 176.168.11.45

Servidor proxy com NAT

INTERNET

200.130.10.205 176.168.11.78

Todos os servidores da empresa são representados na na Internet pelo

servidor proxy 200.130.10.205

6

1.6 O SQUID

O servidor Squid Web Proxy Cache é gratuito e funciona em código aberto para Unix e

Linux. Ele permite que os administradores implementem um serviço de proxy caching para

Web, acrescentem controles de acesso (regras), e armazenem até mesmo consultas de DNS.

O Squid originou-se de um programa desenvolvido pelo projeto Harvest chamado cached

(Cache Daemon). A National Science Foundation (NSF) financia o desenvolvimento do

Squid através do National Laboratory of Network Research (NLANR).

O Squid é um Web proxy cache que atende à especificação HTTP 1.1. É utilizado somente

por clientes proxy, tais como navegadores Web que acessem à Internet utilizando HTTP,

Gopher e FTP. Além disso, ele não trabalha com a maioria dos protocolos Internet. Isto

significa que ele não pode ser utilizado com protocolos que suportem aplicativos como

vídeo-conferência, newsgroups, RealAudio, ou videogames como o Quake ou Counter

Strike. O principal motivo destas limitações é que o Squid não é compatível com programas

que utilizem UDP. O Squid usa o UDP somente para comunicação inter-cache.

Qualquer protocolo de cliente suportado pelo Squid deve ser enviado como um pedido de

proxy no formato HTTP. A maioria dos navegadores suporta esta função, portanto, os

protocolos FTP, HTTP, SSL (Secure Socket Layer), WAIS (Wide Area Information Server)

são suportados na maioria das redes que utilizam o Squid.

Os protocolos funcionarão se você os solicitar utilizando o seu navegador e se ele estiver

configurado como um cliente proxy para o servidor Web proxy cache.

O Squid também suporta protocolos internos e de administração. Tais protocolos são usados

entre os caches que puderem existir em outros no mesmo ou em outros servidores de proxy-

caching, ou para a administração de um proxy cache.

Internet Cache Protocol (ICP) – Consulta outros caches sobre um determinado objeto;

Cache Digest – Obtém um índice de objetos de outros caches;

HTTP – Obtém os objetos de outros caches;

Hypertext Caching Protocol (HTCP) – Está sendo incluído no Squid;

Ethernet da empresa

Workstation

Workstation Workstation

Cache do servidor de proxy web

INTERNET

Filtro de pacotes baseado em endereço de IP, faixa de endereço de IP e faixa e

número de porta TCP/UDP.

Tráfego de HTTP e FTP, outras URL’s e pesquisa DNS. Também filtros de URL’s

baseados em conteúdo.

7

Simple Network Management Protocol (SNMP) – Obtém informações sobre o proxy e as

envia a uma Network Management Station (NMS) para análise.

1.7 REQUISITOS DE SISTEMA ESPECÍFICOS PARA O PROXY CACHING

O Squid utiliza mais recursos de sistema do que outros aplicativos. Os dois principais

subsistemas de hardware que o Squid utiliza e deve ter um bom desempenho é o tempo de

busca aleatória e a quantidade de memória no sistema.

Tempo de busca aleatória em disco – Para um proxy cache, o tempo de busca aleatória

deve ser o mais baixo possível. O problema é que os sistemas operacionais procuram

aumentar a velocidade de acesso em disco utilizando vários métodos que geralmente

reduzem o desempenho do sistema;

Quantidade de memória do sistema – A memória RAM é extremamente importante para a

utilização de um proxy cache. O Squid mantém uma tabela na memória RAM sobre os seus

objetos. Se uma parte dessa tabela tiver que sofrer swapping, o desempenho do Squid será

bastante degradado. O Squid é um processo, então qualquer swapping tornará o programa

mais lento. Por exemplo, se você tiver 16 GB armazenados no cache, precisará de 96 MB

(aproximadamente) de RAM para o indíce de objetos.

Outros requisitos do sistema, como velocidade de CPU, não são tão importantes assim. A

velocidade do processador somente será notado durante o início do sistema (durante a

criação do indíce de objetos). Um sistema multiprocessado não constuma fazer diferença no

desempenho do proxy cache, pois o Squid contém uma pequena porção de código

encadeado.

2. INSTALANDO O SQUID

2.1 DEBIAN/UBUNTU

root@server:/home/vilson#

# apt-get install squid

Ubuntu

Após a instalação, altere o dono e grupo do arquivo "swap.state", senão irá encontrar

problemas mais para frente:


# chown proxy:proxy /var/spool/squid/swap.state

Fedora/CentOS


# yum install squid

8

Após a instalação, coloque o Squid para iniciar durante o boot:


# chkconfig squid on

Slackware

Baixe o pacote do Squid, suas dependências e instale:

http://repository.slacky.eu/slackware(...)/squid-3.0.stable18-i486-1sl.tgz

ftp://ftp.slackware-brasil.com.br/slackware(...)/d/gcc-4.2.4-i486-1.tgz

ftp://ftp.slackware-brasil.com.br/slackware(...)/d/gcc-g++-4.2.4-i486-1.tgz


# installpkg gcc-4.2.4-i486-1.tgz

# installpkg gcc-g++-4.2.4-i486-1.tgz

# installpkg squid-3.0.stable18-i486-1sl.tgz

Após a instalação, coloque o Squid para iniciar durante o boot:


# chmod +x /etc/rc.d/rc.squid

# ln -s /etc/rc.d/rc.squid /etc/rc.d/rc0.d/K05squid




# ln -s /etc/rc.d/rc.squid /etc/rc.d/rc3.d/S95squid



2.2 CONFIGURANDO O SQUID

O arquivo de configuração do Squid se encontra no seguinte caminho:

Debian/Ubuntu: "/etc/squid/squid.conf"

Fedora/CentOS: "/etc/squid/squid.conf"

Slackware: "/etc/squid/squid.conf"

Para começar com a configuração do zero, renomeie o arquivo de configuração padrão, crie

um novo arquivo com o nome "squid.conf" e adicione as seguintes configurações:

http_port 3128

visible_hostname servidor

cache_mgr webmaster@localhost

http://repository.slacky.eu/slackware-12.2/network/squid/3.0.STABLE18/squid-3.0.stable18-i486-1sl.tgz

ftp://ftp.slackware-brasil.com.br/slackware-12.2/slackware/d/gcc-4.2.4-i486-1.tgz

ftp://ftp.slackware-brasil.com.br/slackware-12.2/slackware/d/gcc-g++-4.2.4-i486-1.tgz

9

http_port: determina a porta que será usada pelo servidor.

visible_hostname: defina o nome de exibição do servidor.

cache_mgr: defina o e-mail do administrador para receber mensagem em

casos graves.

Para definir o idioma das páginas de mensagem de erros em português brasileiro, adicione a

seguinte configuração:

Debian/Ubuntu

error_directory /usr/share/squid/errors/Portuguese

Fedora/CentOS

error_directory /usr/share/squid/errors/pt-br

Slackware

error_directory /usr/share/squid/errors/Portuguese

2.3 CACHE

O cache é onde fica armazenado os objetos (arquivos e páginas) quando acessa as páginas

ou baixar arquivos pela Internet. Ao invés de toda vez que um usuário for acessar um site e

ter que esperar baixar a página toda e os arquivos direto da hospedagem, o servidor verifica

se já existe no cache podendo baixar direto do servidor, melhorando o desempenho na

navegação.

Para configurar o cache no Squid, adicione as seguintes configurações:

hierarchy_stoplist cgi-bin ?

cache_mem 32 MB

maximum_object_size_in_memory 64 KB

maximum_object_size 100 MB

hierarchy_stoplist: defina palavras que se for encontradas na url, a página

irá ser carregada direto do cache.

cache_mem: defina a quantidade de memória que o servidor irá usar para o

cache.

maximum_object_size_in_memory: defina o tamanho máximo do objeto

que poderá ser armazenado na memória, senão será armazenado no disco

rígido.

maximum_object_size: defina o tamanho máximo do objeto que poderá ser

armazenado no disco rígido, senão será descartado o objeto.

Para especificar o diretório do cache, aonde será armazenado os objetos e atribuir 2GB de

espaço de armazenamento no cache, adicione a seguinte configuração:

Debian/Ubuntu

cache_dir ufs /var/spool/squid 2048 16 256

10

Fedora/CentOS


Slackware

cache_dir ufs /var/log/squid/cache 2048 16 256

Agora vamos definir o tempo de vida dos objetos no cache, para que sempre o Squid for

verificá-los, saber se é necessário atualizá-los ou não.

refresh_pattern ^ftp: 360 20% 10080

refresh_pattern -i (/cgi-bin/|\?) 0 0% 0

refresh_pattern . 0 20% 4320

1ª coluna: defina o tempo em minutos, em cada acesso, quando deve

verificar se houve modificação no objeto.

2ª coluna: defina a porcentagem mínima da modificação do objeto que deve

ter para ser atualizado.

3ª coluna: defina o tempo em minutos, quando deve efetuar uma atualização

mesmo não ter sido modificado.

Para especificar o caminho do Log de acesso do Squid e o caminho do Log do cache,

adicione a seguinte configuração:

Debian/Ubuntu

access_log /var/log/squid/access.log

cache_log /var/log/squid/cache.log

Fedora/CentOS

access_log /var/log/squid/access.log

cache_log /var/log/squid/cache.log

Slackware

access_log /var/log/squid/logs/access.log

cache_log /var/log/squid/logs/cache.log

2.4 CONTROLE DE ACESSO

A ACL ou Lista de Controle de Acesso, é onde define aonde pode acessar ou não pela

Internet. Uma coisa importante que deve saber é que o Squid interpreta as ACL's de cima

para baixo, então deve ficar atento quando for criar as regras.

Crie duas acl com o tipo src (IP de origem) e adicione o IP do servidor e o IP da rede:

acl localhost src 127.0.0.1/32

acl localnet src 192.168.0.0/24

11

Crie uma acl com o tipo proto (protocolo) e adicione o protocolo "cache_object":

acl manager proto cache_object

O protocolo "cache_object" é usado para obter informações sobre o estado do Squid.

É recomendável que permita apenas o servidor obter as informações do Squid, então

adicione a seguinte regra:

http_access allow manager localhost

http_access deny manager

Crie uma acl do tipo method (método de requisição) e adicione o método PURGE:

acl purge method PURGE

O método de requisição PURGE serve para limpar/excluir objetos armazenados no cache.

Para permitir que apenas o servidor possa exclua objetos, adicione a seguinte regra:

http_access allow purge localhost

http_access deny purge

Crie uma acl do tipo port (porta) e adicione as portas que serão liberadas:

acl Safe_ports port 21 70 80 210 280 443 488 563 591 631 777 873 901 1025-65535

Se quiser deixar mais organizado, ou seja, adicionar uma porta de cada vez para poder

comentar em cada linha a descrição do protocolo da porta que está sendo liberada, também

pode deixando assim:

acl Safe_ports port 21 # ftp

acl Safe_ports port 70 # gopher

acl Safe_ports port 80 # http

acl Safe_ports port 210 # wais

acl Safe_ports port 280 # http-mgmt

acl Safe_ports port 443 # https

acl Safe_ports port 488 # gss-http

acl Safe_ports port 563 # nntps

acl Safe_ports port 591 # filemaker

acl Safe_ports port 631 # cups

acl Safe_ports port 777 # multiling http

acl Safe_ports port 873 # rsync

acl Safe_ports port 901 # swat

acl Safe_ports port 1025-65535 # unregistered ports

12

Para bloquear o acesso em portas que não foram liberadas, adicione a seguinte regra:

http_access deny !Safe_ports

Crie uma acl do tipo method (método de requisição) e adicione o método CONNECT, que

permite fazer conexão direta:

acl connect method CONNECT

Crie uma acl do tipo port (porta) e adicione as portas dos protocolos com SSL que foram

adicionadas na acl "Safe_ports" e devem ser liberadas para conexão direta:

acl SSL_ports port 443 # https

acl SSL_ports port 563 # nntps

acl SSL_ports port 873 # rsync

Para bloquear o acesso em portas que não foram liberadas para conexão direta, adicione a

seguinte regra:

http_access deny connect !SSL_ports

Crie uma acl do tipo dstdomain (domínio de destino) e adicione um dóminio iniciando com

o ponto:

acl domains dstdomain .twitter.com

Se no caso for vários domínios de destino, define o caminho do arquivo que será adicionado

os domínios:

acl domains dstdomain "/etc/squid/domains"

Crie o arquivo que foi definido na acl e adicione os domínios de destino:

.twitter.com

.youtube.com

.vimeo.com

Para bloquear o acesso nos domínios de destino, adicione a seguinte regra:

http_access deny domains

Crie uma acl do tipo url_regex (expressão regular na url) e adicione uma expressão regular:

acl words url_regex jogo

13

A acl do tipo url_regex percorre url em busca de expressões regulares. A acl é case-

sensitive, se no caso estiver procurando a expressão "jogo" e tiver "Jogo", serão

consideradas diferentes.

Para adicionar várias expressões, define o caminho do arquivo que será adicionado as

expressões. E use a opção "-i" para tornar a acl em case-insensitive:

acl words url_regex -i "/etc/squid/words"

Crie o arquivo que foi definido na acl e adicione as expressões regulares:

jogo

blog

msn

Para bloquear o acesso em urls com as expressões regulares, adicione a seguinte regra:

http_access deny words

Criar uma acl do tipo urlpath_regex (expressão regulares no caminho da url) e define o

caminho do arquivo que será adicionado as expressões regulares:

acl extensions urlpath_regex -i "/etc/squid/extensions"

A acl do tipo urlpath_regex é semelhante a url_regex, só que é ignorado o domínio e

protocolo. Por exemplo, essa url "http://www.dominio.com.br/blog/invasao.html", irá fazer

a busca da expressão regular apenas nessa parte "/blog/invasao.html":

Crie o arquivo que foi definido na acl e adicione as expressões regulares:

\.bat($|\?|\&)

\.exe($|\?|\&)

\.scr($|\?|\&)

Para bloquear o acesso em urls path com expressões regulares, adicione a seguinte regra:

http_access deny extensions

Sem mais acl para criar, adicione a seguinte regra para permitir que apenas as máquinas da

rede e o servidor sejam liberados para acessar a Internet:

http_access allow localnet

http_access allow localhost

http_access deny all

14

Com as acl definidas, a sequência das regras deverão está na ordenação correta,

independente esteja a acl junto com a regra. O que importa é que esteja criada a acl antes de

definir a regra.

Aqui vai uma amostra de como deve está ordenado as 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 deny domains

http_access deny words

http_access deny extensions

http_access allow localnet



Debian/Ubuntu

Após ter terminado as configurações, reinicie o servidor Squid:


# /etc/init.d/squid restart

Fedora/CentOS

Após ter terminado as configurações, inicie o servidor Squid:


# service squid start

Slackware

Após ter terminado as configurações, inicie o servidor Squid:


# /etc/rc.d/rc.squid start

2.5. ANEXO: ARQUIVO DE CONFIGURAÇÃO DO SQUID

Renomeia o arquivo original do squid que é squid.conf para squid.conf.bck e crie um novo

arquivo com o none: squid.conf com os dados que estão abaixo:

15

Arquivo de configuração do SQUID( squid.conf) que está dentro da pasta

/etc/squid/squid.conf

#######CONFIGURAÇÕES INICIAIS ##############################

# porta padrão do squid - http_port 3128

http_port 3128

# Nome do servidor squid

visible_hostname server

# Diretório onde serão armazenados os erros

error_directory /usr/share/squid/errors/pt-br

# Armazenamento na memória RAM do servidor squid

cache_mem 64 mb

# Limite de tamanho máximo do objeto na RAM

maximum_object_size_in_memory 2 mb

# Menor arquivo armazenado em RAM

minimum_object_size 3 kb

# Limite para o início da exclusão do cache

cache_swap_low 90

cache_swap_high 95

# Diretório onde serão armazenadas as páginas web navagadas na rede

local


cache_access_log /cache/squid/access.log

##############INICIANDO AS ACL ############################

# Liberar ou negar acesso para todas as faixas de IP

acl all src 0.0.0.0/0.0.0.0

# Limitar acesso a somente o servidor squid em questão

acl localhost src 127.0.0.1/255.255.255.255

# Define a faixa de IP da rede local

acl redelocal src 192.168.3.0/24

############PERMITINDO E NEGANDO ACESSO NA ACL ############


http_access allow redelocal


done

Configurando Um Proxy Squid

Documents

Transcript of Configurando Um Proxy Squid