Squid + squidGuard + AD Lento para autenticar

wandermaia

Boa tarde!

Estou realizando os testes para instalação em um cliente. Estou instalando squid + squidGuard +AD. Quando realizo os testes com o squidGuard desabilitado, tudo funciona muito bem e rápido. Quando habilito o squidGuard fica lento para autenticar. Já verifiquei vários tópicos e tutoriais na internet e ainda não consegui resolver o problema.

O único erro que tenho encontrado é [sp_reconfigure_db] Warning User destinations list empty. Este erro ocorre exatamente antes do [sg_create_config] Add sources: AD_WEB1 AD_WEB2 (esses são os grupos que estou utilizando para o teste). Já verifiquei os arquivos de configuração do squidGuard, mas parece estar tudo normal.

Fiz os testes com o squid, squid3, squidGuard e squidGuard-devel. Em todas combinações possíveis, o resultado é o mesmo.

Alguém já teve algum problema parecido?

tomaswaldow

Não sei se é o caso, mas tenta não usar caracteres: _, @ etc nos nomes de grupos e senhas, usuários.
Tente modificar pra ver se ajuda!

wandermaia

Obrigado pela ajuda Tomas!

Os grupos realmente tinham o "_" no nome. Retirei mas mesmo assim está lento. Estou achando estranho porque não apresentar erro nenhum.

A única mensagem anormal que consegui identificar foi essa no "Filter GUI log", que é exatamente antes de adicionar sources dos grupos que estão criados. Se realizo a configuração para utilizar o squid_ldap_group diretamente no squid (sem usar o squidGuard), ele funciona perfeitamente.

Como sou iniciante, creio que devo estar fazendo alguma coisa errada na configuração do squidGurad.

brainner

Eu tinha o mesmo problema aqui atualizei versão fiz de tudo e sempre ficou lento, o que eu fiz foi colocar no navegador as exceções de proxy do internet explorer, os principais sites que o pessoal acessa para trabalho, o que não estavam na lista, ele pede autenticação.

didonsom

@wandermaia:

Obrigado pela ajuda Tomas!

Os grupos realmente tinham o "_" no nome. Retirei mas mesmo assim está lento. Estou achando estranho porque não apresentar erro nenhum.

A única mensagem anormal que consegui identificar foi essa no "Filter GUI log", que é exatamente antes de adicionar sources dos grupos que estão criados. Se realizo a configuração para utilizar o squid_ldap_group diretamente no squid (sem usar o squidGuard), ele funciona perfeitamente.

Como sou iniciante, creio que devo estar fazendo alguma coisa errada na configuração do squidGurad.

A Sua rede possui quantos usuários? pode ser que precise aumentar o Autentication Process

Monitore a autenticação do squid para ver se apresenta algum erro.

no console digite opção 8 (SHELL)

Tail -f /var/squid/logs/access.log

veja se ao executar esse comando é exibido algum erro.

Eu tinha um problema semelhante mas no meu caso a internet ficava muito lenta, tinha reinstalado o pfsense e nada, ai o que eu identifiquei, problema ocorria na hora de carregar os grupos do squidguard, por algum problema bugou e isso estava deixando lento, resumindo, tive que voltar um backup antigo e recriar as novas configurações na mão ai com isso o problema foi resolvido.

Abraços,

Diego

wandermaia

Obrigado pela ajuda didsom!

Nos logs do squid não aparecem nada. Verifiquei que a integração do squidGuard está sendo realizada antes da autenticação do squid no AD. Isso pode gerar algum problema? Se o usuário ainda não está logado, o squidGuard ainda não tem condições de realizar a pesquisa do grupo corretamente.

Estava "comendo mosca" e não estava olhando o log do squidGuard. Achei o erro abaixo:

2016-05-15 11:40:02 [59846] (squidGuard): ldap_simple_bind_s failed: Can't contact LDAP server

Mas é muito estranho, porque uso as mesmas credenciais no squid realiza autenticação perfeitamente. Existe alguma forma de realizar um debug no squidGuard?

verifiquei o arquivo /usr/local/etc/squid/squidGuard.conf e as configurações estão corretas. Como faço para testar a consulta? Usei como referencia o modelo que vem na própria interface do squidGuard.

Inclusive agora realizei uma nova instalação com o pfsense 2.3 (antes estava usando o 2.2.6) e o erro é o mesmo.

didonsom

@wandermaia:

Obrigado pela ajuda didsom!

Nos logs do squid não aparecem nada. Verifiquei que a integração do squidGuard está sendo realizada antes da autenticação do squid no AD. Isso pode gerar algum problema? Se o usuário ainda não está logado, o squidGuard ainda não tem condições de realizar a pesquisa do grupo corretamente.

Estava "comendo mosca" e não estava olhando o log do squidGuard. Achei o erro abaixo:

2016-05-15 11:40:02 [59846] (squidGuard): ldap_simple_bind_s failed: Can't contact LDAP server

Mas é muito estranho, porque uso as mesmas credenciais no squid realiza autenticação perfeitamente. Existe alguma forma de realizar um debug no squidGuard?

verifiquei o arquivo /usr/local/etc/squid/squidGuard.conf e as configurações estão corretas. Como faço para testar a consulta? Usei como referencia o modelo que vem na própria interface do squidGuard.

Inclusive agora realizei uma nova instalação com o pfsense 2.3 (antes estava usando o 2.2.6) e o erro é o mesmo.

como você está fazendo para configurar o squid e o squidguard?, se possível poste as configurações do squid e squidguard pq fica mais fácil ajudar! :)

se não puder postar responda:

1 - Qual o método de autenticação no squid?

veja se esse tópico que eu criei te ajuda, https://forum.pfsense.org/index.php?topic=59064.msg317218#msg317218

2 - você liberou uma regra no firewall para a porta 3128 (proxy) e para a porta 389( que se refere a consulta ldap) ?

3 - você está utilizando proxy autenticado?

4 - está utilizando algum patch como o pf2ad para integrar o pfsense com o samba?

5- você habilitou a consulta ldap na parte principal do squidguard? se sim, desabilita, pq se não me engano ela só funciona junto com o patch pf2ad. se desabilitar ela e no grupo coloque o nome dos usuários.

a mensagem que ele está exibindo é que não está sendo possível conectar com o servidor ldap.

abraços,

Diego

wandermaia

Seguem abaixo as conigurações que estou utilizando:

Configuração squid (funcionou no 2 e no 3) para autenticar no AD (Server 2008R2):

Authentication server: 10.131.0.7
Authentication server: 389
LDAP Version :3
LDAP server user DN: CN=adm.proxy,OU=ADMs,OU=USUARIOS-EXTERNOS,OU=EMPRESA,DC=meudominio,DC=com,DC=br
LDAP base domain: DC=meudominio,DC=com,DC=br
LDAP username DN atribute: uid
LDAP search filter: sAMAccountName=%s

Adicionei a opção -R no arquivo squid.inc logo após a opção ldap_version, asism a linha de autenticação ficou da seguinte forma (copiado do diretamente do arquvio squid.conf):
auth_param basic program /usr/pbi/squid-amd64/libexec/squid/squid_ldap_auth -v 3 -R -b DC=meudominio,DC=com,DC=br -D CN=adm.proxy,OU=ADMs,OU=USUARIOS-EXTERNOS,OU=EMPRESA,DC=meudominio,DC=com,DC=br -w S3nhA.Pr0xy -f "sAMAccountName=%s" -u uid -P 10.131.0.7:389

Configurações no squidGuard:

LDAP DN: CN=adm.proxy,OU=ADMs,OU=USUARIOS-EXTERNOS,OU=EMPRESA,DC=meudominio,DC=com,DC=br
LDAP DN Password: S3nhA.Pr0xy
LDAP VERSION: version3

Groups ACL:
AD_WEBAC1:
Client Source: ldapusersearch ldap://10.131.0.7:389/DC=meudominio,DC=com,DC=br?sAMAccountName?sub?(&(objectclass=person)(sAMAccountName=%s)(memberOf=CN=WEBAC1%2cOU=PROXY%2cOU=USUARIOS-EXTERNOS%2cOU=EMPRESA%2cDC=meudominio%2cDC=com%2cDC=br))

AD_WEBAC2:
Client Source: ldapusersearch ldap://10.131.0.7:389/DC=meudominio,DC=com,DC=br?sAMAccountName?sub?(&(objectclass=person)(sAMAccountName=%s)(memberOf=CN=WEBAC2%2cOU=PROXY%2cOU=USUARIOS-EXTERNOS%2cOU=EMPRESA%2cDC=meudominio%2cDC=com%2cDC=br))

Os grupos WEBAC1 e WEBAC2 são os utilizados para o teste. Serão utilizados cinco grupos inicialmente da seguinte forma:

Grupo WEBAC1 – Acesso sem restrição
Grupo WEBAC2 – Restrição a tudo, acesso somente a IPs internos e site empresa.
Grupo WEBAC3 – Restrição padrão, Facebook, Globo, Youtube
Grupo WEBAC4 – Restrição padrão, Facebook, Globo, Youtube
Grupo WEBAC5 – Restrição padrão, Facebook, Globo, Youtube

OBS.: Alterei as informações acima que faziam referência a empresa antes de enviar.

Testei tanto com squidGuard quanto squidGuard-Devel. A diferença na configuração é somente que no Devel é necessário utilizar a consulta entre aspas, conforme o exemplo na interface web.

Enquanto estava escrevendo essas informações, identifiquei porque o servidor do AD não estava respondendo para o squidGuard: em algum momento dos testes, troquei o IP do AD pelo do pfsense na consulta do ldapusersearch.
Agora com o IP corrigido ele voltou a apresentar o comportamento inicial: ele autentica e aplica a política, mas demora muito para acessar a página. Em cada acesso a página diferente, ele realiza uma nova autenticação e dessa forma a navegação é impraticável.

Nos testes utilizando apenas o squid, ele estava se comportando dessa forma antes de eu colocar a opção -R.
Utilizando a consulta por grupos do squid, a busta é rápida e funciona normal. No campo custom insiro da seguinte forma:

auth_param basic program /usr/pbi/squid-amd64/libexec/squid/squid_ldap_auth -v 3 -R -b DC=meudominio,DC=com,DC=br -D CN=adm.proxy,OU=ADMs,OU=USUARIOS-EXTERNOS,OU=EMPRESA,DC=meudominio,DC=com,DC=br -w S3nhA.Pr0xy -f "sAMAccountName=%s" -u uid -P 10.131.0.7:389;
auth_param basic children 5;
auth_param basic realm Entre com as Credenciais;
auth_param basic credentialsttl 60 minutes;
acl password proxy_auth REQUIRED;
external_acl_type ldap_users %LOGIN /usr/pbi/squid-amd64/local/libexec/squid/squid_ldap_group -v 3 -R -b DC=meudominio,DC=com,DC=br -D CN=adm.proxy,OU=ADMs,OU=USUARIOS-EXTERNOS,OU=EMPRESA,DC=meudominio,DC=com,DC=br -w S3nhA.Pr0xy -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf=cn=%a,OU=PROXY,OU=USUARIOS-EXTERNOS,OU=EMPRESA,DC=meudominio,DC=com,DC=br))" -h 10.131.0.7:389;
acl AD_WEBAC1 external ldap_users WEBAC1;
acl AD_WEBAC2 external ldap_users WEBAC2;
acl AD_WEBAC3 external ldap_users WEBAC3;
acl AD_WEBAC4 external ldap_users WEBAC4;
acl AD_WEBAC5 external ldap_users WEBAC5;
acl BLOQUEIOPADRAO url_regex -i "/var/squid/acl/sites/bloqueioPadrao.txt";
acl LIBERADOINTERNO dst 10.131.0.0/255.255.255.0;
acl SITE_DOMINIO dstdomain .meudominio.com.br;
http_access allow SITE_DOMINIO;
http_access allow LIBERADOINTERNO;
http_access allow AD_WEBAC1;
http_access deny BLOQUEIOPADRAO;
http_access allow AD_WEBAC3;
http_access allow AD_WEBAC4;
http_access allow AD_WEBAC5;
http_access deny AD_WEBAC2;
http_access deny all;

Estou mantendo a estrutura dos grupos e senhas porque é a que está no cliente. No ambiente de testes retirei, caracteres especiais, pontos e traços, porém o resultado é sempre o mesmo.

wandermaia

Esqueci de mencionar, estou utilizando o AD 2008R2 porque é o que está instalado no cliente, mas validei essa configurações do squid no 2003SP2 e no 2012.

didonsom

@wandermaia:

Esqueci de mencionar, estou utilizando o AD 2008R2 porque é o que está instalado no cliente, mas validei essa configurações do squid no 2003SP2 e no 2012.

Já tentou retirar a consulta ldap do squidguard? desmarque essa opção no webconfigurator e no grupo inclua os usuários manualmente com aspas 'usuario1' 'usuario2' e faça o teste para ver se continua lento.

veja esse tópico, aqui existe um patch que corrige a consulta ldap do squid guard (teste em homologação) :)

http://www.pfsense-br.org/blog/2016/02/patch-corrige-consulta-ldap-do-squidguard/

abraços,

Diego

wandermaia

Obrigado pelas sugestões Diego!!!

Fiz o teste aqui, e validando apenas os grupos criados no squidGuard ele funciona maravilhosamente bem!

As versões instaladas são:
pfsense 2.2.6-RELEASE (amd64)
FreeBSD 10.1-RELEASE-p25
squid 4.3.10
squidGuard 1.9.18

Ao executar o patch, o sistema não foi alterado. Após a instalação, era para ter alterado a interface WEB (acrescentados os campos "LDAP query mode", "ldap query server in bach mode" e "ldap query base OU DN in batch mode"),
o que não ocorreu. Acrescentei a consulta de grupos conforme o descrito (por exemplo: [WEBAC1] ), porém dessa forma ele não estava reconhecendo os grupos.

Então, abri o patch diretamente no navegador e executei os comandos do script, um por um, diretamente no shell. Ao término, realizei um restart no webconfigurador e a partir dai tudo funcionou perfeitamente no ambiente de homologação.

Quando apliquei na produção, ele parece não estar funcionando corretamente. Dei um cat no arquivo squidGuard.conf e verifiquei ele utiliza um arquivo com a lista dos usuários do grupo, no caso /var/db/squidGuard.ldap/ADAC1 (por exemplo). No ambiente de testes a lista está preenchida com os usuário, mas no ambiente de produção não.

Verifiquei no cron do root e do usuário proxy, mas não encontrei onde é feita a atualização da lista de usuários. Vou continuar realizando alguns testes na parte da tarde para verificar se identifico o problema.

Obrigado pela ajuda!!!!!!

didonsom

@wandermaia:

Obrigado pelas sugestões Diego!!!

Fiz o teste aqui, e validando apenas os grupos criados no squidGuard ele funciona maravilhosamente bem!

As versões instaladas são:
pfsense 2.2.6-RELEASE (amd64)
FreeBSD 10.1-RELEASE-p25
squid 4.3.10
squidGuard 1.9.18

Ao executar o patch, o sistema não foi alterado. Após a instalação, era para ter alterado a interface WEB (acrescentados os campos "LDAP query mode", "ldap query server in bach mode" e "ldap query base OU DN in batch mode"),
o que não ocorreu. Acrescentei a consulta de grupos conforme o descrito (por exemplo: [WEBAC1] ), porém dessa forma ele não estava reconhecendo os grupos.

Então, abri o patch diretamente no navegador e executei os comandos do script, um por um, diretamente no shell. Ao término, realizei um restart no webconfigurador e a partir dai tudo funcionou perfeitamente no ambiente de homologação.

Quando apliquei na produção, ele parece não estar funcionando corretamente. Dei um cat no arquivo squidGuard.conf e verifiquei ele utiliza um arquivo com a lista dos usuários do grupo, no caso /var/db/squidGuard.ldap/ADAC1 (por exemplo). No ambiente de testes a lista está preenchida com os usuário, mas no ambiente de produção não.

Verifiquei no cron do root e do usuário proxy, mas não encontrei onde é feita a atualização da lista de usuários. Vou continuar realizando alguns testes na parte da tarde para verificar se identifico o problema.

Obrigado pela ajuda!!!!!!

O patch ldap q te mostrei realiza a consulta de 5 em 5 minutos, o que você pode fazer e rodar o comando antes, dessa forma voce forca ele… Em relação aos grupos, vc colocou ele dentro de uma UN ?

Abs

Diego

wandermaia

Diego, boa tarde!

O caminho está correto pois eles já foram criados lá. Outro ponto que serve como validação das consultas é autenticação usando apenas o squid, pois consigo autenticar e aplicar as políticas por grupo perfeitamente.

Encontrei uma coisa que pode ser a causa do problema: analisando o script, a consulta utilizada como referência para atualizar os arquivos. Ela não está no path, então o find me retornou dois locais:
[2.2.6-RELEASE][admin@SRV-PRO01.meudominio.com.br]/root: find / | grep ldapsearch
/usr/pbi/squid-amd64/local/bin/ldapsearch
/usr/pbi/squidguard-amd64/local/bin/ldapsearch
[2.2.6-RELEASE][admin@SRV-PRO01.meudominito.com.br]/root:

Quando tento executar a consulta com o que está na pasta do squidGuard, ele reclama da versão do LDAP:

[2.2.6-RELEASE][admin@SRV-PRO01.meudominito.com.br]/root: /usr/pbi/squidguard-amd64/local/bin/ldapsearch -x -h 10.131.0.7 -p 389 -b OU=PROXY,OU=USUARIOS-EXTERNOS,OU=empresa,DC=meudominito,DC=com,DC=br -D CN=adm.proxy,OU=ADMs,OU=USUARIOS-EXTERNOS,OU=empresa,DC=meudominito,DC=com,DC=br -w S3nhA.Pr0xy
LDAP vendor version mismatch: library 20443, header 20440

Mas quando executo a consulta utilizando o a versão que está na pasta do squid, ela funciona normalmente:

[2.2.6-RELEASE][admin@SRV-PRO01.meudominito.com.br]/root: /usr/pbi/squid-amd64/local/bin/ldapsearch -x -h 10.131.0.7 -p 389 -b OU=PROXY,OU=USUARIOS-EXTERNOS,OU=empresa,DC=meudominito,DC=com,DC=br -D CN=adm.proxy,OU=ADMs,OU=USUARIOS-EXTERNOS,OU=empresa,DC=meudominito,DC=com,DC=br -w S3nhA.Pr0xy

extended LDIF

LDAPv3

base <ou=proxy,ou=usuarios-externos,ou=empresa,dc=meudominito,dc=com,dc=br>with scope subtree

filter: (objectclass=*)

requesting: ALL

…

Depois disso, renomei o executável que estava apresentando problemas na versão e criei um link simbólico para o outro. Feito isso, habilitei novamente a configuração do squidGuard e verifiquei os arquivos dos grupos, que agora já contem o usuário.
Ainda não pude realizar o teste de acesso, mas assim que realizar descrevo o resultado aqui!</ou=proxy,ou=usuarios-externos,ou=empresa,dc=meudominito,dc=com,dc=br>

wandermaia

Realizei o teste aqui, mas parece que ele ainda não está conseguindo autenticar o usuário no grupo. Vou tentar reinstalar o squidGuard na produção e reconfigurar.

wandermaia

Reinstalei o squidGuard, mas ainda não consegui identificar o problema. Vou continuar testando.

Estou tendo também um outra dificuldade com ACL. preciso criar uma acl que permita acessar as redes internas pra todos os usuários. Testei algumas regras, mas não funcionaram.

A última que testei foi essa:

acl empresa dst 10.31.0.0/24 10.132.0.0/24 172.29.96.0/24 10.141.0.0/24 10.131.3.0/24;
always_direct allow empresa;

Preciso liberar o acesso para sites internos que estão nessas redes. Estou tentando criar uma espécie de whitelist para essas redes. Alguém já teve esse tipo de problema?

wandermaia

Boa tarde!

Realizei a reinstalação no ambiente de produção e uma instalação limpa com squid e SquidGuard e mesmo funcionou. O único problema foi o redirecionamento de páginas de erro, que não está funcionando. Quanto ao acesso as redes internas, existe um roteador onde estão configuradas as vpns para os outros escritórios da empresa onde estão instalados as aplicações e eu ignorava essa informação. Bastou criar as rotas para as devidas redes apontando para esse roteador e foi resolvido.

Quero agradecer a todos que me ajudaram! Essa foi minha primeira experiência com o pfsense e gostei muito do que vi. Pretendo aprofundar bastante no conhecimento desse sistema.

Valeu galera!!!
:D

Só mais uma coisinha: Como faço pra marcar como resolvido? rsrsrsrrssrs ;D