Configuração Básica do Firewall Cisco ASA no Packet Tracer

Olá Pessoal,

Desde a versão 6.1.0 do Cisco Packet Tracer, lançado em junho/2014, existe a opção de o usuário inserir um firewall ASA 5505 em seus laboratórios a partir da paleta de componentes que fica localizada no canto inferior esquerdo da interface do simulador (seção Security). Ainda que as opções de configuração do dispositivo sejam bastante limitadas no simulador, pelo menos é possível começar a interagir um pouco com o sistema operacional dessa appliance de segurança que tem suas próprias particularidades em comparação ao tradicional IOS utilizado em switches e roteadores.

Figura. Visão Frontal do Firewall Cisco ASA 5505

O sistema do firewall ASA tem muitas particularidades que devem ser compreendidas antes de configurar o equipamento. A seguir farei uma síntese das características principais do firewall para que possamos avançar na resolução de um laboratório simples. Por padrão o ASA 5505 vem configurado com 2 VLANs:

• VLAN 1: REDE INTERNA (inside) nas interfaces e0/1 até e0/7
• VLAN 2: REDE EXTERNA (outside) na interface e0/0

Infelizmente no Packet Tracer ainda não é possível criar uma terceira VLAN vinculada a uma zona de segurança, por exemplo para servidores públicos em uma DMZ, porque o dispositivo possui apenas uma licença básica. Ao tentar fazê-lo no simulador, o leitor receberá a seguinte mensagem de erro:

"This license does not allow configuring more than 2 interfaces with nameif and without a "no forward" command on this interface or on 1 interface(s) with nameif already configured."

Uma característica importante do ASA é que, por padrão, todo tráfego entrante na interface outside é negado, a menos que sejam configuradas regras de acesso (ACL) que permitam um determinado perfil de tráfego entrante. Cada interface é associada a uma zona de segurança através do parâmetro nameif, como pode ser observado nas linhas abaixo. Além disso, cada interface possui um nível de segurança (security-level) que varia de 0 a 100, sendo 0 o nível menos seguro (padrão na interface outside) e 100 o nível mais seguro (padrão nas interfaces inside). A configuração desse parâmetro é importante porque outro comportamento padrão do ASA é que todo tráfego originado por uma interface mais segura pode atravessar em direção a uma interface menos segura, no entanto o contrário não é permitido, ou seja, todo tráfego vindo de uma interface menos segura não pode atravessar em direção a uma interface mais segura.

interface Ethernet0/0
  nameif outside
  security-level 0
!
interface Ethernet0/1
  nameif inside
  security-level 100

O objetivo deste artigo é explorar algumas das particularidades técnicas de configuração do firewall Cisco ASA-5505, o modelo de entrada da família ASA (Adaptive Security Appliance) que vem sendo substituído pelo ASA-5506-X. Para fazê-lo será utilizado o laboratório apresentado na figura abaixo, lembrando que estaremos restritos a alguns dos recursos que são suportados pelo simulador Packet Tracer.

Clique aqui para baixar o arquivo do laboratório (.pkt)

Observe que o cenário é simples, onde existe uma rede interna 192.168.0.0/24 conectada à Internet através de um ASA. A interface e0/1 do ASA que está definida na zona inside (VLAN 1) é o gateway da rede interna (192.168.0.1), enquanto que a interface e0/0 definida na zona outside (VLAN2) recebe do provedor um IP na Internet (203.0.113.1). As configurações são realizadas nas interfaces do tipo VLAN, já que múltiplas portas físicas normalmente são associadas a sua respectiva zona de segurança através de uma VLAN. A interface e0/0 está associada à VLAN 2 pelo comando padrão "switchport access vlan 2". A configuração de associação das interfaces pode ser alterada de acordo com o ambiente do usuário a partir do mesmo comando seguido da VLAN correspondente.

A resolução deste laboratório requer os seguintes comandos:

01. ciscoasa> enable
02. ciscoasa# configure terminal
03. ciscoasa(config)# hostname ASA-FW
04. ASA-FW(config) # interface vlan 1
05. ASA-FW(config-if)# nameif inside
06. ASA-FW(config-if)# security-level 100
07. ASA-FW(config-if)# ip address 192.168.0.1 255.255.255.0
08. ASA-FW(config-if)# exit
09. ASA-FW(config)# interface vlan 2
10. ASA-FW(config-if)# nameif outside
11. ASA-FW(config-if)# security-level 0
12. ASA-FW(config-if)# ip address 203.0.113.1 255.255.255.252
13. ASA-FW(config-if)# exit
14. ASA-FW(config)# route outside 0.0.0.0 0.0.0.0 203.0.113.2
15. ASA-FW(config)# object network NAT-LAN
16. ASA-FW(config-network-object)# subnet 192.168.0.0 255.255.255.0
17. ASA-FW(config-network-object)# nat (inside,outside) dynamic interface
18. ASA-FW(config-network-object)# exit 
19. ASA-FW(config)# access-list ENTRADA extended permit icmp any any
20. ASA-FW(config)# access-list ENTRADA extended permit tcp any eq www any
21. ASA-FW(config)# access-group ENTRADA in interface outside

As configurações básicas da rede interna (interface vlan 1) foram realizadas nas linhas 04-07, oportunidade em que definimos a zona inside (nameif), o nível mínimo de segurança (100) e o IP (192.168.0.1/24). As configurações básicas da rede externa (interface vlan 2) foram realizadas nas linhas 09-12, oportunidade em que definimos a zona outside (nameif), o nível máximo de segurança (0) e o IP (203.0.113.1). Na linha 14 foi adicionada uma rota default (0.0.0.0 0.0.0.0) direcionando ao provedor a saída do tráfego para a Internet. Nas linhas 15-17 criamos um objeto associado à rede interna para realização da tradução dos endereços (NAT), procedimento necessário para que as máquinas com endereços privados sejam capazes de receber resposta dos servidores da Internet endereçados publicamente. Nas linhas 19-21 criamos e aplicamos uma regra para permitir o recebimento de respostas ping (ICMP) para testar a conectividade das máquinas da rede interna com o host remoto (1.1.1.1), já que o comportamento padrão do ASA é negar todo tráfego vindo de uma interface com security-level menor que o destino. Reparem que também permitimos a entrada de qualquer tráfego web de resposta (porta de origem = 80), assim as máquinas clientes conseguem acessar o servidor web através do navegador.

As configurações básicas podem ser visualizadas através dos comandos abaixo:

ASA-FW# show ip

(...) Saída Omitida

Current IP Addresses:

Interface Name  IP Address   Subnet Mask      Method

Vlan1 inside    192.168.0.1  255.255.255.0    manual

Vlan2 outside   203.0.113.1  255.255.255.252  manual

ASA-FW# show switch vlan

VLAN Name    Status Ports

---- -------------------------------- --------- -------------------------------

1    inside  up     Et0/1, Et0/2, Et0/3, Et0/4, Et0/5, Et0/6, Et0/7

2    outside up     Et0/0

ASA-FW# show route

(...) Saída Omitida

Gateway of last resort is 203.0.113.2 to network 0.0.0.0

C 192.168.0.0 255.255.255.0 is directly connected, inside

203.0.113.0/30 is subnetted, 1 subnets

C 203.0.113.0 255.255.255.252 is directly connected, outside

S* 0.0.0.0/0 [1/0] via 203.0.113.2

ASA-FW# show access-list

(...) Saída Omitida

access-list ENTRADA line 1 extended permit icmp any any(hitcnt=13) 0x3843e9e3
access-list ENTRADA line 2 extended permit tcp any eq www any(hitcnt=3) 0x7b11a3a4

Façam seus testes...

Samuel. 

CGNAT na Transição IPv6: Solução ou Vilão?

Olá Pessoal.

O Carrier Grade NAT (CGN) ou Large Scale NAT (LSN), definido na RFC 6264, é uma técnica de tradução de grande porte que vem sendo praticada por algumas operadoras de telecomunicações que não possuem mais endereços IPv4 disponíveis e, portanto, se encontram em situação crítica. Essa prática consiste em aplicar o NAT na própria rede da operadora, antes mesmo de chegar ao usuário, entregando para seu cliente um endereço privado, conforme ilustrado na figura abaixo.

Se o NAT (também chamado de NAT44), por si só, já é uma agressão aos princípios arquiteturais da Internet por quebrar o modelo fim-a-fim e tornar o funcionamento de algumas aplicações mais complexo, o CGN é ainda mais grave porque implica na prática daquilo que chamamos de NAT444 ou pejorativamente de "NAT do NAT".

Um primeiro problema do NAT444 é o uso de endereços privados 10/8, 172.16/12 e 192.168/16 da RFC1918, afinal, existe a possibilidade de haver conflito entre os planos de endereçamento utilizados nas redes internas dos clientes e das operadoras. Para "sanar" esse problema e evitar o conflito de endereços, a RFC6598 reserva o prefixo 100.64.0.0/10 como sendo uma faixa privada não roteável na Internet e de uso exclusivo das operadoras. 

Ao se quebrar o modelo fim-a-fim, perde-se a possibilidade de alcançabilidade "direta" entre os pontos (em layer-3), o que torna o gerenciamento e a configuração da rede mais complexa. No entanto, a empresa (ou usuário residencial) ainda tem autonomia para criar políticas de redirecionamento (port-forwarding) através da escrita de regras em seu roteador de borda, permitindo que seu único endereço público possa direcionar o usuário externo às suas aplicações internas que estão escondidas da Internet por obscuridade. 

Com o NAT444, essa autonomia deixa de existir, porque o endereço público que tem alcançabilidade na Internet é de posse da operadora apenas, não mais da empresa. Dessa forma, os administradores da rede vão depender da ação conjunta das operadoras para que as políticas de redirecionamento de tráfego sejam escritas nos próprios roteadores da operadora, o que traz consigo vários problemas para os clientes e também para as operadoras.

Essa prática literalmente acaba com a autonomia da empresa/usuário em criar suas políticas de redirecionamento, afinal, ela fica totalmente dependente da operadora para "auxiliar" nesse processo, o que compromete a flexibilidade, escalabilidade e segurança. Cabe destacar que essa técnica é ruim, inclusive para a operadora, afinal, "administrar" as políticas individuais dos seus clientes é oneroso.

Além disso, para aqueles que sempre defenderam o NAT como medida de segurança (o que ele nunca foi, já que NAT foi criado para economizar IPs), a segurança do ambiente fica comprometida. Com CGNAT a operadora conhece detalhadamente quais portas/serviços estão em execução nos servidores privados, ou seja, é o fim da obscuridade para aqueles que defendiam essa prática e o começo da "iluminação absoluta"!

Essa discussão é aprofundada no meu livro intitulado "IPv6 - O Novo Protocolo da Internet", por isso sugiro sua leitura para os interessados no assunto. Por fim trago mais um vídeo produzido pelo NIC.br, dessa vez apresentando o CGNAT.

Samuel.

NAT no Redirecionamento de Endereços e Portas

Olá Pessoal.

Esse é mais um daqueles artigos que não aborda conteúdo relacionado aos exames de nível CCNA da Cisco, mas que explica como configurar algo muito comum no cotidiano das empresas: o redirecionamento de endereços e portas para que um dado serviço em execução na rede interna privada possa ser acessível através da Internet pública.

No Lab10 do livro "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes" o leitor aprende a configurar o NAT para realizar a tradução dos endereços IPv4 privados de origem de uma rede interna para endereços públicos roteáveis na Internet, um procedimento denominado SNAT que é utilizado pelas empresas para fins de compartilhamento da Internet. 

Cabe apenas destacar que essa modalidade de NAT foi criada com o objetivo principal de economizar endereços IPv4, uma vez que toda uma rede com endereços privados da RFC 1918 (10/8, 172.16/12 e 192.168/16) pode ter acesso à Internet através de apenas um (ou poucos) endereço(s) público(s).  

No entanto, além do SNAT para fins de compartilhamento da Internet, existe uma outra modalidade de NAT, denominada DNAT, em que é feita a tradução dos endereços de destino. Apesar de DNAT não ser cobrado no exame CCNA, em contraste ao SNAT que é bastante cobrado, o DNAT é bastante praticado pelas empresas para fins de redirecionamento de endereços/portas e até mesmo para fins de balanceamento de carga (quando o destino redirecionado são vários endereços).

Nesse artigo estarei utilizando o cenário da figura abaixo (um complemento do Lab10 do livro) para mostrar como o NAT pode ser configurado para realizar o redirecionamento de endereços e portas de forma que um dado serviço web (intranet) em execução na rede privada 172.22.0.0/16, especificamente no servidor 172.22.0.1, possa ser acessado pelos funcionários da empresa em suas casas, através da Internet.

Nesse caso, como a rede utiliza o endereço privado 172.22.0.0/16 da RFC 1918, então o serviço web em execução no servidor não pode ser acessado através da Internet porque esses endereços simplesmente não são roteáveis publicamente. O primeiro ponto da empresa que tem alcançabilidade pela Internet é seu roteador de borda que possui o endereço público 100.1.1.2/30, provido por seu ISP. No Lab10 do livro esse mesmo cenário foi configurado com o NAT (SNAT) para realizar o compartilhamento da Internet para todas as máquinas da rede privada.

Agora trago um exemplo de como ficaria a configuração para habilitar o NAT na modalidade DNAT , permitindo que todo acesso destinado ao endereço público do roteador de borda (100.1.1.2) na porta 8080 seja redirecionado para o endereço privado 172.22.0.1 na porta 80.

01. Router-NAT(config)# int f0/0

02. Router-NAT(config-if)# ip nat inside

03. Router-NAT(config-if)# int s0/0

04. Router-NAT(config-if)# ip nat outside

05. Router-NAT(config-if)# exit

06. Router-NAT(config)# access-list 1 permit 172.22.0.0 0.0.255.255

07. Router-NAT(config)# ip nat inside source list 1 interface s0/0 overload

08. Router-NAT(config)# ip nat inside source static tcp 172.22.0.1 80 100.1.1.2 8080

Obs.: As configurações apresentadas nas linhas de 01 a 07 já existem no Lab10 do livro e foram utilizadas para definir as zonas inside (rede interna privada) e outside (zona externa pública) e para realizar a tradução dos endereços de origem para compartilhamento da Internet (linha 07). 

A configuração do NAT para fazer o redirecionamento de portas/endereços é exibida na linha 8 (destacada em amarelo), onde informamos o mapeamento estático entre um endereço inside e outro outside (e suas respectivas portas). Reparem, portanto, que "dissemos" ao roteador que todos os pacotes destinados ao seu endereço público na porta 8080 (100.1.1.2:8080) devem ser encaminhados para o endereço privado do servidor na porta padrão (172.22.0.1:80). 

Simples assim e bastante útil no cotidiano...

Abraço.

Samuel.