Artigo originalmente publicado no medium em Março de 2020 pelo mesmo autor. As configurações e exemplos continuam válidos.

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/2
Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
      Security Policy:  Should Secure
      Security Status:  Link Unsecure
Server Policies:
           Vlan Group:  Vlan: 1
              ACS ACL:  xACSACLx-IP-Switches_DACL-5e5a93c0
Method status list:
      Method            State
mab                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 any

Finalizando, 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.

Um abraço!!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Outubro de 2020 pelo mesmo autor. As configurações e exemplos continuam válidos.

Fala pessoal, tudo blz? Continuando nossa conversa sobre NAT, é agora que a coisa fica legal :D

Essa é nossa topologia (idem do artigo anterior). Faremos um NAT da DMZ para a Internet. Observem apenas esses dois eqtos na figura abaixo.

Agora vejam a configuração de rotas do router da DMZ: apenas localmente conectadas. Não há rota estática.

E agora para o router da Internet, idem.

Temos então um firewall interligando a rede DMZ e a rede Internet que não sabem como chegar um no outro.

Nosso objetivo prático é da DMZ dar um telnet no router Internet.

Vamos criar uma regra de Manual NAT, que iniciamos a falar dela no artigo anterior (aqui), com origem da DMZ para a Internet e iremos manipular o tráfego dessa forma:

O IP Real do router de Internet é 200.200.200.10, então, à partir do router da DMZ, vamos tratar o pacote original.

Da DMZ nossa origem é o 192.168.0.10 e o destino não pode ser na rede 200, já que não conhecemos essa rede. Então, o destino será um novo IP, o 192.168.0.9 - aqui o firewall faz proxy-arp desse IP nessa interface (no caso a DMZ). De forma básica, à partir desse momento o IP .9 "começa a exitir" na rede e quem responde por ele é o firewall.

Após o pacote atravessar o Firepower, o IP que antes era 192.168.0.10, irá virar 200.200.200.9 (essa parte é como um NAT tradicional de origem, ou Auto NAT pra nós da Cisco), e o destino do pacote, ao invés de 192.168.0.9, será o 200.200.200.10.

Feito o deploy da política, vamos testar. À partir do router da DMZ, vejam:

Nós demos telnet no IP 192.168.0.9 e, ao atravessarmos o firewall, nós chegamos no IP 200.200.200.10 com o IP 200.200.200.9

De forma prática, esse desenho ilustra o que aconteceu.

Finalmente, apenas para verificação, vejam os MAC-ADDRESSES de cada um dos IPs envolvidos. A telinha preta no fundo é o SSH do firewall e o IP e MAC das duas interfaces envolvidas. Reparem nos MACs dos IPs nos dois switches ;)

Obrigado por lerem!

Abraços!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Setembro de 2020 pelo mesmo autor. As configurações e exemplos continuam válidos.

Fala pessoal!!! Primeiramente uma satisfação pra vocês: mudei de emprego e as 24h ficaram pequenas. Minha intenção era continuar com os artigos de ISE - o próximo seria RADIUS com AAA - mas perdi o lab. Então, como o foco no trabalho agora está no grandioso - e digo de verdade - Firepower, vamos com Cisco Threat Defense na veia!

Até a versão 8.2 do ASA, havia somente uma versão de NAT disponível - com algumas variações na sua aplicação. À partir da 8.3, a Cisco incluiu uma possibilidade adicional.

O que o ASA tem a ver com o FTD? Bom, o código do ASA faz parte do FTD e o nome dele é LINA. Após o processamento do pacote em camada 3 e 4, ele envia ao motor do SNORT para inspeção profunda. Em um outro artigo, falaremos mais disso.

Mas enfim, o NAT clássico do ASA agora é o Auto NAT e o NAT "novo" se chama Manual NAT.

Começando pelo NAT clássico então, nossa topologia é essa: vamos traduzir da DMZ para a Internet.

Obs: Os IPs das interfaces do FW são sempre final .1

Imaginando o FW como uma parede, pensamos que o IP 192.168.0.10, ao atravessar a parede, virará um outro IP, no caso o 200.200.200.100.

Simples dessa forma. Não importa pra "onde" queremos ir =)

Na imagem abaixo, repare na regra de NAT e no tipo dele em vermelho. Já o amarelo, mostra a interface de origem e a de destino.

Abaixo, repare no pacote original, com o IP 192.168.0.10 e o pacote traduzido 200.200.200.100.

Ao salvar, veja como fica a política de NAT. Em amarelo, significa que vamos traduzir as requisições DNS que derem match nessa regra - essa parte é especificamente importante para o PAT de acesso à internet que veremos adiante.

No router de Internet, conseguimos pingar o 200.200.200.100 e ao dar telnet, acessamos o router da DMZ.

Esse tipo de NAT traduz a origem da requisição, e ele é indicado pela Cisco para os casos simples de tradução de IP, como por exemplo ao acessarmos a Internet. Da mesma forma poderíamos traduzir uma rede para o IP da interface externa do firewall, fazendo dessa forma um PAT - Port Address Translation - clássico.

Veja na figura abaixo como ficaria: O tipo de NAT é dinâmico, e a origem é toda a rede da DMZ_Inside. O destino é o IP da interface de destino, no caso, a interface internet.

Ao acessar o router de Internet, à partir do router da DMZ_Inside, veja que a conexão de origem parte do IP 200.200.200.1, que é o IP da interface internet do Firewall.

Nossa política de NAT ficou assim:

No próximo artigo, falaremos do Manual NAT, uma abordagem mais complexa e granular.

Obrigado por lerem!

Abraços!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Outubro de 2019 pelo mesmo autor. As configurações e exemplos continuam válidos.

Fala pessoal, tudo bem? Sou o Fernando Mantovani Pierobon e esse é o meu primeiro artigo aqui na TechRebels. A inspiração pra começar a escrever veio dos anos de estudo que levei até conseguir o CCIE Security (#63268).

Vamos então abordar boa parte das tecnologias de segurança da Cisco e hoje começaremos do básico. Vamos brincar com VPN site-to-site autenticando com certificado digital e PSK. Usei roteadores, mas o conceito é exatamente o mesmo entre firewalls (seja ASA ou o Firepower), ok?

Topologia e arquitetura

• ISP - Internet e NTP Server
• R1 - CA Server
• R2 - Site 1
• R3 - Site 2

Obs: Para os estudos do CCIE acostumei a não usar mais rotas estáticas e sim um protocolo de roteamento dinâmico, sempre com autenticação. Isso consta no blueprint e cai na prova

R1

Após a conectividade estar ok a primeira coisa que fazemos é a geração da chave rsa

crypto key generate rsa label rsakey

Consulte a chave depois com o comando abaixo:

R1#sh crypto key mypubkey rsa
% Key pair was generated at: 11:27:31 BRT Oct 15 2019
Key name: rsakey
Key type: RSA KEYS
Storage Device: private-config
Usage: General Purpose Key
Key is not exportable.

Configuração da CA

Em seguida, vamos criar a CA Server. O método de enrollment que usaremos será via http, então precisamos habilitar o http server no router

R1#ip http server
crypto pki server ca-server
database level complete
no database archive
issuer-name CN=r1.lab.com
grant auto

O método de geração do certificado, que no nosso caso é automático (grant auto). Caso fosse manual, após criar a requisição no R2 ou R3, teríamos que entrar com esse output na CA Server que irá gerar o certificado, copiá-lo e depois importá-lo no R2 ou R3. Então, pra facilitar (e como é um lab), podemos usar o modo automático.

O comando database level configura o nível de informações que será guardada na base de dados e o issuer-name o nome do host.

Feito isso, é só dar um no shutdown na CA Server

Para ver o status:

R1#sh crypto pki server
Certificate Server ca-server:
Status: enabled
State: enabled
Server's configuration is locked (enter "shut" to unlock it)
Issuer name: CN=r1.lab.com
CA cert fingerprint: 090C3088 5F798668 32B78445 90C3080C
Granting mode is: auto
Last certificate issued serial number (hex): 3
CA certificate expiration timer: 11:28:50 BRT Oct 14 2022
CRL NextUpdate timer: 17:28:17 BRT Oct 18 2019
Current primary storage dir: nvram:
Database Level: Complete - all issued certs written as <serialnum>.cer

Caso a gente não habilite o ip http server, o status da CA Server estaria disabled.

R2 e R3

A config da CA está pronta, agora vamos criar um trustpoint em cada um dos sites.

Após criar a chave rsa utilizando o mesmo comando anterior - crypto key generate rsa label rsakey - vamos criar o trustpoint de nome trustp-r2

crypto pki trustpoint trustp-r2
enrollment url http://10.0.1.1:80
fqdn r3.lab.com
ip-address ethernet0/0
subject-name CN=r3.lab.com
revocation-check crl
rsakeypair rsakey

O enrollment url que apontamos para o R1, o fqdn e subject-name que será incluído no certificado, o nome da rsakey que criamos, e eu ainda gosto de adicionar o IP do router no certificado.

Finalizada a config, vamos autenticar o trustpoint e fazer o download do certificado do R1:

R2(config)# crypto pki authenticate trustp-r2
Certificate has the following attributes:
Fingerprint MD5: 090C3088 5F798668 32B78445 90C3080C
Fingerprint SHA1: 66F18FBC 68EE0171 25DEAFA3 A6A52B7F AD282B50
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.

Por fim, vamos requisitar o nosso certificado para a CA Server, ou seja, vamos fazer o enrollment do R2

R2(config)#crypto pki enroll trustp-r2
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
Password: xxxxxx
Re-enter password: xxxxxx
% The subject name in the certificate will include: CN=r2.lab.com
% The subject name in the certificate will include: r2.lab.com
% Include the router serial number in the subject name? [yes/no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose trustp-r2' command will show the finge rprint.

Após apenas alguns segundos, receberemos as mensagens abaixo:

R2(config)#
*Oct 15 14:34:43.556: CRYPTO_PKI: Certificate Request Fingerprint MD5: 27936625 CD9C0DC5 D3C7A746 03C2FDED
*Oct 15 14:34:43.557: CRYPTO_PKI: Certificate Request Fingerprint SHA1: 1A927C3 1 5097B653 78FBEFC5 F19B8682 BD06CED7
R2(config)#
*Oct 15 14:34:43.613: %PKI-6-CERTRET: Certificate received from Certificate Authority

Temos agora o nosso certificado que será usado para autenticar a VPN site-to-site com o R3 Obs: Fazer o mesmo procedimento no R3

Para verificarmos o nosso certificado e o certificado da CA que baixamos:

R2#sh crypto pki certificates
Certificate
Status: Available
Certificate Serial Number (hex): 02
Certificate Usage: General Purpose
Issuer: cn=r1.lab.com
Subject: Name: r2.lab.com
IP Address: 10.0.2.2
ipaddress=10.0.2.2+hostname=r2.lab.com
cn=r2.lab.com
Validity Date:
start date: 11:34:43 BRT Oct 15 2019
end date: 11:34:43 BRT Oct 14 2020
Associated Trustpoints: trustp-r2
Storage: nvram:r1labcom#2.cer
CA Certificate
Status: Available
Certificate Serial Number (hex): 01
Certificate Usage: Signature
Issuer: cn=r1.lab.com
Subject: cn=r1.lab.com
Validity Date:
start date: 11:28:50 BRT Oct 15 2019
end date: 11:28:50 BRT Oct 14 2022
Associated Trustpoints: trustp-r2
Storage: nvram:r1labcom#1CA.cer

VPN

Vamos agora pra configuração da VPN IPSec site-to-site:

Em primeiro lugar vamos definir o tráfego Interessante, ou o tráfego que será permitido passar pelo tunel

ip access-list extended VPN-R3
permit ip 172.16.2.0 0.0.0.255 172.16.3.0 0.0.0.255

Obs: Repare que é apenas o tráfego das loopbacks dos dois routers. Essas subnets simulam 2 servidores da rede LAN de cada site

crypto isakmp policy 10
authentication rsa-sig
encryption aes 256
hash sha256
group 2

O comando authentication rsa-sig vem por default e não aparece na config. Caso fôssemos usar pre-shared-key, teríamos que explicitar auth pre-shared-key

crypto ipsec transform-set TSET esp-3des esp-sha-hmac
!
crypto map CMAP 10 ipsec-isakmp
set peer 10.0.3.3
set transform-set TSET
match address VPN-R3
reverse-route static

Habilitar a VPN na interface

interface Ethernet0/0
ip address 10.0.2.2 255.255.255.0
crypto map CMAP

Reparem que nós não temos rota para a loopback do R3 - afinal eu não publiquei ela no BGP e não adicionei nenhuma rota estática

R2#show ip route
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
B 10.0.1.0/24 [20/0] via 10.0.2.10, 00:14:54
C 10.0.2.0/24 is directly connected, Ethernet0/0
L 10.0.2.2/32 is directly connected, Ethernet0/0
B 10.0.3.0/24 [20/0] via 10.0.2.10, 00:14:54
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.2.0/24 is directly connected, Loopback0
L 172.16.2.2/32 is directly connected, Loopback0
R3#sh run | s router bgp
router bgp 3
bgp log-neighbor-changes
network 10.0.3.0 mask 255.255.255.0
neighbor 10.0.3.10 remote-as 123
neighbor 10.0.3.10 password cisco

A solução então é entrar com o comando destacado reverse-route static, que injeta uma rota estática baseado na nossa ACL de tráfego interessante

R2(config-crypto-map)#reverse-route ?
remote-peer Create route in route table for remote tunnel endpoint
static Create routes based on static ACLs permanently

Verificação

Ping

Fase 1

Fase 2

Alternando para pre-shared-key, teríamos essas mudanças na config

crypto isakmp policy 10
encr aes 256
hash sha256
authentication pre-share
group 2
crypto isakmp key cisco address 10.0.2.2

E após mudar o mesmo no R3, verificaríamos

Espero que tenham curtido.

Um abraço!!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Dezembro de 2020 pelo mesmo autor. As configurações e exemplos continuam válidos.

Fala pessoal, todos bem? Espero que sim!

Vamos falar sobre um dos meus assuntos preferidos hoje: AAA (Authentication, Authorization e Accounting)!

Nosso objetivo é logar em um router via SSH, com um usuário do AD autenticando no ISE e obter privilégio 15 automaticamente.

Relembrando:

O quarto artigo do blog mostra o processo de configurar o NAD (Router, Switch, etc.) no ISE. Se você não leu, clique aqui.

No último artigo mostrei como fazer a integração entre o AD e o ISE. Veja aqui.

Bom, nesse momento, temos nosso router configurado (servidor Radius) e o AD integrado ao ISE. Repare na topologia acima. Estamos configurando o R1.

Vamos aplicar as configurações de AAA no roteador:

aaa authentication login SEMAUTENTIC none
aaa authentication login ISE group ISE
aaa authorization exec ISE group ISE

O primeiro comando, cria um grupo de autenticação "sem autenticação". SEMAUTENTIC é o nome que eu dei e associei a um método 'none'. Vamos configurar esse método na line con do router, para não ficarmos presos "pra fora" do roteador caso algo dê errado.

O segundo comando cria um grupo de autenticação "ISE" e associa ao grupo "ISE", que é o nome do servidor que eu criei no artigo com o link acima. Os nomes iguais foram preferência minha, ok? Eles não precisam ser iguais.

Agora que já sabemos "quem" é a pessoa que vai logar no router, veremos "o que" ela pode fazer. Essa parte é bem simples e menos granular do que usando o protocolo TACACS.

Nós já definimos os métodos de autenticação e autorização e apontamos eles para o grupo de servidores Radius chamado ISE. Agora, vamos linkar esses métodos no acesso aos eqtos.

line con 0
 logging synchronous
 login authentication SEMAUTENTIC

line vty 0 4
 authorization exec ISE
 login authentication ISE
 transport input ssh

Repare na line vty que estou usando SSH. Portanto, não esqueça de gerar a chave rsa com o comando:

crypto key generate rsa label MINHA-CHAVE modulus 2048

Finalizamos a parte do router.

Vamos fazer um teste de autenticação agora sem nenhuma configuração adicional no ISE. Veja o resultado:

Olhando os logs do ISE:

Obs: Pessoal, não vou ficar repetindo os menus ou como encontrar a informação na GUI do ISE. Está tudo explicado no segundo artigo aqui.

O padrão do ISE, é procurar em todas as bases de usuários configuradas. Portanto, ele procurou no AD, mas não encontrou meu usuário 'fernando'.

Vou então criá-lo agora no AD (feito!) e também dentro do ISE, mas apontando a senha para o 'AD'. Isso me permitirá adicionar esse user dentro de um grupo do próprio ISE.

Obs: Tem inúmeras formas de fazer essas associações, seja por grupo no AD, no ISE, etc…

Reparem no "Password Type":

Fazemos outro teste de autenticação agora e vejam o resultado:

O usuário se autenticou com sucesso e bateu nas políticas padrão de autenticação e autorização.

Vamos agora fechar um pouco nossa política: Na autenticação, permitiremos apenas usuários do AD e, caso eles sejam membros do grupo AD-Admins (que criaremos no ISE), irão se logar e obter privilégio 15 automaticamente (sem usar senha de enable).

Especificando o AD como única base de usuários para autenticação:

Criando grupo AD-Admins no ISE e adicionando o usuário fernando.

Vamos configurar um Authorization Profile e, usando o atributo av-pair, setar o privilégio (priv-lvl) 15:

Na política de autorização, criamos uma nova regra e selecionamos esse profile nela:

Ah, reparem na condição "Identity-AD-Admins". Essa condição fui eu que criei e ela simplesmente checa se o usuário faz parte do grupo AD-Admins que criamos acima.

Selecionando a condição "IdentityGroup Name", ao clicar no box abaixo, você seleciona o grupo que você quer e pronto.

Veja como fica:

E, finalmente, tudo pronto!

Vamos testar? Reparem no privilégio que o usuário recebe ao se autenticar.

A política de autenticação ainda é a "Default", mas ela só puxa usuários do AD e não mais de todas as bases configuradas no ISE. A política de autorização é que a nós criamos: Network Admins (AD), e entrega privilégio 15 automaticamente para os membros do grupo AD-Admins.

E assim finalizamos por hoje! No próximo artigo faremos o mesmo com TACACS, mas iremos autorizar apenas alguns comandos específicos!

Esse foi o último artigo do ano de 2020 e quero aproveitar e desejar a todos um excelente Natal e um Ano Novo com muitos desafios, pois são eles que nos empurram pra frente e nos faz termos sucesso na vida profissional!

Um abraço!!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Novembro de 2019 pelo mesmo autor. As configurações e exemplos continuam válidos.

Introdução

Bom, pra quem não conhece, o Cisco ISE (Identity Services Engine) é o software de gestão de políticas e identidades da Cisco. Com ele:

Você centraliza e unifica o controle de acesso seguro à sua rede

- O ISE é o software central — onde todas as bases de usuário interna ou externa (AD por exemplo) — que irá permitir e controlar todo o acesso à sua rede. Além disso, todas as políticas de autenticação, autorização e accounting, também serão definidas nele. O que tal usuário, ou grupo, pode acessar e o quanto ele consegue fazer, além de logar cada ação, será definido no Cisco ISE.

Aumenta a visibilidade e identificação de dispositivos

- Através de vários tipos de probes diferentes, o ISE é capaz de identificar o sistema operacional de cada endpoint, seja computadores pessoais, smartphones, dispositivos como impressoras e inúmeros outros. Essa identificação automática permitirá que você construa regras baseadas também no tipo de dispositivo da sua rede.

Permite implementar rede Guest e BYOD

- Gerência centralizada dos usuários guest da sua rede, permitindo self-register (registro próprio) integrado com Facebook e Linkedin, através de sponsor (quando uma pessoa da empresa precisa autorizar a criação da conta) ou simplesmente entrando com um usuário e senha previamente criados.

Aumenta a segurança da rede

- Permite que access-lists de firewall por exemplo sejam criadas não utilizando um IP de origem e destino, mas pessoas, usuários da rede. Além disso, regras de postura, verificando patches de atualização do Sistema Operacional, versão de base do AV e muitos outros irão aumentar a segurança do seu ambiente.

Versões

Além dos appliances SNS e das versões Small, Medium e Large de VMs, a Cisco disponibiliza para trial e PoC uma versão mini do ISE que vem com os 3 tipos de licenças habilitadas para até 100 endpoints. Essa licença tem duração de 90 dias, o que é um excelente tempo pra treinar ou mostrar o valor da ferramenta nos clientes ou na sua empresa.

À partir da versão 2.2 (no momento que escrevo esse artigo a versão 2.7 acabou de ser lançada) é necessário 8 GB de RAM para subir o ISE Evaluation. Como meu modesto notebook possui apenas essa quantidade de memória, vamos mostrar a versão 2.1, que necessita de apenas 4Gb de RAM e que para os recursos e funcionalidades que falaremos é suficiente.

A diferença à partir da versão 2.2 é de uma nova interface gráfica para o set de políticas. Ela está bem mais moderna, limpa e objetiva. Se você aprender com essa interface da 2.1, que não é nada ruim, não terá nenhuma dificuldade em se adaptar às novas telas 😉

Instalação

Faça o download do .ova (no nosso caso o ISE mini) direto do site da Cisco (cisco.com/go/download) e importe esse arquivo no seu VMware Workstation por exemplo. Após ligar a máquina, o primeiro passo é digitar setup no lugar do nome do usuário (o usuário padrão admin será criado e sua senha definida durante esse processo).

Nesse setup inicial iremos fazer as configurações básicas como em qualquer dispositivo de rede: IP, máscara, gateway, NTP, DNS e etc. Após isso, e a senha do usuário admin definida, o ISE irá fazer alguns testes de leitura e escrita de disco e memória (que mesmo não atendido 100% pode ser usado nessa versão Evaluation), e vai começar a criar a base de dados. Esse processo é que costuma demorar um pouco mais de tempo.

Finalizado, teremos um prompt de login, onde, após se logar, você poderá ver toda essa configuração inicial com o bom e velho comando show running-config.

Dica: Existe um usuário admin para se logar na CLI e um usuário admin (são iguais mesmo) pra se logar na GUI. As senhas desses usuários podem ser diferentes, e a da GUI expira (por padrão, mas pode ser alterado), então é comum que os administradores façam confusão, tentando se logar na CLI usando uma senha da GUI, ou achando que é o mesmo usuário.

Caso precise, altere a senha do admin da GUI com o comando: application reset-passwd ise admin

E, se preciso, altere a senha do admin da CLI com o comando: password

Caso perca o acesso via CLI, será necessário bootar com a ISO do ISE e seguir com a recuperação da senha. Aqui tem um doc bem explicativo do processo link.

Além disso, um outro comando muito útil é o show application status ise, que irá mostrar o status de cada um dos processos do ISE. Veja a seguir:

Tour pela GUI

Concluído isso, todo o restante é feito via interface gráfica. Vamos então iniciar nosso tour pelas telas e funcionalidades.

Ao se logar, você verá a aba Summary, com informações do servidor, de autenticação, BYOD, alarmes, processos do sistema, dispositivos de rede, e etc.

Na sequência, vamos para o menu Administration e Deployment. É aqui que será configurado o ISE primário e secundário para alta disponibilidade "manual" em ativo/passivo ou ainda acrescentando um health node e fazendo uma alta disponibilidade automática (detalhes em um próximo artigo).

Você também poderá definir aqui se o ISE irá rodar em modo standalone ou não, apontar os diversos PSNs (nós de política) que normalmente ficam espalhados em sites diferentes, e etc.

É nessa aba também que você habilita alguns serviços que não vêm configurados por padrão, como o TrustSec, pxGrid, TACACS+, etc.

Ainda em Deployment, a segunda aba permite selecionarmos quais meios o ISE irá usar para fazer o Profiling, ou seja identificar e categorizar os dispositivos. Caso não haja probes suficientes habilitadas (não quer dizer que você deva ticar todas), uma máquina Windows 7 por exemplo seria identificada apenas como Intel-based device. Essas probes abaixo vêm por padrão, caso não utilize, elas podem ser desabilitadas.

A próxima aba mostra os detalhes do licenciamento. Existem duas formas possíveis: pelo smart licensing ou traditional licensing (o bom e velho PAK da Cisco).

Repare nos detalhes do licenciamento das licenças Base, Plus e Apex para 100 endpoints com duração de 90 dias. Tudo 100% habilitado pra você testar e treinar!

O ISE também pode ser utilizado como uma CA. Como ele normalmente é configurado em HA, pode ser uma boa alternativa para as empresas que ainda não possuem uma CA.

Caso você precise instalar um certificado válido, é também nessa seção que será feito. No momento da importação do certificado (após gerar o CSR), irá aparecer uma janela para você escolher se esse certificado é para um portal guest, portal de administração do próprio ISE, entre outras.

E para concluir esse primeiro artigo, a aba Maintenance permite a instalação dos patches, que também são baixados diretamente do site da Cisco e feito upload direto para o ISE. A instalação é bem simples e é dessa forma que você manterá seu software operando sem vulnerabilidades e nas melhores condições. A opção de Repository, permite a configuração de um repositório de software onde ficará um arquivo que será utilizado para o upgrade do ISE. Esse repositório pode ser uma unidade de CDROM, HTTP, HTTPS, SFTP, DISK LOCAL, etc.

Bom, pra essa primeira parte é isso. O próximo artigo irá finalizar o tour e depois começa a parte legal, AAA na veia!!

Abraços!!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Janeiro de 2021 pelo mesmo autor. As configurações e exemplos continuam válidos.

Fala pessoal!! Seguindo nossa série, recentemente integramos o ISE com AD, fizemos AAA com Radius e agora vamos fazer o mesmo com TACACS, mas adicionando command authorization.

Nosso objetivo é permitir que um usuário se logue automaticamente com privilégio 15 mas, de forma granular, permitir apenas alguns comandos específicos.

O primeiro passo é ativar o serviço no ISE. Fazemos isso nessa tela:

Em seguida, nesse menu, temos uma visão geral dos passos necessários:

Primeiramente, vamos então adicionar o nosso network device (já fizemos isso nos outros artigos):

Pronto! Vamos criar agora o command set - grupo de comandos que iremos permitir o usuário dar no router. Atente-se à sintaxe, não pode haver erros! Não há checagem por parte do ISE.

Agora vamos criar o Profile. Repare nos menus. A única informação que vamos colocar é o privilégio 15 automático para o usuário.

Feito isso, vamos editar a política de autenticação padrão para buscar o usuário apenas no AD que configuramos no artigo passado.

Repare na estrutura de menu que se trata de outra Policy Set. É uma base de políticas diferente da utilizada pelo Radius. No entanto, elas possuem o mesmo formato.

Na política de autorização, nós definimos o Command Set que criamos, o Profile e, na condição, selecionei apenas o Network Device com o nome "R2". Ou seja, essa condição não se aplica a nenhum outro eqto da rede, apenas a esse router em específico.

Ao logar, o usuário fernando do AD, recebe direto o prompt privilegiado, mas não é possível entrar com o comando show privilege, já que não o permitimos no command set que criamos acima.

Veja abaixo os comandos que permitimos e os que foram negados. Por ex: não permitimos o router rospf, mas permitimos o router eigrp.

Qto aos logs do TACACS, eles são consultados nesse menu:

Um exemplo de log de comando autorizado:

Um exemplo de log de comando não autorizado:

Por fim, mas igualmente importante a config toda do router (também já detalhada nos artigos anteriores):

aaa new-model
!
!
aaa group server tacacs+ ISE_TACACS
 server name ISE_TACACS
!
aaa authentication login NOAUTH none
aaa authentication login ISE_TACACS group ISE_TACACS
aaa authorization config-commands
aaa authorization exec ISE_TACACS group ISE_TACACS
aaa authorization commands 1 ISE_TACACS group ISE_TACACS
aaa authorization commands 15 ISE_TACACS group ISE_TACACS
aaa accounting exec ISE_TACACS start-stop group ISE_TACACS
aaa accounting commands 15 ISE_TACACS start-stop group ISE_TACACS
!
interface Ethernet0/1
 ip address 10.0.0.11 255.255.255.0
!
tacacs server ISE_TACACS
 address ipv4 10.0.0.100
 key cisco123
!
line con 0
 logging synchronous
 login authentication NOAUTH
line aux 0
line vty 0 4
 authorization commands 1 ISE_TACACS
 authorization commands 15 ISE_TACACS
 authorization exec ISE_TACACS
 login authentication ISE_TACACS
 transport input ssh

Importante destacar 3 comandos nessa config:

aaa authorization config-commands

"Config-Commands" significa que o network device precisa obter autorização para comandos dados dentro do prompt de configuração (configure terminal)

aaa authorization commands 15 ISE_TACACS group ISE_TACACS

O "15" significa autorização para comandos de usuários que possuem privilege level 15

aaa accounting commands 15 ISE_TACACS start-stop group ISE_TACACS

E, finalmente, o accounting commands 15, que irá logar cada comando no nível de privilégio 15.

Espero que tenham curtido.

Um abraço!!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Dezembro de 2020 pelo mesmo autor. As configurações e exemplos continuam válidos.

Fala pessoal! Espero que todos estejam bem!

Tinha ficado devendo pra vocês a integração do ISE com o Active Directory da Microsoft, então, vamos lá?

A configuração é extremamente simples, mas 3 pré-requisitos importantes podem nos fazer perder um bom tempo no troubleshooting:

• horário sincronizado (seja usando NTP - recomendado - ou manualmente);

• mesmo timezone;

• ISE apontando o DNS pro AD - ou um dos ADs do domínio.

Fora isso, você precisará de um usuário com permissão para criar um objeto no AD (meus tempos de MCSE já passaram então não lembro se é necessário esse usuário fazer parte do grupo Domain Admins, ou se tem algum outro grupo mais restritivo que permita a criação desse objeto).

Tendo isso em mãos, vamos pro ISE - aqui, consegui atualizar meu lab e estou usando a versão 2.7, atualmente recomendada pela Cisco.

Vamos então configurar o AD, que é uma base externa de usuários, ok?

Menu Administration > External Identity Source > Active Directory

O Join Point Name é apenas um nome que você vai dar para essa base de usuários e o AD Domain o seu domínio.

Depois do Submit, marque a caixa de selação ao lado e clique em Join. Entre com usuário e senha conforme falamos acima:

Você receberá uma mensagem de sucesso (se não, verifique os pré-reqs acima) e o objeto do ISE será criado no seu AD:

É isso! Nos próximos faremos AAA com Radius e TACACS utilizando usuários do AD que acabamos de configurar.

Um abraço!!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Janeiro de 2020 pelo mesmo autor. As configurações e exemplos continuam válidos.

Após conhecermos um pouco do ISE e fazermos um tour pelas principais funcionalidades - acesse aqui os artigos anteriores: ISE Basics - Parte 1 e ISE Basics - Parte 2, vamos agora logo para o que interessa! Faremos duas configurações de autenticação básicas de MAB e 802.1x.

Primeiro as definições:

• MAB que é o acrônimo de MAC Authentication Bypass: é um mecanismo que permite a integração de equipamentos que não suportam 802.1x se autenticarem na rede.

Quando habilitamos o MAB numa porta do switch, essa porta libera apenas o primeiro pacote (para aprender o endereço MAC), ficando todos os outros bloqueados até que a autenticação ocorra.

Ele não é um mecanismo muito seguro, já que é fácil spoofar um MAC, portanto, muitas vezes é utilizado como fallback do 802.1x.

• 802.1x, às vezes chamado de Dot1x, é um protocolo padrão IEEE para controle de acesso à rede. Ele faz parte do grupo IEEE 802.1 de protocolos de redes de computadores. A IEEE 802.1x define o encapsulamento do Extensible Authentication Protocol (EAP) sobre IEEE 802, que é conhecido como “EAP over LAN” ou EAPOL. Isso significa que qualquer computador que tentar se conectar à rede, deverá primeiro fornecer informações de autenticação.

Relembrando, no artigo anterior, nós fizemos a configuração do switch no ISE.

A única diferença, é que eu criei um grupo para nosso NAD (apenas para organização), chamado Switches, repare na figura acima.

A topologia do nosso lab ficou assim (adicionei mais um cliente para o 802.1x):

Acessando o switch, veja as configurações simples de IP e teste básico de conectividade.

Pronto, agora vamos lá, os passos para a configuração do servidor radius e de autenticação no switch:

1. Habilitar o AAA

aaa new-model

2. Criação do servidor radius

aaa group server radius ISE
 server name ISE
radius server ISE
 address ipv4 10.1.1.100 auth 1812 acc 1813
 key cisco

3. Vamos proteger o acesso via console (quem nunca ficou preso "pra fora" do equipamento? :P)

aaa authentication login NOAUTH none
line con 0
 login authen NOAUTH

4. Vamos habilitar a autenticação, autorização e accounting via Dot1x e MAB - sempre apontando para o grupo 'ISE' que criamos no passo 2

aaa authentication dot1x default group ISE
aaa authorization network default group ISE
aaa accounting dot1x default start-stop group ISE

5. Habilitar o ip device tracking e o Dot1x no switch

ip device tracking
dot1x system-auth

6. Agora faremos configuração da porta e0/1, onde está o cliente MAB

interface ethernet0/1
 switchport mode access
 dot1x pae authenticator
 mab
 authentication order mab dot1x
 authentication priority dot1x mab
 authentication port-control auto

7. E finalmente a configuração da porta e0/2, onde está o cliente Dot1x (idem acima, pois ambas estão habilitadas MAB e Dot1x)

interface ethernet0/2
 switchport mode access
 dot1x pae authenticator
 mab
 authentication order mab dot1x
 authentication priority dot1x mab
 authentication port-control auto

Como última task, vamos rapidinho criar um DHCP Server no switch:

ip dhcp excluded-address 10.1.1.1
!IP do meu notebook
ip dhcp excluded-address 10.1.1.10
!IP do switch
ip dhcp excluded-address 10.1.1.100
!IP do ISE
ip dhcp pool VLAN1
 network 10.1.1.0 /24
 default-router 10.1.1.10
 dns-server 10.1.1.10

Nesse momento, eu costumo fazer um teste simples de autenticação, veja abaixo:

SW1#test aaa group ISE fernando Cisco123! legacy
Attempting authentication test to server-group ISE using radius
User was successfully authenticated.

Esse usuário fernando, nós criamos no artigo anterior ISE Basics - Parte 2

Aqui, os logs do ISE em Operations > RADIUS > Live Logs:

Começando então pelo cliente do 802.1X, já que o usuário já está criado e OK.

Acesse a máquina Windows e confirme que o serviço WiredAutoConfig (menu iniciar > executar > services.msc), que habilita o 802.1X na LAN está rodando. Em caso negativo, inicie ele.

Agora a configuração da placa de rede.

Clique com o botão direto, propriedades e aba Authentication: selecione PEAP e depois em configurações, desmarque para validar o certificado do servidor (já que não estamos usando certificado digital nesse caso) e, em configuração do método de autenticação, desmarque para usarmos o usuário do Windows.

Dê OK em tudo e em configurações adicionais, deixe marcado para autenticação de usuário - aqui eu costumo deixar sem user e password pré-definidos, mas você pode configurar se preferir.

E, finalmente, estamos prontos para o teste. A porta do switch estava em shutdown, alterei ela, e apareceu um balão no Windows pedindo usuário e senha (caso não aconteça, desabilite e habilite o adaptador de rede):

Clique nele e entre com usuário fernando, que criamos no post anterior e testamos no switch no início do artigo.

Repare agora nas telas que confirmam a autenticação bem sucedida.

Logs do ISE em Operations > RADIUS > Live Logs

Obs: São duas entradas pois a de baixo é a autenticação em si, e a de cima, a sessão RADIUS que foi criada.

Repare no client que já deve ter pego IP via DHCP.

Dê um show authentication sessions no switch e você verá a autenticação e autorização bem sucedida. Repare no método:

SW1#sh authe sessions
Interface    Identifier     Method  Domain  Status Fg Session ID
Et0/2        5000.0003.0000 dot1x   DATA    Auth      0A01010A00000013004B82AB
Session count = 1
Key to Session Events Blocked Status Flags:
A - Applying Policy (multi-line status for details)
  D - Awaiting Deletion
  F - Final Removal in progress
  I - Awaiting IIF ID allocation
  N - Waiting for AAA to come up
  P - Pushed Session
  R - Removing User Profile (multi-line status for details)
  U - Applying User Profile (multi-line status for details)
  X - Unknown Blocker

Vamos agora ligar a máquina Windows que irá se autenticar com MAB. Nesse caso, não é necessário nenhuma configuração no cliente. Nos logs do ISE, agora vemos um MAC Address ao invés de um usuário.

No switch, temos agora duas portas autenticadas. A primeira é a do MAB e a segunda do 802.1X. Repare no método em destaque:

SW1#show authentication sessions
Interface    Identifier     Method  Domain  Status Fg Session ID
Et0/1        5000.0002.0000 mab     DATA    Auth      0A01010A0000001400585EC1
Et0/2        5000.0003.0000 dot1x   DATA    Auth      0A01010A00000013004B82AB
Session count = 2
Key to Session Events Blocked Status Flags:
A - Applying Policy (multi-line status for details)
  D - Awaiting Deletion
  F - Final Removal in progress
  I - Awaiting IIF ID allocation
  N - Waiting for AAA to come up
  P - Pushed Session
  R - Removing User Profile (multi-line status for details)
  U - Applying User Profile (multi-line status for details)
  X - Unknown Blocker

O Windows também pegou um IP, assim como a primeira máquina:

SW1#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address      Client-ID/              Lease expiration        Type       State      Interface
                Hardware address/
                User name
10.1.1.2         0150.0000.0300.00       Dec 31 2019 08:19 PM    Automatic  Active     Vlan1
10.1.1.3         0150.0000.0200.00       Dec 31 2019 08:38 PM    Automatic  Active     Vlan1

E, por fim, tráfego liberado entre as máquinas.

SW1# ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms
SW1# ping 10.1.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

Obs: Você deve ter reparado que no caso do cliente Dot1x nós criamos um usuário, mas não criamos um endpoint para o cliente MAB. Isso porque por padrão na versão 2.1, o ISE mesmo que não exista um endpoint, ele permite que o processo continue. Essa configuração é feita aqui:

Nos próximos artigos iremos testar configurações de política de autenticação e autorização diferentes.

Um abraço!!

Você pode baixar esse artigo em formato PDF no botão abaixo: