Avdelning, Institution Division, Department
Institutionen för Systemteknik
581 83 LINKÖPING
Datum Date 2002-09-06 Språk Language Rapporttyp Report category ISBN X Svenska/Swedish Engelska/English LicentiatavhandlingX Examensarbete ISRN LITH-ISY-EX-ET-0244-2002 C-uppsats
D-uppsats Serietitel och serienummerTitle of series, numbering ISSN Övrig rapport
____
URL för elektronisk version
http://www.ep.liu.se/exjobb/isy/2002/244/ Titel
Title
Centraliserad autentisering med hjälp av LDAP Using LDAP for centralized authentication Författare
Author
Peter Gunnarsson, Krister Källvik
Sammanfattning Abstract
Effektiv hantering av den växande mängden data i dagens IT-samhälle är ett ständigt återkommande problem. Lösningar som innebär att information med krav till snabb åtkomst dubbellagras på flera olika ställen, är bara en av anledningarna till nytänkandet ”katalogtjänster”. Eftersom det länge inte funnits några fasta standarder för ett sådant protokoll har olika företag utvecklat sina egna lösningar. Detta innebär naturligt att det blir problem när man vill få olika katalogtjänster utvecklade för olika syften att samarbeta. Protokollet som är tänkt att lösa detta är LDAP (Lightweight directory Access Protocol).
Detta arbete behandlar hur man bygger ett centraliserat autentiseringssystem med hjälp av LDAP. Fördelarna med LDAP framför traditionella metoder som NIS/NIS+ diskuteras, samt hur man kan knyta ihop ett nätverk med både Windows- och Linuxdatorer, där informationen om användare och rättigheter finns lagrade centralt i en LDAP-baserad katalogtjänst.
Generella säkerhetsbegrepp kring autentisering tas upp, samt vad det egentligen är man behöver skydda vid autentisering och kommunikation via ett nätverk.
Nyckelord Keyword
Centraliserad autentisering med hj¨
alp
av LDAP
Examensarbete utf¨ort i informationsteori vid Tekniska H¨ogskolan i Link¨oping
av
Peter Gunnarsson, Krister K¨allvik Reg nr: LiTH-ISY-EX-ET-0244-2002
Centraliserad autentisering med hj¨
alp
av LDAP
Examensarbete utf¨ort i informationsteori vid Tekniska H¨ogskolan i Link¨oping
av
Peter Gunnarsson, Krister K¨allvik Reg nr: LiTH-ISY-EX-ET-0244-2002
Handledare: Niclas Andersson Examinator: Viiveke F˚ak Link¨oping, 3 november 2002.
Abstract
Abstract Effektiv hantering av den v¨axande m¨angden data i dagens IT-samh¨alle ¨
ar ett st¨andigt ˚aterkommande problem. L¨osningar som inneb¨ar att information med krav till snabb ˚atkomst dubbellagras p˚a flera olika st¨allen, ¨ar bara en av anledningarna till nyt¨ankandet “katalogtj¨anster”. Eftersom det l¨ange inte funnits n˚agra fasta standarder f¨or ett s˚adant protokoll har olika f¨oretag utvecklat sina egna l¨osningar. Detta inneb¨ar naturligt att det blir problem n¨ar man vill f˚a olika katalogtj¨anster utvecklade f¨or olika syften att samarbeta. Protokollet som ¨ar t¨ankt att l¨osa detta ¨ar LDAP (Lightweight directory Access Protocol).
Detta arbete behandlar hur man bygger ett centraliserat autentiseringssystem med hj¨alp av LDAP. F¨ordelarna med LDAP framf¨or traditionella metoder som NIS/NIS+ diskuteras, samt hur man kan knyta ihop ett n¨atverk med b˚ade Windows-och Linuxdatorer, d¨ar informationen om anv¨andare Windows-och r¨attigheter finns lagrade centralt i en LDAP-baserad katalogtj¨anst.
Generella s¨akerhetsbegrepp kring autentisering tas upp, samt vad det egentligen ¨
ar man beh¨over skydda vid autentisering och kommunikation via ett n¨atverk. Keywords: Autentisering, LDAP, PAM, nsswitch, s¨akerhet, Samba
F¨orord
Vi, Peter Gunnarsson och Krister K¨allvik, har under v˚aren 2002 utf¨ort v˚art examensarbete, om 10 po¨ang, p˚a NSC, Nationellt SuperdatorCentrum i Link¨oping. Under sommaren fick vi sedan tillf¨alle att p˚a heltid implementera ett centraliserat autentiseringssystem f¨or NSC. Detta system ¨ar fr˚an och med augusti i drift. Den ursprungliga rapporten skrevs under v˚arterminen men har efterhand ut¨okats med en mer detaljerad implementationsdel.
Denna rapport riktar sig fr¨amst till systemadministrat¨orer som ¨ar nyfikna p˚a hur en autentiseringsl¨osning med LDAP kan se ut och hur man g¨or en s˚adan s¨aker. ¨
Aven personer som vill ha en ¨oversikt ¨over katalogtj¨anster, kryptering och certifikat kan ha gl¨adje av rapporten; fr¨amst d˚a av kapitel tv˚a.
Inneh˚
all
1 Inledning 1 1.1 Bakgrund . . . 1 1.1.1 NSCs system . . . 1 1.1.2 S¨akerheten . . . 1 1.2 Syfte . . . 2 1.3 Problemformulering . . . 2 1.3.1 Avgr¨ansningar . . . 2 1.4 Oversikt . . . .¨ 3 2 Teoretisk bakgrund 4 2.1 Katalogtj¨anster . . . 4 2.1.1 Definition . . . 42.1.2 Varf¨or man vill anv¨anda en katalog . . . 4
2.1.3 Historia bakom dagens katalogtj¨anster . . . 5
2.1.4 Fyra viktiga komponenter i en katalog . . . 6
2.1.5 Vad som skiljer en katalog fr˚an en vanlig relationsdatabas . . 7
2.1.6 Olika katalogtj¨anster och hur de f¨orh˚aller sig till LDAP . . . 8
2.2 S¨akerhet . . . 9
2.2.1 Vad som m˚aste skyddas . . . 9
2.2.2 Kryptering . . . 10 2.2.3 Nyckelcertifikat . . . 11 2.2.4 SSL/TLS . . . 11 2.2.5 Kerberos . . . 12 2.2.6 SSH . . . 13 2.2.7 SecurID . . . 14
2.3 S¨akerhet vid Inloggning . . . 14
2.3.1 Autentisering i Linux . . . 15
2.3.2 Autentisering i Windows . . . 17
3 Implementation 19 3.1 L¨amplig niv˚a f¨or NSC . . . 19
3.1.1 Befintliga system . . . 19
3.1.2 Vad man vill f¨orb¨attra . . . 20
3.1.3 S¨akerhetsniv˚an p˚a NSC . . . 20
3.1.4 Hur man ska ˚astadkomma denna f¨orb¨attring . . . 22
3.2 F¨oreslagen l¨osning . . . 22
3.2.1 S¨akerhet . . . 23
3.3 Klientsidan . . . 25
3.3.1 Linuxklienter . . . 25
3.3.2 Inloggningsf¨orloppet p˚a en windowsklient . . . 26
3.3.3 Superdatorer som klienter . . . 26
3.4 Serversidan . . . 27
3.4.1 OpenLDAP . . . 27
3.4.2 Samba-servern . . . 27
3.4.3 Utv¨ardering av programvara . . . 27
4 Diskussion 30 4.1 F¨ordelar med v˚ar l¨osning . . . 30
4.2 Skydd av n¨atverket . . . 30
4.3 Hur administrat¨orskonton sk¨ots . . . 31
4.4 Drifts¨akerhet . . . 31
4.5 Framtida expansion . . . 31
4.6 Slutsatser . . . 31
A Verifiering av den krypterade f¨orbindelsen 37 A.1 Utan kryptering . . . 37
A.2 Krypterat med TLS . . . 39
B Konfiguration av OpenLDAP 40 B.1 S¨aker f¨orbindelse med TLS och certifikat . . . 40
B.2 R¨attigheter . . . 40
C Kompilering av Samba 42 C.1 TLS-bug i Samba 2.2.5 . . . 43
D Konfigurering av PAM p˚a en Linuxklient 45
Kapitel 1
Inledning
1.1
Bakgrund
NSC (Nationellt SuperdatorCentrum) vid Link¨opings universitet grundades 1989. NSC’s prim¨ara uppgift ¨ar att tillhandah˚alla f¨orstklassig superdatorkraft till Sveri-ges universitet och forskare. Sedan 1999 har NSC g˚att ett steg l¨angre och komplet-terat de traditionella superdatorerna med s˚a kallade Beowulfsystem eller kluster1
. I dagsl¨aget har NSC en av Europas st¨orsta superdatorparker. F¨or att ytterligare f˚a anv¨andning av den v¨ardefulla superdatorkraft som centret har tillg˚ang till, har man ¨aven ett n¨ara samarbete med b˚ade SAAB och SMHI2
.
1.1.1
NSCs system
Ber¨akningsresurserna p˚a NSC best˚ar idag av tre superdatorer och ett antal kluster. Centret samarbetar med centra p˚a flera andra orter och ofta m˚aste kommunikatio-nen g˚a ¨over andra n¨at ¨an LiuNet3
.
I framtiden vill man knyta ihop n˚agra av dessa orter f¨or att p˚a ett effektivt s¨att utnyttja resurserna b¨attre. D˚a skall en anv¨andare transparent kunna anv¨anda resurser, fr˚an olika orter, utan att beh¨ova bry sig om var de ¨ar lokaliserade.
1.1.2
S¨
akerheten
Det ¨ar en blandad skara som anv¨ander NSC’s maskinpark, allt fr˚an studenter till forskare och f¨oretag. M˚anga av dessa, bland annat SAAB, har krav p˚a att deras data och resultat ska hemligh˚allas. D¨arf¨or ¨ar det viktigt att NSC tillhandah˚aller system som klarar dessa, ofta str¨anga, s¨akerhetskrav.
1
Ett kluster ¨ar en m¨angd vanliga PC sammankopplade f¨or att utf¨ora tunga ber¨akningar.
2
Sveriges meteorologiska och hydrologiska institut
3
Link¨opings universitetsn¨atverk.
2 Inledning
Det ¨ar viktigt att inte driva fram s¨akerhetsl¨osningar som bara ser till kraven och inte till anv¨andarna av systemen. En anv¨andare som besv¨aras allt f¨or mycket kommer inte att anv¨anda systemen i s˚a stor utstr¨ackning.
1.2
Syfte
Syftet med denna rapport ¨ar att unders¨oka hur man p˚a b¨asta s¨att implementerar en centraliserad anv¨andarautentisering f¨or NSC i Link¨oping. Eftersom kravet p˚a s¨akerhet ¨ar extra stort kommer vikten l¨aggas p˚a hur man ska t¨anka vid byggan-det av ett anv¨andbart, men ¨and˚a robust system, som klarar expansion. Med hj¨alp av litteratur, tester, samt praktisk uppbyggnad av ett t¨ankbart system, kommer begreppen kring katalogtj¨anster och autentiseringsmetoder att redas ut. Resone-manget kommer att h˚allas p˚a relativt generell niv˚a. Detta f¨or att det t¨ankta auten-tiseringssystemet har stora krav p˚a kompatibilitet gentemot andra system, samt att det m˚aste t˚ala expansion i framtiden.
1.3
Problemformulering
Huvudfr˚agan ¨ar s˚aledes: Hur ska man b¨ara sig ˚at f¨or att skapa ett robust och s¨akert, men ¨aven anv¨andbart system f¨or autentisering av anv¨andare p˚a NSC’s n¨atverk?
Underfr˚agor kring denna rubrik ¨ar ¨aven av typen: • ¨Ar en katalogtj¨anst l¨osningen p˚a problemet?
• Passar ”Lightweight Directory Access Protocol” (LDAP) bra till att anv¨andas i samband med autentisering?
• Vilka ¨ar f¨ordelarna och nackdelar med LDAP j¨amte traditionella metoder? • Vad beh¨over skyddas?
• Hur kan en l¨amplig l¨osning se ut f¨or NSC?
1.3.1
Avgr¨
ansningar
Vi kommer i denna rapport att koncentrera oss p˚a hur LDAP fungerar i en l¨osning. Andra t¨ankbara l¨osningar kommer att betraktas ur aspekten hur de f¨orh˚aller sig till en LDAP-l¨osning. I f¨orsta hand kommer fri programvara p˚a Linuxsystem att anv¨andas.
S¨akerheten kommer bara att utredas i samband med autentiseringsprocessen. N¨ar en anv¨andare v¨al blivit autentiserad utg˚ar vi fr˚an att de befintliga mekanismerna skyddar mot att anv¨andare utf¨or handlingar de inte ¨ar ber¨attigade till.
1.4 ¨Oversikt 3
1.4
Oversikt
¨
I kapitel tv˚a beskriver vi centrala begrepp och teori som ¨ar av vikt f¨or utrednings-arbetet. H¨ar beskriver vi bl.a. LDAP, kryptering, SSH och inloggningsf¨orlopp.
Kapitel tre ber¨or den l¨osning som vi, efter v˚ar utredning, anser passa NSCs behov. H¨ar beskrivs hur l¨osningen fungerar i stort. Vi kommer inte att g˚a in p˚a de-taljer g¨allande konfiguration av system eftersom det finns risk f¨or att dessa kommer att ¨andra sig i senare versioner av programvarorna.
I det avslutande kapitlet diskuterar vi kring v˚ar l¨osning; om den passar NSC, vilka f¨ordelar som vi ser med denna l¨osning och s˚a vidare.
Vi har valt att l¨agga till fyra appendix d¨ar vi p˚a djupet beskriver f¨orlopp under implementationsprocessen som inte varit sj¨alvklara. Bland annat beskriver vi hur vi korrigerat fel i Samba 2.2.5.
Kapitel 2
Teoretisk bakgrund
2.1
Katalogtj¨
anster
2.1.1
Definition
En katalog ¨ar en f¨orteckning ¨over n˚agonting, t.ex. datorer, certifikat eller personer etc. N˚agon sorts information som m˚anga andra beh¨over s¨oka, verifiera eller sl˚a upp. Ordet ”katalog” kommer ursprungligen fr˚an grekiskans ”kata” + ”legein” som betyder ”att samla”. N¨ar ordet katalogtj¨anst (eng Directory Service) anv¨ands i IT-sammanhang handlar det allts˚a om en elektronisk tj¨anst f¨or att samla och katalogisera data.
En klassisk definition av vad en katalogtj¨anst egentligen ¨ar hittas i specifikatio-nen till X.500-standarden[17]:
”The Directory is a collection of open systems which cooperate to hold a logical database of information about a set of objects in the real world.”
2.1.2
Varf¨
or man vill anv¨
anda en katalog
Effektiv hantering av information f¨or snabb ˚atkomst ¨ar ett stort problem i dagens IT-samh¨alle. Informationsm¨angden och datafl¨odet v¨axer samtidigt som kravet p˚a snabb ˚atkomst ¨okar. Man vill ha informationen samlad och strukturerad, men ¨and˚a kunna komma ˚at den fr˚an vitt skilda platser. Det ¨ar inte sv˚art att f¨orst˚a varf¨or man vill anv¨anda katalogtj¨anster.
En till¨ampning d¨ar man klart och tydligt ser f¨ordelarna med en katalog ¨ar anv¨andarkonton och information om anv¨andare. En anv¨andare inom en organisa-tion b¨or rimligen ha ett anv¨andarkonto, som identifierar anv¨andaren globalt p˚a n¨atverket. Vare sig han sitter vid sin vanliga persondator, eller anv¨ander en publik terminal kopplad till n¨atverket.
2.1 Katalogtj¨anster 5
2.1.3
Historia bakom dagens katalogtj¨
anster
De f¨orsta riktiga bidraget till dagens distribuerade datorsystem gjordes p˚a tidigt 1980-tal vid Xerox Palo Alto Research Center, och ledde efter hand till ”The Grape-vine network”[19]. Detta var den f¨orsta distribuerade katalogen f¨or anv¨andarinfor-mation. N¨atverket omfattade ungef¨ar 1500 datorer p˚a 50 lokala n¨atverk. Finessen med detta var att anv¨andare kunde logga in med samma anv¨andarnamn b˚ade p˚a sin vanliga arbetsplats, och p˚a vilket annat Xerox-kontor som helst i v¨arlden. Det utvecklades ¨aven katalogtj¨anster f¨or andra syften.
DNS F¨or att g¨ora Internet mer anv¨andarv¨anligt, skapades Domain Name Ser-vice (DNS). DNS identifierar ett system med hj¨alp av ett namn som ¨ar kopplat till ett IP-nummer. Tack vare DNS-systemet beh¨over man allts˚a inte komma ih˚ag ett IP-nummer utan det r¨acker med att komma ih˚ag namnet p˚a systemet. Ett exempel ¨
ar att man ist¨allet f¨or 204.152.186.57, vilket r˚akar vara datorn som tillhandah˚aller hemsidan f¨or OpenLDAP, kan skriva openldap.org. DNS-systemet tar sedan fram IP-numret f¨or detta datornamn. Detta ¨ar ett exempel p˚a en katalogtj¨anst med be-gr¨ansad anv¨andbarhet, utvecklat f¨or ett speciellt syfte. Man ins˚ag snabbt f¨ordelarna med ett s˚adant katalogsystem, och b¨orjade utveckla katalogtj¨anster f¨or andra syften ¨
an just att ¨overs¨atta namn till IP-nummer.
I takt med att fler och fler b¨orjade bygga katalogtj¨anster b¨orjade man ¨aven utarbeta standarder f¨or dessa.
X.500 CCITT (Consultative Committee on International Telephony and Tele-graphy) och ISO (International Standards Organization) definierade ˚ar 1988 X.500, som sedan kom att bli ISO standard 9594, Data Communications Network Directo-ry, Recommendations X.500-X.521 1990 [18]. M˚alet var att utveckla en generali-serad standard f¨or katalogtj¨anster som skulle t¨acka de krav man kunde t¨ankas ha p˚a katalogtj¨anster i olika sammanhang. Den kallas fortfarande ofta bara X.500-standarden. Problemet med X.500 standarden var att den p˚a m˚anga punkter var all-deles f¨or komplex, samt kr¨avde en fullst¨andig implementation av ISO-protokollen. Detta innebar d¨armed att alla klienter som anv¨ande X.500-servern ocks˚a m˚aste ha ISO-n¨atverksprotokollen implementerade. Support f¨or dessa protokoll kr¨avde ofta mer datorresurser ¨an som var tillg¨angligt i m˚anga sm˚a n¨atverk. Det var d¨arf¨or man utvecklade ett mindre resurskr¨avande ”l¨attvikts”-protokollinterface till X.500-servrarna, kallat ”Lightweight Directory Access Protocol”.
LDAP LDAP ¨ar kort f¨or ”Lightweight Directory Access Protocol”. Det utveckla-des f¨or att f¨orenkla kommunikationen mellan en X.500 server, och en klient som inte hade hela ISO-stacken av protokoll. Bryggan emellan var allts˚a en LDAP-server, som klienten kommunicerade med. LDAP servern f¨ormedlade sedan fr˚agan vidare till X.500 servern, och returnerade sedan svaret den fick tillbaka till klienten igen. 2.1.3. LDAP utvecklades ursprungligen p˚a University of Michigan och har kommit att bli de-facto standard f¨or katalogtj¨anst p˚a Internet och anv¨ands av ett stort antal applikationer f¨or olika system. Netscape, Novell, Microsoft, Sun och m˚anga
6 Teoretisk bakgrund
andra tunga namn inom branschen har mer och mer b¨orjat anv¨anda sig av LDAP som ett verktyg till b¨attre katalogtj¨anster.
LDAP X.500
Klient Katalog
Figur 2.1.LDAP-gateway till en X.500-server.
N¨ar X.500-servrarna b¨orjade anv¨andas i st¨orre utstr¨ackning och man b¨orjade se de verkliga f¨ordelarna, b¨orjade man ocks˚a fundera p˚a om det verkligen var n¨odv¨andigt att ha en LDAP-server som fungerade som gateway. Om man ist¨allet hade sj¨alva katalogen p˚a LDAP-servern, skulle denna i och f¨or sig bli mer kom-plicerad, men skulle i sin tur g¨ora att man inte beh¨ovde anv¨anda ISO-protokoll n˚agonstans i arkitekturen.
LDAP Klient
Katalog
Figur 2.2.Sj¨alvst¨andig,”Stand-alone”, LDAP-server.
2.1.4
Fyra viktiga komponenter i en katalog
Protokoll
Protokollet specificerar hur klient och server samarbetar Med enkla termer kan man s¨aga att protokollet ¨ar ”spr˚aket” som server och klient anv¨ander f¨or att kom-municera. Ett vanligt protokoll f¨or katalogtj¨anster p˚a Internet ¨ar LDAPv3. Det ¨ar viktigt att po¨angtera att protokollet inte specificerar hur en server internt ska lag-ra data. D¨aremot specificelag-ras hur klienten st¨aller fr˚agor och hur servern levererar svaren.[10]
Server
Katalogservern ¨ar till f¨or att behandla f¨orfr˚agningar fr˚an klienter, och g¨ora sitt b¨asta f¨or att leverera ett svar. H¨ar passar det bra att reda ut ett begrepp. Sj¨alva
2.1 Katalogtj¨anster 7
LDAP ¨ar ett protokoll, vilket flera LDAP-baserade servrar, som t.ex. OpenLDAP-servern (slapd) hanterar.
Mallar
Mallar beskriver hur olika typer av data kategoriseras och etiketteras. Det finns m˚anga olika standardorganisationer som utarbetar standarder f¨or dessa mallar, men ¨aven applikationsutvecklare och n¨atadministrat¨orer bidrar. Genom att stan-dardisera mallar ˚astadkommer man en h¨ogre niv˚a av interoperabilitet mellan olika system. Genom att ha standardiserade mallar f¨or lagring av information vet allts˚a oberoende utvecklare av klienter vilka f¨alt som ¨ar s¨okbara, vilket g¨or att LDAP-servern fungerar som det ¨ar t¨ankt (ur klientens synvinkel).
Klient
En klient ¨ar ett program som anv¨ander sig av information lagrad i katalogtj¨ansten. Eftersom anv¨andningsomr˚adet av katalogtj¨anster ¨ar s˚a utbrett ¨ar det sv˚art att defi-niera exakt vad klienten g¨or. Generellt kan man s¨aga att klienten g¨or f¨orfr˚agningar till servern, och behandlar de svar som returneras. T.ex. uppslagning i ett telefon-register eller mer abstrakta saker som information om r¨attigheter i ett distribuerat filsystem.
2.1.5
Vad som skiljer en katalog fr˚
an en vanlig
relationsda-tabas
Kataloger ¨ar organiserade hierarkiskt, p˚a ett objektorienterat s¨att. Detta inneb¨ar att objekt i databasen motsvarar objekt i den v¨arld den f¨ors¨oker efterlikna.
Ramen f¨or vad som kan eller m˚aste lagras standardiseras med hj¨alp av mal-lar, vilka kallas ”scheman”. Dessa underl¨attar avsev¨art kompatibilitet med andra servrar eller klienter.
Katalogtj¨anster anv¨ander sig av ett hierarkiskt arv ¨aven av s¨akerhetsniv˚aer. Detta inneb¨ar att om man s¨atter en viss s¨akerhetsniv˚a p˚a ett nod i databastr¨adet, s˚a kan denna s¨akerhetsniv˚a ¨arvas av barn till noden.
De flesta katalogtj¨anster har inget st¨od f¨or atom¨ara transaktioner1
. Katalogda-tabasen ¨ar d¨arf¨or ibland tempor¨art inkonsistent. Om en ¨andring g¨ors, ¨ar det med andra ord inte garanterat att ¨andringen syns ¨overallt direkt. Eftersom en katalog-tj¨anst fr¨amst ¨ar avsedd f¨or information som ¨andras relativt s¨allan ¨ar detta inget st¨orre problem. Att sk¨ota uppdateringar p˚a detta s¨att underl¨attar avsev¨art hante-ringen av en distribuerad katalog, men inneb¨ar givetvis att en s˚adan katalog inte ¨
ar l¨amplig f¨or hantering av saldon p˚a bankkonton etc.
En katalog beskrivs ofta som en vanlig databas, men i sj¨alva verket ¨ar det en speciell databas, optimerad f¨or l¨asning. F¨orh˚allandet b¨or vara ¨over 1000 l¨asningar per skrivning[14].
1
8 Teoretisk bakgrund
2.1.6
Olika katalogtj¨
anster och hur de f¨
orh˚
aller sig till LDAP
Vid sidan av DNS, som anv¨ands f¨or namnuppslagning p˚a Internet sedan l¨ange, finns andra mer flexibla katalogtj¨anster som Novell Network Directory Service (NDS), Sun Microsystems Network Information Services (NIS/NIS+), Windows NT Do-mains samt Active Directory Services (ADS). En nackdel med dessa ovan n¨amnda katalogtj¨anster ¨ar att de utvecklats av f¨oretag, f¨or specifika administrativa syften. F¨oretagen har d˚a utarbetat egna ”standarder” f¨or sina produkter, vilket g¨or att de s¨allan eller aldrig ¨ar kompatibla med andra system. Detta inneb¨ar givetvis pro-blem n¨ar man vill knyta ihop olika system, d¨ar vissa system k¨or t.ex. NIS i en UNIX-milj¨o, medan andra system k¨or Active Directory i en Windows-milj¨o. NIS/NIS+
Network Information Services (NIS) har utvecklats av Sun Microsystems. Det ¨ar ett verktyg f¨or att centralisera information inom n¨atverket. NIS inneh˚aller en del brister i s¨akerhet. Det har t.ex. inte st¨od f¨or kryptering av trafik etc. NIS har ¨and˚a blivit accepterat inom UNIX-v¨arlden som ett verktyg i n¨atverksadministrationen. Efterf¨oljaren till NIS kallas NIS+.
LDAP bidrar med l¨osningar p˚a m˚anga problem som ¨aldre system s˚asom NIS/NIS+ har.
N˚agra av f¨ordelar med LDAP framf¨or NIS[32]:
• B¨attre s¨akerhetsmodell som inkluderar v¨al definierade kommunikationspor-tar.
• st¨od f¨or kryptering av data. • st¨od f¨or kontrollista2
(f¨or att l˚ata icke-rootanv¨andare modifiera data)[21]. • Kraftfull s¨okmekanism som till˚ater s¨okningar p˚a vilket f¨alt som helst. • Tillhandah˚aller katalogtj¨anster f¨or ett brett applikationsskikt, vid sidan av
namnuppslagning av t.ex. n¨atverksadress eller f¨orvaring av publika nycklar. Novell NDS
NDS (Network Domain Services)[30] ¨ar Novells svar p˚a katalogtj¨anster. Det ¨ar ett objektorienterat databasprotokoll, designat f¨or att knyta ihop resurser i n¨atverk. Designen baseras p˚a koncept ur X.500 standarden. Sedan 1997 finns ocks˚a ett till¨agg kallat ”LDAP services for NDS”. Det ¨ar ett verktyg f¨or att ¨overs¨atta LDAP-operationer till verkliga NDS-anrop. Denna l¨osning f¨or att g¨ora NDS mer kompati-belt med andra system, resulterade dock i prestandaminskningar och extra jobb, f¨or att mappa LDAP-objektklasser och attribut typer till deras motsvarighet i NDS. f¨or att ut¨oka anv¨andandet av NDS, har man portat det till andra plattformar ¨an Novells egna Netware. NDS kallas ¨aven Novell eDirectory[19].
2
ACL, Access Controll List, anv¨ands f¨or att kontrollera r¨attigheter f¨or anv¨andare p˚a en f¨orfinad niv˚a.
2.2 S¨akerhet 9
Active Directory
Active Directory (AD) ¨ar en katalogserver inbyggd i Windows 2000/XP SERVER. Den ¨ar en LDAP-server, med vissa ut¨okningar. AD implementerar inte X.500 stan-darden annat ¨an vad som kr¨avs f¨or LDAP V.3-support. Fullt st¨od f¨or LDAP har implementerats men AD har ¨and˚a n˚agra begr¨ansningar som hindrar full funktiona-litet med en vanlig LDAP-klient. AD ¨ar en hybrid av NT4-dom¨an-modellen, DNS och LDAP. Designen ¨ar byggt f¨or att fortfarande vara bak˚atkompatibel med NT4-dom¨aner. Man har skapat begrepp som ”forest”(skog) och i denna skog kan man ha olika deltr¨ad som har ansvar f¨or olika delar av n¨atet. F¨or en vanlig LDAP-klient som inte vet om dessa ut¨okningar betyder det t.ex. att denna klient bara kommer kunna utf¨ora s¨okningar p˚a ett deltr¨ad[29].
2.2
S¨
akerhet
Med s¨akerhet i v˚art arbete menar vi hur kommunikationen mellan tv˚a punkter i ett n¨atverk skyddas samt hur de b˚ada parternas identitet s¨akerst¨alls.
N¨ar kommunikation sker ¨over ett n¨atverk finns det flera risker som man m˚aste var medveten om. Information som f¨ormedlas ¨over ett n¨atverk kan p˚a ett relativt enkelt s¨att l¨asas av en godtycklig dator ansluten till n¨atet. D¨arf¨or b¨or man undvika att skicka k¨anslig data i klartext och ist¨allet anv¨anda n˚agon form av krypterad f¨orbindelse.
P˚a grund av n¨atverksarkitekturens flexibilitet ¨ar det m¨ojligt f¨or en dator att byta b˚ade IP-adress och h˚ardvaruadress[2]. Potentiella angripare kan f¨orfalska sin dators identitet och p˚a s˚a s¨att bryta ett systems s¨akerhet. Allt vanligare blir s˚a kallade man-in-the-middle-angrepp[1], d¨ar en angripare ¨ar placerad mellan server och klient. Angriparen f˚angar upp n¨atverkspaket mellan parterna, ¨andrar infor-mationen i dem och skickar tillbaka dem ut p˚a n¨atverket med den ursprungliga avs¨andaren som avs¨andare f¨or paketet. Eftersom de flesta tj¨anster ¨ar anslutningso-rienterade litar de p˚a paket som tas emot via en uppr¨attad anslutning och kommer inte att misst¨anka att integriteten i kommunikationen har skadats. F¨or att mini-mera hotet fr˚an s˚adana angrepp b¨or n˚agon form av integritetskontroll inf¨oras i protokollet, tillsammans med kryptering.
Fr˚agorna om kryptering och integritetsskydd b¨or inte drivas hur l˚angt som helst. En tj¨anst f˚ar inte bli s˚a omst¨andlig att anv¨andaren inte orkar anv¨anda den. Anv¨andbarheten ¨ar en viktig del i den slutliga l¨osningen.
2.2.1
Vad som m˚
aste skyddas
F¨or att f˚a en hanterbar struktur kan man dela in IT-s¨akerhet enligt CIA-modellen: confidentiality, integrity och availability.
• Confidentiality inneb¨ar krav p˚a bibeh˚allen sekretess. Viktigt i organisationer d¨ar k¨anslig eller hemligst¨amplad information hanteras, exempelvis i f¨orsvaret eller sjukv˚arden.
10 Teoretisk bakgrund
• Integrity inneb¨ar att information ska g˚a att lita p˚a, dvs data ska vara tillf¨orlit-liga. Man m˚aste helt enkelt kunna lita p˚a att informationen som finns tillg¨ang-lig ej ¨ar obeh¨origt p˚averkad.
• Availability inneb¨ar att information och tj¨anster ska vara tillg¨anglig f¨or de som har beh¨orighet till dem. En publik webbserver ¨ar ett exempel p˚a ett system med stor vikt p˚a tillg¨anglighet.
2.2.2
Kryptering
Modern kryptering sker ofta med v¨alk¨anda algoritmer d¨ar hemligheten ligger i en eller flera nycklar[7]. Data krypteras med hj¨alp av en nyckel och blir ˚ater l¨asbar igen med hj¨alp av antingen samma nyckel eller en annan.
Kryptering erbjuder ett skydd mot att den skickade informationen kan l¨asas av obeh¨origa. Eftersom den bara kan l¨asas av de som har r¨att nyckel beh¨ovs ingen ytterligare beh¨orighetskontroll. Vidare kan man skapa protokoll som bygger p˚a kryptering i kombination med kontrollsummor, f¨or att garantera h¨og integritet.
Symmetrisk kryptering
En metod d˚a krypterings- och dekrypteringsnycklarna ¨ar identiska, eller p˚a ett en-kelt s¨att kan h¨arledas fr˚an varandra kallas symmetrisk. Eftersom data enbart kan v¨axlas mellan tv˚a deltagare som har samma nyckel kan man s¨aga att de ¨ar auten-tiserade f¨or varandra. Denna form av kryptering ¨ar mindre ber¨akningskr¨avande ¨an den asymmetriska och l¨ampar sig d˚a hastigheten i kommunikationen ¨ar viktig.
Asymmetrisk kryptering
Genom att anv¨anda en egenskap hos primtal har metoder med asymmetriska nyck-lar utvecklats. En deltagare har i det h¨ar fallet ett nyckelpar; en privat och en publik. Processen fungerar s˚a att data som krypterats med en nyckel enbart kan g¨oras l¨asbar med hj¨alp av den andra ur paret.
Som ben¨amningarna antyder l˚ater man den privata nyckeln f¨orbli hemlig me-dan den publika skickas till alla som man vill kommunicera med. F¨or att skicka krypterad data till n˚agon anv¨ander man dennes publika nyckel vid krypteringen, f¨or att dekryptera den m˚aste man ha respektive privat nyckel.
Ett annat anv¨andningsomr˚ade f¨or nyckelpar ¨ar digitala signaturer. F¨or att ga-rantera att ett dokument skapats av en viss person krypterar denne det med sin privata nyckel. L¨asaren av dokumentet dekrypterar det med f¨orfattarens publika nyckel och kan p˚a s˚a vis lita p˚a att det ¨ar denne som skrivit det.
Genom att successivt testa olika nycklar kan man med hj¨alp av den publika nyckeln f˚a fram den privata. Detta ¨ar en ber¨akningskr¨avande process som till stor del beror av storleken eller l¨angden p˚a nyckeln. Anv¨ander man en tillr¨ackligt stor nyckel ¨ar det h¨ogst osannolikt att n˚agon, med dagens datorkapacitet, lyckas med detta inom den n¨armaste framtiden.
2.2 S¨akerhet 11
2.2.3
Nyckelcertifikat
Ibland ¨ar det viktigt att kunna s¨akerst¨alla identiteten p˚a de kommunicerande par-terna. Ett s¨att att g¨ora detta ¨ar med hj¨alp av certifikat. Ett certifikat ¨ar en struktur som inneh˚aller information om den part som det identifierar. S˚adan information kan bland annat vara namn, datoradress och publik nyckel[13]. F¨or att garantera att certifikatet ¨ar riktig m˚aste det utf¨ardas och signeras av en certificate authority (CA). Denna l¨agger till information om sig sj¨alv samt en giltighetstid f¨or certifika-tet. Slutligen krypteras hela strukturen med CAs privata nyckel.
Den som vill verifiera ett certifikats ¨akthet beh¨over utf¨ardarens publika nyckel. Lokalt sparas publika nycklar till de CA som systemet litar p˚a. Finns en passande nyckel i databasen kan man g˚a vidare till n¨asta steg, annars fr˚agar den en CA som systemet litar p˚a om ¨aktheten.
Om certifikatets giltighet slutligen fastst¨alls m˚aste man ta flera steg innan iden-titeten kan s¨akerst¨allas. Datoradressen i certifikatet och avs¨andaradressen till det fysiska n¨atverkspaketet m˚aste st¨amma f¨or att visa att certifikatet inte kommit p˚a villov¨agar. Datoradresser g˚ar att ¨andra p˚a men denna kontroll ger ¨and˚a ett visst skydd. D˚a ett utf¨ardat certifikat inte g˚ar att invalidera anv¨ander man en giltig-hetstid f¨or att begr¨ansa nyttan av ett stulet certifikat. Ett stulet certifikat fungerar bara fram till den tidpunkten. Slutligen kan man testa om motparten kan l¨asa meddelanden kodade med dennes publika nyckel. Denna l¨osning anv¨ands av SSL-protokollet.
2.2.4
SSL/TLS
Secure Sockets Layer (SSL) utvecklades fr˚an b¨orjan av Netscape och anv¨ands flitigt inom m˚anga omr˚aden, t.ex. e-handel och webbportaler En vidareutveckling av SSL 3.0 kallas Transport Layer Security (TLS) och skiljer sig bara i sm˚a drag.
En viktig anledning till att SSL och TLS har blivit s˚a popul¨ara ¨ar att det ¨ar enkelt att bygga om applikationer s˚a att de utnyttjar denna kryptering. Krypte-ringen ligger som ett lager mellan applikationslagret och n¨atverkslagret och ¨ar efter initialisering helt transparent f¨or applikationen.
Applikationslager
TLS/SSL TCP/IP
Figur 2.3.TLS/SSL ligger som ett transparent lager i IP-stacken.
Med hj¨alp av asymmetrisk kryptering och certifikat uppr¨attas en anslutning mellan de kommunicerande parterna[8]. Det finns flera s¨att att konfigurera upp-kopplingsfasen. Det s¨akraste s¨attet kr¨aver att b˚ade servern och klienten autentiserar sig f¨or varandra med hj¨alp av certifikat.
12 Teoretisk bakgrund
Eftersom asymmetrisk kryptering inte l¨ampar sig f¨or snabb data¨overf¨oring, och SSL/TLS str¨avar efter att vara s˚a transparent som m¨ojligt, best¨ammer sig parterna under uppkopplingsfasen f¨or en symmetrisk nyckel. Nyckeln som slumpas fram ¨
overf¨ors krypterad med en asymmetrisk nyckel och anv¨ands sedan f¨or den fortsatta kommunikationen.
Protokollet g¨or det m¨ojligt att anv¨anda flera olika algoritmer. Vilken av dem som anv¨ands f¨orhandlar servern och klienten om under uppkopplingsfasen. Det ¨
ar viktigt att konfigurera systemen att inte godta svaga algoritmer. Detta f¨or att undvika eventuella brister. Ett bra konfigurerat system ger ett bra skydd f¨or in-formation, integritetskoll och autentisering s˚a l¨ange parternas privata nycklar inte kommit p˚a drift.
2.2.5
Kerberos
Autentisering av anv¨andare och datorer ¨ar ett omr˚ade d¨ar m˚anga olika l¨osningar existerar. En av de mest v¨alk¨anda och spridda ¨ar Kerberos som utvecklades p˚a Michigan Institute of Technology[28]. De flesta operativsystem erbjuder st¨od f¨or Kerberosautentisering.
Protokollet sk¨oter autentisering av b˚ade klient och server genom att blanda in en tredje part, en s˚a kallad authentication service (AS).
F¨orenklat kan man beskriva f¨orloppet s˚a h¨ar[20]:
AS
klient
server
1
2
3
4
Figur 2.4.Klienten vill ansluta sig till servern. Genom att att anv¨anda sig av en authen-tication server kan b˚ade klienten och servern lita p˚a att respektive ¨ar vad de utger sig f¨or.
N¨ar en klient vill ansluta och utnyttja tj¨anster p˚a en server m˚aste de b˚ada g˚a igenom flera steg, som garanterar s¨akerheten. Klienten skapar ett paket, krypte-rat med sin privata nyckel, inneh˚allande namnet p˚a servern, aktuell tid samt ett godtyckligt tal och skickar det till AS. AS tar emot paketet och letar upp klient och server i sin databas. D¨ar finns bland annat symmetriska nycklar f¨or kommu-nikation, mellan AS och klient respektive server, lagrade. Om klienten och servern finns i databasen skapar AS en unik symmetrisk nyckel som ska anv¨andas under kommunikationen mellan klienten och servern, en sessionsnyckel.
D¨arefter skickas tv˚a paket till klienten. Det ena inneh˚aller bland annat ses-sionnyckeln, giltighetstid och det godtyckliga talet. Allt krypterat med den f¨orbe-st¨amda nyckeln f¨or kommunikation mellan klient och AS. Att det slumpade talet
2.2 S¨akerhet 13
kommer tillbaka till klienten, som det skickades, bevisar att AS ¨ar vad den utger sig f¨or. Det andra paketet inneh˚aller i stort sett samma information men ¨ar krypterat med den symmetriska nyckel som f¨orbinder server och AS, f¨or att klienten inte skall f˚a chansen att modifiera det. Det senare paketet vidarebefordras direkt till servern ˚atf¨oljt av ett nytt paket skapat av klienten. Detta nya paket, som inneh˚aller en
checksumma f¨orutom diverse ¨ovrig information, krypteras med sessionsnyckeln. Servern tar emot de tv˚a nya paketen och dekrypterar det ena med sin symmet-riska nyckel och f˚ar p˚a s˚a s¨att tag p˚a sessionsnyckeln och b¨astf¨oretiden. D¨arefter ¨
oppnas det andra paket med hj¨alp av sessionsnyckeln. Efter att checksumman kon-trollerats kan servern lita p˚a att paketet verkligen ¨ar krypterat med sessionsnyc-keln. F¨or att f¨orvissa sig om att paketet inte ¨ar en ˚ateruppspelning kontrolleras giltighetstiden mot serverns lokala tid med ett acceptabelt tidsf¨onster p˚a cirka fem minuter.
Om klienten kr¨aver att servern skall autentisera sig m˚aste servern skicka tillbaka ytterligare ett paket, till klienten, f¨or att bevisa att den har lyckats dekryptera paketet inneh˚allande sessionsnyckeln.
Det finns en stor f¨ordel med en l¨osning d¨ar servern aldrig f˚ar reda p˚a klientens publika nyckel och tv¨artom. Om n˚agon part blir bestulen p˚a sina nycklar, blir f¨oljderna inte lika allvarliga. Dessutom beh¨over bara en part, AS, lagra nycklarna. Detta g¨or att man f˚ar b¨attre ¨oversikt i ett stort system.
Kerberos erbjuder ¨aven st¨od f¨or autentisering ¨over n¨atverksgr¨anser. P˚a varje n¨atverk m˚aste det i s˚a fall finnas minst en AS. De konfigureras s˚a att alla inblandade AS, i de inblandade n¨atverken, litar p˚a varandra. Denna process sker med hj¨alp av hemliga symmetriska nycklar best¨amda sen tidigare. N¨ar en anv¨andare, som har sin information lagrad p˚a en AS p˚a ett annat n¨atverk, loggar in s˚a fr˚agar den kontaktade AS anv¨andarens “hem-AS” efter n¨odv¨andig information. P˚a detta s¨att kan man exempelvis bygga upp stora f¨oretagsn¨at lokaliserade p˚a flera platser runt om i v¨arlden.
Ett praktiskt exempel p˚a autentisering via Kerberos ¨ar Windows 2000 Server[24]. N¨ar en anv¨andare vill logga in genereras dennes symmetriska nyckel med hj¨alp av inloggningsl¨osenordet. P˚a AS finns respektive nyckel sparad i en databas tillsam-mans med anv¨andarens loginnamn.
2.2.6
SSH
Det ¨ar vanligt att man anv¨ander en textbaserad anslutning, f¨or att administrera eller anv¨anda en Linux, eller Unixbaserad dator3
. Det finns flera varianter av text-baserade anslutningar, och de flesta ¨ar okrypterade. Genom dessa verktyg f˚ar man tillg˚ang till en prompt, som om man fysiskt sitter vid datorn.
Secure Shell (SSH) har blivit allt vanligare p˚a senare ˚ar. Det anv¨ander sig av SSL/TLS. Med hj¨alp av certifikat identifieras servern. Sedan anv¨ands serverns pub-lika nyckelpar f¨or att f¨ora ¨over en unik symmetrisk sessionsnyckel[42]. N¨ar detta ¨ar klart sker krypteringen helt transparent med sessionsnyckeln. Inbyggt i protokollet finns ¨aven integritetskontroll med checksummor.
3
14 Teoretisk bakgrund
SSH erbjuder ut¨over den krypterade text¨overf¨orningen, ¨aven kryptering och vidarebefodring av meddelanden till X-servern4
. Detta leder till att anv¨andaren kan starta grafiska applikationer p˚a datorn med ssh-server, och dessa applikationer presenteras sedan p˚a klientdatorns sk¨arm5
.
2.2.7
SecurID
Ett s¨att att eliminera risken f¨or att n˚agons l¨osenord stj¨als, ¨ar att anv¨anda sig av tokenbaserade[15] system. Det bygger p˚a att anv¨andaren anv¨ander sig av n˚agon form av hemlighet som ¨ar innesluten i n˚agot som denne fysiskt besitter. Detta f¨orsv˚arar f¨or den som vill stj¨ala l¨osenord d˚a denne fysiskt m˚aste stj¨ala hemligheten. Dessutom kan anv¨andaren inte ”l˚ana ut” sitt l¨osenord till bekanta d˚a denne sj¨alv inte kan anv¨anda sig av det under tiden.
SecurID[16] best˚ar av en liten mikroprocessor samt en display, allt utformat som ett litet kreditkort. L¨osenordet, som visas p˚a displayen, ¨ar giltigt i ett antal sekunder. D¨arefter tar SecurID fram ett nytt med hj¨alp av en algoritm. Algoritmen anv¨ander sig av den aktuella tiden samt en hemlighet lagrad i kortet.
Vid autentisering med hj¨alp av SecurID-kort, finns hemligheten i kortet ¨aven lagrad p˚a servern. Eng˚angsl¨osenordet skrivs in av anv¨andaren tillsammans med en personlig kod. Detta skyddar mot att SecurID-kortet kan anv¨andas, om det blivit stulet.
Detta tillv¨agag˚angss¨attet kan upplevas kr˚angligt och besv¨arande f¨or anv¨andarna och b¨or enbart anv¨andas n¨ar kraven p˚a s¨akerhet ¨ar h¨oga.
2.3
S¨
akerhet vid Inloggning
De kanske mest s¨akerhetskritiska punkterna i just inloggningsf¨orfarandet i n¨atverks-milj¨o ¨ar:
Anv¨andarnamn och l¨osenord Det ¨ar mycket viktigt att kontrollera att en anv¨andare av ett system verkligen ¨ar beh¨orig att anv¨anda det. Det finns olika grad av autentisering. Vanligtvis n¨ojer man sig med att l˚ata anv¨andaren ange anv¨andarnamn och l¨osenord som beh¨orighetsbevis. N¨ar kraven p˚a autentisering blir st¨orre kan man t¨anka sig l¨osningar som t.ex. smartcards, d¨ar anv¨andaren m˚aste b¨ara med sig en fysisk ”nyckel” f¨or att f˚a tillg˚ang till systemet. P˚a senare tid har ¨
aven biometrisk inloggning b¨orjat anv¨andas. Detta inneb¨ar att systemet verifierar anv¨andaren med hj¨alp av anatomiska drag. Bland annat fingeravtryck, n¨athinnan och r¨osten kan anv¨andas till detta.
4
X-servern ¨ar det grafiska anv¨andargr¨anssnittet som de flesta Unix- och Linuxsystem anv¨ander sig av.
5
Det finns en milj¨ovariabel, DISPLAY, som ¨ar satt till den datoradress dit X skall skicka sin f¨onsterinformation. N¨ar en anv¨andare sitter och arbetar lokalt ¨ar denna satt till :0.0. Denna information skickas normalt okrypterad till X-servern d¨ar anv¨andaren fysiskt sitter och arbetar. SSH kapslar in detta i sin datastr¨om s˚a att ¨aven den blir krypterad.
2.3 S¨akerhet vid Inloggning 15
Verifiering av systemen N¨astan alltid vill man ha kontroll ¨over att ett system, som vill verifiera en anv¨andare, verkligen ¨ar ett system man kan lita p˚a. Med diverse brandv¨aggsregler och liknande kan man statiskt hindra datorer fr˚an att ansluta till inloggningsservern. Men i vissa fall r¨acker inte detta till. Ett bra exempel p˚a detta ¨
ar om en misst¨ankt angripare fysiskt ansluter sin dator till det lokala n¨atverket. F¨or att kunna bem¨ota denna typ av problem kan man anv¨anda sig av kerberosbaserade inloggningssystem, alternativt certifikat. Dessa metoder ger ett mycket starkt bevis av att en dator verkligen ¨ar det den utger sig f¨or att vara.
S¨aker n¨atverkskommunikation Ett bra s¨att f¨or att skydda sig fr˚an s˚a kallade man-in-the-middle-attacker och liknande ¨ar att kryptera all trafik som g˚ar mellan datorer p˚a n¨atverket. En vanligt anv¨and metod f¨or att kryptera trafiken mellan datorer ¨ar SSL/TLS. Kryptering anv¨ands ofta n¨ar kravet p˚a sekretess ¨ar extra h¨ogt, men kan ¨aven hj¨alpa till att h¨oja integriteten.
2.3.1
Autentisering i Linux
I Linux sk¨ots autentisering av anv¨andare med hj¨alp av Pluggable Authentication Module (PAM) samt Name Service Switch (NSS).
Pluggable Autentication Module
Pluggable Authentication Module (PAM) finns till de flesta UNIX-liknande sys-tem[41]. Det ¨ar ett ramverk f¨or autentisering och r¨attighetskontroll som applika-tioner kan v¨alja att anv¨anda sig av. F¨ordelen med detta ¨ar att applikaapplika-tioner inte beh¨over skrivas om, ifall autentiseringsmetoden beh¨over ¨andras eller bytas ut. Det-ta inneb¨ar i sin tur frihet f¨or administrat¨oren att sj¨alv best¨amma r¨attighets- och autentiseringspolicy f¨or en tj¨anst.
N¨ar en tj¨anst skall anv¨andas finns det ofta ett behov att ta reda p˚a om den aktuelle anv¨andaren ¨ar ber¨attigad till att anv¨anda den. Ursprungligen anv¨ande sig tj¨ansterna av en egen databas eller filen /etc/passwd, d¨ar anv¨andares l¨osenord6
samt anv¨andarnamn finns lagrade. I och med att allt fler datorsystem vill dra nytta av centraliserade resurser finns behovet av att anv¨andare ska f˚a sitt l¨osenord distribuerat ¨over dessa. F¨or att ˚astadkomma detta finns det flera olika l¨osningar, bl.a. NIS+ och LDAP.
Eftersom det finns flera metoder f¨or att ta reda p˚a l¨osenord och anv¨andarnamn beh¨ovs en version av en tj¨anst f¨or varje autentiseringsmetod. Ett system som f¨orlitar sig p˚a NIS+ kommer inte kunna k¨ora samma version av FTP-server som ett system som f¨orlitar sig p˚a LDAP. F¨or att anv¨anda ett visst system f¨or auten-tisering m˚aste alla tj¨anster som skall anv¨anda autentiseringssystemet kompileras om. Det kan leda till en hel del problem f¨or b˚ade systemadministrat¨orer och pro-gramutvecklare. Flera versioner av tj¨ansterna ¨okar ofta risken f¨or programfel, vilka i sin tur kan leda till ¨okade brister i s¨akerheten.
6
I nyare UNIX- och Linux-system lagras l¨osenorden separat i en f¨or vanliga anv¨andare l¨asskyddad fil kallad /etc/shadow
16 Teoretisk bakgrund Användare Klient Server libpamc libpam agenter moduler Klientens pam Serverns pam
Figur 2.5.Strukturen f¨or PAM p˚a Serversida respektive Klientsida.
Ist¨allet f¨or att en tj¨anst anv¨ander egna funktioner f¨or att kontrollera en anv¨and-ares beh¨orighet anv¨ander den ist¨allet ett gr¨anssnitt som tillhandah˚alls av PAM. F¨orfr˚agningar om beh¨orighet skickas till PAM som i sin tur skickar vidare f¨orfr˚ agning-arna till respektive specifik autentiseringsmodul d¨ar kontrollen sker. I fallet med LDAP som autentiseringsmetod konfigureras PAM att anv¨anda modulen
pam ldap.so som ¨ar specialiserad p˚a just autentisering med hj¨alp av LDAP-databaser. En annan f¨ordel med PAM ¨ar att den g˚ar att konfigureras till att anv¨anda flera olika moduler f¨or att autentisera en anv¨andare. Detta g¨or att man till exempel skulle kunna anv¨anda b˚ade l¨osenord och fingeravtryck f¨or autentisering utan att skriva om applikationerna som ber¨ors av det. Ett annat exempel ¨ar att man kan till˚ata anv¨andare som finns b˚ade lokalt och i en centraliserad inloggningsserver att anv¨anda tj¨anster.
Name Service Switch
Lokalt identifieras anv¨andare av systemet av ett idnummer. F¨or att g¨ora omvand-lingen fr˚an id-nummer till mer anv¨andarv¨anlig information har ett system, med liknande uppbyggnad som PAM, utvecklats[40]. Name Service Switch (NSS) heter denna l¨osning. Om en dator anv¨ander sig av centralt distribuerad information av t.ex. NIS+ eller LDAP lagras information om var informationen g˚ar att hitta i /etc/nsswitch.conf. Filen inneh˚aller bla. raderna passwd, shadow och group. passwd: files ldap nis
shadow: files ldap nis group: files ldap nis
2.3 S¨akerhet vid Inloggning 17
F¨or passwd, shadow och group i ovanst˚aende exempel, s¨oks information f¨orst lokalt i en fil, sen via LDAP, sen via NIS. Finns inte den data som s¨oks g˚ar systemet vidare till n¨asta k¨alla och letar.
NSS hj¨alper till att f¨orse program med information om anv¨andare, grupper och datorer etc, en mekanism som har vissa likheter med PAM. I grunden ligger ett antal programmoduler som var och en ¨ar specialiserad p˚a att h¨amta information p˚a sitt s¨att. Bland annat finns det moduler f¨or lokala filer, LDAP och NIS+. I filen /etc/nsswitch.conf kan systemadministrat¨oren konfigurera vilken modul som skall anv¨andas f¨or respektive information. N¨ar sedan ett program vill ta reda p˚a information om t.ex. en anv¨andare anropar det NSS-API som med hj¨alp av r¨att modul tar reda p˚a den.
2.3.2
Autentisering i Windows
I Windows sk¨ots all autentisering av en m¨angd moduler som ansvarar f¨or olika delmoment. Det h¨ar avsnittet kommer att handla om Windows NT, 2000 och XP ef-tersom de ¨ovriga distributionerna inte implementerat n˚agra avancerade s¨akerhetsme-kanismer. LSA Authentication package . . Winlogon.exe GINA SSP SSPI Klient-applikation Interaktiv autentisering Ickeinteraktiv autentisering
Figur 2.6.F¨orenklat schema ¨over inloggning i Windows NT/2000/XP
Centralt f¨or hela processen ligger modulen Local Security Authority (LSA)[26][27]. Den h˚aller reda p˚a vilka anv¨andare som ¨ar inloggade och kontrollerar ¨aven med hj¨alp av en eller flera “authentication packages” vilka anv¨andare som autentiseras. Dessa sk¨oter kommunikationen mot olika databaser f¨or anv¨andarinformation. Det ¨
ar m¨ojligt att skriva ett eget paket, som anv¨ander sig av LDAP f¨or detta. F¨or autentisering, i n¨atverk, anv¨ands ofta ett paket som utnyttjar
18 Teoretisk bakgrund
SMB-protokollet7
[25].
Utvecklarna har valt att dela upp autentiseringar i tv˚a typer; interaktiva och ic-ke interaktiva. Egentligen ¨ar det fr˚aga om autentisering respektive beh¨orighetskont-roll.
Interaktiv autentisering ¨ar den process d˚a en anv¨andare loggar in till systemet genom att p˚a n˚agot s¨att bevisa sin identitet. N¨ar en anv¨andare ska skriva in sitt l¨osenord sker detta i en dialogruta som handhas av winlogon.exe. N¨ar en anv¨andare v¨al loggar in laddas dennes profil in i registret.
Winlogon.exe arbetar med hj¨alp av programbiblioteket GINA. Detta ansvarar bland annat f¨or att maskinen g˚ar att l˚asa med hj¨alp av sk¨armsl¨ackaren. GINA sk¨oter ¨aven kommunikationen mot det underliggande autentiseringssystemet.
Ickeinteraktiv autentisering8
kr¨aver att en anv¨andare redan ¨ar inloggad genom f¨oreg˚aende metod. Eftersom anv¨andaren redan ¨ar autentiserad mot systemet kr¨aver Windows inte att l¨osenord skrivs in p˚a nytt. Detta anv¨ands d˚a en anv¨andares r¨attigheter beh¨over kontrolleras f¨or att denne skall kunna komma ˚at ytterligare tj¨anster n¨ar v¨al den huvudsakliga inloggningen ¨ar avklarad.
7
SMB f¨orv¨axlas ibland med Samba, som ¨ar ett Unixbaserat program som anv¨ander sig av protokollet.
8
Kapitel 3
Implementation
3.1
L¨
amplig niv˚
a f¨
or NSC
3.1.1
Befintliga system
P˚a NSC finns flera superdatorer, arbetsstationer och servrar. Superdatorerna ¨ar av flera olika typer, fr˚an klassiska parallellsystem till skr¨addarsydda linuxkluster.
Den kraftfullaste datorn, en Cray T3E, ¨ar bel¨agen inne p˚a SAAB’s omr˚ade i Link¨oping. D¨ar finns ¨aven en SGI Origin 3800 och en SGI Origin 2000. B˚ade T3E och SGI3800 delas mellan SAAB, SMHI och akademiska anv¨andare. Eftersom SAAB levererar f¨orsvarsutrustning finns h¨oga krav p˚a s¨akerhet. Gemensamt f¨or de b˚ada systemen ¨ar att de anv¨ander sig av tokenbaserad inloggning med hj¨alp av SecurID-kort. Dessutom skiljs anv¨andare ˚at p˚a en l˚ag niv˚a i operativsystemet, s˚a att de inte kan p˚averka varandra.
Som ett led i Link¨opings universitets satsning p˚a 3D-visualisering tillhandah˚aller NSC Lustig1
, en SGI Onyx2.
P˚a senare ˚ar har man p˚a NSC b¨orjat bygga PC-kluster. Det ¨ar en samling spe-cialdesignade persondatorer kopplade i ett lokalt n¨atverk. Med hj¨alp av mjukvara f˚ar man datorerna att samarbeta f¨or att l¨osa st¨orre ber¨akningsuppgifter.
Det st¨orsta klustret i dagsl¨aget ¨ar Ingvar2
, som finns i NSC’s lokaler. NSC har n¨ara arbete med ett flertal andra centra runt om i landet och har hj¨alpt till med uppbyggandet av kluster d¨ar. Grendel, som ¨ar ett av dessa kluster, ¨ar bel¨aget i Uppsala och anv¨ands av bland annat forskare och studenter i Link¨oping och Uppsala. Detta kluster utg¨or ¨aven en ber¨akningsresurs f¨or NorduGrid3
som ¨ar ett samarbete mellan superdatorcentra i de nordiska l¨anderna.
Ett annat kluster som drivs i NSCs regi heter WhenIm64 och ¨ar placerat p˚a Lunds Datorcentral.
1
Lustig st˚ar f¨or Link¨opings universitets satsning p˚a till¨ampningar inom datorgrafik.
2
Namnet kommer av att hela klustret ¨ar monterat i IKEA-bokhyllor.
3
www.nordugrid.org
20 Implementation Grendel LiuNet Internet Andra centra Brandvägg kluster LUSTIG Brandvägg SAABnet T3E SGI3K servrar skrivare arbetsstationer
Figur 3.1.De befintliga resurserna ¨ar utspridda geografiskt och kommunikationen g˚ar inte alltid ¨over n¨atverk som vi kan lita p˚a.
Ut¨over detta finns ett tjugotal arbetsstationer p˚a NSC som k¨or antingen Win-dows eller Linux som operativsystem. Dessutom finns ett antal servrar bland annat f¨or att sk¨ota www, ftp, DNS, epost etc. ¨Aven en Samba-server finns f¨or att sk¨ota centraliserad autentisering f¨or de arbetsstationer som anv¨ander sig av Windows.
3.1.2
Vad man vill f¨
orb¨
attra
Som situationen ser ut nu lagras anv¨andarinformation lokalt p˚a varje superdator, server och Linux-arbetsmaskin. De Windowsbaserade arbetsstationerna anv¨ander sig av Samba f¨or att centralisera autentiseringen.
Om all information om anv¨andare ist¨allet lagras centralt kommer detta un-derl¨atta f¨or anv¨andarna av n¨atverket. Det kommer bland annat att minska f¨orvirr-ingen som flera l¨osenord/anv¨andarnamn f¨or samma anv¨andare kan leda till. ¨Aven administration av systemen kommer underl¨attas d˚a man f˚ar b¨attre ¨oversikt ¨over vilka anv¨andare som finns samt vilka datorer de har r¨att att anv¨anda.
3.1.3
S¨
akerhetsniv˚
an p˚
a NSC
Som alltid i s¨akerhetsfr˚agor m˚aste man hitta en balans mellan vad som verkligen ¨ar krav p˚a systemen, och vad som ¨ar ¨onskv¨art att uppn˚a. Balansen mellan s¨akerhet och
3.1 L¨amplig niv˚a f¨or NSC 21
Användbarhet
Säkerhet
Tillgänglighet
!
Figur 3.2.3 Viktiga h¨ornstenar.
anv¨andarv¨anlighet m˚aste noga ¨overv¨agas och bet¨ankas. Total s¨akerhet utesluter i m˚anga fall anv¨andarv¨anlighet, och total anv¨andarv¨anlighet utesluter i m˚anga fall h¨ogre niv˚a av s¨akerhet.
Anv¨andarnamn och l¨osenord P˚a NSC ¨ar kravet p˚a s¨akerhet tillr¨ackligt stort f¨or att man ska vilja ha kontroll s˚a att anv¨andarens identitet (anv¨andarnamnet) g˚ar att sp˚ara direkt tillbaka till en anv¨andare, och endast en anv¨andare.
Det enda l¨osenordet som delas ¨ar root-l¨osenord p˚a de olika systemen. Detta delas av administrat¨orerna f¨or systemen p˚a NSC. F¨or det vanliga inloggninsf¨orfarandet bed¨oms det att anv¨andarnamn och l¨osenord ger tillr¨acklig s¨akerhet.
De system som har extra h¨og krav p˚a s¨akerhet (fr¨amst de en g˚ang B1-evaluerade systemen) anv¨ander SecurID-kort. S¨akerhetskraven p˚a dessa system g¨or det v¨aldigt omst¨andigt att implementera centraliserad autentisering av anv¨andare. B1-klassn-ing[31] p˚a ett datorsystem inneb¨ar v¨aldigt h¨og niv˚a av s¨akerhet. Endast B2, B3 och A ¨ar h¨ogre klassningar, men det finns n¨astan inga s˚adana system tillg¨angliga f¨or allm¨anheten.
F¨or de ”vanliga” systemen som kontorsdatorer och PC-kluster ¨ar anv¨andarnamn och l¨osenord fullt tillr¨ackligt autentiseringsf¨orfarande. Eftersom l¨osenord ¨ar s˚apass personligt ¨ar kryptering vid lagring av l¨osenord ett absolut krav.
Verifiering av systemen F¨or att uppn˚a ytterligare s¨akerhet av systemen och g¨ora det sv˚art f¨or utomst˚aende att komma ˚at n¨atverket p˚a NSC kr¨avs ¨aven n˚agon form av starkare bevis p˚a att ett system verkligen tillh¨or NSC. D¨arf¨or ¨ar n˚agon form av mjukvarucertifikat f¨or systemen ett krav.
S¨aker n¨atverkskommunikation En del av kommunikationen som sker p˚a n¨atverket ¨ar k¨anslig. Det r¨or sig om allt fr˚an anv¨andarinformation och l¨osenord till information som r¨or kunderna. V˚ar l¨osning arbetar framf¨orallt med l¨osenord och denna typ av trafik m˚aste krypteras.
22 Implementation
3.1.4
Hur man ska ˚
astadkomma denna f¨
orb¨
attring
Genom att bygga en server som tar hand om autentisering och information om de olika systemen kan man samla all information centralt. Denna eller dessa servrar m˚aste dock byggas p˚a ett s˚adant s¨att att den b˚ade ¨ar kompatibel med windowsk-lienter och unix/linux-kwindowsk-lienter. Den m˚aste vara fullt funktionsdugligt, och noga testas innan den kan tas i drift. Detta kr¨aver att en t¨ankt l¨osning m˚aste kun-na st¨allas upp vid sidan av de nuvarande systemen, f¨or testning och utv¨ardering. Verktygen m˚aste vara flexibla och l¨atta att utveckla vidare f¨or framtida syften, som t.ex. autentisering av datorer p˚a skilda orter.
3.2
F¨
oreslagen l¨
osning
Windows arbetsstation Server Linux arbetsstation Användar-katalog Beowulf-system SuperdatorFigur 3.3.F¨oreslagen l¨osning. Att samla information om anv¨andare p˚a ett st¨alle skulle underl¨atta administrationen av systemen.
En l¨osning m˚aste vara effektiv, l¨att att administrera och framf¨or allt s¨aker. Vi bed¨ommer att LDAP kan vara en l¨amplig komponent i en s˚adan l¨osning.
Som hj¨arta i v˚ar l¨osning finns en LDAP-server som hanterar anv¨andar- och gruppinformation. OpenLDAP ¨ar en ¨oppen serverl¨osning som kan k¨oras under Li-nux. OpenLDAP kan lagra anv¨andarinformation p˚a ett stabilt och effektivt s¨att som passar situationen.
3.2 F¨oreslagen l¨osning 23
direkt till servern med fr˚agor om autentisering och f¨or att komma ˚at diverse infor-mation.
Det finns f¨or n¨arvarande ingen version av Windows som st¨oder direkt koppling mot en OpenLDAP-server. Om en LDAP-server skall anv¨andas kr¨aver Windows att den f¨oljer Microsofts egna “standard” f¨or LDAP. S˚aledes kan enbart Active Directo-ry anv¨andas. Som systemet var upplagt, anv¨ande sig NSCs Windows-datorer av en Samba-server f¨or autentisering. Denna server f˚ar ers¨atta sin egen databas med an-rop till LDAP-servern.
Systemet ¨ar l¨att att installera och n¨ar det v¨al ¨ar uppe r¨aknar vi inte med mycket underh˚all. Administration av anv¨andare kan enkelt ske med hj¨alp av Perl-skript eller grafiska verktyg.
3.2.1
S¨
akerhet
F¨or att uppr¨atta en krypterad f¨orbindelse anv¨ands TLS. N¨ar f¨orbindelsen uppr¨attats med hj¨alp av TLS sker krypteringen transparent f¨or applikationerna. De anslut-ningar det ¨ar fr˚aga om ¨ar de mellan klienterna och servern. Med klienter i detta fall menar vi de arbetsstationer dit anv¨andare vill logga in. Dessa arbetsstationer ansluter sig till LDAP-servern f¨or att verifiera autentiseringsinformation. Eftersom Samba-servern k¨ors p˚a samma dator som OpenLDAP finns det inget sk¨al att kryp-tera f¨orbindelsen mellan dem.
TLS
Nyckelcertifikat
Figur 3.4.F¨orst ¨overf¨ors serverns certifikat till klienten f¨or att s¨akerst¨alla serverns iden-titet. Sedan sker all datakommunikation krypterad med TLS.
Det ¨ar viktigt att kunna kontrollera vilka som har r¨att att l¨asa k¨anslig infor-mation fr˚an v˚ar LDAP-server. Det finns flera olika metoder f¨or att ˚astadkomma detta.
LDAP-servern kommer att konfigureras s˚a att kataloganv¨andare4
m˚aste ange l¨osenord n¨ar de ansluter till den. Beroende p˚a l¨osenordet d¨oljs vissa f¨alt i katalogen. Detta g¨or att vi kan till˚ata anonyma s¨okningar i katalogen f¨or att t.ex. anv¨anda
4
Kataloganv¨andare b¨or inte f¨orv¨axlas med anv¨andare av datorsystem. En post om en anv¨andare i katalogen ¨ags av en kataloganv¨andare. I v˚art fall h¨amtas informationen om den-na kataloganv¨andare ur posten och f˚ar d¨arf¨or samma namn och l¨osenord som datoranv¨andaren. Skillnaden ¨ar vad anv¨andarkontot anv¨ands till.
24 Implementation
katalogen som telefonkatalog. Samtidigt kan samma katalog, med r¨att l¨osenord, anv¨andas i autentiseringsprocessen.
N¨ar man g¨or ett anrop till servern och st¨aller en fr˚aga anv¨ander man n¨amligen ett binddn5
, som identifierar vem man ¨onskar ansluta sig som. En anonym anv¨andare ansluter inte med n˚agot namn och hanteras d¨arf¨or anonymt, medan anv¨andare och administrat¨orer vanligen ansluter sig med sitt eget namn, och tillh¨orande l¨osenord, f¨or att verifiera att den som ansluter sig verkligen ¨ar den den utger sig f¨or att vara. F¨alt som man vill skydda kan vara t.ex. l¨osenord, eller hemliga uppgifter, medan andra uppgifter som epostadress och namn m.m. vanligen ¨ar tillg¨angliga f¨or alla att l¨asa och s¨oka upp.
PAM
NSS
App.skikt
Windows
Linux
arbetsstation
Server
arbetsstation
Samba
LDAP
App.skikt
GINA
LSA
Figur 3.5.Centrala moduler, i arbetsstationer och server, som anv¨ands under autentise-ringsprocesserna.
¨
Aven om dessa l¨osenord kommer att skickas ¨over en krypterad f¨orbindelse kan man fortfarande ut¨oka s¨akerheten ytterligare. Om man begr¨ansar skaran datorer som f˚ar ansluta med hj¨alp av denna typ av l¨osenord eliminerar man risken f¨or att en utomst˚aende dator lyckas kn¨acka l¨osenordet genom gissningar. Vidare kan slarv och andra omst¨andigheter leda till att obeh¨origa kommer ¨over l¨osenord.
Kerberos och nyckelcertifikat ¨ar tv˚a metoder som vi kan anv¨anda f¨or att ytter-ligare ¨oka s¨akerheten och ha kontroll p˚a vilka datorer som ansluter till v˚ar LDAP-server. Vi tror att inte att Kerberos har n˚agon plats i en l¨osning f¨or NSC. Kerberos kr¨aver en server f¨or detta och en hel del konfigurationsarbete. Vidare ger en l¨osning med Kerberos i v˚art fall egentligen inte h¨ogre niv˚a av s¨akerhet ¨an ett r¨att konfigu-rerat system med nyckelcertifikat.
Vi ser nyckelcertifikat som ett komplement till LDAP’s l¨osenord i v˚ar l¨osning. Genom att anv¨anda certifikat f¨or servern kan vi fastst¨alla dennes identitet. Det viktigaste ¨ar att klienten kan lita p˚a att servern verkligen ¨ar vem den utger sig f¨or att vara, s˚a inga l¨osenord skickas ¨over till en falsk server. Detta skulle kunna h¨anda
5
N¨ar n˚agon ansluter till en LDAP-server kallas det att denne binder sig till den. Ett binddn ¨
3.3 Klientsidan 25
om n˚agon ansluter en falsk LDAP-server till n¨atet och, “stj¨al” den riktiga serverns IP-adress. Om detta h¨ander kommer en intet ont anande klient (som inte kr¨aver att f˚a verifiera serverns certifikat) att skicka ¨over det hemliga l¨osenordet till den falska servern.
3.3
Klientsidan
3.3.1
Linuxklienter
F¨or att anv¨anda OpenLDAP p˚a en linuxklient kr¨avs ett paket som heter
“OpenLDAP Client utilities”. Paketet inneh˚aller klientprogram som ger tillg˚ang till OpenLDAP-kataloger. F¨or att anv¨anda LDAP f¨or autentisering kr¨avs ¨aven paketen pam ldap samt nss ldap[23].
Inloggningsf¨orlopp
N¨ar en anv¨andare vill logga in p˚a en arbetsstation anv¨ands datorns PAM och nsswitch. De ¨ar b˚ada konfigurerade att ansluta till LDAP-servern f¨or att h¨amta och lagra information.
LDAP
Figur 3.6. N¨ar en anv¨andare vill anv¨anda en Linuxdator ansluter sig denna dators autentiseringssystem direkt till LDAP-servern. Denna anslutning uppr¨attas med det anv¨andarnamn respektive l¨osenord som anv¨andaren skrivit in. Anv¨andarens autentise-ringsinformation i LDAP och i Linux ¨ar i detta fall identiska.
Undantaget fr˚an denna regel ¨ar lokala anv¨andarkonton, framf¨or allt root, som har prioritet ¨over konton som ligger i LDAP. Detta f¨or att man ska undvika ett globalt administrat¨orskonto med flera anv¨andare. I verkligheten administreras sy-stemen av flera personer som har skilda ansvarsomr˚aden. Det ¨ar en on¨odig risk att l˚ata flera ha administrat¨orsr¨attigheter p˚a alla system. Vidare skulle det kunna uppst˚a problem n¨ar flera organisationer ansluts till LDAP-servern, -ska en global administrat¨or f˚a existera?
26 Implementation
LDAP
A
B
Figur 3.7.Dator B ¨ar en Linuxdator som anv¨ander sig av LDAP f¨or autentisering som i f¨oreg˚aende bild. N¨ar en anv¨andare p˚a dator A vill ansluta sig till dator B, f¨or att anv¨anda sig av n˚agon tj¨anst (t.ex. ssh eller imap), kommer dator B att sk¨ota autentiseringen som i f¨oreg˚aende fall.
3.3.2
Inloggningsf¨
orloppet p˚
a en windowsklient
Tidigare har arbetsstationerna som k¨or Windows anslutit sig till en Samba-server som fungerat som inloggningsserver f¨or dom¨anen. Sett ur dessa arbetsstationers perspektiv har inget f¨or¨andrats.
Samba
LDAP
Figur 3.8. N¨ar en anv¨andare vill anv¨anda en Windowsdator ansluter sig datorn till Samba-servern som har hand om windowsdom¨anen. Samba-servern i sin tur ansluter sig till LDAP-servern f¨or att h¨amta/lagra anv¨andarinformation. Den senare f¨orbindelsen uppr¨attas med hj¨alp av administratorkontot i LDAP som finns lagrat i Sambas konfigu-rationsfiler.
3.3.3
Superdatorer som klienter
Superdatorerna anv¨ander sig av Trusted IRIX, som ¨ar ett Unix-baserat operativ-system. Dessa delar upp anv¨andare och processer i fack och i s¨akerhetsniv˚aer. Att ¨
andra i autentiseringsprocessen ¨ar d¨arf¨or inte helt trivialt. N˚agra f¨ardiga l¨osningar f¨or detta existerar troligen inte. Detta inneb¨ar att autentiseringen p˚a Superdato-rerna tillsvidare f¨orblir som den ¨ar idag.
3.4 Serversidan 27
3.4
Serversidan
Vi l˚ater en dator fungera som server f¨or v˚ar l¨osning. P˚a denna installerar vi OpenLDAP och Samba. Dessa anv¨ands av arbetstationerna till deras autentise-ringsprocesser.
3.4.1
OpenLDAP
Vi anv¨ander oss av en vanlig installation av OpenLDAP f¨or att sk¨ota v˚ar kata-log. I denna sparar vi kontoinformation f¨or anv¨andare i systemet. Linuxdatorerna ansluter direkt till denna f¨or att f˚a tag i information som anv¨ands vid autentisering. Eftersom Windows och Linux byggt upp sitt s¨att att hantera anv¨andare p˚a vitt skilda s¨att m˚aste en hel del data om anv¨andarna dubbellagras. Ett exempel p˚a detta ¨ar l¨osenorden; Linux anv¨ander sig av ett l¨osenord som kan vara krypterat p˚a olika s¨att medan Windows anv¨ander sig av tv˚a stycken krypterade med Microsofts egna algoritmer. N˚agot smidigt s¨att att undvika denna dubbellagring finns inte i nul¨aget.
¨
Aven om l¨osenorden aldrig skickas i klartext ¨over n¨atverket ¨ar det inte ¨onskv¨art att n˚agon kommer ¨over dessa. Speciell mjukvara kan omvandla krypterade l¨osenord till klartext genom en tidskr¨avande process. Annan information som lagras i LDAP kan ¨aven den komma att skickas ¨over n¨atverket. D¨arf¨or anv¨ander sig denna server av en krypterad f¨orbindelse med hj¨alp av TLS.
Vi vill inte l˚ata denna s¨akerhets˚atg¨ard p˚averka tillg¨angligheten negativt. Att kunna konfigurera sitt emailprogram att anv¨anda LDAP som en adressbok ¨ar ¨
onskv¨art och dessa operationer ¨ar ofta anonyma och st¨oder inte TLS. D¨arf¨or ¨ar LDAP-servern ¨aven konfigurerad att ta emot anonyma anslutningar utan TLS. Vid denna typ av anslutning har vi l˚ast k¨ansliga f¨alt mot l¨asning.
3.4.2
Samba-servern
Som en inloggningsserver[22] f¨or windowsdom¨anen har vi satt upp en Samba-server. Den ansvarar f¨or anv¨andarautentisering, n¨atverksskrivare och fildelning.
Vi har h¨amtat hem k¨allkoden till Samba och kompilerat den med LDAP-st¨od, n˚agot som inte finns med i standardutf¨orandet. Samba-servern lagrar all informa-tion om datorer, anv¨andare och grupper i LDAP-servern, dit den ansluter med en TLS-krypterad f¨orbindelse.
Eftersom de b˚ada servrarna ligger p˚a samma dator finns inget egentligt krav p˚a en krypterad f¨orbindelse men eftersom LDAP-servern i framtiden kan komma att flyttas till en annan dator har vi f¨orberett f¨or detta.
3.4.3
Utv¨
ardering av programvara
Det finns ett antal organisationer som regelbundet rapporterar brister i program-vara vilka kan ¨aventyra s¨akerheten. Tv˚a av dem ¨ar CERT och SecurityFocus. Vi har s¨okt i deras arkiv f¨or att se om programvarorna i v˚ar l¨osning ¨ar s¨akra.
28 Implementation
Det finns f¨or n¨arvarande inga k¨anda brister i de versioner6
av OpenLDAP och Samba som vi valt att anv¨anda. Detta ¨ar ingen garanti f¨or att dessa versioner ¨ar helt fria fr˚an brister, utan enbart att de inte blivit uppt¨ackta ¨annu. Det ¨ar viktigt att man regelbundet utnyttjar tj¨anster som informerar om s¨akerhetsbrister s˚a att man i tid blir varse de problem som kan uppst˚a. Oftast kommer en ny version av programvaran ut samma dygn.
Genom att blicka tillbaka p˚a tidigare brister kan man m¨ojligtvis f¨orutsp˚a vilken typ av problem som kan komma att uppst˚a i framtiden och dessutom se vilken kvalitet programvaran h˚aller.
Vidare ¨ar det vanligt bland hackers att f¨ors¨oka hitta brister liknande de som tidigare funnits. D¨arf¨or kan man s¨aga att de brister som mest sannolikt kommer att dyka upp liknar de som varit. Om en brist uppt¨acks i ett program kommer hackers att f¨ors¨oka utnyttja det i liknande program. N¨ar en ny feltyp uppt¨acks i ett liknande program skall man vara extra vaksam, eftersom ens egna program inte ¨
annu hunnit testas.
S¨akerhetsbrister i OpenLDAP
Historiskt sett har det inte f¨orekommit s˚a m˚anga brister, och de som varit har inte varit s˚a allvarliga.
• D˚a ett par andra tillverkares LDAP-servrar har haft problem med att h˚alla sekretessen, har inga s˚adana rapporterats r¨orande OpenLDAP. F¨or att n¨amna ett exempel har Oracles l¨osning[5] haft en rad problem med detta, d¨ar anv¨and-are kunnat l¨asa skyddad information som de inte skall ha tillg˚ang till. • Under f¨orsta kvartalet 2002 har tv˚a brister r¨orande katalogens tillf¨orlitlighet
rapporteras. B˚ade anonyma[38] och autentiserade[39] anv¨andare kunde rade-ra data ur katalogen, under vissa f¨oruts¨attningar.
• Ett utf¨orligt test[3] av de vanligaste LDAP-servrarna7
utf¨ordes under 2001. Det visade sig att flera av dem, d¨aribland OpenLDAP[6][35], inneh¨oll svaghe-ter som kunde utnyttjas vid denial-of-service-attacker. En str¨om av felaktiga f¨orfr˚agningar till OpenLDAP-servern kunde f˚a den att drastiskt f¨orlora pre-standa.
S¨akerhetsbrister i Samba
Samba och andra tj¨anster som utnyttjar SMB-protokollet har inneh˚allit en del allvarliga s¨akerhetsh˚al de senaste ˚aren[34][33]. Sen dessa uppt¨ackts och ˚atg¨ardats under det senaste ˚aret har inga s¨akerhetsbrister rapporteras.
De senaste h¨andelserna av vikt intr¨affade under 2001. Sambaservern k¨ors av en anv¨andare som har relativt omfattande skrivr¨attigheter. Genom att skicka felakti-ga anrop till servern lyckades anv¨andare f˚a den att skriva till filer p˚a servern. Det
6
OpenLDAP version 2.0.23, Samba version 2.2.5
7
3.4 Serversidan 29
allvarligaste var att man i vissa fall kunde skriva direkt till l¨osenordsfilerna p˚a ser-vern. En rad rapporter[36][37][4] visade att man kunde p˚averka serverns p˚alitlighet och i v¨arsta fall ge sig sj¨alv f¨orh¨ojda r¨attigheter.
Kapitel 4
Diskussion
4.1
F¨
ordelar med v˚
ar l¨
osning
All data f¨or anv¨andarhantering kommer att lagras p˚a ett st¨alle1
och ¨andringar som g¨ors i databasen p˚averkar alla system omedelbart. Det tidigare var att anv¨andar-information fanns lagrad i flera system och t.ex. ett l¨osenordsbyte skulle beh¨ova g¨oras flera g˚anger; en g˚ang p˚a varje system. Administrat¨oren f˚ar enkelt en bra ¨
oversikt ¨over vilka som har tillg˚ang till de olika delsystemen genom att anv¨anda verktyg som anv¨ander sig av LDAP-databasen.
4.2
Skydd av n¨
atverket
N¨ar k¨anslig data, s˚a som l¨osenord, skickas ¨over ett n¨atverk m˚aste den skyddas. Vi har implementerat tv˚a mekanismer f¨or att ˚astadkomma detta.
F¨orst och fr¨amst ¨ar alla f¨orbindelser d¨ar l¨osenord f¨orekommer krypterade med TLS . Detta g¨aller inte windowsklienterna som anv¨ander sig av de protokoll som ¨
ar standard f¨or Windows 2000. Vi har gjort bed¨omningen att detta, i nul¨aget, inte ¨
ar n˚agot problem f¨or de f˚atal windowsdatorer det r¨or sig om.
F¨or att ytterligare ¨oka s¨akerheten anv¨ander vi oss av servercertifikat. Detta f¨or att ingen skall kunna utge sig f¨or att vara servern och p˚a s˚a s¨att komma ¨over k¨anslig information. OpenLDAP-servern anv¨ander sig av vanliga certifikat genererade med OpenSSL.
I Samba fungerar det annorlunda. N¨ar en klient ansluter sig till windows-dom¨anen f¨or f¨orsta g˚angen genereras tv˚a ”datorl¨osenord” som anv¨ands varje g˚ang en dator startas och vill ansluta sig till dom¨anen p˚a nytt. Dessa l¨osenords funktion kan liknas med nyckelcertifikat.
Vi har kommit fram till att Kerberos erbjuder s¨akra m¨ojligheter f¨or att verifiera systems identiteter. Om vi skulle anv¨anda oss av detta skulle v˚ar l¨osning inte vara
1¨
Aven i ett ut¨okat system, d˚a datan replikeras ¨over flera LDAP-servrar och existerar fysiskt p˚a flera st¨allen, kan datam¨angden ses som en.
