Capture no Cisco ASA

      E o post de hoje já faz parte do conhecimento que adquiri em meu trabalho atual. Basicamente, os firewalls em que atuamos são Cisco ASA e a função que vou apresentar aqui,apesar de simples, é de extrema importância em Troubleshooting de rede.
 Capture está para Cisco assim como TCPDUMP está para Linux, ambas as ferramentas são de extrema importância.
A poucos dias atrás eu me deparei com uma situação em que uma máquina atrás de um ASA não conseguia acessar a Web, com a ajuda do Capture, consegui evidenciar que o problema estava na máquina e não no firewall.
 O Lab que eu montei usando GNS3 é extremamente simples,porém, suficiente para nosso propósito:




A Ideia aqui é observar, através da funçao Capture, o trafego passando do host para o host .
Vamos iniciar configurando o Capture:


asa-apliance(config)# access-list  teste1 extended permit ip any host 172.16.1.2
asa-apliance(config)# access-list  teste1 extended permit ip host 172.16.1.2 any

Basicamente temos que criar duas ACLs, uma vai analisar o tráfego IN e a outra o tráfego OUT.
Criado nossa ACL, entramos com comando Capture:

 asa-apliance(config)#  capture <Nome para o Capture>   access-list < Em nosso caso teste1> interface <Nome da sua interface>

   
Como pode ser visto, meu ASA possui dois Capture cap1 e cap2:

asa-apliance# sh capture ?


  WORD  Capture name
  |     Output modifiers
  <cr>
asa-apliance# sh capture
capture cap1 type raw-data access-list capture-bastion trace interface wan interface lan [Capturing - 295556 bytes]
capture cap2 type raw-data access-list capture-bastion2 trace interface wan [Capturing - 5746 bytes]

Basicamente são essas as configurações necessárias. Agora vamos começar a analisar o tráfego.

asa-apliance(config)# show capture cap1
12 packets captured
   1: 00:08:06.538225 192.168.1.2 > 172.16.1.2: icmp: echo request
   2: 00:08:06.538225 172.16.1.2 > 192.168.1.2: icmp: echo reply
   3: 00:08:07.107843 192.168.1.2 > 172.16.1.2: icmp: echo request
   4: 00:08:07.107843 172.16.1.2 > 192.168.1.2: icmp: echo reply
   5: 00:08:07.685191 192.168.1.2 > 172.16.1.2: icmp: echo request
   6: 00:08:07.685191 172.16.1.2 > 192.168.1.2: icmp: echo reply
   7: 00:08:08.238619 192.168.1.2 > 172.16.1.2: icmp: echo request
   8: 00:08:08.238619 172.16.1.2 > 192.168.1.2: icmp: echo reply
   9: 00:08:08.797367 192.168.1.2 > 172.16.1.2: icmp: echo request
  10: 00:08:08.797367 172.16.1.2 > 192.168.1.2: icmp: echo reply
  11: 00:08:09.357769 192.168.1.2 > 172.16.1.2: icmp: echo request
  12: 00:08:09.357769 172.16.1.2 > 192.168.1.2: icmp: echo reply


Aqui temos o Cap1 capturando pacotes ICMP vindos do PC 192.168.1.2 e indo para o PC 172.16.1.2. Como podemos ver, tudo está funcionado perfeitamente.

No exemplo abaixo, temos o Cap2, no sentido contrário do tráfego. Ou seja, Origem 172.16.1.2 e destino 192.168.1.2.

asa-apliance(config)# show capture cap2
6 packets captured
   1: 00:10:50.220188 172.16.1.2 > 192.168.1.2: icmp: echo request
   2: 00:10:50.220188 192.168.1.2 > 172.16.1.2: icmp: echo reply
   3: 00:10:50.778875 172.16.1.2 > 192.168.1.2: icmp: echo request
   4: 00:10:50.778875 192.168.1.2 > 172.16.1.2: icmp: echo reply
   5: 00:10:51.346661 172.16.1.2 > 192.168.1.2: icmp: echo request
   6: 00:10:51.346661 192.168.1.2 > 172.16.1.2: icmp: echo reply


Vamos testar uma conexão onde ocorrerá falha para vermos como se comporta:

Do lado Wan de nossa rede, vamos tentar acessar o servidor que está dentro da rede:

root@server_wan:~# telnet 172.16.1.2
telnet: can't connect to remote host (172.16.1.2): No route to host
root@server_wan:~#

Vejamos o que o Capture pegou:
asa-apliance(config)# show capture cap1
 3 packets captured
   1: 00:15:31.773260 192.168.1.2.33522 > 172.16.1.2.23: S 723235514:723235514(0) win 5840 <mss 1460,sackOK,timestamp 420198 0,nop,wscale 4>
   2: 00:15:33.452887 192.168.1.2.33522 > 172.16.1.2.23: S 723235514:723235514(0) win 5840 <mss 1460,sackOK,timestamp 421104 0,nop,wscale 4>
   3: 00:15:33.472723 192.168.1.2.33522 > 172.16.1.2.23: S 723235514:723235514(0) win 5840 <mss 1460,sackOK,timestamp 421109 0,nop,wscale 4>
3 packets shown


Como podemos ver, ocorreu apenas o envio de pacotes. Uma analise mais detalhada poderá ajudar na busca de uma solução.
   Basicamente essa é a função do Capture. Ferramenta muito importante tendo em vista que a função do firewall é realmente de bloqueio de tráfego. Dessa forma, qualquer desconfiança sobre um provável bloqueio indesejado, é preciso analisar o tráfego para ver se está ocorrendo de fato um bloqueio no firewall.
    Espero que seja útil a outros como tem sido pra min.