Undesireable "Deny" or "Block" ASA Behavior

BRIAN SEKLECKI — Fri, 21 Feb 2020 08:41:00 GMT

Per my previous post ---

[In a full "Nat 0" envrionment with the PIX Functioning as an VLAN ACL Filter]

*) When a packet gets blocked by the default ASA policy -- that of a packet with a source in a lower security level traveling to a higher security level interface, you get a "timed out", or no reponse the default behavior of many firewalls "block", "drop", or "deny" rules.

*) If I don't apply an access-list/access-group combination to an "Internal" interface (one defined by a high security level), the implied behavior is an ACL "permit any any" from traffic headed to a destination on a lower interface. As if an explicity ACL "permit any any" is in place.

*) In that scenario, in order for ICMP (and *ONLY* ICMP traffic) reply traffic

to return back from the lower security level interface at the destionation host,

back to the original sender on the higher level security interface,

I must apply an inbound access-list/

access-group statement matching return traffic.

*) Is this something to do with ASA's automatic stateful/reflexive nature of TCP

v.s. ICMP's stateless? Other firewalls can keep state on ICMP/UDP/GRE/ESP.

*) If I apply access-list/access-group combination to the same internal "higher security" interface in an attempt to restrict access from the higher level security interface/subnet to a lower level security interface/subnet, traffic matching "deny" statements will recieve "Connection Refused" ICMP back (TCP Flag RST from the PIX masquarading as the destination),

which is the OpenBSD PF(4) equiv of a "return-rst" argument to a "block", and what

a non-firewalled host will return to an attempt to open a TCP port to a non-listening Service Port.

from capture:

11:03:32.150565 802.1Q vlan#20 P0 192.168.9.2.23 > 192.168.8.2.1096: R 0:0(0) ack 1397346855 win 65535 <mss 1260,nop,nop,sackOK>

and:

106023: Deny tcp src Customer0:192.168.8.2/1099 dst Management:192.168.9.2/23 by access-group "customer0_2_mgmnt"

*) This behavior is a bit misleading and normally something that you would be able to fine-tune in many firewalls.

*) Also, because Pix only allows application of access-groups "inbound", I am left with this quagmire:

Vlan 11 (interface DMZ, Security0 -- public routable),

Vlan 12 (private management, Security15),

Vlan 2[X], Where

X = Interface:CustomerX (Security50).

- All customer subnets are isolated by the nature of ASA/Same Security Levels; good.

- Nat0 applied to all customer interfaces with

an ACL for *each* matching source that subnet destination the Management subnet

- Granular "inbound" ACLs applied from Customer0 to Management to restrict the

default ASA behavior, overriding the default "permit any" behavior

- Nat1/PAT from Management to DMZ (Via Interface Address):

-- nat (Management) 1 access-list MgmntSubnetToNAT 0 0

- Now I must design a very convuluted Access-list applied "inbound" to the

Management interface to permit:

- ICMP returns to CustomerX interfaces

- Specific TCP/UDP from Management to CustomerX interfaces

- Some kind of permit exemption for all traffic from source Management subnet destined

for a wildcard on DMZ. Luckily, DMZ is a different subnet/ip block, and Cisco ACLs use a match-first-rule-stop-evaluating logic so I can do something like:

Perhaps I would be better off with a Gigabit enabled router acting as an ACL filter? If I don't need NAT, Fixups, Like a 26xx or 28xx router? Something that can take a IPSec enabled IOS image and a VPN acellerator in a WIC port?

The problem is, the Supervisor in my 3550 HSRP Pair (or 65xx MSRP) is simply doing default routing from my DMZ to my WAN subnets.

Unforunately, I only enable IPs on those two VLANs. For security, the VLANs I'm ACL'ing on the PIX are only introduced to Layer 3 *on* the PIX, and only Layer2 on the 3550 Pair.

What I have will work, but it is sub-optimal. I should definately be able to reconfigure "block" ACL behavior in the same way I can with generic IOS.

Re: Undesireable "Deny" or "Block" ASA Behavior

gfullage — Tue, 31 Jan 2006 23:54:52 GMT

I'm not 100% sure what you're asking here so I'll try and just help with your first few statements and hopefully that'll clear things up and maybe make your ACL a bit less convoluted.

You wrote:

------------------------------------------------

*) In that scenario, in order for ICMP (and *ONLY* ICMP traffic) reply traffic

to return back from the lower security level interface at the destionation host,

back to the original sender on the higher level security interface,

I must apply an inbound access-list/

access-group statement matching return traffic.

*) Is this something to do with ASA's automatic stateful/reflexive nature of TCP

v.s. ICMP's stateless? Other firewalls can keep state on ICMP/UDP/GRE/ESP.

which is the OpenBSD PF(4) equiv of a "return-rst" argument to a "block", and what

a non-firewalled host will return to an attempt to open a TCP port to a non-listening Service Port.

------------------------------------------------

The PIX/ASA does not by default inspect ICMP packets like it does UDP/TCP packets, meaning that it doesn't open a "hole" for the return packets to come back in. You can of course turn ICMP inspection on meaning the replies to these packet s will be allowed back in just like any other packet. Look near the bottom of your config for the global service policy and all the "inspect" statements, simply add :

inspect icmp

inspect icmp error

into that policy and you will no longer need to worry about ICMP return packets.

The ASA does reply to inside-interface denied packets with a RST, and this cannot be changed. On the outside interface it will by default silently discard the packet, but you can get it to send a RST if you like (not recommended) with the use of the "service resetinbound" command (http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/v_70/cref_txt/s.htm#wp1099773)

Also note that in v7.0 (which you are running if you're using an ASA), then you can apply access-groups both inbound and outbound now. See http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/v_70/cref_txt/ab.htm#wp1409851 for details.

Hopefully all that will make your configuration a bit easier.

topic Undesireable "Deny" or "Block" ASA Behavior in Network Security

Undesireable "Deny" or "Block" ASA Behavior

Re: Undesireable "Deny" or "Block" ASA Behavior