%20e%20106100%20(Permitir)%20para%20o%20mesmo%20pacote.png)
Estou vendo tráfego de vários endpoints internos onde um RST ou FIN/ACK é enviado pelo endpoint para um host na Internet. Essas conexões estão relacionadas a um proxy transparente que não as trata adequadamente. Em vez de tratá-los, simplesmente os encaminha para a ASA. A ASA nunca observou estas conexões antes.
O ASA (8.2) vê este tráfego e gera um evento 106015 (sem conexão) e nega o tráfego. Isto é precisamente o que espero. Contudo, o ASA também registrará um evento 106100 que indica que o tráfego é permitido. Existe um ACE que afirma "permitir ip qualquer log".
Com base nas capturas de tráfego, foi confirmado que o tráfego foi negado e não permitido.
Por que o evento 106100 está acontecendo então? Isso nos deixa completamente confusos, pois parece que o ASA permitiu o tráfego, quando na verdade não o permitiu. Se o ASA descartar o tráfego devido à falta de conexão existente, por que ele chegaria perto das ACLs e muito menos geraria um log de permissão?
Aqui estão os registros nas perguntas:
: %ASA-6-106015: Deny TCP (no connection) from 10.x.x.x/62938 to 216.x.x.x/80 flags FIN ACK on interface inside
: %ASA-6-106100: access-list inside permitted tcp inside/10.x.x.x(62938) -> outside/216.x.x.x(80) hit-cnt 1 first hit [0x62c4905, 0x0]
Os carimbos de data e hora dos dois eventos são idênticos.
Qualquer conselho seria apreciado, obrigado.
Editar: Esclarecimento
De acordo com este artigo da Cisco sobre fluxo de pacotes.
http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html
"Se o fluxo de pacotes não corresponder a uma conexão existente, o estado do TCP será verificado. Se for um pacote SYN ou UDP, o contador de conexão será incrementado em um e o pacote será enviado para uma verificação de ACL. Se não for um pacote SYN, o pacote é descartado e o evento é registrado."
Com base nesse comportamento descrito, ainda não tenho certeza do motivo pelo qual estou vendo o log 106100 indicando que o tráfego é permitido.
Responder1
A ACL está sendo avaliada antes do rastreamento de conexão e da avaliação NAT (verifique a saída da packet-tracersimulação desse tráfego) e, como o tráfego atinge essa regra, ele registra conforme você instruiu no permit ip any any log.
Responder2
Este é o comportamento esperado:
Quando uma linha da lista de acesso tem o argumento de log, espera-se que esta ID de mensagem possa ser acionada devido a um pacote não sincronizado que alcança o ASA e é avaliado pela lista de acesso. Por exemplo, se um pacote ACK for recebido no ASA (para o qual não existe nenhuma conexão TCP na tabela de conexões), o ASA poderá gerar a mensagem 106100, indicando que o pacote foi permitido; no entanto, o pacote é posteriormente descartado corretamente devido a nenhuma conexão correspondente.