Squid3 + Ubuntu Lucid 10.04 + Kerberos Auth + AD
Esse artigo mostrará a configuração do Squid3 utilizando autenticação Kerberos. Ambiente utilizado: Squid3, Ubuntu 10.04, squid_kerb_auth e Windows 2003 AD.
Squid e suas autenticações
Pessoal, depois de 2 anos utilizando Squid + NTLM na empresa ele começou a dar problemas, eu realizei uma pesquisa sobre as diversas maneiras de autenticação, vou resumir para quem quer aprender um pouco sobre como autenticar o Squid.
Para realizar a autenticação o Squid utiliza os chamados helpers, que nada mais são que interfaces que realizam a autenticação e retorna um OK ou um ERR para o proxy. A forma como essa autenticação vai ser negociada é o que define sua segurança, eficiência e compatibilidade. Cabe ao responsável decidir a melhor forma a ser utilizada.
Existem basicamente 4 formas de autenticação:
Esse método porém possui 2 defeitos, devido ao desafio, para cada requisição http no proxy ele gera 3 registro no proxy 2 HTTP_DENIED 407 e um HTTP_MISS ou HIT no momento que a autenticação dá certo, para cada requisição é necessário essa autenticação, o que perde um pouco de performance.
Outro problema é a incompatibilidade. Esse tipo de autenticação também já não é tão segura, tanto que vem desabilitado por padrão o suporte a NTLM no Windows7, para quem quiser testar mesmo assim pode seguir o tutorial do próprio site do Squid:
Os tickets duram em média 5 minutos, o que torna improvável a quebra de uma senha com esse nível de criptografia em tão pouco tempo, após 5 minutos o usuário solicita um novo ticket. O processo de autenticação é mais leve em termo de performance.
O porém dessa autenticação é a incompatibilidade, só funciona com Internet Explorer 7 pra cima e com o Firefox 3 ou superior (não foram testados Chrome, Opera, Safari etc).
Para questão de compatibilidade é possível configurar uma autenticação do tipo Basic como alternativa, será descrito no artigo.
Para realizar a autenticação o Squid utiliza os chamados helpers, que nada mais são que interfaces que realizam a autenticação e retorna um OK ou um ERR para o proxy. A forma como essa autenticação vai ser negociada é o que define sua segurança, eficiência e compatibilidade. Cabe ao responsável decidir a melhor forma a ser utilizada.
Existem basicamente 4 formas de autenticação:
Basic (passando a senha em texto puro)
A Autenticação Basic é a mais comum, compatível e fácil de ser configurada, porém a mais insegura, qualquer interceptação de pacote é possível capturar a senha do usuário que está navegando. Ela pode ser implementada com diversos helpers, por exemplo pam, httpd, ldap, nsca etc. Há diversos tutoriais sobre esse tipo de autenticação.Digest (passando o hash da senha)
Esse tipo de autenticação invés de passar a senha em texto puro passa o hash em MD5 ou SHA-1, isso dificulta um pouco a captura de senhas, porém senhas inferiores a 15 caracteres são facilmente quebradas com ataque de rainbowtables ou de dicionário. Há tutoriais explicando como implementar esse tipo de autenticação com LDAP, porém não achei para o Active Directory, somente para Open LDAP.ntlm (utilizando challenge response)
Na autenticação NTLM é realizado um challenge response, ao autenticar o usuário se identifica e recebe um desafio do servidor, o que trafega pela rede é o hash da senha com a resposta do desafio, caso o pacote seja capturado o atacante não terá a senha e sim a senha + alguma coisa, isso dificulta a quebra da senha e aumenta um pouco a segurança.Esse método porém possui 2 defeitos, devido ao desafio, para cada requisição http no proxy ele gera 3 registro no proxy 2 HTTP_DENIED 407 e um HTTP_MISS ou HIT no momento que a autenticação dá certo, para cada requisição é necessário essa autenticação, o que perde um pouco de performance.
Outro problema é a incompatibilidade. Esse tipo de autenticação também já não é tão segura, tanto que vem desabilitado por padrão o suporte a NTLM no Windows7, para quem quiser testar mesmo assim pode seguir o tutorial do próprio site do Squid:
negotiate
Esse é o tipo de autenticação que abordaremos no artigo, baseia-se na emissão de tickets. Para configuração é necessário gerar um keymap no AD para o srvsquid funcionando da seguinte forma, o srvsquid (nome do servidor Squid) confia no srvdc1 (nome do servidor do AD), o usuário paulo se autentica no servidor srvdc1 e ganha um ticket, uma espécie de "crachá", onde ele autentica seus acessos ao servidor de arquivos, impressão etc. Ao tentar acessar a internet é solicitada autenticação e ele mostra esse "crachá" para o srvsquid, o srvsquid então verifica a validade do crachá com o srvdc1 e se estiver ok ele dá o acesso, tudo isso é feito de forma segura.Os tickets duram em média 5 minutos, o que torna improvável a quebra de uma senha com esse nível de criptografia em tão pouco tempo, após 5 minutos o usuário solicita um novo ticket. O processo de autenticação é mais leve em termo de performance.
O porém dessa autenticação é a incompatibilidade, só funciona com Internet Explorer 7 pra cima e com o Firefox 3 ou superior (não foram testados Chrome, Opera, Safari etc).
Para questão de compatibilidade é possível configurar uma autenticação do tipo Basic como alternativa, será descrito no artigo.
Muito interessante seu artigo, na pratica tenho q colocar senha no browser ou o processo de autenticação é automatico, o usuário logou no dominio ta logado?
Att.
Leandro Moreira