Configurações mínimas recomendadas
Continuação da tradução livre do manual do Squid.
Leia a primeira parte aqui: Manual traduzido do Squid.
Exemplo de regras que permitem acesso às suas redes locais. Adapte as listas às suas redes internas, onde a navegação deve ser permitida.
Comente as linhas que não forem necessárias:
acl localnet src 172.16.0.0/12 # RFC1918 possível rede interna
acl localnet src 192.168.0.0/16 # RFC1918 possível rede interna
acl localnet src fc00::/7 # RFC 4193 rede privada local
acl localnet src fe80::/10 # RFC 4291 máquinas plugadas no link-local
acl SSL_ports port 443
acl Safe_ports port 80 # HTTP
acl Safe_ports port 21 # FTP
acl Safe_ports port 443 # HTTPS
Acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # HTTP-MGMT
Acl Safe_ports port 488 # GSS-HTTP
Acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling HTTP
acl CONNECT method CONNECT
TAG: follow_x_forwarded_for :: permitindo ou negando o cabeçalho “X-Forwarded-For” para encontrar a fonte original da requisição.
As requisições podem passar através de uma cadeia de outros proxies antes de chegar ao Squid. O cabeçalho “X-Forwarded-For” contém uma lista de IPs separados por vírgulas, sendo que o endereço mais à direita, é o mais recente.
Se a requisição chegar a partir de uma fonte permitida pela configuração, então o cabeçalho “X-Forwarded-For” será consultado para ver de onde veio a requisição. Se o cabeçalho “X-Forwarded-For” contiver múltiplos endereços, o Squid continuará recuando a consulta até chegar a um endereço não autorizado, e seguirá até chegar ao primeiro cabeçalho X-Forwarded-For da lista.
O propósito da ACL utilizada na diretiva “follow_x_forwarded_for”, a ACL do tipo “src” sempre corresponderá ao endereço testadoe a ACL “srcdomain” corresponderá ao DNS.
O resultado final deste processo, é um endereço IP referente ao endereço do cliente. Este endereço pode ser tratado como o endereço do cliente, ICAP, delay pools e logging, dependendo de:
- acl_uses_indirect_client
- icap_uses_indirect_client
- delay_pool_uses_indirect_client
- log_uses_indirect_client
- tproxy_uses_indirect_client options
Estas cláusulas são suportadas somente pelas ACLs do tipo fast.
Para maiores detalhes, veja: SquidFaq/SquidAcl – Squid Web Proxy Wiki
Considerações de segurança
Qualquer host do cabeçalho “X-Forwarded-For” pode colocar informações incorretas no cabeçalho e o Squid usará estas informações incorretas como se fosse a fonte da requisição. Isto pode permitir que hosts remotos contornem as restrições de controle de acesso.
Por exemplo:
acl my_other_proxy srcdomain .proxy.example.com
follow_x_forwarded_for allow localhost
follow_x_forwarded_for allow my_other_proxy
Default: follow_x_forwarded_for deny all
TAG: acl_uses_indirect_client on|off :: controla o acesso se o endereço indireto do cliente (veja follow_x_forwarded_for) for usado em vez do endereço direto.
Nota: a ACL maxconn considera que conexões TCP diretas e indiretas serão sempre zero, portanto, não corresponderão.
Default: acl_uses_indirect_client on
TAG: delay_pool_uses_indirect_client on|off
Nota: esta opção só estará disponível se o Squid for compilado com “–enable-follow-x-forwarded-for” e “–enable-delay-pools”.
Controla o acesso se o endereço indireto do cliente (veja “follow_x_forwarded_for”) for usado em vez do endereço direto em “delay pools”.
Default: delay_pool_uses_indirect_client on
TAG: log_uses_indirect_client on|off :: controla o acesso se o endereço indireto do cliente (veja “follow_x_forwarded_for”) for usado em vez do endereço direto em access log.
Default: log_uses_indirect_client on
TAG: tproxy_uses_indirect_client on|off :: controla o acesso se o endereço indireto do cliente (veja “follow_x_forwarded_for”) for usado em vez do endereço direto no spoofing de saída do cliente.
Não tem efeito nas requisições que chegam no modo non-tproxy.
AVISO DE SEGURANÇA: o uso desta opção é perigosa e não deve ser usada trivialmente. A correta configuração de “follow_x_forewarded_for” deve ser usada com um conjunto limitado de fontes para evitar o abuso do proxy.
Default: tproxy_uses_indirect_client off
TAG: http_access :: permite ou nega o acesso com base em listas pré-definidas.
Acesso na porta HTTP:
- http_access allow|deny [!]aclname …
NOTE sobre os valores padrões:
- Se não há linhas “access” presentes, o padrão é negar o acesso.
- Se nenhuma das linhas “access” corresponder, o padrão será o oposto da última linha na lista. Se a última linha negou o acesso, o padrão será permitir. Por outro lado, se a última linha permitiu o acesso, o padrão será negar. Por essa razão sempre tenha uma linha “deny all” no final das ACLs.
Suporta ACLs fast e slow. Para mais detalhes, veja:
Default: http_access deny all
Configurações mínimas
Configurações mínimas recomendadas de permissões de acesso:
Somente permite o acesso do localhost ao “cachemgr”:
http_access deny manager
Nega o acesso para determinadas portas inseguras:
Nega CONNECT para portas SSL inseguras:
Recomendamos, fortemente, descomentar a seguinte linha para proteger as aplicações web rodando no servidor proxy e permitindo o acesso ao localhost somente aos usuários da rede local:
Insira suas próprias regras
Insira suas próprias regras aqui para permitir, ou negar, o acesso de seus clientes.
Exemplo de regras permitindo o acesso às suas redes locais:
Obs.: adapte a ACL “localnet” para o endereço IP das suas redes internas.
http_access allow localhost
E, finalmente, negue o acesso a tudo que não foi permitido acima dessa linha:
TAG: adapted_http_access :: permitir ou negar o acesso com base nas listas pré-definidas.
Idêntica à “http_access”, mas é executada após o redirecionamento e adaptações ICAP/eCAP. Permite o controle de acesso baseado na saída.
Se não for definida, http_access será usada.
Default: none
TAG: http_reply_access :: permite respostas às requisições do cliente. É complementar à “http_access”.
Nota: se não há linhas de acesso, o padrão é permitir todas as repostas.
Se nenhuma das ACLs corresponder, o oposto da última linha será aplicado. Assim, é uma boa prática terminar as regras com “allow all” ou “deny all”.
Esta cláusula suporta ACLs fast e slow. Para detalhes, veja:
Default: none
TAG: icp_access :: permitir ou negar acesso às portas ICP definidas nas ACLs.
Veja “http_access” para maiores detalhes. Esta cláusula somente é suportada nas ACLs fast. Para detalhes, veja:
Permitir ou negar consultas ICP em redes locais:
icp_access deny all
Default: icp_access deny all
TAG: htcp_access :: permitir ou negar consultas ICP em redes locais:
Veja “http_access” para detalhes.
Nota: se nenhuma linha “http_access” estiver presente, o padrão é negar todo o tráfego. Este padrão pode causar problemas com requisições usando HTCP. Esta cláusula somente suporta ACLs do tipo fast.
Para detalhes, veja:
Permitir consultas HTCP a partir das redes locais:
htcp_access deny all
Default: htcp_access deny all
TAG: htcp_clr_access :: permitir ou negar o acesso para limpar consultas HTCP.
Veja “http_access” para detalhes. Suporta somente ACLs fast. Para detalhes, veja:
Permitir requisições HTCP CLR de clientes confiáveis:
htcp_clr_access allow htcp_clr_peer
Default: htcp_clr_access deny all
TAG: miss_access :: determinar se o acesso a rede é permitido quando satisfizer uma requisição.
Por exemplo, para forçar outras redes locais a usar o proxy como um “irmão” em vez de um “pai”.
miss_access allow localclients
miss_access deny !localclients
Isto significa que seus clientes locais estão autorizados a buscar uma resposta “relayed/MISS” da rede e todos os outros clientes só podem buscar objetos em cache (HITs).
HIT significa que o documento foi encontrado no cache. A MISS (ERR), que não foi encontrado no cache. Um Hit negativo significa que foi encontrado no cache, mas não existe.
O padrão para esta configuração permite que todos os clientes que passaram pelas regras, possam retransmitir através do proxy. Suporta apenas ACLs fast.
Para detalhes, veja:
Default: none
TAG: ident_lookup_access :: ACL de elementos que, se combinados, causam uma pesquisa “ident (RFC 931)” a ser realizada na requisição. Por exemplo, você pode optar por sempre realizar pesquisas ident para seus principais usuários Unix, mas não para seus usuários Mac.
Por padrão, as pesquisas ident não são executadas para todas as requisições. Exemplo:
ident_lookup_access allow ident_aware_hosts
ident_lookup_access deny all
Somente ACLs do tipo src são suportadas totalmente. ACLs srcdomain podem funcionar às vezes, mas não é recomendável usar. Suporta soment ACLs fast.
Para detalhes, veja:
Default: ident_lookup_access deny all
TAG: reply_body_max_size size [acl acl…] :: esta opção especifica o tamanho máximo de uma resposta. Pode ser usada para evitar que usuários façam download de arquivos grandes, tais como MP3 e filmes. Quando os cabeçalhos das respostas são recebidos, o “reply_body_max_size” é processado, e a primeira linha (se houver) será usada como tamanho máximo.
Este tamanho é verificado duas vezes. Primeiro, quando chegar o cabeçalho, se o conteúdo existe, e é maior do que o tamanho máximo permitido, a requisição será negada e o usuário receberá uma resposta “the request or reply is too large”. Se não houver conteúdo e a resposta exceder o limite, a conexão será fechada e o usuário recebe uma resposta parcial.
Aviso: o downstream de caches não consegue detectar uma resposta parcial se não houver um cabeçalho “content-length”, então, as respostas serão armazenadas em cache e será dado um HIT.
Você NÃO pode usar esta opção se tiver cache downstream.
Aviso: um tamanho menor do que o tamanho das mensagens de erro do Squid causará um loop infinito e o Squid travará. Coloque um valor diferente de zero e maior do que o tamanho máximo do cabeçalho mais o tamanho da sua página de erro.
Se você não definir este parâmetro, não haverá limite. O formato da configuração; é:
I.e.:
reply_body_max_size 10 MB
Default: none
Opções de rede
TAG: http_port
Uso:
hostname:port [mode] [options]
1.2.3.4:port [mode] [options]
Socket de endereços onde o Squid irá escutar o cliente HTTP. Você pode especificar vários endereços.
Há três formas: somente a porta, hostname com a porta e endereços IP com a porta. Se você especificar um hostname ou IP, o Squid se liga no socket especificado. Se você não precisa se ligar a um endereço específico, pode usar o número da porta sozinho.
Se você estiver executando o Squid no modo accelerator, provavelmente quer escutar na porta 80 também.
A opção “-a” da linha de comando, pode ser usada para especificar porta(s) adicionais. Tais portas são portas de procuração simples sem opções. Você pode especificar vários endereços em várias linhas.
Modos:
- intercept :: suporte para interceptação de requisições de saída IP-Layer sem setar a configuração no navegador.
- NP: desativa a autenticação e o IPv6 na porta.
- tproxy :: suporte para TPROXY Linux para conexões de saída spoofing usando o endereço IP do cliente.
- NP: desativa autenticação e talvez o IPv5 na porta.
- accel :: Modo accelerator/reverse do proxy.
- ssl-bump :: estabelece uma conexão segura entre o cliente e o servidor para cada requisição CONNECT permitida pela ACL ssl_bump e as mensagens HTTPS que passarem pelo Squid serão decifradas e tratadas como mensagens HTTP não criptografadas, tornando o Squid como “man-in-the-middle”.
A opção “ssl_bump” é necessária para habilitar plenamente as requisições CONNECT. Omitindo esta flag, o modo padrão proxy forward será usado.
Opções do modo acelerador:
- defaultsite=domainname :: o que usar para o Host: se o cabeçalho não está presente na requisição. Determina accelerator de site (não servidor de origem) deve ser considerado o padrão.
- no-vhost :: desative usando cabeçalho HTTP/1.1 para o suporte de domínio virtual.
- protocol= :: protocolo para reconstruir requisições aceleradas. O podrão é http_port para HTTP e https_port para HTTPS.
- vport :: suporte para porta de host virtual. Usa http_port number em vez da porta passada no host.
- vport=NN :: suporta da porta de host virtual. Usa o número da porta específica em vez da porta passada no host.
- act-as-origin :: atua como se o Squid fosse o servidor de origem. Isto significa que gera novos cabeçalhos new Date: e Expires: no HIT em vez de adicionar “Age:”.
- ignore-cc :: ignora requisições com cabeçalhos Cache-Control.
Aviso: esta opção viola as especificações HTTP se for usada em configurações non-accelerator.
- allow-direct :: permite o encaminhamento direto no modo accelerator. As requisições diretas no modo accelerator normalmente são negadas como se a opção never_direct fosse usada.
Aviso: esta opção abre o modo accelerator para vulnerabilidades de segurança que geralmente afetam somente no mod intercept. Certifique-se de proteger as requisições com regras “http_access” adequadas.
Opções do modo SSL Bump (colisão):
- ssl-bump exige também opções TLS/SSL.
- generate-host-certificates[=<on|off>] :: cria certificados dinâmicos SSL para os host de destino nas requisições CONNECT. Quando habilitado as opções cert e key são usadas para assinar os certificados gerados. De outra forma, os certificados gerados serão selfsigned.
Se houver um tempo de vida do certificado gerado, será igual ao lifetime do certificado CA. Se o certificado gerado é “selfsigned”, o tempo de vida será de três anos.
Esta opção é ativada por padrão quando “ssl-bump” for usado. Veja as opções ssl-bump acima para maiores informações. - dynamic_cert_mem_cache_size=SIZE :: tamanho usado da memória RAM total aproximado com certificados gerados em cache. Se for definido como o cache será desativado. O padrão é 4 MB.
Opções TLS/SSL
cert= :: caminho para o certificado SSL (PEM format).
key= :: caminho para o arquivo da chave privada SSL (PEM FORMAT). Se não for especificado, o arquivo do certificado é assumido como sendo uma combinação de certificado e chave no mesmo arquivo.
version= :: versões SSL/TLS suportadas:
- automática (default)
- SSLv2 somente
- SSLv3 somente
- TLSv1.0 somente
- TLSv1.1 somente
- TLSv1.2 somente
cipher= :: lista de cifras suportadas, separadas por dois pontos.
Nota: algumas cifras como EDH dependem de configurações adicionais. Se essas configurações forem omitidas, as cifras podem ser ignoradas pela biblioteca OpenSSL.
options= :: opções de implementação SSL. As mais importantes são:
- NO_SSLv2 :: desabilita o uso de SSLv2
- NO_SSLv3 :: desabilita o uso de SSLv3
- NO_TLSv1 :: desabilita o uso de TLSv1.0
- NO_TLSv1_1 :: desabilita o uso de TLSv1.1
- NO_TLSv1_2 :: desabilita o uso de TLSv1.2
- SINGLE_DH_USE :: sempre cria uma nova chave ao trocas DH temporárias/efêmeras.
- ALL :: ativa várias soluções de bugs sugeridas como “harmless” pelo OpenSSL. Isto reduz a segurança SSL/TLS para alguns ataques.
Veja a documentação “OpenSSL SSL_CTX_set_options” para uma lista completa de opções.
clientca= :: arquivo contendo listas de CAs quando um certificado do cliente for requisitado.
cafile= :: arquivo contendo certificados CA adicionais para usar na verificação. Se não for setada, a opção clientca será usada.
capath= :: diretório contendo certificados CA adicionais e listas CRL para verificação do certificado do cliente.
crlfile= :: arquivo de listas CRL adicionais usadas para verificar o certificado do cliente, além dos CRLs da opção capath. Implica na opção VERIFY_CRL abaixo.
dhparams= :: arquivo contendo os parâmetros DH para trocas de chave temporárias/efêmeras. Veja a documentação OpenSSL sobre como criar este arquivo.
Aviso: a cifragem EDH será silenciosamente desabilitada se esta opção não for setada.
sslflags= :: várias flags que modificam o uso de SSL:
- DELAYED_AUTH :: não solicitar imediatamente certificados de clientes, mas espere que a ACL requisite. (ainda não implementada).
- NO_DEFAULT_CA :: não use a lista padrão CA do OpenSSL.
- NO_SESSION_REUSE :: não permitir a reutilização da sessão. Cada conexão resultará em uma nova sessão SSL.
- VERIFY_CRL :: verificar listas CRL ao aceitar certificados de clientes.
- VERIFY_CRL_ALL :: verifique as listas CRL para todos os certificados da cadeia de certificados do cliente.
sslcontext= :: sessão SSL identificadora do contexto ID.
Outras opções: connection-auth[=on|off] :: use connection-auth=off para impedir encaminhamento NTLM, Negotiate e Kerberos. disable-pmtu-discovery= :: Path-MTU controle de uso de descoberta:
- Em off :: deixa que o S.O. decida (default).
- transparent :: desabilita a descoberta PMTU.
- always :: sempre desabilita a descoberta PMTU.
Em muitas configurações de proxy transparente, a descoberta Path-MTU não funciona. Este é o caso quando a interceptação não controla totalmente as conexões e não consegue transmitir mensagens ICMP. Se você tiver essa configuração e alguns clientes não conseguem conectar nunca ou esporadicamente, sete a opção “disable-pmtu-discovery” para “transparent”.
name= :: especifica um nome interno para a porta. Padrões para a especificação de porta (“port” ou “addr:port”).
tcpkeepalive[=idle,interval,timeout] :: habilita o keepalive TCP para conexões ociosas. Em segundos, “idle” é o momento inicial antes do TCP proibir a conexão, interval define quantas vezes, e timeout define o tempo de espera antes de desistir.
Se você rodar o Squid em uma máquina dual-homed com interfaces internas e externas, recomendamos que você especifique o endereço interno “address:port” em “http_port”. Desta forma, o Squid só será visível no endereço interno.
O Squid normalmente escuta na porta 3128
Porta padrão do Squid:
TAG: https_port
Nota: esta opção só funciona se o Squid foi compilado com “–enable-ssl”.
Uso:
É o endereço do socket onde o Squid irá escutar as requisições TLS ou SSL. Comumente referido como HTTPS. Isto é muito útil para situações em que você está executando o Squid em modo acelerador e que fazer o trabalho SSL ao nível do acelerador.
Você pode especificar vários endereços em várias linhas, cada com seu próprio certificado SSL e/ou opções.
Modos:
- accel :: accelerator/reverse proxy modo
- intercept :: suporte para interceptação IP-Layer das requisições sem setar o proxy no navegador.
- NP: desabilita a autenticação e IPv6 na porta usada.
- tproxy :: suporte para Linux TPROXY para conexões spoofing que utilizam o endereço IP do cliente.
- NP: desabilita a autenticação e talvez IPv6 na porta usada.
- ssl-bump :: para cada conexão interceptada permitida pela ACL ssl_bump é estabelecida uma conexão segura com o cliente e o servidor, e as mensagens HTTPS serão decifradas e tratadas como mensagens não-criptografadas HTTP, tornando o Squid como “man-in-the-middle” (homem-do-meio).
É requerido um servidor primário “ssl_bump server-first” para habilitar a interceptação das conexões SSL. Requer tproxy ou intercept.
Omitindo-se o modo, faz com que o modo padrão (forward) de proxy seja usado. Veja http_port para uma lista de opções genéricas.
Opções SSL:
cert= :: caminho para o certificado SSL (PEM format).
key= :: caminho para o arquivo da chave privada SSL (PEM format). Se não for especificado, será assumido que o arquivo da chave e do certificado são o mesmo arquivo.
version= :: especifica a versão suportada pelo SSL/TLS:
- automática (default)
- somente SSLv2
- somente SSLv3
- somente TLSv1.0
cipher= :: dois pontos “:” separam as listas de cifragens suportadas.
options= :: opções de implementação SSL. As mais importantes são:
- NO_SSLv2 :: desabilita o uso de SSLv2
- NO_SSLv3 :: desabilita o uso de SSLv3
- NO_TLSv1 :: desabilita o uso de TLSv1
- SINGLE_DH_USE :: sempre cria uma nova chave ao usar mudanças temporárias/efêmeras com chaves DH.
- ALL :: Habilita várias soluções de bugs sugeridas como “inofensivas” pela OpenSSL. Isso reduz a segurança SSL/TLS para alguns ataques.
Veja “src/ssl_support.c” ou a documentação OpenSSL “SSL_CTX_set_options” para uma lista completa de opções.
clientca= :: arquivo que contém a lista de CAs quando for solicitado um certificado ao cliente.
cafile= :: arquivo contendo certificados CA adicionais para uso ao verificar os certificados dos clientes. Se não for setado, será usada a opção clientca.
capath= :: diretório contendo certificados CA adicionais e listas de CRL para usar ao verificar os certificados dos clientes.
crlfile= :: arquivo de listas CRL adicionais para usar ao verificar o certificado do cliente, além dos setados na opção capath. Implica no uso da flag “VERIFY_CRL”, abaixo.
dhparams= :: arquivo contendo os parâmetros DH para trocas de chaves DH temporárias/efêmeras.
sslflags= :: várias flags modificam o uso de SSL:
- DELAYED_AUTH :: não solicite imediatamente os certificados, mas espere até a ACL requisitar um certificado (ainda não implementado).
- NO_DEFAULT_CA :: não use a lista padrão CA do OpenSSL.
- NO_SESSION_REUSE :: não habilita a reutilização da sessão. Cada conexão resultará em uma nova sessão SSL.
- VERIFY_CRL :: verifica as listas CRL ao aceitar os certificados.
- VERIFY_CRL_ALL :: verifica as listas CRL para todos os certificados dos clientes.
sslcontext= :: identificador de contexto ID da sessão SSL.
generate-host-certificates[=<on|off>] :: cria certificados SSL dinâmicos para o host de destino das requisições SSL. Quando habilitada, as opções “cert” e “key” serão usadas para assinar os certificados gerados. Caso contrário, o certificado gerado será selfsigned (auto-assinado).
Se existir um tempo de vida para o certificado, será o lifetime do certificado CA. Se o certificado gerado for “selfsigned”, o tempo de vida é de três anos.
Esta opção é ativada por padrão quando SslBump for usado. Veja a opção “SslBump” acima para maiores informações.
dynamic_cert_mem_cache_size=SIZE :: tamanho usado da memória RAM total aproximado com certificados gerados em cache. Se for definido como o cache será desativado. O padrão é 4 MB.
Veja “http_port” para uma lista de opções.
Default: none
TAG ToS
TAG: tcp_outgoing_tos :: permite que você selecione um valor “ToS/DiffServ” para os pacotes de saída do servidor com base em uma ACL.
Exemplo de ACL normal_service_net usando o valor ToS 0x00 e good_service_net usando 0x20:
acl good_service_net src 10.0.1.0/24
tcp_outgoing_tos 0x00 normal_service_net
tcp_outgoing_tos 0x20 good_service_net
Os valores ToS/DSCP só tem significado local – então, você deve saber o que está especificando. Para maior informação, veja as RFC2474, RFC2475 e RFC3260. O byte ToS/DSCP deve ser exatamente um octeto – entre 0 – 255, ou “default” para usar o padrão do host. Muitas vezes, apenas múltiplos de 4 são utilizáveis para os dois bits mais à direita, quando forem predefinidos para serem usados por ECN (RFC 3168 seção 23.1).
Processa os recursos na ordem especificada e para na primeira linha correspondente.
Default: none
TAG: clientside_tos :: permite selecionar um valor ToS/DiffServ para pacotes transmitidos pelo cliente, com base em uma ACL.
Exemplo de ACL “normal_service_net” usando o valor ToS 0x00 e good_service_net usando 0x20:
acl good_service_net src 10.0.1.0/24
clientside_tos 0x00 normal_service_net
clientside_tos 0x20 good_service_net
Nota: este recurso é incompatível com “qos_flows”. Quaisquer valores ToS definidos aqui, serão substituídos pelos valores ToS em qos_flows.
Default: none
TAG: tcp_outgoing_mark
Nota: esta opção só está disponível quando o Squid for compilado com o pacote MARK (Linux).
Permite que você aplique um valor de marca Netfilter para os pacotes de saída no servidor, com base em uma ACL.
Exemplo de ACL “normal_service_net” usando a marca de valor 0x00 e good_service_net usando 0x20:
acl good_service_net src 10.0.1.0/24
tcp_outgoing_mark 0x00 normal_service_net
tcp_outgoing_mark 0x20 good_service_net
Default: none
TAG: clientside_mark
Nota: esta opção só está disponível quando o Squid for compilado com o pacote MARK (Linux).
Permite que você aplique um valor de marca Netfilter para os pacotes de saída no cliente, com base em uma ACL.
Exemplo de ACL “normal_service_net” usando a marca de valor 0x00 e good_service_net usando 0x20:
acl good_service_net src 10.0.1.0/24
clientside_mark 0x00 normal_service_net
clientside_mark 0x20 good_service_net
Nota: este recurso é incompatível com “qos_flows”. Quaisquer valores ToS definidos aqui, serão substituídos pelos valores ToS em qos_flows.
Default: none
TAG: qos_flows :: permite selecionar um valor ToS/DSCP para marcar conexões de saída com base na resposta de origem. Para plataformas que usam Netfilter, permite definir uma marca de valor Netfilter em vez do, ou com o valor ToS.
Os valores ToS só tem significado local – então, você deve saber o que está especificando. Para maior informação, veja as RFC2474, RFC2475 e RFC3260.
O byte ToS/DSCP deve ser exatamente um octeto – entre 0 – 255, ou “default” para usar o padrão do host. Muitas vezes apenas múltiplos de 4 são utilizáveis para os dois bits mais à direita quando forem predefinidos para serem usados por ECN (RFC 3168 seção 23.1).
Os valores da marca podem ser qualquer inteiro de 32 bits sem sinal. Os seguintes valores podem ser configurados:
- tos|mark :: define os valores ToS ou Netfilter.
- local-hit=0xFF :: valor para marcar os acessos ao cache local..
- sibling-hit=0xFF :: valor para marcar hits de pares de irmãos.
- parent-hit=0xFF :: valor para marcar hits de pares de pais.
- miss=0xFF[/mask] :: valor para marcar cache perdido. Tem precedência sobre o recurso “preserve-miss” (veja abaixo), a menos que a máscara for especificada, caso em que apenas os bits especificados na máscara serão escritos.
As variantes ToS dos seguintes recursos somente são possíveis no GNU/Linux e requerem que o kernel tenha o patch ToS preservando o patch ZPH, disponível em:
Não precisa nenhum patch para Netfilter, sendo que trabalha com todas as variantes do Netfilter.
disable-preserve-miss :: esta opção desabilita a preservação da marca ToS ou Netfilter.
Por padrão, os valores ToS ou Netfilter existentes vindos do servidor remoto serão mantidos e mascarados com miss-mark.
Nota: no caso de ser Netfilter, a marca deve ser definida na conexão (usando o alvo CONNMARK) e não sobre o pacote (alvo MARK).
miss-mask=0xFF :: permite mascarar certos bits ToS ou as marcas dos valores recebidos do servidor remoto antes de copiar o valor para enviar ao cliente.
Default para ToS: 0xFF (ToS do servidor não é alterado).
Default for mark: 0xFFFFFFFF (mark do servidor não é alterada).
Estes recursos requerem a compilação com a flag “–enable-zph-qos” (habilitada por default). A marcação Netfilter requer também as bibliotecas libnetfilter_conntrack (–with-netfilter-conntrack) e libcap 2.09+ (–with-libcap).
Default: none
TAG tcp_outgoing_address
TAG: tcp_outgoing_address :: permite mapear requisições para diferentes endereços IP com base no nome do usuário ou no endereço de origem do usuário que fez a requisição.
Por exemplo, encaminhamento de clientes com IPs dedicados para certas sub-redes:
acl good_service_net src 10.0.2.0/24
tcp_outgoing_address 2001:db8::c001 good_service_net
tcp_outgoing_address 10.1.0.2 good_service_net
tcp_outgoing_address 2001:db8::beef normal_service_net
tcp_outgoing_address 10.1.0.1 normal_service_net
tcp_outgoing_address 2001:db8::1
tcp_outgoing_address 10.1.0.3
Processa os recursos na ordem especificada, parando na primeira linha que corresponder. O Squid irá adicionar uma versão de teste de IP implícito para cada linha:
- Requisições indo para sites IPv4 usarão endereços: 10.1.0.*
- Requisições indo para sites IPv6 usarão endereços: 2001:db8:*
Nota 1: esta opção é incompatível com o uso de clientes que dependem de ACLs em conexões persistentes no lado servidor. Para garantir resultados corretos, é melhor definir “server_persistent_connections” como “off” quando usar esta opção.
Nota 2: esta opção é incompatível para definir um IP local nas conexões TCP de saída usando um TPROXY. Quando precisar, use as opções “no-tproxy”, “cache_peer” e “client_dst_passthru” para reabilitar o encaminhamento normal.
Default: none
TAG: host_verify_strict :: independentemente da configuração desta opção, o Squid sempre verifica se o endereço IP de destino corresponde ao domínio do cabeçalho do host ou do IP (chamado “authority form URL”).
Isto é feito para satisfazer a exigência da RFC2616, seção 14.23:
“O valor do campo host deve representar a autoridade de nomeação do servidor de origem ou gateway dada pela URL original”.
Quando setado em “ON”: Squid sempre responde com uma página de erro HTTP 409 (Conflict) e registra um log de segurança. O Squid verifica se o endereço IP de destino corresponde ao cabeçalho do host para o tráfego forward-proxy e reverse-proxy.
Para esse dois tipos de tráfego, o Squid compara os cabeçalhos do host e os componentes Request-URI:
- Os nomes do host (domínio ou IP) devem ser idênticos, mas se estiverem sem valor, todas as verificações serão desabilitadas. Os nomes de host devem ser IP ou FQDN.
- Os números de portas devem ser idênticos, mas se a porta estiver faltando, o esquema padrão é assumido.
Quando setado em OFF (padrão): O Squid permite que as requisições suspeitas continuem, mas registra um aviso de segurança e bloqueia o cache de resposta.
- O tráfego forward-proxy não é verificado em tudo.
- O tráfego reverse-proxy não é verificado em tudo.
- O tráfego interceptado é tratado de acordo com a opção client_dst_passthru.
- Requisições interceptadas nas quais falharam a verificação, são enviadas para o destino original do cliente em vez de DIRECT. Isto substitui “client_dst_passthru off”.
Requisições CONNECT suspeitas são sempre respondidas com uma página de erro HTTP 409 (Conflict).
Nota de Segurança: Como descrito em “CVE-2009-0801”, quando o “host:header for” usado para determinar o destino de uma requisição, torna-se trivial que scripts maliciosos em sites remotos contornem a política de segurança do navegador e as proteções sandboxing.
A causa disso é que tais applets estão autorizadas a efetuar sua própria pilha TCP, caso em que a política sandboxing do navegador verifica apenas que a applet tenta contatar o mesmo endereço IP a partir de onde foi carregado. O “host:header” pode ser diferente do IP conectado e da origem aprovada na requisição.
Default: host_verify_strict off
TAG: client_dst_passthru :: com NAT ou TPROXY o tráfego pode passar a requisição diretamente ao IP de destino original do cliente ou buscar uma fonte mais rápida usando o cabeçalho do host HTTP.
A utilização do host para localizar servidores alternativos fornecem uma conectividade mais rápida com um leque de opções de recuperação de falhas. Mas também, pode levar a problemas de conectividade quando o cliente e o servidor estão tentando interações stateful desconhecidas para o proxy.
Esta opção (on por padrão) impede que DNSs alternativos sejam localizados para enviar o tráfego direto a um servidor de origem. O IP de destino e a porta originais dos clientes serão usados em vez dos desconhecidos.
Independentemente desta opção estar configurada, o Squid verificará o “host:header” e todo o tráfego será tratado como se esta opção estivesse ON.
Veja “host_verify_strict” para obter detalhes do processo de verificação.
Default: client_dst_passthru on
Linux para iniciante 