LPI-2 202-450 Topico 208.3
Implementação do servidor proxy Squid

Índice

208.3 Implementação do Squid como um servidor proxy - Objetivos
208.3 Implementação do Squid como um servidor proxy - Conteúdo
- O que é um servidor proxy
- O que é o Squid
  - Configuração do Squid

208.3 Implementação do Squid como um servidor proxy - Objetivos

Peso 2

O candidato deve ser capaz de instalar e configurar um servidor de proxy, incluindo políticas de acesso, autenticação e consumo de recursos. Conhecimentos-chave:

Arquivos de configuração, termos e ferramentas do Squid 3.x;
Métodos de restrição de acesso;
Métodos de autenticação de usuários;
Formato e conteúdo de ACL nos arquivos de configuração do squid.

Lista parcial dos arquivos, termos e ferramentas utilizados:

squid.conf;
acl;
http_access

208.3 Implementação do Squid como um servidor proxy - Conteúdo

O Squid é o serviço web proxy mais importante na família de servidores Linux e semelhantes, conta com inúmeros recursos porém nesse conteúdo vamos focar apenas nos objetivos propostos para o exame LPI 202-450.

O que é um servidor proxy

Um servidor proxy atua como um intermediário entre um computador cliente e um servidor. Há vários motivos para o uso de um proxy:

Para compartilhar Internet em uma LAN;
Para melhorar a velocidade de Internet;
Para mascarar endereços de IP dos computadores na LAN;
Para implementar controles de navegação;
Para auditar o conteúdo dos usuários da LAN;
Para restringir acesso a determinados endereços.

Obviamente vários desses motivos se encaixam em ambientes comerciais. Saber implementar um servidor proxy é uma habilidade importante para um administrador de rede.

O que é o Squid

Squid é um serviço de web proxy cheio de recursos e de código livre, lançado sob a GPL 3. Pode ser usado como um serviço de cache web para melhorar a velocidade de navegação, cache de resolução de nomes DNS, filtrar o conteúdo que está sendo acessado pelos usuários da LAN. Suporta fazer cache dos protocolos HTTP e FTP.

A instalação do squid é bastante trivial, geralmente usa-se o gerenciador de pacotes da distribuição em questão, dificilmente se compila dos fontes, pois devido a popularidade do squid geralmente a versão que constará nos repositórios será uma versão atual e estável.

Configuração do Squid

A configuração do squid também é muito parecida indiferente da distribuição e seu arquivo de configurações costuma estar em /etc/squid/squid.conf ou em /etc/squid3/squid.conf.

O arquivo contém as diretivas necessárias ao funcionamento do serviço, segue uma lista básica:

http_port: Define a porta utilizada pelo Squid. A porta padrão é a 3128;
cache_mem: Define quanto de memória será utilizado pelo cache. O padrão é 256MB;
maximun_object_size_in_memory: Objetos maiores do que o valor dessa diretiva não serão mantidos em memória;
cache_dir [formato] [local] [tamanho] L1 L2: Essa diretiva define o cache em disco, por padrão ela não é ativa, portanto para ativar o cache em disco essa linha no arquivo de configuração padrão do pacote deve ser descomentada e parametrizada, [formato] remete ao tipo de armazenamento usado (o padrão atual é aufs) L1 é a quantidade de subdiretórios que serão criados no subdiretório definido em [local] e L2 é a quantidade de subdiretórios que serão criados dentro de L1;
maximum_object_size: Tamanho máximo dos objetos no cache em disco, o padrão é 4MB;
cache_mgr: O Email do administrador do proxy;
cache_effective_use: O usuário sob o qual o daemon squid será executado. Importante o squid não deve ser rodado sob o usuário root;
cache_effective_group: O grupo sob o qual o daemon squid será executado.

Após do arquivo squid.conf corretamente parametrizado, podemos testar o arquivo com o comando squid -k check se não houver alertas de erro podemos iniciar o daemon com o comando systemctl start squid.

O comando squid também pode ser reiniciado de forma "suave" utilizando o comando squid -k reconfigure.

Access Control Lists ACLs ou Listas de Controle de Acesso

As ACLs são as definições das regras de acesso. No Squid elas são muito flexíveis permitindo vários ajustes como permitir acessos em dias e horários específicos, domínios de origem, domínios de destino e muito mais.

O esquema das ACLs no Squid é composto por dois componentes:

As ACLs são declaradas no Squid por linhas iniciadas pela diretiva acl e representam tipos de dados, seguem a sintaxe:

acl [NOME] [TIPO] [CONTEUDO]

Nome: é o nome da ACL pela qual a referenciaremos posteriormente no arquivo de configuração;
Tipo: existem vários tipos que podem ser usados, como porta, endereço de origem, endereço de destino e aí por diante.

Exemplo:

Listagem 1: Exemplo de ACLs

acl Safe_ports port 80
# É possível colocar mais de um elemento no conteúdo de uma mesma ACL
# basta separar os elementos por espaços
acl SSL_ports port 443 8443
# --- ACL que ativa o SNMP
acl snmpPADRAO snmp_community squid-snmp-test-community
# --- Especifica metodos de conectividade
acl http proto http
acl CONNECT method CONNECT
# --- Streaming geral
acl streaming req_mime_type ^video/x-ms-asf
# --- ACL baseada em regex de URL
acl whitelist url_regex .autodesk.com
acl whitelist url_regex time.akamai.com
# --- ACLs tambem podem carregar seu conteudo de arquivos
acl web_skype url_regex "/var/lib/squidguard/db/grupos/web_skype"

Regras de ACLs as regras são baseadas nas ACLs que criamos acima e são usadas para indicar qual ação ou limitação será aplicada mediante uma requisição de um client.

Listagem 2: Exemplo de regras baseadas em ACLs

# --- Libera whitelist
http_access allow http whitelist
http_access allow CONNECT whitelist
# --- Nao libera portas diferentes de Safe_ports e SSL_ports, no caso o "!" 
# --- representa uma lista negada, portanto a regra deve ser lida como
# --- "bloqueie todas as portas exceto as da lista"
http_access deny !Safe_ports
http_access deny CONNECT !Safe_ports
http_access deny CONNECT !SSL_ports
# --- Libera Skype
http_access allow Skype_80
http_access allow CONNECT Skype_80 
http_access allow Skype_443
http_access allow CONNECT Skype_443

Notas:
1. Um regra baseada em ACL consiste em uma liberação (allow) ou uma negação (deny), seguida por um nome de ACL;
2. As regras baseadas em ACL são lidas de cima para baixo. Dando match na primeira ocorrência que casar;
3. Se uma regra contiver múltiplos elementos de ACL o Squid usara a lógica AND. Em outras palavras, todas as ACLs constantes na regra precisam casar para a regra ter efeito;
4. Os elementos dentro da regra não tem uma hordem correta de interpretação portanto em uma regra como:
  
  http_access allow sales_net sales_time
  
  Os hosts existentes na ACL sales_net só poderão acessar a Internet nos hários definidos na ACL sales_time a ordem dessas ACLs dentro da regra não importa;
5. Se nenhuma regra casar a que será aplicada será o oposto da última regra na sua lista de regras. Portanto é uma boa ideia criar uma regra de ação Default, no caso liberando ou bloqueando todo o tráfego que não casar com as listas anteriores.
  
  Exemplo de regra de fim de lista (bloqueando tudo que não casar): http_access deny all

Autenticação de usuários no Squid

Um dos recursos mais populares do Squid em ambientes empresariais é a autenticação de usuários, ela permite a aplicação de regras mediante a quem está logado no proxy.

A diretiva responsável pela autenticação é a auth_param é uma diretiva bastante complexa que suporta vários esquemas de autenticação, podemos citar: basic, digest, NTLM. O tipo basic é a mais comum e é a que iremos abordar para os objetivos do exame LPIC2, mesmo assim segue uma tabela contendo alguns tipos de autenticação possíveis:

Tipo	Descrição
NCSA	Utiliza o formato NCSA semelhante ao `htpasswd`
LDAP	Utiliza o Lightwight Directory Access Protocol
MSNT	Utiliza o domínio Windows NT
PAM	Utiliza o Linux Pluggable Authentication Modules
SMB	Utiliza um servidor SMB como Windows NT ou Samba
getpwam	Utiliza o antigo formato de senhas do Linux
SASL	Utiliza as bibliotecas SALS
NTLM	Negotiate and Digest authentication

Sintaxe: auth_param basic program /opt/squid/ncsa /etc/squid/passwd

Assim basic indica o tipo de autenticação. O próximo item program indica qual é a localização do programa (helper) utilizado na autenticação e o último elemento /etc/squid/passwd é o arquivo necessário ao programa ncsa.

No caso o programa ncsa é o método de autenticação mais simples possível. No caso ele segue o padrão do htpasswd

Listagem 3: Fragmento do squid.conf relativo a autenticação NCSA

# --- Indica o tipo de autenticação usado, qual helper e a
# --- localização do arquivo de senhas
auth_param basic program /usr/lib64/squid/basic_ncsa_auth /etc/squid/passwords

# --- O número de processos filhos de autenticação a subir
auth_param basic children 5

# --- Texto que será mostrado no popup de autenticação
auth_param basic realm "Autentique-se para navegar na Internet"

# --- Especifica o tempo de vida útil de uma única autenticação
# --- Após esse período o usuário precisará se autenticar novamente
auth_param basic credentialsttl 2 hours


# --- ACL relativa a autenticação
acl BASICAUTHENTICATED proxy_auth REQUIRED

# --- Regra de ACL permitindo usuários autenticados
http_access allow BASICAUTHENTICATED

Agora cria-se o arquivo de autenticação que mencionamos acima:

htpasswd -c /etc/squid/passwords user1

Esse arquivo pode ser testado com o próprio programa que utilizamos para a autenticação:

Listagem 4: Teste do arquivo de autenticação

$ /usr/lib64/squid/basic_ncsa_auth /etc/squid/passwords
user1 *****
OK

LOGs

Os LOGs do squid ficam em /var/log/squid/. Eles mantém informações sobre a carga do sistema e a performance e também os registros de acessos. Por padrão são esperados 3 arquivos de LOGs:

/var/log/squid/access.log: Este arquivo contém o registro de acessos no LOG;
/var/log/squid/cache.log: Este arquivo contém informações de debug;
/var/log/squid/store.log: Este arquivo é sobre os objetos mantidos ou removidos do cache de disco, também muito utilizado para debug.

LPI-2 202-450 Topico 208.3 Implementação do servidor proxy Squid