topic Re: ISE DACL bi-directional setting in Network Access Control

ISE DACL bi-directional setting

Chris S — Fri, 05 Jan 2024 21:31:16 GMT

I have a DACL being applied allowing 445 access to an internal resource. Is there a way to allow the internal resource reverse access so it can access the restricted device on 445 as well?

Re: ISE DACL bi-directional setting

davidgfriedman — Fri, 05 Jan 2024 22:07:29 GMT

If I understand you correctly, we do that all of the time. Example (assuming TCP/455):

permit tcp any eq 455 any <--- inbound to port tcp/455 on the endpoint device)
permit tcp any any eq 455 ---> outbound from the endpoint device to anything on tcp/455. This assumes firewalls in between allow access, of course).

Plus, as you know you can replace "any' with "host A.B.C.D" or subnet/mask "A.B.D.C 255.255.255.0" (etc).

Re: ISE DACL bi-directional setting

hslai — Mon, 08 Jan 2024 04:29:16 GMT

@Chris S Take a look at Understand 802.1x DACL, Per-User ACL, Filter-ID, and Device Tracking Behavior .

DACLs are usually for the access clients only. The network access device will replace the source portion of each ACE with the access client's IP address. For another device to access this client, we would likely need to allow any ports higher than 1024 from the access client's IP.

Re: ISE DACL bi-directional setting

MHM Cisco World — Mon, 08 Jan 2024 07:26:09 GMT

As I know the Per-User ACL use "IN" direction not "OUT"
and ip tracking resolve the IP of host and add it to dACL, i.e. permit ip any any will resolve by ip tracking to permit ip host x.x.x.x any

now you can change the dacl
instead of permit ip any any
use
deny ip any any eq 455
permit ip any any

try this way

MHM

Re: ISE DACL bi-directional setting

Arne Bier — Tue, 09 Jan 2024 23:57:49 GMT

I have always found this topic confusing, especially because we use the terms "source" and "destination" as if it's meant to be obvious. But it's only obvious if you mention in the same sentence, from whose perspective you're saying source/destination.

My assumption was always this: an ACL exists on an interface to check/control/protect data from attached endpoints entering the network. In other words, we don't naturally consider what to check/control from the network towards the endpoint.

What @davidgfriedman quite correctly stated earlier, I realised my confusion about the simple word inbound - but, inbound from whose perspective?

permit tcp any eq 455 any <--- inbound to port tcp/455 on the endpoint device)

Ok - the ACL syntax is "source destination" - if I had to translate this into layman's terms I would read it as "accept data from the endpoint from any src addr where the TCP source port is 455, towards any destination address" - but in reality it's the other way around. It means "allow data TO the device on a service that is running on TCP/455". e.g. a Linux server in the data center wants to access an endpoint at TCP/455. Okaaaaaaay .but then why is the source port TCP/455? The TCP connection is established from the data center and the TCP destination port would be 455. My brain starts to hurt and it shuts down.

With some of the previous explanations it got a bit clearer. I even started having doubts that these ACE entries were perhaps stateful - but now I know they are not. I decided to test things in the lab to sort out my doubts.

I used a C9300 switch that has a raspberry pi as the endpoint attached to Gig 1/0/22 - this interface is enabled for MAB and ISE authorized the session with a dACL. I built up the dACL in various stages to see what worked, and what didn't - e.g.

from switch: ping the raspi
from switch: ssh to the raspi
from raspi: ping default gw
from raspi: ssh to an Ubuntu server

I put this into layman's terms to keep as a reference for myself

Re: ISE DACL bi-directional setting

Chris S — Wed, 10 Jan 2024 13:08:39 GMT

Maybe the better question would be to ask how everybody handles onboarding new computers to the network? Our method was to have ISE push a default dACL policy to allow minimal access to systems (dns, active directory, cert enrollment, PDQ) .. then once the device would pass posture, ISE would change the dACL to allow for full access.

Default dACL:

remark PDQ
permit tcp any host 172.30.8.106 eq 445
permit tcp any eq 445 host 172.30.8.106

remark DHCP
permit udp any any eq 68
remark DNS
permit udp any any eq 53
permit tcp any any eq 53
remark RFC1918
deny ip any 172.16.0.0 0.0.240.255
deny ip any 192.168.0.0 0.0.255.255
deny ip any 10.0.0.0 0.0.0.255
remark Internet
permit tcp any any eq 80
permit tcp any any eq 443

Re: ISE DACL bi-directional setting

Arne Bier — Wed, 10 Jan 2024 20:34:20 GMT

TL;DR - It depends

It's good to get the ACL/dACL theory out of the way and well understood, and then the sky is the limit, regarding what ACLs to apply to endpoints in various stages of authorization/posture. TCP/445 might be useful for Microsoft workstations, but doesn't benefit other endpoints like cameras, printers, MacOS, etc. - the list goes on.

In practice, when a customer is in low-impact mode wired NAC, there should be a pre-auth ACL hard coded on the interface (access-group PRE_AUTH_ACL in) and this one takes care of controlling what the endpoint can do before ISE declares the session as Authorized (i.e. ISE has finished Authentication) - if ISE sends down a dACL to this session (which it should do as part of low-impact mode) then the pre-auth ACL gets bypassed, because dACL now rules the roost. This is where you apply your next level of ACLs to give the endpoint control of what it can do. Perhaps ISE authorized the endpoint as accurately as it can (e.g. 100% certainty or via 802.1X) or it failed through to the last Rule which is a general catch-all Rule - even this Rule should allow some minimum access to the endpoint to allow profiling (especially in the MAB case).

In practice, I allow DHCP/DNS/TFTP (pretty much the image I posted earlier, but without the SSH ACEs)

tftp was added to help the PXEBOOT process (it's used during the PXE process to fetch a config file). Perhaps PXEBOOT is used in your environment?

My question to @Chris S - what type of access does TCP/445 allow ? Does the endpoint then talk to the Domain Controller? Does that help for Machine Auth'd workstations to have some sort of basic SMB comms to the DC? I thought there was more than this required. And also, wouldn't that be a nice open door for hackers?

Re: ISE DACL bi-directional setting

Chris S — Wed, 10 Jan 2024 21:13:30 GMT

@Arne Bier Our pre-auth ACL on the switch ports only allow DHCP/DNS/ISE access - past that nothing. We decided to have a device group for all new workstations .. once ISE is aware of the device, it passes down a dACL that allows for the nessesary resources to setup the machine. 445 allows for the baseline applications to install and update. The 445 is specific to the file server hosting the installation media. We don't use PXEBOOT for anything.

Re: ISE DACL bi-directional setting

MHM Cisco World — Wed, 10 Jan 2024 21:34:51 GMT

friend the dACL is Port-ACL and it INBOUND only
and the host connect to port always initiate the traffic not the server so you need only
permit tcp any host 172.30.8.106 eq 445
~~permit tcp any eq 445 host 172.30.8.106~~ <- if the server port dont use 802.1x

if server port use 802.1x then you need this line then you need <permit tcp any eq 445 <subnet of host >>
which is rare since the server always have static IP.

MHM