ANBEFALT SIKKERHETSLØSNING FOR IEEE 802.IX I KABLET NETTVERK. UNINETT Fagspesifikasjon. UFS nr: 133 Versjon: 1.0

Transkript

1 UNINETT Fagspesifikasjon ANBEFALT SIKKERHETSLØSNING FOR IEEE 802.IX I KABLET NETTVERK UFS nr: 133 Versjon: 1.0 Status: Godkjent Dato: Arbeidsgruppe: Nettarkitektur Forfattere: Øystein Gyland, Tom Myren, Rune Sydskjør, Gunnar Bøe Ansvarlig: UNINETT Kategori: Anbefaling

2 Innholdsfortegnelse 1 Bakgrunn Introduksjon Elementene i IEEE 802.1X Sertifikatautentisering av RADIUS-tjener Brukerautentisering Maskinautentisering RADIUS Feilsøking: Nettverksoppsett Cisco-svitsjer Feilsøking Cisco-svitsj: HP-svitsjer Feilsøking HP-svitsj: Klientspesifikke elementer Windows Mac Linux Maskiner uten støtte for IEEE 802.1X Alternativer til IEEE 802.1X Referanser Definisjoner Intellektuelt eierskap Forfatternes adresser

3 1 Bakgrunn Sikring av kablet nett hvor den fysiske tilgangen til porter ikke er begrenset, er ressurskrevende og IEEE 802.1X er den mest elegante løsningen fra et sikkerhetsmessig perspektiv. IEEE 802.1X er en lag 2-protokoll hvor porten er sperret for annen type trafikk inntil den tilkoblede brukeren/maskinen er autentisert. Svitsjen vil videresende EAPoL-trafikk mellom supplikanten (maskinen) og RADIUStjeneren. 2 Introduksjon Dette dokumentet gir en orientering om oppsett av IEEE 802.1X i kablet nett. Anbefalingen er generisk, men oppskrifter på leverandørspesifikke oppsett av noen svitsjer er inkludert. Generelt oppsett av svitsjer finnes i [UFS 105] («Anbefalt konfigurasjon for svitsjer i campusnett»). Vi beskriver bruk av IEEE 802.1X i svitsjede kablede nettverk. Grunnen til at man ønsker å bruke 802.1X-autentisering er å ha kontroll på hvilke maskiner og hvilke brukere som kopler seg til nettet. Dette har vært brukt i lengre tid på trådløse nett, og utdypende informasjon om oppsett av RADIUStjener og hvordan IEEE 802.1X fungerer finnes i [UFS 112] («Anbefalt sikkerhetsløsning for trådløse nettverk»). På kablet nett har dette vært brukt i mindre grad, men med økt fokus på sikkerhet og nye trusler ønsker man å ha bedre kontroll. Flere institusjoner har i lengre tid brukt IEEE 802.1Xautentisering på kablet nett. [UFS122] «Anbefalt sikkerhetsarkitektur for UH-sektoren» med sin bruk av soner gir anbefalinger om hvor man bør bruke IEEE 802.1X-autentisering. I tillegg er IEEE 802.1X veldig fleksibel med mulighet for å gjøre dynamisk VLAN-tildeling, klientsjekk og enkel bruk av karantenenett. 3

4 3 Elementene i IEEE 802.1X I IEEE 802.1X er 3 parter involvert i en autentiseringsprosess; supplikant (på klienten), autentikator (svitsjen) og autentiseringstjener (RADIUS). I tillegg ligger som regel brukerdatabasen i en katalogtjener (LDAP/AD/SQL) som RADIUS gjør oppslag mot. Dersom man allerede har eduroam (802.1X på trådløse nett) kan RADIUS- og katalogtjenere gjenbrukes. Ved tilkobling til en IEEE 802.1X aktivert svitsj vil denne (dersom klient er satt opp for 802.1X) videresende EAPol-trafikken til RADIUS-tjener. Dersom en klient uten 802.1X-oppsett eller funksjonalitet kobles til, er det konfigurasjon av svitsj som avgjør hvilken tilgang en slik klient får. Dette kan være en stengt port, eller som anbefalt plassering i et VLAN med begrenset tilgang. En slik begrensning kan gjøres ved hjelp av aksesslister eller brannmur, og kan variere etter hva man finner hensiktsmessig for eksempel kan det gis kun internett-tilgang eller kun adgang til enkelte deler av internt nett. IEEE 802.1X er basert på gjensidig autentisering mellom klient og RADIUS-tjener. Klient kan autentisere seg med brukernavn og passord eller sertifikat, RADIUS-tjener må autentiseres med sertifikat. Det er likevel mulig å benytte 802.1X uten at klienten sjekker serversertifikatets gyldighet eller navn i sertifikatet, dette er ikke en anbefalt løsning. Se beskrivelser av RADIUS-tjener og klientautentisering under. 3.1 Sertifikatautentisering av RADIUS-tjener Hensikten med dette er at klienten skal kunne stole på at den snakker med korrekt RADIUS-tjener. Autentisering initieres av enten supplikant eller autentikator i det klienten kobler seg til nettverket. Det medfører at RADIUS-tjener sender sitt sertifikat til supplikant via autentikator før bruker/maskin autentisering skjer. Klienten må på forhånd ha installert det offentlige sertifikatet til den «certification authority» (CA) som har utstedt og signert RADIUS-tjenerens sertifikat. Dette kan distribueres via epost, webside eller et management system (f.eks. AD). Klienten sjekker gyldighet av RADIUStjenerens sertifikat ved hjelp av CA-sertifikatet. Siden CA-sertifikater som oftest er forhåndsinstallert på mange klienter, bør klienten også sjekke navn i serversertifikatet. Dette for å redusere muligheten for phishing, en mulighet som er mindre ved bruk av egen lokal CA enn ved å bruke sertifikater fra en større CA. 4

5 3.2 Brukerautentisering Dette kan gjøres med ett av følgende alternativer: - Personlig sertifikat (EAP-TLS). - Brukernavn og passord. (EAP-TTLS eller EAP-PEAP med MSCHAPv2 er anbefalt). Autentisering er her nøyaktig lik den autentisering som gjøres ved tilkobling til eduroam (802.1X i trådløsenett). Se [UFS 112] «Anbefalt sikkerhetsløsning for trådløse nett». Brukerautentisering kan i motsetning til maskinautentisering, benyttes for privateide maskiner og andre maskiner hvor man ikke ønsker at maskinen skal være meldt inn i et sentralt driftsopplegg. Brukerautentisering kan gjøres mot samme RADIUS-tjener som maskinautentisering. Her kan det være en utfordring med konfigurasjon av maskinen, dersom bruker selv må sette opp 802.1X på egen maskin. Eksempler på konfigurasjon av de mest vanlige klienter for brukerautentisering finnes i dette dokumentet. 3.3 Maskinautentisering Maskinautentisering er oftest brukt for Windows-maskiner som er innmeldt i AD, men kan også benyttes for Mac og Linux klienter. Også for maskinautentisering benyttes enten EAP-TLS (maskinsertifikat) eller EAP-PEAP med MSCHAPv2 (maskinens AD-navn og passord). Om man velger å benytte EAP-TLS, kan sertifikat tildeles maskinen ved innmelding i domene (autoenrollment). Konfigurasjonen kan ordnes ved installasjon slik at maskinen er klar for IEEE 802.1X uten at brukeren trenger å konfigurere noe senere. Maskiner som er innmeldt i AD kan motta oppdateringer/fjernadministreres som vanlig, selv om bruker ikke er innlogget. Bruker kan logge inn lokalt på maskinen på samme måte som uten 802.1X. For windows er det mulig å benytte maskinautentisering og/eller brukerautentisering. Dette skal gi en mulighet for å tildele forskjellige VLAN avhengig av hvilke autentisering som er gjort. Det er rapportert om problemer knyttet til dette og funksjonaliteten er foreløpig ikke testet hos UNINETT. Maskinautentisering, som gir enklere driftsadministrasjon, er anbefalt løsning i kombinasjon med brukerautentisering. Mer informasjon om oppsett av policy med Windows NPS for maskinautentisering er tilgjengelig hos Microsoft Technet [TECHNET]. 5

6 4 RADIUS Alle moderne RADIUS-tjenere (de mest brukte i UH sektoren er FreeRADIUS og forskjellige Windowsvarianter) har støtte for IEEE 802.1X. Dersom «eduroam» allerede er i drift, kan samme infrastruktur gjenbrukes. Med RADIUS gjøres bl.a.: Dynamisk VLAN-tildeling. Tilkobling mot AD/LDAP/lokal brukerdatabase, etc. RADIUS-proxy med hierarki-løsninger à la eduroam. Har man allerede etablert eduroam, anbefales bruk av samme RADIUS-tjener med en tilleggskonfigurasjon slik at forskjellige brukergrupper tildeles adresser i egne VLAN (kablet ansatt, student, etc). Radiusserveren kan skille kablede klienter fra eduroam-klienter ved å identifisere svitsjen eller trådløskontrolleren som forespørselen kom fra ved å se på NAS-Identifier eller NAS-IP-Address attributtene. For best mulig oppetid anbefales en redundant RADIUS og bruker database løsning, og når det er mulig sørge for site redundans. 4.1 Feilsøking: På FreeRADIUS: radiusd -X gir store mengder informasjon og er således uegnet i et produksjonsmiljø. Accounting-loggene kan inneholde nyttig informasjon. Man kan bruke en Linux-maskin som autentikator (se fig 1): eapol_test er et program som følger med wpa_supplicant og dette snakker direkte med radius-tjeneren. Eapol_test gir store mengder informasjon og er et bra verktøy for testing og feilsøking. På Linux-klient: wpa_supplicant dd, gir mye nyttig debug informasjon. 6

7 5 Nettverksoppsett «Alle» moderne svitsjer støtter IEEE 802.1X, men funksjonaliteten varierer. Flere enheter bak samme svitsjeport (liten svitsj uten 802.1X støtte eller PC koblet til SIP telefon på kontorer) kan være en utfordring i kombinasjon med 802.1X. Løsninger for dette ikke tatt med i denne anbefalingen. 5.1 Cisco-svitsjer Cisco IOS endret syntax for oppsett av IEEE 802.1X i versjon For tidligere versjoner se dokumentasjon fra Cisco. Her er et eksempel på minimumskonfigurasjon: (Forutsetter IOS >= ) Globalt: aaa new-model aaa group server radius radius-dot1x-group! server-private <host> auth-port 1812 acct-port 1813 key <key> aaa authentication dot1x default group radius-dot1x-group dot1x system-auth-control aaa authorization network default group radius-dot1x-group (for dynamisk VLANtildeling) Per interface: switchport mode access switchport access vlan XX (dersom man ikke bruker dynamisk VLAN-tildeling) authentication port-control auto dot1x pae authenticator Ekstra konfigurasjon for å gi gjestenett for maskiner uten dot1x og eventuelt ved feil: Globalt: dot1x guest-vlan supplicant 7

8 Per interface: authentication event fail action authorize vlan <vlan-nr> authentication event server dead action authorize vlan <vlan-nr> authentication event no-response action authorize vlan <vlan-nr> authentication event server alive action reinitialize Dersom man ikke skal autentisere seg, eller autentisering feiler kan det ta lang tid før svitsjen godtar å gi deg nett. Default verdier er gjerne satt høyt. Da kan det være fornuftig å skru litt på timere for at prosessen skal bli gjennomført raskere. Her er eksempler på timeout-parametre man kan endre på: dot1x timeout quiet-period <sec> (default verdi 60) dot1x timeout tx-period <sec> (default verdi 60) dot1x timeout supp-timeout <sec> (default verdi 60) Det henvises til Ciscos websider for nærmere dokumentasjon av disse Feilsøking Cisco-svitsj: På svitsjsiden: «debug dot1x (events,all,packets)» Stort sett uegnet i et miljø hvor det er flere brukere tilkoblet grunnet den store mengden informasjon som printes og mangel på filtreringsmuligheter. Loggen bør isåfall leses på en loggtjener. «sh dot1x interface XX/YY detail» gir en liten oversikt over hvorvidt IEEE 802.1X-autentisering er påskrudd og status på autentiseringen (feilet, pågående etc). 5.2 HP-svitsjer Her er et eksempel på minimums-konfigurasjon: aaa authentication port-access eap-radius aaa accounting network start-stop radius radius-server host <ip-addr> key <key> Gir støtte for dynamisk tildelt VLAN: 8

9 aaa port-access gvrp-vlans Angir hvilke porter som skal ha dot1x-autentisering: aaa port-access authenticator <port-range> aaa port-access authenticator <port-range> auth-vid <vlan-nr> aaa port-access authenticator <port-range> unauth-vid <vlan-nr> aaa port-access authenticator <port-range> logoff-period 60 aaa port-access authenticator active Feilsøking HP-svitsj: show port-access authenticator clients gir status for autentiseringen for portene. debug security port-access authenticator 9

10 6 Klientspesifikke elementer Innebygget IEEE 802.1X-klientstøtte finnes i moderne operativsystem. Anbefalt løsning for alle typer klienter er distribusjon av klientoppsett (profil) fra et sentralt management system, der AD er en av flere muligheter. I teksten under forklarer vi hvordan en 802.1Xprofil kan settes opp på de mest vanlige klientene. Noen mulige utfordringer bør likevel nevnes: Flere operativsystemer med tildels forskjellig oppsett. o o o Apple: 10.5 (Leopard), 10.6 (SL), 10.7 (Lion), 10.8 (ML) har alle forskjellige oppsett. Windows: XP, Vista, Windows 7, Windows 8 har også forskjellig oppsett. Vi anbefaler ikke bruk av 802.1X på versjoner tidligere enn Windows 7. Linux/FreeBSD har flere ulike supplikanter. Innføring av IEEE 802.1X krever kompetanse på flere plattformer hos brukerstøtte. 6.1 Windows Vi anbefaler IEEE 802.1X-autentisering kun på Windows 7 eller nyere. Her følger et eksempel på Windows 7 manuelt oppsett av klient. Merk at dette gjøres best via autoenrollment fra AD, uten at bruker må involveres. Start «Services», og under egenskaper for «Wired AutoConfig» sett Startup Type til «Automatic». Start deretter tjenesten. Se figuren under: 10

11 Gå deretter til Control Panel Network and sharing center Change adapter settings. Høyre klikk på den aktuelle Local Area Connection og velg Properties. Gå deretter til «Authentication» fanen som har kommet etter at Wired AutoConfig ble startet. Her aktiveres 802.1X. Autentisering settes til «Smart Card or other certificate» (TLS), eventuelt PEAP. Under Settings velges deretter sertifikat (maskinautentisering) samt validering av serversertifikat. Merk at et klientmaskinsertifikat er påkrevet for at dette skal fungere som beskrevet under maskinautentisering. I eksempelet over er det vist at autentisering gjøres mot samme RADIUSserver som eduroam-klienter (eduroam.uninett.no). Under «Additional Settings» kan man videre spesifisere 802.1X autentiseringen: 11

12 Her gis en mulighet for å kombinere maskin- og brukerautentisering. Tar autentiseringen så lang tid at DHCP-forespørselen blir tidsavbrutt, så blir maskinen stående med en /16 (ikke-rutbar «link-local» adresse), selv om autentiseringen var vellykket. Maskinen vil etterhvert få tildelt IP-adresse når den sender en ny DHCP-forespørsel. For å restarte autentisering så er det enkleste å ta nettverkskabelen inn og ut. Dersom man ønsker å sette opp 802.1X-autentisering på eldre Windows-klienter, se nærmere informasjon hos Microsoft [MS-VISTA]. 12

13 6.2 Mac Fra og med Mac OS X 10.7 Lion og nyere endret Apple mulighetene for å definere 802.1Xautentisering lokalt på maskinen X-fanen finnes fortsatt under nettverksoppsett, men gir kun mulighet for å se 802.1X-profiler eller velge mellom dem hvis flere finnes. Man kan fremdeles koble til 802.1X-nettverk manuelt. Ved første gangs tilkobling vil en 802.1X-aktivert port vil bruker bli spurt om å akseptere RADIUS-serverens sertifikat og dermed lagre dette. En åpenbar svakhet er at bruker altfor enkelt kan akseptere en ikke gyldig server. Deretter blir bruker spurt om brukernavn og passord, og profilen blir opprettet på maskinen. Dette er ikke en anbefalt metode. Det er også mulig å bruke ipcu (iphone Config Utility) til å lage profil som distribueres til brukere. En profil kan defineres pr bruker eller bruker grupper. Det er viktig å spesifisere RADIUS-serverens CA-sertifikat (det legges ved profilen), Trusted Server Certificate-navn og ikke huke av for «Allow Trust Exception». Profilen opprettes i form av en.mobilconfig fil (xmlformat), som kjøres på klienten. ipcu er tilgjengelig fra Apple for både Win og Mac, se [APPLE]. 13

14 6.3 Linux Her følger et eksempel på oppsett av Linux-klient med bruk av Network Manager: 6.4 Maskiner uten støtte for IEEE 802.1X Man kan sette opp gjestevlan på svitsj for enheter som ikke støtter IEEE 802.1X. Altså fallback til et VLAN med noe begrenset konnektivitet. Dette anbefales som et standard oppsett. Se forøvrig konfigurasjon av de forskjellige svitsjer. 14

15 7 Alternativer til IEEE 802.1X Det finnes alternativer til å bruke 802.1X i et kablet nett, men de har flere svakheter. Disse er de mest aktuelle alternativene: MAC-adresselister - Kun klienter med godkjent, registrert MAC adresse kan koble seg på nettet. Svært tungt å vedlikeholde og gir ingen sikkerhetsmessig gevinst da en MAC-adresse er lett å finne og lett å forfalske. Port security Med port-security kan man begrense antall MAC adresser per port. MAC adressene kan læres automatisk eller settes statisk. Dette gir ingen verifikasjon av hver maskin, men normalt vil kun foretakets maskiner tillates så lenge antallet MAC adresser er begrenset. De samme innvendinger som for MAC-adresselister gjelder. Web-portaler - Metoden er mye brukt for offentlig tilgjengelige nettverk. Før pålogging er det sperret for alle tjenester, og brukeren omdirigeres til en webside for pålogging. Autentisering kan beskyttes med kommunikasjon over TLS. Det gjøres en gjensidig autentisering av system og klient gjennom TLS, men i praksis er det for enkelt for brukeren å overse varsler om feil i sertifikatet, eller at det i det hele tatt blir brukt TLS. Dette gjør det enkelt for en angriper å sette opp en falsk web-portal. Denne løsningen fungerer for offentlig / gjeste aksess nettverk, men er ikke brukervennlig for daglig bruk. VLAN - VLAN i seg selv gir ingen autentisering av klient, men sørger i det minste for en adskillelse av ulike nett. Ingen sikkerhet. Konklusjon: Det er kun IEEE 802.1X autentisering som gir tilstrekkelig sikkerhet når man ønsker å ha kontroll på hvilke klienter og brukere man har på nettet. 15

16 Referanser Relevante UNINETT fagspesifikasjoner (UFS) [UFS105] [UFS109] [UFS112] [UFS122] [UFS127] «Anbefalt konfigurasjon for svitsjer i campusnett» «Oppskrift for konfigurasjon av Cisco IOS svitsjer i campusnett» «Anbefalt sikkerhetsløsning for trådløse nettverk» «Anbefalt sikkerhetsarkitektur for UH-sektoren» «Guide to configuring eduroam using a Cisco wireless controller» Alle UNINETT fagspesifikasjoner er tilgjengelige fra Øvrige referanser [TECHNET] [MS-VISTA] [APPLE] [RAD-DB] [RAD-AD] Best Practice Document on FreeRADIUS Database Connection Freeradius integrasjon med AD 16

17 Definisjoner AD CA CLI DHCP EAP EAPoL EAP-PEAP EAP-TLS EAP-TTLS IEEE 802.1X ipcu LDAP MAC MSCHAP NAS ID NPS PAE: RADIUS: SQL UH-sektor XML Active Directory Certificate Authority Command Line Interface Dynamic Host Configuration Protocol Extensible Authentication Protocol Extensible Authentication Protocol over LAN EAP - Protected Extensible Authentication Protocol EAP - Transport Layer Security EAP - Tunnelled Transport Layer Security Autentiseringsmekanisme for kablet og trådløst nett. iphone Config Utility Lightweight Directory Access Protocol Media access control Microsoft Challenge-Handshake Authentication Protocol Network Access Server IDentifier Network Policy Server Port Access Entity Remote Authentication Dial In User Service. Protokoll for autentisering, autorisering og «accounting». Brukes mellom svitsjen og RADIUS-tjeneren. Structured Query Language Universitet og Høyskole sektor Extensible Markup Language 17

18 Intellektuelt eierskap UNINETT står ansvarlig for innholdet i dette dokument. Arbeidet er utført som et samarbeidsprosjekt i UH-sektoren. Forfatternes adresser Gunnar Bøe UNINETT Abels gt 5 - Teknobyen 7465 Trondheim Norway Telefon: Epost : gunnar.boe@uninett.no Rune Sydskjør UNINETT Abels gt 5 - Teknobyen 7465 Trondheim Norway Telefon: Epost : rune.sydskjor@uninett.no Tom Ivar Myren UNINETT Abels gt 5 - Teknobyen 7465 Trondheim Norway Telefon: Epost : tom.myren@uninett.no Øystein Gyland Universitetet i Oslo Boks 1072 Blindern 0316 Oslo Norway Telefon: Epost : oystegy@usit.uio.no 18

19

20 Ved spørsmål omkring denne eller andre UFSer kontakt Andre UFSer er tilgjengelige på