Postura em linha de VPN usando iPEP ISE e ASA

Introdução

Este documento fornece informações sobre como configurar a postura em linha com um Adaptive Security Appliance (ASA) e um Identity Services Engine (ISE).

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas na versão 8.2(4) para o ASA e na versão 1.1.0.665 para o ISE.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Informações de Apoio

O ISE oferece muitos serviços AAA (postura, criação de perfil, autenticação, etc.). Alguns dispositivos de rede (NAD) suportam a alteração de autorização (CoA) Radius que permite alterar dinamicamente o perfil de autorização de um dispositivo final com base em sua postura ou no resultado da criação de perfil. Outros NADs, como o ASA, ainda não oferecem suporte a esse recurso. Isso significa que um ISE em execução no modo de aplicação de postura em linha (iPEP) é necessário para alterar dinamicamente a política de acesso à rede de um dispositivo final.

O conceito básico é que todo o tráfego do usuário passará pelo iPEP, com o nó também atuando como um Proxy Radius.

Fluxo básico

1. O usuário da VPN faz login.

2. O ASA envia a solicitação ao nó iPEP (ISE).

3. O iPEP regrava a solicitação (adicionando atributos Cisco AV-PAIR para indicar que esta é uma autenticação iPEP) e envia a solicitação ao ISE Policy Node (PDP).

4. O PDP responde ao iPEP que encaminhará ao NAD.

5. Se o usuário for autenticado, o NAD DEVERÁ enviar uma solicitação de início de contabilização (consulte CSCtz84826 ). Isso acionará o início da sessão no iPEP. Neste estágio, o usuário é redirecionado para postura. Além disso, você precisa habilitar a atualização de contabilização temporária para o túnel estabelecido no portal WEBVPN, pois o ISE espera ter o atributo framed-ip-address na contabilização de raio. No entanto, ao conectar-se ao portal, o endereço IP da VPN do cliente ainda não é conhecido porque o túnel não está estabelecido. Isso garantirá que o ASA enviará atualizações provisórias, como quando o túnel será estabelecido.

6. O usuário passa pela avaliação de postura e, com base nos resultados, o PDP atualizará a sessão usando CoA no iPEP.

Esta captura de tela ilustra este processo:

Exemplo de topologia

Configuração do ASA

A configuração ASA é uma VPN remota IPSEC simples:

!
interface Ethernet0/0
nameif ISE
security-level 50
ip address 192.168.102.253 255.255.255.0 
!
interface Ethernet0/1
nameif outside
security-level 0
ip address 10.48.39.236 255.255.255.0 
!
access-list split extended permit ip 192.168.0.0 255.255.0.0 any 
!
aaa-server ISE protocol radius
interim-accounting-update 

!--- Mandatory if tunnel established from WEBVPN Portal

aaa-server ISE (ISE) host 192.168.102.254  

!--- this is the iPEP IP
 
key cisco
crypto ipsec transform-set TS1 esp-aes esp-sha-hmac 
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map DMAP1 10 set transform-set TS1
crypto dynamic-map DMAP1 10 set reverse-route
crypto map CM1 10 ipsec-isakmp dynamic DMAP1
crypto map CM1 interface outside
crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400
!
ip local pool VPN 192.168.5.1-192.168.5.100
!
group-policy DfltGrpPolicy attributes
dns-server value 192.168.101.3  

!--- The VPN User needs to be able to resolve the CN from the !--- ISE HTTPS Certificate (which is sent in the radius response)

vpn-tunnel-protocol IPSec svc webvpn
split-tunnel-policy tunnelspecified
split-tunnel-network-list value split
address-pools value VPN
!
tunnel-group cisco general-attributes
address-pool VPN
authentication-server-group ISE
accounting-server-group ISE 

!--- Does not work without this (see introduction)

!
tunnel-group cisco ipsec-attributes
pre-shared-key cisco
!
route outside 0.0.0.0 0.0.0.0 10.48.39.5 1
route ISE 192.168.0.0 255.255.0.0 192.168.102.254 1 

!--- You need to make sure the traffic to the local subnets !--- are going through the inline ISE

!

Configuração do ISE

Configuração iPEP

A primeira coisa a fazer é adicionar um ISE como um nó iPEP. Você pode encontrar informações adicionais sobre o processo aqui:

http://www.cisco.com/en/US/docs/security/ise/1.1/user_guide/ise_ipep_deploy.html#wp1110248.

Isto é basicamente o que você tem que configurar nas várias abas (capturas de tela fornecidas nesta seção ilustram isto):

• Defina as configurações de IP não confiável e IP global (nesse caso, o IP não confiável é 192.168.102.254).

• A implantação está no modo roteado.

• Coloque um filtro estático para que o ASA possa passar pela caixa iPEP (caso contrário, a conectividade de/para a caixa iPEP do ISE será descartada).

• Configure o Policy ISE como servidor Radius e o ASA como cliente Radius.

• Adicione uma rota à Sub-rede VPN que aponte para o ASA.

• Defina o ISE de monitoramento como o host de registro (porta 20514 por padrão; nesse caso, a política ISE também está monitorando).

Requisitos importantes de configuração de certificado:

Antes de tentar registrar um nó iPEP, certifique-se de que os seguintes requisitos de uso estendido de chave do certificado sejam atendidos. Se os certificados não forem configurados corretamente nos nós iPEP e Admin, o processo de registro será concluído. No entanto, você perderá o acesso de administrador ao nó iPEP. Os detalhes a seguir foram extrapolados do Guia de implantação iPEP do ISE 1.1.x:

A presença de certas combinações de atributos nos certificados locais dos nós Administração e Postura em linha pode impedir que a autenticação mútua funcione.

Os atributos são:

• Uso Estendido de Chave (EKU - Extended Key Usage) - Autenticação de Servidor

• Uso Estendido de Chave (EKU - Extended Key Usage) - Autenticação de Cliente

• Tipo de Certificado do Netscape — Autenticação do Servidor SSL

• Tipo de Certificado do Netscape — Autenticação de Cliente SSL

É necessária uma das seguintes combinações para o certificado de Administração:

• Ambos os atributos EKU devem ser desabilitados, se ambos os atributos EKU forem desabilitados no certificado de Postura em Linha, ou ambos os atributos EKU devem ser habilitados, se o atributo de servidor estiver habilitado no certificado de Postura em Linha.

• Os dois atributos do tipo de certificado Netscape devem estar desabilitados ou ambos.

É necessária uma das seguintes combinações para o certificado de Postura em Linha:

• Os dois atributos EKU devem ser desabilitados, ou ambos devem ser habilitados, ou o atributo de servidor sozinho deve ser habilitado.

• Os dois atributos do tipo de certificado Netscape devem estar desabilitados, ou ambos devem estar habilitados, ou o atributo de servidor sozinho deve estar habilitado.

• Quando os certificados locais autoassinados são usados nos nós Administração e Postura embutida, você deve instalar o certificado autoassinado do nó Administração na lista confiável do nó Postura embutida. Além disso, se você tiver nós de Administração primários e secundários em sua implantação, deverá instalar o certificado autoassinado de ambos os nós de Administração na lista confiável do nó Postura in-line.

• Quando os certificados locais assinados pela CA são usados nos nós Administração e Postura em linha, a autenticação mútua deve funcionar corretamente. Nesse caso, o certificado da autoridade de certificação assinante é instalado no nó Administração antes do registro e é replicado para o nó Postura em linha.

• Se as chaves emitidas pela CA forem usadas para proteger a comunicação entre os nós Administração e Postura embutida, antes de registrar o nó Postura embutida, você deverá adicionar a chave pública (certificado CA) do nó Administração à lista de certificados CA do nó Postura embutida.

Configuração básica:

Configuração do Modo de Implantação:

Configuração de filtros:

Configuração de RADIUS:

rotas estáticas:

Registro:

Configuração de autenticação e postura

Há três estados de postura:

• Desconhecido: Postura ainda não foi feita

• Compatível: Postura é feita e o sistema é Compatível

• Não Compatível: Postura é feita, mas o sistema falhou em pelo menos uma verificação

Agora, os perfis de autorização devem ser criados (que serão Perfis de autorização em linha: isso adicionará o atributo ipep-authz=true no par Cisco AV) que será usado para o caso diferente.

Geralmente, o perfil Desconhecido retorna a URL de redirecionamento (descoberta de postura) que encaminhará o tráfego do usuário para o ISE e solicitará a instalação do NAC Agent. Se o NAC Agent já estiver instalado, isso permitirá que sua solicitação HTTP Discovery seja encaminhada ao ISE.

Neste perfil, é usada uma ACL que permite pelo menos o tráfego HTTP para o ISE e o DNS.

Os perfis Compatível e Não Compatível normalmente retornam uma ACL para download para conceder acesso à rede com base no perfil do usuário. Um perfil não compatível pode permitir que os usuários acessem um servidor Web para baixar um antivírus, por exemplo, ou conceder acesso limitado à rede.

Neste exemplo, os perfis Desconhecido e Compatível são criados, e a presença de notepad.exe como requisitos é verificada.

Configuração de perfis de postura

A primeira coisa a fazer é criar as ACLs para download (dACL) e os perfis:

Observação: não é obrigatório ter o nome dACL correspondente ao nome do perfil.

• Compatível

  • ACL: ipep-desconhecido

  • Perfil de Autorização: ipep-desconhecido

• Não compatível

  • ACL: ipep não compatível

  • Perfil de Autorização: não compatível com ipep

dACL desconhecido:

Perfil desconhecido:

dACL compatível:

Perfil de conformidade:

Configuração de Autorização

Agora que o perfil foi criado, você precisa corresponder à solicitação Radius proveniente do iPEP e aplicar a eles os perfis corretos. Os iPEP ISEs são definidos com um tipo de dispositivo especial que será usado nas regras de autorização:

NADs:

Autorização:

Observação: se o agente não estiver instalado na máquina, você poderá definir regras de Provisionamento de Cliente.

Resultado

Você é solicitado a instalar o agente (neste exemplo, o provisionamento de cliente já está definido):

Alguma saída neste estágio:

ciscoasa# show vpn-sessiondb remote 
 
Session Type: IPsec
Username     : cisco                  Index        : 26
Assigned IP  : 192.168.5.2            Public IP    : 10.48.39.134
Protocol     : IKE IPsec
License      : IPsec
Encryption   : AES128                 Hashing      : SHA1
Bytes Tx     : 143862                 Bytes Rx     : 30628
Group Policy : DfltGrpPolicy          Tunnel Group : cisco
Login Time   : 13:43:55 UTC Mon May 14 2012
Duration     : 0h:09m:37s
Inactivity   : 0h:00m:00s
NAC Result   : Unknown
VLAN Mapping : N/A                    VLAN         : none

E do iPEP:

w-ise-ipep-1/admin# show pep table session 

Current Sessions (IP, MAC(if available), Profile ID, VLAN (if any)):
192.168.5.2 00:00:00:00:00:00 2 0 
w-ise-ipep-1/admin# show pep table accesslist normal 
#ACSACL#-IP-ipep-unknown-4fb10ac2:
deny tcp any host 192.168.101.1 eq 80
deny tcp any host 192.168.101.1 eq 443
permit ip any host 192.168.101.1
permit udp any any eq 53

Depois que o agente for baixado e instalado:

O agente deve detectar automaticamente o ISE e executar a avaliação de postura (supondo que você já tenha as regras de postura definidas, que é outro assunto). Neste exemplo, a postura é bem-sucedida, e isso aparece:

Observação: há duas autenticações na captura de tela acima. No entanto, como a caixa iPEP armazena em cache as ACLs, ela não é baixada todas as vezes.

No iPEP:

w-ise-ipep-1/admin# show pep table session 
 
Current Sessions (IP, MAC(if available), Profile ID, VLAN (if any)):
192.168.5.2 00:00:00:00:00:00 3 0 
w-ise-ipep-1/admin# show pep table accesslist normal 
#ACSACL#-IP-PERMIT_ALL_TRAFFIC-4f57e406:
permit ip any any
 
#ACSACL#-IP-ipep-unknown-4fb10ac2:
deny tcp any host 192.168.101.1 eq 80
deny tcp any host 192.168.101.1 eq 443
permit ip any host 192.168.101.1
permit udp any any eq 53
w-ise-ipep-1/admin#

Informações Relacionadas

• Suporte Técnico e Documentação - Cisco Systems