Proxy Squid - 2

Arquivo de configuração do Squid

O arquivo de configuração do squid é o squid.conf, normalmente ele se encontra em /etc/squid.conf ou em /usr/local/squid/etc/squid.conf. Caso não encontre o seu em nenhum desses lugares, procure-o com:

  # locate squid.conf 
  
     ou
  
  # find squid.conf 

Pode parecer fútil, mas uma limpeza inicial no arquivo squid.conf pode ser bem útil. O arquivo de configuração original tem, em média, 2000 linhas.

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

Entre várias opções de configurações do Squid, algumas merecem atenção especial, pois definem o funcionamento básico do programa.

http_port n - esta opção é utilizada para definir em quais portas (n) o squid espera por conexões http. A porta padrão é 3128, mas é possível especificar uma outra qualquer, dependendo da necessidade.

Exemplo: http_port 3128

cache_dir Tipo diretório Mbytes Nível-1 Nível-2 - esta opção serve para definir em quais diretórios serão armazenados os objetos. Tipo especifica o tipo de sistema de armazenamento a ser utilizado. Atualmente o tipo que pode ser utilizado com segurança é ufs.

Diretório especifica o nome do diretório onde há o arquivo que mantém os metadados dos objetos armazenados no disco. Este arquivo é utilizado para recriar o cache durante a inicialização do Squid. Mbytes especifica a quantidade de espaço em disco que deverá ser utilizada sob este diretório.

O valor padrão é 100 MB. Nível-1 e Nível-2 especificam o número de diretórios de primeiro e segundo nível, respectivamente, a serem criados, definindo na opção Diretório. Os valores padrão são 16 e 256, respectivamente. É possível ter vários diretórios para cache, inclusive em discos distindos.

Exemplo: cache_dir ufs /var/spool/squid 100 16 256

cache_mgr e-mail - esta opção permite especificar o e-mail do usuário do sistema que receberá uma mensagem caso o Squid venha a ser encerrado de forma anormal. Este endereço também é mostrado em páginas de erros retornadas aos usuários caso, por exemplo, a máquina remota não possa ser acessada.

Exemplo: cache_mgr Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo.

cache_efective_user usuarop, cache_efective_group grupo - estas opções servem para informar ao Squid com qual ID de usuário e de grupo, respectivamente, ele deve ser executado, caso seja iniciado como root, que é como ele costuma ser iniciado.

Exemplo:

cache_efective_user squid

cache_efective_group squid

cache_mem mem - o Squid utiliza muita memória por razões de desempenho. É muito mais demorado ler algo do disco do que diretamente da memória como todos sabem. Mas deve-se estar atento ao definir este valor, pois esse parâmetro não é o total de memória que o Squid usa, ele apenas põe um limite em um dos aspectos da memória. Mas ele usa memória para outras atividades, assim, é necessário reservar espaços para os outros processos.

Para verificar quanta memória o squid esta utilizando, podemos utilizar o comando top, por exemplo.

Exemplo: cache_mem 8MB

visible_hostname computador - esta opção define o nome do computador que aparece em mensagens de erro e em outras informações compartilhadas entre servidores cache. Colocar o nome do computador local.

Exemplo: visible_hostname micro_00

 

ACL (Access Control List)

 

Insert your own Rules (s)

 

            Essa é a parte fundamental do projeto. É onde será empregada todas as Access Control Lists (Também conhecidas como ACL's) da implementação da segurança da rede.

O controle de acesso do Squid tem recursos suficientes para definir com precisão quais tipos de serviços podem ser acessados por quais máquinas e em quais horários. As regras da lista de controle de acesso (Access Control List ou simplesmente ACLs) tem uma sintaxe bastante simples e são incluídas no arquivo squid.conf.

 

Tipos de elementos de ACL:

src: endereço IP de origem (cliente);

dst: endereço IP de destino (servidor);

srcdomain: um domínio de origem (cliente);

dstdomain: um domínio de destino (servidor);

srcdom_regex: padrão de texto, ou expressão regular, que conste no conteúdo da origem (cliente);

dstdom_regex: padrão de texto, ou expressão regular, que conste no conteúdo do destino (servidor);

time: Hora e dia da semana. Especifica um determinado horário.

url_regex: comparação de URL baseada em expressão regular. Utilizado para comparar uma string à uma URL inteira. Muito utilizado para fazer o bloqueio de sites indevidos.

urlpath_regex: Tem uma função semelhante à anterior, porém procura apenas em pedaços do caminho da URL. Muito utilizado para bloquear extensões, como veremos mais à frente.

port: número da porta do destino (servidor);  Usado para especificar acesso à determinada porta de um servidor.

myport: número da porta local na qual o cliente se conectou;

proto: especifica um protocolo de transferência (http, ftp, etc);

method: método http de requisição (get, post, etc);

browser: Comparação executada baseada no cabeçalho (header) do cliente (browser);

ident: nome do usuário;

src_as: número do Sistema Autônomo da origem (cliente);

dst_as: número do Sistema Autônomo do destino (servidor);

proxy_auth: Somente utilizada caso você esteja utilizando autenticação. Serve para especificar nomes de usuários. Filtro por usuários autenticados.

proxy_auth_regex: expressão regular que consta em uma autenticação de usuário via um processo externo;

snmp_community: string que indica o nome da comunidade SNMP;

maxconn: um número máximo de conexões de um mesmo endereço IP de cliente. Filtro por conexões.

arp: endereço Ethernet (MAC Address).

port: filtro por porta.

Nem todos os elementos de ACL podem ser usados com todas as listas de acessos (descritas a seguir). Por exemplo, snmp_community só terá significado quando usado com a lista snmp_access, bem como os elementos src_as e dst_as somente serão usados na lista cache_peer_access.

Cada elemento de ACL deve ser relacionado com somente um nome. Um elemento ACL com determinado nome consiste em uma lista de valores. Quando forem sendo feitos os testes, os múltiplos valores utilizarão o operador lógico OR. Em outras palavras, um elemento ACL será válido, quando qualquer um de seus valores for verdadeiro.

Você não pode dar o mesmo nome para diferentes tipos de elementos ACLs. Isto ocasionará um erro de sintaxe.

Você poderá colocar diferentes valores para a mesma ACL em diferentes linhas. O Squid os combinará em uma lista.

Lista de acessos

http_access: permite clientes http (browsers) acessarem a porta http. Esta ACL é a primária;

icp_access: permite caches "vizinhos" fazerem requisições ao seu cache através do protocolo ICP;

miss_access: permite a alguns clientes fazerem encaminhamento (forward) através de seu cache;

no_cache: define respostas que não deverão ser armazenadas no cache;

always_direct; controla quais requisições deverão ser sempre encaminhadas diretamente aos servidores de origem;

never_direct: controla quais requisições nunca deverão ser sempre encaminhadas diretamente aos servidores de origem;

snmp_access: controla acesso ao agente SNMP do squid;

cache_peer_access: controla quais requisições poderão ser encaminhadas a um servidor de cache vizinho. (peer)

Uma regra de lista de acesso consiste da palavra allow (permitir) ou deny (negar), seguido de uma lista de nomes de elementos ACL. Uma lista de acesso consiste em uma ou mais regras de acesso.

As listas de acesso são verificadas na mesma ordem em que foram escritas. A pesquisa na lista termina assim que uma requisição satisfazer uma regra.

Se uma regra possuir múltiplos elementos de ACL, esta usará o operador lógico AND. Em outras palavras, todos os elementos de uma regra precisarão ser validos para que esta regra seja válida. Isto significa que é possível escrever uma regra que nunca será válida. Por exemplo, um número de porta nunca poderá ser igual a 80 e 8000 ao mesmo tempo.

 

Alguns exemplos práticos:

Se você quiser impedir que qualquer usuário acesse páginas que contenham a palavra "sexo" na URL, acrescente as seguintes linhas no seu squid.conf:

acl proibir_cracker url_regex cracker

http_access deny proibir_cracker

 

E o bloqueio ainda pode ser para máquinas específicas. Imagine que o usuário da máquina cujo IP é 192.168.0.7 esteja ocupando muito a sua rede, transferindo arquivos de música em formato MP3. Para bloquear este usuário específico, use a regra como abaixo:

acl mp3 url_regex mp3

acl usr_ofensor src 192.160.0.7/255.255.255.255

http_access deny usr_ofensor mp3


Se quiser proibir todos os usuários de acessarem um determinado site:

acl site_proibido dstdomain .orkut.com
http_access deny all site_proibido

 

Também é possível permitir ou proibir o acesso em determinados dias e horários:

acl tempo_proibido time MTWHF 15:00-16:00
acl usr_ofensor src 192.168.0.7/255.255.255.255
http_access deny usr_ofensor tempo_proibido

 

A regra acima bloqueia o acesso à internet para o IP 192.168.0.7 durante o período das 15:00 às 16:00 horas. A opção MTWHF indica os dias da semana em inglês. Também podem ser utilizadas as opções A e S que equivalem ao sábado e ao domingo respectivamente.

Existem casos que uma empresa gostaria de liberar o acesso à internet apenas durante o horário de almoço. Para isso, a seguinte regra poderia ser aplicada:

acl funcionários src 192.168.0.0/0

acl acesso_almoco time MTWHF 12:00-13:00

http_access allow funcionários acesso_almoco

http_access deny funcionários

 

Dependendo do número de domínios ou de palavras-chave listadas em ACLs é aconselhável construir uma lista em um arquivo separado e indicá-lo no squid.conf. O arquivo com uma lista de domínios ou de expressões regulares a serem bloqueadas deve conter uma entrada por linha, como no exemplo:

Orkut
Sexo

Facebook
Blog
Fotolog

 

Caso o arquivo seja salvo em /etc/squid/sites_proibidos, por exemplo: podemos indicá-lo no arquivo de configuração do squid da seguinte maneira:

acl funcionários src 192.168.0.0/0

acl proibidos url_regex "/etc/squid/sites_proibidos"

http_access deny funcionários proibidos

 

Após incluir todas as suas regras restritivas, não se esqueça de incluir regras especificando que tudo o que não estiver expressamente proibido deve ser permitido. Na configuração original do squid.conf, as linhas serão como a que segue:

acl funcionários src 192.168.0.0/0

acl proibidos url_regex "/etc/squid/sites_proibidos"

http_access deny funcionários proibidos

 

Após incluir todas as suas regras restritivas, não esqueça de incluir regras especificando que tudo o que não estiver expressamente proibido deve ser permitido. Na configuração original do squid.conf, as linhas serão como a que segue:

acl rede_local src 192.168.0.0/255.255.255.0

http_access allow all rede_local

 

Observe que você deve definir a "rede_local" como conjunto de endereço IP e máscara que melhor descrevem a sua rede.

Normalmente o seu squid.conf virá com linhas como as que seguem:

#
# INSERT YOUR OWN RULE(S) HERE ALLOW ACCESS FROM YOUR CLIENTS
#
http_access deny all

 

Ela serve para bloquear o acesso ao Squid até que ele seja configurado, e é interessante você deixá-lo como última regra, pois desta forma, se a requisição não satisfazer nenhuma regra o squid irá bloqueá-la.

Examinando o squid.conf

Alterações bem feitas e pensadas podem trazer um grande ganho para a performance de seu cache, enquanto um erro de configuração pode impedir seu Squid de trabalhar ou remover muitas de suas funcionalidades.

É importante alterar as opções com cuidado e ter a certeza de que realmente necessita fazer a mudança planejada.

Tags da seção Network

Essa seção explica todos os parâmetros de endereços de redes relevantes para uma instalação do Squid.

http_port

O número da porta onde o Squid irá ouvir as requisições dos clientes.

O padrão é 3128. Essa opção será ignorada quando o squid é iniciado com a opção "-a" na linha de comando.

Você pode espeficicar múltiplas portas, em qualquer uma das três formas: somente a porta, por hostname e porta ou IP e porta. Se você espeficiar um hostname ou endereço IP, então o Squid irá ouvir naquele endereço especificado.

http_port porta

http_port ip:porta

hostname: porta

icp_port

Especifica o número da porta na qual o squid irá enviar e receber solicitações ICP de outros Cache Servers. Para desabilitar, basta colocar um 0. Padrão: 3130

Como já dito anteriormente, o ICP é usando para comunicação entre caches, provendo as funcionalidades necessárias para troca de informações sobre objetos armazenados.

icp_port porta

 

htcp_port

Especifica o número da porta através do qual o Squid irá receber e enviar requisições HTCP de e para caches vizinhos. Para desabilitar, colocar 0. O padrão é 4827.

Specify the port number through which Squid sends and receives HTCP queries to and from neighbor caches. To disable "0" is used (default = 4827).

htcp_port porta

 

mcast_groups

Especifica uma lista de grupos multicast, no qual seu servidor pode juntar-se para receber requisições ICP. Padrão = none

mcast_groups Endereço_IP

 

tcp_outgoing_address

É usado para conexões feitas em servidores remotos. Também é usado para comunicar-se com outros caches durante o uso de HTCP ou CARP.

Normalmente não deve-se especificar tcp_outgoing_address. A melhor opção é deixar o sistema operacional escolher um endereço. Padrão: 255.255.255.255

tcp_outgoing_address Endereço_IP

 

udp_incoming_address

É usado pelo socket ICP para receber pacotes de outros caches. Padrão: 0.0.0.0

udp_incoming_address Endereço_IP

 

udp_outgoing_address

É usado pelo socket ICP para enviar pacotes a outros caches. Padrão: 255.255.255.255

udp_outgoing_address Endereço_IP

 

 

Tags da seção Peer cache servers e Squid hierarchy

 

As tags dessa seção são relevantes quando rodando o Squid em uma rede com hierarquia.

 

cache_peer

Especifica outros caches na hierarquia. A opção cache_peer é dividida em 5 campos. O primeiro campo é o IP ou nome do servidor do cache que será pesquisado. O segundo indica o tipo de relacionamento. No terceiro configura-se a porta HTTP do servidor destino. No quarto campo configura-se a porta de requisição ICP e, finalmente, o quinto campo pode conter zero ou algumas palavras-chave.

cache_peer hostname tipo porta_http porta_icp [opções]


Parâmetros  -------- Descrição

 

Hostname (FQDN) ou endereço IP do cache a ser pesquisado.

tipo: especifica-se a hierarquia de cache definida. Opção importante para escolha de regras de vizinhança.

Opções:

Parent

sibling

multicast

porta_http - o número da porta onde o cache ouve as requisições http.

porta_icp - o número da porta onde o cache ouve as requisições http.

Opções

Descrição

proxy-only

Especifica que os objetos desse servidor não devem ser salvos localmente

Weight=n

Especifica o peso de um "pai". Deve ser um valor inteiro, sendo que o padrão é 1. Servidores com um peso maior tem preferência

ttl=n

Especifica o tempo de vida de um multicast

no-query

Essa opção será utilizando quando fazendo requisições a caches que não aceitam ou não suportam ICP. Caso utilize essa opção, configure o quarto campo como 0

default

Se esse cache será usado como uma última opção e ele não está configurado para trabalhar com ICP, entãp utilize essa opção. Ele não será o padrão, mas sim a última opção, apesar do que indica o nome da tag

round-robin

Define uma série de "pais" que podem ser usados baseados em algorítimo round-robin.

multicast-responder

Indica que o servidor indicado é membro de um grupo de multicast.

closest-only

Indica que, para uma resposta ICP_OP_MISS, nós somente iremos passar CLOSEST_PARENT_MISS e nunca FIRST_PARENT_MISS.

no-digest

Não faz requisições tipo digest para esse vizinho.

no-netdb-exchange

Desabilita requisições ICMP RTT desse vizinho

no-delay

Evita que esse vizinho seja influenciado por uma delay pool.

login=usuário:senha

Caso esse servidor exija autenticação.

connect-timeout=nn

Especifica o time out para essa conexão.

digest-url=url

Diz ao Squid para buscar o resumo do cache utilizando essa URL.

cache_peer_domain

Limita o domínio para qual cada vizinho será requisitado. É usado para enviar requisições para caches diferentes dependendo do domínio.

·         Colocar um '!' antes do domíno significa que o cache irá armazenar o que não for para tal.

·         Podemos colocar tantos domínios quanto necessário por cache, tanto na mesma linha como em linhas separadas.

·         Quando múltiplos domínios são dados para um único cache, o primeiro domínio é plicado.

·         Cache hosts sem domínio irão aceitar todos os pedidos

cache_peer_domain cache_host domínio [domínio]

neighbor_type_domain

Modifica o tipo do servidor vizinho dependendo do domínio. Você pode tratar domínios de forma diferente quando um servidor padrão é usado na tah cache_peer.

neighbor_type_domain parent|sibling domínio [domínio]

 

icp_query_timeout

Definição para o timeout de uma requisição ICP.

Visto que o Squid irá automaticamente determinar um valor ideal baseado em requisições recentes, é bom não alterar essa opção.

icp_query_timeout milisegundos

 

maximum_icp_query_timeout

Tempo máximo de expiração de uma requisição ICP. A resposta não será mais esperada depois desse tempo.

maximum_icp_query_timeout milisegundos

 

mcast_icp_query_timeout

Normalmente o Squid envia pacotes de teste para os endereços multicast para determinar quais servidores estão na escuta. Essa opção determina quanto tempo o Squid irá esperar por uma resposta.

Como o Squid fica aguardando resposta, não coloque um valor muito alto. O padrão está OK. 2000 ms.

mcast_icp_query_timeout milisegundos

 

dead_peer_timeout

Controla quanto tempo o Squid leva para declarar um servidor como morto. Se nenhuma requisição ICP for respondida nesse tempo, o Squid continuará mandando requisições ICP, mas não esperará por resposta. O servidor será novamente marcado como vivo depois que uma determinada seqüência de respostas for enviada. Padrão de 10 segundos.

dead_peer_timeout segundos

 

hierarchy_stoplist

Uma lista de palavras que, encontradas na URL, farão com que o objeto seja manipulado automaticamente por esse cache.

hierarchy_stoplist palavras

 

no_cache

Uma lista de elementos de uma ACL, onde, se encontrados, impedem o objeto de ser cacheado.

no_cache deny|allownomeacl

Adonel  Bezerra

Pós-graduado em Teoria em Educação a Distância e Docência do Ensino Superior;

MBA Executivo em Coaching;

Coordenador de cursos de pós-graduação.

Experiência em Gestão de Negócios, envolvendo-se com as áreas administrativa, financeira, comercial, produção e logística;

Experiência de mais de 20 anos como professor conferencista na área de segurança da informação;

Sólida experiência na gestão de negócios e tecnologia da informação;

Sólida experiência no meio acadêmico; 

Consultor de Segurança da informação com mais de vinte anos de experiência;

Treinamentos e palestras ministrados para milhares de profissionais em todo o Brasil;

Livro publicado pela Editora Ciência Moderna e diversos artigos publicados.

 

ALGUMAS PARTICIPAÇÕES COMO CONFERENCISTA OU PALESTRANTE

Centro Universitário do Maranhão – UniCeuma/2009 – Apresentação “O MERCADO DE CONSULTORIA EM SEGURANÇA DE INFORMAÇÃO. 

Universidade de Fortaleza|UNIFOR – Apresentação “TÉCNICAS HACKERS PARA TESTES DE INVASÃO”.

Faculdades Integradas do Ceará – FIC/2010 – Apresentação “ SEGURANÇA DA INFORMAÇÃO”.

Escola de Gestão Pública do Estado do Ceará – /2012 – Apresentação “ SEGURANÇA DA INFORMAÇÃO COM SOFTWARE LIVRE”.

Faculdade La Salle – 2013 – Apresentação “ESPIONAGEM INTERNACIONAL”.

Estácio|FIC/2013 – Apresentação “ ANÁLISE DE VULNERABILIDADES COMO FATOR PRIMORDIAL NAS ORGANIZAÇÕES”.

Estácio|FIC/2015 – Apresentação “PROVA DE CONCEITO”.

Devry Brasil|FANOR Salvador/BA, Fortaleza/CE, Belém/PA, Caruaru/PE, Recife/PE, Teresina/PI    - Apresentação “ VULNERABILIDADES DE SISTEMAS COMPUTACIONAIS”.

 

PROJETO PESSOAL – 1998 – Até o momento

- Fundador e Mantenedor de um dos maiores portais de Segurança de sistema do Brasil, o portal Clube do Hacker; www.clubedohacker.com.br

Fundador e mantenedor da Academia Linux www.academialinux.com.br

Fundador da BUCOIN – www.bucoin.com.br