Segurança : Dispositivos de segurança adaptáveis Cisco ASA 5500 Series

Troubleshooting de Conexões via PIX e ASA

8 Junho 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (1 Setembro 2011) | Feedback

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Produtos Relacionados
      Convenções
Informações de Apoio
Problema
Solução
      Passo 1 - Descoberta do Endereço IP do Usuário
      Passo 2 - Identificação da Causa do Problema
      Passo 3 - Confirmação e Monitoração do Tráfego do Aplicativo
      Próximos Passos
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Este documento apresenta idéias e sugestões de troubleshooting quando o Cisco ASA 5500 Series Adaptive Security Appliance (ASA) e o Cisco PIX 500 Series Security Appliance são usados. Com freqüência, quando aplicativos ou recursos de rede param de funcionar ou se tornam indisponíveis, os firewalls (PIX ou ASA) tendem a ser o alvo principal e são apontados como a causa das interrupções. Ao realizar alguns testes no ASA ou PIX, um administrador pode determinar se o ASA/PIX causou ou não o problema.

Consulte PIX/ASA: Estabelecimento e Troubleshooting de Conectividade com o Cisco Security Appliance para saber mais sobre o troubleshooting relacionado a interfaces nos Cisco Security Appliances.

Nota: Este documento concentra-se no ASA e no PIX. Após a conclusão do troubleshooting no ASA ou PIX, é provável que troubleshooting adicional seja necessário em outros dispositivos (roteadores, switches, servidores e assim por diante).

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas no Cisco ASA 5510 com OS 7.2.1.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração padrão. Se a sua rede estiver em um ambiente de produção, esteja ciente do impacto potencial de qualquer comando.

Produtos Relacionados

Este documento também pode ser utilizado com estas versões de hardware e software:

  • PIX OS 6.3

  • ASA e PIX OS 7.0 e 7.1

  • Firewall Services Module (FWSM) 2.2, 2.3 e 3.1

Nota: Comandos e sintaxes específicos podem variar de acordo com a versão do software.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Informações de Apoio

O exemplo supõe que o ASA ou PIX esteja em um ambiente de produção. A configuração do ASA/PIX pode ser relativamente simples (somente 50 linhas de configuração) ou complexa (de centenas a milhares de linhas de configuração). Os usuários (clientes) ou servidores podem estar em uma rede segura (interna) ou insegura (DMZ ou externa).

asa-pix-troubleshooting-1.gif

O ASA começa com esta configuração. A configuração destina-se a fornecer um ponto de referência ao laboratório.

Configuração Inicial do ASA

ciscoasa#show running-config
: Saved
:
ASA Version 7.2(1)
!
hostname ciscoasa
enable password 8Ry2YjIyt7RRXU24 encrypted
names
!
interface Ethernet0/0
 nameif outside
 security-level 0
 ip address 172.22.1.160 255.255.255.0
!
interface Ethernet0/1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0
!
interface Ethernet0/2
 nameif dmz
 security-level 50
 ip address 10.1.1.1 255.255.255.0
!
interface Management0/0
 shutdown
 no nameif
 no security-level
 no ip address
!
passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
access-list outside_acl extended permit tcp any host 172.22.1.254 eq www
access-list inside_acl extended permit icmp 192.168.1.0 255.255.255.0 any
access-list inside_acl extended permit tcp 192.168.1.0 255.255.255.0 any eq www
access-list inside_acl extended permit tcp 192.168.1.0 255.255.255.0 any eq telnet
pager lines 24
mtu outside 1500
mtu inside 1500
mtu dmz 1500
no asdm history enable
arp timeout 14400
global (outside) 1 172.22.1.253
nat (inside) 1 192.168.1.0 255.255.255.0
static (inside,outside) 192.168.1.100 172.22.1.254 netmask 255.255.255.255
access-group outside_acl in interface outside
access-group inside_acl in interface inside
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout uauth 0:05:00 absolute
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
telnet timeout 5
ssh timeout 5
console timeout 0
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip
  inspect xdmcp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:d41d8cd98f00b204e9800998ecf8427e
: end

Problema

Um usuário entra em contato com o departamento de TI para informar que o aplicativo X não funciona mais. O incidente é levado para o administrador do ASA/PIX. O administrador conhece muito pouco esse aplicativo específico. Ao usar o ASA/PIX, o administrador descobre as portas e os protocolos usados pelo aplicativo X e também o que poderia estar causando o problema.

Solução

O administrador do ASA/PIX precisa obter o máximo de informações possível do usuário. As informações úteis incluem:

  • Endereço IP de origem — Normalmente, a estação de trabalho ou o computador do usuário.

  • Endereço IP de destino — O endereço IP do servidor ao qual o usuário ou aplicativo tenta se conectar.

  • Portas e protocolos usados pelo aplicativo.

Muitas vezes, o administrador tem sorte se consegue obter uma resposta para uma dessas perguntas. No nosso exemplo, ele não é capaz de obter informação alguma. Uma revisão das mensagens de Syslog do ASA/PIX é ideal, mas é difícil identificar o problema se o administrador não sabe o que procurar.

Passo 1 - Descoberta do Endereço IP do Usuário

Há muitas formas de identificar o endereço IP do usuário. Este documento é sobre o ASA e o PIX. Assim, este exemplo usa o ASA e o PIX para descobrir o endereço.

O usuário tenta se comunicar com o ASA/PIX. Essa comunicação pode ser feita via ICMP, Telnet, SSH ou HTTP. O protocolo escolhido deve ter atividade limitada sobre o ASA/PIX. Nesse exemplo específico, o usuário envia um ping para a interface interna do ASA.

O administrador precisa configurar uma ou mais destas opções e, em seguida, deve pedir ao usuário para enviar um ping para a interface interna do ASA.

  • Syslog

    Certifique-se de que o log esteja habilitado. O nível do log deve ser definido como debug. O log pode ser enviado para vários locais. Este exemplo usa o buffer de log do ASA. Em ambientes de produção, um servidor de log externo pode ser necessário.

    ciscoasa(config)#logging enable
    ciscoasa(config)#logging buffered debugging
    

    O usuário envia um ping para a interface interna do ASA (ping 192.168.1.1). A saída é exibida.

    ciscoasa#show logging
    
    !--- Saída suprimida.
    
    %ASA-6-302020: Built ICMP connection for faddr 192.168.1.50/512
    gaddr 192.168.1.1/0 laddr 192.168.1.1/0
    %ASA-6-302021: Teardown ICMP connection for faddr 192.168.1.50/512
    gaddr 192.168.1.1/0 laddr 192.168.1.1/0
    
    !--- O endereço IP do usuário é 192.168.1.50.
    
    
  • Recurso de Captura do ASA

    O administrador precisa criar uma lista de acesso que defina o tráfego que o ASA deverá capturar. Após a definição da lista de acesso, o comando capture incorpora a lista de acesso e a aplica a uma interface.

    ciscoasa(config)#access-list inside_test permit icmp any host 192.168.1.1
    ciscoasa(config)#capture inside_interface access-list inside_test interface inside
    

    O usuário envia um ping para a interface interna do ASA (ping 192.168.1.1). A saída é exibida.

    ciscoasa#show capture inside_interface
       1: 13:04:06.284897 192.168.1.50 > 192.168.1.1: icmp: echo request
    
    !--- O endereço IP do usuário é 192.168.1.50.
    
    

    Nota: Para baixar o arquivo de captura para um sistema como o ethereal, você pode proceder conforme mostrado nesta saída.

    
    !--- Abra um Internet Explorer e navegue com este formato de link HTTPS:
    
    https://[<pix_ip>/<asa_ip>]/capture/<capture name>/pcap
    
  • Debug

    O comando debug icmp trace é usado para capturar o tráfego ICMP do usuário.

    ciscoasa#debug icmp trace
    

    O usuário envia um ping para a interface interna do ASA (ping 192.168.1.1). Esta saída é exibida no console.

    ciscoasa#
    
    !--- Saída suprimida.
    
    ICMP echo request from 192.168.1.50 to 192.168.1.1 ID=512 seq=5120 len=32
    ICMP echo reply from 192.168.1.1 to 192.168.1.50 ID=512 seq=5120 len=32
    
    !--- O endereço IP do usuário é 192.168.1.50.
    
    

    Para desabilitar o debug icmp trace, use um destes comandos:

    • no debug icmp trace

    • undebug icmp trace

    • undebug all, Undebug all ou un all

Cada uma dessas três opções ajuda o administrador a determinar o endereço IP de origem. Neste exemplo, o endereço IP de origem do usuário é 192.168.1.50. O administrador está pronto para aprender mais sobre o aplicativo X e determinar a causa do problema.

Passo 2 - Identificação da Causa do Problema

Ao consultar as informações listadas na seção Passo 1 deste documento, o administrador agora conhece a origem de uma sessão do aplicativo X. Ele está pronto para aprender mais sobre o aplicativo X e começar a localizar a origem dos problemas.

O administrador do ASA/PIX precisa preparar o ASA para pelo menos uma das sugestões aqui relacionadas. Quando o administrador estiver pronto, o usuário deverá iniciar o aplicativo X e limitar todas as demais atividades, já que atividades de usuário adicionais poderiam causar confusão ou enganar o administrador do ASA/PIX.

  • Monitoração das mensagens do Syslog.

    Procure o endereço IP de origem do usuário que você identificou no Passo 1. O usuário inicia o aplicativo X. O administrador do ASA executa o comando show logging e exibe a saída.

    ciscoasa#show logging
    
    !--- Saída suprimida.
    
    %ASA-7-609001: Built local-host inside:192.168.1.50
    %ASA-6-305011: Built dynamic TCP translation from inside:192.168.1.50/1107
    to outside:172.22.1.254/1025
    %ASA-6-302013: Built outbound TCP connection 90 for outside:172.22.1.1/80
    (172.22.1.1/80) to inside:192.168.1.50/1107 (172.22.1.254/1025)

    Os logs revelam que o endereço IP de destino é 172.22.1.1, o protocolo é o TCP, a porta de destino é HTTP/80 e o tráfego é enviado para a interface externa.

  • Modificação dos filtros de captura.

    O comando access-list inside_test foi usado anteriormente e é usado aqui.

    ciscoasa(config)#access-list inside_test permit ip host 192.168.1.50 any
    
    !--- Esta linha da ACL captura todo o tráfego de 192.168.1.50
    !--- que vai para ou passa pelo ASA.
    
    ciscoasa(config)#access-list inside_test permit ip any host 192.168.1.50 any
    
    !--- Esta linha da ACL captura todo o tráfego que sai
    !--- do ASA e vai para 192.168.1.50.
    
    ciscoasa(config)#no access-list inside_test permit icmp any host 192.168.1.1
    ciscoasa(config)#clear capture inside_interface
    
    !--- Limpa os dados registrados anteriormente.
    !--- O parâmetro no capture inside_interface remove/exclui a captura.
    
    

    O usuário inicia o aplicativo X. O administrador do ASA então executa o comando show capture inside_interface e exibe a saída.

    ciscoasa(config)#show capture inside_interface
    1: 15:59:42.749152 192.168.1.50.1107 > 172.22.1.1.80:
    S 3820777746:3820777746(0) win 65535 <mss 1460,nop,nop,sackOK>
    2: 15:59:45.659145 192.168.1.50.1107 > 172.22.1.1.80:
    S 3820777746:3820777746(0) win 65535 <mss 1460,nop,nop,sackOK>
    3: 15:59:51.668742 192.168.1.50.1107 > 172.22.1.1.80:
    S 3820777746:3820777746(0) win 65535 <mss 1460,nop,nop,sackOK>

    O tráfego capturado fornece ao administrador várias informações valiosas:

    • Endereço de destino — 172.22.1.1

    • Número da porta — 80/http

    • Protocolo — TCP (observe o "S" ou sinalizador syn)

    Além disso, o administrador também descobre que o tráfego de dados do aplicativo X chega até o ASA.

    Se a saída foi esta saída do comando show capture inside_interface, o tráfego do aplicativo nunca chegou ao ASA ou o filtro de captura não foi configurado para capturá-lo:

    ciscoasa#show capture inside_interface
    0 packet captured
    0 packet shown

    Nesse caso, o administrador deve considerar investigar o computador do usuário e qualquer roteador ou dispositivo de rede no caminho entre esse computador e o ASA.

    Nota: Quando o tráfego chega em uma interface, o comando capture registra os dados antes que qualquer política de segurança do ASA analise o tráfego. Por exemplo, uma lista de acesso nega todo o tráfego recebido em uma interface. O comando capture ainda registra o tráfego. A política de segurança do ASA então analisa o tráfego.

  • Depuração

    O administrador não está familiarizado com o aplicativo X e, assim, não sabe quais serviços de depuração habilitar para investigar o aplicativo X. Depurar pode não ser a melhor opção de troubleshooting neste ponto.

Com as informações coletadas no Passo 2, o administrador do ASA obtém vários trechos de informação valiosos. O administrador sabe que o tráfego chega na interface interna do ASA e conhece o endereço IP de origem, o endereço IP de destino e o serviço usado pelo aplicativo X (TCP/80). Dos Syslogs, o administrador também sabe que a comunicação foi inicialmente permitida.

Passo 3 - Confirmação e Monitoração do Tráfego do Aplicativo

O administrador do ASA deseja confirmar que o tráfego do aplicativo X saiu do ASA e também monitorar qualquer tráfego de retorno do servidor do aplicativo X.

  • Monitoração das mensagens do Syslog.

    Filtre as mensagens do Syslog pelo endereço IP de origem (192.168.1.50) ou pelo endereço IP de destino (172.22.1.1). Na linha de comando, a filtragem de mensagens do Syslog é semelhante a show logging | include 192.168.1.50 ou show logging | include 172.22.1.1. Neste exemplo, o comando show logging é usado sem filtros. A saída foi removida para facilitar a leitura.

    ciscoasa#show logging
    
    !--- Saída suprimida.
    
    %ASA-7-609001: Built local-host inside:192.168.1.50
    %ASA-7-609001: Built local-host outside:172.22.1.1
    %ASA-6-305011: Built dynamic TCP translation from inside:192.168.1.50/1107
    to outside:172.22.1.254/1025
    %ASA-6-302013: Built outbound TCP connection 90 for outside:172.22.1.1/80
    (172.22.1.1/80) to inside:192.168.1.50/1107 (172.22.1.254/1025)
    %ASA-6-302014: Teardown TCP connection 90 for outside:172.22.1.1/80
    to inside:192.168.1.50/1107 duration 0:00:30 bytes 0 SYN Timeout
    %ASA-7-609002: Teardown local-host outside:172.22.1.1 duration 0:00:30
    %ASA-6-305012: Teardown dynamic TCP translation from inside:192.168.1.50/1107
    to outside:172.22.1.254/1025 duration 0:01:00
    %ASA-7-609002: Teardown local-host inside:192.168.1.50 duration 0:01:00

    A mensagem do Syslog indica que a conexão foi fechada devido a um timeout de SYN. Isso informa ao administrador que nenhuma resposta do servidor do aplicativo X foi recebido pelo ASA. Os motivos do encerramento das mensagens do Syslog podem variar. Consulte Mensagens de Sistema do ASA para obter mais informações sobre as mensagens do Syslog.

  • Criação de um novo filtro de captura.

    Do tráfego capturado anteriormente e das mensagens do Syslog, o administrador sabe que o aplicativo X deve deixar o ASA pela interface externa.

    ciscoasa(config)#access-list outside_test permit tcp any host 172.22.1.1 eq 80
    
    !--- Quando a saída é mantida como 'any', o
    !--- administrador pode monitorar qualquer conversão de endereço de rede (NAT).
    
    ciscoasa(config)#access-list outside_test permit tcp host 172.22.1.1 eq 80 any
    
    !--- Quando as informações de origem e destino são invertidas,
    !--- o tráfego de retorno é capturado.
    
    ciscoasa(config)#capture outside_interface access-list outside_test interface outside
    

    O usuário precisa iniciar uma nova sessão com o aplicativo X. Após a nova sessão do aplicativo X ter sido iniciada, o administrador do ASA deve executar o comando show capture outside_interface no ASA.

    ciscoasa(config)#show capture outside_interface
    3 packets captured
       1: 16:15:34.278870 172.22.1.254.1026 > 172.22.1.1.80:
    S 1676965539:1676965539(0) win 65535 <mss 1380,nop,nop,sackOK>
       2: 16:15:44.969630 172.22.1.254.1027 > 172.22.1.1.80:
    S 990150551:990150551(0) win 65535 <mss 1380,nop,nop,sackOK>
       3: 16:15:47.898619 172.22.1.254.1027 > 172.22.1.1.80:
    S 990150551:990150551(0) win 65535 <mss 1380,nop,nop,sackOK>
    3 packets shown

    A captura mostra o tráfego saindo da interface externa, mas não mostra nenhuma resposta do servidor 172.22.1.1. Essa captura mostra os dados conforme eles saem do ASA.

  • Uso da opção packet-tracer.

    Nas seções anteriores, o administrador do ASA obteve informações suficientes para usar a opção packet-tracer no ASA.

    Nota: O ASA oferece suporte ao comando packet-tracer a partir da versão 7.2.

    ciscoasa#packet-tracer input inside tcp 192.168.1.50 1025 172.22.1.1 http
    
    !--- Esta linha indica uma porta de origem de 1025. Se a porta de origem
    !--- for desconhecida, qualquer número poderá ser usado.
    !--- As portas de origem mais comuns normalmente variam
    !--- entre 1025 e 65535.
    
    Phase: 1
    Type: CAPTURE
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    MAC Access list
    
    Phase: 2
    Type: ACCESS-LIST
    Subtype:
    Result: ALLOW
    Config:
    Implicit Rule
    Additional Information:
    MAC Access list
    
    Phase: 3
    Type: FLOW-LOOKUP
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    Found no matching flow, creating a new flow
    
    Phase: 4
    Type: ROUTE-LOOKUP
    Subtype: input
    Result: ALLOW
    Config:
    Additional Information:
    in   172.22.1.0      255.255.255.0   outside
    
    Phase: 5
    Type: ACCESS-LIST
    Subtype: log
    Result: ALLOW
    Config:
    access-group inside_acl in interface inside
    access-list inside_acl extended permit tcp 192.168.1.0 255.255.255.0 any eq www 
    Additional Information:
    
    Phase: 6
    Type: IP-OPTIONS
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    
    Phase: 7
    Type: CAPTURE
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    
    Phase: 8
    Type: NAT
    Subtype:
    Result: ALLOW
    Config:
    nat (inside) 1 192.168.1.0 255.255.255.0
      match ip inside 192.168.1.0 255.255.255.0 outside any
        dynamic translation to pool 1 (172.22.1.254)
        translate_hits = 6, untranslate_hits = 0
    Additional Information:
    Dynamic translate 192.168.1.50/1025 to 172.22.1.254/1028
    using netmask 255.255.255.255
    
    Phase: 9
    Type: NAT
    Subtype: host-limits
    Result: ALLOW
    Config:
    nat (inside) 1 192.168.1.0 255.255.255.0
      match ip inside 192.168.1.0 255.255.255.0 outside any
        dynamic translation to pool 1 (172.22.1.254)
        translate_hits = 6, untranslate_hits = 0
    Additional Information:
    
    Phase: 10
    Type: CAPTURE
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    
    Phase: 11
    Type: CAPTURE
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    
    Phase: 12
    Type: IP-OPTIONS
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    
    Phase: 13
    Type: CAPTURE
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    
    Phase: 14
    Type: FLOW-CREATION
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    New flow created with id 94, packet dispatched to next module
    
    Phase: 15
    Type: ROUTE-LOOKUP
    Subtype: output and adjacency
    Result: ALLOW
    Config:
    Additional Information:
    found next-hop 172.22.1.1 using egress ifc outside
    adjacency Active
    next-hop mac address 0030.a377.f854 hits 11
    
    !--- O endereço MAC pertence à Camada 2 do modelo OSI.
    !--- Informa ao administrador o próximo host
    !--- que deve receber o pacote de dados.
    
    
    Result:
    input-interface: inside
    input-status: up
    input-line-status: up
    output-interface: outside
    output-status: up
    output-line-status: up
    Action: allow

    A saída mais importante do comando packet-tracer é a última linha: Action: allow.

As três opções do Passo 3 mostram para o administrador que o ASA não é responsável pelos problemas do aplicativo X. O tráfego do aplicativo X deixa o ASA, mas o ASA não recebe resposta do servidor do aplicativo X.

Próximos Passos

Há vários componentes que possibilitam que o aplicativo X funcione corretamente para os usuários. Os componentes incluem o computador do usuário, o cliente do aplicativo X, roteamento, políticas de acesso e o servidor do aplicativo X. No exemplo anterior, provamos que o ASA recebe e encaminha o tráfego do aplicativo X. Os administradores do servidor e do aplicativo X devem ser envolvidos agora. Os administradores devem verificar se os serviços do aplicativo estão em execução, examinar os logs no servidor e verificar se o tráfego do usuário é recebido pelo servidor e pelo aplicativo X.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 71871