Slutrapport SKA fas två. Godkänd: Rev: Maj. Rapport SKA 1(8)

Transkript

1 Rapport SKA 15 Maj (8)

2 Innehåll 1 Inledning Projektets genomförande Exponering / Spridning Genomförande av testerna Testerna Hälsokontroll av DNS:er Verktyg Resultat och analys Framtiden Certifiering av andra partners IPv Best Practice...8 2(8)

3 1 Inledning SKA, Säker Kund Anslutning, är ett projekt/produkt som Svenska Stadsnätsföreningen, SSNf, drivit sedan hösten Projektets initiala syfte var att förhindra spoofing och hijacking i bredbandsnät genom att ta fram regler och krav för den utrustning som implementeras i näten. Arbetet har till dags dato resulterat i att nio tillverkare är certifierade enligt SKA version 3.1 och fler tillverkare är på väg in. SKA version 3.1 är idag en branschstandard för bredbandsnät inom stadsnät och de allmännyttiga näten. I stort sett alla upphandlingar ställer de här kraven på utrustningen och även andra nätbyggare har hört av sig och ställer de här kraven. Läs mer på Ganska tidigt i arbetet med utrustningen i näten så upptäcktes dock brister. Även om SKA-certifierad utrustning användes så var det svårt att till fullo uppnå de ställda kraven. Orsaken var själva designen och uppbyggnaden av näten, klara riktlinjer och Best practice för detta saknades helt enkelt. Att implementera även detta inom ramen för SKA blev därför aktuellt. 2 Projektets genomförande SKA fas två har inletts som ett pilotprojekt i syfte att ta fram underlag för test och certifiering av hela nät. I pilotprojektet har 10 stycken stadsnät eller mediaoperatörer deltagit. Finansieringen av projektet har skett via SSNf,.SE:s Internetfond samt att deltagare har ställt upp med egen tid och tillåtit test i sina nät. Pilotprojektet har varit lyckosamt och en tidigare saknad Best Practice med riktlinjer för hur man skall bygga bredbandsnät är nu under framtagning. Från våren 2008 kan SSNf testa och certifiera hela kedjan i nät, från korrekt uppsatt kundport till en DNS som klarar hälsokontroll och korrekta loggar i DHCP-servern. Se vidare under 3 Genomförande av testerna 3(8)

4 2.1 Exponering / Spridning Projektet har gett en hel del positiv exponering. Intresset och medvetenheten har bland de direkta intressenterna inom SSNf, Stadsnäten, gått från traditionellt tveksamt till högst intressant. En hel del har även gjorts för att sprida SKA-budskapet. SSNf och de stadsnät som genomgått certifiering har i samband med godkännande publicerat detta på respektive hemsidor. Utskick av pressreleaser i ämnet till fackpress har intensifierats. Föredrag har hållits på seminarier i SSNfs och andras regi. Även allmänheten har kunnat få information i samband med t ex IT-föredrag på bibliotek. SSNf har, för att ytterligare utveckla och strukturera arbetet med konceptet SKA, gett Interlan Gefle AB uppdraget att förvalta produkterna SKA version 3.1 och SKA fas två. Inom förvaltningsåtagandet finns uppdraget att ytterligare sprida konceptet, bland annat genom att certifiera partners som utför SKA-certifiering av nät. I skrivande stund har Absilion AB i Luleå genomgått och klarat en sådan partnercertifiering. Företag som har intresse av att utföra tredjeparts certifieringar av bredbandsnät enligt SKA kan finna mer information och krav på adress nedan. 4(8)

5 3 Genomförande av testerna Testutrustningen som använts har varit en server med två virtuella datorer vilka har simulerat två bredbandskunder. Testservern har managerats via en port och på så sätt har de olika momenten i testerna kunnat testas utan att kontakten med servrarna förlorats. 3.1 Testerna Punkterna nedan är de som testats i samtliga nät. De skiljer sig lite åt om det är fast IPadress eller dynamisk via DHCP. De två bör-kraven som finns i SKA version 3.1 är inte testade i näten. Det är viktigt att man testar så mycket som möjlig live i nätet, det är därför det är två maskiner med i testen, så kan man testa mellan dem utan att störa andra. Så kallad DHCP-snooping ska finnas på accessportarna, d v s en kund ska inte kunna vara DHCP-server åt någon annan kund. Det ska inte gå att sätta en fast IP-adress och komma vidare från porten som kunden är ansluten i om dynamisk tilldelning används. När kunden fått en eller flera adresser via DHCP ska bara den eller de adresserna kunna skicka trafik ut från den porten. Om inte IP-adressen förnyas via DHCP-servern ska den IP-adressen stängas av i switchporten. Alla typer av spoofing/poisoning ska förhindras för IP och ARP-protokollen. D v s de av DHCP godkända adresserna är de enda adresserna som ska förekomma som source-address i IP och ARP-paket i header och payload. 5(8)

6 Spårbarhet ska läggas in i DHCP-förfrågningarna i L2-läge, accessswitchen skall inte vara DHCP-relay. Befintliga DHCP-servrar måste användas och här begärs utdrag ur loggarna mellan vissa tidpunkter för att se resultat och att tiden är korrekt så långt det är utläsbart från loggarna. Om fasta IP-adresser används ska switchporten bara tillåta den för porten definierade IP-adressen som source-adress i IP och ARP-paket. UPnP ska alltid vara spärrat mellan acessportar. IPv6 ICMP6 router advertisment och IPv6 DHCP-servrar ska spärras mellan kundportar Hälsokontroll av DNS:er Innan de två sista näten testades beslutades att även göra hälsokontroller på DNS:erna för respektive ISP som finns näten. De DNS:erna blir tilldelade antingen statiskt eller dynamiskt och test genomförs både inifrån och utifrån nätet. Inget nät har blivit underkänt om inte alla punkter uppfyllts men stadsnäten har ombetts att skicka framlagda synpunkter till respektive leverantör. Följande testades på DNS:erna. De skall stödja DNSSEC och verifiera det. De skall använda slumpmässigt valda portar för att försvåra Kaminsky-attack. De bör inte vara rekursiv för hela Internet. De bör inte svara på cachade svar för hela Internet. Kontrollera så att inte någon gammal obsolete version av DNS-programvara använts Verktyg Testserver har varit Fedora 8, 9 och 10 med VMWare server 1.07 och 1.08 som virtualiseringsplattform. De virtuella testdatorerna har varit Ubuntu server 8.04 med följande installerade verktyg. Arpspoof från paketet dsniff Hping2 Iperf Radvd Dibbler Host från bind 9.05 och bind byggt för DNSSEC Dhcpd från ISC Ldns Fpdns 6(8)

7 4 Resultat och analys Resultaten av testerna visar att det finns teknologier genom vilka det är enklare att uppnå certifiering enligt SKA. Följande accessteknologier är till idag testade: Kabel-TV via central CMTS Fast IP-adress och xdsl, alla godkända Dynamisk adress och xdsl Fast IP-adress och ETTH Dynamisk adress och ETTH De teknologier som visat sig vara svårast att få godkända är kabel-tv, fasta IP-adresser och spärren av UPNP och IPv6 mellan kundportarna. Inget av de kabel-tv nät som testats har blivit godkänt och generellt har problem funnits med att få fasta IP-adresser att smidigt klara kraven i ETTH. 5 Framtiden Det finns ett fortsatt starkt behov av SKA-certifiering som en drivande kraft i utvecklingen och säkerställandet av funktionerna i bredbandsnäten. Även om det finns till exempel en del white-papers på hur ett bredbandsnät skall byggas så är det ofta som inte alla rekommendationer följs. Bredbandsnäten utvecklas även hela tiden med nya anslutningsmetoder och nättyper så ingenting inom Internet är konstant, vilket naturligtvis innebär att inte heller SKA får bli konstant. Närmast kommer till exempel IPv6 att börja märkas mer markant och här måste det finnas lösningar för att detta kan samexistera och verka på ett säkert sätt parallellt med IPv Certifiering av andra partners Sedan är två personer på Absilion AB i Luleå certifierade att utföra testerna och certifiera bredbandsnät. Målet är att sprida detta till fler personer/företag för att sprida varumärket och styrkan i certifieringen IPv6 Ett arbete att ta fram standard för nästa Internetprotokoll, IPv6, har påbörjats och resultatet av det arbetet kommer att redovisas på En första del av idéer hur man kan bygga IPv6 nät finns redan där men det kommer att komma mer information ju mer produkter som kommer med stöd för IPv6. 7(8)

8 5.1.3 Best Practice Fortsätta framtagningen av Best Practice och exempel för design och uppbyggnad av nät. Idag ställs en mängd krav på näten men det finns många andra saker runtomkring detta som inte är med som krav i SKA. Det kan till exempel vara rekommendationer för hur STP, CDP och andra protokoll skall sättas upp för att inte påverka driftstabiliteten. Men även hur man sätter upp en Teredoserver, DNS med DNSSEC osv för att skapa ett säkert nät hela vägen. 8(8)