A história da autenticação segura do usuário no squid

Era uma vez, uma bela selva virtual quente na América do Sul e um servidor de Lula morava lá. aqui está uma imagem perceptiva da rede:

                 <the Internet>
                        | 
                        | 
           A            |          B
Users <---------> [squid-Server] <---> [LDAP-Server] 

Quando a Userssolicitação acessar a Internet, squidpergunte o nome e o passaporte, os autentique LDAPe se o LDAP os aprovar, ele os concederá.

Todos ficaram felizes até que alguns farejadores roubaram o passaporte no caminho entre os usuários e o squid [caminho A]. Este desastre aconteceu porque o squid usou o Basic-Authenticationmétodo.

O povo da selva se reuniu para resolver o problema. Alguns coelhos ofereceram usando o NTLMmétodo Serpentes preferidas Digest-Authenticationenquanto Kerberosrecomendadas por árvores.

Afinal, muitas soluções oferecidas pelas pessoas da selva e tudo estava confuso! O leão decidiu acabar com a situação. Ele gritou as regras para soluções:

• A solução deve ser segura!
• A solução deve funcionar para a maioria dos navegadores e softwares (por exemplo, baixar softwares)
• A solução deve ser simples e não precisa de outro subsistema enorme (como o servidor Samba)
• O método não deve depender de um domínio especial. (por exemplo, Active Directory)

Então, uma solução inteligente, abrangente e abrangente, oferecida por um macaco, fazendo dele o novo rei da selva!

você consegue adivinhar qual foi a solução?

Dica: O caminho entre squide LDAPé protegido pelo leão, portanto, a solução não precisa protegê-lo.

Nota: desculpe se a história é chata e confusa, mas a maior parte é real! =)

               /~\/~\/~\
            /\~/~\/~\/~\/~\
          ((/~\/~\/~\/~\/~\))
        (/~\/~\/~\/~\/~\/~\/~\)
       (////     ~   ~     \\\\)
       (\\\\(   (0) (0)   )////)
       (\\\\(   __\-/__   )////)
        (\\\(     /-\     )///)
         (\\\(  (""""")  )///)
          (\\\(  \^^^/  )///)
           (\\\(       )///)
             (\/~\/~\/~\/)         **
               (\/~\/~\/)        *####*
                |     |           ****
               /| | | |\            \\
            _/  | | | | \_ _________//   Thanks!
           (,,)(,,)_(,,)(,,)--------'

Atualizar:

Massimo explicou que o método de autenticação entre Users- squide squid- LDAPnão precisa ser o mesmo. podemos usar o método arbitrário para obter informações de autenticação dos usuários e o método arbitrário para os dados coletados autenticados.

Mas há um problema: a entrada / saída de todos os tipos de autenticadores não é a mesma. Por exemplo:

• um Basicautenticador deve ler o par "senha de nome de usuário" em uma linha e responder a OKse a senha do usuário estiver correta ouERR
• um Digestautenticador deve ler um username:realme responder um codificado em hexadecimal de HA(A1)ou um ERR.

Embora não exista relação direta entre o método client-squid e o método squid-ldap, os dados coletados do cliente devem ser compatíveis com o método usado na parte squid-ldap. Portanto, se alterarmos o método de autenticação no lado do usuário, talvez também devamos alterar nosso autenticador.

Portanto, o problema simplifica para:

1. No primeiro nível, eu (o macaco!) Estou procurando um bom método de autenticação no lado do usuário. Qual método você recomenda, que é seguro e suportado pela maioria dos navegadores ? Estou confuso entre NTLM, Kerberose Digest.

2. Onde posso encontrar um autenticador que ofereça suporte a informações de credenciais do método selecionado e autentique através do LDAP.

Kerberos não é uma opção para autenticação HTTP. O NTLM não é bem suportado em nenhum navegador que não seja o IE. O Basic não é seguro, a menos que você o coloque atrás do HTTPS, que o AFAIK squid não pode fazer. Então você fica com o Digest.

Uma característica interessante que pode ajudá-lo aqui é que o método Squid usa para solicitar autenticação ao navegador do cliente (caminho A) não precisa estar relacionado ao método que ele usa para validar as credenciais fornecidas pelo usuário (caminho B) ) Isso significa, por exemplo, que você pode fazer o Squid "falar" o NTLM com os navegadores clientes, mas pode muito bem validar os usuários no banco de dados interno do usuário do Linux (/ etc / passwd). Não há necessidade de credenciais adquiridas usando NTLM (no caminho A) para serem realmente validadas em um domínio do Windows (no caminho B). O mesmo se aplica a qualquer combinação possível de métodos de autenticação do lado do cliente e de autenticação do lado do servidor.

O que isso significa no seu caso, é que você pode configurar o Squid com segurança para solicitar autenticação NTLM dos navegadores clientes em vez da autenticação básica, e isso não exigirá, de forma alguma, que você realmente use o Samba / WinBind / AD / o que for.

Assim, você pode escolher o método que deseja para autenticação no lado do cliente e continuar validando os usuários em um servidor LDAP depois que eles fornecerem suas credenciais usando o método selecionado.

A mágica acontece, é claro, em squid.conf:

#auth_param negotiate program <uncomment and complete this line to activate>
#auth_param negotiate children 5
#auth_param negotiate keep_alive on
#auth_param ntlm program <uncomment and complete this line to activate>
#auth_param ntlm children 5
#auth_param ntlm keep_alive on
#auth_param digest program <uncomment and complete this line>
#auth_param digest children 5
#auth_param digest realm Squid proxy-caching web server
#auth_param digest nonce_garbage_interval 5 minutes
#auth_param digest nonce_max_duration 30 minutes
#auth_param digest nonce_max_count 50
#auth_param basic program <uncomment and complete this line>
#auth_param basic children 5
#auth_param basic realm Squid proxy-caching web server
#auth_param basic credentialsttl 2 hours
#auth_param basic casesensitive off

Cada auth_paramdiretiva permite uma autenticação específica para os navegadores clientes (caminho A), enquanto a parte "programa" define o que o Squid realmente usará para validar as credenciais fornecidas pelos usuários. Você pode usar o programa autenticador que desejar aqui (mesmo um personalizado), desde que possa receber um ID de usuário e uma senha e responder "sim" ou "não".

Você só precisa pegar o autenticador que estiver usando para fazer sua consulta LDAP e colá-lo nas instruções "auth_param ntlm" ou "auth_param digest", em vez do "auth_param basic" onde está agora.

Atualizar:

Você definitivamente deve usar o squid_ldap_auth como seu autenticador, mas não posso dizer exatamente como, sem nenhum detalhe sobre o servidor LDAP específico que você está usando.

Em relação à autenticação do lado do cliente, qualquer um deve ser bom; Estou muito feliz com o NTLM e a maioria dos navegadores o suporta atualmente.

Essa configuração ficaria assim no squid.conf:

auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>

Isso solicitará credenciais do usuário (caminho A) usando NTLM e as validará em um servidor LDAP (caminho B); mas esses "parâmetros" dependem estritamente da implementação e configuração do LDAP.

Isso também pode ajudar: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html .