Finalmente, chegamos na parte mais interessante: “O controle de acesso“.
As permissões de acesso ao cache são configuradas com a definição de ACLs (lista de controle de acesso). As ACLs são identificadores específicos para o tipo de “conteúdo” que desejamos filtrar, podendo ser: “endereços de origem/destino, métodos de conexão, tipo mime, domínios, URLs, usuários e etc“.
O formato de uma ACL é definido da seguinte maneira:
acl nome tipo argumentosou
acl nome tipo "/caminho_absoluto/arquivo"
Os tipos mais utilizados costumam ser: “src (IP de origem: 10.0.0.1), proxy_auth (usuário: user1@dominio.local), dstdomain (domínio de destino: .dominio.com), dstdom_regex (domínio de destino: \.dominio[0-9]\.com\.br), url_regex (URL: facebook\.com\/[0-9]+\/photos\/), port (portas: 80, 8080 ou 8081) e method (método HTTP: GET ou POST), por exemplo“.
“As ACLs all, manager, localhost e to_localhost são prédefinidas (nem sempre foram)“.
Alguns exemplos:
1. Identificando determinados domínios do Youtube:
acl dstyoutube dstdomain .youtube.com .googlevideo.com .video.google.com
2. Definindo uma blacklist por domínio:
acl blacklist dstdomain "/etc/squid/acl/domain_blacklist"– Conteúdo de /etc/squid/acl/domain_blacklist:
#Games .friv.com .friv2online.com .yoob.com .spilgames.com .wowwiki.com .warnet.com.br .innogames.com .dkpsystem.com .bosskiller.com .animesxgames.com .crafterstome.com .mmo-champion.com .tribalwars.com.br .thesettlersonline.com.br .goodgamestudios.com .netfreedomgames.com .guerrakhan.com .supremacy1914.com .jogatina.com .callofwar.com .frivjogosonline.com.br .leagueoflegends.com .rachacuca.com.br .frivjogosonline.com.br .coolrom.com
O nome da primeira ACL foi definido como dstyoutube e o segundo como blacklist. Em ambos os casos, identificando domínios de destino (tipo dstdomain). Conforme exposto inicialmente, são “apenas identificadores”.
Diferentes ações podem ser tomadas a partir dos filtros anteriores.
O veredito é feito com opções como: “http_access (requisições HTTP) ou http_reply_access (respostas HTTP), delay_access (recurso delay_pool para controle de banda), icp_access (controle de acesso entre caches vizinhos) ou no_cache (controle de objetos armazenados em cache)”.
Poderíamos, por exemplo, criar um controle de banda para dstyoutube e bloquear todos os domínios identificados pela ACL blacklist.
acl no_delay src 10.0.1.0/24 acl dstyoutube dstdomain .youtube.com .googlevideo.com .video.google.com acl blacklist dstdomain "/etc/squid/acl/domain_blacklist" # Limitando a banda total de domínios do Youtube em aproximadamente 5Mb/s (5000k * 1000 / 8) # - Exceto para a rede 10.0.1.0/24 (ACL no_delay) delay_pools 1 delay_class 1 1 delay_parameters 1 626000/626000 delay_access 1 allow dstyoutube !no_delay delay_access 1 deny all # Bloqueando os domínios listados no arquivo domain_blacklist http_access deny blacklist
Caso existam dúvidas quanto a configuração da opção delay_pools, recomendo a leitura do blog do João Eriberto:
https://eriberto.pro.br/wiki/index.php?title=Implementa%C3%A7%C3%A3o_de_delay_pool_com_Squid
Conforme demonstrado, cada opção de controle (delay_access ou http_access) permite especificar mais de uma ACL na mesma regra, estabelecendo um operador lógico AND. Logo, no exemplo acima, o limite de 5Mb/s NÃO se aplicará a rede 10.0.1.0/24 – percebam que houve uma inversão com !no_delay (utilizando o sinal !).
As permissões de acesso costumam ser feitas através da opção http_access, definindo allow para liberações e deny para bloqueios. Mas, tome cuidado com a sequência de http_access ou http_reply_access, pois, como o processamento é top-down (de cima para baixo), o veredito será final na primeira correspondência (sem analisar as regras seguintes).
Se fizéssemos uma liberação (http_access allow) para no_delay antes do controle de blacklist, nenhum bloqueio seguinte se aplicaria a rede 10.0.1.0/24. Ou seja, percebam que a estrutura de configuração depende do critério de acesso desejado.
# Bloqueando os domínios listados no arquivo domain_blacklist http_access allow no_delay http_access deny blacklist
“Vale lembrar que o processamento de um operador lógico “AND” se faz através de duas ou mais ACLs na mesma opção de controle. Como o processamento é sequencial, o “OR” é o operador lógico padrão. Caso a primeira condição não seja satisfeita, a regra seguinte é verificada“.
A utilização de expressões regulares (ACLs terminadas com _regex) oferece uma flexibilidade ainda maior. E, para demonstrar o potencial existente, finalizarei o artigo demonstrando, por meio de expressões regulares, como bloquear o facebook globalmente, autorizando apenas as fanpages linuxfirewall e aprendizfinanceiro (risos).
“Como a maior parte destas requisições é encriptada, a configuração do SSL_Bump será obrigatória“.
Colocando a mão na massa (TO GET THE HANDS DIRTY)… 😉
Para ativar o suporte ao SSL_Bump é necessário que o Squid tenha sido compilado com as opções “–enable-ssl“, “–enable-ssl-crtd” e “–with-openssl=’/usr/include/openssl/’“.
O Squid trabalha com processos separados, gerenciados pelo binário ssl_crtd, para recriar os certificados originais dos sites remotos. Sendo assim, para viabilizar esta demanda (criação e armazenamento dinâmico dos certificados), devemos satisfazer alguns pré-requisitos.
# Geração do certificado auto-assinado do servidor proxy # - Informações serão solicitadas para incorporar ao certificado (comando openssl req) sudo apt-get install ssl-cert sudo mkdir -p /etc/squid/ssl_cert/ sudo chown -R proxy.proxy /etc/squid/ssl_cert sudo chmod 700 /etc/squid/ssl_cert cd /etc/squid/ssl_cert openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes -x509 -extensions v3_ca -keyout myCA.pem -out myCA.pem openssl x509 -in myCA.pem -outform DER -out myCA.der # Estrutura para o gerenciamento dinâmico de certificados de sites remotos sudo ln -sf /usr/lib/squid/ssl_crtd /bin/ssl_crtd sudo /bin/ssl_crtd -c -s /var/spool/squid_ssldb sudo chown -R proxy.proxy /var/spool/squid_ssldb
No primeiro comando openssl (openssl req -new …), criamos um certificado auto-assinado (válido por 10 anos) para que a criptografia aconteça entre o servidor proxy e os clientes, permitindo ao Squid identificar o conteúdo de conexões HTTPS (é um man-in-the-middle). O segundo, foi utilizado para gerar outro certifcado, em codificação DER, que será importado na seção “Autoridades” dos navegadores dos usuários – sem esta etapa, inúmeros sites (como facebook e google) retornarão erro de certificado.
Em caso de dúvidas, leiam o howto oficial do Squid:
http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit
Para tornar o exemplo ainda mais claro, criaremos uma sequência de controles mandatórios (whitelists e blacklists), antes de submeter aos demais filtros. Demonstraremos um controle de acesso global e mandatório, antecedendo o controle de acesso para redes sociais.
Para isto, na ACL alnetworks, o administrador deverá cadastrar quais redes terão acesso ao cache. Do contrário, nenhuma requisição será aceita. Em serverlist é possível cadastrar uma lista de servidores confiáveis (destino) – ou seja, servidores livres de qualquer restrição. As demais ACLs foram utilizadas na definição dos controles mandatórios.
A princípio, apenas os IPs listados no arquivo clientaddr_socialnetwork serão autorizados para acessar as principais redes sociais. Porém, no caso do facebook, todas as estações da rede terão acesso garantido a fanpage linuxfirewall – aliás, será a página de erro padrão (vide deny_info) para chamadas não autorizadas também.
Antes de prosseguir, é importante compreender como as expressões são construídas. Sendo assim, demonstrarei algumas referências básicas:
| Expressão | Identificação da cadeia de caracteres |
|---|---|
| ^(expr) | Início de cadeia – que inicie com “expr” |
| (expr)$ | Fim de cadeia – que termine com “expr” |
| (expr)* | Múltiplas ocorrências (ou nenhuma repetição) |
| (expr)+ | Ao menos uma ou mais ocorrências (repetições) |
| (expr1|expr2) | expr1 OU expr2 |
| [0-9] | Variações entre 0 e 9 |
| . | Qualquer caractere |
| \. | Exatamente “.” (quando desejamos identificar o “ponto”) |
Estou validando a eficiência dos filtros com SSL_Bump, mas o resultado já está dentro do previsto. Para aplicar a configuração, edite o arquivo squid.conf e inclua as seguintes linhas:
... ## Networks acl serverlist dst "/etc/squid/acl/serverlist" acl alnetworks src "/etc/squid/acl/networks_allowed" http_access deny !alnetworks ## SSL site monitor http_port 8080 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myCA.pem sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/spool/squid_ssldb -M 4MB acl step1 at_step SslBump1 acl monitoredSites ssl::server_name .google.com .google.com.br .ssllabs.com .facebook.com .fbcdn.net .cloudfront.net sslproxy_cert_error allow monitoredSites ssl_bump peek step1 all ssl_bump bump monitoredSites ssl_bump splice all http_access allow CONNECT step1 monitoredSites ## Global Whitelist acl domain_whitelist dstdom_regex -i "/etc/squid/acl/domain_whitelist" acl clientaddr_whitelist src "/etc/squid/acl/clientaddr_whitelist" acl url_whitelist url_regex "/etc/squid/acl/url_whitelist" ## Global Blacklist acl domain_blacklist dstdomain -i "/etc/squid/acl/domain_blacklist" acl clientaddr_blacklist src "/etc/squid/acl/clientaddr_blacklist" acl url_blacklist url_regex "/etc/squid/acl/url_blacklist" ## Whitelist control (url_blacklist will deny domain_whitelist) http_access allow clientaddr_whitelist http_access allow serverlist http_reply_access allow serverlist http_access allow localhost !to_localhost http_access deny url_blacklist http_access allow domain_whitelist http_access allow url_whitelist http_reply_access allow clientaddr_whitelist http_reply_access allow domain_whitelist http_reply_access allow url_whitelist ## Blacklist control http_access deny to_localhost http_access deny domain_blacklist ## Socialnetwork access acl domain_socialnetwork dstdom_regex \.(facebook|fbcdn|twitter|badoo|linkedin|myspace|hi5|tagged|pinterest|twoo|tumblr)\.(net|com) acl domain_socialnetwork dstdom_regex (plus|plusone)\.google\.(com|com\.br) (messenger|twitter|instagram|facebridge|fbstatic-[a-z].akamaihd|snapchat)\.(net|com) acl clientaddr_socialnetwork src "/etc/squid/acl/clientaddr_socialnetwork" deny_info https://www.facebook.com/linuxfirewallbrasil/ clientaddr_socialnetwork http_access deny domain_socialnetwork !clientaddr_socialnetwork
O “pulo do gato” vem logo a seguir…
Através do controle estabelecido pela ACL url_whitelist, podemos criar expressões regulares que garantam o acesso para parte da API do facebook, sem precisar liberar o domínio por completo. Assegure, apenas, que nenhum bloqueio em url_blacklist possa invalidar a liberação que exemplificaremos abaixo.
Edite o arquivo /etc/squid/acl/url_whitelist e inclua as seguintes linhas:
# Para autorizar a renderização da página (requer SSL_Bump) facebook\.com\/ajax\/(bz|(mercury|event)\/|photos\/.*\/init\.php|pagelet\/.*\/(PhotoViewerInitPagelet|WebEgoPane)|log_ticker_render\.php) facebook\.com\/v[0-9]\.[0-9]\/plugins\/like\.php (external|scontent)-gru[0-9]-[0-9]\.xx\.fbcdn\.net staticxx\.facebook\.com\/(connect\/.*\.js|common\/.*\.php) \.fbcdn\.net\/rsrc\.php\/ \.facebook\.com\/(api\/graphqlbatch|ping\?) (^|\.)facebook.com\/pages_reaction_units\/more\/ (^|\.)facebook\.com\/(logout|login.php\?|bluebar\/modern_settings_menu\/) (^|\.)facebook\.(com|com\.br)(\/pg\/|\/)linuxfirewallbrasil($|\/) (^|\.)facebook\.(com|com\.br)(\/pg\/|\/)aprendizfinanceiro($|\/) (^|\.)cloudfront\.net\/assets\/(js|css|fonts)\/.*\.(js|css|ttf)($|\?) pro\.iconosquare\.com # Para autorizar alteração nas fanpages (requer SSL_Bump) (^|\.)facebook\.com\/react_composer\/(logging|status|scraper)\/ (^|\.)facebook\.com\/job_opening\/composer (^|\.)facebook\.com\/ufi\/(add|edit|delete|typing|reaction)\/ (^|\.)facebook\.com\/ajax\/(create|edit|sharer|notifications|edits\/(save|browser\/post))\/ (^|\.)facebook\.com\/ajax\/(photos\/.*(\.php|(edit|save)\/|\/move)|updatestatus\.php|timeline\/take_action_on_story.php)(\?|\/) (^|\.)facebook\.com\/ajax\/(feed\/edit_post\.php|typeahead\/search|ticker_entstory\.php)(\?|\/) (^|\.)facebook\.com\/ajax\/pages\/(recommendations|notifications|review|insights|edit_page)\/ (^|\.)facebook\.com\/events\/(dialog\/(create|edit|share)|ajax|create|edit)\/ (^|\.)facebook\.com\/page_edit\/dialog\/ (^|\.)facebook\.com\/pages\/(call_to_action|callout|feed|presence|insights|profile\/.*_(save|upload))\/ (^|\.)facebook\.com\/phot(o|os)\/(tagging\/|publish|.*\/save) (^|\.)facebook\.com\/profile\/(picture\/(composer_data|crop_(viewer|profile_pic))\/|timeline) (^|\.)facebook\.com\/album\/uploader (^|\.)facebook\.com\/[0-9]+\/photos\/\?tab=album\& (^|\.)facebook\.com\/(media|share)\/
Qualquer estação da rede poderá interagir com as duas fanpages autorizadas, sem liberar o domínio por completo e nem a timeline pessoal. Para liberar o acesso completo a uma estação específica, basta editar o arquivo clientaddr_socialnetwork e cadastrar o respectivo endereço.
Acredito que o básico (um pouco mais) e fundamental foi apresentado. Criar esta estrutura pela primeira vez pode ser um pouco trabalhoso. Mas, feito isto, o processo passa a ser praticamente operacional.
Futuramente, para trabalhar com filtragem heurística e sistema de classificação por categorias, pretendo compartilhar outro artigo com dicas para integração com serviços de filtragem avançada de conteúdo, como QLProxy ou C-ICAP.
Infelizmente, é inviável cobrir todas as possibilidades em um único artigo. O objetivo foi demonstrar o básico de configuração do servidor Squid, separando em quatro partes.
Espero que tenham gostado, e que as dicas sejam úteis ou possam ajudar de alguma forma.
[…] Para maiores informações quanto a configuração do ssl-bump: http://linuxfirewall.com.br/linuxwp/instalacao-e-configuracao-do-squid-basico-parte-44/ […]