Os níveis de acesso utilizando CLI do FTD e FXOS

Neste post estarei apresentando um resumo sobre os níveis de acesso utilizando a CLI no Firewall FTD e FXOS, quero apresentar as possibilidades que podem ser utilizadas para realizar análise de configurações, debugs e troubleshooting.

Fluxo de navegação FTD CLIcli ftd

Presumindo que vc esteja na CLI do FXOS, execute o seguinte comando para se conectar ao Security Module onde o software FTD está instalado, neste exemplo estou utilizando o FTD 4110.

Firepower-4100# connect module 1 console
Telnet escape character is ‘~’.
Trying 127.5.1.1…
Connected to 127.5.1.1.
Escape character is ‘~’.
CISCO Serial Over LAN:
Close Network Connection to Exit
Firepower-module1>

Partindo da mesma ideia que agora você está na CLI do Security Module. Execute o comando abaixo para se conectar à CLI do FTD:

Firepower-module1>connect ftd
Connecting to ftd console… enter exit to return to bootCLI
>

Está informação >  indica que você está na CLI do FTD todas as tarefas executadas aqui são relacionadas ao FTD. Se você quiser alterar para o console do ASA, precisamos executar outro comando para trocar de CLI.

> system support diagnostic-cli
Attaching to ASA console … Press ‘Ctrl+a then d’ to detach.
Type help or ‘?’ for a list of available commands.
firepower>

Agora, você está na CLI do ASA. Execute o seguinte comando para acessar o modo privilegiado. Será solicitada a senha de enable.

firepower> enable
Password:
firepower#

Para sair do console ASA, pressione ‘Ctrl + a depois d’.

firepower#
Console connection detached.
>

Espero que possa ser útil para alguém.

BUG CVE-2018-0101 – VPN Anyconnect RA

A Cisco anunciou no dia 29 de janeiro de 2018 uma falha que pode ser explorada no ASA ou FTD quando a configuração de VPN Anyconnect Remote Access está configurada.

ASA-BUG

A vulnerabilidade pode ser explorada quando o recurso de webvpn está habilitado no  Cisco ASA. O atacante pode explorar essa vulnerabilidade enviando pacotes XML para a interface configurada no webvpn no sistema afetado. Com a utilização de um exploit o atacante ganha acesso para executar códigos maliciosos e obter o controle total do Cisco ASA ou FTD e pode causar uma sobrecarga do dispositivo afetado fazendo com que ele seja reiniciado.

Os dispositivos que foram afetados com esta falha são:

  • 3000 Series Industrial Security Appliance (ISA)
  • ASA 5500 Series Adaptive Security Appliances
  • ASA 5500-X Series Next-Generation Firewalls
  • ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
  • ASA 1000V Cloud Firewall
  • Adaptive Security Virtual Appliance (ASAv)
  • Firepower 2100 Series Security Appliance
  • Firepower 4110 Security Appliance
  • Firepower 9300 ASA Security Module
    Firepower Threat Defense Software (FTD)

Workarounds
Nenhum workaround para abordagem desta vulnerabilidade foi disponibilizado é necessário a atualização do ASA ou FTD.

Releases com as correções para Cisco ASA

ASA

Correção para Cisco FTD

ftd

Para aqueles que foram afetados e estão utilizando ASA ou FTD, é extremamente importante a atualização do sistema.

Como reiniciar console de gerenciamento do FMC?

Este documento descreve como reiniciar os serviços em um appliance Cisco FMC com a utilização da Interface gráfica ou através da CLI.

Reiniciar os processos de gerenciamento do FMC

Dependendo do problema que você se deparar pode ser necessário reiniciar os processos e serviços que são executados no FMC.
Podemos reiniciar esses serviços e processos sem a necessidade de reinicie todo o Firepower, conforme estarei apresentando nas seções que se seguem.

Passos para reiniciar os processos através da interface WEB
Abaixo relacionei as etapas para reiniciar os processos do FMC através da interface Web:

Passo1: Faça login na interface Web do FMC
Passo2: Em System > Local > Configuration > Process

FMC
Clique em  Run Command para Restart Defense Center Console. Isso reinicia os serviços e processos.

Reiniciar os processos com a CLI
Abaixo relacionei as etapas para reiniciar os processos do FMC através da CLI:

Passo1: Faça login na CLI do FMC

Passo2: Elevar seu nível de privilégio para o modo de usuário raiz
admin@ccielab-fmc:~$ sudo su –

Passo3: Digite este comando na CLI para reiniciar o console
root@ccielab-fmc:~# /etc/rc.d/init.d/console reiniciar

Obs. Após reiniciar os processos, isso pode leva alguns minutos, não precisa se preocupar, não terá nenhuma indisponibilidade no ambiente, apenas a gerencia do FMC ficará indisponível até terminar o processo de reinicialização.

Overview Protocolo 802.1x

802.1X

802.1X oferece uma visibilidade e controle de acesso seguro baseado em identidades e certificados de controle na borda da rede.

A necessidade para controlar o acesso seguro à rede nunca foi tão grande como os dias atuais, existe a necessidade para controlar acesso aos consultores, prestadores de serviços e todos os clientes que precisam do acesso aos recursos de rede sobre as mesmas conexões de LAN. Como as redes de dados tornam-se cada vez mais indispensável em operações de negócios do dia-a-dia, a possibilidade de que pessoas ou dispositivos não autorizados terão acesso a informações controladas ou confidenciais também aumenta. A melhor e mais segura solução para a vulnerabilidade na borda de acesso é aproveitar a inteligência da rede.

Antes e depois 802.1X

Antes da autenticação, a identidade do endpoint é desconhecida e todo o tráfego é bloqueado por padrão. Após a autenticação, a identidade do endpoint passa a ser conhecida e todo o tráfego a partir desse ponto é permitido. O switch executa a filtragem do MAC para garantir que apenas o ponto final autenticado tenha permissão para enviar tráfego.

antes-depois

Benefícios sobre 802.1x

802.1X oferece os seguintes benefícios em redes com fio:

  • Visibilidade: 802.1X fornece maior visibilidade na rede porque o processo de autenticação fornece uma maneira de visualizar o nome de usuário com o endereço IP, endereço MAC Address e a porta do switch a qual está conectado. Esta visibilidade é útil quando necessário para realizar auditorias de segurança, estatísticas de uso de rede e solução de problemas;
  • Segurança: 802.1X é o método mais forte para autenticação e deve ser usado para ativos gerenciados que suportam um cliente que utiliza o protocolo 802.1X, trabalha na camada 2 de rede, permitindo controlar o acesso à rede a partir da borda;
  • Serviços com base em identidades: 802.1X permite que utilize uma identidade autenticada para entregar dinamicamente serviços personalizados. Por exemplo, um usuário pode ser autorizado em uma VLAN específica ou atribuir uma lista de acesso que prove a autorização de acesso a recurso no ambiente para este usuário

Componentes do 802.1x

802.1X define os três componentes necessários seguintes:

  • Suplicante: É um cliente que encaminha as credenciais para autenticação, os suplicantes podem ser aplicativos de software instalado em estações, servidores, exemplos de estações Linux que necessitam do “wpa_supplicant”, ou eles podem ser incorporados em sistemas operacionais como o Microsoft Windows, estações com sistema operacional Mac que suportam 802.1X TLS nativo, entre outros;
  • Autenticador: O dispositivo de acesso à rede que inicia o processo de autenticação ele envia as credenciais do suplicante para o servidor de autenticação. No contexto deste documento, o autenticador por ser os switches ou simplesmente a controladores Wireless que trabalha camada de acesso;
  • Servidor de autenticação: Um servidor que valida as credenciais enviadas pelo suplicante e determina o nível de acesso à rede ao usuário final ou dispositivo que deve receber.

Protocolos 802.1x

802.1X utiliza os seguintes protocolos:

  • Extensible Authentication Protocol (EAP): O formato de mensagem e quadro definido pela RFC 4187 que fornece uma maneira para que o suplicante e o autenticador negociam um método de autenticação (o método EAP).
  • Método EAP: Define o método de autenticação, o tipo de credencial e como ele é apresentado a partir do suplicante para o servidor de autenticação usando a estrutura do EAP.
  • OS métodos comuns usados em redes 802.1x são EAP-Transport Layer Security (EAP-TLS) e EAP-Microsoft Challenge Handshake Authentication Protocol v2 (PEAP-MSCHAPv2).
  • EAP sobre LAN (EAPoL): Um encapsulamento definido pelo 802.1x para o transporte EAP do suplicante para o switch sobre redes IEEE 802, EAPoL é um protocolo de camada 2.
  •  O padrão para a comunicação entre o switch e o servidor de autenticação.

802.1x

Visão Geral Sequência de Operação

Na figura abaixo representa o modo de operação de como os componentes do protocolo 802.1x trabalha.

802.1x-2

ASA Clustering

Adaptive Security Appliance (ASA) – Clustering

A partir da versão 9.0 de software do ASA ele passou a suportar a funcionalidade de Firewall Clustering. Isso permite que dependendo do hardware, podemos utilizar até 16 devices para trabalhar em modo de cluster, isso permite que quando configurado em modo de cluster eles apareçam como um único dispositivo. As vantagens é que agora, pode se aproveitar todas as vantagens dos protocolos como vPC e VSS para transporte de tráfego e balanceamento de carga entre todos os dispositivos em uma configuração active/active. Ao contrário do antigo modo de uso active/standby ou active/active com modo multi-contexto, onde um dispositivo estava sempre em standby e não realmente passando o tráfego entre ele.

  • Multiple Context Mode: Um ASA pode ser configurado para operar como vários contextos virtuais, cada um deles atuarão como firewalls independentes.
  • Transparent Mode: Um ASA pode ser configurado para funcionar como um firewall transparente, que se tornam efetivamente como uma bridge entre duas interfaces. Firewalls em modo transparente permite ser ligado numa rede existente, sem necessidade de qualquer.

Arquitetura do Cluster utilizando Cisco ASA

Diferente do modo de cluster tradicional do ASA, a arquitetura de Clustering ela é construída da seguinte maneira, um membro do cluster é eleito Master e os outros dispositivos são Slaves. A primeira unidade a entrar no domínio do cluster ou com base em um valor de prioridade se tornará a unidade Master. O dispositivo Master é responsável por toda a gerencia da configuração, gerenciamento do dispositivo ele também possui o VIP do cluster. Um ponto importante é que um novo Master somente é eleito se haver problemas com o Master atual.

Os dispositivos do cluster utilizam uma comunicação chamado de Cluster Control Link ou (CCL), este link é utilizado para o backplane do cluster. Cada dispositivo deve ter pelo menos uma interface de hardware dedicada para a configuração deste link, a recomendação é que seja utilizado em port-channel e a largura de banda para o CCL seja próxima a quantidade de tráfego que passar pelo cluster, por exemplo, se chegar um tráfego em torno de 12 a 14Gbps por caixa no cluster, então é preciso que o link trabalhe com algo em torno de 14 Gbps. Neste caso, seria preciso configurar 2 interfaces de 10G em um port-channel.

Modos de interface suportados

  • Layer 2 Mode

O modo de interface Spanned EtherChannel é o método recomendado pela Cisco para configurar interfaces do Cluster para switches adjacentes na camada de agregação. Esse método usa o LACP para fornecer uma solução ECMP de camada 2.

  • Layer 3 Mode

O modo de interface individual requer que cada interface do ASA tenha um endereço IP exclusivo atribuído a ele. Nos switches ou roteadores, é preciso utilizar PBR ou um algum protocolo de roteamento dinâmico para fornecer a solução ECMP. Esta é a solução menos recomendada pela Cisco.

Gerencia de conexões do ASA

Quando uma nova conexão é direcionada a um membro do cluster via balanceamento de carga, essa unidade possui ambas as direções da conexão. Se quaisquer pacotes de conexão chegarem a uma unidade diferente, eles serão encaminhados para a unidade Owner por meio Control Cluster Link. Se o fluxo de dados inverso chega a uma unidade diferente, ele é redirecionado de volta para a unidade original, via o Forwarder.

  • Owner – Quando o trafego é iniciado ele passa pela primeira unidade do cluster esta unidade é chamada de owner da conexão ele mantém o estado da sessão.
  • Diretor – Essa unidade controla as solicitações de consulta dos Fowarders e também mantém o estado de conexão para servir como backup se o Owner falhar. Os Diretors são escolhidos com base no hash dos endereços IP SRC/DST e as portas TCP enviadas por um Owner.
  • Forwarder – Uma unidade de Forwarder passa pacotes para o Owner. Ele pode olha o cookie SYN para determinar o fluxo Owner.

 

clusterASA

VPN Site-to-Site com overlapping de endereços

Neste post vamos falar sobre algo que pode acontecer com qualquer consultor de redes e segurança desde o nível básico a nível de arquiteto, quando configuramos o endereçamento de uma rede interna escolhemos quais serão os ranges de escala aleatória da RFC1918 para endereçamento de nossos dispositivos no ambiente.
Mas podemos nos deparar com alguns cenários onde não temos o controle sobre qual range de endereço foi definido para endereçamento dos dispositivos, então logo que estamos falando sobre VPNs entre dois site, vem o risco de sobreposição de endereços, quando isso acontece, a seguinte pergunta ocorre, eae? ferrou, como vamos resolver este problema? podemos trocar o endereço da nossa LAN? sim podemos, porém é somente a rede onde se encontra todos os servidores do nosso ambiente como AD, Banco de Dados, DNS, etc, melhor não né? ou então pode pedir para o Sysadmin do site remoto trocar o endereço dele, vamos jogar a bomba para ele né, absurdamente insano pensarmos isto, correto? Claro Sim!

Então, como podemos corrigir a sobreposição? Aham! Com NAT, mas é claro! =D

Neste post vou mostrar como usar o conceito de “Twice NAT” ou traduzindo ao pé da letra “duas vezes NAT”, com esse tipo de NAT podemos trabalhar de boa quando ocorrer sobreposição de endereços entre duas redes. Isso aí, let’s go!

Considerações antes de começarmos:

  • Conforme outros posts, não vou abordar as configurações iniciais de Firewall, ACLs, etc, estou partindo do princípios que seu ambiente já esteja configurado.
  • Antes de prosseguir com esta configuração, certifique-se que os firewalls estejam com as configurações de endereços IPs e tenham conectividade básica com internet e rotas para a rede (192.168.1.0/24) caso não sejam diretamente conectadas.

Topologia VPN Site-to-Sitenat-twice

Observem que na topologia acima, as redes LAN1 e LAN2 está definida com os mesmos endereços, 192.168.1.0/24, então em situações como esta nada melhor que nosso bom e velho NAT entrar em ação.

Para que as duas redes que estão com sobreposição de endereços se comuniquem, temos que configurar o NAT em ASA1, será definido duas sub-redes que não estejam em utilização para ambos os lados do ambiente.

Rede LAN1 192.168.1.0/24 será visto como 192.168.101.0/24 do ponto de vista da rede LAN2.
Rede LAN2 192.168.1.0/24 será visto como 192.168.201.0/24 do ponto de vista da rede LAN1.

Muito legal né! =D

A função aqui é garantir que um host 192.168.1.1 na rede LAN1 seu endereço seja traduzido para 192.168.101.1 do ponto de vista da LAN2.

Configuração de VPN
Não vou entrar em detalhes durante esta etapa porque já existe um post pronto neste link.

Configuração Fase 1
ASA-1:
ASA-1(config)# crypto ikev1 policy 10
ASA-1(config-ikev1-policy)# authentication pre-share
ASA-1(config-ikev1-policy)# encryption aes
ASA-1(config-ikev1-policy)# hash sha
ASA-1(config-ikev1-policy)# group 2

ASA-1(config)# crypto ikev1 enable OUTSIDE

ASA-1(config)# tunnel-group 101.0.0.1 type ipsec-l2l
ASA-1(config)# tunnel-group 101.0.0.1 ipsec-attributes
ASA-1(config-tunnel-ipsec)# ikev1 pre-shared-key @Cisco@123

ASA 2:
ASA-2(config)# crypto ikev1 policy 10
ASA-2(config-ikev1-policy)# authentication pre-share
ASA-2(config-ikev1-policy)# encryption aes
ASA-2(config-ikev1-policy)# hash sha
ASA-2(config-ikev1-policy)# group 2

ASA-2(config)# crypto ikev1 enable OUTSIDE

ASA-2(config)# tunnel-group 201.0.0.1 type ipsec-l2l
ASA-2(config)# tunnel-group 201.0.0.1 ipsec-attributes
ASA-2(config-tunnel-ipsec)# ikev1 pre-shared-key @Cisco@123

Fase 2 do IPsec
ASA 1:
ASA-1(config)# access-list LAN1-to-LAN2 extended permit ip 192.168.101.0 255.255.255.0 192.168.1.0 255.255.255.0

ASA-1(config)# crypto ipsec ikev1 transform-set ESP-TS esp-aes-192 esp-sha-hmac
ASA-1(config)# crypto map ASA1 10 match address LAN1-to-LAN2
ASA-1(config)# crypto map ASA1 10 set peer 101.0.0.1
ASA-1(config)# crypto map ASA1 10 set ikev1 transform-set ESP-TS
ASA-1(config)# crypto map ASA1 interface OUTSIDE

ASA 2:
ASA-1(config)# access-list LAN2-to-LAN1 extended permit ip 192.168.1.0 255.255.255.0 192.168.101.0 255.255.255.0

ASA-2(config)# crypto ipsec ikev1 transform-set ESP-TS esp-aes-192 esp-sha-hmac
ASA-2(config)# crypto map ASA2 10 match address LAN2-to-LAN1
ASA-2(config)# crypto map ASA2 10 set peer 201.0.0.1
ASA-2(config)# crypto map ASA2 10 set ikev1 transform-set ESP-TS
ASA-2(config)# crypto map ASA2 interface OUTSIDE

ASA 2:
ASA-2(config)# access-list LAN2-to-LAN1 extended permit ip 192.168.1.0 255.255.255.0
192.168.101.0 255.255.255.0

Configuração de Objetos e NAT
Um ponto importante é que toda a mágica do Twice NAT acontece apenas no ASA1, durante a configuração pode parecer um pouco confuso, I know, mas vamos tentar entender a lógica do negocio.

No ASA1 os seguintes objetos serão configurados.

ASA 1:
ASA-1(config)# object network LOCAL-LAN1
ASA-1(config-network-object)# subnet 192.168.1.0 255.255.255.0

É como a rede local será vista a partir da rede remota:
ASA-1(config)# object network LOCAL-LAN1-NAT
ASA-1(config-network-object)# subnet 192.168.101.0 255.255.255.0

ASA-1(config)# object network REMOTE-LAN2
ASA-1(config-network-object)# subnet 192.168.1.0 255.255.255.0
ASA-1(config)# object network REMOTE-LAN2-NAT
ASA-1(config-network-object)# subnet 192.168.201.0 255.255.255.0

Talvez você tenha pensado ué, LOCAL-LAN1 e LOCAL-LAN2 aponta para a mesma rede? Sim, então poderíamos utilizar apenas o objeto LOCAL-LAN1? sim poderíamos, porém, para a logica da estrutura que será construída fica mais fácil utilizar este modelo de configuração.

No ASA2 os seguintes objetos serão configurados.
ASA 2:
ASA-2(config)# object network LOCAL-LAN1
ASA-2(config-network-object)# subnet 192.168.1.0 255.255.255.0

É como a rede local será vista a partir da rede remota:
ASA-2(config)# object network LOCAL-LAN1-NAT
ASA-2(config-network-object)# subnet 192.168.201.0 255.255.255.0

ASA-2(config)# object network REMOTE-LAN2
ASA-2(config-network-object)# subnet 192.168.1.0 255.255.255.0
ASA-2(config)# object network REMOTE-LAN2-NAT
ASA-2(config-network-object)# subnet 192.168.101.0 255.255.255.0

Configuração de NAT ASA-1 & ASA-2

ASA1:
nat (INSIDE,OUTSIDE) source static LOCAL-LAN1 LOCAL-LAN1-NAT destination static REMOTE-LAN2-NAT REMOTE-LAN2

Let’s go tentar entender toda essa bagaça.

A primeira parte do comando source traduz a rede local LOCAL-LAN1 (192.168.1.0/24) para LOCAL-LAN1-NAT (192.168.101.0/24) quando ela precisar falar com  a rede REMOTE-LAN2-NAT (192.168.201.0/24)

A segunda parte do comando destination traduz a rede remota REMOTE-LAN2-NAT (192.168.201.0/24) para REMOTE-LAN2 (192.168.1.0/24).

ASA2:
nat (INSIDE,OUTSIDE) source static LOCAL-LAN1 LOCAL-LAN1 destination static REMOTE-LAN2-NAT REMOTE-LAN2-NAT

Para a configuração de NAT em ASA2, não temos nenhuma novidade, precisamos em destination apenas apontar para o objeto REMOTE-LAN2-NAT (192.168.101.0/24).

 

Topologia Final VPN Site-to-Site com Twice NAT
fw-internet

 

That’s it for now.

 

 

Configurando VPN IPsec entre ASA

A algum tempo atrás, eu tinha em mente que VPN era apenas e unicamente aquela coisa de um aplicativo ou uma configuração que é realizada somente no Windows para acessar a rede onde trabalhamos, é impressionante como nossos pensamentos vão mudando conforme vamos entendendo a real funcionalidade do negocio, e qual sua utilidade, trabalhando hoje como consultor em Redes e Segurança, posso dizer que VPN não é somente aquela configuração básica feita para acessar o ambiente onde trabalhamos, mas sim um protocolo incrível e fantástico, praticamente utilizada no mundo inteiro, hoje eu posso entender e apontar as várias vantagens para utilização delas, vamos conversar aqui sobre a VPN Site-to-Site utilizada para conectar e permitir que duas ou mais redes remotas possam conversarem como se estivessem na mesma rede local, também utilizado para redundância quando o meio principal é MPLS por exemplo, entre outros.
Estou escrevendo este post para mostrar como é feito a configuração de uma VPN Site-to-Site entre 2x ASA utilizando IPsec com IKEv1.

Tá, falei de VPN e logo em seguida comentei sobre IPSec, IKEv1 e mais um monte de nomes, vamos por partes, mas afinal o que é isso, o que é IPSec?
Vamos agora falar sobre alguma teoria por trás do IPsec, a fim de ter uma base de conhecimento para a compreensão referente a configuração que vamos iniciar.

O protocolo IPsec trabalha especificamente na camada de rede do modelo OSI, a função dele basicamente consiste na criptografia e autenticação dos pacotes IPs entre outros equipamentos participantes conhecidos como(peers), a conexão pode ser estabelecida com equipamento do tipo de Roteadores Cisco, Firewalls Cisco, softwares de VPN, etc. Como o IPsec é um padrão aberto IETF, outros fornecedores de firewall, roteadores e sistemas operacionais também suportam ele, então é ideal para construir conexões VPNs entre dispositivos de diferentes fornecedores.

Os seguintes protocolos serão usados em nossa configuração, então achei interessante dar uma pincelada basica referente ao que se trata cada um deles.

  • ESP (Encapsulation Security Payload): Fornece integridade de dados, autenticação e serviços de confidencialidade. O ESP é usado para criptografar o payload dos pacotes IPs.
  • AH (Authentication Header): Fornece integridade de dados, autenticação, não fornece serviços de criptografia, mas sim atua como uma “assinatura digital” para os pacotes para garantir que a adulteração de dados não tenha ocorrido.
  • Internet Key Exchange (IKE): Este é o mecanismo usado pelos dispositivos para iniciar a troca segura de chaves de criptografia, autenticação de peers IPsec e negociação de parâmetros de segurança IPsec. No firewall ASA, conhecemos ele como ISAKMP, vamos ver na pratica como é a configuração.
  • DES, 3DES, AES: Todos eles são algoritmos de criptografia suportados pelo Cisco ASA Firewall.
  • Diffie-Hellman Group (DH): Este é um protocolo de criptografia de chave pública usado pela IKE para estabelecer a sessão de chaves.
  • MD5, SHA-1: Ambos são algoritmos de hash usados para autenticação de dados para os pacotes. O algoritmo SHA é mais forte do que MD5.
  • Security Association (SA): Quando se fala em uma conexão IPsec é muito comum fazer referencia para uma SA, que nada mais é uma conexão entre dois peers IPsec. Cada peer IPsec mantém um banco de dados SA em sua memória contendo parâmetros SA, basicamente é endereço do peer remoto, protocolos de segurança e parâmetros de segurança.

Topologia Site-to-Site IPSEC IKEv1

drawing1

O nosso objetivo aqui é conectar as duas redes LAN distantes através da Internet e utilizando o protocolo IPsec estaremos aplicando um nível maior de segurança dizendo que qualquer pacote que trafegar dentro do tunel será criptografado.
As redes locais também chamadas de uma LAN eu digo que +|- 90 – 95% das vezes elas estão utilizando endereçamento privados RCF1918 como mostrado em nosso diagrama acima e fazendo NAT no Firewall ou Roteador para acesso a internet. Então sem a conectividade de VPN, as duas redes LAN acima (LAN1 e LAN2) seriam incapazes de se comunicarem entre elas. Agora que acontece a mágica, configurando uma VPN Site-to-Site com IPsec entre os dois firewalls ASA, podemos estabelecer um túnel seguro pela Internet e passar nosso tráfego dentro deste túnel. O resultado é que os hosts na rede 192.168.1.0/24 agora podem acessar diretamente hosts na rede 192.168.2.0/24 e vice-versa como se estivessem localizados na mesma LAN. O túnel IPsec é estabelecido entre os endereços IP públicos dos firewalls (201.0.0.1 e 101.0.0.1).

Podemos dizer que basicamente existem cinco etapas na operação do IPsec, descreveremos os comandos de configurações necessários para cada etapa a fim de configurar a VPN. Para todos os exemplos de configurações estamos utilizando como base o diagrama de rede acima. Esta configuração é para o IPsec IKEv1 . Em um outro post veremos também como configurar VPNs IPsec com IKEv2.

Obs. Não estarei abordando neste post a configuração inicial do ASA bem como acesso a Internet, NAT, ACLs, etc, isto será assunto para outros posts, vamos lá configurar está bagaça.

Passo1: Configurar tráfego interessante, ou seja, qual rede que vamos tunelar pela VPN.
Usando uma ACL podemos identificar qual fluxo de tráfego deve ser criptografado. Em nosso diagrama acima, queremos que todo o fluxo de tráfego entre as redes 192.168.1.0/24 e 192.168.2.0/24 sejam criptografados.

ASA 1:
ASA-1(config)# access-list LAN1-to-LAN2 extended permit ip 192.168.1.0 255.255.255.0
192.168.2.0 255.255.255.0

ASA 2:
ASA-2(config)# access-list LAN2-to-LAN1 extended permit ip 192.168.2.0 255.255.255.0
192.168.1.0 255.255.255.0

Atenção.  Reparem que a lista de acesso é espelho entre os Firewalls que participam da VPN Site-to-Site,  é muito comum encontramos problemas com ACLs que classificam as redes por exemplo com a mascara diferente, e acreditam em mim, é complicado pra caramba identificar o problema, então, quando se deparar com instabilidades na Fase 1 com o túnel VPN subindo e caindo de uma olhadinha nas ACLs em ambos os firewalls. =)

Exclusão NAT para tráfego VPN
Uma questão importante a considerar é o caso de usar NAT no firewall para acesso à Internet.
Como o IPsec não funciona com NAT, precisamos excluir o tráfego a ser criptografado da operação NAT, segue exemplos de como configurar para versões acima da 8.3).

ASA 1:
ASA-1(config)# object network VPN-LOCAL
ASA-1(config-network-object)# subnet 192.168.1.0 255.255.255.0
ASA-1(config-network-object)# exit
ASA-1(config)# object network LAN-REMOTO
ASA-1(config-network-object)# subnet 192.168.2.0 255.255.255.0
ASA-1(config-network-object)# exit
ASA-1(config)# nat (INSIDE,OUTSIDE) source static VPN-LOCAL VPN-LOCAL destination static LAN-REMOTO LAN-REMOTO

ASA 2:
ASA-2(config)# object network VPN-LOCAL
ASA-2(config-network-object)# subnet 192.168.2.0 255.255.255.0
ASA-2(config-network-object)# exit
ASA-2(config)# object network LAN-REMOTO
ASA-2(config-network-object)# subnet 192.168.1.0 255.255.255.0
ASA-2(config-network-object)# exit
ASA-2(config)# nat (INSIDE,OUTSIDE) source static VPN-LOCAL VPN-LOCAL destination static LAN-REMOTO LAN-REMOTO

Passo2: Configuração Fase 1 IKEv1 ou ISAKMP como preferir chamar =)
A Fase 1 da operação IPsec é usada para estabelecer o primeiro túnel de comunicação para transmissão de dados. Na fase 1, os peers de VPN trocam chaves secretas compartilhadas, autenticam-se, negociam políticas de segurança de IKE, etc. Nesta Fase nós configuramos uma política de ikev1 que DEVE combinar a política configurada no outro peer. Esta política ikev1 diz aos outros peers quais parâmetros de segurança devem ser usados na VPN.

ASA 1:
ASA-1(config)# crypto ikev1 policy 10
ASA-1(config-ikev1-policy)# authentication pre-share
ASA-1(config-ikev1-policy)# encryption aes
ASA-1(config-ikev1-policy)# hash sha
ASA-1(config-ikev1-policy)# group 2

ASA-1(config)# crypto ikev1 enable OUTSIDE

ASA-1(config)# tunnel-group 101.0.0.1 type ipsec-l2l * IP do peer Remoto
ASA-1(config)# tunnel-group 101.0.0.1 ipsec-attributes
ASA-1(config-tunnel-ipsec)# ikev1 pre-shared-key @Cisco@123

ASA 2:
ASA-2(config)# crypto ikev1 policy 10
ASA-2(config-ikev1-policy)# authentication pre-share
ASA-2(config-ikev1-policy)# encryption aes
ASA-2(config-ikev1-policy)# hash sha
ASA-2(config-ikev1-policy)# group 2

ASA-2(config)# crypto ikev1 enable OUTSIDE

ASA-2(config)# tunnel-group 201.0.0.1 type ipsec-l2l # IP do peer Remoto
ASA-2(config)# tunnel-group 201.0.0.1 ipsec-attributes
ASA-2(config-tunnel-ipsec)# ikev1 pre-shared-key @Cisco@123

Passo3: Após estabelecer o túnel na Fase 1, a próxima etapa na configuração da VPN é negociar os parâmetros de segurança IPsec que serão usados para proteger os dados e as mensagens dentro do túnel, isto é o que acontece durante a Fase 2 do IPSEc.

ASA 1:
ASA-1(config)# crypto ipsec ikev1 transform-set ESP-TS esp-aes-192 esp-sha-hmac
ASA-1(config)# crypto map ASA1 10 match address LAN1-to-LAN2
ASA-1(config)# crypto map ASA1 10 set peer 101.0.0.1
ASA-1(config)# crypto map ASA1 10 set ikev1 transform-set ESP-TS
ASA-1(config)# crypto map ASA1 interface OUTSIDE

ASA 2:
ASA-2(config)# crypto ipsec ikev1 transform-set ESP-TS esp-aes-192 esp-sha-hmac
ASA-2(config)# crypto map ASA2 10 match address LAN2-to-LAN1
ASA-2(config)# crypto map ASA2 10 set peer 201.0.0.1
ASA-2(config)# crypto map ASA2 10 set ikev1 transform-set ESP-TS
ASA-2(config)# crypto map ASA2 interface OUTSIDE

Passo4: Verificação se o túnel está UP
Com os três passos acima concluímos a configuração de uma VPN IPsec Site-to-Site. Agora, podemos iniciar a verificação se tudo está funcionando conforme esperamos e se os dados estão realmente sendo criptografados pelos firewalls. Vamos utilizar dois comandos importantes que o ajudarão a verificar se o túnel está estabelecido e se os dados sendo bidireccionalmente criptografados.

Verificar se o túnel está estabelecido
O comando show crypto isakmp sa verifica se a Security Association (SA) está estabelecida, o que significa que o túnel está em funcionamento. Vamos ver um exemplo de saída deste comando abaixo:

ASA1# show crypto isakmp sa
IKEv1 SAs:

Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1 IKE Peer: 101.0.0.1
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
There are no IKEv2 SAs

O ponto importante aqui é observar que o State : MM_ACTIVE. Isso confirma que a Fase 1 do IPsec foi estabelecido com sucesso.

Verificar se os dados estão criptografados bidirecionalmente
O comando show crypto ipsec sa verifica se os dados estão sendo criptografados e descriptografados.

ASA1# show crypto ipsec sa
interface: OUTSIDE
Crypto map tag: ASA1, seq num: 10, local addr: 101.0.0.1
access-list LAN1-to-LAN2 permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
current_peer: 201.0.0.1

#pkts encaps: 3150, #pkts encrypt: 2050, #pkts digest: 2050
#pkts decaps: 2108, #pkts decrypt: 3149, #pkts verify: 2108
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 2050, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 101.0.0.1, remote crypto endpt.: 201.0.0.1
—Output Omitted—

A saída #pkts encrypt:3150 e #pkts decrypt:3149 mostram que temos criptografia de dados bidirecional.

 

 

Isso é tudo por hoje, espero que possa ajudar alguém!