Manual traduzido do Squid - Parte 2

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

[ Hits: 34.215 ]

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

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

Antivírus ClamAV com proteção em tempo real

Como agendar um backup automático do PostgreSQL no Cron evitando o problema de senha

Compilando kernel no Debian Squeeze

Instalar OBS Studio e VLC no Slackware 15

Leitura recomendada

Squid com autenticação ncsa_auth no Mandriva 2006

Analisando log Squid do Mikrotik no SARG

Bloqueando Windows Live Messenger com Squid (Debian ou Ubuntu)

PhpDansAdmin, protótipo de ferramenta web para administração do DansGuardian

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

  
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