ISE DACL bi-directional setting

[Chris S]

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? 

[davidgfriedman]

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).

[hslai]

@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.

[MHM Cisco World]

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

[Arne Bier]

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

[Chris S]

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

[Arne Bier · Accepted solution]

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?

[Chris S]

@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. 

[MHM Cisco World]

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