UNIVERSIDADE FEDERAL DE SANTA CATARINA
Desenvolvimento de um ambiente de gerenciamento centralizado
para autenticação, autorização e auditoria em um cenário de rede
heterogênea
Luís Fernando Cordeiro
Florianópolis – SC
2012/2
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE SISTEMAS DE INFORMAÇÃO
Desenvolvimento de um ambiente de gerenciamento centralizado
para autenticação, autorização e auditoria em um cenário de rede
heterogênea
Luís Fernando Cordeiro
07238071
Florianópolis – SC
2012/2
Trabalho de conclusão de curso
apresentado como parte dos
requisitos para a obtenção do
grau de Bacharel em Sistemas
de Informação.
Luís Fernando Cordeiro
Desenvolvimento de um ambiente de gerenciamento centralizado
para autenticação, autorização e auditoria em um cenário de rede
heterogênea
Trabalho de conclusão de curso apresentado como parte dos requisitos para
obtenção do grau de Bacharel em Sistemas de Informação.
__________________________________________________
Profa. Dra. Carla Merkle Westphall
Orientadora
__________________________________________________
Prof. Dr. Carlos Becker Westphall
__________________________________________________
Edison Tadeu Lopes Melo
Resumo
O presente trabalho de conclusão de curso possui como tema o estudo, o
desenvolvimento e a implantação de um sistema de autenticação centralizado para
equipamentos de rede, utilizando como base tecnologias padronizadas e livres. Ao
longo do trabalho, são apresentadas as análises realizadas sobre os principais
protocolos que envolvem as áreas de Autenticação, Autorização e Contabilização
(AAA) (METZ,1999), como RADIUS (IETF 2865, 2000) e TACACS+ (METZ,1999).
Além da parte teórica, foram desenvolvidas duas aplicações, uma para suporte e
outra para a gerência do ambiente. Foram realizados ainda testes com uma
aplicação já consolidada no mercado, a qual se mostrou muito completa mas pouco
adaptável a ambientes de rede heterogêneas. Por fim, denota-se do estudo da nova
estrutura que além de suportar uma variedade maior de equipamentos, é possível
customizar ainda mais o ambiente e expandir o seu uso para computadores
pessoais e servidores, sendo eles Windows ou Linux, o que será indicado como
trabalhos futuros.
Palavras-chave:
openLDAP, TACACS+, AAA, Gerenciamento de
Identidades.
Lista de Figuras
Figura 1 - Modo de Autenticação de Três Partes. Fonte: Todorov (2007) ... 15
Figura 2 - Troca de mensagens usando RADIUS. Fonte: CISCO (2008) ... 18
Figura 3 - Troca de mensagens usando TACACS+. Fonte: CISCO (2008) ... 19
Figura 4 - Comparação entre o X.500 e o LDAP ... 24
Figura 5 - Exemplo de uma árvore de diretório LDAP ... 25
Figura 6 - Exemplo dos atributos de um objeto ... 26
Figura 7 - Processo de autenticação atual ... 30
Figura 8 - Arquitetura do ambiente proposto ... 32
Figura 9 - Infraestrutura de rede dos servidores ... 34
Figura 10 - Fluxo dos dados no ambiente proposto ... 36
Figura 11 - Exemplo de Configuração de usuários no tac_plus ... 40
Figura 12 - Exemplo de uma entrada LDAP com suporte ao TAC_PLUS MAVIS .... 43
Figura 13 - Exemplo de configuração de níveis de privilégios ... 44
Figura 14 - Exemplo de configurações de grupos de equipamentos ... 45
Figura 15 - Definições de especificações de tempo e ACLs ... 46
Figura 16 - Roteador Cisco 7606 ... 49
Figura 17 - Switch 3Com 5500G ... 49
Figura 18 - D-Link DGS 3100 PoE ... 50
Figura 19 - Cisco WLC 5500 ... 51
Figura 20 - Interface de Logs - logs de comandos ... 53
Figura 21 – Interface de Logs - logs de acessos ... 54
Figura 22 - Interface de Logs - logs de acessos 2 ... 55
Figura 23 - Interface de gerência - visão inicial ... 56
Figura 24 - Interface de gerência - acompanhamento de comandos ... 57
Figura 25 - Interface de gerência - adicionar usuário ... 58
Lista de Abreviaturas
TACACS – Terminal Access Controller Access-Control System
RADIUS – Remote Authentication Dial in User Service
LDAP – Lightweight Directory Access Protocol
IEEE – Institute of Eletrical and Eletronics Engineers
AAA – Authentication, Authorization and Accounting
ISP – Internet Service Provider
NAS – Network Access Server
PAP – Password Authentication Protocol
Sumário
1. Introdução ... 7
1.1 Objetivo ... 9
1.1.1 Objetivo Geral ... 9
1.1.2 Objetivos Específicos ... 9
1.2 Justificativa ... 10
1.3 Organização do Trabalho ... 10
2. Conceitos Básicos ... 11
2.1 Autenticação, Autorização e Contabilização (AAA) ... 12
2.1.1 Autenticação ... 13
2.1.2 Autorização ... 15
2.1.3 Contabilização ... 16
2.2 Protocolos de Autenticação para equipamentos ... 17
2.2.1 RADIUS ... 17
2.2.2 TACACS+ ... 18
2.2.3 Diferenças entre RADIUS e TACACS+ ... 20
3. Tecnologias ... 22
3.1 openLDAP ... 23
3.2 TAC_PLUS ... 27
3.3 MAVIS ... 27
4. Estudo de Caso – Rede UFSC ... 29
4.1 Projeto ... 29
4.1.1 Cenário Atual ... 29
4.1.2 Cenário Proposto ... 31
4.2. Desenvolvimento ... 36
4.2.1 Cisco ACS ... 37
4.2.2 TAC_PLUS ... 39
4.3. Implantação ... 48
4.3.1 Estrutura Física ... 48
4.3.2 Implantação em Números ... 51
4.3.3 Gerência do Ambiente ... 52
4.3.4 Adequação com normas de segurança ... 60
5. Considerações Finais ... 62
5.1 Trabalhos Futuros ... 63
Referências ... 65
1. Introdução
Com o crescente número de usuários da rede UFSC, os equipamentos de
rede estão em constante mudança, seja por melhoria da infraestrutura, seja pelas
novas configurações que lhes são aplicadas.
Com esse quadro de modernização, esses equipamentos ganharam suporte a
novos protocolos, dentre os quais estão alguns que são usados para a gerência de
identidades de usuários, como o TACACS+ (METZ, 1999) e o RADIUS (IETF 2865,
2000).
Assim, é importante a utilização mais adequada das ferramentas baseadas
nos protocolos TACACS+ e RADIUS, a fim de aproveitar todas as vantagens
oferecidas, bem como permitir uma gerência mais segura dos ativos de rede.
Em um ambiente tão crítico e complexo como o de gerência da rede UFSC,
onde um comando errado pode acarretar em problemas de conectividade para
usuários e serviços, é preciso ter o maior controle possível do que é feito e por quem
é feito.
Para tanto, verifica-se a necessidade do uso de uma aplicação que realize o
gerenciamento das identidades dos usuários, para garantir que cada pessoa com
acesso ao equipamento faça apenas o que lhe é permitido e não tenha acesso total,
como acontece normalmente.
Tendo por base situações como esta, foi proposto um framework estrutural
que provê um conjunto de três funções de segurança, o AAA (Authentication,
Authorization e Accounting) (METZ, 1999). Baseado nesse framework, é possível
definir quem terá acesso (Autenticação), quais as ações que poderão ser feitas
depois de sua autenticação (Autorização), o horário que estas ações podem ser
feitas, bem como a geração de todos os logs das ações efetuadas para fins de uma
possível auditoria (Contabilização).
O presente trabalho é fundamentado nesse framework e no problema da
ausência de controle no atual ambiente de gerência da rede UFSC, que é apenas
usado nos roteadores, a fim de propor uma solução que poderá ser aproveitada para
uma variedade maior de equipamentos, desde que tenham suporte ao protocolo
TACACS+, possibilitando, assim, que o AAA seja utilizado, quando possível.
Outras questões muito importantes que envolvem a estrutura em análise diz
respeito à criticidade da aplicação, já que o acesso à gerência dos equipamentos
estará diretamente relacionada com o bom funcionamento dos servidores, à
carência de redundância dos serviços, para que, caso aconteça algum problema
com um servidor, ter um outro no mesmo estado para assumir os serviços, e à falta
de uma gerência proativa do ambiente, o que pode gerar contratempos caso
aconteçam problemas de um processo parar ou o disco encher e o administrador
não ser avisado, por exemplo.
Este trabalho tem por objeto realizar o estudo das principais tecnologias de
autenticação para equipamentos de rede, analisando seus funcionamentos e
características. Também será desenvolvida uma interface Web para a gerência do
ambiente e visualização dos logs dos usuários.
1.1 Objetivo
1.1.1 Objetivo Geral
O objetivo geral deste trabalho é projetar, desenvolver e implantar um
ambiente de autenticação centralizada para os administradores/operadores da rede
UFSC, construindo um ambiente com alta disponibilidade, diante da criticidade da
aplicação, e com segurança na troca de informações. Pretende-se utilizar apenas
implementações livres de tecnologias padrões como o OpenLDAP (BUTCHER,
2007) e o TAC_PLUS (HUBBER, 2011), que são alternativas a softwares
proprietários de empresas como Microsoft e Cisco, respectivamente.
1.1.2 Objetivos Específicos
Os objetivos específicos que podem ser citados neste trabalho são:
• Estudar o framework estrutural AAA;
• Estudar os protocolos RADIUS, TACACS+ e LDAP;
• Desenvolver uma interface web para a gerência do ambiente, cadastro de
novos usuários, grupos e equipamentos;
• Gerar alertas de status dos serviços associados com o ambiente (gerência
proativa);
1.2 Justificativa
A rede UFSC está em pleno crescimento, tanto de usuários quanto de
equipamentos e serviços. Gerenciar todos esses equipamentos, sem um controle
rigoroso, tanto de acesso, quanto de modificações, pode ser um grande problema.
Um outro problema que é enfrentado pelos administradores é que são
contratados estagiários para ajudar na gerência e melhoria da infraestrutura da rede,
e estes, quando acaba o período de estágio, conhecem todas as senhas de acesso
aos equipamentos. Existem outros mecanismo de bloqueio de acesso de fora da
rede de gerência, mas mesmo assim é um ponto de falha gravíssimo alguém
externo à organização ter as credenciais para acesso aos equipamentos.
Além disso, a universidade cada vez mais é cobrada pela Controladoria Geral
da União para melhorar suas práticas de gestão de recursos de Tecnologia da
Informação baseando-se por exemplo, na ISO/IEC 27001 (ABNT, 2006).
Percebendo estas necessidades, este estudo tem como objetivos pesquisar,
desenvolver e implantar um ambiente onde problemas como os citados não
ocorram, utilizando tecnologias livres.
1.3 Organização do Trabalho
Este trabalho está dividido em cinco capítulos. O capítulo 2 se refere as
fundamentações teóricas sobre os conceitos básicos de AAA, RADIUS e TACACS+.
No capítulo 3 serão descritas as principais tecnologias utilizadas durante o estudo e
implementação do novo ambiente. O capítulo 4 confronta o cenário atual com o
proposto, justificando a implementação do novo sistema. Apresenta os resultados
obtidos com o novo ambiente, bem como as principais configurações necessárias
para o seu funcionamento. Por fim, no capítulo 5, serão apresentadas as
considerações finais e sugestões para trabalhos futuros.
2. Conceitos Básicos
Este capítulo tem o objetivo de descrever conceitos sobre os protocolos e
tecnologias referentes ao tema de autorização, autenticação e contabilização,
auxiliando no entendimento dos estudos realizados.
De acordo com TODOROV (2007), as informações são ativos importantes das
organizações e pessoas. A divulgação, modificação imprópria ou indisponibilidade
das informações podem gerar grandes prejuízos para a organização ou ao indivíduo.
Um ativo de informação é uma parte atômica que tem significado para o indivíduo ou
à organização, de modo que cada entidade, dentro de suas possibilidades, tenta
proteger essas informações.
Ambas as entidades tem tipicamente três requisitos para a proteção de ativos
de informação, que de acordo com a ISO/IEC 27001 (ABNT, 2006) são:
• Confidencialidade – Propriedade de que a informação não esteja
disponível ou revelada a indivíduos, entidades ou processos não
autorizados;
• Integridade – Propriedade de salvaguarda da exatidão e completeza de
ativos;
• Disponibilidade – Propriedade de estar acessível e utilizável sob
demanda por uma entidade autorizada.
Na linha de evolução da segurança, MATOS (1999) sugere que, à medida
que se desenvolveram as redes de computadores e as informações passaram a
trafegar livremente por elas, as preocupações acerca da segurança deixaram de
envolver apenas a parte física, ou seja, o acesso indevido ao prédio/sala onde a
máquina se encontrava, e passaram a cuidar do risco de acesso não autorizado aos
dados, criando a necessidade de proteção pela rede.
Nesse sentido, SOARES (1995) elucida que segurança na área da tecnologia
de computadores e rede
“[...] está relacionada à necessidade de proteção contra o acesso ou
manipulação, intencional ou não, de informações confidenciais por
elementos não autorizados, e a utilização não autorizada do
computador ou de seus dispositivos periféricos. A necessidade de
proteção deve ser definida em termos das possíveis ameaças e riscos
dos objetivos de uma organização, formalizada nos termos de uma
política de segurança.”.
Para CISCO ... (2006), o AAA é uma forma segura e eficaz de fazer o referido
controle de segurança, através do qual é possível configurar o controle de acesso
aos equipamentos de rede e servidores.
NAKHJIRI (2005) entende que o AAA são três blocos importantes usados na
construção da arquitetura de uma rede, que ajuda a proteger tanto os
administradores quanto os clientes contra fraudes, ataques, gestão de recursos
inadequados e perda de informação.
2.1 Autenticação, Autorização e Contabilização (AAA)
Segundo METZ (1999), provedores de serviços de Internet (ISPs) têm mais a
se preocupar do que somente garantir o acesso à rede aos seus clientes. É preciso
ter proteção contra ataques que possam prejudicar a disponibilidade do serviço.
Devem ser estabelecidos níveis de autorização, controle de acesso e fazer o registro
de todas as ações feitas durante a conexão.
Enfrentar esses desafios de forma simplificada e escalável é a principal tarefa
da Autenticação, Autorização e Contabilização (METZ,1999). O AAA, por sua vez,
nada mais é do que um framework estrutural para coordenar todas essa áreas sob
várias tecnologias de redes e plataformas.
Alguns dos benefícios de usar o AAA em equipamentos de rede são:
• Aumento da flexibilidade e controle do acesso a configuração;
• Escalabilidade;
• Métodos de autenticação padronizados como RADIUS, TACACS+ e
Kerberos.
2.1.1 Autenticação
Para TODOROV (2007), o processo de autenticação, geralmente, consiste
em duas fases distintas: a identificação e a autenticação.
• Identificação – provê a identificação do usuário ao sistema de
segurança. Esta identidade é geralmente fornecida através de um ID
único de usuário. O sistema de segurança normalmente procura por
todos os seus objetos abstratos que ele conhece e encontra o objeto
específico para os privilégios que o usuário atual está se submetendo;
• Autenticação – é o processo de validar a identidade do usuário. O fato
de o usuário dizer que é alguém, não necessariamente significa que
isso é verdade. Para ter certeza que o usuário é quem ele diz ser, o
usuário deve fornecer informações que comprovem sua identidade ao
sistema. As evidências fornecidas por um usuário em um processo de
autenticação são chamadas credenciais. Em sistemas computacionais,
as credenciais frequentemente tomam a forma de uma senha, a qual é
um segredo conhecido apenas pelo indivíduo e o sistema.
NAKHJIRI (2005) e TODOROV (2007) ressaltam que são tipicamente três
componentes interagindo em um processo de autenticação, como demostra a Figura
1:
• Usuário – é o usuário que tenta o acesso. É o responsável por
informar as credenciais, para provar sua identidade;
• Autenticador – é o responsável por toda interação com o usuário. Não
tem autoridade nenhuma para barrar por ele mesmo o acesso de um
suplicante ao serviço, podendo ser comparado com um guarda que
fica na porta de entrada de um prédio, verificando a identidade das
pessoas que desejam entrar. No modelo AAA é também conhecido
como NAS (Network Access Server), que, neste contexto, é
considerado um cliente;
• Servidor de Autenticação – é quem realmente tem a autoridade e
acesso à base de dados, para poder autorizar ou não o acesso do
cliente ao sistema.
Figura 1 - Modo de Autenticação de Três Partes. Fonte: Todorov (2007)
2.1.2 Autorização
Segundo CISCO ... (2006), a autorização provê o método de controle de
acesso. A autorização do AAA trabalha montando uma lista de atributos, que
descreve quais ações o usuário é autorizado a realizar.
“Autorização é definida como o ato de determinar se um privilégio especial
pode ser concedida para o apresentador de uma credencial particular.” (NAKHJIRI,
2005, p.7).
TODOROV (2007) ressalta que a autorização só entra em funcionamento
depois que o usuário estiver devidamente identificado e com as credenciais
validadas para ganhar acesso aos serviços.
2.1.3 Contabilização
A contabilização, conforme CISCO ... (2006), fornece o método de coleta e
envio de informações sobre as ações do usuário, sendo esses dados utilizados para
contabilizar, auditar e reportar. Possibilita saber os serviços que os usuários estão
acessando, como também a quantidade de recursos de rede que estão usando.
“Usuários são responsáveis pelas suas ações em um sistema.
Usuários podem ser autorizados para acessar um recurso; se eles
acessam, o sistema operacional ou a aplicação precisa fornecer uma
trilha de auditoria que fornece dados históricos sobre quando e como
um usuário acessou um recurso. Por outro lado, se um usuário tentou
acessar um recurso, sem que ele tenha permissão para tal, uma trilha
de auditoria ainda é necessária para determinar uma tentativa de violar
o sistema de autorização e, em alguns casos, as políticas de
autenticação.” (NAKHJIRI, 2005, p.8).
NAKHJIRI (2005) continua seu pensamento afirmando que as ações do
usuário devem ser registradas em caso de sucesso ou falha, bem como suas
tentativas de autenticação no sistema. Isso torna a contabilização muito útil a partir
de uma perspectiva de segurança.
Para TODOROV (2007), existe uma variedade de aplicações que são
definidas para o uso de contabilização, dentre as quais são citadas as seguintes:
• Auditoria: ato de verificar a conformidade das políticas de uso,
diretrizes de segurança e assim por diante;
• Análise de Tendências: utilizado na previsão de uso futuro para fins de
planejamento de capacidade.
2.2 Protocolos de Autenticação para equipamentos
Sistemas de autenticação, que utilizam protocolos como RADIUS e
TACACS+, estão sendo implementados com sucesso. Este capítulo descreve
algumas características de cada um desses protocolos.
2.2.1 RADIUS
RADIUS é um sistema distribuído cliente/servidor que previne as redes contra
acesso não autorizado (CISCO, 2006). Foi desenvolvido em meados de 1990 pela
Levingston Enterprise, com o fim de prover autenticação e auditoria para os
equipamentos de rede da organização (METZ, 1999).
Segundo o RFC 2865 (IETF, 2000), os seus atributos funcionais consistem
em:
• Modelo Cliente/Servidor – o equipamento de acesso à rede (NAS)
opera como um cliente do RADIUS. O cliente é o responsável por
passar as informações do usuário ao servidor RADIUS e depois agir de
acordo com a resposta retornada. O servidor RADIUS é o responsável
por receber o pedido de conexão do usuário, fazer a autenticação e
retornar todas as configurações necessárias ao cliente, para que este
consiga fornecer o serviço ao usuário, como mostra a Figura 2;
• Segurança de Rede – Transações entre o servidor RADIUS e o NAS
são autenticadas por uma chave compartilhada, que nunca é enviada
pela rede. As senhas dos usuários são enviadas cifradas entre o
cliente e o servidor para evitar o roubo em redes inseguras;
• Mecanismo de Autenticação Flexível – Um servidor RADIUS pode
suportar vários mecanismos de autenticação como PAP e CHAP;
• Protocolo Extensível – Novos valores de atributos podem ser
adicionados sem prejudicar as implementações existentes do
protocolo.
Figura 2 - Troca de mensagens usando RADIUS. Fonte: CISCO (2008)
Porém, o RADIUS deixa a desejar quando o assunto é segurança.
“Proteção de segurança no RADIUS é bastante primitivo. Duas funções
principais são fornecidas, uma é esconder o atributo (principalmente
senha) e o outro é autenticar certas mensagens. Ambas são realizadas
usando funções de hash MD5 e um segredo é compartilhado entre o
servidor RADIUS e o cliente (NAS).” (NAKHJIRI,2005, p131).
2.2.2 TACACS+
Outro protocolo que provê os serviços de AAA é o Terminal Access Controller
Access Control Protocol (TACACS). Originalmente descrito na RFC 1492 (IETF,
1993), foi reestruturado ao longo dos anos pela CISCO e é suportado por vários
servidores, roteadores e outros dispositivos encontrados nas redes empresarias de
hoje. A versão atual é chamada de TACACS+, que reflete as melhorias feitas no
protocolo original (METZ,1999).
De acordo com HARRIS (2007) o TACACS tem três gerações: TACACS;
XTACACS; TACACS+. Na verdade, o TACACS+ não é uma nova geração, é um
novo protocolo que provê funcionalidades similares. Por ser um protocolo totalmente
diferente, não é compatível com o TACACS ou XTACACS.
Para CISCO ... (2006), TACACS+ é uma aplicação de segurança que provê a
validação centralizada dos usuários que estão tentando acessar equipamentos de
rede ou servidores de acesso à rede. O Protocolo possibilita a instalação separada e
modular dos serviços de autenticação, autorização e contabilização. Outro ponto
muito importante, é que toda a troca de informações entre o equipamento de acesso
e o daemon é cifrado.
A Figura 3 mostra todo o fluxo de comunicação entre um cliente e o servidor
TACACS+. Cada serviço, ou seja, autenticação, autorização e contabilização tem
um momento específico dentro deste fluxo. Para a autenticação, primeiro o cliente
faz uma requisição de acesso, o servidor retorna requisitando o nome de usuário e
depois a senha. Já para a autorização e a contabilização, para cada requisição
existe uma resposta. Quando o pacote inicial de verificação de acesso ao shell é
executado, é feita uma requisição de autorização, o servidor verifica se a permissão
existe e retorna o resultado. Com isso é enviado também uma requisição para início
de execução de contabilização, mesmo que o comando seja negado. Verificado se o
usuário tem permissão de acesso ao shell, inicia-se a requisição do comando e seus
parâmetros. Para cada requisição de comando é feita uma requisição de
contabilização, para gravar as ações do usuário. Ao fim desse fluxo é feita uma
requisição para parar o processo de contabilização. É importante ressaltar que esse
fluxo é feito para cada comando executado no equipamento.
2.2.3 Diferenças entre RADIUS e TACACS+
De uma forma resumida, para CISCO ... (2008), as principais diferenças entre
RADIUS e o TACACS+ são descritas na sequência:
Protocolo de Transporte:
O RADIUS utiliza UDP, ao passo que o TACACS+ usa TCP. TCP oferece
algumas vantagens em relação ao UDP, tais como:
• TCP oferece transporte orientado à conexão, enquanto o UDP oferece
o melhor esforço de entrega;
• TCP é mais escalável e adaptável para redes em crescimento ou
bastante congestionadas;
• Usando TCP é possível indicar se o servidor está com problemas ou
está desligado, já com UDP essa diferenciação não é possível.
Cifragem dos Pacotes
O RADIUS cifra apenas a senha do usuário no pacote de requisição de
acesso do cliente ao servidor. O resto do pacote é enviado sem estar cifrado. O
TACACS+, por sua vez, permite que todo o corpo do pacote seja criptografado,
sendo excluído apenas um cabeçalho, o qual possui um campo que indica se o resto
do pacote é cifrado ou não.
Autenticação e Autorização
RADIUS combina a autenticação e autorização. O pacote de acesso aceito do
servidor RADIUS para o cliente contém informações de autorização, dificultando o
desacoplamento dessas duas funções.
O TACACS utiliza a arquitetura AAA, na qual cada funcionalidade pode ser
usada independentemente. Isso possibilita o emprego de diferentes soluções de
autenticação, sendo possível ainda usar a autorização e a contabilização do
TACACS+. Um exemplo disso seria o uso da autenticação via Kerberos e o
TACACS+ para as funcionalidades de autorização e contabilização.
Suporte a Multiprotocolos
TACACS+ oferece suporte a multiprotocolos, já RADIUS não suporta:
• AppleTalk Remote Access protocol
• Novell Asynchronous Services Interface (NASI)
• X.25 Pad
Gerência de Equipamentos
A utilização do RADIUS não permite um controle mais profundo de quais
comandos podem ou não ser executados em um equipamento.
O TACACS+ oferece dois métodos de autorização de comandos. No primeiro
método, é possível definir um nível de privilégio para o usuário. Assim, o
equipamento verifica se o usuário tem nível de privilégio suficiente para executar um
comando ou não. Por padrão, os níveis de privilégio vão de 0 a 15, no qual zero
significa nenhum privilégio e quinze significa privilégio total. O outro método
destina-se a especificar os atributos dos usuários ou grupos e quais comandos eles terão
permissão de executar, deixando a verificação da permissão ou não do comando a
encargo do servidor TACACS+.
3. Tecnologias
Para o desenvolvimento do ambiente proposto, foram utilizadas apenas
tecnologias livres, que estão disponíveis livremente na Internet.
O openLDAP, que será usado para o armazenamento dos usuários, o
TAC_PLUS, que é a implementação de código aberto do protocolo TACACS+ e
interage com o openLDAP por meio do MAVIS.
Outras tecnologias foram usadas para o desenvolvimento do ambiente,
principalmente na interface administrativa do sistema, como javascript, JQuery,
AJAX, JSON, HTML, PHP e no servidor onde são armazenados todos os logs, foi
usado o MySQL como sistema gerenciador de banco de dados, mas como não
fazem parte do objetivo central, não serão explicadas.
3.1 openLDAP
O Lightweight Directory Access Protocol (LDAP) de uma forma simplificada, é
um protocolo para pesquisar e atualizar diretórios. Segundo a RFC 2251 (IETF,
1997), que define a versão três do protocolo, o LDAP segue o modelo de serviços de
diretório X.500, que é uma árvore de nós, cada um consistindo de um conjunto de
atributos com seus respectivos valores. O modelo X.500 era muito complexo para
ser suportado em desktops e através da Internet, então o LDAP foi criado para
prover este serviço.
Segundo CARTER (2003), diretórios são frequentemente confundidos com
bancos de dados. Ambos têm características em comum como rapidez em leitura e
extensibilidade de esquemas. A maior diferença é que diretórios são desenvolvidos
para terem mais operações de leitura do que escrita, já bancos de dados assumem
que essas operações ocorrem com mesma frequência. Em consequência a isto,
estruturas de diretórios não implementam transações e locks, como as bases de
dados.
Para CARTER (2003), serviços de diretórios podem assumir muitas formas,
mas cinco características, pelo menos, são verdadeiras:
• Otimizadas para leitura;
• Implementam modelos distribuídos de armazenamento de informações;
• Pode estender os tipos de informação que armazena;
• Recursos avançados de pesquisa;
• Replicação consistente entre servidores de diretórios.
O serviço de diretório X.500 ganhou o título de “pesado”. Nele, toda a
comunicação entre cliente e servidor é feita usando o a pilha do protocolo Open
System Interface (OSI), e como trabalha na camada de aplicação, o cabeçalho de
rede fica muito pesado.
Já o LDAP é considerado leve, como o próprio nome sugere, em comparação
com o X.500 pois utiliza mensagens com baixa sobrecarga, mapeadas diretamente
na camada TCP da pilha do protocolo TCP/IP.
A figura 4 ilustra essa comparação entre os dois serviços e suas respectivas
pilhas.
Figura 4 - Comparação entre o X.500 e o LDAP
Modelos LDAP representam os serviços providos pelo servidor, vistos por um
cliente. São modelos abstratos que descrevem as várias facetas de um diretório
LDAP. De acordo com a RFC 2251, um diretório LDAP é dividido em dois
componentes: modelo protocolo e modelo de dados.
O modelo de dados assume que o servidor garante acesso à árvore de
informações do diretório. A árvore é feita de várias entradas, estas, por sua vez,
possuem informações relevantes ao objeto.
Já o modelo protocolo basicamente define a forma de interação entre cliente e
servidor. O cliente faz uma requisição de uma operação sobre o diretório, o servidor
faz o processamento e retorna o resultado.
Até este momento foram apresentadas apenas algumas características dos
diretórios, em especial do LDAP. A partir de agora o foco será na estrutura da árvore
e dos objetos. Para tal considere como base as Figuras 5 e 6.
Figura 5 - Exemplo de uma árvore de diretório LDAP
O Distinguished Name (DN) é usado para identificar uma entrada de forma
não ambígua e única em um serviço de diretórios. Esse atributo é composto por uma
sequência de Relative Distinguished Name (RDN) e cada RDN corresponde a um
ramo na árvore do diretório, desde a raiz até a entrada à qual o DN faz referência.
Na
árvore
usada
como
exemplo,
um
DN
possível
é
Figura 6 - Exemplo dos atributos de um objeto
Na Figura 6, podemos visualizar os atributos e seus respectivos valores em
um objeto. Para fins de um melhor entendimento do desenvolvimento desde
trabalho, destacamos os atributos objectClass. Para a RFC 2251, um atributo
objectClass especifica as classes de um objeto, e permite determinar quais atributos
são válidos para uma entrada.
Segundo BUTCHER (2007) para utilizar um objectClass, o openLDAP utiliza
schemas, que são arquivos onde são definidos as diferentes classes dos objetos e
seus atributos que o openLDAP deve suportar, entre outras coisas. Usando estes, o
OpenLDAP pode determinar quais entradas são permitidas armazenar, se qualquer
entrada de dado é válida, e como as entradas devem ser idealmente armazenadas.
Uma outra possibilidade é a criação de schemas para uma maior customização dos
elementos de uma árvore LDAP.
Depois dessa visão geral sobre o openLDAP e seu funcionamento, que para
este projeto será usado como backend do ambiente, entraremos em detalhes das
tecnologias utilizadas para prover os serviços de AAA.
3.2 TAC_PLUS
De acordo com HUBBER (2011), principal desenvolvedor do projeto, o
tac_plus é um daemon dirigido a eventos do TACACS+, ou seja, seu funcionamento
esta extremamente relacionado ao envio e recebimento de eventos. Provê os
serviços de autenticação, autorização e contabilização para roteadores Cisco e
outros equipamentos de rede, desde que suportem o protocolo. É uma reformulação
do código-fonte original do TACACS da Cisco. Alguns dos principais recursos
incluem:
• Flexibilidade de backends externos para perfis de usuários (LDAP,
Active Directory e RADIUS);
• Multiplexação das conexões – múltiplos clientes por processo;
• Escalabilidade – sem limite de usuários, servidores ou clientes;
• Suporte aos protocolos IPv4 e IPv6;
• Compilado com a especificação mais recente do protocolo TACACS+;
Para poder oferecer a já falada flexibilidade de backend, o tac_plus usa um
outro módulo chamado MAVIS e que será explicado a seguir.
3.3 MAVIS
O Modular Attribute-Value Interchange System (MAVIS) é uma biblioteca que
provê um protocolo extensível e modular para as tarefas de autenticação e
autorização. Também funciona como um subsistema de autenticação modular,
usado pelo daemon tac_plus. Esta biblioteca contem vários módulos para o uso de
diversos backends e um deles é para serviço de diretório, seja o openLDAP ou o
Active Directory da Microsoft.
Para poder usar todas suas vantagens é só adicionar um novo arquivo de
schema no servidor LDAP e em cada objeto que poderá fazer uso das
funcionalidades do tac_plus, adicionar o objectClass “tacacsAccount“ e seus
respectivos atributos.
4. Estudo de Caso – Rede UFSC
A partir deste capítulo passa-se a discorrer sobre o ambiente proposto. Serão
abordadas três fases: Projeto, Desenvolvimento e Implantação.
No Projeto será analisado o ambiente atual e apresentado uma solução que
resolva suas limitações. No Desenvolvimento será exposto com mais detalhes as
configurações do ambiente. Já na Implantação serão apresentados os resultados de
desenvolvimento.
4.1 Projeto
Nesta seção será descrito e analisado o ambiente atual, listando as
deficiências que motivaram às modificações e melhorias que são descritas no
ambiente proposto.
4.1.1 Cenário Atual
O ambiente de autenticação atual é simples e tem problemas de segurança.
Da forma como é usado, a autenticação é bastante limitada e o uso de
contabilização e autorização é implementada apenas nos equipamentos de core
(núcleo) da rede. A Figura 7 mostra como é o fluxo da informação em um processo
de autenticação. Nos roteadores existe um agente externo, que é o servidor Cisco,
participando da autenticação e também da autorização, como indica o número 2.
Figura 7 - Processo de autenticação atual
Já para os demais equipamentos, indicados pelo número 1, não existe
nenhum sistema atuante no processo de autenticação, sendo que os usuários são
autenticados na base de dados local destes equipamentos. Pelo fato da
autenticação ser feita dessa forma, vários problemas são gerados, dentre eles:
• Se não for criada uma credencial para cada usuário, todas as pessoas
que terão acesso precisam saber a senha do usuário administrador;
• Se cada pessoa tiver sua credencial, é necessário o acesso em todos
os equipamentos e criar na base local a conta para o usuário;
• Caso seja necessário trocar alguma senha, seja de administrador ou
de um usuário, é preciso acessar cada equipamento e fazer a
mudança;
• Caso seja preciso retirar o acesso de um usuário de um equipamento,
ou de todos, é necessário remover as credenciais de cada
equipamento onde existir o registro;
• No caso de equipamentos que suportam o serviço de autorização e
não existir a política de cada usuário ter uma credencial, todo mundo
terá o mesmo nível de privilégio, desde pessoas com mais experiência
aos mais inexperientes;
• Nos equipamentos que suportam o serviço de contabilização,
principalmente os de core (núcleo), se todos usarem as credenciais de
administrador, não é possível saber quem executou determinado
comando no equipamento, pois todos usuários fazem o login com a
mesma conta.
• Faltou falar da trilha de auditoria tanto no que se refere para toda a
estrutura AAA
Assim, o principal problema do cenário atual é a gerência das identidades dos
usuários, já que para fazer qualquer alteração, tanto para mudança de senha,
quanto para permitir um novo usuário, será obrigatório o acesso em cada
equipamento para fazer essas alterações. Por outro lado este ambiente tem um
ponto muito importante que é o funcionamento independente de outros sistemas,
reduzindo assim os pontos de falha.
4.1.2 Cenário Proposto
Tentando resolver todos as deficiências expostas, foi elaborado um ambiente
com características que possibilite, além de todas as principais funcionalidades do
AAA, uma alta disponibilidade e confiabilidade, como mostra o desenho esquemático
da Figura 8.
Figura 8 - Arquitetura do ambiente proposto
Na infraestrutura proposta, existem dois servidores virtualizados, um
funcionando como master e outro como slave. Os softwares adotados utilizam
daemons, que, conforme OLIVEIRA, CARISSIMI e TOSCANI (2001), são processos
do sistema, e realizam as tarefas do próprio sistema, e não do usuário. Em cada
servidor foram instalados os daemons:
• LDAP e TACACS+ - utilizados para fazer a gerência das identidades,
todas as regras e permissões para as autorizações e interação com os
equipamentos de rede;
• MySQL – utilizado para armazenamento todos os logs gerados na
utilização do sistema, tanto na parte de contabilização quanto das
interfaces administrativas;
• Apache – servidor web para hospedar a aplicação de administração e
monitoramento do ambiente.
Os servidores são independentes entre si, ou seja, se um comutador de rede
for configurado para utilizar o servidor master, e outro equipamento for configurado
para o slave, ambos devem ter os mesmos resultados. Isso é possível pois todos os
arquivos de configurações, bases de dados do MySQL e os diretórios LDAP são
replicados bidirecionalmente entre as máquinas. Para isso, no MySQL e no LDAP
foram configurados os serviços de replicação dos próprios daemons.
Já os arquivos de configurações, principalmente os do TACACS+, são
sincronizados utilizando o softwares Unison File Synchronizer. De acordo com
PIERCE (2009), principal desenvolvedor do projeto, o Unison é uma ferramenta de
sincronização de arquivos, disponível para Unix e Windows. Permite a réplica de
arquivos e diretórios usando diferentes tipos de ferramentas como por exemplo CVS,
Coda e Rsync.
Para acesso às máquinas, foi definido que cada servidor teria configurada
uma interface de rede para acesso roteado, ou seja, quando os endereços IP de
quem está fazendo o acesso não pertencem ao mesmo segmento de rede do
servidor. Além da interface roteada, vão ser configuradas interfaces em cada rede
de gerência de equipamentos. Isso possibilita o acesso aos equipamentos mesmo
que haja problemas na rede a nível de roteamento, já que os switches, roteadores e
servidores de autenticação estarão em camada dois (enlace) no modelo TCP/IP. O
acesso ficará comprometido apenas em casos de problemas no meio físico, como
por exemplo rompimento de fibra ou cabo de rede. A Figura 9 exemplifica as
configurações de rede dos servidores.
Figura 9 - Infraestrutura de rede dos servidores
Supondo que o servidor AAA tenha as seguintes interfaces de rede
configuradas:
• rede1 – IP: 10.0.1.1
• rede2 – IP: 10.0.2.1
• Interface Roteada – IP: 10.0.5.1
Qualquer equipamento pertencente a rede 10.0.1.0/24 fará toda a
comunicação pela interface 10.0.1.1. O mesmo ocorre para equipamentos com IPs
pertencentes a rede 10.0.2.0/24, que farão acesso pela interface 10.0.2.1.
Caso um usuário ou equipamento com o IP 10.0.6.5 queira fazer acesso ao
sistema, toda a comunicação acontecerá pela interface 10.0.5.1 pois o servidor não
tem nenhuma interface configurada para a rede 10.0.6.0/24, sendo necessário o uso
de roteamento.
Além disso, será usado um outro daemon, o UCARP, que servirá para fazer
com que a disponibilidade do ambiente seja transparente ao usuário. Para DENIS
(2010), o UCARP é uma implementação portátil do protocolo CARP (Common
Address Redundancy Protocol). Com ele é possível, por exemplo, configurar uma
máquina para responder ao IP 10.0.5.1, a outra ao IP 10.0.5.2 e criar uma interface
virtual que responda no endereço 10.0.5.3. O próprio daemon, quando recebe uma
requisição no seu endereço, é o responsável por fazer o “roteamento” e enviar os
pacotes para o servidor que estiver com o melhor tempo de resposta. Isto é muito
útil, pois caso aconteça algum problema com um servidor de exemplo 192.168.1.2, e
ele estiver configurado como master, o daemon encaminha todo o tráfego para o
servidor com o IP 192.168.1.3 sem que o usuário perceba.
Uma outra mudança significativa em relação ao ambiente anterior é no que
diz respeito ao fluxo dos dados no ambiente, após o usuário informar suas
credenciais. Diferente do que era, onde para a grande maioria dos equipamentos
não havia nenhum sistema de suporte as funcionalidades de AAA, agora todas as
requisições são recebidas por um servidor, que faz todo o processamento e retorna
as informações necessárias. Esse processo pode ser melhor visualizado na Figura
10.
Figura 10 - Fluxo dos dados no ambiente proposto
Nesse caso os equipamentos acabam funcionando como suplicantes,
repassando as credenciais ou informações do usuário para o autenticador (servidor
AAA). Esse comportamento é que possibilita ao servidor AAA analisar as
informações, e de acordo com as configurações do daemon autenticar, autorizar e
gerar logs de tudo que é feito nesse processo de interação do usuário com o
equipamento.
Uma outra funcionalidade do ambiente é a possibilidade de integração da
autenticação de máquinas Windows e Linux, independente de serem estações de
trabalho ou servidores. Isso possibilita que com apenas uma credencial o usuário
possa acessar o sistema de autenticação nos comutadores de rede e também nas
suas máquinas pessoais e/ou servidores.
4.2. Desenvolvimento
Apresentados o funcionamento do ambiente, bem como o propósito que se
pretende alcançar com o presente trabalho, neste momento, passa-se a discorrer
sobre duas ferramentas que possuem mecanismos capazes de solucionar as
necessidades verificadas anteriormente. Foram analisadas duas ferramentas para
desenvolver o projeto proposto:
• Cisco Secure Access Control Server 5.1 (ACS) (CISCO, 2012);
• TAC_PLUS (HUBBER, 2011).
Como a ferramenta desenvolvida pela Cisco possui algumas limitações, que
serão explicadas no texto, foi escolhida a solução utilizando o TAC_PLUS MAVIS
para uso no projeto.
4.2.1 Cisco ACS
Segundo CISCO...(2012), o Secure Access Control Server (ACS) é um
servidor de segurança baseado em políticas que fornece os padrões de
autenticação, autorização e contabilização (AAA) para uma rede. Facilita o
gerenciamento administrativo de aplicações e dispositivos, sejam eles Cisco ou não.
Também serve de ponto de integração entre o controle de acesso à rede e o
gerenciamento de identidade.
Dentro do contexto dos dois principais protocolos do AAA – RADIUS e
TACACS+ – o ACS tem as seguintes áreas funcionais:
• No framework do protocolo RADIUS, o ACS controla o acesso cabeado
ou wireless por usuários e máquinas à rede e gerencia os recursos de
rede utilizados por meio de contabilização. Suporta múltiplos métodos
de autenticação do RADIUS incluindo PAP, CHAP, MSCHAPv1,
MSCHAPv2 e outros da família de protocolos EAP como EAP-MD5,
LEAP, PEAP, EAP-FAST e EAP-TLS;
• Já no framework do protocolo TACACS+, o ACS facilita o
gerenciamento administrativo de equipamentos como switches, pontos
de acesso wireless, roteadores e gateways, como também serviços
como acesso dial-up, VPN (Virtual Private Network) e firewall, sendo
Cisco ou não.
O ACS é o responsável por identificar usuário e dispositivos que tentam
acessar a rede. Essa identificação pode ocorrer diretamente no repositório interno
de identidades para fazer autenticação local, mas também existe a possibilidade do
uso de repositórios externos como:
• LDAP
• Active Directory
• RSA SecurID Token Server
• RADIUS Identity Server
Outro detalhe importante são os recursos necessário para a instalação da
aplicação. De acordo com CISCO...(2011), existem duas formas para a instalação
do ACS, usando uma máquina virtual no hipervisor VMWare ou em um hardware
específico da Cisco. Caso seja instalado o ACS no formato de uma máquina virtual,
o sistema operacional é um Linux Red Hat 5 e é exigido pelo menos 500 GB de
espaço de disco para funcionar nas configurações mínimas de avaliação do sistema.
Estas características do ACS acabam se transformando em problemas pois
necessitam de muitos recursos, tanto de hardware como financeiros para a compra
de software. Para a instalação do ambiente proposto, com todos os componentes já
citados, seria necessária a aquisição de duas licenças do ACS 5.1 e pelo menos 2
TB de capacidade de armazenamento, que é o recomendado pela Cisco para o uso
em ambiente de produção.
Outra limitação que acabou deixando muito a desejar diz respeito ao suporte
à equipamentos de outras empresas, já que o ACS não suporta, quando instalado
sem nenhum modificação, o uso de autorização em equipamentos que não são da
Cisco. Comparando com a realidade da rede UFSC, onde existe uma
heterogeneidade nos equipamentos, este é o principal ponto negativo, pois desta
forma a solução só funcionaria de maneira satisfatória nos equipamentos de core da
rede, da mesma forma que é feito atualmente. Para os demais equipamentos, o ACS
funcionaria apenas para suporte à autenticação.
4.2.2 TAC_PLUS
Considerando que já foi exposto o conceito do daemon TAC_PLUS na seção
3.2, foram feitos dois testes distintos:
• Compilação padrão
• Compilação TAC_PLUS MAVIS
Da forma padrão o TAC_PLUS é limitado. Uma das principais limitações é
que todos os usuários, dispositivos e demais diretivas precisam estar cadastrados
no arquivo de configurações do daemon. Isso é um grande problema já que para
adicionar cada novo usuário ao sistema é necessário que um administrador edite o
arquivo de configurações e depois reinicie o daemon. Se por acaso alguém estiver
executando algum comando no equipamento exatamente na hora em que o daemon
é reiniciado, o comando será negado, por exemplo. Caso o usuário não esteja
cadastrado no arquivo de configurações, é possível fazer login utilizando o PAM
(Pluggable Authentication Modules) do servidor linux. Desta maneira também é
necessário ter um registro no arquivo de configurações mostrando que, para aquele
usuário específico, as informações serão fornecidas pelo sistema operacional. Um
exemplo dessa configuração pode ser visto na Figura 11, onde o usuário luís é
autenticado via PAM e o usuário joão via arquivo de configuração.
Figura 11 - Exemplo de Configuração de usuários no tac_plus
Utilizando a compilação padrão, o PAM é uma peça fundamental ao sistema
pois é através dele que o TAC_PLUS tem a possibilidade do uso de recursos
externos para a autenticação, como por exemplo o LDAP. O funcionamento é bem
simples:
1. Quando o usuário está configurado para autenticar via PAM, o daemon
busca as credenciais do usuário da base local do sistema operacional.
2. É instalada uma biblioteca ao PAM que permite que ele verifique as
credenciais de um usuário em um diretório LDAP.
3. Essa biblioteca é configurada para que sempre a primeira opção de
busca seja feita na base local, e caso não seja encontrado o usuário, a
busca é feita no diretório LDAP.
Essa obrigatoriedade do uso do PAM deixa todo o sistema um tanto quanto
inflexível, pois centraliza tudo no arquivo de configurações, ao invés de ter uma
forma simples de possibilitar a gerência de todo o daemon.
Outra limitação é não possibilitar que um usuário tenha várias políticas de
acesso. Dessa forma o usuário terá o mesmo nível de privilégio para todos os
equipamentos que ele tiver acesso. Caso o usuário em questão seja um estagiário,
ou qualquer outro que deve ter níveis de acesso distintos, e precise de acesso total
a algum tipo de equipamento, seja ele de borda ou core, existem duas opções:
• Criar uma Access Control List (ACL) onde é negado o acesso a
equipamentos de maior criticidade, como por exemplo os de core, e
vinculá-la às suas definições no arquivo de configurações. Dessa
forma o usuário não terá acesso ao equipamento;
• Permitir o acesso ao equipamento com todos os privilégios garantidos
pelas configurações. A Figura 11 ilustra um caso onde os dois
usuários têm o mesmo nível de privilégio para todos os equipamentos,
já que não existe nenhuma ACL associada com nenhum deles. Os
níveis de privilégios são garantidos pela variável member. Na variável
pertence a este grupo. No caso mostrado na Figura 11, os dois
usuários cadastrados pertencem ao mesmo grupo GrupoTeste,
portanto têm o privilégio de executar os mesmos comandos como por
exemplo show, traceroute, ping, logout e exit.
Usando o TAC_PLUS MAVIS (explicado na seção 3.3) algumas dessas
limitações são atendidas. Primeiramente, o daemon tem suporte nativo a agentes
externos como:
• Active Directory;
• LDAP;
• RADIUS.
Caso a autenticação esteja configurada para acontecer via Active Directory ou
LDAP, a solução torna-se ainda mais completa, pois permite que sejam definidos
atributos específicos nos registros do diretório e não somente no arquivo de
configurações. O exemplo da Figura 12 mostra a adição dos três novos atributos -
tacacsClient, tacacsMember e tacacsProfile – que são responsáveis por possibilitar
a flexibilidade necessária com o seu uso.
Figura 12 - Exemplo de uma entrada LDAP com suporte ao TAC_PLUS MAVIS
tacacsClient
Define o endereço IP ou segmento de rede de onde o daemon pode aceitar a
conexão do usuário. Funciona de forma semelhante a um firewall, analisando a
origem da requisição e permitindo, ou não, o acesso ao equipamento. Na Figura 12
o usuário tem acesso somente a partir da rede 150.162.248.0/24, ou seja, se esse
usuário específico tentar se conectar pela rede 150.162.161.0/24, mesmo não
havendo um firewall instalado no servidor, o acesso será negado. É possível
também especificar o endereço IP exato para o acesso, como por exemplo
150.162.248.43/32.
tacacsMember
Atributo responsável pela definição das políticas de acesso. As sintaxes
permitidas são as seguintes:
• nível de privilégio@grupo de equipamentos.
Tanto o nível de privilégio quanto o grupo de equipamentos são configurados
no arquivo de configurações do daemon. Cada nível de privilégio é composto por
uma lista de comandos possíveis de serem executados para aquele nível. A Figura
13 exemplifica a configuração dos níveis de privilégios.
Figura 13 - Exemplo de configuração de níveis de privilégios
Como mostrado na Figura 13, usuário que possuem o atributo tacacsMember
como admin_1, terão permissão de executar todos os comandos existentes no
equipamento pois o padrão da configuração é permitir tudo. Já para os casos onde o
atributo for operador_2, o padrão para esse nível é negar (default command =
deny) o comando, exceto para os casos de comandos listados pelos campos cmd,
que são usados para especificar alguns comandos com permissão.
Foram definidos 4 níveis de privilégios para atender as demandas de
autorização do ambiente:
• admin_1 – acesso total, sem restrições;
• admin_2 – pode ver todas as configurações. Alterar apenas ACLs,
Interfaces e VLAN;
• operador_1 – pode ver todas as configurações, exceto running-config.
Alterar apenas Interface;
• operador_2 – apenas ver configurações de rotas, arp, interface, log,
VLAN, processos, spanning-tree;
• Todos os níveis podem executar os comandos de ping e traceroute.
No caso dos grupos de equipamentos, podem ser definidos endereços IP de
um ou mais equipamentos, ou segmentos de rede, e a chave secreta que é usada
para autenticar o equipamento no servidor TACACS+. Um exemplo simples da
configuração de grupos pode ser visto na Figura 14.
Cada escopo marcado como host define o grupo. Pode ter um ou mais
address, que são os endereços IP dos equipamentos deste grupo e uma key, que é
a chave de autenticação no daemon que deve ser configurada igual no equipamento
pertencente ao grupo.
tacacsProfile
Usado para definir mais algumas variáveis ao registro. Utilizando este atributo
é possível definir tempo de validade do registro, caso seja necessário liberar o
acesso por um tempo determinado, fazer restrições de acesso por horário e também
fazer o uso de ACLs para restringir ou permitir o acesso a outros equipamentos.
Alguns exemplos dessas definições podem ser vistas na Figura 15.
Figura 15 - Definições de especificações de tempo e ACLs
No exemplo de usuário mostrado na Figura 12, o atributo tacacsProfile possui
duas definições, uma definindo a validade das credenciais e outra uma
especificação de tempo, indicando o período do dia que o acesso será liberado. A
acl acl_horario_padrao, mostrada na Figura 15, para a qual a credencial está
configurada, restringe o acesso para apenas os dias da semana, em horário
comercial, das 8 as 18 horas.
Todas essas possibilidades acabam deixando o sistema muito mais dinâmico
e simples, pois não será mais necessário fazer acesso ao servidor e editar o arquivo
de configurações sempre que for preciso criar/editar/excluir uma credencial. Desta
forma foi criada uma nova necessidade, o desenvolvimento de uma aplicação para
fazer a gerência de todo o ambiente.
4.3. Implantação
Esta seção tem o objetivo de descrever o ambiente de implantação, bem
como a estrutura e os equipamentos suportados. Também serão apresentados os
resultados da implantação e os sistemas de gerência e acompanhamento de logs
que foram desenvolvidas.
4.3.1 Estrutura Física
No desenvolvimento deste ambiente, foi trabalhado com dois tipos de
infraestrutura:
• Servidores;
• Comutadores de rede.
Para a infraestrutura de servidores foram criadas duas máquinas virtuais,
hospedadas em um ambiente com o hipervisor VMWare. Cada uma possui dois
processadores virtuais Intel® Xeon® de 3.33GHz, capacidade de armazenamento
de 24 GB e 2GB de memória. Além destas características de hardware, cada
servidor tem associado a ele cinco interfaces de rede, para possibilitar o uso dos
recursos descritos na seção 4.2, quando é descrito a forma de acesso aos
servidores.
No caso da infraestrutura dos equipamentos de rede, a rede UFSC dispõe
principalmente dos seguintes modelos de equipamentos:
Figura 16 - Roteador Cisco 7606
Uso: Core da rede.
Principais Características: Faz o roteamento de toda a rede. Possui
interfaces 1Gb e 10Gb via fibra óptica para fazer a conexão tanto ao PoP-SC,
quanto aos principais equipamentos de distribuição da UFSC, seja para rede
cabeada ou sem fio.
Suporte ao ambiente: implementa autenticação, autorização e
contabilização.
• 3Com SuperStack® 4 5500G (Figura 17)
Figura 17 - Switch 3Com 5500G
Uso: Usados principalmente para a distribuição dos centros da UFSC.
Principais Características: Interfaces 1Gb via fibra óptica ou cabo UTP.
Suporte ao ambiente: implementa autenticação, autorização e
contabilização.
• D-Link DGS 3100-24/48 PoE
Figura 18 - D-Link DGS 3100 PoE
Uso: Equipamentos usados principalmente para acesso dos usuários (borda).
Principais Características: Interfaces 1Gb via cabo UTP, sendo que as
quatro ultimas podem ser optado pelo uso de fibra óptica. São utilizados modelos de
24 e 48 portas e alguns com a opção de PoE (Power over Ethernet).
Suporte ao ambiente: implementa autenticação e autorização com apenas
dois tipo de privilégio, acesso total ou somente leitura.
Figura 19 - Cisco WLC 5500
