30 Augusti SEC 2010 1(14)
Innehåll 1 INTRODUCTION... 4 2 Inledning... 4 3 SEC for dummies... 5 3.1 ARP poisoning...5 3.2 Förhindra spoofing och loggning...7 3.3 Spärr för UPnP...7 3.4 Spärr av IPv6...8 4 SEC, Secure Endser Connection... 9 4.1 Requirements for IPv4...9 4.1.1 So-called DHCP-snooping must be located on the access ports. I.e. a client should not be able to act like a DHCP-server for another client....9 4.1.2 It must not be possible to apply a static IP-address to get pass the port that the client is connected with....9 4.1.3 When a client is assigned one or more addresses via DHCP it must only be possible for these specific address/addresses to send traffic out through that port....9 4.1.4 If the address is not renewed via the DHCP-server it must be closed in the subscriber port...9 4.1.5 All types of spoofing/poisoning must be prevented for the TCP/IP and ARP-protocols. I.e. the addresses which are approved from DHCP are the only addresses that must occur as the source address in TCP/IP and ARP packets....9 4.1.6 Traceability must be added to the DHCP-requests in L2-mode. The access switch must not be DHCP-relay.... 10 4.1.7 Filter possibilities may exist between client ports. For example arbitrary TCP/UDP-ports to be filtered between subscribers.... 10 4.1.8 If static IP-addresses are used, the subscriber port must only allow communication for the port defined IP-address as source address in IP and ARP packets.... 10 4.1.9 UPnP must be blocked between subscriber ports.... 10 4.1.10 ICMPv6 messages for RA and DHCPv6 must be blocked between subscriber ports.... 10 4.1.11 There may be a possibility to filter different Ether types to only allow 0 800 and 0 806 to pass between subsriber ports. This is a good function to filter out PPPOE messages for example. In Sweden PPPOE is very unusual so that s why it isn t a must requirement.... 10 4.2 Port isolation...11 4.3 Requirements SEC IPv6...12 4.3.1 IPv6 Stateless Address Auto configuration ( RFC2462 ) Snooping... 12 4.3.2 IPv6 snooping... 12 4.3.3 DHCPv6 (RFC 3315) snooping... 12 4.3.4 Router Advertisement (RA, RFC 2462, RFC 5006) snooping... 12 4.3.5 Dynamic "IPv6 neighbour solicitation/advertisement" (RFC 24611) inspection... 12 4.3.6 Neighbour Unreachability Detection (NUD, RFC 2461) snooping... 13 4.3.7 Duplicate Address Detection (DAD, RFC 4429) snooping... 13 2(14)
4.3.8 IPv6 Multicast Listener Discovery v2 (RFC 3810) snooping... 13 4.3.9 IPv6 Routing Header (RFC 2460, Next Header value 43) snooping... 13 4.3.10 UPNP filtering... 13 4.3.11 There may be a possibility to filter different Ether types to allow only 0x86dd between subscriber ports. And most probably you must also permit 0 800 and 0 806 for IPv4.... 13 3(14)
1 INTRODUCTION SEC, Secure End user Connection, is the new name of the SKA certification product. In the following point 2 and 3 is a short SEC for Dummies in Swedish and the requirements for certification in IPv4 and IPv6 is then followed from point 4 and onwards. 2 Inledning SKA startade 2005 med syftet att säkerställa att den svenska bredbandsmarknaden inte innehåller felaktigt byggda och osäkra nät. SKA certifierade från början bara hårdvara men är sedan två tillbaka ett sätt för bredbandsnät att visa att de uppfyller säkerhetskraven genom certifiering av bredbandsnät. När det nu gått mer än fem år är det dags att internationalisera SKA och byta namn på till SEC, Secure End user Connection. Syftet med namn- och språkbytet är bland annat att slippa språkproblemen med internationella tillverkare. www.säkerkundanslutning.se kommer därför i framtidan bara vara på engelska och alla krav kommer också att vara på engelska så att vi slipper översättnings och underhållsproblem. Detta dokument innehålla först en SEC for dummies på svenska och sedan kommer SEC-kraven på engelska för både IPv4 och IPv6. SKA/SEC v4 och v6 kommer hädanefter att vara SEC 2010-09-30 med stigande versionsnummer efter datum i takt med att nya versioner kommer. Observera att man fortfarande kan certifiera sig för antingen IPv4 eller IPv6 eller båda samtidigt. 4(14)
3 SEC for dummies ( Swedish only ) SEC startade utifrån det faktum att bredbandsnät konstruerades och byggdes med otrygga anslutningar och säkerhetsbrister som slutkunderna själva inte kunde vidta åtgärder mot. Tyvärr så sker sådan konstruktion och byggnation även idag. Nedan så följer en kortfattad lista med kravställningar och även exempel på vad som kan hända om man inte följer kraven. Det är för IPv4 som vi presenterar kraven men målen för IPv6 är detsamma. Vi skall även komma ihåg att de här sakerna kan man inte som bredbandskund skydda sig emot utan det är bredbandsleverantören som måste skapa detta skydd SEC är primärt skrivet för nät med delad broadcastdomän men man skall testa alla punkter i andra typer av nät också då det kan finnas fel i design eller konfigurering i dem. 3.1 ARP poisoning ARP är ett hjälpprotokoll som gör att IPv4 protokollet fungerar i ett Ethernet nät. Detta problem är störst i nät med delad broadcastdomän och det finns en hel del nät i Sverige med den designen. På bilden ovan ser vi hur trafiken mot Internet går normalt med de gröna pilarna. Varje kunds dators trafik går normalt in och ut genom uplinkporten mot Internet. Internet Om nätet är felbyggt/feldesignat kan det gå att köra så kallad ARP-poisoning. I bilden ovan skickar den röda datorn förfalskade ARP-paket till de övriga datorerna där den uppger sig vara deras default gateway. 5(14)
Internet Vad som händer nu är att de datorer som fått de förfalskade ARP-paketen börjat skicka sin trafik genom den röda datorn och den kan nu avlyssna alla inloggningar, IPtelefonisamtal, styra om trafik så när man går till en sida, t ex sin bank, så är man egentligen omstyrd till en annan sida etc. Det finns färdiga programvaror för detta som är mycket enkla att använda. Se www.oxid.it till exempel. Även många trådlösa hotspots lider av detta problem så det är på sin plats att alltid vara lite extra försiktig när man surfar via sådana Nedan ser ni exempel på tester gjorde med Cain i bredbandsnät. Efter bara några sekunders test så kan man se avlyssnade inloggningar för mail, ftp och IP-telefoni. 6(14)
3.2 Förhindra spoofing och varför vi loggar Detta krav är till för att någon annan i nätet inte skall kunna ta din identitet. Om du t ex har blivit tilldelad en IP-adress dynamiskt eller statiskt ska ingen annan kunna använda den så länge den tillhör dig. Typfallet är att någon begår ett brott av något slag och operatörens loggar av IP-adressen pekar mot dig men någon annan i nätet är den skyldige. Därför har vi också krav på att all tilldelning av IP-adresser skall loggas. Det är inte populärt att logga den informationen idag men jag anser att det är nödvändigt att logga för att hjälpa brottsutredande myndigheter, IPRED-mål undantaget. 3.3 Spärr för UPnP UPnP, Universal Plug And Play, är ett protokoll som är tänkt att användas i hemmet/kontoret bakom en brandvägg/router. UPnP aktiveras ofta utan att du vet om det när du installerar programvaror för att styra skrivare, routrar mm. Många användare har alltså detta igång utan att vara direkt medveten om det. Att köra UPnP oskyddat ut på 7(14)
Internet kan t ex innebära att dina utskrifter hamnar på en grannes skrivare. Därför har vi kravet att UPnP mellan slutkunder ska vara spärrat. 3.4 Spärr av IPv6 Om vi inte spärrar för IPv6 mellan slutkunderna och utrustningen inte stödjer SEC för IPv6 så kan attacker liknande den med ARP-poisoning genomföras. Den här gången är det inte ARP-protokollet som används utan du talar om för dina grannar att du är en IPv6-router och/eller DHCPv6-server. Då alla operativsystem idag har IPv6 aktiverat från fabriken så kommer det att gå att styra om mycket trafik till den röda datorn och man kan avlyssna vad de andra gör. 8(14)
4 SEC, Secure Enduser Connection This is not a RFC-document but the key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119. We are following The IETF WF for Source Address Validation Improvements (savi) and IPv6 Router Advertisement Guard with interest but we don t think they do it all when I comes to a secure network. 4.1 Requirements for IPv4 The demands were primary written for shared broadcast domains, but every point of test must be executed if one VLAN/subscriber or similar technologies is used. In my experience there are many possible configuration errors in networks that can make some errors described below occur. 4.1.1 So-called DHCP-snooping to filter out DHCP messages between subscribers must be located on the access ports. I.e. a subscriber must not be able to act like a DHCP-server for another subscriber. 4.1.2 It must not be possible to apply a static IP-address to get pass the port that the client is connected with, only the approved IP-address from the static entry or DHCP approved address can be used. 4.1.3 When a client is assigned one or more addresses via DHCP it must only be possible for these specific address/addresses to send traffic in through that port. 4.1.4 If the address is not renewed via the DHCP-server a anti spoofing filter as in 4.1.2 must be applied. 4.1.5 All types of spoofing/poisoning must be prevented for the TCP/IP and ARPprotocols. I.e. the addresses which are approved from DHCP are the only addresses that must occur as the source address in TCP/IP and ARP packets. 9(14)
4.1.6 Traceability must be added to the DHCP-requests in L2-mode as in option 82 for example. The access switch must not be DHCP-relay. 4.1.7 Filter possibilities may exist between client ports. For example arbitrary TCP/UDP-ports to be filtered between subscribers. 4.1.8 If static IP-addresses are used, the subscriber port must only allow communication for the port defined IP-address as source address in IP and ARP packets. 4.1.9 UPnP must be blocked between subscriber ports. 4.1.10 ICMPv6 messages for RA and DHCPv6 must be blocked between subscriber ports. 4.1.11 There may be a possibility to filter different Ether types to only allow 0 800 and 0 806 to pass between subsriber ports. This is a good function to filter out PPPOE messages for example. In Sweden PPPOE is very unusual so that s why it isn t a must requirement. 4.1.12 The network may, if possible, use force forward /Port isolation to isolate the subscribers from each other and in that way build a more secure network. It can be managed as in 4.2 but also as a vlan / subscriber. 10(14)
4.2 Port isolation Some vendors can t filter out 4.1.1, 4.1.9, 4.1.10 and 4.1.11 above so they use what we call Port Isolation to achieve that. Private VLAN, source port filter and traffic segmentation are some vendor specific name for same function and it s is also a great thing in security issues to design the network like this. In the picture above the subscriber can t talk direct between each other and the router must use proxy ARP to accomplish communication between subscribers. If Port Isolation is used it s important that it s implemented everywhere and between different switches. 11(14)
4.3 Requirements SEC IPv6 The requirements given below with a brief explanation of the functions that must exist in a network with shared broadcast domain. This chapter describes the requirements in shared broadcast domain and in chapter 4.4 we look on other and better design. If your network don t fit in 4.3 or 4.4 you should look at 4.3 because that covers all security requirements. 4.4 IPv6 RFC There are few RFC drafts contains elements to our requirements but it is only drafts and do not meet all the requirements we set. The RFC drafts are: draft-ietf-v6ops-rogue-ra-01 draft-ietf-v6ops-ra-guard-08 draft-ietf-savi-fcfs-04 draft-ietf-savi-dhcp-06 4.4.1 IPv6 Stateless Address Auto configuration ( RFC2462 ) Snooping The equipment must create tables with the auto generated link local addresses so that duplicate addresses never occur. 4.4.2 IPv6 snooping There must not be possible to use another source IPv6-addresses than the auto generated link local, SLAAC or the DHCPv6 assigned address. The equipment must create a table with that information dynamically. If DHCPv6 Prefix Delegation ( RFC 3633 ) is used the equipment must add those prefix to the table mentioned above. 4.4.3 DHCPv6 (RFC 3315) snooping DHCPv6 messages must be blocked between subscribers and the network so not false DHCPv6 servers can distribute addresses. 4.4.4 Router Advertisement (RA, RFC 2462, RFC 5006) inspection RA inspection must be used in the network. Port Isolation as in point 4.1.1 is one way and my opinion is that SEND can t be used in unmanaged networks and maybe not in managed either. 4.4.5 Dynamic "IPv6 neighbour solicitation/advertisement" (RFC 24611) inspection There must be an IPv6 neighbour solicitation/advertisement inspection as in IPv4 Dynamic ARP inspection. The table with MAC-address and link-local and other assigned IPv6-addresses must be dynamically created by SLAAC or DHCPv6 messages. 12(14)
4.4.6 Neighbour Unreachability Detection (NUD, RFC 2461) inspection There must be a NUD snooping function so false NUD messages cannot be sent. 4.4.7 Duplicate Address Detection (DAD, RFC 4429) inspection Only addresses as in point 4.3.5 must be allowed as source IPv6-addresses in DUD messages. 4.4.8 IPv6 Multicast Listener Discovery v2 (RFC 3810) inspection Multicast Listener Discovery v2 must be enabled and snooping must be enabled so that only permitted hosts can receive the stream. 4.4.9 IPv6 Routing Header (RFC 2460, Next Header value 43) inspection IPv6 Routing Header messages must not be allowed between subscriber ports and subscriber and uplink to prevent routing loops. See also RFC 5095, Deprecation of Type 0 Routing Headers in IPv6. 4.4.10 UPNP filtering UPNP messages must always be blocked between subscriber ports. 4.4.11 There may be a possibility to filter different Ether types to allow only 0x86dd between subscriber ports. And most probably you must also permit 0 800 and 0 806 for IPv4. 13(14)
4.5 Other designs When you deploy IPv6 it s easy to think in normal IPv4 design but it s important to forget IPv4 and only think IPv6 here. 4.4 shows the requirements with shared broadcast domain and this section show how you should, if possible, deploy IPv6 and It s accomplished in both Port isolation / Force forward and a VLAN/subscriber model. The benefits is that It s easy to make the network secure and you can also protect the backbone against DOS attacks. 4.5.1 No GUA address space between PE and CPE IPv6 Stateless Address Auto configuration ( RFC2462 ) and DHCPv6 (RFC 3315) address assignment must not be used between PE and CPE. There must not be any connection between the subscribers CPE. The DHCPv6 server can be placed in other places than the PE above. 4.5.2 IPv6 snooping There must not be possible to use another source IPv6-addresses than the by DHCPv6 prefix delegation assigned prefix. If it is a VLAN/subscriber scenario a filter must be applied in the central router. If Port isolation / Force Forward is used a table with assigned prefix must be created at every subscriber port/connection. 14(14)