Sunday, September 22, 2013
VPN Site-To-Site em ASA 8.02
Algum tempo atrás escrevi um post sobre VPN Client-to-Site e no final do post prometi escrever um de Site-to-Site. Desde então me envolvi em vários outros assuntos e acabei não escrevendo. Porém, como VPN Site-to-Site é um assunto de extrema importancia e muito interessante, vou escrever hoje.
Esse tipo de assunto é bem melhor mostrado em forma de vídeo, mas fazer um vídeo requer algumas técnicas e condições que ainda não é meu foco. Desta forma, vamos por post mesmo.
Ao final vou deixar a running-config de dois ASAs para rodar em GNS3.
Tenho trabalhado quase que todo dia com VPN. Seja em ASA ou em Checkpoint, VPN é um recurso largamente usado. Não só por uma questão de segurança, mas permite montar uma topologia com certa versatilidade, além de segura, que atende os requerimentos de muitas empresas que não podem arcar com uma núvem MPLS ou BGP.
ASA é um firewall Cisco muito utilizado por apresentar um ótimo custo benefício. Atualmente entrando na versão 9.0, é mais comum nas versõa 8.x. A versão 8.4 por exemplo, ainda é bem recente e apresenta algumas mudanças em relação às versões anteriores como NAT e IKE v2. Além de possuir uma politica de ACLs mais parecida com um Checkpoint. Aliáis, Checkpoint deve ser um norte da Cisco e de muitos outros fabricantes para Firewall. Apesar do ASA ser preferível na hora de um troubleshooting devido ao IOS, ou muito similar, Checkpoint é incontestavelmente um firewall superior.
Neste post usaremos ASA mas é possivel rodar Checkpoint com uma versão de avaliação. E valeu muito apena aprender sobre esse Firewall.
A versão do nosso ASA será o 8.02. Tenho também a versão 8.4 mas é bem pesado.
Vamos mostrar nossa topologia:
Server_001 é um servidor Linux microcode emulado em QEMU, bem como o Server_001_4. Temos dois ASAs , R1 faz apenas o Layer 2, apesar do simbolo ser de um 6500 com FWSM e C2 é a conexão com nossa máquina física. A idéia é instalar ASDM nos ASAs e numa próxima oportunidade mostrar também por interface gráfica.
Assim poderemos aproveitar o port "ASDM 6 no ASA 8.0" escrito em e que considero o mais interessante que já escrevi pela complexidade do assunto.
A configuração dos Linux é bem simples:
ifconfig ethx "ip address" netmask "máscara"
route add default gw "ip do gateway"
Não precisa nada mais do que isso para fazer teste de ping e telnet de um para o outro.
No ASA1 foi definido duas internfaces : "inside" e outside". Por default, o IOS atribui peso 100 à interface com nome "inside" e peso zero a qualquer outro nome. Isso é automático e pode ser deixado dessa forma.
Porém, é interessante entender como funciona a relação entre as interfaces de um ASA. Security Level , como é chamado, pode proporcionar algumas surpresas desagradáveis quando não tratadas de acordo, podendo, inclusive, derrubar uma rede.
Não vou entrar em detalhes aqui mas vale dizer que interface com peso 100 é considerada mais segura e interface com peso zero menos segura. Fluxo de uma interface mais segura para uma menos segura é permitido. Porém, o contrário é barrado. Para um fluxo fluir de uma interface de peso zero para uma de peso 100 é preciso permitir com uma ACL colocada na interface de origem do fluxo.
Outro ponto que merece muita atenção é em relação ao NAT. Já vi várias redes serem derrubadas ao aplicar NAT em uma interface do ASA que não tinha NAT ainda configurado. Quando se aplica o NAT para um determinado destino, ele passa a fazer NAT para todos as interfaces. É preciso colocar um NAT Exempt para as interfaces onde não se deseja ter NAT. Na minha topologia teremos um exemplo de NAT Exempt.
As VPNs são dividas em Fase 1 e Fase 2. Na Fase 1 é realizado as definições de parâmetros mais próximo a camada física enquando na Fase 2 é definido políticas de camada 3 ou também chamado de "Interesting traiffic".
As primeiras configurações em um Firewall que receberá sua primeira configuração de VPN, como é o nosso caso, será a definição das políticas de Fase 1.
É fundamental que ambos os Firewalls concordem em todas as políticas. Do contrário, a VPN não irá se estabelecer.
VPNs são constrídas sobre IPSec, uma abreviação de IP Security. IPSec é um conjunto de protocolos que se integram para oferecer uma conexão fim-a-fim com segurança.
Até pouco tempo atrás, eu diria que IPSec oferece uma conexão fim-a-fim com máxima segurança mas, após os escândalos recentes divulgados pela Mídia, através das contribuições de Eduard Snowden, hoje sabemos que infelizmente não é bem assim.
A NSA é capaz de quebrar esse tipo de segurança e outros que considerávamos muito seguros. Fazem isso em conlui com as empresas que desenvolveram esses protocolos como a RSA. Essas empresas deixam brechas, backdoor ou/e outros artificios que permitem ao governo americano analisar dados mesmos em conexões antes consideradas acima de qualquer suspeitas.
Estou colocando isso aqui porque realmente é uma informação que precisa ser analisada em qualquer meio técnico. Se antes profissionais de TI, especialmente de Secutiy, enchiam a boca para falar de algoritmos inquebráveis, ou quebráveis a um esforço tão grande que não valeria a pena, hoje sabemos que o governo amaricano possui métodos de quebrar qualquer criptografia graças a ajuda dos fabricantes que , infelizmente, majoritariamente são americanos.
Feito esse adendo, vamos voltar ao IPSec.
O IPsec, como dito acima, é um conjunto de protolos. Vou lista-los abaixo:
1: DESP - encapsulation Security Payload
2: AH - Authentication Header. Provides data integrity and authentication. Digital signature.
3: IKE : Internet Key Exchange - isakmp
Mechanism used by the Firewall for security exchange Keys.
4: DES(56 bits) and 3DES(weaker 168),AES(Stronger 128,192 and 256 bits)
Encryption mechanism
5: Diffie Hellman - Used by IKE to stablish session keys
6: MD5 and SHA - Hash algoritmum
Transforme set for authentitcation
7: SA - Security Association
Connection between two IPsec Tunnels.
Compreender cryptografia é algo que exige um pouco de estudo. Ninguem precisa compreender como funciona cada protocolo acima para fechar uma VPN, mas certamente quanto mais se sabe sobre eles mas compreenção de todo o processo você terá. Isso pode ajudar muito em troubleshooting the alta complexidade.
Por hora vamos ficar apenas com as informações acima.
Para estabelecer uma VPN precisamos definir cinco fases:
1: Trafico de Interesse
2: phase 1 parameters ( isakmp)
3: phase 2 parameters (IPsec)
4:Data Transfer
5:IPsec Tunnel
A definição do Tráfico de interesse se dá através de uma ACL como essa abaixo:
access-list ASA1-to-ASA2 line 1 extended permit ip 172.16.100.0 255.255.255.0 172.16.200.0 255.255.255.0
access-list ASA1-to-ASA2 line 2 extended permit ip 172.16.100.0 255.255.255.0 172.16.0.0 255.255.255.0
Em um Firewall onde muitas VPNs são fechadas, é interessante nomear essas ACLs mensionando o nome do cliente ou localidade. Isso facilita muito na organização e no troubleshooting.
Vamos criar também, um rota para o nosso Firewall. De acordo com nossa topologia, o ASA1 possui apenas uma conexão com o restante da rede que é através da interface outside.
Sendo assim, ele pode ter uma rota default como abaixo:
route outside 0.0.0.0 0.0.0.0 10.0.0.2
Sendo o IP 10.0.0.2 o IP da Interface do Firewall ASA2.
Também vou definir que não há necessidade de NAT. Vou criar um NAT Exempt:
Novamente precisamos definir uma ACL:
access-list No_NAT line 1 extended permit ip 172.16.100.0 255.255.255.0 172.16.200.0 255.255.255.0
access-list No_NAT line 2 extended permit ip 172.16.100.0 255.255.255.0 172.16.0.0 255.255.255.0
Nossa ACL possui duas linhas porque temos duas redes no destino e não quero fazer NAT para nenhuma delas.
Definida a ACL, podemos configurar o NAT propriamente dito:
nat (inside) 0 access-list No_NAT
Definido nosso trafico de interesse, rota e NAT, vamos aos parâmetros de VPN propriamente dito e vamos para o ítem 2 mensionado acima:
2: phase 1 parameters ( isakmp)
Os comandos para Fase 1 são:
isakmp policy "Numero entre 1 e 65535". Vou usar o número 10.
authentication pre-shared
encryption aes
hash sha
group 2
lifetime 36000
É importante ressaltar que esses parâmetros devem ser os mesmos para os dois Firewalls e não precisam ser esses definidos acima.
Em cada um deles, é possível escolher entre várias opções.
De nada adianta criar uma policy se não aplicarmos ela em algum lugar. No nosso caso, vamos aplicar na interface outside porque será onde fechará a VPN:
isakmp enable outside
Como último passo da nossa Fase 1, vamos definir que a identificação será feita por um IP Address:
isakmp identify address
Podemos passar para o passo 3:
3: phase 2 parameters (IPsec)
tunnel-group 10.0.0.2 type ipsec-l2l
tunnel-group 10.0.0.2 ipsec-attributes
pre-shared-key "chave"
O IP definido acima é o IP da interface do outro Firewall. A chave pode ser definida qualquer uma desde que seja idêntica nas duas pontas.
Vamos definir agora alguns parametros importantes de Fase 2, tal qual como em Fase 1, é preciso que os dois Firewalls tenham os mesmos parametros:
crypto ipsec transform-set "nome" esp-aes-192 esp-sha-hmac
crypto ipsec transform-set "nome" esp-aes-192 esp-sha-hmac
crypto map "nome" "sequencia" match address "ACL"
crypto map "nome" "sequencia" set peer "IP do outro Firewall"
crypto map "nome" "sequencia" set transform-set "nome"
crypto map "nome" "sequencia" set security-association lifetime seconds 36000
crypto map "nome" interface outside
Acima, estou mostrando como pode ser e abaixo vou mostrar como eu configurei:
crypto ipsec transform-set ASA1T esp-aes-192 esp-sha-hmac
crypto map ASA1VPN 10 match address ASA1-to-ASA2
crypto map ASA1VPN 10 set peer 10.0.0.2
crypto map ASA1VPN 10 set transform-set ASA1T
crypto map ASA1VPN 10 set security-association lifetime seconds 36000
crypto map ASA1VPN interface outside
Sendo assim, estão configurados todos os parâmetros pertinentes a uma VPN básica. Uma VPN pode ser muito mais complexa, mas as configurações acima é suficiente para configurar um Túnel VPN entre duas localidades.
Um detalhe muito importante no fechamento do túnel é que ele apenas irá se estabelecer quando for gerado tráfico em uma das pontas. Um simples ping é suficiente.
Após o ping, que deverá ser bem sucedido se todas as configurações foram feitas de forma correta, dois comandos importantes são úteis para verificar Fase 1 e Fase 2, como segue:
show crypto isakmp sa e show crypto ipsec sa peer "IP".
Abaixo, o comando executado no firewall:
ASA1(config)# sh crypto isakmp sa
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: 10.0.0.2
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
ASA1(config)#
==================================================
ASA1(config)# sh crypto ipsec sa peer 10.0.0.2
peer address: 10.0.0.2
Crypto map tag: ASA1VPN, seq num: 10, local addr: 10.0.0.1
access-list ASA1-to-ASA2 permit ip 172.16.100.0 255.255.255.0 172.16.200.0 255.255.255.0
local ident (addr/mask/prot/port): (172.16.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (172.16.200.0/255.255.255.0/0/0)
current_peer: 10.0.0.2
#pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3
#pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 3, #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.: 10.0.0.1, remote crypto endpt.: 10.0.0.2
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: FD69A057
inbound esp sas:
spi: 0x431477B0 (1125414832)
transform: esp-aes-192 esp-sha-hmac none
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 8192, crypto-map: ASA1VPN
sa timing: remaining key lifetime (kB/sec): (3824999/35976)
IV size: 16 bytes
replay detection support: Y
outbound esp sas:
spi: 0xFD69A057 (4251557975)
transform: esp-aes-192 esp-sha-hmac none
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 8192, crypto-map: ASA1VPN
sa timing: remaining key lifetime (kB/sec): (3824999/35976)
IV size: 16 bytes
replay detection support: Y
ASA1(config)#
Destaquei acima em vermelho duas informações importantes de serem observadas. No primeiro caso, MM_ACTIVE mostra que temos Fase 1 fechada com sucesso. Existem outros status para esse parâmetro, principalmente quando a VPN estiver enfrentando algum problema.
No segundo comando, a parte em destaque mostra os pacotes Encriptados e Decriptados. É muito importante observar algum valor nos dois campos. Um deles com zero significa problemas.
Abaixo vou repetir o comanado:
ASA1(config)# sh crypto ipsec sa peer 10.0.0.2
peer address: 10.0.0.2
Crypto map tag: ASA1VPN, seq num: 10, local addr: 10.0.0.1
access-list ASA1-to-ASA2 permit ip 172.16.100.0 255.255.255.0 172.16.200.0 255.255.255.0
local ident (addr/mask/prot/port): (172.16.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (172.16.200.0/255.255.255.0/0/0)
current_peer: 10.0.0.2
#pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3
#pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 3, #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.: 10.0.0.1, remote crypto endpt.: 10.0.0.2
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: FD69A057
inbound esp sas:
spi: 0x431477B0 (1125414832)
transform: esp-aes-192 esp-sha-hmac none
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 8192, crypto-map: ASA1VPN
sa timing: remaining key lifetime (kB/sec): (3824999/35899)
IV size: 16 bytes
replay detection support: Y
outbound esp sas:
spi: 0xFD69A057 (4251557975)
transform: esp-aes-192 esp-sha-hmac none
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 8192, crypto-map: ASA1VPN
sa timing: remaining key lifetime (kB/sec): (3824999/35899)
IV size: 16 bytes
replay detection support: Y
Crypto map tag: ASA1VPN, seq num: 10, local addr: 10.0.0.1
access-list ASA1-to-ASA2 permit ip 172.16.100.0 255.255.255.0 172.16.0.0 255.255.255.0
local ident (addr/mask/prot/port): (172.16.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (172.16.0.0/255.255.255.0/0/0)
current_peer: 10.0.0.2
#pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
#pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 2, #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.: 10.0.0.1, remote crypto endpt.: 10.0.0.2
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: 40558284
inbound esp sas:
spi: 0x37BC1942 (935074114)
transform: esp-aes-192 esp-sha-hmac none
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 8192, crypto-map: ASA1VPN
sa timing: remaining key lifetime (kB/sec): (3824999/35998)
IV size: 16 bytes
replay detection support: Y
outbound esp sas:
spi: 0x40558284 (1079345796)
transform: esp-aes-192 esp-sha-hmac none
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 8192, crypto-map: ASA1VPN
sa timing: remaining key lifetime (kB/sec): (3824999/35998)
IV size: 16 bytes
replay detection support: Y
ASA1(config)#
Percebam que a saída do comando ficou mais extensa. Isso se deu porque eu realizei, a partir do servidor, um ping para uma outra rede.
Repare que os fluxos são separados para serem mostrados. Isso é importante de ser observado. Muitas vezes a VPN está ok para um fluxo e não para outro. Uma causa comum desse problema é a criação de ACLs diferentes na definição do tráfico de interesse. Os endereços e máscaras tem que ser idênticos.
Assim concluímos esse post sobre VPN Site-to-Site. Como já dito na introdução desse post, esse tipo de rede é de extrema importância para muitas empresas porque permite a interligação de forma segura de localidades remotas usando como meio a Internet. Isso permite que empresas compartilhem recursos ou criem filiais remotas sem a necessidade da contratação de um serviço em núvem. A rededução de custo pode ser absurda. Obviamente que a performance não é a mesma de uma núvem dedicada mas eu conheço exemplos de empresas com quantidades muito grandes de "Peers" e rodando serviços como Dominio, Acesso Web,Voz,etc.
Certamente vale muito a pena dominar essa tecnologia.
Sunday, September 8, 2013
Border Gateway Protocol - BGP
A nível de CCNA nós estudamos protocolos importantes e muito interessantes como OSPF,RIP,EIGRP e Frame-relay. Porem, já é hora de avançarmos em nosso conhecimento e pensar em termos de CCNP.
A nível de CCNP nós temos um protocolo chamado BGP que, se não for o protocolo mais importante quando se trata de Internet, é certamente um dos mais importantes.
BGP é conhecido como o protocolo da Internet porque toda a Internet está organizada em Sistemas Autonomos e esses Sistemas Autonomos se comunicam usando esse protocolo.
Mesmo que como profissional de TI voce não trabalhe em um provedor de Internet, é muito provável que você ainda terá contato com o BGP de alguma forma.
É muito comum empresas privadas de maior porte terem um AS (Autonomous System) sob sua responsabilidade e interagir, usando BGP, com os ASs de Provedores de Internet.
Em geral, usa-se um protocolo IGP como o OSPF para realizar a divulgação das rotas internas para o BGP e o BGP faz a Interface com a Internet.
Se você tiver o privilégio de trabalhar em uma multinacional, é muito provável que ela tenha sua própria nuvem . Desta forma, é como se você trabalhasse em um provedor de Internet.
Em um post anterior ( "OSPF sobre Frame Relay (ERRATA)") falamos da interação entre o Frame Relay, protocolo de camada 1 e 2, com o OSPF, protocolo de camada 3. Explicamos e mostramos as nuâncias entre os dois protocolos e as formas de fazer ambos se relacionar.
Nesse Post, o objetivo é estudar sobre BGP mas teremos a chance de revisar os conceitos de Frame Relay e OSPF. Desta vez usaremos ao inves de Packet tracer, o GNS3. A instalação e utilização do GNS3 é largamente encontrado na Internet e altamente recomendado para quem pretende aprender sobre redes a um nível mais avançado.
Falando um pouco mais sobre o BGP antes de apresentar minha topologia, gostaria de fazer um pararela com outros protocolos.
Assim como o Frame Relay é um protocolo de camada 2 e o OSPF de camada 3, podemos dizer que o BGP é um protocolo de camada 4.
O BGP funciona sobre uma conexão TCP na porta 179, tal qual uma conexão de FTP, Telnet ou outros protocolos conhecidos de Redes.
Isso confere ao protocolo BGP uma característica muito peculiar. Muito diferente dos IGPs como OSPF, RIP e EIGRP que precisam estar dirertamente conectados para formar adjacências e trocar tabelas de roteamente, o BGP funciona com uma outra lógica. Isso faz dele totalmente adaptado para uma rede gigantesca e complexa como é a Internet.
Já sabemos que o OSPF é um protocolo Link State, enquanto o RIP é distance Vector e o EIGRP é Hybrid. Pois, o BGP é Path Vector.
BGP não prima pela rapidez na convergência e sim pela eficiência. Apesar de não ser nada rápido, BGP é extremamente inteligente e oferece uma gama de possibilidades jamais pensada quando falamos de IGPs.
Com a demanda cada vez maior por velocidade em conexões de redes, pode ser que num futuro próximo, outros protocolos venham tirar a hegemonia do BGP, mas por hora, ele é absoluto.
Pois bem, feita uma breve apresentação do BGP, recomendo uma leitura mais aprofundada sobre o mesmo.
Vamos expor nossa topologia:
Rodar essa topologia exige um PC como uma capacidade razoável mas nada difícil de encontra em qualquer residência nos dias de hoje. Eu uso um notebook com 4 Gigas de RAM e processador I5. Consigo trabalhar normalmente com a topologia e várias outras coisas ao mesmo tempo.
Essa topologia foi montada baseado no vídeo "Policy-Based_Routing,_Intro_to_BGP,__shaping_BGP_path_selection_with_Route-maps" que pode ser facilmente encontrado na Internet e recomento muito. Ótima didática, ótimo inglês e aborda temas de extrema importância para quem gerencia ou pretende gerenciar redes com BGP.
Nesse post, vou explicar a topologia e pretendo escrever outros posts mostrando como configurei. Mostrar tudo em um único post ficará massante.
Da esquerda para a direita temos um servidor rodando Linux microcode, parte do GNS3 como Qemu.
O router R1 foi configurado com rota estática e OSPF. Aqui ja podemos aprender sobre Redistribute de Rotas estáticas em protocolo OSPF.
O primeiro círculo seria a rede de nossa empresa e R2 o router de borda da rede. Ele faz interface com nosso provedor e por isso suporta OPSF e BGP. Aqui também o conceito de Redistribute é usado, só que entre os dois protocolos.
R5 é um Frame Relay Switch. No GNS3, como roda um IOS real, temos essa feature. Isso facilita muito a configuração de nossa núvem Layer 2, representando nosso provedor de Internet.
Vamos ver também como configurá-la.
R3 e R5 representa a Internet propriamente dita. Sao dois ASs distintos e com uma rede 10.1.0.0/32 totalmente isolada e só alcançavel através do BGP.
Por último temos um servidor que representa qualquer servidor presente na Internet.
Vamos poder mostrar aqui conceitos de configuração básica de BGP e conceitos mais complexos como route-maps, prefix-lists, local preference,aspath,path selection e outros.
Espero que o post seja informativo para todos pois eu aprendi muito configurando essa topologia.
Críticas, dúvidas e sugestões sempre são bem vindas seja na tecnoligia em si, seja na forma de expressar, seja no que for.
É possível aprender observando os outros mas só é possível evoluir corrigindo a nós mesmo.
Subscribe to:
Posts (Atom)