ufs112: anbefalt sikkerhetsløsning for trådløse nettverk

ANBEFALT SIKKERHETSLØSNING FOR TRÅDLØSE NETTVERK

UNINETT Fagspesifikasjon

UFS nr.: 112Versjon: 1Status: GodkjentDato: 20. 12. 2007 Tittel: IEEE 802.IX for trådløse nettverkArbeidsgruppe: Mobilitet Forfatter: Jardar LeiraAnsvarlig: Jardar LeiraKategori: AnbefalingUgyldiggjøring:

IMPLEMENTASJON AV IEEE 802.IX

FAGSPESIFIKASJON FRA UNINETT – UTKAST

2

Sammendrag Dette dokumentet gir en orientering om de ulike sikkerhetsmekanismene som er tilgjengelig for trådløse nettverk. Det beskrives kort svakhetene ved bruk av MAC-adressefilter, WEP, Web-portaler og VPN og anbefaler 802.1X basert gjensidig autentisering som beste alternativ. EAP ved bruk av TLS, PEAP og TTLS er anbefalte alternativer som også kan støttes samtidig av systemet. Standarden IEEE 802.11i og bedre kjent som WPA og WPA2 med henholdsvis TKIP og AES kryptering. AES kryptering er det foretrukne men TKIP er et kompromiss ved manglende AES støtte hos klientene. Sertifikatgenerering kan være komplisert å sette seg inn i men dokumentet inneholder script som kan forenkle prosessen. eduroam er et internasjonalt RADIUS-hierarki hos akademiske institusjoner som gjør at brukere kan logge seg på trådløsnettet hos andre medlemsinstitusjoner med sitt eget brukernavn og passord. Innhold 1. Definisjoner 2. Bakgrunn 3. IEEE 802.11i med IEEE 802.1X, TKIP og AES 3.1 802.11i og WPA/WPA2 3.2 Elementene i 802.1X 3.3 Sertifikater og brukerautentisering 3.4 Kryptering 4. Sertifikatgenerering på SAMSON3 (Linux) 4.1 Lage CA root-sertifikat og etablere sertifikathierarki 4.2 Lage serversertifikat 4.3 Lage klientsertifikat 4.4 Script for å generere sertifikat 5. Kjøp av sertifikat fra UNINETT SCS 6. Konfigurasjon av FreeRADIUS på SAMSON3 (Linux) 7. Konfigurasjon av basestasjon/kontroller 8. Konfigurasjon av klient 9. Dynamisk tildeling av VLAN 10. eduroam 11. Oppsummering og anbefaling 12. Referanser 13. Intellektuelt eierskap 14. Forfatters adresse


3

1. Definisjoner AES: Advanced Encryption Standard, en svært sikker krypteringsalgoritme. CA: Certificate Authority er en entitet som utsteder sertifikater som andre parter kan bruke. CA er en pålitelig tredjepart som alle partene skal kunne bruke for å verifisere hverandre. BSSID: Basic Service Set ID, MAC adressen til en trådløs basestasjon. EAP: Extensible Authentication Protocol, protokoll som frakter autentiseringsprotokollen i et 802.1X sikret nettverk. EAPOL: EAP over LAN, EAP protokollen som går på lag 2 på nettverket. IEEE: Institute of Electrical and Electronics Engineers, organisasjon som utarbeider standarder for bl.a. datakommunikasjon. IEEE 802.11: Den første standarden for trådløst nettverk slik vi er vant med i dag. Baserte seg på bruk av frekvenser på 2.4GHz men definerte to ulike transmisjonsteknikker: Frequency Hopping Spread Spectrum (FHSS) og Direct Sequence Spread Spectrum (DSSS). Begge hadde overføringshastighetene 1Mbps og 2Mbps. I tillegg var det også definert bruk av IR men det ble aldri implementert for markedet. IEEE 802.11 DSSS har vært basisen for IEEE 802.11b. DSSS definerte kanalene 1 til 11 (USA), 1 til 13 (Europa) og 1 til 14 (Japan) for 2.4Ghz frekvensene. En del av disse kanalene overlapper. IEEE 802.11i: Standard for bruk av 802.1X og TKIP eller AES kryptering i trådløse nettverk. IEEE 802.1X: Standard for portbasert autentisering ved hjelp av protokollen EAP. En port kan være en fysisk nettverkskontakt i en switch eller en virtuell kobling mellom en assosiert klient og en basestasjon. MAC: Media Access Control, en unik adresse alle nettverksenheter må ha PKI: Public Key Infrastructure, et hierarkisk system der man har en CA og underliggende server og brukersertifikat. Hvert sertifikat er unikt og kan verifiseres av CA. RADIUS: Navn på en protokoll som benyttes av en RADIUS server. En RADIUS server er en autentiseringsserver. SAMSON3: UNINETT standard linux servermaskin for e-mail, DNS, web server, RADIUS, m.m. SCS: Server Certificate Service SSID: Service Set ID, identifiserer et spesifikt trådløsnett. Flere basestasjoner kan ha samme SSID for å ta del i et større nettverk.


4

SSL: Secure Sockets Layer, kryptert kommunikasjonskanal. TKIP: Temporal Key Integrity Protocol, en RC4 kryptering som er en forbedring av WEP. Trådløst nettverk: Et "trådløst nettverk" er i utgangspunktet lite spesifikt og kan omfatte mange ulike typer teknologi. Dette dokumentet definerer trådløse nettverk som gjengitt i standardene IEEE 802.11, IEEE 802.11b, IEEE 802.11g, IEEE 802.11a og IEEE 802.11n. VPN: Virtual Private Network, kryptert kommunikasjonskanal WEP: Wired Equivalent Privacy, trådløs kryptering definert i IEEE 802.11. Wi-Fi Alliance: Interesseorganisasjon med omtrent alle produsenter av trådløst utstyr som medlemmer. Utarbeider testkriterier og sertifiserer produkter som møter disse kriteriene. Tanken er en trygghet for forbrukeren som skal kunne stole på at produktet han kjøper virker med produkter fra andre leverandører. WPA: Wi-Fi Protected Access. Sertifisering av utstyr som møter Wi-Fi Alliance sine krav om funksjonalitet i henhold til IEEE 802.11i standarden. Dvs. støtte TKIP kryptering. WPA2: Wi-Fi Protected Access 2. Sertifisering av utstyr som møter Wi-Fi Alliance sine krav om funksjonalitet i henhold til IEEE 802.11i standarden. Dvs. støtte AES kryptering.


5

2. Bakgrunn Trådløse nettverk er i utgangspunktet langt mindre sikkert enn et kablet nettverk. Utgangspunktet for det argumentet er at trådløse nettverk er basert på bruk av radiobølger og dermed kringkaster alle de data som blir overført mellom klienter og basestasjoner. Følgelig kan noen innen rekkevidde lytte til all kommunikasjon. Med en ekstra kraftig antenne kan også rekkevidden for denne avlyttingen utvides betraktelig. Mangelen på kabel mellom klienten og tilkoblingspunktet kan også være et sikkerhetsproblem da en basestasjons identitet (SSID og BSSID) enkelt kan forfalskes da de ikke er ment å være brukt som sikkerhetstiltak. Klienten kan derfor ikke stole på at den basestasjonen en er tilkoblet er den ekte, med de følger det kan få for videre datakommunikasjon. På den andre siden kan heller ikke basestasjonen stole på at klienten er en gyldig bruker fordi det eneste som trengs fra klientens side er korrekt SSID. Oppsummert kan vi si at trådløse nettverk har to sikkerhetsmessige utfordringer: 1 - Sikker, gjensidig autentisering av basestasjon og klient 2 - Datakommunikasjon sikret mot avlyttning og forfalskning Med dette som bakgrunn har vi fått se flere ulike metoder for å gjøre trådløse nett sikrere.

• MAC adresselister - Kun klienter med godkjent, registrert MAC adresse får assosiere seg til basestasjonene. Svært tungt å vedlikeholde og gir ingen sikkerhetsmessig gevinst da en MAC adresse er lett å finne og lett å forfalske. Det gir heller ingen kryptering av datakommunikasjonen.

• WEP kryptering - Finnes med ulike krypteringsgrader (RC4). En felles, delt hemmelighet må være kjent for å få assosiert seg til basestasjonen og sørger samtidig for kryptering av datakommunikasjonen. WEP har flere svakheter og kan i dag knekkes på under ett minutt ved hjelp av programvare lett tilgjengelig på Internet. En delt hemmelighet skalerer dårlig og all datakommunikasjon blir kryptert likt slik at om man kjenner nøkkelen så kan man lytte til all datakommunikasjon.

• Web-portaler - Klienten kobler seg til et ukryptert og åpent trådløst nett. Når brukeren prøver å bruke sin webleser til å aksessere en ekstern side, blir forespørselen omdirigert til en web-basert innloggingsside for nettverket. Siden er som regel beskyttet med kommunikasjon over SSL. Dette er en brukervennlig løsning som er mye brukt i såkalte "hot-spots" og offentlig tilgjengelige trådløsnett. Det er en gjensidig autentisering av system og klient gjennom SSL men i praksis er det for enkelt for brukeren å overse varsler om feil i sertifikatet eller at det i det hele tatt blir brukt SSL. Siden det ikke er noen verifisering av tilkoblingspunktet (basestasjonen) så er denne løsningen svært utsatt for Man-in-the-Middle og Phishing. Datakommunikasjon blir heller ikke kryptert. Man bør generelt være svært aktsom som bruker av slike systemer.

• VPN – Man definerer et ellers helt åpent trådløst nett som "usikkert, eksternt nett" og så tillate kun trafikk mellom konsentrator og trådløse klienter. Klienter blir nødt til å autentisere seg mot VPN konsentratoren for å få opprettet en kryptert tunnel som når ut av trådløsnettet. Metoden gir høy sikkerhet med gjensidig autentisering og individuell kryptering av datakommunikasjonen. Men det stiller store krav til kapasitet hos konsentratoren da


6

alle trådløse brukere vil måtte bruke den. Klientprogramvaren kompliserer ytterligere og gir et stort behov for brukerstøtte, samt at det gjerne er begrenset tilgjengelighet for alle OS.

Kort tid etter at de trådløse brukerne i verden hadde blitt gjort kjent med at WEP var blitt knekt, kom det masse krav om at det måtte komme noe som sikret trådløse nettverk på en god og enkel måte. Da hadde IEEE allerede vært i god gang med å utvikle standarden 802.11i og med den skulle vi få noe som løste begge de to sikkerhetsmessige utfordringene.


7

3. IEEE 802.11i med IEEE 802.1X, TKIP og AES IEEE 802.11i er vår anbefalte sikkerhetsløsning for trådløse nett. Vi gjør her rede for denne standarden. 3.1 802.11i og WPA/WPA2 Med IEEE standarden 802.11i har vi fått en mulighet for å bruke IEEE 802.1X for autentisering også i trådløse nettverk. Mens 802.11i standarden var under utvikling, lanserte Wi-Fi Alliance noe de kalte WPA. Den benytter seg av 802.1X for autentisering og TKIP som kryptering. Da 802.11i ble ferdig, kom WPA2 som er 802.1X med AES som kryptering. "802.11i" er ikke så godt kjent av brukere som "WPA" og "WPA2" men man kan si at WPA og WPA2 er Wi-Fi Alliance sin sertifisering av produkter som har implementert 802.11i på en måte som gjør dem kompatible med andre WPA-sertifiserte produkter. At et produkt er WPA/WPA2 sertifisert skal være en trygghet for at brukeren har utstyr som vil fungere med utstyr fra andre produsenter. WPA og WPA2 finnes hver i to varianter, "Enterprise" og "PSK" (Pre-Shared Key). Enterprise benytter seg av 802.1X og er godt egnet for bedriftsnett mens PSK benytter seg av en delt hemmelighet på 64 heksadesimale tegn og er beregnet på hjemmeløsninger. PSK er i utgangspunktet en uegnet løsning for en akademisk institusjon, men siden svært mange også har en trådløs basestasjon hjemme så nevnes det litt om PSK i dette dokumentet som en sikkerhetsbetrakning. Selv om WPA med PSK er en signifikant forbedring fra WEP så er det viktig at man velger sitt passord/passfrase med omtanke slik at det ikke blir lett å gjette eller for kort. Det er ikke veldig brukervennlig å la brukeren fylle ut alle 64 heksadesimale tegnene selv. Derfor har produsentene implementert en algoritme som ekspanderer et passord/passfrase til 64 heksadesimale tegn. Dersom dette passordet/passfrasen blir under 20 tegn så har man i realiteten ikke oppnådd stort bedre sikkerhet enn om man brukte WEP. Det finnes tilgjengelig på nett programvare som kan knekke slike korte passord/passfraser fra WPA-PSK. Merk at i beskrivelsene i avsnittene under så vil det fokuseres på anbefalte eller mye brukte løsninger for å få optimal sikkerhet. Med som så mye annet så er det dessverre mulig å konfigurere også WPA/WPA2 på måter som gjør det langt mindre sikkert. 3.2 Elementene i 802.1X Kjernen i IEEE 802.11i er IEEE 802.1X. IEEE 802.1X gjør bruk av tre parter i en autentiseringsprosess: Supplicant (klienten), Authenticator (AP) og Authentication Server (RADIUS). Kommunikasjonen mellom disse går via en protokoll ved navn EAP (Extensible Authentication Protocol). Mellom Supplicant og Authenticator går EAP direkte på lag 2 (EAPOL - EAP over LAN) mens det mellom Authenticator og Authentication Server går over TCP/IP som en del av RADIUS-protokollen.


8

Klient Basestasjon RADIUS-tjenerSupplicant Authenticator Authentication server

Internett

EAPOL EAP i RADIUS

Autentiseringsprosessen initieres av enten Supplicant eller Authenticator i det klienten prøver å assosiere seg mot basestasjonen. Det er flere måter å gjøre det på, men ved gjensidig autentisering så vil Authentication Server først sende sitt sertifikat til Supplicant via Authenticator. Dersom Supplicant godtar denne, så vil den så følge opp med å oppgi sitt brukernavn/passord eller sertifikat, avhengig av hvilken metode som brukes. Dersom Authentication Server godtar dette svaret så vil den sende beskjed til Authenticator om dette som så vil åpne en trådløs "port" for Supplicant. Denne virtuelle porten er en sikret, trådløs tilknytning mellom Supplicant og Authenticator slik at klienten får fri tilgang til nettverket bak basestasjonen.

Klient Basestasjon RADIUS-tjenerSupplicant Authenticator Authentication server

EAPOL EAP i RADIUS

Forespørsel om identitet

Respons med identitet

Forespørsel med utfordring

Svar på utfordring

Godkjent eller Avvist

Respons med identitet

Forespørsel med utfordring

Svar på utfordring

Godkjent eller Avvist

EAPOL - Start

EAPOL - Avslutt


9

Figuren viser gangen i EAP-prosessen. Den initielle prosessen hvor RADIUS serveren først sender sin offentlige nøkkel er ikke tatt med i denne figuren men vil foregå før klienten blir spurt som sin identitet. EAP er konstruert for at man skal kunne benytte seg av en valgfri autentiseringsmekanisme.

TLS TTLS PEAP OTP

Extensible Authentication Protocol (EAP)

EAP Over LANs (EAPOL)

PPP 802.3 802.5 802.11

Autentiseringslag

EAP lag

MAC lag

Det finnes mange muligheter men det er få av dem som gir den gjensidige autentiseringen vi trenger på trådløse nettverk. Disse er TLS (Transport Layered Security), TTLS (Tunneled TLS) og PEAP (Protected EAP). Felles for alle er at Authentication Server må ha et serversertifikat. TLS benytter seg av klientsertifikat for alle brukere også mens for TTLS og PEAP, som er veldig like, benytter seg av brukernavn og passord. TTLS og PEAP bør da bruke MS-CHAPv2 for å pakke inn dette før det sendes til Authentication Server. Det er ingenting i veien for å tilby flere autentiseringsmekanismer samtidig. De fleste som kjører 802.1X for trådløse nettverk gir gjerne klienten valget mellom TLS, PEAP og TTLS. 3.3 Sertifikater og brukerautentisering Siden vi med disse metodene involverer sertifikater, må man ha etablert et minimum av PKI-løsning. Det vil si at man må enten benytte seg av en eksisterende CA (Certificate Authority) eller man må etablere sin egen. På en SAMSON3 (eller en annen Linux-maskin) så er dette rimelig trivielt (se eget avsnitt), det samme gjelder Microsoft IAS. Dersom man etablerer sin egen CA så koster ikke det noe og man kan generere så mange server- og brukersertifikater som man ønsker. Ulempen er at din egen CA i utgangspunktet vil være ukjent for alle dine brukere slik at de ikke vil være i stand til å sjekke ektheten til sertifikatet som kommer fra Authentication Server. For å gjøre det må alle klientene installere det offentlige sertifikatet til den lokale CA. Den kan trygt spres åpent gjennom f.eks. mail og web-sider men det er en ekstra operasjon i konfigurasjonen en bruker må få til rett. Alternativet er at man kjøper et serversertifikat fra en organisasjon som har fått preinstallert det offentlige sertifikatet til sin CA i operativsystemet til klienten. Her er det mange å velge mellom og mange ulike prismodeller. Hvorvidt det lønner seg økonomisk vil være en avveining mellom kostnad på brukersupport og kostnad på serversertifikatet. Det må også nevnes at det KAN være en sikkerhetsrisiko involvert ved å bruke sertifikater fra en større CA. De færreste klienter vil nemlig sjekke om sertifikatet tilhører en server


10

med rett navn men nøyer seg med å finne ut om sertifikatet er gyldig. Dermed kan man teoretisk få servert et gyldig sertifikat men fra en server som er satt opp for phishing. Risikoen for at dette skal skje blir foreløpig sett på som ganske liten. Når det gjelder identifikasjon av brukeren/klienten så kan man der også benytte seg av sertifikater. Hver bruker får sitt personlige sertifikat og maskiner kan få et maskinsertifikat. I dette scenariet vil brukere slippe å ha brukernavn og passord men til gjengjeld må organisasjonen ha et godt opplegg for PKI med sertifikathåndtering, noe som kan koste mye i form av både penger og administrative ressurser. Alternativet er brukernavn og passord. Denne metoden blir sett på som like sikker som sertifikater og har den ekstra fordelen at man kan knytte opp autentiseringen mot en eksisterende brukerdatabase. Det er imidlertid en forutsetning at brukerdatabasen kan sjekke med MD4-hashet passord da dette er formatet til passord over MS-CHAPv2. 3.4 Kryptering Man må merke seg at med 802.1X autentisering så er det kun autentiseringsprosessen som er kryptert. Etter at prosessen er ferdig så vil datakommunikasjonen kunne gå ukryptert. Ved at man bruker 802.1X så får man samtidig en mulighet for basestasjonene å på en sikker måte distribuere en unik per-bruker nøkkel som kan brukes til kryptering. Dette utnyttes i WPA ved å bruke TKIP kryptering og WPA2 med AES kryptering. Da får man en god og unik per-pakke kryptering av all datatrafikk. Det er mulig å konfigurere et 802.1X sikret trådløsnett til å ikke benytte seg av kryptering eller å bruke rullerende WEP-nøkler. Det er langt sikrere enn vanlig WEP dersom man har en hyppig rotasjon, men det er allikevel ikke anbefalt. TKIP er en RC4 kryptering som WEP men har noen kraftige forbedringer som gjør at den ikke har de samme svakhetene. Eldre trådløskort som støttet 128-bits WEP vil kunne firmware oppgraderes til å kjøre TKIP men dessverre er det flere produsenter som ikke har prioritert dette i eldre modeller. TKIP er ikke 100 % sikker og har noen svakheter men blir allikevel generelt sett på som meget sikkert så langt. AES er svært lik Rijndael, som er "originalen". AES har noen begrensninger på bl.a. nøkkelstørrelse. Den er brukt av statlige organisasjoner i USA og brukes for kryptering av materiale i graden SECRET, dvs. til TOP SECRET. Med andre ord så blir den ansett som svært sikker.


11

4. Sertifikatgenerering på SAMSON3 (Linux) Generering av sertifikater og bruk av sertifikater kan, som så mye annet, virke forvirrende, komplisert og arbeidskrevende før man har kommet inn i det. Denne forklaringen tar det hele med ”teskje” for at man skal kunne forstå gangen i det. Til slutt er det listet opp tre script som automatiserer mye av disse manuelle operasjonene. 4.1 Lage CA root-sertifikat og etablere sertifikathierarki Når man skal etablere en egen sertifikatstruktur, må man først og fremst ha på plass et root-sertifkat som senere skal brukes til å generere og kontrollere alle andre sertifikater med.

Dette genererer et nytt X509 sertifikat og privat nøkkel til samme fil i PEM-format (Privacy Enhanced Mail). Dette eksempelet gir en CA med varighet i 1825 dager som er 5 år. Det er ingenting i veien for å lage noe med lengre eller kortere varighet, men siden alle andre sertifikater er avhengig av dette så bør dette settes til en fornuftig lang varighet så ikke alle sertifikater må byttes i utide. Ofte setter man så lang som 10 års varighet. Du vil få spørsmål om å legge inn noen data:

Legg inn informasjonen slik det virker fornuftig. Vær påpasselig med å gi ”Common Name” (CN) et fornuftig navn som for eksempel ”UNINETT WLAN CA” siden dette er navnet alle brukere vil se i listen sin når de skal bruke sertifikatet. I stedet for å fylle ut all denne informasjonen manuelt i det man genererer sertifikat, kan man i stedet redigere i konfigurasjonsfila til OpenSSL /etc/ssl/openssl.cnf Et stykke ned i filen finner man innslag som countryName_default, organizationalUnitName_default, osv. Her legges standardverdiene som man vil skal dukke opp. Man kan også legge til slike _default for de innslagene som mangler det. Resultatet av denne operasjonen blir en fil root-req.pem. Så må man etablere et sertifikathierarki. Det gjøres ved å bruke scriptet CA.pl som følger med OpenSSL og parameteren -newca

Country Name (2 letter code) [AU]: State or Province Name (full name) [Some-State]: Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]: Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []: Email Address []:

openssl req -new -x509 \ -keyout root-req.pem \ -out root-req.pem \ -days 1825 \ -passout pass:capassord


12

På spørsmålet: CA certificate filename (or enter to create) Skriver du navnet på det sertifikatet vi nettopp har generert: root-req.pem Avhengig av hva som er konfigurert i openssl.cnf så blir det laget en katalog (demoCA) med underliggende katalogstruktur og filer som skal huse sertifikathierarkiet. Det offentlige sertifikatet til CA legges også der. I tillegg trenger vi en fil som holder rede på serienummeret til neste sertifikat som skal lages. Vi kan gjøre det enkelt å lage det på denne måten:

Kontroller at demoCA/cacert.pem inneholder det samme sertifikatet som det som ligger i root-req.pem og at demoCA/private/cakey.pem inneholder den samme nøkkelen som root-req.pem. Etter det kan du slette root-req.pem.

Til slutt må man lage et offentlig sertifikat i DER-format (Distinguished Encoding Rules) slik at brukerne kan importere det i sine klienter som root CA.

Fila CAroot.der kan man gi et passende navn og distribuere fritt til alle egne brukere som kunne tenkes å bruke trådløsnettet. Den kan for eksempel sendes ut pr. mail, legges inn på en web-side eller liggende tilgjengelig i resepsjonen på en minnepinne. På Windows importeres den enkelt til rett sted ved å dobbeltklikke på den.

echo "01" > demoCA/serial

openssl x509 -inform PEM \ -outform DER \ -in demoCA/cacert.pem \ -out CAroot.der

rm root-req.pem

/usr/lib/ssl/misc/CA.pl -newca


13

4.2 Lage serversertifikat Serversertifikatet er nødvendig uansett om man skal ha TLS, PEAP eller TTLS autentisering fordi det er den eneste måten RADIUS serveren kan identifisere seg på. Det første vi må gjøre er å rekvirere en fil i PEM-format.

Som da vi laget CA sertifikatet, får vi spørsmål om å fylle inn verdiene for organisasjon, lokasjon og navn. Fyll inn med det som er fornuftig. Det er fornuftig å la levetiden til serveren sitt sertifikat vare noen år men det er ikke problematisk å bytte ut sertifikatet etter behov og det får ingen konsekvenser for klientenes konfigurasjon. VIKTIG! Common Name (CN) må være det fulle DNS-navnet (hostname + domain name) til RADIUS serveren! For eksempel radius1.uninett.no. Det er fordi enkelte klienter vil sjekke om CN i RADIUS serveren sitt sertifikat stemmer med hva de forventer den skal hete. Klienten har naturligvis ikke anledning til å sjekke direkte i DNS under autentiseringsprosessen så dette er noe brukeren må legge inn selv. Å bruke navnet angitt i DNS vil være naturlig for mange. I tillegg får man disse spørsmålene:

Her er det bare å svare blankt. Kommandoen resulterer i filen req-server.pem. Denne må signeres av CA og dessuten få lagt til nødvendig policy slik at den kan brukes til vårt tiltenkte formål. De ulike formålene et sertifikat kan brukes til, angis ved hjelp av OID (Object ID). Vi må spesifisere at dette sertifikatet skal brukes av en server for autentisering. ODI for det er 1.3.6.1.5.5.7.3.1 For enkelhets skyld legger vi dette inn i en fil som vi kaller for EXTENSIONS.

Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

[ xpserver_ext ] extendedKeyUsage = 1.3.6.1.5.5.7.3.1

openssl req -new \ -keyout req-server.pem \ -out req-server.pem \ -days 1825 \ -passout pass:serverpassord


14

Slik signeres sertifikatet:

Resultatet blir filen server-cert.pem som vi bruker videre til å først generere sertifikatet i P12 format:

Deretter bruker vi filen som blir laget, server.p12, til å lage et endelig sertifikat i PEM-format:

Filen server.pem er strengt tatt den eneste du trenger for RADIUS serveren, noe som betyr at du nå kan slette filene req-server.pem, server-cert.pem og server.p12 med mindre du har en RADIUS server som ønsker sitt sertifikat i P12-format.

rm req-server.pem rm server-cert.pem rm server.p12

openssl pkcs12 -in server.p12 \ -out server.pem \ -passin pass:serverpassord \ -passout pass:serverpassord

openssl pkcs12 -export \ -in server-cert.pem \ -inkey req-server.pem \ -out server.p12 \ -clcerts \ -passin pass:serverpassord \ -passout pass:serverpassord

openssl ca -policy policy_anything \ -out server-cert.pem \ -extensions xpserver_ext \ -extfile EXTENSIONS \ -passin pass:serverpassord \ -key capassord \ -infiles req-server.pem


15

4.3 Lage klientsertifikat Dersom man skal kjøre en TLS løsning så må man også utstede klientsertifikater. Å lage ett klientsertifikat er bare marginalt forskjellig fra å lage et serversertifikat. Det første vi må gjøre er å rekvirere en fil i PEM-format.

Vi får spørsmål om å fylle inn verdiene for organisasjon, lokasjon og navn. Fyll inn med det som er fornuftig. Sertifikatets gyldighet kan det være fornuftig å sette til studiets/ansettelsesforholdes varighet, for eksempel 3 år. VIKTIG! Common Name (CN) anbefales å være brukerens brukernavn pluss hjemmeorganisasjon/domene, for eksempel [email protected]. Dette er for å kunne rute forespørselen riktig gjennom et radiushierarki (se avsnittet om eduroam). I tillegg får man disse spørsmålene:

Her er det bare å svare blankt. Kommandoen resulterer i filen req-klient.pem. Denne må signeres av CA og dessuten få lagt til nødvendig policy slik at den kan brukes til vårt tiltenkte formål. De ulike formålene et sertifikat kan brukes til, angis ved hjelp av OID (Object ID). Vi må spesifisere at dette sertifikatet skal brukes av en klient for autentisering. ODI for det er 1.3.6.1.5.5.7.3.2 For enkelhets skyld legger vi dette inn i en fil som vi kaller for EXTENSIONS.

Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

[ xpclient_ext ] extendedKeyUsage = 1.3.6.1.5.5.7.3.2

openssl req -new \ -keyout req-klient.pem \ -out req-klient.pem \ -days 1095 \ -passout pass:klientpassord


16

Slik signeres sertifikatet:

Resultatet blir filen klient-cert.pem som vi bruker videre til å først generere sertifikatet i P12 format:

Filen klient.p12 er det formatet de fleste klienter kan benytte seg av. For en Windows klient er det bare å dobbeltklikke på fila for å importere den til rett sted. Det her oppgitte ”klientpassord” er brukerens passord til den private nøkkelen og må brukes for å kunne importere fila til sin egen maskin. Du kan nå slette filene req-klient.pem og klient-cert.pem.

rm req-klient.pem rm klient-cert.pem

openssl pkcs12 -export \ -in klient-cert.pem \ -inkey req-klient.pem \ -out klient.p12 \ -clcerts \ -passin pass:klientpassord \ -passout pass:klientpassord

openssl ca -policy policy_anything \ -out klient-cert.pem \ -extensions xpserver_ext \ -extfile EXTENSIONS \ -passin pass:klientpassord \ -key capassord \ -infiles req-klient.pem


17

4.4 Script for å generere sertifikat ca-cert.sh

EXTENSIONS

[ xpclient_ext] extendedKeyUsage = 1.3.6.1.5.5.7.3.2 [ xpserver_ext ] extendedKeyUsage = 1.3.6.1.5.5.7.3.1

#!/bin/sh PATH=/etc/ssl/misc/:${PATH} CA_PL=/usr/lib/ssl/misc/CA.pl if [ $# != 1 ] then echo "Format: $0 capassord" exit 1 fi # Dersom CA hierarkiet er eksisterer foer, maa den tidligere strukturen # slettes. Ellers vil ikke det nye CA sertifikatet bli kopiert inn. rm root* rm -rf demoCA # Lage et nytt CA rootsertifikat openssl req -new -x509 -keyout root-req.pem -out root-req.pem -days 1825 \ -passout pass:$1 # Lage CA hierarki echo "root-req.pem" | $CA_PL -newca >/dev/null # Lage serienummerfil echo "01" >> demoCA/serial # Lage CA sertifikatet i DER-format openssl x509 -inform PEM -outform DER -in demoCA/cacert.pem -out CAroot.der # Rydde opp rm root-req.pem


18

server-cert.sh

#!/bin/bash if [ $# != 3 ] then echo "Format: $0 filnavn capassord sertifikatpassord" exit 1 fi # Rekvirer et nytt sertifikat openssl req -new -keyout req-$1.pem -out req-$1.pem -days 1825 \ -passout pass:$3 # Signer sertifikat og legg innoedvendig OID openssl ca -policy policy_anything -out $1-cert.pem \ -extensions xpserver_ext -extfile EXTENSIONS \ -passin pass:$3 -key $2 -infiles req-$1.pem # Eksporter til P12 format openssl pkcs12 -export -in $1-cert.pem -inkey req-$1.pem -out $1.p12 \ -clcerts -passin pass:$3 -passout pass:$3 # Konverter til PEM format openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:$3 -passout pass:$3 # Rydd opp rm req-$1.pem rm $1-cert.pem


19

klient-cert.sh

#!/bin/bash if [ $# != 3 ] then echo "Format: $0 filnavn capassord sertifikatpassord" exit 1 fi # Rekvirer et nytt sertifikat openssl req -new -keyout req-$1.pem -out req-$1.pem -days 1095 \ -passout pass:$3 # Signer sertifikat og legg innoedvendig OID openssl ca -policy policy_anything -out $1-cert.pem \ -extensions xpclient_ext -extfile EXTENSIONS \ -passin pass:$3 -key $2 -infiles req-$1.pem # Eksporter til P12 format openssl pkcs12 -export -in $1-cert.pem -inkey req-$1.pem -out $1.p12 \ -clcerts -passin pass:$3 -passout pass:$3 # Rydd opp rm req-$1.pem rm $1-cert.pem


20

5. Kjøp av sertifikat fra UNINETT SCS Alternativet til å lage sertifikater selv er å kjøpe fra en etablert sertifikatutsteder. Fordelen med det er at CA allerede er installert hos klientene. Skal man kjøpe et sertifikat står man fritt til å kjøpe fra dem man ønsker. UNINETT har en Server Certificate Service (SCS) gjennom vårt medlemsskap i TERENA sitt SCS-prosjekt. Sertifikatene er utsted av GlobalSign, en CA som er lokalisert i Belgia og som er en del av Cybertrust-gruppen. På http://forskningsnett.uninett.no/scs/ vil man finne nødvendig informasjon om hvordan man går frem for å bestille. Prosessen er i korte trekk:

1. Din organisasjon må få etablert en Forhåndsgodkjenning 2. Genere nøkkelpar og ”Certificate Signing Request” (CSR) 3. Sende inn CSR via ”SCS enrolment pages” 4. Bekrefte bestilling 5. Motta sertifikatet 6. Installere sertifikatet

Erfaring har vist at det kan være problematisk å generere CSR fra enkelte plattformer/applikasjoner. Vi anbefaler derfor OpenSSL som finnes både for Windows og Linux.


21

Konfigurasjon av FreeRADIUS på SAMSON3 (Linux) FreeRADIUS er basert på åpen kildekode og svært utbredt. Konfigurasjonsfiler og spesielt debug-meldingene fra programmet kan til å begynne med fortone seg som uforståelig, men med litt erfaring så er den ganske grei å ha med å gjøre. Den kan knyttes opp mot en mengde forskjellige typer brukerdatabaser som gjennom PAM, UNIX, SQL og LDAP. Den mest brukte brukerdatabasen å knytte seg opp mot er antakeligvis Active Directory. For den som ønsker å installere dette selv på en egen Linux basert maskin, enten som binærdistribusjon eller fra lokalkompilert kildekode så vil det være tidsbesparende å vite at Debian distribusjonen ikke er kompilert med den nødvendige EAP-støtten. Standard configure av kildekoden har heller ikke inkludert de nødvendige parametere for dette. Installasjonen på SAMSON3 har imidlertid rettet på dette. For å kompilere inn den nødvendige EAP-støtten må man ved configure som et minimum kjøre:

Det vil gi den nødvendige støtten for TLS, PEAP og TTLS. Alle konfigurasjonsfiler til FreeRADIUS er som regel å finne under /etc/freeradius. Det er ganske mange av dem men de som er viktige for oss med 802.1X er:

• radiusd.conf – Hovedkonfigurasjonsfilen. • eap.conf – Alle parametere for autentisering via EAP. • clients.conf – Liste over basestasjoner eller kontrollere som får bruke RADIUS. Også

en liste over andre RADIUS servere som får lov å ta kontakt. • proxy.conf – Liste over hvor de ulike ”realms” skal håndteres, dvs. hvilke RADIUS

servere som skal håndtere forespørselen. • users – brukernavn og passord i tekstformat og/eller spesialhåndtering av

autentiseringen dersom bruker oppfyller visse vilkår. Det anbefales å ikke bruke users filen som brukerdatabase.

Alle konfigurasjonsfiler kommer med et standard oppsett. I dette dokumentet viser vi kun elementene som er nødvendige for å få 802.1X operativt med TLS, PEAP og TTLS. Lokale tilpassninger til spesielt autentisering mot aktuell brukerdatabase vil komme i tillegg.

./configure --with-rlm_eap_tls --with-rlm_eap_peap --with-rlm_eap_ttls


22

radiusd.conf

#Motta RADIUS forespørsler via andre RADIUS servere proxy_requests = yes #Inkluder konfigurasjonsfilen for RADIUS proxy $INCLUDE ${confdir}/proxy.conf #Inkluder konfigurasjonsfilen for RADIUS klienter $INCLUDE ${confdir}/clients.conf #Seksjon med definisjon av moduler modules {

#Inkluder konfigurasjonsfilen for EAP $INCLUDE ${confdir}/eap.conf

#Gjør det mulig å bruke MS-CHAP (og MS-CHAPv2) mschap {

authtype = MS-CHAP }

#Definer suffix med skilletegn @

realm suffix { format = suffix delimiter = "@" ignore_default = no ignore_null = no

} #Gjør bruk av users-filen

files { usersfile = ${confdir}/users

} } # Hvilke moduler som skal brukes for autorisasjon. authorize { suffix eap files } # Hvilken moduler som skal håndtere de ulike autentiseringsmetodene. authenticate {

#MS-CHAP for MS-CHAPv2 i PEAP og TTLS Auth-Type MS-CHAP {

mschap } #EAP meldinger eap

}


23

eap.conf

eap { # Velg forventet standard EAP-type (tls, peap eller ttls)

default_eap_type = peap # Ikke la det gå for lang tid mellom respons og forespørsel. timer_expire = 60 # Håndtere ukjente/ikke konfigurerte EAP typer? no|yes ignore_unknown_eap_types = yes # Det er en feil i Cisco AP1230B firmware 12.2(13)JA1 cisco_accounting_username_bug = no

# Håntering av EAP-TLS. Også serversertifikat for PEAP og TTLS.

tls { # Passordet til RADIUS server sin private nøkkel

private_key_password = hemmelig # Privat nøkkel og sertifikat kan være i samme fil # eller i to separate filer. private_key_file = /etc/freeradius/certs/server.pem certificate_file = /etc/freeradius/certs/server.pem # Offentlige sertifikatet til CA CA_file = /etc/freeradius/certs/demoCA/cacert.pem # DH fil dh_file = /etc/freeradius/certs/dh # Fil med vilkårlig innhold (random seed) random_file = /etc/freeradius/certs/random

# De fleste AP har max pakkestørrelse på 1500-1600 bytes # I så fall må denne verdien settes til 1024 eller mindre.

fragment_size = 1024 } # Håndtering av EAP-TTLS ttls { # Anbefalt standard EAP type i TTLS

default_eap_type = mschapv2 } # Håndtering av EAP-PEAP peap { # Anbefalt standard EAP type i PEAP

default_eap_type = mschapv2 } # Håndtering av EAP-MS-CHAPv2 mschapv2 { }

}


24

clients.conf

proxy.conf

# Hvordan skal de som blir definert som LOCAL håndteres? realm LOCAL { type = radius authhost = LOCAL accthost = LOCAL } # Hvordan skal de som ikke har noe realm håndteres? realm NULL { type = radius authhost = LOCAL accthost = LOCAL } # Hvordan andre definerte realms skal håndteres realm uninett.no { type = radius authhost = LOCAL accthost = LOCAL } # Alle andre realms som ikke er definert # Dette brukes i et RADIUS hierarki for å finne rett RADIUS server realm DEFAULT { type = radius authhost = 158.38.0.237:1812 accthost = 158.38.0.237:1813 secret = superhemmelig nostrip }

# IP adresse til Authenticator, dvs. basestasjon/kontroller som skal # bruke RADIUS serveren for klientautentisering. client 192.168.1.10 { # Delt hemmelighet mellom basestasjon/controller og RADIUS server.

secret = hemmelig # Kort navn på enheten (for RADIUS loggen) shortname = Cisco AP1131AG

} client 192.168.1.11 {

secret = hemmelig shortname = Cisco AP1230

} client 192.168.1.12 {

secret = hemmelig shortname = Cisco AP1100

}


25

users

# Kun eksempler. Denne filen kan stå uten innhold. # Bruker anonymous kan nektes (NB! Alt skal på samme linje!) DEFAULT User-Name =~ "^[Aa][Nn][Oo][Nn][Yy][Mm][Oo][Uu][Ss]$", AuthType:= Reject # Slik kan en nekte brukere uten realm DEFAULT Realm == NULL, AuthType := Reject # Brukes til testing og evt. restarting av freeradius eduroam-test Auth-Type := Reject Reply-Message = "samson3.uninett.no: OK" # Man kan legge inn brukere med passord i klartekst eller kryptert. # Det er ikke anbefalt å bruke users filen som brukerdatabase. "bruker" Cleartext-Password := "hemmelig"


26

7. Konfigurasjon av basestasjon/kontroller Basestasjoner og kontroller utgjør den parten som gjør den minst kompliserte biten av autentiseringsprosessen. Nøyaktig hvordan å sette opp dette vil selvsagt variere fra produkt til produkt men generelt skal man:

1. Opprette en SSID 2. Knytte SSID mot et VLAN 3. Definere autentiseringsmekanismen til å benytte seg av 802.1X med EAP, eventuelt at

man skal velge WEP/WEP2 4. Definere krypteringsalgoritme til å være TKIP og/eller AES 5. Definere RADIUS servere

På en Cisco basestasjon så vil dette kunne se slik ut (kun relevante innslag er tatt med):

aaa group server radius rad_eap server 158.38.0.237 auth-port 1812 acct-port 1813 ! aaa group server radius rad_acct server 158.38.0.237 auth-port 1812 acct-port 1813 ! dot11 ssid mittnettverk authentication open eap eap_methods authentication key-management wpa accounting acct_methods ! interface Dot11Radio0 encryption mode ciphers tkip ! ssid eduroam ! ! radius-server host 158.38.0.237 auth-port 1812 acct-port 1813 key hemmelig radius-server vsa send accounting


27

8. Konfigurasjon av klient Det er like mange måter å konfigurere på som det finnes ulike klienter. Hvordan de skal konfigureres blir også opp til hvilke valg man har gjort for autentisering og kryptering. Generelt kan man si:

1. Eventuelt installer CA sitt offentlige sertifikat. 2. Definer en profil for ønsket WLAN 3. Angi SSID 4. Angi nettverksautentisering til WPA og/eller WPA2 5. Angi datakryptering til TKIP og/eller AES 6. Angi EAP type til å bruke sertifikat (TLS) eller brukernavn/passord

(PEAP eller TTLS) 7. Angi at man vil verifisere serversertifikat og angi CA. Der det er mulig bør man også

angi navnet til serveren slik at man kan sjekke om det også stemmer. 8. Ved PEAP/TTLS: Angi MS-CHAPv2 for autentisering og legg inn brukernavn og

passord om ønskelig. Noen få klienter støtter eksport/import av profiler, noe som gjør denne prosessen enklere med flere like klienter.


28

9. Dynamisk tildeling av VLAN Siden man bruker RADIUS så har man muligheten til å sende noe informasjon tilbake til basestasjonen sammen med godkjenning av brukerens autentisering, AV Pair (Attribute-Value Pair). Dette er en svært nyttig funksjon der man kan sende beskjed om hvilket VLAN brukeren skal være på. Dette kan altså gjøres dynamisk slik at en bruker får tildelt et VLAN dynamisk etter de rettigheter man har som bruker, eventuelt hvilken tid det er på døgnet. Såfremt basestasjonen har VLANet tilgjengelig i sin trunk, vil klienten bli plassert der. Det er flere måter å identifisere en bruker i brukergruppe. Det kan f.eks. ligge som ekstra informasjon fra en LDAP forespørsel eller det kan vurderes ut i fra et prefiks eller suffiks ("realm") til brukernavnet. I FreeRADIUS kan en slik AV-pair konfigurasjon se slik ut i users fila:

En bruker som får en vellykket innlogging som "[email protected]" vil havne på VLAN 10 mens en bruker som får en vellykket innlogging som "[email protected]" (en helt annen bruker) vil havne på VLAN 20. Standard VLAN for aktuell SSID kan godt være et tredje VLAN.

# Ansatte skal til VLAN 10 DEFAULT Realm == ans.uninett.no Service-Type = Login-User, Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-Id = 10, Fall-Through = yes # Studenter skal til VLAN 20 DEFAULT Realm == stud.uninett.no Service-Type = Login-User, Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-Id = 20, Fall-Through = yes


29

10. eduroam eduroam er resultatet av et samarbeidsprosjekt i TERENA (TF-Mobility) hvor bl.a. UNINETT er medlem. Kort fortalt vil alle brukere av eduroam enkelt kunne logge seg på det trådløse nettverket hos alle institusjoner i hele verden som har koblet seg til eduroam. Dette er realisert gjennom et system basert på tillit hvor alle medlemmer har knyttet sammen sine RADIUS servere i et RADIUS hierarki. Det finnes et par internasjonale toppnivå dedikerte eduroam RADIUS servere hvor alle medlemsland har koblet til sine respektive nasjonale dedikerte eduroam toppnivå RADIUS servere. I hvert land har alle eduroam-tilknyttede institusjoner koblet sine RADIUS servere mot de nasjonale RADIUS serverne. I Norge er det UNINETT som har ansvaret for de nasjonale RADIUS serverne.

Det er et krav at de tilknyttede institusjoner skal tilby et trådløst nettverk med SSID "eduroam". I tillegg skal dette trådløse nettverket være beskyttet med 802.1X autentisering og minimum TKIP kryptering. Det er også et minimum av porter som skal være åpen mot omverden. I dette RADIUS hierarkiet er det RADIUS serveren hos organisasjonen hvor brukeren hører hjemme, som alltid utfører autentiseringen. Autentiseringsforespørselen blir rutet hjem til riktig RADIUS server ved å bruke "realm", dvs. en organisasjonsidentifikasjon som blir oppgitt etter brukernavnet. F.eks. en bruker hos UNINETT vil være [email protected] mens en bruker hos UiO vil være [email protected]. Den lokale RADIUS serveren vil stole på resultatet av autentiseringsprosessen når den gir gjester tilgang. Av praktiske årsaker velger de fleste institusjoner å bruke SSID "eduroam" som den eneste SSID på campus og styre brukere over til ønsket VLAN ved hjelp av dynamisk VLAN tildeling. Denne løsningen velges fordi det gir mindre forvirring om hvilken SSID man skal bruke, det innarbeider en gjenkjennelse når brukeren besøker andre institusjoner. Ikke minst er det fordi brukerens WLAN profil/konfigurasjon kan brukes uendret alle steder som har


30

eduroam. Brukeren trenger altså ikke gjøre noen endringer av konfigurasjon men koble seg til det fremmede trådløsnettet på akkurat samme måte som hjemme på egen institusjon. Dersom man har på plass 802.1X og bruk av RADIUS på eget trådløst nettverk, er steget over til eduroam svært kort. Det innebærer i praksis etablering av et eget IP subnett for gjester, SSID "eduroam" for dette subnettet og litt ekstra konfigurasjon av RADIUS serveren slik at autentisering fra ukjente realms blir videresendt til de nasjonale toppnivå RADIUS serverne. For flere detaljer om eduroam og Policy dokumentet for tilkobling, henvises det til http://www.eduroam.no


31

11. Oppsummering og anbefaling Med bakgrunn i de metoder som har blitt beskrevet i dette dokumentet, oppsummerer vi med vår anbefalte sikkerhetsløsning for trådløse nett. Autentisering:

- Benytt IEEE 802.1X

Autentiseringsprotokoll: - PEAP - TTLS - TLS, dersom man har PKI til det.

Disse protokollene er ikke ekskluderende og kan støttes samtidig. RADIUS server:

- FreeRADIUS - Microsoft IAS - Cerebrum

Man står fritt til å velge RADIUS server etter preferanse men ikke alle støtter EAP metodene PEAP, TTLS og TLS som bør være et minimumskrav (de ovenstående støtter dette) Kryptering:

- Minimum TKIP (WPA) - Helst AES (WPA2)

Det beste hadde vært å utelukkende bruke AES men på grunn av bakoverkompatibilitet må de fleste også støtte TKIP. Begge kan være tilgjengelig samtidig, men enkelte klienter kan få problemer med å koble seg til. Lokal situasjon bestemmer valget. Sertifikat:

- Selvgenerert - Kjøpt fra kjent CA

Her står man fritt. Ens egen situasjon vil diktere kunne diktere valget. Det er teoretisk sikrere med et selvgenerert men i praksis er risikoen liten med et kjøpt sertifikat. Man må ha et sertifikat for sin RADIUS server men om man vil bruke det også for brukere, er en vurdering mellom å bruke en brukerdatabase administrere en PKI. Brukerrettigheter Fordel brukerne på ulike VLAN etter brukergrupper, for eksempel ansatte, administrasjon, teknisk, studenter, osv. Bruk RADIUS med dynamisk VLAN-tildeling og kun en SSID. Ønsket VLAN kan settes av RADIUS serveren eller komme fra brukerdatabasen dersom den har informasjon om det. Bruk vanlige nettfilter for å gi rettigheter til de forskjellige VLAN. Brukerdatabase Brukerdatabasen kan for mange ideelt sett være en allerede eksisterende brukerdatabase slik at man slipper å opprette en ny bare til trådløs autentisering. Det finnes et utall av forskjellige typer brukerdatabaser. Valget bør falle på noe som er enkelt å administrere, lagerer passord på en sikker måte og gjør passord tilgjengelig for kontroll via MS-CHAPv2, dvs. i et MD4 format. I tillegg må den selvsagt kunne kommunisere med den typen RADIUS server man bruker.


32

eduroam Når man har på plass IEEE 802.1X og RADIUS server skal det teknisk svært lite konfigurasjon til for å koble seg til eduroam. Et krav er SSID ”eduroam”. Fordelen er tilgang til å bruke trådløsnettet hos alle andre eduroam institusjoner i verden. Mindre, frittstående AP (for eksempel hjemme) Bruk WPA-PSK med MINST 20 tegn i passordet. Hold det til alfanumeriske tegn da nøkkelgenereringsrutinen på enkelte produkt ikke fungerer riktig med spesialtegn. Spesielt om autonome AP

- Ikke la basestasjonens administrative IP adresse være tilgjengelig for brukere. Legg IP adressene til et administrativt nettverk som ikke er tilgjengelig trådløst.

- Med flere VLAN må AP få en trunk. Husk å sikre kabelen mot at uønskede får fysisk tak i den og med det få adgang til ellers adgangsbegrensede VLAN. Ikke la trunken inneholde flere VLAN enn nødvendig for det trådløse nettverket.

- Bruk kryptert kommunikasjon for konfigurasjon (SSH/HTTPS). Spesielt om trådløs infrastruktur med kontroller

- Sett basestasjoner på et eget administrativt nett som kun har lov til å kommunisere med kontrolleren (all trafikk inn og ut til klientene går via kontrolleren).

- Bruk kryptert kommunikasjon for konfigurasjon (SSH/HTTPS) - Utnytt kontrollerens funksjoner til å aktivt følge med på om det dukker opp

mistenkelige basestasjoner i ditt nettverk.


33

12. Referanser eduroam - Et akademisk RADIUS hierarki som gir brukere adgang til andre WLAN. http://www.eduroam.no/ FreeRADIUS - En RADIUS server basert på åpen kildekode. http://www.freeradius.org/ IEEE – Standardiseringsorgan. http://www.ieee.org/ http://standards.ieee.org/getieee802/802.11.html TERENA - Et europeisk samarbeidsorganisasjon for europeiske NREN (National Research and Education Network). http://www.terena.org/ Wi-Fi Alliance - Sertifisering av kompatible trådløse produkter. http://www.wifialliance.com/ 13. Intellektuelt eierskap Forfatter med arbeidsgruppe står ansvarlig for innholdet i dette dokument. UNINETT står ikke ansvarlig for innholdet. 14. Forfatters adresse Jardar Leira UNINETT Abels gt 5 - Teknobyen 7465 Trondheim Norway Telefon: 735 57917 Epost: [email protected]

Ved spørsmål omkring denne eller andre UFSer – kontakt [email protected] UFSer er tilgjengelige på www.uninett.no/ufs

ufs112: anbefalt sikkerhetsløsning for trådløse nettverk

Documents