Servidor DNS (BIND9) – Integração Perfeita com o GOsa

1. Introdução

O servidor DNS é utilizado para resolver nomes de computadores, ou seja, toda vez que chega uma requisição com um nome (ex: www.nisled.org), ele o transforma em um endereço IP. O servidor DNS é a base da Internet. Para uma compreensão mais ampla, imagine a Internet sem o servidor DNS: tudo funcionaria sem problemas; no entanto, imagine que, ao invés de acessar os sites pelos nomes (www.uol.com.br, www.estadao.com.br, www.nisled.org, etc.), você teria que decorar o endereço IP dos servidores para poder acessá-los!

Se decorar número de telefone já é difícil, imagine decorar IPs.

Normalmente, o DNS mantém suas informações numa lista gravada num arquivo de texto simples. No entanto, ao estudar a sua estrutura, descobrimos que ele trabalha em forma de árvore. Portanto, é possível diminuir as despesas gerais de administração (gerenciamento dos domínios) guardando os dados do DNS em forma de árvore; a estrutura geral do OpenLDAP já contribui para isso.

Outro fator que contribui para o uso do OpenLDAP é o fato dos servidores DNS necessitarem de uma replicação de dados para o DNS secundário. Como esse serviço já vem implementado no OpenLDAP, torna-se muito mais fácil a sua implementação. Os requisitos de segurança para a replicação são satisfeitos pelo OpenLDAP, o que nem sempre acontece com os servidores DNS.

Vamos começar esse artigo, descrevendo como criar a estrutura do DNS dentro do LDAP com ajuda do GOsa. Neste artigo vamos utilizar como exemplo o domínio "curso.ldap" e o ip do servidor 192.168.0.1.

2. GOsa

O ambiente GOsa é uma poderosa ferramenta de gerenciamento de recursos de rede no LDAP, e como não poderia ser diferente, ele tem suporte para gerenciar as entradas para o servidor dns BIND.

Para começar a criar as entredas para o BIND, entre no ambiente GOsa e logo em seguida click no ícone "Systems" como mostra a figura 1.

Figura 1 – Ambiente central do GOsa

Ao entrar no "Systems" será mostrada todos os componentes cadastrados, caso existem. Na parte superior da tela temos as lista de sistemas que podem ser cadastrados. Escolha criar um novo servidor como mostra a figura 2.

Figura 2 – Lista de Sistemas

Ao entrar na tela para criar um novo servidor, automaticamente abrirá a aba "Generic". Nela devem ser preenchidos os campos "Server name" e o endereço de IP e MAC. Esses dados não são utilizados pelo DNS, apenas para cadastrar o servidor. A figura 3 mostra o cadastro desta tela.

Figura 3 – Cadastro do servidor

Após o cadastro dos dados na primeira aba, click na aba "DNS" para criar uma nova zona de DNS. Para isso click no botão "Add", como mostra a figura 4.

Figura 4 – Criação de uma zona de DNS

Para adicionar uma nova zona, preencha os dados de acordo com o domínio desejado. O campo "zone name" define o domínio que será criado. Também defina o endereço de rede e a mascara da rede. Os campo da área "SOA record" definem o cabeçalho do servidor dns, por isso preencha os campos "Primary dns Server for this zone" com o nome do servidor dns, como mostra a figura 5. Lembre-se de resolver esse nome no arquivo /etc/hosts do servidor dns. Também preencha os campos de email. Na área "MxRecords" registre os servidores de email deste domínio. Para editar os computadores deste domínio é necessário primeiramente salvar a zone para o botão "Zone records" habilitar.

Figura 5 – Criação da zona

Após salvar o registro da zona, aba novamente que o botão "Edit" estará habilitado e com ele podemos cadastrar os computadores do domínio, como mostra a figura 6.

Figura 6 – Criação das maquinas domínio

3. BIND9

Com a criação do domínio no GOsa, vamos passar para a instalação do servidor dns. Será utilizado o pacote pré-compilado para o servidor Ubuntu.

# apt-get install bind9

O próximo passo é a configuração da zona no bind9. Para isso altere o arquivo /etc/bind/named.conf acrescentando as seguintes linhas.

zone "curso.ldap" {
type master;
file "/etc/bind/db.curso.ldap";
};

zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/rec.curso.ldap";
};

O próximo passo é criar os arquivos db.curso.ldap e o arquivo rec.curso.ldap. Esses arquivos são criados através de um script que exporta as informações do LDAP (GOsa).

4. ldap2zone

Utilizaremos o script ldap2zone para exportar os registros da base LDAP. Esse script foi escrito com a linguagem de C, portanto é preciso compilá-lo. Para realizar essa tarefa entre no diretório /usr/local/src, e faça download do script.

# cd /usr/local/src
# wget www.venaas.no/dns/ldap2zone/ldap2zone.c

Antes de começar a compilar os fontes do script, instale os pré-requisitos que são as bibliotecas do LDAP e os compiladores.

# apt-get install libc6-dev gcc libldap2-dev

A compilação do script de exportação é bem simples. Segue o passo para a compilação.

# gcc -o ldap2zone -lldap -llber ldap2zone.c

Após a compilação mova o arquivo binário compilado para o diretório /usr/local/bin.

# mv ldap2zone /usr/local/bin

Agora com o script compilado, vamos realizar alguns testes para verificar se exportação está sendo corretamente.

Primeiro vamos exportar o db.

# ldap2zone curso.ldap. ldap://192.168.0.10 604800
$TTL 604800
@ IN SOA ns1.curso.ldap. clodonil.nisled.org. (
2009080904 ; Serialnumber
3600 ; Refresh
1800 ; Retry
720000 ; Expire
6400 ) ; Minimum TTL

NS ns1.curso.ldap.
MX 0 mail.curso.ldap.
MX 1 server.curso.ldap.
www 7440 A 192.168.0.1
mail 7440 A 192.168.0.1
server 7440 A 192.168.0.1
ns1 7440 A 192.168.0.1

Como pode ver a exportação foi feita corretamente, também vamos testar a exportação do reverso.

# ldap2zone 0.168.192.in-addr.arpa ldap://192.168.0.10 604800
$TTL 604800
@ IN SOA ns1.curso.ldap. clodonil.nisled.org. (
2009080904 ; Serialnumber
3600 ; Refresh
1800 ; Retry
720000 ; Expire
6400 ) ; Minimum TTL
NS ns1.curso.ldap.
MX 0 mail.curso.ldap.
MX 1 server.curso.ldap.
1 7440 PTR www.curso.ldap.
7440 PTR mail.curso.ldap.
7440 PTR server.curso.ldap.
7440 PTR ns1.curso.ldap.

Para tornar a tarefa de exportação mais automatizada, vamos criar um script para exportar as entradas do LDAP e criar os respectivos arquivos. Segue o script.

#!/bin/bash

ldap2zone 0.168.192.in-addr.arpa ldap://192.168.0.10 604800 > /etc/bind/rev.curso.ldap
ldap2zone curso.ldap. ldap://192.168.0.10 604800 > /etc/bind/db.curso.ldap

Para não precisar ficar executando o script toda vez que fizer uma alteração pelo GOsa, vamos colocar o script no crontab e pedir para executar em 5 em 5 minutos.

*/5 * * * * /usr/local/bin/dns.sh

5. Teste

Para realizar os testes que precisamos, vamos alterar primeiramente reiniciar o servidor DNS.

# /etc/init.d/bind9 restart

O próximo passo é alterar o arquivo /etc/resolv.conf, e apontar para o servidor DNS que acabamos de configurar.

nameserver 192.168.0.1

Em seguida utilize o comando ping para verificar se o servidor tá "resolvendo" o nome pesquisa.

# ping www.curso.ldap
PING www.curso.ldap (192.168.0.1) 56(84) bytes of data.
64 bytes from nucleo.local (192.168.0.1): icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from nucleo.local (192.168.0.1): icmp_seq=2 ttl=64 time=0.054 ms
64 bytes from nucleo.local (192.168.0.1): icmp_seq=3 ttl=64 time=0.056 ms

Conforme o resultado apresentado pelo comando ping, o servidor DNS tá funcionando corretamente.

6. Troubleshooting

• Verifique se os arquivos db e rev estão sendo gerados pelos scripts;
• Verifique os logs do bind9 (tail –f /var/log/daemon)
• No GOsa verifique se colocou ponto (.) no final dos nomes definidos como servidor de e-mail.

Proxy SQUID – Integração Perfeita com o GOsa

Squid com LDAP e controles de Sites por grupos e Quotas

Proxy é o elemento responsável pela ligação da rede interna do cliente com a rede externa, a internet. Quando o cliente da rede interna tenta acessar a Internet, ele solicita o acesso ao proxy. Este, por sua vez, acessa o conteúdo desejado e devolve-o para o cliente. Dessa forma, o cliente não tem acesso direto à Internet, o que constitui uma vantagem do ponto de vista da segurança.

Quando falo que é uma vantagem o cliente não ter acesso direto à Internet, significa que ele não pode utilizar ferramentas maliciosas contra outros hosts, em portas aleatórias. Um exemplo disso seria rodar um scanner ou tentar invadir um computador em outra porta que não seja a 80, que é utilizado para navegação.

Perceba que, neste caso, a preocupação é o cliente da rede interna tentar invadir alguma máquina na Internet. Lembre-se que a responsabilidade do que acontece na rede é do administrador da rede e, caso aconteça algum ataque a um host externo, este irá responsabilizar o administrador da rede na qual o invasor (usuário) estiver trabalhando.

Outra vantagem de instalar um Proxy é pelo recurso de cachê que normalmente acompanha o proxy. O cachê permite o armazenamento de sites dentro da rede interna. Ao usuário solicitar um site, o proxy verifica se o mesma encontra-se no cachê, e envia para o usuário sem precisar pesquisar na internet.

Para integração com o LDAP, vamos utilizar o Proxy SQUID que é um dos "open source" mais utilizado.

Instalação

A instalação do SQUID no Ubuntu Serve e Debian é simples é rápido. O comando "apt-get" faz a instalação.

[root@cabeca]# apt-get install squid3

Com a instalação feita, vamos passar para a configuração do SQUID. O arquivo de configuração é o squid.conf. Como ponto de partida, será adotado um squid.conf modelo. Este arquivo é funcional, porém exclui uma série de recursos que não será abordado neste documento. Para acrescer recursos no SQUID e fazer ajustes de outras configurações, é recomendável consultar a documentação no site oficial.

Crie um arquivo no diretório /etc/squid, chamado squid.conf e coloque a configuração do squid. Esta configuração tem algumas particularidades que vale a pena marcar.

• Porta 3128: Porta que o squid aceita as configurações, configure o proxy no browser com este ip.
• Acl rede src 10.0.0.0/24: Define a faixa de ip que corresponde à rede interna. Normalmente esta configuração é feita para permitir o acesso na internet da rede interna.
• Cachê_dir: Define o diretório que ficarão os cachês
• cache_effective_user: Define o usuário do squid.

Segue o arquivo squid.conf modelo:

• /etc/squid3/squid.conf

acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost

#Liberando a Rede Local
acl rede src 10.0.0.0/24
http_access allow rede
http_access deny all
icp_access deny all
htcp_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
cache_dir ufs /var/spool/squid3 100 16 256
access_log /var/log/squid3/access.log squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern (cgi-bin|\?) 0 0% 0
refresh_pattern . 0 20% 4320
cache_effective_user proxy
cache_effective_group proxy

Antes de prosseguir, teste se o SQUID está funcionando corretamente.

Cenário 1

Com o SQUID básico funcionando, vamos adotar o cenário 1 como teste. Neste cenário vamos considerar que é necessário apenas o controle do usuário por autenticação. Cada usuário que desejar acessar a Internet, obrigatoriamente utilizará um login e uma senha. As políticas de acesso a sites podem ser feitas utilizado como regras todos os usuário. Neste caso não temos recursos para gerenciar políticas de acessos para grupos específicos de usuários.

Lembrando que os usuários já tem que estar criado no GOsa, vamos acrescentar as seguintes linhas no squid.conf.

#Autenticador
#Acrescente as 4 linhas abaixo no início do arquivo squid.conf
auth_param basic program /usr/lib/squid3/squid_ldap_auth -D "cn=manager,dc=trigo" -w x -b ou=people,dc=trigo -h servidor_ldap -p 389 -v 3 -f "uid=%s"
auth_param basic children 5
auth_param basic realm ACESSO A INTERNO DO DOMINIO BACULO
auth_param basic credentialsttl 2 hours

#Acrescente as duas linhas abaixo logo após a regra "http_access allow rede"
acl autenticacao proxy_auth REQUIRED
http_access allow autenticacao

squid.conf completo com autenticação de usuário.
auth_param: Este parâmetro ajusta a forma de autenticação, que em nosso caso é o OpenLDAP. Portanto altere conforme as suas configurações. Observe os parâmetros –D que define o administrador base LDAP, a opção –w que define a senha, a opção –b que define a sub-arvore que será pesquisa.

As outras linhas do auth_param definem na sequência:

• O Número de processos filhos que o SQUID vai abrir para receber as autenticações;
• Uma mensagem que vai aparecer na tela de autenticação do cliente; e
• Tempo que autenticação vai ser válida.

As últimas duas linhas são propriamente ditas à autenticação e permissão para navegação dos usuários autenticados.

Cenário 2

Com o cenário 1 funcionando, vamos passar para o cenário 2. Neste cenário vamos considerar que é necessário apenas o controle por grupos de usuários. Dessa forma podemos criar grupos e definir o que cada grupo pode acessar definindo assim uma política mais eficiente para controlar os usuários. Nesse cenário os usuários ainda continuam obrigatoriamente utilizando um login e uma senha para acessar a Internet, porém as políticas não são definidas por usuários individualmente.

Como exemplo. Vamos utilizar dois grupos, sendo compras e financeiro. Os usuários do grupo compras têm que acessar várias sites, já o grupo financeiro só deve acessar o site da empresa. A seguir segue as configurações para este cenário.

Lembrando que os usuários e os grupos já tem que estar criado no GOsa, como mostra a figura 1 e 2, vamos acrescentar as seguintes linhas no squid.conf.

Figura 1 – Grupo no Gosa

Figura 2 – Criação de grupos no Gosa

Com os grupos criados e usuários definidos, vamos configurar o squid.conf.

external_acl_type ldap_group %LOGIN /usr/lib/squid/squid_ldap_group -d -b "ou=groups,dc=clodonil,dc=trigo" -B "ou=users,dc=clodonil,dc=trigo" -f "(&(memberUid=%u)(cn=%g))" -p 389 -v3 -H ldap://localhost -D cn=Manager,dc=clodonil,dc=trigo -w x

acl senha proxy_auth REQUIRED
acl financeiro external ldap_group financeiro
acl compras external ldap_group compras
acl tudo dst 0.0.0.0/0.0.0.0

#Crie o arquivo sites_financieiro e coloque dentro os sites que serão liberados ou os sites que
#serão negados. Lembrando que dentro do arquivo ou todos os sites serão negados ou todos
#serão permitidos.

acl sites_financeiro dstdomain -i "/etc/squid/sites_financeiro"
acl sites_compras dstdomain -i "/etc/squid/sites_compras"  

http_access allow sites_financeiro financeiro
http_access allow !sites_compras compras

Percebe a linha "http_access allow !sites_compras compras", mas especificamente na !sites_compras que funciona como uma negação, dessa forma apenas os sites cadastrados no arquivo sites_compras NÃO poderam ser acessadas.

segue o squid.conf completo para autenticação de grupo.

Para finalizar teste no browser.

Cenário 3

Até este momento, mostramos como configurar o SQUID com autenticação por usuário e por grupo do LDAP criado pelo GOsa. O GOsa também tem a opção do SQUID na aba "Connectivity" que possibilita filtrar sites, limitar acesso a internet por tempo determinado ou por quota, como mostra a figura 03.

Figura 03 – Aba Connectivity do GOsa

Para fazer essas opções funcionarem é necessário utilizar os scripts que estão no diretório /usr/share/gosa/contrib/scripts que vem juntamente com a instalação do GOsa.

Uma breve descrição de cada script:

• goAgent.pl

Não é necessário para o SQUID, pode ser utilizado para criar o home do usuário.

• goQuota.pl

Esse script consulta o atributo quota no servidor LDAP e cria um banco de dados com essas quotas para uma leitura rápida pelo SQUID. O ideal é colocar esse script no crontab para ser executado de tempo em tempo para ativa mudanças feitas pelo GOsa.

• goQuotaView.pl

Permite visualizar a quota de um usuário no console, desde que o DB seja criado pelo script "goQuota.pl".

Nota: No script, comente a linha abaixo.

forma:

#time2str("%d.%m.%Y %H:%M:%S",$cache{TIMESTAMP}),

• goSquid.pl

Neste script é feito o redirecionamento para uma página caso a quota em MB seja excedido. Esse script verifica o tempo de navegação e o DB criado pelo "goQuota.pl".

Existe outros scripts que faz a censura de uma lista de sites, mas esse script não tem funcionando. Cada um desses scripts precisa ser editado para alguns ajustes, tais como os dados do servidor LDAP.

Como exemplo de como deve ser editado os scripts, vamos editar o goQuota.pl. A edição do script sempre estão na primeiras linhas

A alteração deve ser algo como:

my $LDAP_HOST = "servidor.trigo" ;
my $LDAP_PORT = "389";
my $LDAP_BASE = "ou=people,dc=trigo";

Todos os scripts foram feitos usando a linguagem Perl, por isso precisamos instalar o pacote de conexão entre o Perl e o LDAP. No ubuntu e debian, basta instalar o seguinte pacote:

# apt-get install libnet-ldap-perl

Para continuar a configuração, copie os scripts para o diretório /etc/gosa e adicione a seguinte linha no squid.conf

redirect_program /etc/squid/gosa/goSquid.pl
redirect_children 5

Essa linha verifica a base de dados criado pelo script "goQuota.pl" e quando a quota excede ele redireciona para um link definido no script.

Lembre-se de colocar o goQuota.pl no crontab.