Cisco ISE —Customizando políticas de autenticação e autorização
Fala pessoal, tudo bem?
Continuando nossa série sobre o ISE — começamos pelo básico nos artigos ISE Basics — Parte 1 e ISE Basics — Parte 2 e depois fizemos um lab completo no último artigo: Cisco ISE — Autenticação MAB e 802.1X — vamos agora customizar as políticas de autenticação e autorização.
A intenção é que você perceba a granularidade do ISE.
Nosso objetivo: Vamos negar a regra padrão de autenticação e não vamos mexer na regra de MAB. Mas, para 802.1X, vamos autenticar apenas os switches dentro do grupo “Switches” e os usuários criados localmente no ISE que fazem parte do grupo Lab_Admin. Por fim, para essa mesma regra, vamos aplicar uma VLAN e uma DACL (Downloadable ACL) caso a autenticação seja bem sucedida.
Lembrando que esse artigo é uma continuação dos anteriores, caso você não entenda algo, consulte eles, ok?
Vamos começar clicando em Policy > Conditions > Authentication e Compound Conditions. Aqui, vamos criar uma nova condição para que uma autenticação ocorra. Nela vamos selecionar apenas o grupo “Switches” que criamos nos artigos anteriores, que é onde colocamos o nosso switch de teste “SW1”.
Agora aplicamos essa nova condição. Vá para Policy > Authentication, negue a última regra padrão (isso só para essa versão que estamos usando, a 2.1) e edite a regra de Dot1x. Na condição, remova Wireless_802.1x, altere a regra para AND, e selecione a condição que criamos acima. Por fim, na última caixa, altere qual base de dados o ISE irá pesquisar. Altere de All_User_ID_Stores para Internal Users. Ou seja, apenas usuários criados localmente poderão se autenticar. Caso houvesse uma base do AD integrada (futuramente faremos isso), esses usuários externos não poderiam se autenticar. Por fim, salve tudo.
Vamos agora para Policy > Authorization e crie uma nova regra. Nomeie como está abaixo e edite a condição. Selecione dentro de User Identities Store, o grupo Lab_Admin. É nesse grupo que nosso usuário de teste “Fernando” está inserido (também foi criado nos artigos anteriores).
Ligue a VM do Windows e vamos testar a autenticação, que ocorrerá com sucesso. Veja abaixo em Operations > Radius > Live Logs.
Caso tentemos autenticar um usuário “Henrique” que eu criei agora, mas não faz parte do grupo Lab_Admin, veja o resultado:
O processo de autenticação passou, pois a condição para o switch está OK, mas o usuário não obteve autorização para o login. O processo deu match na nossa regra de autenticação mas, na autorização, ele bateu na regra default, que nega o acesso. Analise a figura pra entender bem. A quantidade de informação é grande, e isso facilita muito o troubleshooting.
Cavando um pouquinho mais, vamos agora ao invés de apenas permitir o acesso, vamos criar um profile e aplicar configurações no switch, caso a autenticação seja bem sucedida.
Clique em Policy > Policy Elements > Results > Authorization > Downloadable ACLs. Conforme a figura, vamos criar uma ACL que será enviada pelo ISE para o switch especificamente para esse usuário nessa porta que ele se autenticou.
A granularidade aqui é de uma ACL comum ok? No nosso exemplo, vamos apenas negar o ping para o ISE. De resto, tudo permanece liberado.
Agora, ainda nesse menu, vá no item acima e à esquerda: Authorization Profiles. Acompanhe na figura, você irá escolher a DACL que criamos e também irá setar uma VLAN específica para esse usuário. No nosso caso será a VLAN 1 mesmo, já que não criamos outra.
E aí ficou fácil! Vamos voltar pra Autenticação e Autorização e, ao invés de selecionar “PermitAccess”, vamos escolher esse Authorization Profile que acabamos de criar. Veja, como ficou:
Vamos testar novamente a autenticação. Dê um bounce na placa de rede, e um clear authentication sessions no switch. Entre com o usuário “Fernando” na caixa que vai aparecer no Windows e analise os logs:
Repare acima que a ACL foi enviada com sucesso para o switch.
Abrindo o log da ACL (na lupinha em Details), veja a mensagem de sucesso e o nosso network device “SW1”.
No switch, entre com o comando show authentication sessions int e0/2 details e você terá o seguinte:
SW1#show authe sessions int e0/2 details
Interface: Ethernet0/2
MAC Address: 5000.0003.0000
IPv6 Address: Unknown
IPv4 Address: 10.1.1.2
User-Name: fernando
Status: Authorized
Domain: DATA
Oper host mode: single-host
Oper control dir: both
Session timeout: N/A
Restart timeout: N/A
Periodic Acct timeout: N/A
Session Uptime: 49s
Common Session ID: 0A01010A0000000E000E343B
Acct Session ID: 0x00000004
Handle: 0xA9000002
Current Policy: POLICY_Et0/2Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
Security Policy: Should Secure
Security Status: Link UnsecureServer Policies:
Vlan Group: Vlan: 1
ACS ACL: xACSACLx-IP-Switches_DACL-5e5a93c0Method status list:
Method Statemab Stopped
dot1x Authc Success
Repare na sessão “Server Policies” destacada. Você verá que foi aplicada a vlan 1 e a ACL que criamos nessa interface eth0/2 apenas.
Para complementar, veja também o show ip access-list.
SW1#show ip access-list
Extended IP access list xACSACLx-IP-Switches_DACL-5e5a93c0 (per-user)
1 deny icmp any host 10.1.1.100
2 permit ip any anyFinalizando, vá para a máquina Windows e tente pingar o IP 10.1.1.100 e também o 10.1.1.10 (que é o SW1) ;D
Muito obrigado por lerem e espero que tenham curtido o artigo! Tem muito mais coisa interessante pela frente. Acho que dá pra escrever durante o ano todo só de ISE =P
Se você gostou, deixa seu “claps” aí do lado esquerdo e compartilhe nos seus grupos. Você também pode me seguir e a TechRebels!
Sobre o autor:
Fernando Mantovani Pierobon trabalha há 18 anos na área de TI sendo 14 com segurança da tecnologia da informação.
É formado em Ciências da Computação e CCIE Security #63268.
