1 votes

Cisco ASA 8.2 - Journaux 106015 (Deny) et 106100 (Permit) pour le même paquet

Je vois du trafic provenant de nombreux points d'extrémité internes où un RST ou un FIN/ACK est envoyé par le point d'extrémité à un hôte sur Internet. Ces connexions sont liées à un proxy transparent qui ne les gère pas correctement. Au lieu de les traiter, il les transmet simplement à l'ASA. L'ASA n'a jamais observé ces connexions auparavant.

L'ASA (8.2) voit ce trafic et génère un événement 106015 (pas de connexion) et refuse le trafic. C'est exactement ce que j'attends. Cependant, l'ASA enregistre également un événement 106100 qui indique que le trafic est autorisé. Il y a un ACE qui dit "permit ip any any log".

Sur la base des captures de trafic, il a été confirmé que le trafic était refusé et non autorisé.

Pourquoi l'événement 106100 a-t-il lieu alors ? Nous avons été complètement déstabilisés car il semble que l'ASA ait autorisé le trafic alors que ce n'est pas le cas. Si l'ASA laisse tomber le trafic en raison de l'absence de connexion existante, pourquoi s'approcherait-il des ACL, et encore moins générer un journal d'autorisation ?

Voici les registres en question :

: %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]

Les horodatages des deux événements sont identiques.

Tout conseil serait apprécié, merci.

Edit : Clarification
Selon cet article de Cisco sur le flux de paquets. http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html

"Si le flux de paquets ne correspond pas à une connexion existante, l'état du TCP est vérifié. S'il s'agit d'un paquet SYN ou UDP, le compteur de connexions est incrémenté d'une unité et le paquet est envoyé pour une vérification ACL. S'il ne s'agit pas d'un paquet SYN, le paquet est abandonné et l'événement est consigné."

Sur la base de ce comportement décrit, je ne sais toujours pas pourquoi je vois le journal 106100 indiquant que le trafic est autorisé.

1voto

Shane Madden Points 112034

L'ACL est évaluée avant le suivi des connexions et l'évaluation de la NAT (vérifiez la sortie de packet-tracer simulant ce trafic), et parce que le trafic atteint cette règle, il s'enregistre comme vous l'avez demandé dans la section permit ip any any log .

0voto

Peter Housen Points 1

C'est un comportement attendu :

https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog/syslog-messages-101001-to-199021.html

Lorsqu'une ligne de liste d'accès a l'argument log, on s'attend à ce que cet ID de message soit déclenché à cause d'un paquet non synchronisé atteignant l'ASA et évalué par la liste d'accès. Par exemple, si un paquet ACK est reçu sur l'ASA (pour lequel aucune connexion TCP n'existe dans la table des connexions), l'ASA peut générer le message 106100, indiquant que le paquet a été autorisé ; cependant, le paquet est plus tard correctement abandonné en raison de l'absence de connexion correspondante.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X