Guia de Implementação de Balanceamento de Carga em Clusters ASA-VPN com Certificação Digital

 

 

Este documento descreve um conjunto de boas práticas e um cenário alternativo para a solução de acesso remoto de distribuição do ASA-5500 VPN em um ambiente de Load Balancing/Clustering usando a autenticação de certificados digitais.

Para obter mais informações sobre os serviços de Load Balancing de VPN/Clustering High Availability dos dispositivos ASA por favor consulte o guia do configuração em

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/vpnsysop.html#wp1048834.

Verifique em cisco.com se há novas versões do original.

Para obter mais informações sobre configuração de Certificados nos dispositivos ASA, por favor consulte o guia do configuração em

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/cert_cfg.html.

Verifique em cisco.com se há novas versões do original.

I. O procedimento de Boas Práticas para depuração com um Certificado de Cliente Unificado - Unified Client Certificate (UCC)

Etapas gerais:

1) Obtenha um UCC com múltiplo SANs (Subject Alternative Name extensions) com cada ASA FQDN/IP incluído.

Conseqüentemente você precisará de um certificado UCC com o CN para o cluster FQDN e/ou cluster IP, e SANs para cada ASA no cluster hte: ASA-1 FQDN e/ou IP, ASA-2 FQDN e/ou IP, e assim por diante. Diversos vendedores PKI/Certificate tais como o UCC suportado por Entrust.com, mais conhecidos como certificados unificados de Multi-Domínio SSL do cliente.

Nota: O ASA não gera uma solicitação de assinatura de certificado (Certificate Signing Request - CSR) com SANs múltiplos (CSCso70867 é o aprimoramento que necessita desta capacidade), assim você precisará mandar o vendedor CA/PKI submeter o registro para você.


2) No ASA mestre configure um ponto confiável “<name>” que aponta ao virtual/cluster.

O exemplo do CLI está abaixo:

crypto ca trustpoint asa-cluster
subject-name CN=asa-cluster.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US
enrollment terminal


Agora importe o cerficiado obtido de um vendedor CA/PKI:


crypto ca import certificate

A implementação de segurança adaptável o pedirá para copiar o certificado e colar no terminal usando o formato base-64.

3)Exporte o ponto confiável como o pkcs12 (certificado e chaves serão exportados)

 

crypto ca export asa-cluster pkcs12 <passphrase>


Copie a saída resultante e guarde-a em um arquivo de texto.

4)Importe o pkcs12 a cada membro ASA do cluster.

 

crypto ca import asa-cluster pkcs12 <passphrase>

 

5)Configure todos os comandos ssl < interface e ssl outside vpnloadbalanced que apontam ao ponto confiável importado “<name>”.

6) Inicie suas sessões de acesso remota VPN (clientes de IPSec, cliente SSL AnyConnect, Clientless SSL VPN com baseado em navegador) ao Load Balanced Virtual IP (VIP) ou ao FQDN.

II. Alternativa usando certificados múltiplos ou certificados Wilcard

  • A)      exige um número n+1 de endereços IP e/ou número DNS-FQDN      e n+1 números de certifcados.

O exemplo abaixo depura um cluster de 2 nós, conseqüentemente 3 IPs/DNS-FQDNs são necessários.

- Três certificados (um para o cluster ASA, um para asa1, e um para asa2) são exigidos

  • B) Um certificado wilcard

Os certificados Wilcard não são recomendados em favor dos UUC certs. De acordo com um vendedor, Entrust, estes são 2 motivos principais:

  1. O      UCC é mais seguro do que os certificados wildcard desde que os      certificados Entrust UC especifiquem exatamente que os hosts e os domínios      devem ser protegidos
  2. O      UCC é mais flexível do que os certificados do convite pois os certificados      Entrust UC não são limitados a um único domínio

O procedimento para usar Certifcados múltiplos segue:

Exemplo de configuração com dois ASA que operam como um conjunto com função de balanceamento de carga usando certificados múltiplos

VPN cluster IP address:     10.10.1.1
ASA1 outside IP:            10.10.1.2
ASA2 outside IP:            10.10.1.3


Configuração de DNS (domínio = company.com):

hostname:          IP:
asa-cluster        10.10.1.1
asa1               10.10.1.2
asa2               10.10.1.3


Configuração de load balancing VPN (em todos os ASA no cluster)

vpn load-balancing
redirect-fqdn enable
cluster ip address 10.10.1.1
participate

Resolução de nome: O ajuste redirect-FQDN enable faz o redirecionamento da saída do ASA usando o hostname ao contrário do endereço IP. Este *requer* que o DNS em uso tenha registros dns inversos apropriados para nomes de host envolvidos a fim de funcionar, e que o ASA, não o cliente, pode fazer esta definição.  Isto deve ser configurado para evitar avisos pop-up da má combinação de hostname do certificado.

Para testar a resolução de nome no ASA, emita um comando ping ao FQDN do cluster, e ao FQDN de cada membro. Todos os membros do cluster ASA devem poder resolver estes nomes para que redirecionem o trabalho.

Como uma ação alternativa, você pode pôr os nomes sobre o próprio ASA para resolver estes endereços, se o DNS não é uma opção

Exemplo:

name 10.10.1.1 asa-cluster.example.com
name 10.10.1.2 asa1.example.com              
name 10.10.1.3 asa2.example.com    

Após isto, o asa deve poder resolver asa-cluster.example.com, asa1.example.com, e asa2.example.com. Você pode testar isto emitindo um ping a todos os 3 endereços. O ICMP pode não funcionar, mas o asa deve poder dar-lhe um endereço IP para cada um dos nomes. Se não o fizer, verifique por favor a resolução de nome outra vez, pois o comando redirect-fqdn não trabalhará sem ela.


Configurações do ponto confiável

1) ID do ponto confiável do certificado asa1


crypto ca trustpoint myca
subject-name CN=asa1.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US
Optionalmente você poderá incluir CN=<asa1 IPAddress> no DN acima.

2) ID do ponto confiável do certificado asa2


crypto ca trustpoint myca
subject-name CN=asa2.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US
Optionalmente você poderá incluir CN=<asa2 IPAddress> no DN acima.

3) ponto confiável da função de balanceamento de carga - configurado em um ou outro ASA e pode ser importado a todos ASA restantes no cluster


crypto ca trustpoint asa-cluster
subject-name CN=asa-cluster.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US
 
Optionalmente você poderá incluir CN=<asa-cluster IPAddress> no DN acima.

4) Exportando e importando o ponto confiável de balanceamento de carga ao membro ASA

Uma vez que este ponto confiável está autenticado e registrado (ambos certificados CA e ID estejam presentes) lhe pode ser exportado para o pkcs12 e ser importado a todo o membro de cluster ASA com função de balanceamento de carga usando o seguinte procedimento:


a. Exporte o ponto confiável (certificados e chaves) para um pkcs12 protegido com senha.

crypto ca export asa-cluster pkcs12 <passphrase>


Copie as saídas resultante e guarde-as em um arquivo de texto.


b. Importe o pkcs12 a outros ASA

crypto ca import asa-cluster pkcs12 <passphrase>


Cole os dados do pkcs12 dentro e digite ‘quit’ em uma linha por si só quando acabado de finalizar o processo.

Nota: O processo da exportação/importação migra somente os certificados/keypair de um dispositivo a outro. Toda a configuração necessária do ponto confiável deve manualmente ser reconfigurada (como a verificação de revogação, as opções CRL, etc.).

Observação importante: Nas versões anteriores a 8.0(3)6, você era incapaz de exportar um ponto confiável que tivesse somente o certificado ID preenchido corretamente. Isto criava um problema porque em ASDM, o certificado ID e o certificado CA foram postos em 2 pontos confiável diferentes. Se você verificar um problema onde você faça a importação do certificado do cluster em um membro do cluster, e ele disser que está bem sucedido mas o certificado não aparecer, este é o problema mais provável. Volte ao ASA que emitiu o CSR para o certificado do cluster, e autentique o ponto confiável com o certificado de emissão e então o exporte novamente. Veja CSCsl59266 para mais detalhes.


Neste momento os certificados do cluster ASA são instalados e podem ser usados para identificar corretamente os pedidos SSL que acessam o endereço IP/hostname do cluster.

 

Configuração de SSL para usar o certificado LB

ssl trust-point myca outside
ssl trust-point asa-cluster outside vpnlb-ip

III. Client Connection Experienc para VPN com Clientless SSL


A experiência de conexão de um cliente que usa um navegador (VPN com Clientless SSL) é como segue:

a. O cliente consulta https://asa-cluster.company.com e o ASA envia seu certificado ID ao cliente.  Nota: Se a autenticação do certificado de cliente é permitido, o cliente será alertado escolher um certificado ID do pop-up do navegador.

- O expedidor do certificado ASA deve ser confiado pelo cliente e conseqüentemente não deve advertir.

- O nome a que foi consultado (asa-cluster.company.com) está no certificado do conjunto ASA então não deverá advertir sobre a má combinação de hostname.


b. O cluster master decide o melhor ASA a orientar (asa2 neste exemplo) e envia uma redirecionamento ao cliente.


c. O cliente inicia silenciosamente a nova conexão a https://asa2.company.com e o ASA2 envia seu certificado ID ao cliente.

- O expedidor do certificado ASA deve ser confiado pelo cliente e conseqüentemente não deve advertir.

- O nome a que foi consultado (asa-cluster.company.com) está no certificado do conjunto ASA então não deverá advertir sobre a má combinação de hostname.


d. A experiência do cliente depende da configuração de autenticação ASA.

- AAA somente - o cliente está alertado a autenticar no portal inicial de uma sessão e/ou escolher um grupo (se tunnel-group-list enable e group-alias está configurado)

- Certificado de autenticação somente, com group-url ou mapa do certificado - o cliente é conectado e vê o portal do webvpn/links, etc.

- Certificado de autenticação somente, sem group-url ou mapa do certificado (o group-alias é permitido ao invés) – o cliente deve selecionar um grupo do portal e clicar em conectar. Conexão completa.

- Autenticação do Certificado AAA + - com group-url ou mapa do certificado - autenticação do certificado ocorre, então o cliente será solicitado para o AAA; após entrar, a conexão estará completa.

- Autenticação do Certificado AAA + - group-url ou mapa do certificado (o group-alias é permitido ao invés) - cliente serão solicitados para o aaa e a seleção de grupo (se tunnel-group-list enable e group-alias está configurado); após entrar, a conexão está completa.

Histórico de versão
Revisão #
2 de 2
Última actualização:
‎08-31-2017 12:04 PM
Actualizado por:
 
Etiquetas (1)
Contribuintes