I'm in the process of locking down an ASA that been in production with wide open ACLs for years. In this case I'm locking down one of several contexts but these questions aren't context specific and would be the same if it was single context. Here's the scenario. I have done a good amount of log analysis and coordination with system owners and have created an inside-out and outside-in ACL that's permitting most of the traffic. Some traffic is slipping down to the "permit ip any any" rule that still at the end of my ACL but due to go away soon. I'm analyzing this traffic that's slipping past my rules.
I've observed a fair amount of Outside_to_Inside traffic that's destined to an inside host on destination ports which are high range TCP ephemeral ports. This traffic isn't expected or permitted by my draft ruleset. Looking closer at the traffic these flows are (as expected) replies to traffic that was initiated from the inside host using a random high source port and a well known destination port.
Digging into the ASA logs that lead up to this inbound flow that's matching permit hits on outside-in ACL it looks to me like the inbound flows (despite showing a permit on the inbound ACL) are actually denied in the end by the TCP stateful inspection behavior of the ASA. The permit is a bit of a false positive since the flow is denied "later". This assumption is based on a handful of ASA packet flow process steps/order of operation references I dug up online, one of which is attached.
I'm just looking for a few more sets of sharp eyes (folks who know ASAs) to confirm my assumptions here or let me know where I'm getting it wrong. I've attached a single reference for the ASA process steps. Additionally below I've attached a SYSLOG output (actual IPs are sanitized but I put in some replacement values that express the same thing) as well as numbered index of process steps as I interpret them. Any assistance is appreciated!
The ASA's TCP Stateful inspection permits only expected TCP Flags to flow. In the example below and unexpected TCP packet is received and dropped due to the ASA's TCP stateful inspection behavior.
This issue is effecting traffic to an SNMP Host 2.2.2.2. Traffic is always initiated from the inside host 1.1.1.1…..
====================================================================================
1.) Inside host 1.1.1.1 starts a conversation over TCP 25 (SMTP) with host 2.2.2.2. The initiating inside host sourced this flow from ephemeral port TCP 36378. The ASA evaluates this flow
against the inside-out ACL and it is permitted.
2.) The ASA places connection "2428777825" in its connection table for this flow. Return traffic will be let in statefully. The conversation goes on, traffic flows in both directions.
3.) The ASA tears down the connection from its connection table after observing a TCP RST that came from the inside host (TCP Reset-I).
4.) The inside host has already sent a TCP RST (which caused the ASA to close the connection) but now sends another TCP RST. The ASA has already dropped this connection based on the first RST so the flow doesn't match an existing connection table entry. Since no connection table entry exists the only acceptable initial TCP flow is a SYN packet. This is a RST and thus fails the test and is dropped with the log entry "ASA-6-106015: Deny TCP (no connection)".
5.) The outside host sends an ACK to the inside host's last (successful) RST. This flow is initially permitted by ACL since the ACL is wide open and since the ACL is evaluated BEFORE the TCP Stateful Inspection.
6.) This same flow makes it to the TCP stateful inspection check ("security checks") in the ASA and is dropped since it's a ACK that doesn't match and existing TCP flow. Additional packets come from the outside host FIN PSH ACK (3X) and a RST ACK. All are dropped.
7.) Successful outbound flow.
8.) Successful inbound flow.
==============================================================================================
1.) Nov 15 14:34:20 192.168.45.50 : %ASA-6-106100: access-list inside-out permitted tcp INSIDE/1.1.1.1(36378) -> OUTSIDE/2.2.2.2(25) hit-cnt 1 first hit [0x123456789, 0x0]
!
2.) Nov 15 14:34:20 192.168.45.50 : %ASA-6-302013: Built outbound TCP connection 2428777825 for OUTSIDE:2.2.2.2/25 (2.2.2.2/25) to INSIDE:1.1.1.1/36378 (1.1.1.1/36378)
!
3.) Nov 15 14:34:20 192.168.45.50 : %ASA-6-302014: Teardown TCP connection 2428777825 for OUTSIDE:2.2.2.2/25 to INSIDE:1.1.1.1/36378 duration 0:00:00 bytes 1600 TCP Reset-I
!
4.) Nov 15 14:34:20 192.168.45.50 : %ASA-6-106015: Deny TCP (no connection) from 1.1.1.1/36378 to 2.2.2.2/25 flags RST on interface INSIDE
!
5.) Nov 15 14:34:20 192.168.45.50 : %ASA-6-106100: access-list outside-in permitted tcp OUTSIDE/2.2.2.2(25) -> INSIDE/1.1.1.1(36378) hit-cnt 1 first hit [0x123456789, 0x0]
!
6.) Nov 15 14:34:20 192.168.45.50 : %ASA-6-106015: Deny TCP (no connection) from 2.2.2.2/25 to 1.1.1.1/36378 flags ACK on interface OUTSIDE
6.) Nov 15 14:34:20 192.168.45.50 : %ASA-6-106015: Deny TCP (no connection) from 2.2.2.2/25 to 1.1.1.1/36378 flags FIN PSH ACK on interface OUTSIDE
6.) Nov 15 14:34:21 192.168.45.50 : %ASA-6-106015: Deny TCP (no connection) from 2.2.2.2/25 to 1.1.1.1/36378 flags FIN PSH ACK on interface OUTSIDE
6.) Nov 15 14:34:22 192.168.45.50 : %ASA-6-106015: Deny TCP (no connection) from 2.2.2.2/25 to 1.1.1.1/36378 flags FIN PSH ACK on interface OUTSIDE
6.) Nov 15 14:34:25 192.168.45.50 : %ASA-6-106015: Deny TCP (no connection) from 2.2.2.2/25 to 1.1.1.1/36378 flags RST ACK on interface OUTSIDE
!
7.) Nov 15 14:39:21 192.168.45.50 : %ASA-6-106100: access-list inside-out permitted tcp INSIDE/1.1.1.1(36378) -> OUTSIDE/2.2.2.2(25) hit-cnt 1 300-second interval [0x123456789, 0x0]
!
8.) Nov 15 14:39:21 192.168.45.50 : %ASA-6-106100: access-list outside-in permitted tcp OUTSIDE/2.2.2.2(25) -> INSIDE/1.1.1.1(36378) hit-cnt 4 300-second interval [0x123456789, 0x0]
