1

I'm seeing traffic from numerous internal endpoints where a RST or FIN/ACK is sent by the endpoint to a host on the Internet. These connections are related with a transparent proxy that is not handling these properly. Instead of dealing with them, it simply forwards them to the ASA. The ASA has never observed these connections before.

The ASA (8.2) sees this traffic and generates a 106015 event (no connection) and denies the traffic. This is precisely what I expect. However, the ASA will also log a 106100 event that states the traffic is permitted. There is an ACE that states "permit ip any any log".

Based on traffic captures, it was confirmed that the traffic was denied and not permitted.

Why is the 106100 event happening then? It's completely thrown us for a loop as it appears that the ASA has allowed traffic when in fact it has not. If the ASA drops the traffic due to lack of existing connection, why would it go anywhere near the ACLs, much less generate a permit log?

Here are the logs in questions:

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

Timestamps of the two events are identical.

Any advice would be appreciated, thanks.

Edit: Clarification
According to this Cisco article on packet flow. http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html

"If packet flow does not match an existing connection, then TCP state is verified. If it is a SYN packet or UDP packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged."

Based on this described behavior, I'm still unsure as to why I'm seeing the 106100 log indicating the traffic is permitted.

Sgt B
  • 123
  • 1
  • 5

2 Answers2

1

The ACL is being evaluated before the connection tracking and NAT evaluation (check the output of packet-tracer simulating this traffic), and because the traffic hits that rule, it logs as you've instructed it to in permit ip any any log.

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • That's the opposite of how I thought it worked. I thought it would check the packet against existing connections prior to applying it to its ACLs as it would be quite a bit faster than applying every packet to the ACL. I'll certainly see how things look with packet tracer though. Thanks for the response. – Sgt B May 13 '14 at 19:58
  • 1
    @SgtB Check out `packet-tracer` with appropriate fake traffic to see exactly what it's evaluating and in what order. – Shane Madden May 13 '14 at 19:59
  • Will do, thanks Shane. It'll take some doing as I don't have access to the ASA, but it'll certainly help. Thanks – Sgt B May 13 '14 at 20:11
  • Actually how would I use packet-tracer to inject and trace RST or FIN/ACK packets? This behavior only occurs when a RST or FIN/ACK packet is observed that is not associated with an existing connection. – Sgt B May 13 '14 at 20:21
  • 1
    @SgtB I don't think you can, but you can see the order in which the processing occurs. – Shane Madden May 13 '14 at 20:33
  • Got it, I'll have a look then. – Sgt B May 13 '14 at 20:36
0

This is expected behaviour:

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

When an access-list line has the log argument, it is expected that this message ID might be triggered because of a nonsynchronized packet reaching the ASA and being evaluated by the access list. For example, if an ACK packet is received on the ASA (for which no TCP connection exists in the connection table), the ASA might generate message 106100, indicating that the packet was permitted; however, the packet is later correctly dropped because of no matching connection.

Peter Housen
  • 1