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

Que são Vlans e Bridge Groups?

O que são VLANs?

Uma VLAN ou (Virtual Area Networks) é um agrupamento lógico de dispositivos de rede ou de usuários que não se limita a um segmento de switch físico. Os dispositivos ou usuários de uma VLAN podem ser agrupados por funções, departamentos, aplicações, etc., independentemente da localização física de seu segmento. Uma VLAN cria um domínio de broadcast único que não se restringe a um segmento físico, e é considerado como uma sub-rede. A configuração da VLAN é realizada no switch através do software. As VLAN atuais foram padronizadas de acordo com a norma IEEE 802.1Q.

Sem título

É importante em qualquer arquitetura de VLAN, tenha a capacidade de transportar informações de VLAN entre todos os switches da rede pois a cada frame de dados a que atravessar um switch é feito uma inserção de TAG ou identificação que faz referencia aquela VLAN que o frame faz parte.

vlans2

Roteamento Inter-VLAN

Após segmentar a rede em vários domínios de broadcast utilizando VLANs, se tivermos utilizando um firewall por exemplo precisamos permitir a conectividade entre computadores de VLANs diferentes. Quando não existe um dispositivo de Firewall entre as VLANs de diferentes segmentos de Rede temos que utilizar um dispositivo Layer 3, que realize o roteamento entre as VLANs.

inter-vlans

 

Bridge Group

Os Bridge Group (BG) foram criados para fornecer um método para agrupar duas ou mais VLANs em um único domínio de broadcast, o bridge group é usado para conectar o tráfego entre duas interfaces. Por exemplo, agrupar duas VLANs conectadas por meio de um Firewall e fazer a inspeção de trafego dentro dessa rede, o funcionamento consiste em configurar uma para tráfego de VLAN L2 e outra L3 para fazer parte do mesmo bridge group. Isso criará uma ligação entre as duas VLANs e os pacotes Ethernet de uma LAN serão visíveis na outra. Se definir o bridge-group em ambas as interfaces, elas se tornarão parte de um único domínio de broadcast.

Na topologia abaixo é uma demonstração de comunicação entre duas redes utilizando bridge group, quando o PC1 iniciar o tráfego fora da sua sub-rede, ele irá fazer o ARP para o seu gateway, que começará na VLAN 100, em seguida, vai atravessar o firewall para VLAN 110, então o switch SW responderá na VLAN 110 enviando o trafego para o PC2 com base nas informações na sua tabela de roteamento.

bridge-group

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.

 

 

Upgrade NSX Manager 6.2.2/3 para 6.2.4

Após um bom tempo apanhando em busca de materiais/informações na internet com procedimentos sobre como realizar o upgrade de NSX, resolvi criar este passo a passo com todas as informações que utilizei durante minhas atividades.

Antes de começar é extremamente recomendado que seja feita a leitura completa do Release Notes referente a versão que está sendo atualizada.

Para o upgrade de versão do NSX, devemos seguir os seguintes passos para atualização da Manager e os demais componentes.

1. Appliance do NSX Manager
2. Cluster de Controllers
3. Hosts (VIBs)
4. NSX Edge/DLR
5. Endpoint/Data Security

nsx-up-1

Considerações antes da atualização:

  • Não deixe de ler e prestar atenção no Release Notes para versão do NSX.
  • Precisamos fazer o download do bundle de atualização do NSX e verificação do MD5.
  • Faça backup da Manager do NSX, é uma boa opção também realizar um snapshot da VM do NSX antes da atualização, faça um backup da configuração do Web Client do Vsphere.

Passo1:
Primeiramente precisamos acessar o site da VMware e baixar o bundle de upgrade do NSX.

bundle

Passo2:
Conectar ao NSX Manager e siga para a página de atualização, selecionar o botão Upgrade.

00

E informe a localização do arquivo “VMware-NSXManager-
upgrade-bundle-6.2.4-4292526.tar.gz”.

nsx1

Agora isso vai demorar um bom tempo até terminar o upload é super recomendado que você vá até a máquina de café e se sirva. =)

01-upload-bundle

Após terminar o upload será apresentado a seguinte página responda as duas opções e clique em Upgrade para continuar.

03-upload-bundle

Passo3:
Após terminar o upgrade podemos verificar que a manager foi atualizada corretamente e se encontra na versão 6.2.4, precisamos checar se todos os serviços estão rodando, clique em “View Summary”.

nsx8

Tudo se encontra em ótimas condições, podemos confirmar isto analisando os campos “Common Components e NSX Management Components”. NEXT =)

nsx9

Passo3:
Após atualização da Manager, precisamos atualizar o Cluster de Controllers. Entre no Web Client do vCenter e vá até Networking & Security > Installation. Na aba “Management” será apresentada uma informação de atualização disponível para os Controllers “Upgrade Available”. Clique sobre ela para iniciar o processo de atualização.

Uma janela solicitando a confirmação de upgrade será apresentada, apenas clique em Yes para prosseguir.

upgrade8

Isso leva algum tempo para terminar, minha recomendação é que você retorne a máquina de café e se sirva novamente. =)

upgrade11

Obs. Os controllers serão reiniciados um após o outro depois do upgrade.

upgrade13

Posso4:
Estamos quase chegando ao final do nosso objetivo, agora é a parte mais legal na minha opinião, atualização das VIBs dos Hosts!
Este processo é obrigatório que os Hosts que fazem parte do cluster ESXi sejam reiniciados após atualização de cada um deles, então vamos ao que interessa.
Para começarmos nosso upgrade, vamos no seguinte caminho Networking & Security > Installation > Host Preparation, será a apresentando uma informação de “upgrade available”, ao clicar nela serão instaladas as VIBs para os respectivos Hosts daquele Cluster.

untitled

Uma janela solicitando a confirmação de upgrade será apresentada, apenas clique em Yes para prosseguir.

nsx17

Em alguns casos na aba Installation Status pode acontecer de apresentar a seguinte mensagem ‘Not Ready‘, clique sobre a mensagem de erro em vermelho e após clique em Resolve all.

nsx19

Passo5:
Após terminar a instalação das VIBs em todos os hosts precisamos reiniciar cada um deles, acabei não fazendo o print das imagens para esta etapa “I’m sorry”, mas basicamente o processo é o seguinte, para cada host que será reiniciado precisamos mudar ele para modo de manutenção e esperar que as VMs sejam migradas para o outro Host do cluster e então podemos reiniciar em segurança, simples e fácil assim. =D

No final tudo deve ficar como a imagem abaixo, pronto, as VIBs foram instaladas corretamente aos Hosts do Cluster, NEXT.

nsx21

Passo6:
Para a última etapa será feito o upgrade dos Edges e DLRs, vamos em Networking & Security > NSX Edges, observe que eles estão na versão 6.2.3.

nsx25

Clique com o botão direito em cada dispositivo que será feito o upgrade e em
seguida, selecione “Upgrade Version”.

nsx30

Uma janela solicitando a confirmação de upgrade será apresentada, apenas clique em Yes para prosseguir com o upgrade.

nsx23

Após a atualização podemos verificar que o status dos Edges e DLRs estão com a versão de imagem correta 6.2.4.

nsx32

 

Espero que este post seja útil para você, obrigado!

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!

Procedimento para Recover de Password FW ASA

Se por algum motivo você ficou bloqueado para o lado de fora do ASA ou simplesmente estiver precisando iniciar o procedimento para fazer Recovery de Password, os seguintes passos pode ser de grande ajudar para resolver este problema.

Passo 1:
Conecte um um cabo de console ao ASA, desligue e ligue o equipamento.

Passo 2:
Pressione continuamente a tecla “ESC” do teclado até o dispositivo entrar no modo ROMMON. O seguinte modo será exibido:
Rommon #1>

Passo 3:
Será preciso mudar o “Config Register”, está configuração controla como a será lida a startup-config.

Passo 4:
Agora é preciso alterar o valor do confreg para 0x41, o que estamos dizendo aqui é para o Firewall ignorar a configuração da startup-config durante a inicialização. Após definir o novo confreg, reinicie o equipamento.
Rommon #2> confreg 0x41
Rommon #3> boot

Passo 5:
Nosso FW ASA irá ignorar a configuração de inicialização da startup-config, ao digitar “enable” você vai perceber que nenhuma senha foi solicitada.
Ciscoasa> enable
Senha: ciscoasa#

Passo 6:
Agora precisamos copiar o arquivo de configuração da startup-config para a running-config.
ciscoasa# copy startup-config running-config
Deixe o nome do arquivo para o destino conforme sugerido [running-config]?

Passo 7:
Agora configure uma a nova senha e também precisamos voltar a configuração do Config Register para seu valor original (0x01).
ciscoasa# configure terminal
ciscoasa(config)# enable password X@cisco@123
ciscoasa(config)# config-register 0x01
ciscoasa(config)# write mem

Passo 8:
Recomendo que seja feito outro reload no Firewall para validar as configurações. Após Reiniciar você deve ser capaz de entrar com a nova senha.
ciscoasa(config)# reload