topic Re: ASA access-group and packet tracer behaviour in Network Security

ASA access-group and packet tracer behaviour

sulaimangd — Fri, 21 Feb 2020 16:43:28 GMT

Hi,

I was wondering what is the logic used to apply access-group to an Interface in ASA.

i have a simple topology

(Client)---> ASA----> (SSH_Server)

these are my configured IPs

object-group network inside

network-object host 192.168.200.10

object-group network dmz-http

network-object host 172.29.10.10

object-group network SSH_Server (this is basically a Linux Machine)

network-object host 4.2.2.2

object-group service webmin_10000 tcp

port-object eq 10000

and

this is my access list

access-list inside-out extended permit tcp object-group inside object-group SSH_Server eq ssh

and this is my access-group

access-group inside-out out interface inside

although in the ACL is allows only ssh traffic

from the client when i browse https://4.2.2.2:10000

I'm able to access the web page.

when running packet tracer

ASAv# packet-trace input inside tcp 192.168.200.10 1024 4.2.2.2 10000 detailed

Phase: 1

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 202.110.0.2 using egress ifc Outside

Phase: 2

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in id=0x7f51495dca10, priority=1, domain=nat-per-session, deny=true

hits=638, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=any, output_ifc=any

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in id=0x7f51499a4690, priority=0, domain=inspect-ip-options, deny=true

hits=317, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=inside, output_ifc=any

Phase: 4

Type: QOS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in id=0x7f514980bc90, priority=70, domain=qos-per-class, deny=false

hits=627, user_data=0x7f51499bd7b0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=any, output_ifc=any

Phase: 5

Type: QOS

Subtype:

Result: ALLOW

Config:

Additional Information:

Reverse Flow based lookup yields rule:

in id=0x7f514980bc90, priority=70, domain=qos-per-class, deny=false

hits=628, user_data=0x7f51499bd7b0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=any, output_ifc=any

Phase: 6

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Reverse Flow based lookup yields rule:

in id=0x7f51495dca10, priority=1, domain=nat-per-session, deny=true

hits=640, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=any, output_ifc=any

Phase: 7

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Reverse Flow based lookup yields rule:

in id=0x7f51499fc4f0, priority=0, domain=inspect-ip-options, deny=true

hits=314, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=Outside, output_ifc=any

Phase: 8

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 314, packet dispatched to next module

Module information for forward flow ...

snp_fp_tracer_drop

snp_fp_inspect_ip_options

snp_fp_tcp_normalizer

snp_fp_translate

snp_fp_adjacency

snp_fp_fragment

snp_ifc_stat

Module information for reverse flow ...

snp_fp_tracer_drop

snp_fp_inspect_ip_options

snp_fp_translate

snp_fp_tcp_normalizer

snp_fp_adjacency

snp_fp_fragment

snp_ifc_stat

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: Outside

output-status: up

output-line-status: up

Action: allow

but when i run packet-tracer like this

ASAv# packet-trace input Outside tcp 192.168.200.10 1024 4.2.2.2 10000 detaile$

Phase: 1

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 202.110.0.2 using egress ifc Outside

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in id=0x7f51499f7510, priority=111, domain=permit, deny=true

hits=3056, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=Outside, output_ifc=Outside

Result:

input-interface: Outside

input-status: up

input-line-status: up

output-interface: Outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

my questions,

1- why does the the ACL is not applied on the Interface with configured Access-group. (my assumption, because the ACL didn't get a hit, and since ASA allows by default traffic from Higher security level to lower security level im able to access the Server on port 10000)

2- what is the difference between packet-tracer command when i run packet-trace input inside tcp 192.168.200.10 1024 4.2.2.2 10000 detailed and packet-trace input Outside tcp 192.168.200.10 1024 4.2.2.2 10000 detail

i know this is a very basic question but it's really confusing how this work.

i hope everything is clear.

Re: ASA access-group and packet tracer behaviour

Sheraz.Salim — Wed, 30 Jan 2019 14:33:39 GMT

(Client)---> ASA----> (SSH_Server)

let assume Client is inside network with security level 100 and SSH_Server is outside network security level 0. as you understand and right to think that the flow is allow from higher to low. however if you want low to higher than in that case you need access-list with access group and nat if required.

now PC1 at client want to connect to SSH_Server. The packet come to asa and ASA see it from from higher level and going to lower level so what ASA do here is a stateful entry of the connection by remembering the connection state. so packet in allow and ASA keep the cache entry of the connection. this can be check by giving command show conn address 192.168.1.1 (client_pc here).

now why you need the access-list/access-group lets walk you through it.

now let say you want to keep your PC_CLIENT not to talk to your SSH_SERVER for some reason. in that case you can write an access-list like this

access-list INSIDE_OUT extended deny tcp host 192.168.1.1 host x.x.x.x eq ssh

access-list INSIDE_OUT permit ip any any

access-group INSIDE_OUT in interface inside

what that mean. now try to undersand/imagine the flow of the traffic from the ASA point of view. in order to act for ASA first line of defence is the interface of ASA. I said to ASA if a packet comes in at the inside interface apply these check which are deny the ssh for the host 192.168.1.1 (CLIENT_PC) to server SSH rest allow anything.

now let see the traffic pattern for the outside interface with access-list/access-group

access-list OUTSIDE_IN extended permit ip host SSH_SERVER host CLIENT_PC

access-group OUTSIDE_IN in interface outside

now here. first look at the access-group i am saying let the packet in from the outside with condition permit ip SSH_SERVER as the flow of the traffis is coming from outside and i am saying let it communicate with Client_PC only nothing else. howerver, having said that when the traffic land outside and going inside we apply natting rules. so the nat rule will be like this

object network CLIENT_PC

host 192.168.1.1

nat (inside,outside) static interface

no what will happen is once the ACL are check the nat kicks in and the ASA create an entry where i said in rules going inside,outside static use the interface of the ASA outside interface.

you also need to understand the flow of packet flow here it is

Re: ASA access-group and packet tracer behaviour

msanlimit — Wed, 30 Jan 2019 14:44:39 GMT

Hey!

1.)Your access-list said: permit tcp from source host 192.168.200.10 to destination host 4.2.2.2 port 22 and you applied it on inside interface but for OUT traffic. Think about interface like it's your hand. Hand goes towards your body - it will be "IN" for your interface(source 192.168.200.10 -> 4.2.2.2), hand goes from your body - it will be "OUT" for interface (source 4.2.2.2 -> 192.168.200.10).

So to permit ssh from host 192.168.200.10 to host 4.2.2.2 yo need apply ACL "access-group inside-out in interface inside"

2.) packet-trace input inside - packet comes to the inside interface(from your internal network).

While packet-trace input Outside - packets comes to the outside interface(from Internet).

Re: ASA access-group and packet tracer behaviour

sulaimangd — Thu, 31 Jan 2019 15:59:23 GMT

Hi,
Thanks for the explanation. so if i understood

inside outside

(Client)-----------(ASA)-----------(SSH_Server)

if a traffic originates from Client, we apply the the ACL to the traffic ingress inside interface. now if i wanted to apply that ACL on outside Interface, it should be access-group inside-out out interface outside and now im not able to access the URL from the browser, (https://4.2.2.2:10000) but im able to access Server with SSH.
the question now..
when i applied the access-group inside-out in interface Outside, it still allows the access of the URL https://4.2.2.2:10000.
and when i run packet-tracer this is my output
ASAv(config)# packet-tracer input outside tcp 192.168.200.10 2222 4.2.2.2 10000 details
Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 202.110.0.2 using egress ifc Outside

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fee899f7320, priority=111, domain=permit, deny=true
hits=20412, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Outside, output_ifc=Outside

Result:
input-interface: Outside
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

if it showed as denied by ACL, why i'm able to access the Server using the URL? As far as i understood, i applied the ACL to the traffic leaving the outside Interface?
Thanks

Re: ASA access-group and packet tracer behaviour

Rob Ingram — Thu, 31 Jan 2019 19:00:18 GMT

Hi,
If you entered the command "access-group inside-out in interface Outside" - you have applied the ACL inbound on the outside interface, not leaving the outside interface as you believed.

Your packet-tracer command "packet-tracer input outside tcp 192.168.200.10 2222 4.2.2.2 10000 details" - this will run ingress traffic on the interface. Re-run the command with "inside" interface

To answer your last question, the packet-tracer isn't hitting your new ACL when it's run, which is misleading you.

HTH