%20y%20106100%20(permitir)%20para%20el%20mismo%20paquete.png)
Veo tráfico desde numerosos puntos finales internos donde el punto final envía un RST o FIN/ACK a un host en Internet. Estas conexiones están relacionadas con un proxy transparente que no las maneja adecuadamente. En lugar de ocuparse de ellos, simplemente los envía a la ASA. La ASA nunca antes había observado estas conexiones.
El ASA (8.2) ve este tráfico, genera un evento 106015 (sin conexión) y niega el tráfico. Esto es precisamente lo que espero. Sin embargo, el ASA también registrará un evento 106100 que indica que el tráfico está permitido. Hay una ACE que dice "permitir ip cualquier registro".
Según las capturas de tráfico, se confirmó que el tráfico estaba denegado y no permitido.
¿Por qué ocurre entonces el evento 106100? Nos ha desconcertado por completo, ya que parece que el ASA ha permitido el tráfico cuando en realidad no lo ha hecho. Si el ASA interrumpe el tráfico debido a la falta de conexión existente, ¿por qué se acercaría a las ACL y mucho menos generaría un registro de permisos?
Aquí están los registros de preguntas:
: %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]
Las marcas de tiempo de los dos eventos son idénticas.
Cualquier consejo sería apreciado, gracias.
Editar: Aclaración
Según este artículo de Cisco sobre flujo de paquetes.
http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html
"Si el flujo de paquetes no coincide con una conexión existente, entonces se verifica el estado de TCP. Si es un paquete SYN o un paquete UDP, entonces el contador de conexión se incrementa en uno y el paquete se envía para una verificación de ACL. Si no es una paquete SYN, el paquete se descarta y se registra el evento".
Según este comportamiento descrito, todavía no estoy seguro de por qué veo el registro 106100 que indica que el tráfico está permitido.
Respuesta1
La ACL se evalúa antes del seguimiento de la conexión y la evaluación de NAT (verifique el resultado de packet-tracerla simulación de este tráfico) y, debido a que el tráfico alcanza esa regla, se registra como usted le indicó en permit ip any any log.
Respuesta2
Este es el comportamiento esperado:
Cuando una línea de la lista de acceso tiene el argumento de registro, se espera que esta ID de mensaje se active debido a que un paquete no sincronizado llega al ASA y es evaluado por la lista de acceso. Por ejemplo, si se recibe un paquete ACK en el ASA (para el cual no existe ninguna conexión TCP en la tabla de conexiones), el ASA podría generar el mensaje 106100, indicando que el paquete estaba permitido; sin embargo, el paquete se descarta correctamente debido a que no hay una conexión coincidente.