Habilitar Modelo de Lista de Permissões do ISE TrustSec (IP de Negação Padrão) com SDA

Introdução

Este documento descreve como habilitar o modelo de lista de permissão (IP de negação padrão) do TrustSec no SDA (Software Defined Access). Este documento envolve várias tecnologias e componentes que incluem Identity Services Engine (ISE), Digital Network Architecture Center (DNAC) e switches (Border and Edge).

Há dois modelos TrustSec disponíveis:

• Deny-List Model (Default Permit IP) - Neste modelo, a ação padrão é Permit IP e todas as restrições devem ser explicitamente configuradas com o uso de Security Group Access Lists (SGACLs). Isso geralmente é usado quando você não tem um entendimento completo dos fluxos de tráfego dentro da rede. Esse modelo é bastante fácil de implementar.

• Allow-List Model (Default Deny IP) - Neste modelo, a ação padrão é Deny IP e, portanto, o tráfego necessário deve ser explicitamente permitido com o uso de SGACLs. Isso geralmente é usado quando você tem um bom entendimento do tipo de fluxo de tráfego dentro de sua rede. Esse modelo requer um estudo detalhado do tráfego do plano de controle, bem como tem o potencial de bloquear TODO o tráfego, no momento em que for habilitado.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Dot1x/MAC Authentication Bypass (MAB)
• Cisco TrustSec (CTS)
• Protocolo de troca de segurança (SXP - Security Exchange Protocol)
• Proxy da Web
• Conceitos de firewall
• DNAC

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• 9300 Edge e 9500 Border Nodes (switches) com Cisco IOS^® versão 16.9.3
• DNAC 1.3.0.5
• Patch 3 do ISE 2.6 (dois nós - implantação redundante)
• DNAC e ISE são integrados
• Os nós de borda e borda são provisionados pelo DNAC
• O túnel SXP é estabelecido do ISE (alto-falante) para os dois nós de borda (ouvinte)
• Os pools de endereços IP são adicionados à integração do host

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Configurar

Diagrama de Rede

Configuração

Estas são as etapas para habilitar o Modelo de Lista de Permissões (IP de Negação Padrão):

1. Altere Switches Security Group Tag (SGT) de Desconhecido para Dispositivos TrustSec.
2. Desabilite a imposição baseada em função CTS.
3. Mapeamento IP-SGT em switches de borda e borda usando o modelo DNAC.
4. SGACL de Fallback usando Modelo DNAC.
5. Habilitar Lista de Permissões (IP de Negação Padrão) na Matriz trustsec.
6. Crie SGT para endpoint/usuários.
7. Crie SGACL para endpoint/usuários (para tráfego de sobreposição de produção).

Etapa 1. Altere Switches SGT de Desconhecido para Dispositivos TrustSec.

Por padrão, o SGT desconhecido é configurado para autorização do dispositivo de rede. Alterá-lo para TrustSec Device SGT oferece mais visibilidade e ajuda a criar SGACL específico para o tráfego iniciado pelo Switch.

Navegue para Centros de trabalho > TrustSec > Política Trustsec > Autorização de dispositivo de rede e altere-o para Trustsec_Devices de Desconhecido.

Etapa 2. Desative a aplicação baseada em função CTS.

• Uma vez que o modelo de Lista de Permissões (Negação Padrão) estiver em vigor, todo o tráfego será bloqueado na estrutura, o que inclui tráfego multicast e broadcast subjacente, como IS-IS (Sistema Intermediário para Sistema Intermediário), BFD (Detecção de Encaminhamento Bidirecional) e SSH (Shell Seguro).

• Todas as portas TenGig que se conectam à borda da malha, bem como à borda, devem ser configuradas com esse comando. Com isso em vigor, o tráfego iniciado a partir dessa interface e que chega a essa interface não está sujeito a aplicação.

Interface tengigabitethernet 1/0/1

no cts role-based enforcement

Note: Isso pode ser feito com o uso de um modelo de intervalo no DNAC para simplificar. Caso contrário, para cada switch, é necessário que ele seja concluído manualmente durante o provisionamento. O próximo trecho de código mostra como fazer isso por meio de um modelo DNAC.

interface range $uplink1

no cts role-based enforcement

Para obter mais informações sobre modelos DNAC, consulte este URL para o documento.

https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/2-3-5/user_guide/b_cisco_dna_center_ug_2_3_5/b_cisco_dna_center_ug_2_3_5_chapter_01000.html

Etapa 3. Mapeamento IP-SGT em switches de borda e borda com modelo DNAC.

A ideia é que o mapeamento de SGT de IP local esteja disponível nos switches, mesmo que todos os ISEs fiquem inativos. Isso garante que a subjacência esteja ativa e que a conectividade com os recursos críticos esteja intacta.

A primeira etapa é vincular serviços críticos a um SGT. Por exemplo, Basic_Network_Services/1000. Alguns desses serviços incluem:

• Sub-rede de subjacência/ISIS
• ISE/DNAC
• Ferramenta de monitoramento
• Sub-rede do AP em caso de OTT
• Servidor de terminal
• Serviços críticos - por exemplo, telefone IP

Um exemplo é mostrado abaixo:

cts role-based sgt-map <ISE/DNAC Subnet> sgt 1000

cts role-based sgt-map  sgt 2

cts role-based sgt-map <Wireless OTT Infra> sgt 1000

cts role-based sgt-map <Underlay OTT AP Subnet> sgt 2

cts role-based sgt-map <Monitoring Tool IP> sgt 1000

cts role-based sgt-map vrf CORP_VN <Voice Gateway and CUCM Subnet> sgt 1000

Etapa 4. SGACL de Fallback com Modelo DNAC.

Um mapeamento SGT não tem utilidade até que um SGACL relevante seja criado usando o SGT e, portanto, nossa próxima etapa seria criar um SGACL que atue como um Fallback local caso os nós do ISE fiquem inativos (quando os serviços do ISE estão inativos, o túnel do SXP fica inativo e, portanto, o SGACLs e o mapeamento IP SGT não são baixados dinamicamente).

Essa configuração é enviada para todos os nós de borda e borda.

ACL/contrato de fallback baseado em função:>

ip access-list role-based FALLBACK

permit ip

Dispositivos TrustSec para dispositivos TrustSec:

cts role-based permissions from 2 to 2 FALLBACK

Acima do SGACL Garanta a comunicação dentro dos switches de estrutura e dos IPs subjacentes

Dispositivos TrustSec para SGT 1000:

cts role-based permissions from 2 to 1000 FALLBACK

Acima, o SGACL garante a comunicação de switches e pontos de acesso com ISE, DNAC, WLC e ferramentas de monitoramento

SGT 1000 para dispositivos TrustSec:

cts role-based permissions from 1000 to 2 FALLBACK

Acima, o SGACL garante a comunicação dos pontos de acesso com o ISE, o DNAC, o WLC e as ferramentas de monitoramento para os switches

Etapa 5. Habilite o modelo de lista de permissões (Negação padrão) na matriz TrustSec.

O requisito é negar a maior parte do tráfego na rede e permitir uma extensão menor. Em seguida, serão necessárias menos políticas se você usar o padrão deny com regras explícitas de permissão.

Navegue para Centros de trabalho > Trustsec > Política TrustSec > Matriz > Padrão e altere-o para Negar tudo na regra catch final.

Note: Esta imagem representa (Todas as colunas estão em vermelho por padrão), Negação padrão foi habilitada e somente o tráfego seletivo pode ser permitido após a criação de SGACL.

Etapa 6. Criar SGT para endpoint/usuários.

No ambiente SDA, o novo SGT deve ser criado somente a partir da GUI do DNAC, pois há vários casos de corrupção do banco de dados devido à incompatibilidade do banco de dados SGT no ISE/DNAC.

Para criar o SGT, faça login em DNAC > Policy > Group-Based Access Control > Scalable Groups > Add Groups, uma página o redireciona para o ISE Scalable Group, clique em Add, insira o nome do SGT e salve-o.

O mesmo SGT é refletido no DNAC através da integração do PxGrid. Este é o mesmo procedimento para toda criação futura de SGT.

Etapa 7. Criar SGACL para endpoints/usuários (para tráfego de sobreposição de produção).

No ambiente SDA, o novo SGT só pode ser criado a partir da GUI do DNAC.

Policy Name: Domain_Users_Access

Contract : Permit

Enable Policy :√

Enable Bi-Directional :√

Source SGT : Domain Users (Drag from Available Security Group)

Destination SGT: Domain_Users, Basic_Network_Services, DC_Subnet, Unknown (Drag from Available Security Group)



Policy Name: RFC_Access

Contract : RFC_Access (This Contract contains limited ports)

Enable Policy :√

Enable Bi-Directional :√

Source SGT : Domain Users (Drag from Available Security Group)

Destination SGT: RFC1918 (Drag from Available Security Group)

Para criar um Contrato, faça login no DNAC e navegue até Política > Contratos > Adicionar contratos > Adicionar protocolo necessário e clique em Salvar.

Para criar um Contrato, efetue login no DNAC e navegue até Política > Controle de acesso baseado em grupo > Políticas de acesso baseado em grupo > Adicionar políticas > Criar política (com as informações fornecidas) agora clique em Salvar e, em seguida, em Implantar.

Uma vez que o SGACL/Contrato é configurado a partir do DNAC, ele reflete automaticamente no ISE. Aqui está um exemplo de visualização da matriz unidirecional para um sgt.

A Matriz SGACL, como mostrado nesta imagem, é uma exibição de exemplo para o modelo de lista de permissões (Negação padrão).

Verificar

Use esta seção para confirmar se a sua configuração funciona corretamente.

SGT do dispositivo de rede

Para verificar os switches SGT recebidos pelo ISE, execute este comando: show cts environmental-data

Aplicação em portas de uplink

Para verificar a aplicação na interface de uplink, insira estes comandos:

• show run interface <uplink>
• show cts interface <uplink interface>

Mapeamento local de IP-SGT

Para verificar os mapeamentos IP-SGT configurados localmente, insira este comando: sh cts role-based sgt-map all

SGACL de FALLBACK local

Para verificar FALLBACK SGACL, execute este comando: sh cts role-based permission

Note: O SGACL fornecido pelo ISE tem uma prioridade sobre o SGACL local.

Ativação da lista de permissões (negação padrão) em switches de estrutura

Para verificar o modelo da lista de permissões (Negação padrão), insira este comando: sh cts role-based permission

SGACL para endpoint conectado à malha

Para verificar o SGACL baixado do ISE, execute este comando: sh cts role-based permission

Verificar contrato criado pelo DNAC

Para verificar o SGACL baixado do ISE, execute este comando: show access-list <ACL/Contract Name>

Subjacente ao contador SGACL em switches de estrutura

Para verificar os acertos da política SGACL, execute este comando: Mostrar contador baseado em função cts

Troubleshooting

Esta seção fornece informações que podem ser usadas para o troubleshooting da sua configuração.

Problema 1. Caso ambos os nós do ISE estejam inoperantes. (Somente se o nó de borda for usado como ponto de aplicação norte-sul)

Caso ambos os nós do ISE estejam inativos, o mapeamento de IP para SGT recebido pelo ISE é removido nos nós de borda e todos os DGTs são marcados como desconhecidos, e todas as sessões de usuário existentes são interrompidas após 5 a 6 minutos.

Note: Esse problema é aplicável somente quando o acesso SGACL sgt (xxxx) -> desconhecido (0) é limitado a DHCP, DNS e porta proxy da Web.

Solução:

1. Criou um SGT (por exemplo, RFC1918).
2. Empurre o intervalo de IP privado RFC para a borda.
3. Limite o acesso ao DHCP, DNS e proxy da Web do sgt (xxxx) —> RFC1918
4. Crie/modifique sgacl sgt (xxxx) —> desconhecido com o contrato Permit IP.

Agora, se ambos os nós ise forem desativados, SGACL sgt—>hits desconhecidos e a sessão existente estará intacta.

Problema 2. Telefone IP com Voz Unidirecional ou Sem Voz.

A conversão de extensão para IP ocorreu no SIP e a comunicação de voz real ocorre no RTP entre IP e IP. O CUCM e o gateway de voz foram adicionados ao DGT_Voice.

Solução:

1. A mesma localização ou comunicação de voz leste-oeste pode ser habilitada permitindo o tráfego de IP_Phone —> IP_Phone.
2. O restante do local pode ser permitido pelo intervalo do protocolo RTP de permissão em DGT RFC1918. O mesmo intervalo pode ser permitido para IP_Phone —> Unknown.

Problema 3. O Ponto de Extremidade de VLAN Crítica Não Tem Acesso à Rede.

O DNAC provisiona um switch com VLAN crítica para dados e, de acordo com a configuração, todas as novas conexões durante a interrupção do ISE obtêm VLAN crítica e SGT 3999. A política de negação padrão do trustsec restringe a nova conexão para acessar qualquer recurso da rede.

Solução:

Enviar SGACL para SGT crítico em todos os switches de borda e borda usando o modelo DNAC

cts role-based permissions from 0 to 3999 FALLBACK

cts role-based permissions from 3999 to 0 FALLBACK

Esses comandos são adicionados à seção de configuração.

Note: Todos os comandos podem ser combinados em um único modelo e podem ser enviados durante o provisionamento.

Problema 4. VLAN crítica de drop-in de pacotes.

Uma vez que a máquina está em VLAN crítica devido a nós de ISE inativos, há uma queda de pacote a cada 3-4 minutos (máximo de 10 quedas observadas) para todos os pontos finais na VLAN crítica.

Observações: Os contadores de autenticação aumentam quando os servidores estão INATIVOS. Os clientes tentam se autenticar com o PSN quando os servidores são marcados como DEAD.

Solução/Solução alternativa:

Idealmente, não pode haver nenhuma solicitação de autenticação de um endpoint se os nós PSN do ISE estiverem desativados.

Envie este comando por push em um servidor radius com DNAC:

automate-tester username auto-test probe-on

Com esse comando no switch, ele envia mensagens de autenticação de teste periódicas ao servidor RADIUS. Ele procura uma resposta RADIUS do servidor. Uma mensagem de êxito não é necessária - uma autenticação com falha é suficiente porque mostra que o servidor está ativo.

Informações adicionais

Modelo final de DNAC:

interface range $uplink1

no cts role-based enforcement

! .

cts role-based sgt-map <ISE Primary IP> sgt 1102

cts role-based sgt-map <Underlay Subnet> sgt 2

cts role-based sgt-map <Wireless OTT Subnet>sgt 1102

cts role-based sgt-map <DNAC IP> sgt 1102

cts role-based sgt-map <SXP Subnet> sgt 2

cts role-based sgt-map <Network Monitoring Tool IP> sgt 1102

cts role-based sgt-map vrf CORP_VN <Voice Gateway Subnet> sgt 1102

!

ip access-list role-based FALLBACK

permit ip

!

cts role-based permissions from 2 to 1102 FALLBACK

cts role-based permissions from 1102 to 2 FALLBACK

cts role-based permissions from 2 to 2 FALLBACK

cts role-based permissions from 0 to 3999 FALLBACK

cts role-based permissions from 3999 to 0 FALLBACK

Note: Todas as interfaces de uplink nos nós de borda são configuradas sem imposição e presume-se que o uplink se conecta apenas ao nó de borda. Nos nós de borda, as interfaces de uplink em direção aos nós de borda precisam ser configuradas sem imposição, e isso deve ser feito manualmente.