DNSSEC-rapport Regionförbundet i Kalmar Län

Transkript

1 Page 1 (29) Rickard Bellgrim, rickardb@certezza.net Karl Castor, karl@certezza.net Certezza AB Stockholm DNSSEC-rapport Regionförbundet i Kalmar Län Kornhamnstorg 61, 2 tr SE Stockholm Sweden Telefon: +46 (0) Telefon: +46 (0)

2 Page 2 (29) Innehållsförteckning 1 Inledning Bakgrund Syfte Frågeställning Avgränsningar Metod Krav Fysisk säkerhet Administrativa kontroller Personorienterade kontroller Loggning Teknisk säkerhet DNS Zonsignering Rutiner Dokumentation Övrigt Nulägesanalys Svar i nulägesrapporten som strider mot SKALL-krav Svar i nulägesrapporten som skiljer mot BÖR-krav Lösningsförslag MGMT (Management) DNSSEC Master Slave Registrar Lösningsförslag 1 Internt Lösningsförslag 2 Externt Lösningsförslag 3 Mix Lösningsförslag 4 Mix Implementationer Internt Externt Blandat Förvaltning Dokumentation Drift Backup Övervakning Felsökning Uppgradering Fortsatt arbete DNSSEC-policy Kurser Gemensam lösning Framtida användning av DNS Validering av DNSSEC Signering av övriga zoner Bilaga A Krav på DNSSEC Bilaga B Nulägesrapport... 27

3 Page 3 (29) Ordförklaringar DNS DNSSEC DP DPS DS FIPS HSM KASP KSK M-av-N NSEC NSEC3 PIN SA SO Säkerhetsmodul TLD TTL Zon ZSK Domain Name System DNS Security Extensions DNSSEC Policy. En övergripande policy på hur DNSSEC ska hanteras i organisationen. DNSSEC Practice Statement. En beskrivning på hur DNSSEC faktiskt tillämpas i organisationen. Delegation Signer. Är en DNS-post där föräldrazonen pekar ut en nyckel i barnzonen som kan användas vid validering av DNSSEC. En amerikansk säkerhetsstandard för säkerhetsmoduler. Hardware Secuirty Module. Specialiserad hårdvara som fysiskt skyddar nycklarna samt kan ge ökad kryptografisk prestanda. Key And Signing Policy Key Signing Key. Huvudnyckeln som signerar det nyckelset som används vid signering av zonen. Flerpersonskontroll. Ett antal, M, personer ur en betrodd grupp, N, måste vara på plats för att en operation skall få genomföras. Next Secure. En DNS-post för DNSSEC som används vid autentisering av negativa DNS-svar. Next Secure 3. Vidareutveckling av NSEC. Personal Identification Number. Lösenord. System Administrator. Systemadministratör. Security Officer. En betroddroll som ansvarar för säkerheten i systemet. Se HSM. Top-Level Domain. Toppdomän. Time to Live. Tiden som DNS-information sparas i en resolver. Är den del i DNS-namnrymden till vilket organisationen har fått ett tilldelat administrativt ansvar. Zone Signing Key. En underliggande nyckel som signerar informationen i zonen.

4 Page 4 (29) 1 Inledning 1.1 Bakgrund Myndigheten för samhällskydd och beredskap (MSB), i samarbete med Kommunikationsmyndigheten PTS, Sveriges kommuner och landsting (SKL) och.se, genomför ett projekt där kommuner via länsstyrelserna kan söka medel från anslag 2:4 Krisberedskap för att införa säker adressering (DNSSEC) på Internet. Kommunerna i Kalmar län tillsammans med Regionförbundet har ansökt om och har fått beviljat medel för införande av DNSSEC. Ett länsgemensamt projekt för införandet av DNSSEC har startats upp, men innan projektet går igång helt behöver en förstudie genomföras. Genom en upphandling blev Certezza tilldelade att genomföra denna förstudie åt Regionfördbundet i Kalmar län. 1.2 Syfte Syftet med förstudien är att visa på hur kommunernas DNS ser ut idag och vad som behöver åtgärdas för att ge ökad robusthet och tillförlitlighet för de kommunala namnservrarna. 1.3 Frågeställning I upphandling fanns följande frågeställningar: Visa på vilka krav som minst skall uppfyllas för säker DNS, DNSSEC, nyckelhantering, kompetenskrav, dokumentation och rutiner. o Se kapitel 2 Visa på ett antal scenarion att implementera säker DNS och hur man bör gå tillväga för respektive implementation. o Se kapitel 4 Rekommendera mjuk- respektive hårdvara som uppfyller ställda krav vid drift i egen regi. o Se kapitel 5.1 Rekommendera leverantörer vid extern drift som uppfyller ställda krav. o Se kapitel 5.2 Ge rekommendationer på olika samarbetsformer mellan kommuner, för t.ex. redundans. o Se kapitel 4.8, 4.9, 5.3 och 7.3 Visa på hur man bör hantera tjänster som ligger utanför kommunernas egen regi vad gäller säker DNS. o Se kapitel 2 Ange vilken dokumentation/policy som är nödvändig och ajourhållas. o Se kapitel 6.1 Visa på hur drift, backup, övervakning och felsökning av DNS och DNSSEC kan ske. o Se kapitel 6 Visa på hur en framtida utveckling av DNS i länet och relaterade funktioner som kan användas och utvecklas. o Se kapitel 4 och 7.4 Visa på hur implementation av DNSSEC kan verifieras internt och av extern part. o Se kapitel 6.4 Vara leverantörs- och produktoberoende och resultera i en skriftlig rapport som överlämnas och presenteras för beställaren efter överenskommelse med projektledaren. o Se denna rapport

5 Page 5 (29) 1.4 Avgränsningar Rapporten skall vara leverantörs- och produktoberoende varvid flera lösningar och leverantörer nämns, men att det är upp till projektet gå vidare med respektive förslag. 1.5 Metod Resultatet i detta arbete grundar sig i en uppsättning krav som avspeglar god tillförlit samt rådande rekommendationer. Dessa krav tillsammans med lösningsförslag presenterades under en workshop tillsammans med de tolv kommunerna i Kalmar län. Utifrån diskussionerna har kraven och förslagen reviderats, vilka går att finna i denna rapport.

6 Page 6 (29) 2 Krav En del av arbetet är att visa på vilka krav som minst skall uppfyllas för säker DNS, DNSSEC, nyckelhantering, kompetenskrav, dokumentation och rutiner. Dessa krav är ofta några som brukar formuleras i en DNSSEC-policy (DP). En liknande strukturering, som i ett sådant dokument, har använts i detta arbete. Styckena nedan är en sammanfattning av de kompletta kraven som går att finna i Bilaga A. Utgångspunkten i kraven är att ge kommunerna en robust, resurseffektiv och tillförlitlig lösning. 2.1 Fysisk säkerhet Det viktigaste att tänka på är att enbart behörig personal skall få tillgång till de datorsystem som hanterar DNSSEC. Skulle obehöriga få tillgång till utrymmet kan de logiska skydden relativt enkelt sättas ur spel. Utöver tillträdesskydd ger en bra serverhall skydd mot brand, vätska, strömavbrott, och liknande. Skydd mot korta strömavbrott skall åtminstone finnas på plats. Om inte de övriga skydden finns, så är det viktigt att man har bra rutiner och säkerhetskopior för att komma igång på en alternativ driftsplats. 2.2 Administrativa kontroller Vad gäller administrationen av DNSSEC-systemet är det väsentligt att skydda de processer och arbetsflöden som hanterar känsliga uppgifter. Detta görs genom att minst två betrodda personer kan aktivt godkänna och/eller verifiera att rätt kommandon, rutiner, och processer följs. Främst avses hanteringen av de privata nycklarna samt export av tillitsankare. Dessa komponenter är vad som utgör grunden för DNSSEC. 2.3 Personorienterade kontroller Personalen som arbetar med systemen behöver ha rätt utbildning och bakgrund för att kunna genomföra sina uppgifter på ett säkert och effektivt sätt. Kunskapsnivån säkerställs genom utbildningar och dokumentation av systemen. 2.4 Loggning Genom ett bra loggningsarbete kan händelser och incidenter följas upp. För det mesta sköter systemen loggning automatiskt, men de känsliga processer och rutiner som inte har automatisk loggning krävs det manuell hantering genom att exempelvis notera händelsen i en loggbok. Loggarna skall skyddas mot otillbörlig förändring, vilket oftast sker genom åtkomstregler på det lokala systemet. Det är däremot starkt rekommenderat att ha ett centralt loggsystem för att säkerställa tillgängligheten men även försvåra manipulation. 2.5 Teknisk säkerhet De privata nycklarna som används för DNSSEC skall enbart hanteras på det system där de skall användas, om inte en tillförlitlig överföring kan säkerställas. Enbart godkända processer och användare skall ha tillgång till nycklarna, detta för att minimera risken att de kan läcka från systemet. Vidare måste säkerhetskopior av nycklarna göras för att säkerställa den framtida driften. Systemet som hanterar DNSSEC-signeringen skall placeras på det interna nätverket som en så kallad hidden-master. De privata nycklarna skyddas då av flera logiska lager och är därmed inte direkt tillgänglig från Internet.

7 Page 7 (29) 2.6 DNS Robustheten i DNS uppnås genom att informationen finns replikerad på flera servrar. Det är därför viktigt att tillgängliggöra informationen så att den finns på minst två skilda nätverk (AS-nummer). Kan bland annat uppnås genom att använda två oberoende operatörer. 2.7 Zonsignering De krav som ställs vad gäller zonsignering följer rådande rekommendationer och ger en lägsta nivå som skall följas. Värt att tänka på är att använda en algoritm som är allmänt tillgänglig och resurseffektiv för alla inblandade parter. DNSSEC introducerar absoluta tider i och med de digitala signaturerna, som har en starttid och en sluttid vad gäller dess giltighet. Utgångspunkten i detta läge är att det skall finnas tillräckligt med tid för att få personal på plats samt genomföra felsökning innan signaturerna går ut. 2.8 Rutiner Många punkter i DNSSEC kan automatiskt hanteras av programvaran, men däremot kräver många fall att tillitsankaret (DS-post) måste hanteras manuellt då automatiskt gränssnitt mellan programvara och registrar saknas. Det måste därför finnas rutiner på plats som hanterar dessa fall och kan ge en god tillförlitlighet att förändringarna sker på rätt sätt. 2.9 Dokumentation Utifrån kraven som nämnts här kan kommunen lätt skapa en säkerhetsdeklaration som beskriver hur DNSSEC genomförs för sina egna domäner. Ett sådant dokument kan dels skapa tillit på systemet, dels ge personalen en bra dokumentation om hur arbetet och egenskaparna för DNSSEC ser ut. Dokumentet kan även användas vid interna revisioner. För att kunna göra ett bra informationssäkerhetsarbete inom en organisation så behövs det dokumenterade policy, processer, rutiner, och motsvarande. Saknas ett sådant arbete så måste riktlinjer och dokument skapas kring bland annat logghantering och kontinuitetsplanering Övrigt IT-säkerhet är föränderligt och måste ses över med jämna mellanrum. Minst vartannat år måste systemet, rutiner, policyn, och liknande som hanterar DNSSEC ses över.

8 Page 8 (29) 3 Nulägesanalys Sammanställning av nulägesrapporten finns i Bilaga B 3.1 Svar i nulägesrapporten som strider mot SKALL-krav Fysisk säkerhet 1 kommun klarar INTE skall-kravet på inpasseringskontroll till serverhallen Administrativa kontroller 3 kommuner klarar INTE skall-kravet på utpekade Systemadministratör (SA) för DNS. Ingen av kommunerna har idag rutiner eller riktlinjer för tvåhandsfattning. 5 kommuner klarar INTE skall-kravet på komplexa lösenord (åtminstone för SA) Personorienterade kontroller Loggning Teknisk säkerhet 9 kommuner saknar kravspecifikationer på vilka kunskaper som krävs för personal eller konsulter. 9 kommuner saknar information eller utbildning på följande punkter: o Rollens (befattningens) omfattning, ansvar och befogenheter. o SA Fördjupade tekniska kunskaper i DNS och DNSSEC. o Grundläggande kunskaper i informationssäkerhet. o Handhavande, rutiner och checklistor. o Rutiner för incidenthantering. o Rutiner för krishantering. 10 kommuner saknar dokumentation för att personalen skall kunna genomföra sina uppgifter på ett säkert och fullgott sätt. 1 kommun har INTE förvaringsplats för backuper och säkerhetskopior som är skilt från verksamheten (t.ex. bankfack eller annan byggnad). 11 kommuner använder sig INTE av funktionen Hidden Master. 2 kommuner har INTE en central punkt för tidssynkronisering (NTP) DNS Alla kommuner saknar namnservrar på minst två olika AS (Autonomous System) Dokumentation Alla kommuner saknar DP och DPS 11 kommuner saknar en systemdokumentation på DNS Övrigt 11 kommuner utför i dagsläget INTE någon revision. 3.2 Svar i nulägesrapporten som skiljer mot BÖR-krav Fysisk säkerhet Flertal kommuner saknar: Alternativ driftmiljö på en fysiskt skild plats i händelse av driftproblem. Detektorer för och skydd mot utströmmande vätska. System för branddetektering och -släckning. Automatisk släckanläggning. Serverhallen är en egen brandcell.

9 Page 9 (29) Administrativa kontroller Flertal kommuner saknar stark autentisering (två-faktor) Personorienterade kontroller Flertal kommuner saknar repetitionsutbildning minst vartannat år eller vid större förändringar i rutiner eller de tekniska systemen Loggning De flesta kommuner saknar central loggserver Teknisk säkerhet Det finns inga BÖR-krav DNS De flesta kommuner saknar IPv Dokumentation Övrigt 3 kommuner saknar en Informationssäkerhetspolicy. De flesta kommuner utför inte någon revision på systemet, rutiner, policy, och dylikt.

10 Page 10 (29) 4 Lösningsförslag DNS och DNSSEC kan delas in i fem olika delar: MGMT Master DNSSEC Slave Registrar De fem delarna behöver inte vara på samma hårdvara, ägas eller förvaltas av samma organisation. Med varje del följer ett ansvar och krav som måste uppfyllas. 4.1 MGMT (Management) MGMT är gränssnittet som används för att hantera DNS. Den kan även hantera DNSSEC i from av nyckel generering, nyckelrullning. Avancerade lösningar (IPAM) hjälper även till med uppdatering av systemen, IP-planer och DHCP (Internt). Det är inte alltid som det finns ett managementsystem, utan hanteringen måste då ske på respektive system. 4.2 DNSSEC I DNSSEC ligger nyckelhanteringen och signeringen av zonen. Vilka algoritmer, antalet bitar, tider och hur nyckelrullning ska ske regleras av den egna policyn Nyckelhantering Vid nyckelhantering ser systemet till att generera nya nycklar (KSK och ZSK) samt att byta ut dem med hjälp av en nyckelrullning Signering Antingen så sker signeringen på Mastern eller på vägen från Master till Slave (Bump on the Wire). 4.3 Master Eftersom nyckelhanteringen oftast, i någon form, sker på Mastern och för att säkra att DNS-informationen från att förvanskad så ska Mastern vara en Hidden Master (Varken konfigurationsmässigt synlig eller exponerad mot internet). Informationen följer då vägen: Hidden master till Slav (Nivå 1) och sedan vidare till Slav (Nivå 2) 4.4 Slave I följande flöde Hidden master -> Slav (Nivå 1) -> Slav (Nivå 2) finns det 2 nivåer slavar Nivå 1 Det finns bara en DNS på Nivå 1 och den står med i SOA. Den agerar som distributionspunkt för DNS-informationen. Den rollen som i vanliga fall innehas av Mastern, men nu ligger det på denna slav att vara överlämningspunkten mellan den interna servern och de externa servrarna Nivå 2 Detta är de riktiga DNS-slavarna. Informationen hämtas från Nivå 1 via vanlig zonöverföring (AXFR eller IXFR). Kräver lite konfiguration och behöver inte vara av varken samma hårdvara eller mjukvara. Det är rekommenderat att minste en slav står på ett skilt nätverk. 4.5 Registrar En DNS-zon anses inte signerad förrän DS-posten har lagts till hos föräldrazonen och därmed skapar en förtroendekedja mellan dessa två parter. När det gäller de svenska domänerna är det enbart registraren, där man är kund, som kan genomföra denna operation. Alla registrarer har inte denna förmåga att hantera DNSSEC och det kan därmed bli aktuellt att byta registrar för att kunna

11 Page 11 (29) få igång DNSSEC. Vissa av dessa registrarer kräver dock att man blir helkund (DNS och DNSSEC-signering sköts av dem), medan andra lämnar det öppet på var man hanterar sin DNS. I samband med att rapportern skrevs fanns det 34 registrarer hos.se som hanterar DNSSEC. Den kompletta listan går att finns på följande sida: Lösningsförslag 1 Internt Alla delare (utom sekundär slav) hanteras och ägs av organisationen. Replikering av zondata: Hidden master -> Slav (DMZ) -> Slav (Externt). Minst två publika slav DNS:er på två olika nätverk (AS) Fördelar Interna zoner kan hanteras av samma MGMT och hårdvara/mjukvara. Hidden Master är Master för de interna zonerna. Kan använda en IPAM-lösning och få fler fördelare (IP-plan och DHCP) Nackdelar All utrustning och konfiguration hanteras av organisationens personal Inga samverkans fördelar förutom slav (Externt) 4.7 Lösningsförslag 2 Externt Alla delar (utom sekundär slav) hanteras och ägs av annan part. Den andra parten är antingen en annan kommun, registrar eller ISP. Dock så ska organisationen ha möjlighet att ändra på innehållet på zonen/zonerna Fördelar Personalen slipper underhålla hårdvara, mjukvara och konfiguration Nackdelar DNS inte kontrolleras av den egna organisationen (SLA). Kan vara svårt att kontrollera rutiner vid hanteringen av DNSSEC.Inga samarbeten förutom upphandling.

12 Page 12 (29) 4.8 Lösningsförslag 3 Mix1 MGMT, Hidden Master och DNSSEC hanteras och ägs av organisationen, men slavarna står hos annan part. T.ex. annan kommun, registrar eller ISP Fördelar Kommunerna kan slava åt varandra. Dock så ska en slav stå på annat AS. Kan använda en IPAM-lösning och få fler fördelare (IP-plan och DHCP) Nackdelar Inga

13 Page 13 (29) 4.9 Lösningsförslag 4 Mix2 (Bump in the wire) MGMT och hidden Master hanteras och ägs av organisationen, men DNSSEC och slavar sköts av annan part. T.ex. annan kommun, registrar eller ISP Fördelar Personal med hög kunskap om DNSSEC och nyckeln hantering sköter just det. Kommunerna kan slava åt varandra. Dock så ska en slav stå på annat AS. Kan använda en IPAM-lösning och få fler fördelare (IP-plan och DHCP) Nackdelar Eftersom DNSSEC är en lösning på ett förtroende problem så ställer det krav på den som ska hantera nycklar (SLA).

14 5 Implementationer Enligt tidigare kapitel kan lösningen designas enligt tre olika koncept: Hantera allt själv och ha full kontroll över DNS (Alternativt att slavar hanteras externt). Lägga ut hanteringen på tredjepart. En blandad lösning där DNSSEC hanteras av tredjepart. 5.1 Internt Den interna lösningen kan byggas upp med lösa komponenter eller levereras som en komplett lösning Programvara Hidden Master som sköter DNSSEC kan installeras på en egen server. Från denna kan zonen skickas vidare till de externa slavarna. DNSSEC kan skötas av följande open-source-programvara: OpenDNSSEC BIND (kan installeras på Windows) PowerDNS DNSSEC kan skötas av följande kommersiell programvara: Microsoft Windows 2008 R2 (ej rekommenderat) Microsoft Windows 8 Nominum Servrar Det finns även dedikerade hårdvara och virtuella servrar som hanterar DNS. Ofta kombineras DNS ihop med andra tjänster så som DHCP och ger då en komplett IPAM-lösning. Dessa ger även möjlighet till grafiska gränssnitt samt styrning av sekundära namnservrar. Några exempel på IPAMprodukter: BlueCat Infoblox InfoWeapons Men&Mice Xelerence Vidare finns det också servrar som bara hanterar DNS och DNSSEC så som: Secure Externt Möjligheten finns att ha de externa zonerna helt hos en tredjepartsleverantör. Dock är det viktigt att stämma av att de uppfyller kraven. Nedan följer några exempel på tjänster som kan sköta DNSSEC: Frobbit NameISP PortsIT TDC 5.3 Blandat Syftet med att blanda den interna och externa lösningen är att ha kvar zonredigeringen i den egna lösningen där både de interna och externa zonerna finns. Sedan görs en zonöverföring till tredjepartsleverantören eller den gemensamma plattformen som sköter signeringen av de externa zonerna. Page 14 (29)

15 Page 15 (29) 5.4 Kryptohårdvara Det ställs inga krav på att använda kryptohårdvara, Hardware Security Module (HSM), eftersom att säkerhetskraven inte ställda på den nivån. Ofta är även investeringskostnaden rätt hög och kan därmed vara svår att räkna hem. Däremot kan en HSM användas för flera applikationer inom organisationen, så som PKI och dokumentsignering. Om HSM:en delas mellan flera applikationer eller flera kommuner så kan kostnaden lättare räknas hem. Dessutom utgör en delad infrastruktur ett större mål rent säkerhetsmässigt och även där motivera användandet av en HSM. Värt att tänka på är att alla programvaror inte har stöd för att kommunicera med en HSM (via exempelvis PKCS#11 eller en Microsoft CSP)

16 6 Förvaltning Efter att DNSSEC-systemet har installerats är det viktigt att det dokumenteras och underhålls för att säkerställa den framtida driften. Vad som behöver hanteras av kommunen beror på om man använder en intern eller extern lösning. 6.1 Dokumentation Hantering av DNSSEC-systemet kommer inte att ske på daglig basis, utan troligare bara vid installation, uppgradering, och byte av KSK. I och med att detta inte sker så frekvent är det viktig att lösningen och rutinerna är dokumenterade på ett bra sätt DNSSEC Policy (DP) De krav som tagits fram i denna förstudie kan enkelt omsättas till en DNSSEC-policy. I ett sådant dokument beskriver man ingående de olika kraven som ställs på en DNSSEC-lösning. Ramverket är under standardisering av IETF och kommer inom en snar framtid att bli en RFC. För tillfället finns standarden enbart som ett arbetsdokument (draft-ietf-dnsop-dnssec-dps-framework-07). Arbetet är på engelska, men.se har ett motsvarande dokument på svenska där rubrikerna kan med fördel användas. Rekommendationen är att regionen har ett gemensamt dokument som respektive kommun kan peka på. Därmed fås en effektivare resursutnyttjande samt att en god samverkan uppnås DNSSEC Practice Statement (DPS) I en säkerhetsdeklaration redogör kommunen hur DNSSEC hanteras i relation till de krav som ställs i DNSSEC-policyn. Detta dokument kallas för DNSSEC Practice Statement (DPS) och är ett dokument som är till nytta för förlitande parter, men även den egna organisationen då tekniska lösningar, processer, och rutiner redogörs. Samma rubriker som i policydokumentet används, men fokus är att beskriva hur DNSSEC går till i den egna lösningen. Dokumentet kommer att fungera som ett internt dokument för styrning och uppföljning. Det är därför som det inte är något krav att det görs tillgängligt på en publik webbplats Systemdokumentation I en del fall kan säkerhetsdeklarationen även fungera som en systemdokumentation, men ofta kan det vara bra att skapa ett separat dokument som beskriver systemet ur en annan synvinkel. Något som kan göra det lättare att arbeta med systemet, men även möjligt att beskriva detaljer som annars inte skulle passa i ett dokument som kan jämställas med publik information Rutiner Operationer som är väsentliga för DNSSEC-systemets integritet är värda att dokumentera. Dels för att det inte skall falla i glömska då operationerna inte sker tillräckligt ofta, dels för att det ger en bättre kontroll av arbetsflödet. Följande arbetsflöden är viktiga att ha nedskrivna som rutiner: Installation av DNSSEC-systemet Förändring av tillitsankare i den egna zonen (om tillämpbart) Förändring av tillitsankare hos föräldrazon Återställning av system Page 16 (29)

17 Page 17 (29) 6.2 Drift När DNSSEC-systemet är installerat så sköter det sig själv. Det är bara vid byte av KSK som operatören behöver jobba med systemet. Viktigt är dock att hålla sig uppdaterad med de rådande rekommendationerna för vilka värden som skall användas för DNSSEC. Signaturlivslängder kan justeras under pågående drift utan några speciella procedurer. När det kommer till nycklarna och dess egenskap blir det lite annorlunda. Byte av nyckellängd hanteras som en vanlig nyckelrullning. Önskas byte av algoritm måste det hanteras som en algoritmrullning. I en algoritmrullning läggs de nya signaturerna till i zonen innan den nya nyckeln publiceras. Detta eftersom att DNSSEC har mekanismer som motverkar nedgraderingsattacker. Alla lösningar klarar inte av algoritmrullning och därmed kan det bli aktuellt med att först gå osignerad innan man börjar om med den nya algoritmen. 6.3 Backup Säkerhetskopior är viktigt att ha av både konfiguration och nycklar. Skulle något hända så kan man lätt gå tillbaka till ett läge som man vet fungerade. Kopiorna skall även lagras på en plats skild från verksamheten och skyddas med enligt samma skyddsnivå som originalinformationen. 6.4 Övervakning Övervakning är en viktig del i ett driftåtagande. Det kan hjälpa till vid felsökning, men framför allt kan det avslöja avikelser innan de blir ett problem. Kontroller mot infrastrukturen och tjänsterna kan ske både aktivt och passivt, där aktiv övervakning är en del i distributionskedjan medan den passiva övervakningen sker från ett externt system utan möjlighet att påverka systemen Passiv Det enklaste sättet att övervaka är genom att använda manuella verktyg, men det är stor risk att problem inte upptäcks förrän det är för sent. Det finns ett flertal tjänster på nätet där kvalitén på DNS:en kan mätas, så som: DNSCheck - DNSViz - DNSSEC Debugger - Automatisk övervakning är att föredra. Antingen kan man bygga egna skript med exempelvis DNSCheck ( eller plugga in moduler i exempelvis Nagios. Med fördel kan liknande tester används som för TLDmon ( hos DNS-OARC Aktiv Den aktiva övervakningen är en del i distributionskedjan mellan signeraren och de publika slavarna. Varje gång det sker en zonöverföring så validerar övervakningen att allt ser rätt ut. Skulle något vara felaktigt så stoppas zonöverföringen och ett felmeddelande flaggas. Problemet måste då åtgärdas innan signaturerna går ut. Följs rekommendationerna i denna rapport så har man minst 7 dagar på sig. Ofta testar man att signaturerna inte är på väg att gå ut samt att den osignerad och signerade zonen innehåller samma information. Övervaknings kan bland annat byggas av: YAZVS - Yet Another Zone Validation Script - ldns-verify-zone - validns -

18 Page 18 (29) 6.5 Felsökning Om något problem uppstår så behöver man skapa sig en bild av vad som hänt och vilka symtom som yttrar sig. Det enklaste sättet att börja på är att exempelvis använda sig av DNSCheck. Den kan ge fingervisningar på var felkällan ligger. Steget efter kan genomföras med manuella DNS-frågor för att hitta det exakta felet. Problemet behöver sedan åtgärdas i den lösning som används för DNS och DNSSEC. Det exakta tillvägagångsättet beror på vilken lösning som används. Oftast är det bäst att börja granska loggarna. DNSSEC är inte förlåtande och går något sönder så kommer inte svaren att kunna valideras. Kan inte problemet åtgärdas inom rimlig tid, så måste man besluta om att dra tillbaka DS-posten för att kunna göra zonen nåbar igen. Finns inte DS-posten så anses man vara osignerad. 6.6 Uppgradering DNSSEC-programvaran behöver precis som annan programvara uppgraderas med jämna mellanrum. Det är därför även viktigt att detta system är med organisations cykel för programuppdateringar Programuppdatering I och med att flera DNS-servrar används, så kan uppgradering ske under dagtid utan att tjänsten i sig påverkas. Detta eftersom att DNS-protokollet är uppbyggt på ett sådant sätt att om man inte får ett svar från en server så går man vidare till nästa server. Innan en uppgradering är det viktigt att ha gjort en säkerhetskopia på konfiguration och nycklar. Skulle något hända så kan man lätt rulla tillbaka till den tidigare versionen. Finns ett testsystem tillgängligt kan uppgraderingar testas där innan de går i produktion Byte av system Ibland kan det vara aktuellt att inte bara göra programuppdatering, utan man vill även byta lösning. Att byta en namnserver eller att migrera till en tredjepart går till på ungefär samma sätt. Den nya lösningen sätts upp parallellt med den gamla lösningen. Genomför tester för att se att allt fungerar och sedan kan man antingen göra förändringar i zonöverföringarna eller göra en omdelegering hos.se. Byte av signeringslösning kan vara lite svårare. Man har tre alternativ: Flytta nycklar Göra systemrullning (nyckelrullning mellan två system) Gå osignerad under flytten Att flytta nycklar går bra om det är internt inom en och samma maskin, exempelvis vid byte av programvara. Att flytta nycklar mellan system är inte tillåtet rent säkerhetsmässigt. Vill man byta system men ändå fortsatt vara signerad så måste man genomföra något som kallas för systemrullning. Det är som en nyckelrullning, men att det sker manuellt genom utbyte av publika nycklar mellan de två systemen. Den enklaste metoden är att ta bort DS-poster, byta över till den nya lösningen, och till sist publicera DS-poster för det nya systemet.

19 Page 19 (29) 7 Fortsatt arbete Resultatet av förstudien går att finna under respektive kapitel. Ett antal punkter har dock identifierats som kan vara bra att ta med till det fortsatta arbetet med projektet. 7.1 DNSSEC-policy Kraven som går att finna i bilagan kan med enkelhet omsättas till en DNSSEC-policy (DP). Detta då kraven ger en god täckning av de olika områdena som behandlas i ett sådant dokument. Rekommendationen är som sagt att regionen har ett gemensamt dokument som respektive kommun kan peka på. 7.2 Kurser Alla kommuner är i behov av kurser inom DNS och DNSSEC för att kunna uppfylla kraven kring införande av DNSSEC. Genom att samverka om dessa tillfällen kan kunskap spridas mer effektivt inom regionen. 7.3 Gemensam lösning Vilken lösning som väljs beror på diskussioner inom region och även inom respektive kommun. Det finns dock även möjlighet kring samverkan av den tekniska plattformen. Antingen att liknande programvara används eller att en gemensam/delad plattform utformas. 7.4 Framtida användning av DNS I och med att DNS nu är säkrat av DNSSEC så kan man med säkerhet veta att DNS-informationen är korrekt. Därmed kan man publicera information som inte får förvanskas samt behöver autentiseras. Till exempel publika nycklar för SSH-servrar eller certifikat (Use Cases and Requirements for DNS- Based Authentication of Named Entities (DANE) - RFC6394). Detta gör att DNS kan användas som en autentiserad grund för andra applikationer. 7.5 Validering av DNSSEC Detta arbete syftar till att signera kommunernas huvuddomäner/zoner. Det naturliga är då också att man själv börjar validera de DNS-svar man får från internet. Detta är dock inget krav för ett DNSSEC-införande. Hur validering aktiveras beror på den lösning som används, men huvudtanken är att man lägger till tillitsankaret (trust anchor) för rotzonen i resolvern. 7.6 Signering av övriga zoner Förutom huvuddomänen/zonen kan kommunen vara ansvarig för andra zoner så som alternativa stavningar, skolar, orter, kampanjdomäner, eller kommunalt ägda bolag. Dessa kan med fördel hanteras i samma system som huvuddomänen, men omfattas då av samma krav.

20 Page 20 (29) Bilaga A Krav på DNSSEC A.1 Fysisk säkerhet Den fysiska säkerheten är till för att skydda den utrustning som hanterar DNS och DNSSEC. Detta för att förhindra manipulation, stöld, olyckor, eller motsvarande. Skydda utrustning som hanterar känslig information eller är en väsentlig komponent i DNS-systemet. Placera utrustning i skyddade utrymmen där enbart behörig personal har tillgång. Använda UPS eller motsvarande för att hantera kortare strömavbrott. Ej förvara aktiveringsdata tillsammans med den eller de enheter som kan låsas upp med informationen. Destruera media vid avveckling som hanterat känslig information. Förvara säkerhetskopior på en lagringsplats skild från verksamheten. Ha en alternativ driftmiljö på en fysiskt skild plats i händelse av driftproblem. Använda reservkravsanläggning eller stänga av servrar på ett kontrollerat sätt vid längre strömavbrott. Ha detektorer för och skydd mot utströmmande vätska. Ha system för branddetektering och -släckning. Utrusta utrymmet med automatisk släckanläggning. Se till att utrymmet är en egen brandcell. A.2 Administrativa kontroller I organisationen har man tillgång till olika roller som hanterar systemen. Det primära syftet är att skydda processer/arbetsflöden som hanterar känsliga uppgifter. Ha en roll motsvarande Systemadministratör (System Administrator, SA) som ansvarar för den tekniska hanteringen av systemen. Ha minst två betrodda personer närvarande eller aktivt godkännande vid följander händelser: o Hantering av de privata nycklarna. o Export och kontroll av tillitsankare. o Förändring av bemanning eller uppdragsbeskrivning för betrodd roll. o Inloggning på DNSSEC-servrar med fullständiga administratörsrättigheter. o Återskapande av systemet från säkerhetskopia. Minst använda starka lösenord för autentisering av betrodda roller. Använda stark autentisering (två-faktor) av betrodda roller. Kornhamnstorg 61, 2 tr SE Stockholm Sweden Telefon: +46 (0) Telefon: +46 (0)

21 Page 21 (29) A.3 Personorienterade kontroller Personalen som arbetar med systemen behöver ha rätt utbildning och bakgrund för att kunna genomföra sina uppgifter på ett säkert och effektivt sätt. Kommun SKALL: Begära in bevis på att de som kandiderar till en betrodd roll har rätt bakgrund och kvalifikationer. Ge personalen relevant och erforderlig utbildning inom: o Rollens omfattning, ansvarsområde och befogenheter. o Fördjupade tekniska kunskaper i DNS och DNSSEC (för Systemadministratör). o Grundläggande kunskaper i informationssäkerhet. o Handhavande, rutiner och checklistor. o Rutiner för incidenthantering. o Rutiner för krishantering. Ställa samma krav vad gäller bakgrund och utbildning på kontrakterad personal som fast anställd personal. Tillhandhålla dokumentation för att personalen skall kunna genomföra sina uppgifter på ett säkert och fullgott sätt. Tillhandahålla repetitionsutbildning minst vartannat år eller vid större förändringar i rutiner eller de tekniska systemen. A.4 Loggning Loggning är en vital del av säkerhetsarbetet där händelser och incidenter kan följas upp. Åtminstone logga händelsetyper av följande slag. o Händelser som kan orsaka en negativ påverkan på DNSSEC-systemets tillämpning. o Händelser som är av typen säkerhetsloggning. o Händelser som kan orsaka en direkt och negativ påverkan på det logiska åtkomstskyddet. o Händelser som inträffar vid fysisk åtkomst av DNSSEC-systemet och dess förvaringsplatser för loggar eller nycklar. o Händelser som påverkar tillgängligheten, t.ex. avbrott och driftstörningar. o Start och stopp av hela eller delar av systemet. o Händelser relaterade till DNSSEC, så som nyckelgenerering, signering, och export av publika nycklar. Använda en manuell rutin i de fall loggning inte sker automatiskt. Skydda loggar mot otillbörlig förändring. Lagra säkerhetskopior av loggar i ett fysiskt säkert utrymme på skild plats från originaldata. Informera personalen att loggning sker. Utreda incidenter för att kunna åtgärda eventuella incidenter. Skriva loggar till ett separat loggsystem utanför DNSSEC-systemet.

22 Page 22 (29) A.5 Teknisk säkerhet A.5.1 Generering och installation av nyckelpar Nyckelparen är en väsentlig del av DNSSEC och måste hanteras därefter. A.5.2 Generera nyckelpar baserat på slumptal som är slumpmässig på så sätt att det är beräkningsmässigt ogörligt att återskapa ett genererat slumptal, oavsett mängden kunskap om genereringsprocessens beskaffenhet eller vid vilken tidpunkt eller med hjälp av vilken utrustning slumptalet skapades. Ej hantera nycklarna utanför nyckelgenereringsprocessen annat än genom säker överföring till avsedd förvaringsplats. Aldrig använda nycklar avsedda för DNSSEC i annat ändamål. Skydd av privata nycklar Det är inget krav att säkerhetsmoduler används, men det är viktigt att filerna innehållandes nycklarna skyddas på ett säkert sätt. Begränsa åtkomsten av nycklarna till enbart de berörda användare och processer på servern. Göra säkerhetskopior av nycklarna som förvaras på en fysiskt skild plats med motsvarande skyddsnivå som originalnycklarna Ej återanvända nyckelpar som tidigare har byts ut A.5.3 A.5.4 A.5.5 Säkerhet i datorsystem Enbart tillåta behörig personal få tillgång till systemen. Säkerhet i kommunikationsnätverk Ha logiskt sektionerade nätverk med indelning i olika säkerhetszoner, samt säkrad kommunikation däremellan. Placera den del av systemet som sköter signeringen på det interna nätverket som en så kallad hidden-master. Enbart de sekundära namnservrarna kan nås direkt från Internet. Tidsstämpling Ha alla klockor synkroniserade mot, av verksamheten utsedd, säker tidskälla.

23 Page 23 (29) A.6 DNS Ett välfungerande DNS-system bygger inte bara på att DNSSEC finns utan att infrastrukturen ser bra ut. Ha zonen på minst två publika namnservrar. Ha namnservrar på minst två olika nätverk (Autonomous System, AS). Ha minst en namnserver tillgänglig över IPv6. Kravställa att refererade zoner (exempelvis via CNAME eller MX) är signerade med DNSSEC. Ha minst två namnservrar tillgängliga över IPv6. A.7 Zonsignering A.7.1 Nyckellängder och algoritmer Använda nyckellängder och algoritmer med en styrka som är tillräcklig för ändamålet under respektive nyckels livslängd. Använda algoritmer som är standardiserade av IETF, allmänt tillgängliga och resurseffektiva för alla inblandade parter. Använda RSA-algortimen med minsta nyckellängd av 2048 bitar för KSK och 1024 bitar för ZSK. A.7.2 Autentiserade negativa svar Använda valfri metod för autentiserade negativa svar o NSEC o NSEC3 (Opt-In) o NSEC3 (Opt-Out) Använda NSEC3 (Opt-In) då enumering av zondata försvåras. Begränsa antalet NSEC3-iterationer till 10 för att bibehålla systemets prestanda. A.7.3 Signaturformat Använda det signaturformat som specificeras av den valda algoritmen. Inte använda algoritmer som tillämpar MD5 som hashsumma. Använda RSA i kombination med SHA-256 för signering. A.7.4 Byta av zonsigneringsnycklar (ZSK) Byte av zonsigneringsnycklar sker oftast automatiskt i DNSSEC-systemet. Byta ZSK var tredje månad.

24 Page 24 (29) A.7.5 Byte av nyckelsigneringsnycklar (KSK) Byte av nyckelsigneringsnycklar kräver interaktion med föräldrazonen. Byta KSK varje eller vartannat år i syfte att upprätthålla kunskapsnivån och rutiner i organisationen. I annat fall byta KSK enbart vid behov. A.7.6 Signaturlivsklängd och frekvens för omsignering Välja signaturlivslängd och frekvens för omsignering på ett sådant sätt att signaturerna alltid är giltiga tillräckligt länge för att eventuella systemfel kan åtgärdas innan signaturerna går ut. Inte göra omsignering allt för ofta för att minimera belastningen på servrarna. Ha signaturer som är giltiga någonstans i tidsspannet mellan 7 och 30 dagar. A.7.7 Verifiering av nyckeluppsättning Göra regelbundna kontroller mot den signerade zonen, där tillitskedjan verifieras. Detta minst i samband med byte av KSK. A.7.8 Ha ett automatiskt övervakningssystem. DNS-posters livslängd (TTL) Livslängden på DNS-posterna påverkar säkerheten och hanteringen av DNSSEC. Därför måste rimliga värden användas. Sätta SOA Expire till ett värde som är mindre än den kortaste signaturlivslängden. Detta för att se till att zonen går ut innan signaturerna går ut. Sätta TTL för DNSKEY till 3600 sekunder. Minimera TTL på övriga DNS-poster för att inte få orimliga TTL:er på signaturerna. Detta påverkar hur snabbt en nyckel kan bytas. Ge NSEC/NSEC3 sin TTL från SOA Minimum.

25 Page 25 (29) A.8 Rutiner A.8.1 A.8.2 Hantering av DS-poster för barnzoner Det är möjligt att delegera delar av en DNS-domän till en annan administrativ avdelning eller motsvarande. Alltså att de har en egen uppsättning av DNS-servrar som är ansvariga för informationen. DNSSEC kan fortfarande säkra systemet genom publicering av DS-poster i den egna zonen. Dessa DS-poster pekar på vilka nycklar som används för signering hos barnzonen. Kommunen SKALL (om tillämpbart): Ha rutiner för publicering av DS-poster i den egna zonen. Ha rutiner för avpublicering av DS-poster i den egna zonen. Se till att förändringsförfrågan kommer ifrån en behörig person. Hantering av DS-poster till föräldrazonen För att zonen skall anses vara signerad av externa parter så räcker det inte bara att slå på DNSSEC i den egna zonen, utan det måste även signaleras genom publicera en DS-post i föräldrazonen. Ha rutiner för publicering av DS-poster i föräldrazonen. Ha rutiner för avpublicering av DS-poster i föräldrazonen. Ha ett godkännande från två betrodda personer vid en förändringsförfrågan. A.9 Dokumentation A.9.1 Säkerhetsdeklaration I en säkerhetsdeklaration redogör kommunen hur DNSSEC hanteras i relation till de krav som ställs i detta dokument. Detta dokument kallas för DNSSEC Practice Statement (DPS) och är ett dokument som är till nytta för förlitande parter, men även den egna organisationen då tekniska lösningar, processer, och rutininer redogörs. Skapa en säkerhetsdeklaration med en dokumentstruktur motsvarande draft-ietf-dnsop-dnssec-dps-framework från IETF.

26 Page 26 (29) A.9.2 Informationssäkerhetspolicy För att kunna göra ett bra informationssäkerhetsarbete inom kommunen så behövs det dokumenterade policy, processer, rutiner, och motsvarande. Ha ett dokumenterat informationssäkerhetsarbete som kan förse information till arbetet med DNSSEC kring: o Loggning Frekvens för kontroll av loggdata. Lagringstid för loggar. o Kontinuitetsplanering Katastrofhantering. Tester av katastrofplaner. Återstartsrutiner (gradvis, mellansnabb och omedelbar). Automatisk övervakning. Rullning av röjda nycklar. Beslut om tillbakadragande av DS-post hos föräldrazon. Genomförande av säkerhetsuppgraderingar. Om inte någon av punkterna ovan finns med i informationssäkerhetspolicyn eller motsvarande, så måste dessa dokumenteras som en del av DNSSEC-arbetet. A.9.3 Systemdokumentation Enligt tidigare krav upprätthålla en systemdokumentation. A.10 Övrigt A.10.1 Revision Genomföra granskning minst vartannat år med hjälp av interna resurser eller med hjälp av en extern part. Låta granskningen genomföras av en person för uppgiften och förståelse för DNSSEC, informationssäkerhetsteknik och verktyg som innehar erfarenhet från IT-säkerhetsgranskningar. Uppdatera systemet, rutiner, policy eller dylikt baserat på de fynd som gjorts. Genomföra en komplett revision på systemet, rutiner, policy, och dylikt.

27 Bilaga B 1 Fysisk säkerhet Nulägesrapport Sammanställning 1. Har ni idag inpasseringskontroll på er serverhall? Ja:11 / Nej:1 2. Har ni idag en UPS eller/och reservkraftsanläggning? Ja:12 / Nej:0 3. Har ni branddetekteringssystem i serverhallen? Ja:12 / Nej:0 4. Har ni brandsläckningssystem i serverhallen? Ja:8 / Nej:4 5. Har ni detektor för vätska i serverhallen? Ja:6 / Nej:6 6. Har ni riktlinjer för destruktion av känslig information Ja:6 / Nej:6 (Informationssäkerhetspolicy)? 7. Har ni förvaringsplats för backuper och säkerhetskopior som är skilt Ja:11 / Nej:1 från verksamheten (t.ex. bankfack eller annan byggnad)? 8. Har ni en sekundärdriftplats (Co-location)? Ja:4 / Nej:8 9. Är serverhallen en egen brandcell? Ja:10 / Nej:2 2 Administrativa frågor 1. Har ni idag en Informationssäkerhetspolicy eller en IT-säkerhetspolicy? Ja:11 / Nej:1 2. Har ni idag utpekad Systemadministratör för DNS (System Ja:9 / Nej:3 Administrator, SA)? 3. Har ni idag utpekad Säkerhetsansvarig (Security Officer, SO)? Ja:9 / Nej:3 4. Har ni idag riktlinjer för tvåhandsfattning (två betrodda roller närvarande eller aktivt godkännande vid förändringar)? 5. Använder ni idag: Ja:0 / Nej:12 a. Komplexa lösenord (T.ex. - Minsta 8 tecken. Minsta en gemen, versal Ja:6 / Nej:6 och siffra. Minst ett special tecken t.ex.!@. Byte minst en gång i halvåret)? b. Stark autentisering (två-faktors)? Ja:2 / Nej:10 6. Innehas idag SO rollen och SA rollen av samma person? Ja:0 / Nej:12 3 Personorienterade frågor 1. Får/Har personalen idag tydlig information eller utbildning: a. Rollens (befattningens) omfattning, ansvar och befogenheter? Ja:3 / Nej:9 b. SO Grundläggande tekniska kunskaper i DNS och DNSSEC? Ja:2 / Nej:10 c. SA Fördjupade tekniska kunskaper i DNS och DNSSEC? Ja:2 / Nej:10 d. Grundläggande kunskaper i informationssäkerhet? Ja:7 / Nej:5 e. Handhavande, rutiner och checklistor? Ja:4 / Nej:8 f. Rutiner för incidenthantering? Ja:5 / Nej:7 g. Rutiner för krishantering? Ja:7 / Nej:5 2. Finns det idag någon kravspecifikation på vilka kunskaper eller utbildningar som krävs för personal eller konsulter? 3. Finns det idag dokumentation över hur personalen ska genomföra sina uppgifter på ett säkert sätt? 4. Använder kommunen sig av Arbets-/Uppgiftsrotation t.ex. för att öka kunskapsspridningen? 4 Loggning/Övervakning Ja:2 / Nej:10 Ja:1 / Nej:11 Ja:3 / Nej:9 1. Finns det idag central loggserver? Ja:3 / Nej:9 2. Ligger denna server och loggarna med i backupen? Ja:1 / Nej:10 3. Sker det idag någon revision eller automatisk analys av loggar? Ja:3 / Nej:9 Page 27 (29)

28 Page 28 (29) 4. Loggas inpasseringssystemet till serverhallen (Av er eller annan part)? Ja:10 / Nej:2 5. Finns det idag något övervakningssystem (SNMP)? Ja:9 / Nej:3 6. Övervakas nätets tillgänglighet (T.ex. switch, router, FW)? Ja:10 / Nej:2 5 Teknisk säkerhet 6 DNS 7 Zoner 1. Har ni idag en HSM (Hardware Security Module)? Ja:0 / Nej:12 2. Har ni ett segmenterat nät där segmenteringen utgår ifrån säkerhetsklassning av systemen (T.ex. Externt, DMZ, Admin klienter, Edu klienter, Admin servrar, Edu servrar, Gemensamma resurser)? Ja:12 / Nej:0 3. Använder ni idag DNS funktionen Hidden master? Ja:1 / Nej:11 4. Finns det idag en central punkt för tidssynkronisering internt (NTP)? Ja:10 / Nej:2 1. Hur många interna DNS:er har ni idag? Median:3, Medel:3,4 2. Hur många externa DNS:er har ni idag (Egna) Median:1, Medel:0,8 3. Hur många externa DNS:er har ni idag (Hos t.ex. ISP)? Median:1, Medel:1,3 6. Vilken/Vilka ISP har ni? Telia Högsbynät OHE 7. Har ni IPv6-adresser? Ja:1 / Nej:11 8. Kan man nå servrar eller annan utrustning över IPv6 via internet? Ja:1 / Nej:11 1. Hur många zoner har ni internt? Median:2,5, Medel:8,4 2. Hur många zoner har ni externt? Median:2,5, Medel:8,5 6. Har ni delegerat till någon underzon? Ja:1 / Nej:11 8 Dokumentation 9 Övrigt 1. Har ni en DNSSEC Policy (DP) eller DNSSEC Practice Statement (DPS)? Ja:0 / Nej:12 2. Har ni en Informationssäkerhetspolicy? Ja:9 / Nej:3 3. Har ni en systemdokumentation för DNS? Ja:1 / Nej:11 1. Utför ni idag Revision av befintliga system? Ja:1 / Nej:11

29 Page 29 (29)