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: