sexta-feira, 16 de outubro de 2015

TACACS+ na Autenticação Centralizada de Dispositivos Cisco

Olá Pessoal.

A autenticação de usuários em dispositivos Cisco pode ser realizada através de uma base local de usuários que fica distribuída em cada uma das caixas ou através de uma base centralizada na rede via servidor TACACS+ (Terminal Access Controller Access Control System Plus). O TACACS+ é um protocolo de segurança utilizado para controlar os usuários que tentam se autenticar em roteadores ou switches da Cisco (e de outros fabricantes). Ao acessar uma caixa da rede, o usuário é conectado previamente a um servidor centralizado para fins de identificação e autorização das credenciais. Se autorizado, então o servidor TACACS+ encaminha as informações de login para a caixa remota que solicitou a autenticação.

A solução comercial oficialmente recomendada pela Cisco que implementa as funcionalidades de um servidor TACACS+ é o Cisco Secure Access Control System (ACS). Uma alternativa gratuita e que pode ser instalada no Linux é a ferramenta TAC_Plus (pacote tacacs+ no Debian). Neste artigo irei detalhar os passos necessários para configurar um servidor TACACS+ no Linux Debian e também como configurar as caixas Cisco para que o processo de autenticação seja centralizado através da comunicação com o servidor. A topologia proposta é bastante simples e pode ser observada na figura abaixo, sendo que o laboratório pode ser reproduzido no GNS3 em conjunto com o VirtualBox.


A primeira etapa consiste na instalação do pacote tacacs+ para que o Linux Debian possa ser posteriormente configurado como servidor TACACS+ na rede. Essa tarefa é simples através do APT.

root@tacacs:/# apt-get install tacacs+

Depois de instalado o pacote tacacs+, o arquivo de configuração principal do servidor TACACS+ fica armazenado em /etc/tacacs+/tac_plus.conf. Nas configurações abaixo definiremos uma chave de verificação do servidor denominada "CHAVE" e criaremos dois perfis, sendo um com privilégio administrativo de nível 15 (grupo "admin") e outro com privilégio de execução de nível 7 (grupo "user"). Na sequência, criaremos o usuário "shbbrito" no grupo "admin" e definiremos sua senha que deve ser informada de maneira cifrada. 

###--- em /etc/tacacs+/tac_plus.conf

accounting file = /var/log/tac_plus.acct

key = "CHAVE"

group = "admin"
{
  default service = permit
service = exec
{
priv-lvl = 15
idletime = 10
timeout  = 60
}
}

group = "user"
{
default service = deny
service = exec
{
priv-lvl = 7
idletime = 10
timeout  = 30
}
}

user = "shbbrito"
{
name = "Samuel Henrique Bucke Brito"
member = "admin"
login = des "1oV3QcqhpSN2w"
}


Obs.: Para gerar a senha cifrada pode ser utilizado o aplicativo tac_pwd. Ao digitar tac_pwd no shell, será necessário informar a senha para que o aplicativo possa fazer a cifragem e trazer seu resultado na tela. Neste exemplo, utilizamos a senha "SENHA" que equivale a "1oV3QcqhpSN2w".

Feito isso o servidor TACACS+ já está devidamente configurado no Linux Debian.
Para inicializar o serviço, basta digitar:

root@tacacs:/# service tacacs_plus start
[ OK ] tacacs_plus.service: TACACS+ authentication daemon

Agora que o servidor TACACS+ está operacional na rede, as caixas Cisco (roteadores e switches) devem ser configuradas para fazer a autenticação via TACACS+. Essa configuração é rápida e os comandos necessários para fazê-lo são listados abaixo, com destaque em amarelo para as informações do IP do servidor e a respectiva key que configuramos anteriormente.

Roteador(config)# aaa new-model
Roteador(config)# aaa authentication login default group tacacs+ local
Roteador(config)# aaa authorization exec default group tacacs+ local
Roteador(config)# tacacs-server host 192.168.221.1
Roteador(config)# tacacs-server key CHAVE

Façam seus testes...

Samuel.

segunda-feira, 12 de outubro de 2015

Servidores DHCP Redundantes em Dispositivos Cisco

Olá Pessoal.

Uma prática útil para prover redundância no serviço de configuração automática de endereços IP é a inserção de um servidor DHCP adicional na rede que possa garantir a disponibilidade do serviço mesmo em caso de queda do servidor principal, além de dividir a carga de trabalho.

Basicamente essa tarefa pode ser implementada de duas maneiras: (a) através da divisão manual dos escopos configurados nos dois servidores DHCP, de maneira que os endereços providos por um servidor não conflitem com os endereços providos pelo outro; (b) através do protocolo DHCP Failover que viabiliza a coordenação das ações de ambos os servidores, feature suportada pelo ISC-DHCP no Linux Debian e também a partir do Windows Server 2012.

O método manual é suportado em qualquer caixa ou Sistema Operacional por ser o mais simples e não envolver nenhum protocolo específico, no entanto não há uma coordenação das atividades dos dois servidores, de maneira que as tabelas de leases dos dois servidores são totalmente independentes, o que não permite gerenciamento centralizado dos leases ou manutenção das reservas em caso de queda de um dos servidores. Apesar dessas limitações, ainda assim trata-se de uma opção muito comum e funcional para assegurar a disponibilidade do serviço de configuração automática de IPs.

Pois bem, neste breve artigo trago um exemplo bastante simples de configuração de dois roteadores Cisco (poderiam ser switches). Na figura abaixo existem dois roteadores que fazem parte de um grupo HSRP e que respondem pelo IP Virtual 192.168.0.10 (gateway).  Na figura abaixo o leitor pode observar a configuração de ambos os roteadores como servidor DHCP.



Em cada roteador foi definido um escopo denominado ESCOPO para distribuição de endreços na rede 192.168.0.0/24. No roteador DHCP-SRV1 excluímos a faixa inicial dos primeiros dez endereços para fins de atribuição estática e toda a segunda metade dos endereços da rede (de 192.168.0.129 até 192.168.0.254), ou seja, ele irá distribuir endereços que variam de 192.168.0.11 até 192.168.0.128. No roteador DHCP-SRV2 fizemos o processo inverso, ou seja, excluímos toda a primeira metade dos endereços da rede (de 192.168.0.1 até 192.168.0.128). Ao fazer isso, eliminamos qualquer possibilidade de conflito na distribuição de endereços a partir dos dois servidores DHCP presentes na rede.

Obs.: Aqueles interessados na tecnologia HSRP podem recorrer ao Laboratório 26 da segunda edição do livro Laboratórios de Tecnologias Cisco em Infraestrutura de Redes, que traz um exemplo de configuração de Alta Disponibilidade em Cluster de Roteadores.

Façam seus testes...

Samuel.

domingo, 4 de outubro de 2015

Anúncio de Servidores DNS em Roteadores Linux (RDNSS)

Olá Pessoal.

Vamos a uma dica rápida sobre a autoconfiguração SLAAC do IPv6...

Recentemente escrevi um artigo intitulado "Anúncio de Prefixos IPv6 em Roteadores Linux" explicando o processo de instalação do pacote RADVD no Linux para fazer o anúncio dos prefixos IPv6 para toda uma rede local (link) através da autoconfiguração de endereços denominada SLAAC. No Linux o RADVD permite o envio periódico das mensagens ICMPv6 Tipo 134 (RA) para todos os clientes através do endereço ff02::1 (multicast-all-nodes) com o anúncio dos prefixos configurados.

Ocorre que uma limitação bastante reconhecida da autoconfiguração SLAAC é que ela originalmente permitia apenas a autoconfiguração do prefixo da rede e do endereço de gateway (fe80 do roteador responsável pelos anúncios RA). De fato um recurso muito interessante, mas pouco útil na prática por não permitir a configuração de um ou mais endereços de servidores DNS para fazer a resolução de nomes no contexto da Internet. 

Essa limitação foi solucionada e revisada em 2010 com a publicação da RFC 6106, oportunidade em que o daemon RADVD do Linux passou a oferecer suporte à configuração de parâmetros adicionais que permitem anunciar também, além do prefixo e gateway, um ou mais servidores DNS para os clientes autoconfiguradores via SLAAC. A configuração em si é bastante simples, bastando adicionar a declaração de um bloco RDNSS (Recursive DNS Server) no arquivo de configuração /etc/radvd.conf, conforme observado na figura abaixo. Também pode ser declarado um bloco DNSSL (DNS Search List) para informar aos clientes o sufixo do domínio.


Agora sim a autoconfiguração SLAAC se torna mais atrativa no IPv6!
Façam seus testes...

Samuel.