Security

 View Only
last person joined: yesterday 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Back to discussions
Expand all | Collapse all

NAS-Filter-Rule permit to FQDN instead of IP

This thread has been viewed 19 times

  • 1.  NAS-Filter-Rule permit to FQDN instead of IP

    MVP
    Posted Feb 20, 2024 09:39 AM

    Hi everbody,

    is it possible to implement a NAS-Filter-Rule using a FQDN instead of a an IP?

    Example:

    permit in tcp from any to 10.1.1.10 443 CNT > works fine but is it possible to use something like:

    permit in tcp from any to *.manage.microsoft.com 443 CNT

    Kind regards

    Matthias



  • 2.  RE: NAS-Filter-Rule permit to FQDN instead of IP

    Posted Feb 20, 2024 12:10 PM

    Depends, what is the NAD?  This is an ACL to a switch?  What exactly is the use-case?  


    Original Message


  • 3.  RE: NAS-Filter-Rule permit to FQDN instead of IP

    MVP
    Posted Feb 21, 2024 07:02 AM
    You're absolute right, it would have been a good idea to consider the use case :-)
    We have several Aruba 2540 and Aruba 2530 switches. These switches are integrated to our ClearPass environment. 
    I´ve implemented a wired MAC based service, wich works fine. If a client is connected to the switch and doesn't use 802.1x a guest logon enforcement profile is assigned.
    This profile redirects to the captive portal and allows tcp 80&443 to the captive portal. All other http+s traffic is denied:
    1.  Radius:IETF Session-Timeout = 10800
    2. Radius:IETF Termination-Action = RADIUS-Request (1)
    3. Radius:IETF Tunnel-Type = VLAN (13)
    4. Radius:IETF Tunnel-Medium-Type = IEEE-802 (6)
    5. Radius:IETF Tunnel-Private-Group-Id = 65
    6. Radius:Hewlett-Packard-Enterprise HPE-Captive-Portal-URL = https://fqdn/guest/oc_wired.php
    7. Radius:IETF NAS-Filter-Rule = permit in udp from any to any 53 CNT
    8. Radius:IETF NAS-Filter-Rule = permit in udp from any to any 67 CNT
    9. Radius:IETF NAS-Filter-Rule = permit in tcp from any to 10.x.x.x 80 CNT
    10. Radius:IETF NAS-Filter-Rule = permit in tcp from any to 10.x.x.x 443 CNT
    11. Radius:IETF NAS-Filter-Rule = deny in tcp from any to any 80 cpy CNT
    12. Radius:IETF NAS-Filter-Rule = deny in tcp from any to any 443 cpy CNT
    The same profile is applied if I connect and client and try to install the client via Microsoft Autopilot. For this I would like to permit tcp in TCP from any to *.manage.microsoft.com

    Original Message


  • 4.  RE: NAS-Filter-Rule permit to FQDN instead of IP

    Posted Feb 21, 2024 07:14 AM
    Got it, newer versions of IOS-XE 17.X on Cisco Switches do support DNS ACL entries. The switch performs a DNS lookup at a set intervals and updates the IP based on DNS result in the ACL dynamically. It does have limitations though around the number of results it will install. I’m not aware of Aruba switches having such a feature.

    I would consider using a firewall upstream for this use-case


    Original Message


  • 5.  RE: NAS-Filter-Rule permit to FQDN instead of IP

    Posted Feb 21, 2024 05:27 AM

    The point is that a switch just sees the IP address. Some advanced network solutions, like firewalls, controllers, gateways, do support this by either:

    • Snoop the client DNS traffic for *.manage.microsoft.com, and store the answers/returned IPs in a table that is used for the actual ACL enforcement. This does not work if DNS goes via a different path (or cached), uses DNS over HTTPS, or other encryption techniques.
    • Resolve the FQDN periodically and store the responses in a similar table, which can have issues with dynamic DNS services. This does not work for your example *.manage.microsoft.com as you can only resolve FQDNs not wildcards.
    • For HTTPS snoop the SSL session setup and check the hostname (SNI) and check that against the ACL, which requires the first packets to be permitted, works only for HTTPS and will stop to work once the SNI will be encrypted (optional part of TLS 1.3).

    For switches this means (line rate) deep packet inspection or periodic DNS requests, which is not common in many switches. And even then not all mentioned strategies work in all cases. So it's not as simple as the question may look.



    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------

    Original Message