Manual traduzido do Squid - Parte 2

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

[ Hits: 30.177 ]

Por: Buckminster em 29/07/2013


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 localnet
http_access allow localhost

E, finalmente, negue o acesso a tudo que não foi permitido acima dessa linha:

http_access deny all

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".

http_reply_access allow|deny [!] aclname ...

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.

icp_access  allow|deny [!]aclname ...

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 allow localnet
icp_access deny all

Default: icp_access deny all


TAG: htcp_access :: permitir ou negar consultas ICP em redes locais:

htcp_access  allow|deny [!]aclname ...

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 allow localnet
htcp_access deny all

Default: htcp_access deny all


TAG: htcp_clr_access :: permitir ou negar o acesso para limpar consultas HTCP.

htcp_clr_access  allow|deny [!]aclname ...

Veja "http_access" para detalhes. Suporta somente ACLs fast. Para detalhes, veja:
Permitir requisições HTCP CLR de clientes confiáveis:

acl htcp_clr_peer src 172.16.1.2
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".

acl localclients src 172.16.0.0/16
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:

acl ident_aware_hosts src 198.168.1.0/24
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; é:

reply_body_max_size SIZE UNITS [acl ...]

I.e.:

reply_body_max_size 10 MB

Default: none

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

Instalação do PAP (PostgreSL, Apache2 e PHP7) no Debian Jessie

Montagem de Cluster

Manual traduzido do Squid - Parte 3

Squid - Entendendo um pouco as configurações

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

Leitura recomendada

SUSE Linux - Squid autenticando no Active Directory (AD)

Mandriva 2006 - Configurando servidor proxy transparente completo

Squid autenticado - Instalar e configurar

Controlando acesso às páginas do Apache na rede interna

Squid avançado + OpenLDAP

  
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