Cisco ISE, un 10 sense mitigació: la teva xarxa ja va decidir què fa sense ell

Obre el show run d'un switch de planta i busca-hi dues coses: quants servidors RADIUS hi ha configurats de debò, i quin deadtime tenen. Això és el que farà la teva xarxa el dia que el motor de polítiques no contesti. El valor per defecte de radius-server deadtime a IOS i a IOS XE és 0.

Cisco ho documenta amb la conseqüència enganxada al costat. Si no s'especifica el deadtime val 0, «which brings the server back to the UP state right away», i per això «the RADIUS server state could flap, causing additional authentication issues». A la pràctica: el switch triga a marcar mort un servidor, perquè calen els dos criteris —un temps mínim sense resposta vàlida i un nombre de timeouts consecutius—, i tan bon punt el marca, el reviu. A la següent autenticació torna a preguntar al mateix servidor que s'està reiniciant. L'altre servidor, el que és aixecat, rep la petició només després que el primer exhaureixi els seus reintents, si és que hi arriba. Dos servidors configurats i deadtime 0 fan un servidor amb cua d'espera.

Aquest detall fa anys que hi és i gairebé mai no molesta. Aquesta setmana sí, perquè a molta gent li toca reiniciar els seus nodes d'ISE amb presses.

L'avís

Cisco va publicar el 16 de setembre cisco-sa-ISE-ABP-VNSW7Tn5, versió 1.0 i ja marcada com a final. CVE-2026-76460, CVSS 10.0, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, CWE-648. La causa, literal: «insufficient authentication control on an API endpoint». Afecta Identity Services Engine i el Passive Identity Connector a les branques 3.1, 3.2, 3.3, 3.4 i 3.5, i es corregeix a 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 i 3.5 Patch 4. Si corres la 3.0, la taula de l'avís no t'ofereix pedaç: diu que aquesta branca ha arribat a fi de manteniment de programari i que cal migrar a una versió suportada que inclogui la correcció. No hi ha workarounds. I el PSIRT declara que té constància d'explotació activa.

CISA el va incloure al catàleg de vulnerabilitats explotades aquell mateix 16, a la versió 2026.09.16, sota la directiva BOD 26-04 i amb la marca de triatge forense. Hi van entrar tres CVE aquell dia, els tres amb data límit el 19 de setembre: aquest, la fallada de permisos del connector de còpies d'Acronis de què escrivíem aquest mateix matí i una fallada del mòdem cel·lular dels Google Pixel. El 19 cau en dissabte, així que l'últim dia laborable és demà.

Abans del pedaç va l'access.log

La part de l'avís que gairebé no s'ha citat a les cobertures d'ahir és la secció d'indicadors de compromís, i és la que canvia l'ordre de les tasques. Cisco diu que per confirmar un intent d'explotació cal revisar l'access.log i buscar-hi noms d'usuari sospitosos, i dóna el lloc on mirar. A sota hi ha el paràgraf que convé llegir dues vegades: després d'una explotació reeixida, els atacants poden obtenir «command execution with root privileges», i precisament per aquest nivell d'accés «evidence of exploitation and indicators of compromise may be removed or hidden by the threat actors». D'aquí la recomanació de creuar els registres de xarxa i de tallafocs externs a l'aparell afectat.

El que no sabem és com s'està explotant. Cisco no publica detall tècnic de l'atac ni la data des de la qual s'observa, i qui t'expliqui avui l'exploit pas a pas se l'està inventant. Amb el que hi ha publicat n'hi ha prou per ordenar la feina: mirar el registre abans de tocar res, pedaçar, i decidir què fas si el registre té alguna cosa.

Per què un 10 i no un 9,8

Gairebé tots els salts d'autenticació remots es queden en 9,8. Aquest arriba al 10 per una lletra: S:C, scope changed, que en CVSS vol dir que el component vulnerable i el que pateix l'impacte no són el mateix. El mateix avís diu quin és aquest encreuament uns paràgrafs més avall: el que se salta és l'autenticació de la interfície de gestió web, i el que s'obté és execució d'ordres com a root. La caixa sencera, no l'aplicació.

La puntuació es queda aquí, perquè CVSS no puntua el dany aigües avall. El dany aigües avall és el que t'ocuparà la tarda, i per a això convé separar dues coses que es confonen. El gestor de tallafocs de què parlàvem fa uns dies és un pla de gestió: es consulta quan algú vol canviar alguna cosa. ISE en té un d'igual, i a més és una altra cosa: un pla de decisió en temps real, al camí crític de cada autenticació 802.1X, cada MAB d'una impressora i cada autorització de VPN. Se li pregunta milers de vegades al dia, quan algú endolla un cable. Un pla de decisió es pot robar, i també es pot apagar. El segon és el que gairebé mai no està decidit.

El pedaç roda, si tens on caure

El que frena l'aplicació de pedaços en un control d'accés a la xarxa és una por raonable: deixar l'oficina sense autenticar durant la finestra. Per a un desplegament distribuït, el fabricant té resposta. Cisco ho escriu així: «Cisco ISE installs the patch on the primary node first, then proceeds to the secondary nodes». Si falla al primari no continua cap als secundaris; si falla en un secundari, segueix amb el següent; i cada node es reinicia quan acaba la seva pròpia instal·lació. El requisit previ que anota el manual és deixar desmarcada la casella d'auto-failover del PAN mentre dura l'operació. El que la documentació no promet enlloc és que dos secundaris no se solapin: això ho comproves tu, amb un node de prova o mirant el rellotge.

Ara la part que no surt a cap guia, perquè descriu bona part dels nostres clients: en una oficina de trenta persones, ISE no és un desplegament distribuït. És una màquina, o dues. Allà no roda res. Quan l'únic node que atén autenticacions es reinicia, no hi ha segon on caure, i tot el que ve després d'aquest paràgraf deixa de ser un matís de configuració per convertir-se en la pregunta sencera.

Els dos modes que decideixes, i el tercer que ja tens

Quan el servidor no respon, un port amb 802.1X activat es comporta d'una d'aquestes tres maneres. Dues són decisions. La tercera acostuma a ser una resta.

• Tancat. Sense servidor no hi ha autorització. La documentació dels Catalyst ho descriu sense adorns: sense el bypass, «the client attempts and fails authentication indefinitely, and the switch port remains in the spanning-tree blocking state». És el que passa per defecte tan bon punt actives 802.1X, perquè la taula de configuració per defecte porta «Inaccessible authentication bypass: Disabled». Segur i car: el portàtil que arrenca no entra, i la impressora que es va reiniciar tampoc.
• El segon és l'inaccessible authentication bypass, també anomenat autenticació crítica o política de fallada d'AAA: si el servidor no respon, el switch posa el port en estat d'autenticació crítica. Per a un equip que encara no estava autoritzat, a la VLAN que hagis configurat; però per a un que ja ho estava i li toca reautenticar, la guia avisa que es queda «in the current VLAN, which might be the one previously assigned by the RADIUS server». És a dir, a la que li va donar ISE, no necessàriament a la que vas triar tu. En tornar el servidor pots fer que els ports crítics reinicialitzin els seus hosts i els reautentiquin.
• I després hi ha el port que porta authentication open, on el trànsit passa encara que l'autenticació no hagi acabat o no hi hagi resposta de ningú. És una funció documentada i legítima: així es desplega 802.1X sense trencar l'oficina el primer dia, i així es monitora abans d'aplicar de debò. També és l'estat on es queda una quantitat incòmoda de desplegaments, perquè algú ho va posar perquè deixessin d'arribar tiquets, va funcionar, i ningú no ho va treure. Si és el teu cas, el CVSS 10 d'aquesta setmana no canvia gran cosa als teus switches: el teu control d'accés ja era en mode degradat permanent.

Cap dels tres és el correcte en abstracte. Un hospital i un laboratori no volen el mateix, i una nau amb lectors de producció tampoc no vol el mateix que una oficina de trenta persones. El que no és defensable és no saber en quin ets.

Per això som prudents amb el diagnòstic fàcil. El motiu que es diu en veu alta per retardar el pedaç d'un NAC és la finestra de manteniment, i la finestra de manteniment acostuma a ser la part barata, perquè la tries tu. La cara és l'altra: la que tria un tercer. Algú que pugui tombar la disponibilitat del teu motor de polítiques no necessita saltar-se el teu control d'accés a les nou i mitja d'un dimarts; li n'hi ha prou d'obligar-te a decidir en calent, amb la centraleta sonant, entre deixar la plantilla fora o obrir la porta. És la redundància que existeix al diagrama i no sobreviu al procediment, un altre cop.

L'ordre que seguiríem

Primer el registre, i això és el que canvia respecte d'un pedaç normal. Abans de reiniciar res, revisa l'access.log de cada node del desplegament buscant usuaris que no reconeguis, tal com indica l'avís. Si hi apareix alguna cosa, el pedaç deixa de ser el final de la feina i passa a ser el principi: la recomanació del fabricant és reinstal·lar aquest node i restaurar-ne la configuració. I com que l'execució és amb privilegis de root, els indicadors poden haver estat esborrats des de dins; els registres que valen de debò són els que són fora de l'aparell, al teu tallafocs i al teu col·lector.

Després el pedaç, amb el número del pedaç i no el de la branca. «Estem a 3.3» no és una resposta: les referències són 3.1 P12, 3.2 P11, 3.3 P12, 3.4 P7 i 3.5 P4, i a la 3.0 no hi ha pedaç, hi ha migració. Mira també el Passive Identity Connector, que és a la llista d'afectats i s'oblida perquè ningú no l'anomena «l'ISE». I ja que hi ets, la pregunta que planteja l'AV:N: des de quina xarxa s'arriba a aquesta interfície d'administració. No té motiu per ser accessible des de les VLAN d'usuari, ni des de la de convidats, ni des d'internet.

I després, ja amb calma, la part que sobreviu a aquest CVE. Compta al show run —no al diagrama— quants servidors veu cada switch, i posa un deadtime que no sigui zero, coherent amb el que triga un node teu a reiniciar-se. Decideix si vols sondeig amb automate-tester entenent l'intercanvi: sense probe-on sondeja sempre, detecta la caiguda abans que la pagui un usuari i a canvi envia trànsit constant contra el servidor; amb probe-on sondeja només quan ja és marcat mort, així que no t'estalvia el primer usuari però recupera el servidor sense esperar que expiri el deadtime. Qualsevol de les dues val més que el valor de fàbrica, que és no tenir-ne cap.

Queda l'inventari que decideix tot això i que gairebé ningú no consulta abans de triar: els dispositius que entren per MAB i no tenen ningú al darrere. Impressores, càmeres, lectors, control d'accessos, la màquina de la nau, els telèfons. Quan es queden fora no obren tiquet: es queden muts, i per això el cost del mode tancat no apareix a cap estadística de suport. I amb aquesta llista al davant, l'últim pas: apagar un node a posta un dimarts a les deu i mirar què passa en un port real, amb un portàtil real. És el pas que més resistència genera i l'únic que produeix certesa; ho fem amb tot el que considerem crític, pel mateix motiu pel qual cronometrem les restauracions. Un pla que ningú no ha assajat és una intenció amb format de document.

Queda una idea que és opinió nostra: un NAC no és Zero Trust. Un 802.1X que autentica el port i després deixa anar l'equip en una VLAN plana continua sent un perímetre, només que mogut a l'armari de planta. El símptoma el delata: si l'autorització continués valent alguna cosa després de creuar la porta, el mode degradat de la porta importaria bastant menys del que importa. És el mateix argument que fèiem sobre tractar el proveïdor d'identitat com una aplicació més: la peça que decideix no pot viure al mateix sac que les peces sobre les quals decideix. I que consti que ISE fa bé una feina que intenten molts i aconsegueixen pocs; un control d'autenticació insuficient en un endpoint d'API apareix en productes de totes les mides, i aquest mes ja en porta uns quants.

Nota de fonts

Consultat tot el 17 de setembre de 2026. Un: l'avís cisco-sa-ISE-ABP-VNSW7Tn5 de Cisco, publicat el 16-09-2026 en versió 1.0 final, d'on surten el CVE, el CVSS 10.0 i el seu vector, la CWE-648, la frase sobre el control d'autenticació insuficient en un endpoint d'API, les branques afectades 3.1 a 3.5 amb ISE-PIC, els pedaços corregits, la nota que la 3.0 ha arribat a fi de manteniment de programari i cal migrar, l'absència de workarounds, l'explotació activa constatada pel PSIRT, i tota la secció d'indicadors de compromís: revisar l'access.log buscant noms d'usuari sospitosos, les citacions sobre l'execució d'ordres com a root i sobre que els indicadors poden ser esborrats o amagats pels atacants, la recomanació de creuar els registres de xarxa i tallafocs externs a l'aparell, i la de reinstal·lar el node i restaurar la configuració si se sospita activitat maliciosa. Dos: el catàleg de vulnerabilitats explotades conegudes de CISA, versió 2026.09.16, llegit al seu JSON: les tres entrades afegides el 16-09-2026 (CVE-2026-76460 de Cisco ISE, CVE-2026-87886 d'Acronis Backup i CVE-2026-58704 de Google Pixel), les tres amb data límit 19-09-2026 i marca de triatge forense, sota la directiva BOD 26-04. Que el 19 caigui en dissabte és aritmètica de calendari. Tres: les guies d'actualització de Cisco ISE (branques 3.1 i 3.3), d'on surt la frase literal sobre l'ordre primari-secundaris, el comportament davant fallada al primari o a un secundari, el reinici de cada node en acabar la seva instal·lació i el requisit de deixar sense marcar la casella d'auto-failover del PAN. Que la documentació no promet la no-solapació de reinicis entre secundaris és una lectura nostra del que aquestes guies no diuen, i va dita com a tal. Quatre: l'article de suport de Cisco «Understand AAA Dead Detection and Deadtime on IOS XE» i la referència d'ordres de radius-server deadtime, d'on surten el valor per defecte 0, les dues citacions literals sobre el retorn immediat a l'estat UP i el flapeig, els dos criteris de marcatge com a mort, i el comportament d'automate-tester amb i sense probe-on. Cinc: les guies de configuració de seguretat dels Catalyst (9300 i 1000): la descripció de l'inaccessible authentication bypass com a autenticació crítica o política de fallada d'AAA, el comportament a la VLAN crítica per a un port no autoritzat i l'advertiment que en la reautenticació d'un port ja autoritzat s'usa la VLAN actual, la reinicialització de hosts en tornar el servidor, la frase sobre què passa sense la funció —el client falla indefinidament i el port queda en bloqueig d'spanning tree—, la taula de configuració per defecte de 802.1X amb «Inaccessible authentication bypass: Disabled» i la reautenticació periòdica deshabilitada, i la secció sobre ports ja autenticats, que romanen autenticats sense requerir comunicació amb el servidor RADIUS. L'existència d'authentication open com a mode de desplegament és funció documentada de Cisco; que una part incòmoda dels desplegaments s'hi quedi és observació nostra, no una dada mesurada. També és opinió nostra, i va dita com a tal, que un NAC no és Zero Trust i que la finestra de manteniment és la part barata del problema. No sabem com s'està explotant aquesta fallada i no ho afirmem.