A cosa serve il profiling in ISE

Il profiling è il servizio con cui Cisco ISE classifica automaticamente gli endpoint che si connettono alla rete (stampanti, IP phone, telecamere IP, laptop, dispositivi IoT) attribuendo loro un profile (o endpoint identity group). La classificazione alimenta le authorization policy: un dispositivo profilato come Cisco-IP-Phone riceve una dACL e una VLAN voce, una telecamera va in una VLAN segmentata, un endpoint sconosciuto resta in quarantena. Il profiling gira sul Policy Service Node (PSN) con persona Profiling Service abilitata; la classificazione è basata su regole di condizione che confrontano gli attributi raccolti con centinaia di profiling policy predefinite, ciascuna con un Certainty Factor (CF): vince la policy con CF cumulativo più alto sopra la Minimum Certainty.

Le probe principali

Le probe sono i meccanismi con cui il PSN raccoglie attributi. Ognuna osserva un aspetto diverso del traffico dell’endpoint.

Probe Cosa raccoglie Note operative
DHCP dhcp-class-identifier, host-name, option 55 (Parameter Request List) Richiede ip helper-address verso il PSN sull’SVI
DHCP SPAN Stessi attributi DHCP ma via mirroring Alternativa se non si può usare l’ip helper
RADIUS MAC, Calling-Station-ID, attributi dell’auth Sempre disponibile, è il “collante” del flusso
SNMP Query sysDescr, tabella CDP/LLDP, ifIndex, MAC del NAD Innescata dal RADIUS accounting (query mirata)
SNMP Trap Notifiche linkup/linkdown/MAC-notification Trigger per lanciare la SNMP Query
HTTP User-Agent dal browser Ottima per distinguere OS/browser; via redirect o SPAN
DNS Reverse lookup (FQDN dell’endpoint) Funziona solo se un’altra probe ha già fornito l’IP
NMAP Scan attivo: porte aperte, OS fingerprint, SNMP Scan manuale o automatico su subnet; genera traffico
NetFlow Flussi L3/L4 esportati dai device Volume elevato: usare solo per casi mirati
Active Directory Attributi AD dell’host Utile per distinguere domain vs non-domain

Device Sensor su IOS-XE

Sugli switch e WLC IOS-XE il Device Sensor raccoglie localmente gli attributi visti dal NAD tramite CDP, LLDP, DHCP, mDNS e H.323 e li incapsula dentro i pacchetti RADIUS accounting inviati al PSN. Questo evita di attivare probe pesanti o mirroring centralizzati: gli attributi arrivano “gratis” nel flusso di autenticazione già presente. La configurazione tipica prevede l’attivazione dei filtri e l’inclusione nell’accounting:

device-sensor filter-list dhcp list DHCP_LIST
device-sensor filter-spec dhcp include list DHCP_LIST
device-sensor accounting

Il Device Sensor è il metodo preferito e più scalabile per raccogliere attributi di access layer, perché sposta la raccolta sul NAD e usa RADIUS come trasporto.

Perché combinare più probe

Nessuna singola probe classifica in modo affidabile un endpoint moderno. La DHCP option 55 distingue una famiglia di OS, ma serve lo User-Agent HTTP per capire la versione, la SNMP Query per leggere il vicino CDP/LLDP, l’NMAP per confermare le porte aperte di una stampante. Sommando gli attributi si sommano i Certainty Factor: più evidenze concordi alzano il CF totale e portano la classificazione dal generico (Workstation) allo specifico (Microsoft-Workstation → poco importa il vendor, il concetto è la granularità). Combinare le probe riduce inoltre i falsi positivi e resiste allo spoofing del solo MAC.

Trappole tipiche d’esame

  • Scenario: la DHCP probe è abilitata sul PSN ma gli endpoint non vengono profilati. → Manca l’ip helper-address del PSN sulla SVI di accesso (o va usata la DHCP SPAN). La probe abilitata non basta: i pacchetti DHCP devono raggiungere fisicamente il PSN.

  • Scenario: serve profilare l’access layer in modo scalabile senza SPAN né traffico aggiuntivo. → Configurare il Device Sensor su IOS-XE, che inoltra CDP/LLDP/DHCP dentro il RADIUS accounting. Non moltiplicare le probe centralizzate.

  • Scenario: dopo aver attivato NetFlow e NMAP su tutte le subnet il PSN va in sovraccarico. → Abilitare solo le probe necessarie; NetFlow (volume dei flussi) e NMAP (scan attivo) vanno usate in modo mirato, non a tappeto, per non saturare CPU e rete.

  • Scenario: la DNS probe non restituisce l’FQDN. → La DNS probe fa solo reverse lookup e dipende dall’IP già fornito da un’altra probe (DHCP, RADIUS, SNMP). Da sola non produce nulla.

  • Scenario: distinguere un IP phone da una workstation dietro lo stesso switchport. → Affidarsi a CDP/LLDP via Device Sensor o SNMP Query, non alla sola DHCP: gli attributi del vicino identificano con certezza il Cisco-IP-Phone.