Manual traduzido do Squid - Parte 2

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

[ Hits: 30.183 ]

Por: Buckminster em 29/07/2013


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 localhost src 127.0.0.1
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 allow localhost manager
http_access deny manager

Nega o acesso para determinadas portas inseguras:

http_access deny !Safe_ports

Nega CONNECT para portas SSL inseguras:

http_access deny CONNECT !SSL_ports

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:

http_access deny manager

Página anterior     Próxima página

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

Manual traduzido do Squid - Parte 3

Encapsulando BIND 9 e Apache 2 para obter maior segurança

Problema no GRUB no Debian Squeeze 6.0.7 [Resolvido]

Squid - Entendendo um pouco as configurações

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

Leitura recomendada

FLogSQD - Filtro de log do proxy Squid

Squid3 com bloqueio HTTPS [que realmente funciona] - Versão 3.5.22

Liberando vídeos específicos do YouTube com e2guardian + Squid utilizando interceptação SSL

Squid + HTB Tools - Cache indo a FULL!

Implementação de um proxy/cache para ganho de conexão

  
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