Niels Sijm en Thijs Kinkhorst
maart 2009
In grootschalige installaties is opslagconsolidatie een belangrijk thema. iSCSI is een snel opkomende techniek voor opslagconsolidatie met een gunstige prijs/kwaliteitverhouding. Het protocol heeft echter een aantal inherente beveiligingstekortkomingen. In dit rapport verzamelen en bespreken we de tekortkomingen en adviseren we over een veilige implementatie in een aantal veelvoorkomende scenario's.
Het inzetten van IPsec of andere cryptografie is in bijna alle gevallen essentieel om de beveiliging te waarborgen; echter IPsec is maar beperkt beschikbaar in software en apparaten.
Authenticatie en autorisatie zijn in iSCSI van elkaar ontkoppeld. Dit compliceert de implementatie en configuratie van iSCSI en maakt het eenvoudig beveiligingslekken te creëeren.
SCSI (Small Computer System Interface) is een zeer gevestigde techniek voor communicatie tussen computer en een opslagmedium. De huidige generatie is SCSI-3[1], dat al in 1995 gestandaardiseerd is. iSCSI (Internet SCSI) is van veel recenter datum, 2004[2], maar staat veel in de belangstelling. Kort samengevat biedt het de mogelijkheid om centrale opslag aan te bieden over standaard, dus relatief goedkope IP-infrastructuur.
Opslagconsolidatie leent zich met name voor grootschalige installaties, waarbij men te maken heeft met een diverse verzameling hosts die gegevens willen opslaan en gebruiken. Door te consolideren hoeft niet elk systeem opnieuw zorg te dragen voor bijvoorbeeld voldoende capaciteit of het alloceren van ruimte voor backups, maar kan dit op één plaats consequent opgelost worden.
Als men informatie gecentraliseerd opslaat en beschikbaar maakt op meerdere hosts, is deze informatie bijgevolg vaak van centraal belang of zelfs missie-kritiek voor de organisatie. Zeker bij opslagconsolidatie, waarbij gestreefd wordt naar één oplossing voor de dataopslagwensen is dit het geval: de integriteit en vertrouwelijkheid van de gegevens dient verzekerd te worden. Een goede beveiliging van de data die recht doet aan deze eisen is dus van groot belang.
Echter, iSCSI is niet zonder beveiligingsproblemen; het wordt in de praktijk al wel eens Insecure SCSI genoemd.[33] Hoewel die risico's in een kleinschalige omgeving nog wel acceptabel kunnen zijn, kunnen diezelfde risico's in grootschalige scenario's onaanvaardbaar groot zijn. Wil men dus iSCSI implementeren in een geconsolideerde omgeving, dan moet men zich bewust zijn van de risico's en beperkingen van het protocol om de veiligheid te kunnen waarborgen.
Uit het bovenstaande volgt onze onderzoeksvraag:
Hoe kan iSCSI in grootschalige installaties op een veilige manier toegepast worden?
Om deze vraag te beantwoorden gaan we als volgt te werk. In hoofdstuk 2 schetsen we kort de context waarin iSCSI opereert en geven een korte inleiding in het onderwerp. In hoofdstuk 3 beschrijven we een aantal scenario's waarin men in een grootschalige installatie iSCSI zou kunnen implementeren, mede gezien vanuit de adviezen die vendors hierover verstrekken. Over diverse beveiligingsrisico's van iSCSI is al eerder gepubliceerd. In hoofdstuk 4 hebben we deze risico's verzameld en beschreven. Vervolgens koppelen we in hoofdstuk 5 de risico's aan de scenario's om zo tot een advies te komen hoe men in een gegeven scenario iSCSI toch veilig kan implementeren. We sluiten af met een conclusie en een blik op de toekomst.
Dit onderzoek is uitgevoerd door Niels Sijm en Thijs Kinkhorst, in het kader van het vak Large Installation Administration van de masteropleiding System and Network Engineering, Universiteit van Amsterdam.
Bij het ontsluiten van storage is flexibiliteit een steeds belangrijkere eis. Tegelijkertijd dienen infrastructuren zo eenvoudig mogelijk te zijn. iSCSI is een techniek die het mogelijk maakt storage zowel flexibel als eenvoudig te ontsluiten en daardoor consolidatie haalbaar en doelmatig maakt.
iSCSI is een protocol om block devices over een TCP/IP-infrastructuur te benaderen: het tunnelt SCSI-commando's over een TCP/IP-infrastructuur. Het voordeel is dat storage op block level benaderbaar is. Dit in tegenstelling tot bijvoorbeeld NFS, een veelgebruikte techniek die storage op filesystem-niveau via TCP/IP ontsluit.
iSCSI laat zich vergelijken met Fibre Channel, dat ook storage ontsluit op block level. Het belangrijkste verschil is dat Fibre Channel een eigen fysieke infrastructuur vereist met glasvezels, host bus adapters en speciale switchingapparatuur. iSCSI daarentegen werkt op TCP/IP, een protocol suite die bij vrijwel alle organisaties in gebruik is. Implementatie van iSCSI is in dat geval eenvoudiger dan Fibre Channel, omdat er al ervaring is met de technieken en de benodigde apparatuur niet special-purpose is en dus goedkoper ingekocht kan worden.
Security maakt maar beperkt deel uit van het ontwerp van iSCSI. De mate van security hangt sterk af van de manier waarop iSCSI in infrastructuren wordt geïmplementeerd.
Een gedetailleerde behandeling van het iSCSI-protocol voert te ver voor dit rapport. Zie IP SANs door Clark[27] voor alle details; hier behandelen we de hoofdlijnen en gebruikte terminologie van het protocol.
iSCSI gebruikt dezelfde commando's als SCSI normaliter gebruikt over de systeembus.[1] Het doet dit echter als een apart protocol, dat bovenop TCP/IP draait. De opslag luistert op well-known port 3260[28], en de gebruiker zet naar die poort een TCP-verbinding op. Na authenticatie en autorisatie is op het lokale systeem de opslag zichtbaar als elk ander SCSI block device (bijvoorbeeld als /dev/sda onder Linux) en kan ook op die manier aangesproken worden, bijvoorbeeld door er een filesysteem op aan te maken.
iSCSI gebruikt de SCSI-terminologie voor het aanduiden van de verschillende actoren. Het systeem dat de fysieke opslag huisvest en beschikbaar stelt wordt de target genoemd, en de systemen die een verbinding initiëren met deze opslag om die vervolgens als lokaal block device te kunnen gebruiken, de initiator. Dit is zeer vergelijkbaar met wat in andere protocollen de server respectievelijk client wordt genoemd.
Door haar flexibiliteit kan iSCSI op verschillende manieren worden ingezet. Gebruikers kunnen zelf infrastructuren bouwen met iSCSI, of oplossingen van vendors gebruiken.
Vooral grote organisaties maken gebruik van NAS (network-attached storage) of SAN (storage area network) technologie om hun storage te centraliseren. Vendors bieden hiervoor oplossingen die gebruik maken van iSCSI.
We gaan er vanuit dat door vendors aangedragen oplossingen voor veel organisaties inspirerend of misschien zelfs leidend zijn voor hun eigen implementatieopzet. In dit hoofdstuk zetten wij de iSCSI-oplossingen van een aantal grote vendors uiteen. Vervolgens abstraheren wij deze oplossingen naar een aantal standaard scenario's.
Van de volgende drie belangrijke vendors die NAS- en SAN-oplossingen aanbieden hebben wij de aanbevolen iSCSI-implementatie onderzocht:
Hewlett-Packard ziet iSCSI als een kostenefficiënte oplossing voor "midrange"-bedrijven, en voor enterprises als een oplossing waarbij een bestaand SAN kan worden verbonden met kleinere afdelingen of locaties op afstand, hetgeen bij gebruik van Fibre Channel een probleem is. Voor een klassieke opstelling met een SAN dat een lokaal data center voorziet, blijven ze bij een Fibre Channel-gebaseerde oplossing.[37]
In een aantal documenten, waaronder IP SAN solution guide[3,30,34] raadt HP aan iSCSI op het back-office netwerk te draaien. Aan het netwerk zijn de applicatieservers en het IP SAN Storage system gekoppeld. De overige machines bevinden zich op een apart fysiek netwerk en communiceren met de applicatieservers en het IP SAN Storage system.
Juist de visie om kleinere departementen of locaties op afstand aan een bestaand SAN te verbinden, neigen weer naar het draaien van iSCSI over lokale IP-infrastructuur of zelfs WAN links.
In een onderlinge vergelijking van zijn SAN-oplossingen speelt Fibre Channel de hoofdrol, maar IBM schaalt iSCSI-ondersteuning onder de Enterprise SAN directors als optie voor als je een verbindingsmogelijkheid wilt met lage kosten. Ook is er nog een optie voor Fibre Channel over IP, een vergelijkbare techniek die in dit rapport verder niet behandeld zal worden.[38]
In haar iSCSI overview[4] geeft IBM een implementatievoorbeeld waarin zowel servers als clients direct met het Data and Storage IP Network verbonden zijn. Dit in tegenstelling tot haar Classic SAN implementatie, waarin alleen servers direct toegang hebben tot de storage via Fibre Channel.
In januari 2008 heeft Dell EqualLogic overgenomen[13], waarmee hun aanbod in iSCSI-oplossingen behoorlijk uitgebreid is. Het overzicht Dell iSCSI Storage Solutions[41] beschrijft iSCSI als een oplossing die je inzet op dezelfde manier als een traditioneel Fibre Channel SAN, maar dan met goedkopere apparatuur en technologie waarvan je al kennis hebt.
Volgens Dell is iSCSI net zo veilig als FC zolang je het logisch of fysiek scheidt. In hun End-to-End iSCSI Deployment Guide[14] wordt geadviseerd om iSCSI NIC's op een eigen "subnet" te configureren. In Securing storage area networks with iSCSI[15] wordt gemeld dat gebruik op een switched netwerk het "bijna onmogelijk" zou maken om pakketten af te luisteren of te injecteren. In hetzelfde document is de volgende illustratie opgenomen om te laten zien dat je het iSCSI-netwerk over je bestaande infrastructuur kunt draaien, maar dat je een firewall of router moet inzetten om het verkeer te scheiden van de rest van het netwerk. Een VPN-tunnel is de oplossing voor een iSCSI-verbinding die deels over een vreemd netwerk gaat.
Vóór de overname van EqualLogic had Dell een partnerschap met EMC. In de novembereditie van PowerStorage noemt een medewerker van EMC het een kostenvoordeel dat iSCSI over bestaande netwerkinfrastructuur gedraaid kan worden.[16]
HP, IBM en Dell verschillen van mening over de beschikbaarheid van iSCSI storage. HP raadt aan iSCSI alleen voor de back-office beschikbaar te stellen, alhoewel ze ook suggereren om verbindingen op afstand op te zetten. IBM daarentegen ziet iSCSI als kans om storage op block level aan clients beschikbaar te stellen. Dell kiest een tussenvorm waarbij je wel hetzelfde netwerk gebruikt maar netwerkcomponenten als routers en firewalls gebruikt om een scheiding van verkeer te implementeren, en ziet mogelijkheden om over langere afstand verbindingen op te zetten.
De scenario's die wij gaan onderzoeken zijn daarom de volgende:
Het dedicated netwerk van scenario 1 komt het meest overeen met de klassieke SAN zoals die door HP gezien wordt. In een grote organisatie met opslagconsolidatie betekent dat nog steeds een groot aantal verschillende machines toegang zal hebben tot dit netwerk, waarbij er verschillende categoriën gegevens zijn, waarvan elk beschikbaar gesteld wordt aan een bepaalde subgroep van de machines.
In scenario 2 kiest men ervoor om iSCSI te draaien over het bestaande corporate LAN. Dit komt overeen met de voorbeelden van HP en IBM, bijvoorbeeld in een enterpriseomgeving waarin één centraal datacenter niet mogelijk is omdat afdelingen op afstand ook met het SAN willen communiceren, of omdat men meerdere datacenters heeft die onderling storagegerelateerd verkeer moeten kunnen uitwisselen.
Het bieden van iSCSI-toegang via WAN komt ook terug in het voorbeeld van Dell. Hierbij kun je denken aan een grote organisatie met een gecentraliseerd SAN, die een aantal dependances heeft die ook toegang willen krijgen tot de data. Dit is met klassiek Fibre Channel niet mogelijk. Ook kan men denken aan het maken van snapshots of backups op een remote locatie, of zelfs het migreren van virtual machines tussen verschillende datacenters over een WAN-verbinding.
Onderstaande afbeeldingen geven een schematische weergave van de netwerkinfrastructuur die elk scenario representeert.
Een verantwoorde implementatie van iSCSI houdt rekening met het vereiste niveau van vertrouwelijkheid en integriteit van de opgeslagen data. Om een uitspraak te kunnen doen over een verantwoorde implementatie van iSCSI in diverse omgevingen, is het uiteraard nodig een goed begrip te hebben van welke beveiligingsrisico's van toepassing zijn bij gebruik van iSCSI. Hier is al een en ander over gepubliceerd; we brengen de verschillende publicaties bij elkaar om zo een aantal risico's te identificeren.
Een aanvaller zou netwerkpakketten kunnen afluisteren, zich voordoen als een legitieme initiator, of zelf pakketten met data of commando's kunnen injecteren (denial of service laten we in dit onderzoek buiten beschouwing). Als we integriteit en vertrouwelijkheid vertalen naar technische eisen, komen we uit op de volgende aspecten:
Het aspect beschikbaarheid, of te wel het risico van denial-of-service-aanvallen, laten we in dit rapport buiten beschouwing. Ook kiezen we ervoor een pure iSCSI-installatie te beschouwen. Dat betekent dat bijvoorbeeld iSNS[32] niet als factor meegenomen wordt.
Om te kunnen vaststellen of een initiator legitiem is, vindt bij het opzetten van de verbinding tussen initiator en target authenticatie plaats. Hiervoor worden een gebruikersnaam en wachtwoord (shared secret) uitgewisseld.
Echter, deze uitwisseling is niet verplicht. Sterker nog, in belangrijke implementaties zoals Open-iSCSI[25] en Microsoft iSCSI initiator[29] staat authenticatie standaard uitgeschakeld en kan iedereen met iedereen verbinden. Dit is te zien in het volgende fragment van het Open-iSCSI-configuratiebestand:
# To enable CHAP authentication set node.session.auth.authmethod # to CHAP. The default is None. #node.session.auth.authmethod = CHAP
Schakel je authenticatie in, dan verplicht RFC 3720[5] het gebruik van CHAP om het wachtwoord niet in cleartext uit te wisselen. Dit Challenge-Handshake Authentication Protocol (RFC 1994[6]) is een challenge-response systeem: target en initiator hebben een shared secret (wachtwoord). De target stuurt een challenge, waarna de initiator een hash berekent van deze challenge en het wachtwoord.
CHAP werkt als volgt:[8]
CHAP biedt slechts beperkte bescherming van het wachtwoord.[9,10] Een sniffer die de interactie heeft afgeluisterd, heeft beschikking over drie van de vier elementen uit de vergelijking: ID, nonce en hash. Alhoewel hij natuurlijk niet direct de hash kan terugrekenen, kan hij door één pakket af te vangen een offline brute force attack beginnen om het wachtwoord terug te halen.[36] Het offline-karakter maakt het probleem paralleliseerbaar en ongevoelig voor rate limits. We verwachten dat in een organisatie met veel verschillende opslagafnemers het wachtwoord na installatie niet snel meer gewijzigd zal worden. Hierdoor kan de aanvaller desnoods maanden later terugkomen met het gekraakte wachtwoord om zich voor te doen als een legitieme gebruiker.
Voor een andere mogelijke aanval is actieve inmenging nodig: reflectie, waarbij het idee is dat een aanvaller een machine een hash laat genereren die vervolgens gebruikt wordt om tegen diezelfde server te authenticeren.[12] Bij iSCSI werkt dit als volgt. Authenticatie kan twee kanten op werken: van initiator naar target en vice versa. In dat geval is sprake van mutual authentication. Mutual authentication is voor iSCSI niet verplicht gesteld. Een iSCSI-setup is dus niet per definitie kwetsbaar voor een CHAP reflection attack.
De CHAP reflection attack werkt als volgt. De aanvaller begint een sessie met de target en ontvangt een ID en een challenge. In een tweede connectie vraagt hij diezelfde target om zich he authenticeren en stuurt de zojuist verkregen tupel mee. De server zal de juiste hash terugsturen, en die hash wordt direct via de eerste verbinding gestuurd, waarna de aanvaller geauthenticeerd is.[11]
Autorisatie is een verplicht onderdeel van de iSCSI-standaard. Een target kan meerdere logical unit numbers (LUN's) aanbieden, waarvan opgegeven kan worden welke initiators er toegang toe hebben.
De identificatie van een initiator gaat via een Extended Unique Identifier, T11 Network Address Authority of, meestal, door een iSCSI Qualified Name (IQN). Op de target kan gedefinieerd worden welke IQN's toegang hebben tot bepaalde LUN's; bijvoorbeeld de webservers tot hun content en het administratieve netwerk tot de salarisgegevens. Wil een aanvaller die op het aangesloten netwerk zit toegang tot een bepaald LUN, dan heeft hij afgezien van de eerder genoemde optionele authenticatie, alleen het juiste IQN nodig. Met dit IQN kan hij precies de pakketten construeren die hij nodig heeft.[11]
De IQN is een string die bestaat uit iqn., dan een vendorspecifiek deel met een datum en domeinnaam, bijvoorbeeld iqn.1991-05.com.microsoft of iqn.1993-08.org.debian. Tot slot nog een optioneel variabel deel.[31] Bij de Microsoft initiator is dit default de hostname:
Zonder het optionele deel is de identificatie dus volledig voorspelbaar, en als die wel wordt toegevoegd is die vaak niet willekeurig. Mocht een aanvaller het dan nog niet lukken om de juiste waarde te achterhalen of enumereren, dan heeft hij nog een optie: de IQN's worden, in tegenstelling tot de CHAP-gehashte wachtwoorden, cleartext meegestuurd en zijn dus afluisterbaar, behalve als de verbinding tussen target en initiator adequaat versleuteld is.
Eénmaal geauthenticeerd kan een initiator elke gewenste IQN aannemen en zodoende verbinding maken met alle LUN's. De target houdt bij welke IQN's toegang hebben tot welke LUN's. Authenticatie is in dit model niet opgenomen; authenticatie geeft toegang tot het storage network maar doet niet aan identificatie van initiators. Juist in een grootschalige installatie met geconsolideerde opslag kunnen er verschillende categoriën opslagafnemers zijn die men strict gescheiden wil houden. De "aanvaller" van een LUN kan dus best een voor een ander LUN geauthenticeerde en geautoriseerde gebruiker zijn.
Feitelijk zijn authenticatie en autorisatie dus losgekoppeld, en is het eenmaal geauthenticeerd mogelijk elke identiteit aan te nemen bij de autorisatie voor een LUN.
Als we in de context van iSCSI spreken over vertrouwelijkheid, dan doelen we op het onderscheppen van iSCSI-verkeer zodat opgeslagen gegevens gelezen kunnen worden. Was het aanvankelijk nog optioneel[17], in de iSCSI RFC wordt vertrouwelijkheid geïntegreerd met de eis dat een implementatie ondersteuning biedt voor IPsec.[18,19] Dit betekent dat bij gebruik van iSCSI sec de blokdata in cleartext over de lijn gaat.
IPsec is een methode om IP-verkeer op een verbinding te versleutelen. IPsec komt buiten het gebruik voor VPN's vooralsnog weinig van de grond.[20] Als reden wordt met name genoemd dat het protocol te ingewikkeld en inflexibel is, hetgeen leidt tot een grotere kans op fouten in implementaties, compatibiliteitsproblemen en operationele problemen zoals sleutelbeheer.[21]
Als gevolg hiervan blijkt de ondersteuning van IPsec in iSCSI-producten marginaal. In de handleiding van de Dell MD3000i vinden we: IPsec is not supported[22]; de EqualLogic PS Series ondersteunt het ook niet[35]. HP schrijft dat the HP-UX iSCSI Software Initiator has not been tested with IPSec due to the lack of iSCSI targets that support IPSec.[23] Bij een software target of initiator kunnen er nog mogelijkheden zijn om het besturingssysteem IPsec te laten afhandelen, maar voor iSCSI-appliances is het in zo'n geval niet meer mogelijk om IPsec end-to-end te implementeren.
Een alternatief voor het versleutelen van de hele verbinding is om dit te doen voor de specifieke TCP-connectie die gelegd wordt tussen initiator en target. Dit kan met Transport Layer Security (TLS, voorheen SSL).[24] Met deze techniek is al veel ervaring, bijvoorbeeld voor het beveiligen van HTTP-verbindingen. Hiervoor is ondersteuning nodig in de software die de connectie opzet, maar wij hebben geen appliances kunnen vinden die TLS ondersteunen. Ook softwareimplementaties zoals Open-iSCSI[24] en iSCSI Enterprise Target[25] ondersteunen dit niet.
Als het desalniettemin lukt de verbinding te versleutelen is dit wellicht niet altijd gewenst. Encryptie van de gegevensverbinding brengt niet-verwaarloosbare kosten voor de aangesloten machines met zich mee. In het geval van IPsec kan het, specifiek voor iSCSI, tot 90% extra CPU-belasting zorgen.[7] Dit kan problematisch worden in een grootschalige opzet. Omdat performance een belangrijke factor is in opslag, zal dit meegewogen moeten worden in de afweging of encryptie ingezet kan worden op de verbindingen. Een speciale host bus adapter die de encryptie voor zijn rekening neemt kan helpen, maar dit betekent extra hardware en dus extra kosten, terwijl standaard hardware en lage kosten juist een onderscheidend kenmerk van iSCSI zijn. Dit kan er toe leiden dat encryptie niet ingezet wordt omdat het de performance te nadelig beïnvloedt.
Door de verschillende netwerkarchitecturen zijn de verschillende scenario's vatbaar voor verschillende veiligheidsrisico's. Van elk scenario is in kaart gebracht welke risico's relevant zijn.
In dit scenario is toegang tot het netwerk voorbehouden aan machines die direct aangesloten zijn op het fysiek afgeschermde storagenetwerk. Om deze eigenschap te garanderen moet het dus goed fysiek beveiligd zijn, bijvoorbeeld door het netwerk te beperken tot één datacenter.
Het hangt van de omgeving af in hoeverre de aangesloten hosts als te vertrouwen beschouwd kunnen worden. In principe zou je elke aangesloten host kunnen vertrouwen, maar de werkelijkheid is troebeler. Een aangesloten host kan bijvoorbeeld gecompromitteerd worden door een aanvaller van buitenaf. Een grote omgeving betekent veel verschillende hosts die toegang hebben tot het SAN, wat deze kans reëel maakt.
Ook al wordt deze kans geminimaliseerd, dan nog is er het probleem van verschillende gebruikersgroepen die rechten hebben op verschillende LUN's. Als een gebruiker van LUN A ongeautoriseerd verkeer kan zien van en naar LUN B, is er feitelijk weinig onderscheid meer met het corporate LAN.
In het algemeen zou je in een grootschalige organisatie een dedicated netwerk dus net zo goed moeten beveiligen als wanneer je iSCSI op het corporate LAN gebruikt, en dus de adviezen in sectie 5.2 moeten opvolgen.
Ga je er vanuit dat in het slechtste geval aanvallers op hosts op het dedicated LAN géén roottoegang hebben, kan kun je ook zonder IPsec de beveiliging waarborgen. Niet-root-gebruikers kunnen niet al het verkeer afluisteren, dus encryptie van de verbindingen is niet nodig en ook het sniffen van de CHAP responses of IQN's is dus niet mogelijk. Wat wel moet gebeuren is ervoor zorgdragen dat de initiator names niet voorspelbaar zijn, zodat de grens tussen twee LUN's niet overschreden kan worden. Alleen als er authenticatie gebruikt wordt met een sterk wachtwoord en het optionele deel van de IQN altijd ingesteld wordt op een willekeurige string van voldoende lengte, is deze oplossing als veilig te beschouwen.
In dit geval gaan we er vanuit dat fysieke toegang tot het netwerk niet afgeschermd kan worden, en er dus maatregelen genomen moeten worden om ongewenste toegang en afluisteren door derden tegen te gaan.
Authenticatie is van belang omdat iedere host op het LAN contact kan maken met het iSCSI-target. Bij gebruik van CHAP zijn de risico's van offline hash cracking en de reflection attack relevant, aangezien de verbinding tussen de host en het iSCSI target niet per definitie betrouwbaar is. De risico's van het kraken van de hash zijn in te perken door een lang en willekeurig secret te kiezen, dat regelmatig vervangen wordt. Een reflection attack blijft echter mogelijk, maar kan worden bestreden met access control lists, dus het alleen toestaan van specifieke IP's om te verbinden met de target. Dit kan in een grootschalige installatie wel lastig beheerbaar worden.
Autorisatie vindt plaats op basis van de naam van de initiator. Indien deze naam kan worden afgeluisterd is het LUN gecompromitteerd. De verbinding tussen een host en een iSCSI target over een corporate LAN is niet per definitie betrouwbaar. Autorisatie over een onversleutelde verbinding kan dus compromittering van het benaderde LUN tot gevolg hebben.
Bij compromittering van een LUN lopen ook andere LUN's gevaar. Namen van initiators zijn vaak opgebouwd uit een vaste prefix en een makkelijk te raden volgnummer. In dat geval kan door middel van een enumeration attack een hele reeks van LUN's gecompromitteerd raken. Dit risico is in te perken door IQN's, in tegenstelling tot wat vaak de default is, een lange, willekeurige optionele component te geven. Als er echt strict gescheiden autorisatiedomeinen in een organisatie zijn, dan moet er serieus overwogen worden om per domein een target of zelfs een apart apparaat neer te zetten, omdat autorisatie binnen een target maar erg beperkt mogelijk is.
SCSI commands worden bij iSCSI in leesbare vorm over de verbinding getransporteerd. Een Man in the Middle kan communicatie met de LUN dus op block device-niveau afluisteren. Ook kan een Man in the Middle zelf SCSI commands naar de LUN sturen waarmee deze volledig lees- en schrijftoegang tot de LUN heeft. Wanneer iSCSI over een corporate LAN wordt gebruikt is de kans op een Man in the Middle reëel.
Een manier om zowel de authenticatie als vertrouwelijkheid te regelen is gebruikmaken van IPSec of SSL/TLS. IPSec authenticeert hosts op network-niveau (OSI layer 3). SSL/TLS werkt op de transportlaag (OSI layer 4). De verbinding is versleuteld zodat pakketten niet afgeluisterd kunnen worden, en alleen via X.509-certificaten geauthenticeerde hosts kunnen met elkaar verbinden. Op deze technieken zijn geen relevante aanvallen bekend.
Let wel dat autorisatie dan nog niet per definitie geregeld is, omdat als er eenmaal verbinding is tussen een valide initiator en target, deze initiator zijn IQN zou kunnen veranderen naar een IQN met andere autorisaties. Zorgvuldigheid met betrekking tot IQN-selectie is dus nog steeds van belang. Gebruik van IPsec of TLS is in dit scenario dus het meest geschikt, maar de ondersteuning in apparaten is beperkt en encryptie brengt performanceoverhead met zich mee. Hier dient bij de selectie van appliances en software rekening mee gehouden te worden. Bijkomend nadeel is dat SSL/TLS een Public Key Infrastructure (PKI) vereist. PKI is in technisch opzicht eenvoudig maar vereist wel beheer en compliceert daarmee de implementatie van SSL/TLS.
In principe zou een corporate LAN meer vertrouwd moeten zijn dan het wereldwijde Internet. Echter, in een grootschalige omgeving is het risico op een kwaadwillende partij op het corporate netwerk al groot genoeg om dit LAN niet te vertrouwen. We zagen in de vorige sectie al dat geen enkele entiteit als vertrouwd kan worden beschouwd.
Voor iSCSI over het Internet gelden dus in principe dezelfde aanbevelingen als voor het corporate LAN. Echter, je zou ook gebruik kunnen maken van een combinatie van technieken. Als je een datacenter in Europa hebt en een backuplocatie in de VS, kun je beide locaties inrichten als een dedicated netwerk met de voordelen daarvan, zoals geen encryptieoverhead en het kunnen inzetten van appliances en software die geen IPsec ondersteunen. Uitsluitend tussen de twee locaties zet je een VPN-verbinding op, bijvoorbeeld met IPsec, tussen de twee routers aan elke zijde. Dit maakt backups op lange afstand haalbaar, zonder dat je tegen de beperkingen van lokale installaties aanloopt.
Deze methodiek zou ook ingezet kunnen worden binnen een corporate LAN, waarbij je twee vertrouwde segmenten, bijvoorbeeld twee datacenters op verschillende locaties, verbindt met een VPN-verbinding over het tussenliggende, minder vertrouwde netwerk.
Voor hen die erover denken iSCSI in hun omgeving te implementeren is de belangrijkste conclusie dat eigenlijk geen van de scenario's veilig is zonder gebruik van encryptie. Zelfs in het dedicated netwerk, dat op het eerste gezicht veilig lijkt, kan een zwakheid op één host compromittering van het hele SAN betekenen als er geen IPsec gebruikt wordt.
Helaas is tegelijkertijd ook onze conclusie dat cryptografie zoals IPsec of TLS in de context van iSCSI maar heel weinig werkelijk beschikbaar is. Beheerders die iSCSI overwegen zullen dus op zoek moeten naar apparatuur en software die dit aankan, of zich beperken tot het dedicated netwerk en zich de beperkingen en risico's daarvan realiseren. Eventueel is het mogelijk om direct voor het target en elke initiator een speciaal encryptiedevice neer te zetten, maar dit moet dan al bij het ontwerp van het SAN meegenomen worden.
Zelfs met gebruikmaking van encryptie blijft autorisatie een probleem. Het kiezen van moeilijk te raden IQN's en LUN names in combinatie met encryptie lost dit probleem grotendeels op. Een meer waterdichte implementatie is de situatie waarin elk target maar één LUN omvat. Maar juist bij consolidatie is dit vaak ongewenst.
Aan vendors zouden we willen adviseren om IPsec en TLS op te nemen in hun producten, en ervoor te zorgen dat deze en andere beveilingsaspecten standaard ingeschakeld zijn. Zolang dat niet het geval is, zou men duidelijk moeten propageren om iSCSI alleen op een volledig gescheiden netwerk aan te bieden.
De gesignaleerde problemen met iSCSI komen voor een belangrijk deel voort uit de ontwerpbeslissingen in het protocol. Het gebrek aan koppeling tussen authenticatie en autorisatie leidt juist in geconsolideerde omgevingen tot problemen. Kiezen voor IPsec als beveiligingsinfrastructuur en niet zelf het wiel opnieuw uitvinden is theoretisch een goed idee. Helaas blijkt dat in de praktijk IPsec veel implementatiehindernissen kent en het gevolg is dat het protocol nu bij veel implementaties zonder cryptografie opereert.
In dit onderzoek hebben we maar beperkt praktisch onderzoek gedaan en ons voornamelijk gebaseerd op geschreven bronnen. Wellicht dat in een proefopstelling meer informatie verkregen kan worden over de werkelijke haalbaarheid van attacks of juist nieuwe problemen aan het licht komen.
We hebben iSCSI op zichzelf staand beschouwd. Er zijn natuurlijk nog andere oplossingen voor opslagconsolidatie (Fibre Channel, NFS, CIFS), die ook hun mogelijkheden en beperkingen hebben. Het is ook goed mogelijk om elk van die technieken onveilig te implementeren. Wel is het zo dat het feit dat iSCSI over IP draait, het verleidelijker maakt om het over een onveilige verbinding te gebruiken dan Fibre Channel, dat een dedicated fysieke verbinding afdwingt. Een vergelijking tussen de technieken en hoe goed ze te beveiligen zijn in een grootschalige omgeving zou nuttig kunnen zijn.
Beschikbaarheid van storage is van groot belang in een geconsolideerde omgeving; is die opslag niet beschikbaar dan zullen veel applicaties dat ook niet meer zijn. Alhoewel wij nog niet gekeken hebben naar denial of service, kunnen we ons voorstellen dat er significante risico's bestaan als men iSCSI over het corporate LAN draait.
Het zou interessant kunnen zijn om in aanvulling op dit onderzoek te kijken naar de rol van iSNS (Internet Storage Name Service)[32] in de genoemde setups. Er is niet veel onderzoek gedaan naar deze techniek en de veiligheid ervan in grootschalige omgevingen.
iSCSI is niet de enige speler in het veld van SAN over standaard netwerkinfrastructuur. Er is een redelijk aantal alternatieven, die ook erg verschillen in mate van adoptie en volwassenheid. Een aantal voorbeelden zijn Fibre Channel over IP (FCIP), Internet Fibre Channel Protocol (iFCP), en Fibre Channel over Ethernet (FCoE). Ook is er nog HyperSCSI en ATA over Ethernet. Sommige zijn ook IP-gebaseerd, andere draaien direct op Ethernet. Deze protocollen zouden ook aan een (al dan niet vergelijkend) onderzoek onderworpen kunnen worden.[39,40]
Tot slot zien we nog mogelijkheden in minder gangbare technieken om iSCSI beter te beveiligen. De standaard biedt mogelijkheden voor het inzetten van Kerberos voor authenticatie en autorisatie[42], maar hierover is weinig praktische informatie voorhanden. Is er vendorondersteuning voor, op een manier die werkbaar is in een grote organisatie? SSH Local port forwarding zou een alternatief kunnen zijn voor situaties waarin de iSCSI software zelf geen encryptieondersteuning heeft.[43] Hoe haalbaar is dit in een grotere installatie?
© 2009 Niels Sijm en Thijs Kinkhorst.
De Creative Commons Naamsvermelding 3.0 Nederland Licentie is van toepassing op dit werk. Ga naar http://creativecommons.org/licenses/by/3.0/nl/ om deze licentie te bekijken.