Manual traduzido do Squid - Parte 2

Continuação da tradução livre do artigo: Manual traduzido do Squid.

[ Hits: 30.178 ]

Por: Buckminster em 29/07/2013


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.

tcp_outgoing_address ipaddr [[!]aclname] ...

Por exemplo, encaminhamento de clientes com IPs dedicados para certas sub-redes:

acl normal_service_net src 10.0.0.0/24
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

Página anterior    

Páginas do artigo
   1. Configurações mínimas recomendadas
   2. Considerações de segurança
   3. Insira suas próprias regras
   4. Opções de rede
   5. Opções TLS/SSL
   6. O Squid normalmente escuta na porta 3128
   7. TAG ToS
   8. TAG tcp_outgoing_address
Outros artigos deste autor

Compilando o Squid3

Redes de Computadores · IPtables · Endereços IPs - Explicações básicas

Compilando kernel no Debian Squeeze

Problema no GRUB no Debian Squeeze 6.0.7 [Resolvido]

Como um monte de letras de um código fonte transforma-se em voltagens?

Leitura recomendada

Squid autenticado no Active Directory com Winbind

Squid + Sarg + IPtables - Configuração rápida

Projeto Squid

OpenBSD Proxy - Squid, SquidGuard, SquidClamAV e AdZapper

Squid como proxy transparente: Instalando e configurando

  
Comentários
[1] Comentário enviado por removido em 29/07/2013 - 18:42h

Parabéns pela iniciativa, favoritado....

[2] Comentário enviado por flashnecessary em 31/07/2013 - 13:10h

Não sei se é o lugar certo ou você pode me ajudar.

Tenho o seguinte cenário e problema.
Firewall sonicwall com SSO habilitado,só que eventualmente aparecem computadores na rede (que não estão no domínio) que precisam de acesso a internet sem aparecer nenhuma tela de autenticação.

Ai entra minha duvida,o que posso utilizar para que quando a maquina entrar na rede e for verificado que ela não está no domínio ela navegue normalmente. Isso porque com o SSO habilitado tenho que bloquear tudo por default e ir liberando por departamento.

Att,

[3] Comentário enviado por Buckminster em 03/08/2013 - 15:42h


[2] Comentário enviado por flashnecessary em 31/07/2013 - 13:10h:

Não sei se é o lugar certo ou você pode me ajudar.

Tenho o seguinte cenário e problema.
Firewall sonicwall com SSO habilitado,só que eventualmente aparecem computadores na rede (que não estão no domínio) que precisam de acesso a internet sem aparecer nenhuma tela de autenticação.

Ai entra minha duvida,o que posso utilizar para que quando a maquina entrar na rede e for verificado que ela não está no domínio ela navegue normalmente. Isso porque com o SSO habilitado tenho que bloquear tudo por default e ir liberando por departamento.

Att,


Se for rede sem fio é só você criar uma rede aberta (sem senha ou com uma senha pública). Se for pela rede com fio, a única coisa a se fazer é criar a política de que os computadores de fora do domínio devem se cadastrar com o responsável pela rede quando chegam na empresa.

[4] Comentário enviado por juniorbiu em 13/09/2013 - 16:44h

Dr., Buckminster, boa tarde.
Vi seu post e achei fantástico.
Como percebi que você indicou configurações bem complexas, gostaria de saber se poderia me apoiar com meu post http://vivaolinux.com.br/topico/Seguranca-Linux/Squid-ERR-TUNNEL

Ja tentei usar o ssl_bump, mas meu squid da o erro:
cache_cf.cc(381) parseOneConfigFile: squid.conf:87 unrecognized: 'ssl_bump'
cache_cf.cc(381) parseOneConfigFile: squid.conf:88 unrecognized: 'ssl_bump'

Já viu isso?

Abs
Jr


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts