Há Vida Após o Cisco ISE? Análise e Teste do NAC Russo da Eltex em Laboratório de Rede
Uma análise detalhada do sistema NAC russo Eltex NAICE, comparando-o com gigantes como Cisco ISE. O artigo explora a arquitetura, funcionalidades e desempenho do NAICE em cenários de rede reais, oferecendo uma visão sobre o futuro do controle de acesso.
MundiX News·10 de maio de 2026·15 min de leitura·👁 1 views
Há Vida Após o Cisco ISE? Análise e Teste do NAC Russo da Eltex em Laboratório de Rede
As soluções NAC (Network Access Control) têm sido tradicionalmente associadas a “monstros” como Cisco ISE ou Aruba ClearPass. Mas e se fosse possível construir um NAC russo a partir dos módulos “Medved”, “Lisa” e “Zayats”, colocá-los na vanguarda da rede e tentar cobrir os mesmos cenários? Nossa equipe trabalha com soluções NAC há mais de 19 anos. Os últimos anos têm sido particularmente interessantes: o segmento russo de NAC cresceu notavelmente, novos produtos aparecem regularmente e o interesse dos clientes nos impulsiona a analisar constantemente o mercado.
Este artigo faz parte de um ciclo sobre soluções NAC que estamos analisando em nosso laboratório de rede. Desta vez, o foco é o Eltex NAICE – um novato na área de controle de acesso, mas longe de ser um novato no mundo das redes. Vamos descobrir como ele é estruturado, quais tarefas ele realmente cobre e quão confiante ele se sente em comparação com sistemas NAC mais familiares. O nome do produto evoca imediatamente flashbacks do passado, do curso de segurança de rede Cisco da CBT-Nuggets, onde Keith Barker cantava ISE-ISE-Baby. NAICE.. ISE.. O fabricante acertou em cheio com o nome, ele cativa, faz você sentir um pouco de nostalgia.
Esquecemos o passado, vamos descobrir nosso novato. Arquiteturalmente, o sistema é um conjunto de contêineres docker, cada contêiner responsável por seu próprio módulo: RADIUS, TACACS+, servidor web e assim por diante. Cada módulo é nomeado em homenagem a animais do norte, para não se confundir, desempenhando seu papel:
Medved (Ursus) é o módulo central que gerencia todas as entidades do sistema, o esquema do banco de dados através da API interna.
Chayka (Larus) - WEB-GUI para administradores.
Baran (Ovis) fica teimosamente parado e distribui access-accept/reject para as solicitações recebidas.
Lisa (Vulpus) realiza o perfilamento com base nas informações coletadas, inclusive por meio de sondas DHCP, tendo-as retirado de Zayats, que coletou essas sondas.
Zayats (Lepus) - coletor de sondas DHCP.
O banco de dados PostgreSQL é usado como banco de dados. No momento em que escrevi este artigo, a primeira versão principal do NAICE 1.0 e a versão secundária 1.1 foram lançadas, então tive que reescrever algo em movimento - alguns pontos foram alterados para melhor. É bom ver o desenvolvimento do produto, e não o lançamento de novas versões apenas para marcar presença. E imediatamente observo que a atualização do sistema é feita com um comando, novas imagens são puxadas automaticamente do repositório público, muito conveniente.
Primeiros Passos
Com o lançamento da versão 1.0, a capacidade de instalar o sistema usando uma imagem OVA apareceu. Para ser franco, essa abordagem é muito mais amigável para o administrador do sistema e simplifica muito a vida ao implementar a solução para o integrador. Antes disso, era necessário instalar o sistema usando playbooks Ansible, embora tudo esteja descrito em detalhes na documentação. Então, a imagem foi baixada, iniciamos a máquina virtual. Inserimos eltex/eltex no console e começamos a configurar o sistema. Aqui somos recebidos por uma interface pseudo-gráfica que permite configurar os parâmetros básicos do servidor: endereço IP, fuso horário, DNS, NTP e outros. Configuramos, clicamos em , aguardamos o lançamento de todos os contêineres e pronto, o sistema NAC Eltex NAICE está implantado. Abrimos o navegador e acessamos a porta 443 em nosso IP.
Além da interface web principal do sistema, apareceu um console para gerenciar o próprio software NAICE usando uma interface web separada, disponível na porta 8000. Antes de começarmos a configurar o sistema, vamos dar uma olhada no que está sob o capô do próprio servidor.
Console de Gerenciamento
Na guia principal, vemos a telemetria básica da máquina virtual. É possível abrir um terminal bash, às vezes útil se não houver acesso direto ao servidor via SSH. Em seguida, no menu na guia Docker, você pode ver quais contêineres estão em execução, se necessário, é possível reiniciá-los. Na seção Eltex, há guias onde você pode configurar o servidor de licenciamento, importar/exportar a configuração do servidor e também coletar logs para suporte técnico em caso de problemas. Em seguida, a seção NAICE. Na guia Backup, é possível exportar/importar o banco de dados do sistema. Na guia Certification, vemos as configurações dos certificados TLS usados para autenticação PEAP/TLS, bem como para o portal de convidados e a interface web do sistema. Aqui fiquei um pouco desapontado por não haver possibilidade de fazer uma solicitação CSR diretamente na interface do sistema. Terei que descompactar o openssl à moda antiga. Imediatamente gerei um certificado para o servidor, para não ter que voltar a isso mais tarde, e apliquei-o para autenticação EAP e WEB, para que o navegador não xingasse. A última guia é Configuration, dentro - configurações do agendador para remover backups de banco de dados, tempo de vida das sessões TACACS+, sessões de administradores do sistema e alguns outros parâmetros. No geral: é conveniente, você não precisa entrar no console para fazer um backup do banco de dados ou reiniciar o contêiner. Algumas configurações do próprio sistema, por exemplo, trabalhar com certificados, ainda são exibidas nesta interface, embora seja mais lógico colocá-las na interface principal. Esta é uma solução temporária do fabricante, mais tarde as configurações serão transferidas para a interface principal.
Montando o Stand
Vamos começar com a parte mais interessante: testar a funcionalidade do sistema. Vamos para a própria interface web do sistema. Ao entrar, somos recebidos por um painel com estatísticas de conexões. Não há nada para ver aqui por enquanto, primeiro vamos configurar nosso stand. Pareceu-me lógico, em primeiro lugar, montar um pequeno laboratório de um único fornecedor Eltex a partir de um conjunto mínimo - um switch de acesso e um controlador Wi-Fi com um ponto de acesso. O esquema é simples, nele veremos como a funcionalidade RADIUS/TACACS+ declarada funcionará.
Configuração Básica
Primeiro, adicionaremos nosso equipamento de rede como dispositivos NAS. Vamos para a guia “Administração” -> “Recursos de rede”. Adicionamos nosso switch MES2410-08DP e o controlador WLC-15. Especificamos o nome, modelo, um dos perfis pré-instalados no sistema (no nosso caso, Eltex MES e Eltex WLC), endereço IP, descrição. Em seguida, selecionamos um grupo e um local, usaremos essas abstrações nas políticas de acesso. Inserimos a chave para RADIUS e TACACS+ e.. o campo para inserir a chave TACACS+ está inativo. A dica diz “Não suportado pelo perfil selecionado”. Aconteceu que, por padrão, o TACACS+ está desativado em cada perfil de dispositivo. Vamos para as configurações de perfil e ativamos o protocolo. Em seguida, voltamos para as configurações do dispositivo, registramos a chave para TACACS+ e salvamos.
Vamos dar uma olhada mais de perto nas configurações do perfil do dispositivo. Além de ativar/desativar os protocolos RADIUS/TACACS+, temos configurações de atributos disponíveis para determinar o tipo de autenticação (802.1x ou MAB), configurações de atributos para trabalhar com MAB e o protocolo PAP ou EAP_MD5. As configurações de atributos também estão disponíveis para atribuição dinâmica de VLAN e ACL, configurações de CoA e atributos para redirecionar o cliente para o portal de convidados. Parece que há tudo o que você precisa - vamos verificar como tudo funciona na prática.
Agora, vamos configurar nosso diretório Active Directory de laboratório como uma fonte externa de contas. Vamos para a guia “Administração” -> “Gerenciamento de identidade” e adicionar uma fonte. Nas configurações, a seleção do esquema do diretório está disponível, há um esquema predefinido para AD. Inserimos o nome do domínio, em seguida, o nome e a senha do computador com o qual o sistema se conectará ao AD durante a autorização do usuário. Aqui está um ponto importante, o computador deve ser criado com antecedência pelo administrador do AD. Acredito que este ponto pode ser aprimorado, nos sistemas NAC de outros fabricantes, o computador é criado automaticamente. Em seguida, inserimos o login e a senha da conta com a qual o sistema procurará usuários do diretório usando LDAP. Inserimos o FQDN do domínio - o nome completo e a porta LDAP. A partir da versão 1.1, a capacidade de ativar o suporte a LDAPS apareceu. Verificamos a conexão com o servidor, como resultado do teste, vemos uma conexão LDAP bem-sucedida. Clicamos em e selecionamos os grupos para nossas futuras políticas. A última etapa é a seleção de atributos, por enquanto vamos pular isso. Salvamos as configurações.
RADIUS
Em termos gerais, a abordagem para configurar políticas de acesso é o mais clara possível, todos os parâmetros necessários estão próximos. O processo de configuração é consistente e rápido. Na guia “Políticas” -> “Elementos”, configuramos:
Perfis de autorização - o resultado da autorização do cliente.
Conjunto de protocolos permitidos - no momento, estes são PAP, MSCHAPv2, EAP-PEAP e EAP-TLS, bem como MAB.
Condições - na verdade, um construtor para criar condições compostas usadas em políticas de autenticação e autorização.
Dicionários - conjuntos de atributos IETF, por exemplo, um dicionário de atributos RADIUS padrão, bem como dicionários RADIUS de fornecedores conhecidos.
Não vamos nos aprofundar em cada etapa da configuração. Criaremos os perfis de autorização necessários para os testes com atributos diferentes (VLAN, ACL) e ativaremos os protocolos necessários - testaremos MAB, PEAP e TLS.
Vamos diretamente para a configuração dos conjuntos de políticas. Quem conseguiu trabalhar com o Cisco ISE reconhecerá a interface familiar, e eu acho que isso é uma vantagem. As políticas são agrupadas em vários níveis. O nível mais alto é o conjunto de políticas, também conhecido como Policy Set. Ao cair sob a condição apropriada, as sessões serão processadas de acordo com condições de nível inferior. Além disso, um conjunto específico de protocolos disponíveis é definido para cada conjunto de políticas. Dentro de cada conjunto de políticas, as políticas de autenticação e autorização são criadas separadamente. Na fase de autenticação, a política apropriada é selecionada para cada sessão do cliente de acordo com a condição apropriada e uma cadeia de identificação específica é aplicada, ou seja, a ordem de verificação das fontes de autenticação. Em seguida, na fase de autorização, dependendo das condições definidas, perfis de autorização específicos (resultados) configurados anteriormente são aplicados. Por exemplo, usuários do grupo condicional AD_Contractors receberão acesso limitado à rede usando o ACL aplicado à sessão e entrarão em seu VLAN_Contractors.
\nNa guia separada “Perfilamento”, é possível configurar políticas de perfilamento de conexões de clientes com base em vários parâmetros. Graças a essas políticas, um perfil específico pode ser atribuído ao cliente, por exemplo, Windows PC ou Eltex IP Phone. No momento, os perfis podem ser atribuídos com base em apenas dois mecanismos - determinar o fornecedor por OUI MAC-address e informações da cópia dos pacotes DHCP. Esperamos um aumento nesta lista e o aparecimento de perfilamento por CDP/LLDP, SNMP, NMAP, User-Agent.
Vamos começar a configurar. Primeiro, configuraremos as políticas de perfilamento para nossos clientes com antecedência. Estes serão pontos de acesso, PCs Windows, um smartphone e um “dispositivo malicioso” Linux PC. Não vamos nos deter nos detalhes, as políticas são configuradas de forma intuitiva. Para preencher corretamente os atributos como condições de perfilamento, estou ouvindo os pacotes DHCP com Wireshark. Além disso, nos endpoints na seção “Sondas”, você pode ver os dados recebidos usando o perfilamento.
Sugestão ao fornecedor: já faça uma biblioteca de perfis pré-preparada, pelo menos para seu equipamento - pontos de acesso, telefones IP, para que os usuários não precisem mexer nas políticas manualmente, apenas se precisarem corrigir algo.
Em seguida, configuraremos dois Policy Sets, separadamente para MAB e 802.1X. Como condição para entrar no conjunto de políticas, usamos um filtro por mecanismo de autenticação - Wireless/Wired MAB e Wireless/Wired 802.1X, respectivamente.
No conjunto MAB, configuraremos a autenticação mac dos pontos de acesso. Já existe um ponto na rede, o mecanismo de autenticação mac está configurado na porta do switch e já são visíveis tentativas de autorização malsucedidas. Adicionamos o mac do ponto ao grupo local “AP” e, ao mesmo tempo, configuramos a política de perfilamento com base nos dados dos pacotes DHCP. Nas regras de autorização, especificamos uma verificação para inclusão no grupo “AP” e perfilamento bem-sucedido com base no DHCP. O resultado da autorização configuraremos a aplicação dinâmica de VLAN para pontos de acesso. Reconectamos o ponto e nos alegramos com nosso primeiro access-accept. A VLAN correta foi aplicada à sessão, o ponto de acesso está na rede e registrado no controlador.
Como temos o perfilamento configurado para pontos de acesso, vamos tentar verificar se ele deixará nosso “malfeitor” entrar na rede. Substituímos o endereço mac do ponto de acesso e conectamos à porta do switch. Verificamos os logs - access-reject, não foi permitido na rede, o mecanismo de perfilamento funcionou.
Agora, vamos configurar a autenticação PEAP por contas AD. Tenho um PC preparado, registrado no domínio e o usuário user0 foi criado, que faz parte do grupo XXX-Users. No conjunto de políticas DOT1X, usaremos uma verificação para inclusão do usuário no grupo AD correto, bem como uma verificação do resultado bem-sucedido do perfilamento como condições de autorização. Tentamos nos conectar à rede usando um smartphone via Wi-Fi e um PC via porta do switch. Sucesso, nos alegramos com access-accepts. O PC e o telefone entraram em sua VLAN, mas usando o ACL aplicado à sessão, receberam acesso limitado à rede - há Internet e alguns endereços locais estão disponíveis - todo o resto está bloqueado.
Vamos complicar a tarefa, configurar a autenticação por certificados TLS. Os certificados de usuário e máquina já estão instalados no PC do domínio, e o certificado de nossa CA também foi adicionado como raiz confiável. Passaremos pela autorização nas condições já criadas para PEAP, e passaremos pela autenticação usando a cadeia de identificação configurada, que indica qual atributo de certificado usar como nome de usuário (Common Name).
Conectamos o PC à rede, nos alegramos com mais access-accepts.
TACACS+
Vamos testar a funcionalidade de autenticação e autorização de administradores em equipamentos de rede usando o protocolo TACACS+. Na guia “Controle de dispositivos de rede” -> “Elementos de política” -> “Conjuntos de comandos TACACS+”, configuramos com antecedência um conjunto de comandos de teste “show run”, no qual permitiremos apenas a execução do comando show running-config. No domínio, criaremos 2 grupos de usuários - Administradores e Operadores. Daremos acesso total aos administradores e permitiremos que os operadores usem apenas o comando show run.
Na guia “Controle de dispositivos de rede” -> “Políticas de dispositivos de rede”, expandiremos o conjunto de políticas padrão. Especificamos nosso domínio como a fonte de autenticação, nas regras de autorização criamos regras para verificar a inclusão do usuário nos grupos Administradores ou Operadores.
Conectamos ao switch usando a conta admin0, tentamos show run e conf t - funciona, há autenticação bem-sucedida nos logs e os comandos inseridos são visíveis. Agora nos conectamos usando a conta operator0, tentamos show run - funciona, conf t - o comando não passa na autorização, como pretendido. Dos logs de autorização, fica imediatamente claro qual comando passou e qual não.
Resumo
No total: testamos MAB, PEAP, TLS, perfilamento e TACACS+, em geral, a funcionalidade básica que cobre a maior parte das necessidades de nossos clientes. Não desmontamos o stand, ainda será útil para testes futuros. Chegou a hora de olhar para o quadro geral.
Podemos dizer com segurança que a versão atual do NAICE fecha com sucesso os cenários básicos de NAC (802.1X com EAP-TLS/PEAP, MAB, CoA, acesso de convidado, VLANs/ACLs dinâmicos, TACACS+), mas em alguns pontos ainda há uma lacuna funcional para “benchmarks” (Cisco ISE e Aruba ClearPass) e uma série de soluções domésticas: suporte aprimorado para protocolos EAP, perfilamento profundo, integrações de postura/MDM.
A nova funcionalidade está sendo adicionada literalmente diante de nossos olhos e as atualizações secundárias são lançadas regularmente, então continuamos a acompanhar o desenvolvimento do produto. Nos próximos artigos, testaremos os recursos aprimorados da solução à medida que novas funcionalidades aparecerem. Estamos aguardando a implementação da Postura (verificações adicionais de dispositivos finais), modelos BYOD - será interessante ver o mecanismo de integração de dispositivos pessoais.
Há Vida Após o Cisco ISE? Análise e Teste do NAC Russo da Eltex em Laboratório de Rede
As soluções NAC (Network Access Control) têm sido tradicionalmente associadas a “monstros” como Cisco ISE ou Aruba ClearPass. Mas e se fosse possível construir um NAC russo a partir dos módulos “Medved”, “Lisa” e “Zayats”, colocá-los na vanguarda da rede e tentar cobrir os mesmos cenários? Nossa equipe trabalha com soluções NAC há mais de 19 anos. Os últimos anos têm sido particularmente interessantes: o segmento russo de NAC cresceu notavelmente, novos produtos aparecem regularmente e o interesse dos clientes nos impulsiona a analisar constantemente o mercado.
Este artigo faz parte de um ciclo sobre soluções NAC que estamos analisando em nosso laboratório de rede. Desta vez, o foco é o Eltex NAICE – um novato na área de controle de acesso, mas longe de ser um novato no mundo das redes. Vamos descobrir como ele é estruturado, quais tarefas ele realmente cobre e quão confiante ele se sente em comparação com sistemas NAC mais familiares. O nome do produto evoca imediatamente flashbacks do passado, do curso de segurança de rede Cisco da CBT-Nuggets, onde Keith Barker cantava ISE-ISE-Baby. NAICE.. ISE.. O fabricante acertou em cheio com o nome, ele cativa, faz você sentir um pouco de nostalgia.
Esquecemos o passado, vamos descobrir nosso novato. Arquiteturalmente, o sistema é um conjunto de contêineres docker, cada contêiner responsável por seu próprio módulo: RADIUS, TACACS+, servidor web e assim por diante. Cada módulo é nomeado em homenagem a animais do norte, para não se confundir, desempenhando seu papel:
Medved (Ursus) é o módulo central que gerencia todas as entidades do sistema, o esquema do banco de dados através da API interna.
Chayka (Larus) - WEB-GUI para administradores.
Baran (Ovis) fica teimosamente parado e distribui access-accept/reject para as solicitações recebidas.
Lisa (Vulpus) realiza o perfilamento com base nas informações coletadas, inclusive por meio de sondas DHCP, tendo-as retirado de Zayats, que coletou essas sondas.
Zayats (Lepus) - coletor de sondas DHCP.
O banco de dados PostgreSQL é usado como banco de dados. No momento em que escrevi este artigo, a primeira versão principal do NAICE 1.0 e a versão secundária 1.1 foram lançadas, então tive que reescrever algo em movimento - alguns pontos foram alterados para melhor. É bom ver o desenvolvimento do produto, e não o lançamento de novas versões apenas para marcar presença. E imediatamente observo que a atualização do sistema é feita com um comando, novas imagens são puxadas automaticamente do repositório público, muito conveniente.
Primeiros Passos
Com o lançamento da versão 1.0, a capacidade de instalar o sistema usando uma imagem OVA apareceu. Para ser franco, essa abordagem é muito mais amigável para o administrador do sistema e simplifica muito a vida ao implementar a solução para o integrador. Antes disso, era necessário instalar o sistema usando playbooks Ansible, embora tudo esteja descrito em detalhes na documentação. Então, a imagem foi baixada, iniciamos a máquina virtual. Inserimos eltex/eltex no console e começamos a configurar o sistema. Aqui somos recebidos por uma interface pseudo-gráfica que permite configurar os parâmetros básicos do servidor: endereço IP, fuso horário, DNS, NTP e outros. Configuramos, clicamos em <Finish>, aguardamos o lançamento de todos os contêineres e pronto, o sistema NAC Eltex NAICE está implantado. Abrimos o navegador e acessamos a porta 443 em nosso IP.
Além da interface web principal do sistema, apareceu um console para gerenciar o próprio software NAICE usando uma interface web separada, disponível na porta 8000. Antes de começarmos a configurar o sistema, vamos dar uma olhada no que está sob o capô do próprio servidor.
Console de Gerenciamento
Na guia principal, vemos a telemetria básica da máquina virtual. É possível abrir um terminal bash, às vezes útil se não houver acesso direto ao servidor via SSH. Em seguida, no menu na guia Docker, você pode ver quais contêineres estão em execução, se necessário, é possível reiniciá-los. Na seção Eltex, há guias onde você pode configurar o servidor de licenciamento, importar/exportar a configuração do servidor e também coletar logs para suporte técnico em caso de problemas. Em seguida, a seção NAICE. Na guia Backup, é possível exportar/importar o banco de dados do sistema. Na guia Certification, vemos as configurações dos certificados TLS usados para autenticação PEAP/TLS, bem como para o portal de convidados e a interface web do sistema. Aqui fiquei um pouco desapontado por não haver possibilidade de fazer uma solicitação CSR diretamente na interface do sistema. Terei que descompactar o openssl à moda antiga. Imediatamente gerei um certificado para o servidor, para não ter que voltar a isso mais tarde, e apliquei-o para autenticação EAP e WEB, para que o navegador não xingasse. A última guia é Configuration, dentro - configurações do agendador para remover backups de banco de dados, tempo de vida das sessões TACACS+, sessões de administradores do sistema e alguns outros parâmetros. No geral: é conveniente, você não precisa entrar no console para fazer um backup do banco de dados ou reiniciar o contêiner. Algumas configurações do próprio sistema, por exemplo, trabalhar com certificados, ainda são exibidas nesta interface, embora seja mais lógico colocá-las na interface principal. Esta é uma solução temporária do fabricante, mais tarde as configurações serão transferidas para a interface principal.
Montando o Stand
Vamos começar com a parte mais interessante: testar a funcionalidade do sistema. Vamos para a própria interface web do sistema. Ao entrar, somos recebidos por um painel com estatísticas de conexões. Não há nada para ver aqui por enquanto, primeiro vamos configurar nosso stand. Pareceu-me lógico, em primeiro lugar, montar um pequeno laboratório de um único fornecedor Eltex a partir de um conjunto mínimo - um switch de acesso e um controlador Wi-Fi com um ponto de acesso. O esquema é simples, nele veremos como a funcionalidade RADIUS/TACACS+ declarada funcionará.
Configuração Básica
Primeiro, adicionaremos nosso equipamento de rede como dispositivos NAS. Vamos para a guia “Administração” -> “Recursos de rede”. Adicionamos nosso switch MES2410-08DP e o controlador WLC-15. Especificamos o nome, modelo, um dos perfis pré-instalados no sistema (no nosso caso, Eltex MES e Eltex WLC), endereço IP, descrição. Em seguida, selecionamos um grupo e um local, usaremos essas abstrações nas políticas de acesso. Inserimos a chave para RADIUS e TACACS+ e.. o campo para inserir a chave TACACS+ está inativo. A dica diz “Não suportado pelo perfil selecionado”. Aconteceu que, por padrão, o TACACS+ está desativado em cada perfil de dispositivo. Vamos para as configurações de perfil e ativamos o protocolo. Em seguida, voltamos para as configurações do dispositivo, registramos a chave para TACACS+ e salvamos.
Vamos dar uma olhada mais de perto nas configurações do perfil do dispositivo. Além de ativar/desativar os protocolos RADIUS/TACACS+, temos configurações de atributos disponíveis para determinar o tipo de autenticação (802.1x ou MAB), configurações de atributos para trabalhar com MAB e o protocolo PAP ou EAP_MD5. As configurações de atributos também estão disponíveis para atribuição dinâmica de VLAN e ACL, configurações de CoA e atributos para redirecionar o cliente para o portal de convidados. Parece que há tudo o que você precisa - vamos verificar como tudo funciona na prática.
Agora, vamos configurar nosso diretório Active Directory de laboratório como uma fonte externa de contas. Vamos para a guia “Administração” -> “Gerenciamento de identidade” e adicionar uma fonte. Nas configurações, a seleção do esquema do diretório está disponível, há um esquema predefinido para AD. Inserimos o nome do domínio, em seguida, o nome e a senha do computador com o qual o sistema se conectará ao AD durante a autorização do usuário. Aqui está um ponto importante, o computador deve ser criado com antecedência pelo administrador do AD. Acredito que este ponto pode ser aprimorado, nos sistemas NAC de outros fabricantes, o computador é criado automaticamente. Em seguida, inserimos o login e a senha da conta com a qual o sistema procurará usuários do diretório usando LDAP. Inserimos o FQDN do domínio - o nome completo e a porta LDAP. A partir da versão 1.1, a capacidade de ativar o suporte a LDAPS apareceu. Verificamos a conexão com o servidor, como resultado do teste, vemos uma conexão LDAP bem-sucedida. Clicamos em <Next> e selecionamos os grupos para nossas futuras políticas. A última etapa é a seleção de atributos, por enquanto vamos pular isso. Salvamos as configurações.
RADIUS
Em termos gerais, a abordagem para configurar políticas de acesso é o mais clara possível, todos os parâmetros necessários estão próximos. O processo de configuração é consistente e rápido. Na guia “Políticas” -> “Elementos”, configuramos:
Perfis de autorização - o resultado da autorização do cliente.
Conjunto de protocolos permitidos - no momento, estes são PAP, MSCHAPv2, EAP-PEAP e EAP-TLS, bem como MAB.
Condições - na verdade, um construtor para criar condições compostas usadas em políticas de autenticação e autorização.
Dicionários - conjuntos de atributos IETF, por exemplo, um dicionário de atributos RADIUS padrão, bem como dicionários RADIUS de fornecedores conhecidos.
Não vamos nos aprofundar em cada etapa da configuração. Criaremos os perfis de autorização necessários para os testes com atributos diferentes (VLAN, ACL) e ativaremos os protocolos necessários - testaremos MAB, PEAP e TLS.
Vamos diretamente para a configuração dos conjuntos de políticas. Quem conseguiu trabalhar com o Cisco ISE reconhecerá a interface familiar, e eu acho que isso é uma vantagem. As políticas são agrupadas em vários níveis. O nível mais alto é o conjunto de políticas, também conhecido como Policy Set. Ao cair sob a condição apropriada, as sessões serão processadas de acordo com condições de nível inferior. Além disso, um conjunto específico de protocolos disponíveis é definido para cada conjunto de políticas. Dentro de cada conjunto de políticas, as políticas de autenticação e autorização são criadas separadamente. Na fase de autenticação, a política apropriada é selecionada para cada sessão do cliente de acordo com a condição apropriada e uma cadeia de identificação específica é aplicada, ou seja, a ordem de verificação das fontes de autenticação. Em seguida, na fase de autorização, dependendo das condições definidas, perfis de autorização específicos (resultados) configurados anteriormente são aplicados. Por exemplo, usuários do grupo condicional AD_Contractors receberão acesso limitado à rede usando o ACL aplicado à sessão e entrarão em seu VLAN_Contractors.
\nNa guia separada “Perfilamento”, é possível configurar políticas de perfilamento de conexões de clientes com base em vários parâmetros. Graças a essas políticas, um perfil específico pode ser atribuído ao cliente, por exemplo, Windows PC ou Eltex IP Phone. No momento, os perfis podem ser atribuídos com base em apenas dois mecanismos - determinar o fornecedor por OUI MAC-address e informações da cópia dos pacotes DHCP. Esperamos um aumento nesta lista e o aparecimento de perfilamento por CDP/LLDP, SNMP, NMAP, User-Agent.
Vamos começar a configurar. Primeiro, configuraremos as políticas de perfilamento para nossos clientes com antecedência. Estes serão pontos de acesso, PCs Windows, um smartphone e um “dispositivo malicioso” Linux PC. Não vamos nos deter nos detalhes, as políticas são configuradas de forma intuitiva. Para preencher corretamente os atributos como condições de perfilamento, estou ouvindo os pacotes DHCP com Wireshark. Além disso, nos endpoints na seção “Sondas”, você pode ver os dados recebidos usando o perfilamento.
Sugestão ao fornecedor: já faça uma biblioteca de perfis pré-preparada, pelo menos para seu equipamento - pontos de acesso, telefones IP, para que os usuários não precisem mexer nas políticas manualmente, apenas se precisarem corrigir algo.
Em seguida, configuraremos dois Policy Sets, separadamente para MAB e 802.1X. Como condição para entrar no conjunto de políticas, usamos um filtro por mecanismo de autenticação - Wireless/Wired MAB e Wireless/Wired 802.1X, respectivamente.
No conjunto MAB, configuraremos a autenticação mac dos pontos de acesso. Já existe um ponto na rede, o mecanismo de autenticação mac está configurado na porta do switch e já são visíveis tentativas de autorização malsucedidas. Adicionamos o mac do ponto ao grupo local “AP” e, ao mesmo tempo, configuramos a política de perfilamento com base nos dados dos pacotes DHCP. Nas regras de autorização, especificamos uma verificação para inclusão no grupo “AP” e perfilamento bem-sucedido com base no DHCP. O resultado da autorização configuraremos a aplicação dinâmica de VLAN para pontos de acesso. Reconectamos o ponto e nos alegramos com nosso primeiro access-accept. A VLAN correta foi aplicada à sessão, o ponto de acesso está na rede e registrado no controlador.
Como temos o perfilamento configurado para pontos de acesso, vamos tentar verificar se ele deixará nosso “malfeitor” entrar na rede. Substituímos o endereço mac do ponto de acesso e conectamos à porta do switch. Verificamos os logs - access-reject, não foi permitido na rede, o mecanismo de perfilamento funcionou.
Agora, vamos configurar a autenticação PEAP por contas AD. Tenho um PC preparado, registrado no domínio e o usuário user0 foi criado, que faz parte do grupo XXX-Users. No conjunto de políticas DOT1X, usaremos uma verificação para inclusão do usuário no grupo AD correto, bem como uma verificação do resultado bem-sucedido do perfilamento como condições de autorização. Tentamos nos conectar à rede usando um smartphone via Wi-Fi e um PC via porta do switch. Sucesso, nos alegramos com access-accepts. O PC e o telefone entraram em sua VLAN, mas usando o ACL aplicado à sessão, receberam acesso limitado à rede - há Internet e alguns endereços locais estão disponíveis - todo o resto está bloqueado.
Vamos complicar a tarefa, configurar a autenticação por certificados TLS. Os certificados de usuário e máquina já estão instalados no PC do domínio, e o certificado de nossa CA também foi adicionado como raiz confiável. Passaremos pela autorização nas condições já criadas para PEAP, e passaremos pela autenticação usando a cadeia de identificação configurada, que indica qual atributo de certificado usar como nome de usuário (Common Name).
Conectamos o PC à rede, nos alegramos com mais access-accepts.
TACACS+
Vamos testar a funcionalidade de autenticação e autorização de administradores em equipamentos de rede usando o protocolo TACACS+. Na guia “Controle de dispositivos de rede” -> “Elementos de política” -> “Conjuntos de comandos TACACS+”, configuramos com antecedência um conjunto de comandos de teste “show run”, no qual permitiremos apenas a execução do comando show running-config. No domínio, criaremos 2 grupos de usuários - Administradores e Operadores. Daremos acesso total aos administradores e permitiremos que os operadores usem apenas o comando show run.
Na guia “Controle de dispositivos de rede” -> “Políticas de dispositivos de rede”, expandiremos o conjunto de políticas padrão. Especificamos nosso domínio como a fonte de autenticação, nas regras de autorização criamos regras para verificar a inclusão do usuário nos grupos Administradores ou Operadores.
Conectamos ao switch usando a conta admin0, tentamos show run e conf t - funciona, há autenticação bem-sucedida nos logs e os comandos inseridos são visíveis. Agora nos conectamos usando a conta operator0, tentamos show run - funciona, conf t - o comando não passa na autorização, como pretendido. Dos logs de autorização, fica imediatamente claro qual comando passou e qual não.
Resumo
No total: testamos MAB, PEAP, TLS, perfilamento e TACACS+, em geral, a funcionalidade básica que cobre a maior parte das necessidades de nossos clientes. Não desmontamos o stand, ainda será útil para testes futuros. Chegou a hora de olhar para o quadro geral.
Podemos dizer com segurança que a versão atual do NAICE fecha com sucesso os cenários básicos de NAC (802.1X com EAP-TLS/PEAP, MAB, CoA, acesso de convidado, VLANs/ACLs dinâmicos, TACACS+), mas em alguns pontos ainda há uma lacuna funcional para “benchmarks” (Cisco ISE e Aruba ClearPass) e uma série de soluções domésticas: suporte aprimorado para protocolos EAP, perfilamento profundo, integrações de postura/MDM.
A nova funcionalidade está sendo adicionada literalmente diante de nossos olhos e as atualizações secundárias são lançadas regularmente, então continuamos a acompanhar o desenvolvimento do produto. Nos próximos artigos, testaremos os recursos aprimorados da solução à medida que novas funcionalidades aparecerem. Estamos aguardando a implementação da Postura (verificações adicionais de dispositivos finais), modelos BYOD - será interessante ver o mecanismo de integração de dispositivos pessoais.
