Manual traduzido do Squid - Parte 2

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

[ Hits: 33.216 ]

Por: Buckminster em 29/07/2013


O Squid normalmente escuta na porta 3128



Porta padrão do Squid:

http_port 3128

TAG: https_port
Nota: esta opção só funciona se o Squid foi compilado com "--enable-ssl".

Uso:

[ip:]port cert=certificate.pem [key=key.pem] [mode] [options...]

É 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:
  1. automática (default)
  2. somente SSLv2
  3. somente SSLv3
  4. 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

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

Compilação do Kernel

Instalação do Ventoy, programa para criar pendrives inicializáveis

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

Instalando e Configurando o pgAgent no Linux (pgAdmin e PostgreSQL)

VMD no Debian - Instalação e configuração

Leitura recomendada

Squid + Bridge + TProxy no CentOS 5.4

Compilando o Squid com autenticação PAM

Implementação de um servidor Linux Squid + Iptables + DHCP

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

Thunder Cache - Cache inteligente

  
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

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts