Af Jan Frank Nielsen, Systems Engineer, Conscia
I dag er det næsten en selvfølge, at man implementerer 802.1x i sit netværk, ofte på trådløst netværk og i stigende grad også på det kablede netværk. I den forbindelse vil man skulle tage stilling til, hvad kravene for at kunne komme på netværket skal være, hvor granuleret dette skal være og, hvordan man teknisk set vil håndtere det.
Et udsnit af ønsker Conscia ofte møder er:
- Der skal være styr på, at vores brugere kun kan komme på netværket fra en PC – vi har fuld kontrol over det, vi kunne kalde et ”corporate device”.
- Vi vil samtidig godt kunne skelne mellem et corporate device og f.eks et privat device, såsom en mobiltelefon, vi kan kalde det et ”non-corporate device”.
- Vi vil gerne bruge denne information til at give forskellige rettigheder til corporate og non-corporate devices, f.eks forskellig VLAN-tildeling eller endnu bedre forskellige Scalable Group Tags.
- Vi vil også gerne vil kunne granulere adgangen for vores brugere på et corporate device afhængig af deres AD-gruppemedlemskab.
Når disse ønsker skal opfyldes, har der, med Cisco Identity Service Engine som Radius Server, reelt kun været to muligheder, der opfylder alle kravene. Dette på mere eller mindre sikkerhedsmæssigt forsvarlige måder:
- Machine Access Restriction (MAR)
- AnyConnect EAP-Chaining med EAP-FASTv2
MAR – Simpelt, men ikke særlig sikkert
MAR fungerer ved, at ISE cacher information om et maskin-login identificeret på den MAC-adresse, som maskinen benyttede ved login. Herved kan et givent bruger-login fra den samme MAC-adresse angives til at komme fra en maskine, der også er valideret. I praksis er denne ”validering” altså kun en MAC-adresse-validering så længe, at MAR cachen stadig indeholder MAC-adressen.
Fordele:
- Virker på standard Windows 802.1x supplikant, ingen ekstra agenter installeres
- Simpelt at konfigurere, kræver ingen speciel supplikant config
Ulemper:
- Her er ingen sikker binding mellem bruger og maskine. Maskinen behøver kun at validere én gang, herefter er spoofing af MAC, det eneste der skal til for at blive betragtet som en godkendt maskine.
- Har problemer med skifte mellem kablet og trådløs, da MAC-adressen skifter.
- Har udfordringer med cache timeout, som normalt løses ved højere cache-levetid, hvilket igen gør løsningen endnu mere usikker.
- Indtil for nylig virkede MAR heller ikke, hvis det var to forskellige ISE-servere, der validerede brugeren, da MAR cache var lokal på den specifikke ISE-server (dette er dog ”fikset”).
AnyConnect EAP-Chaining – Cisco AnyConnect only, men mere sikkert end MAR
AnyConnect EAP-Chaining benytter en proprietær metode kaldet EAP-FASTv2, som er opfundet af Cisco, og som kun virker på Network Access Manager (NAM) plug-in til Cisco AnyConnect-klienten. EAP-Chaining validerer både bruger og maskine hver gang, der forbindes til netværket, og kan altså ikke snydes ved blot at spoofe en MAC-adresse. EAP-Chaining kan valgfrit bruge ens eller forskellige authentication-metoder til bruger og maskine, således kan brugervalidering f.eks foregå med PEAP-MSCHAPv2 og maskin-validering f.eks med EAP-TLS.
Fordele:
- Sørger for en sikker binding imellem bruger og maskine
- AnyConnect er generelt en rigtig god supplikant med mange features
- Plugin til AnyConnect, som ofte er benyttet til VPN i forvejen
- Relativt nemt at konfigurere
Ulemper:
- Kræver en ny agent (AnyConnect)
- Opdatering af AnyConnect VPN kræver også opdatering af NAM plugin
- Virker ikke sammen med Hyper-V med en External switch defineret
- Support på eventuelle fejl kan risikere at falde mellem to stole (Microsoft, Cisco)
- Konfigureres med separat værktøj og XML config-filer, ikke via GPO’er
Efter sådan en lang introduktion, så kom dog til sagen, hvad er det nye smarte?
Microsoft har nu langt om længe implementeret support for den standardiserede udgave af EAP-FASTv2, kaldet EAP-TEAP (RFC7170), dette betyder nu at vi kan opnå den samme sikkerhed for bindingen mellem bruger og maskine med den indbyggede supplikant i Windows 10 (fra 20H1). TEAP er supporteret i ISE fra version 2.7. Det betyder, at vi undgår ulemperne i MAR og AnyConnect NAM-løsningerne og får stort set alle fordelene:
- Native Microsoft supplikant, så ingen ekstra agent nødvendig
- Styres ligesom i dag via GPO, helt standard
- ISE-konfigurationen er meget lig det, der skal gøres for EAP Chaining med AnyConnect NAM
- Sikker metode til binding mellem bruger og maskine
- Anvender standardiserede metoder via RFC 7170 compliance
Fordelene ved dette er langt større end ulemperne, og ulemperne er i stor udstrækning, at det er nyt og ikke testet i større omfang, dvs. disse ulemper forsvinder med stor sandsynlighed af sig selv med tid.
Så for at opsummere, hvad er ulemperne så lige nu?
- TEAP er en ny feature, altså ikke testet i stor stil hverken i Windows 10 eller ISE
- Kræver ISE 2.7, som også er ret nyt og ikke recommended release endnu, forvent at dette sker omkring sommerferien
- Cisco har p.t ingen planer for TEAP-support i ISE 2.4/2.6
Skulle du være interesseret i at høre mere, eller godt vil i gang med at teste denne nye funktionalitet, så kontakt din yndlingssikkerhedskonsulent.