Inmiddels is iedereen er wel van overtuigd. Public Cloud is de toekomst in het IT landschap. Aanvankelijk verzonnen we redenen om niet naar de cloud te moeten. We vonden de cloud bijvoorbeeld niet secure. De data stond niet in Nederland en het was alleen geschikt voor websites. Ook was het voornamelijk bedoeld voor start ups, en ehh, oh ja, de cloud was te duur. Toch zijn er door de jaren heen steeds meer bedrijven die kozen voor de Public Cloud. Blijkbaar waren onze redenen drogredenen. Of misschien hadden we de feiten onjuist, een soort alternatieve waarheden? Nu we deze vooroordelen achter ons hebben gelaten, kunnen we naar de Cloud. Of gelooft u nog steeds dat de mens niet op de maan is geweest en dat Elvis nog steeds leeft?

Natuurlijk verloopt de adoptie niet bij alle bedrijven even snel. Het is alleen niet meer de vraag “Of we naar de Cloud gaan”, maar “Wanneer”. Een interessante observatie daarbij is dat Amazon’s AWS verreweg de grootste aanbieder is van Public Cloud diensten. Interessant omdat Amazon geen speler was in het IT landschap. Ze begon ooit als webshop voor boeken, maar bouwde al snel een infrastructuur waar haar klanten ook graag gebruik van maakten. Inmiddels is ze de grootste aanbieder van Public Cloud diensten. AWS (Amazon Web Services) is vele malen groter dan alle overige Cloud aanbieders bij elkaar. Maar hoe maken we AWS geschikt voor grote bedrijven?

Multi account structuur

Wanneer je snel aan de slag wilt met Public Cloud, dan is een Amazon AWS account zo aangelegd. Voor zo’n account is slechts een credit card nodig en je bent “In business”. Alle AWS diensten staan je vervolgens ter beschikking. Ook echte enterprise features zoals Content Delivery Networks en uitgebreide security tools. Dat klinkt allemaal prima, maar gaan grote bedrijven er zo ook mee om? Is het echt een kwestie van account aanleggen credit-card-klaar? Misschien dat bedrijven op deze wijze starten, maar na verloop van tijd kiezen zij voor een structuur die past bij een enterprise.

Grote bedrijven hebben bijvoorbeeld behoefte om applicaties van elkaar gescheiden te houden. Ook willen ze uitgebreid gebruikersbeheer (met gedelegeerde rechten) te kunnen uitvoeren of IT architectuur uitgangspunten te kunnen afdwingen (zoals off site backups). Daarnaast willen ze security maatregelen kunnen treffen (zoals off site audit trails) en overzicht te houden over de kosten (consolidated billing). In AWS is dit mogelijk door meerdere accounts aan elkaar te koppelen, waarbij sommige account generieke voorzieningen verzorgen, de multi account structuur.

Root account

Nu is het belangrijk om te weten dat de eerste user die je aanlegt de root user is. Dit is de enige user binnen het AWS account waarmee alles gedaan kan worden. Het is ook de enige die het gehele account kan opgeheffen. Het dagelijks gebruik van deze root user is daarom ook af te raden. Deze root user credentials kunnen beter in een kluis worden opgeslagen. Voor het dagelijkse gebruik van de AWS console (de web toegang tot alle AWS diensten) worden gewone user accounts gemaakt.

Operationele- versus non-operationele accounts

Bij het gebruik van meerder AWS accounts wordt een onderscheid gemaakt tussen operationele accounts (zoals bijvoorbeeld een account waarin de productieomgeving van een specifieke applicatie draait) en non-operationele accounts (zoals bijvoorbeeld een account waarin alleen gebruikersbeheer wordt gedaan). AWS biedt daarom de mogelijkheid de accounts op een zinvolle manier te integreren zoals bijvoorbeeld de kosten in een billing account te verzamelen. Hiermee kunnen zaken effectief van elkaar gescheiden worden. Door de verschillende operationele accounts van elkaar te isoleren kunnen bijvoorbeeld fijnmazig rechten worden gegeven aan beheerders. Ook kunnen de omgevingen elkaar niet beïnvloeden, praktisch, want dit zorgt voor een hoger security niveau.

Welke non-operationele account zijn er nodig?

Billing

Het is praktisch om alle kosten centraal te verzamelen, ook wel consolidated billing genoemd. Dit gebeurd in een “Billing account”. De billing account wordt niet gebruikt voor productietaken, maar alleen voor de financiële afhandeling van de kosten. Zo “Hangen” alle accounts aan dezelfde credit card, of worden alle kosten middels een enkele factuur afgerekend. De voordelen hiervan zijn dat de volumekorting van AWS over het gehele bedrag wordt verkregen en dat gebruikers met een financiële verantwoordelijkheid alleen toegang krijgen tot deze billing account. Zij hebben geen toegang nodig tot een operationele account en houden toch overzicht over de kosten. Deze kosten worden overigens in groot detail inzichtelijk gemaakt, ze zijn per account en per resource type of tag te bekijken. Zo is te zien wat de kosten van storage zijn, of wat de kosten zijn van een ontwikkel account.

IAM

Naast de billing account is er een “Identity and Access Management (IAM) Account”. Dit is het account waar het gebruikersbeheer uitvoert wordt. Het enige dat in deze account gemaakt wordt zijn users, groepen en rollen. De overige accounts (zoals operationele accounts) hebben geen gebruikers. Vanuit de IAM account krijgen users rechten binnen andere accounts. De voordelen hiervan zijn evident, centraal gebruikersbeheer, een centrale account waarop users inloggen en geen users in de andere accounts. Deze manier van werken leidt ook tot een hogere mate van security en een beter controleerbaarheid daarvan. Voor de duidelijkheid, de users waarover we hier spreken zijn users die werken binnen de webconsole van AWS en niet de eindgebruikers van applicaties.

Audit

Vanuit security standpunt bezien is het wenselijk dat een audit trail veiliggesteld wordt voor het geval een applicatie of account gecompromitteerd raakt. In zo’n geval moet het audit trail aantoonbaar onveranderd zijn en op een andere plaats opgeslagen zijn. Speciaal hiervoor is de “Audit Account”. Dit account bestaat uit S3 buckets (object store – opslag van files) waarin de audit informatie wordt weggeschreven. Ieder operationeel account heeft een eigen S3 bucket waarin alleen dat account mag schrijven, ze mag er niet lezen en niet verwijderen. Uiteraard worden de kosten verhaald op de account die de betreffende S3 bucket gebruikt en netjes verzameld in de billing account.

Backup

De bovenstaande constructie wordt ook gebruikt voor backups. Bedrijven willen graag dat backups aantoonbaar veilig worden opgeslagen, liefst met aparte credentials. Dus waarom zou niet dezelfde constructie gebruikt kunnen worden als bij de audit account? En dat is precies waarom er een “Backup Account” gemaakt wordt. Deze account heeft alleen S3 buckets voor de verschillende operationele accounts waarin zij een backup mogen schrijven. Ook hier kunnen zij de backups niet lezen of verwijderen. De kosten van iedere bucket wordt verhaald op de betreffende operationele account en verzameld in de billing account.

Shared

Soms zijn er generieke diensten die beschikbaar gesteld moeten worden aan de operationele accounts, zoals bijvoorbeeld een GIT repository (een versiebeheersysteem voor software en configuratie files), een Puppetmaster (state config software) of centrale opslag van gedeelde informatie. Het gebruik van een zogenaamde “Shared Account” dan erg handig.

My Organization

Inmiddels heeft Amazon een nieuwe dienst gelanceerd die het opzetten en beheren van een multi account structuur vereenvoudigen, “My Organization”. Organizations geeft overzicht over de gekoppelde accounts (de billing account is leidend). Centraal kunnen bijvoorbeeld beperkingen op andere accounts aangelegd worden.

Tot slot

Er is inmiddels een goed beeld geschetst over een enterprise structuur in AWS. De non-operationele accounts zorgen voor overzicht, inzicht en betere isolatie van enterprise functies. Middels uitgebreide autorisatie kunnen users rechten krijgen op de verschillende functionele gebieden die zo gecreëerd zijn. De hier beschreven non-operationele accounts zijn wel de belangrijkste, maar er is geen beletsel er nog meer te maken als dat opportuun mocht zijn.

Met het ondersteunen van een dergelijke enterprise structuur toont Amazon aan dat Public Cloud klaar is for the enterprise, maar dan wel met de juiste inrichting.

Een sterk opkomende trend is The Internet of Things (IoT). Het betreft het op internet beschikbaar maken of, het verbinden van allerlei huishoudelijke apparatuur met internet. Dit biedt tal van nieuwe functionaliteit, zoals bestanden van thuis kunnen raadplegen, verlichting instellen of de thermostaat bedienen.

One network to rule them all..

Er is natuurlijk veel te zeggen om allerlei huishoudelijke apparatuur met internet te verbinden. Steeds meer huishoudelijke apparaten kunnen bedient worden middels bijvoorbeeld een smart phone. Via internet kan bijvoorbeeld thuis een kijkje genomen worden via een webcam die met internet is verbonden, of kan de temperatuur thuis ingesteld worden en dat alles via één netwerk. Dit zijn bijvoorbeeld handige zaken voor mensen die ver van huis zijn. Deze ontwikkeling heeft feitelijk betrekking op alle apparaten is huis zoals tv’s, geluidsinstallaties, computers en printers. Alles is “internet connected”. Een van de handige aspecten hiervan is dat hetzelfde netwerk (internet / thuisnetwerk) voor allerlei toepassingen gebruikt wordt. Het “computer netwerk” is eindelijk universeel toepasbaar.

Geen keuze

Natuurlijk zijn er mensen die dit geweldig vinden en er geld voor over hebben om aan deze trend mee te doen. Maar inmiddels zijn het mogelijkheden die gewoon aanwezig zijn – of je er nu voor betaald of niet. Als je een nieuw apparaat koopt zit het er gewoon in. Feitelijk hebben consumenten geen keuze meer en het gevolg is dat IoT niet meer te stuiten is, het gaat er gewoon komen als het er al niet is.

Updates

Met de grote hoeveelheid apparaten in huis die verbonden zijn met internet komt de verantwoordelijkheid deze regelmatig van updates te voorzien. Voor mensen die werkzaam zijn binnen de ICT is dit een redelijk normale gang van zaken, maar ik zie mijn tante haar ADSL router nog niet updaten laat staan haar tv of koelkast. Het gevolg is dat deze devices verouderde software hebben met tal van (inmiddels bekende) exploits (achterdeurtjes). Ook al zou je alle devices regelmatig van updates voorzien (zoals ik dat zelf doe), dan is nog steeds de vraag of fabrikanten wel tijdig updates beschikbaar stellen. Deze updates worden veelal zonder kosten ter beschikking gesteld, dus wie garandeert mij dat de betreffende fabrikant daar überhaupt nog energie in wil steken? Verwacht mag dus worden dat consumenten thuis legio apparaten hebben die wagenwijd open staan voor een ieder die er maar misbruik van wil maken.

Geheime diensten

Nou en die zijn er. Voor met name geheime diensten is dit natuurlijk geweldig. Moest je vroeger iemand schaduwen, of gericht afluisteren, dat is nu niet meer nodig. Het is zelfs niet meer nodig afluisterapparatuur te hebben. Mensen dragen vrijwillig allerlei apparaten mee die voorzien zijn van microfoons, camera’s, temperatuursensors, bewegingssensors en GPS. Bovendien zijn die apparaten voorzien van verouderde software met de nodigde exploits. Je hoeft ze alleen maar te gebruiken… Wauw, that’s a dream come true..

 Feiten

Lezers van mijn blog en artikelen weten dat ik vaak overs security schrijf, maar willen misschien ook weten of ik e.e.a. kan staven met feiten? Daarom een klein voorbeeld.

De site die u nu leest draait op een server waarop ik de nodige security maatregelen neem. Logisch, als je over security schrijft dan ben je vanzelf een keer aan de beurt, ik maak me daar geen illusies over. Zo laat ik een script iedere dag logfiles doorlopen op zoek naar inlog pogingen die niet geslaagd zijn. Dat is best interessant. Soms zie ik IP adressen veelvuldig langs komen. Het lijkt dan wel of er gericht ingebroken wordt. Bijvoorbeeld:

Dec 17 10:52:40 luna sshd[13598]: Did not receive identification string from xx.xxx.xxx.xx
Dec 17 10:58:20 luna sshd[13783]: Bad protocol version identification 'root' from xx.xxx.xx.xx port 60991
Dec 17 11:01:33 luna sshd[13799]: Did not receive identification string from xx.xxx.xx.xx
Dec 17 11:12:56 luna sshd[13852]: Did not receive identification string from xx.xxx.xx.xxx

De bovenstaande output (geanonimiseerd) is een deel van het log dat ik laat genereren. Soms doe ik een poortscan om uit te vinden wie deze inlogpogingen onderneemt. Dit brengt me op de vreemdste plaatsten. Eens kwam ik eens op een campus server van een Chinese universiteit, maar meestal betreft het ADSL routers in Rusland. Ik heb niet het idee dat de eigenaren van deze apparaten achter deze inlogpogingen zitten, maar wel heb ik het idee dat deze apparaten gekaapt zijn en door iemand anders misbruikt worden. Onderstaand is (geanonimiseerde) een portscan te zien. Bijvoorbeeld:

 

root@luna:/var/log# nmap -A -T4 xxx.xxx.xxx.xxx

Starting Nmap 6.40 ( http://nmap.org ) at 2014-12-17 11:00 CET
Nmap scan report for xx.xxx.xxx.xxx.adsl.xs4all.nl (xx.xxx.xxx.xxx)
Host is up (0.059s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
21/tcp open ftp ProFTPD
8080/tcp open http Apache httpd
|_http-methods: No Allow or Public header in OPTIONS response (status code 501)
|_http-open-proxy: Proxy might be redirecting requests
| http-robots.txt: 2 disallowed entries 
|_/cgi-bin/ /*.html$
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
8089/tcp open http-proxy sslstrip
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: storage-misc|general purpose|specialized|WAP|media device
Running (JUST GUESSING): HP embedded (91%), Linux 2.6.X|3.X (88%), Crestron 2-Series (85%), Netgear embedded (85%), Western Digital embedded (85%)
OS CPE: cpe:/h:hp:p2000_g3 cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3 cpe:/o:crestron:2_series cpe:/h:netgear:dg834g cpe:/o:westerndigital:wd_tv
Aggressive OS guesses: HP P2000 G3 NAS device (91%), Linux 2.6.32 - 3.9 (88%), Linux 3.0 - 3.9 (88%), Linux 3.6 (87%), Linux 2.6.32 - 2.6.39 (86%), Linux 2.6.38 (86%), Crestron XPanel control system (85%), Netgear DG834G WAP or Western Digital WD TV media player (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 3 hops

TRACEROUTE (using port 21/tcp)
HOP RTT ADDRESS
1 2.85 ms xxx.xxx.xxx.xxx
2 21.15 ms xxx.xxx.xxx.xxx.xs4all.net (xxx.xxx.xxx.xxx)
3 56.19 ms axx.xxx.xxx.xxx.adsl.xs4all.nl (xxx.xxx.xxx.xxx)

In dit geval is te zien dat het een klant van mijn eigen provider is. Er staat een webpoort open (poort 8080). Als dit adres in een browser ingevuld (met toevoeging van poort 8080) levert een inlogpagina op een Qnap device bij iemand thuis naar ik aanneem. Vermoed kan worden dat de inlogpogingen bij deze Qnap vandaan komen*.

*Dat is natuurlijk niet zeker, het ADSL router kan ook nog een ander apparaat port-forwarden dat de daadwerkelijk aanval uitvoert. In dat geval voert alleen poort 8080 naar de Qnap.

Interessant is te zien dat het inderdaad gewone apparaten zijn die deze aanvallen uitvoeren. Hier stopt voor mij het onderzoek, ik doe geen pogingen op de betreffende Qnap in te loggen. Naast Qnap kwam ik ook al pagina’s van bedienbare verlichting tegen en ADSl routers.

Disaster of Things

Het bovenstaande voorbeeld toont naar mijn idee aan dat IoT al bestaat en dat het inderdaad apparaten betreft die verouderde software hebben. Nu weet ik niet hoeveel mensen wel de software up to date houden, maar ik vermoed dat naar mate we meer apparaten in huis krijgen die “internet connected” zijn, dat het steeds lastiger wordt om ze up to date te houden – ervan uitgaande dat fabrikanten hun software al van updates voorzien. Verwacht mag worden dat dit een onhoudbare situatie is. We worden nu en in de toekomst omgeven van apparaten die niet veilig zijn en die oren en ogen hebben. Succes! The Disaster of Things is realiteit geworden.

update 21 januari 2015:

Mark Shuttleworth (Canonical) doet een interessante aankondiging in dit kader..

 

Gepubliceerd op 17 december 2014

Indien u mijn artikels leest of mijn Twitter tweets volgt, dan is u duidelijk dat (ICT) security mijn interesse heeft. Dat is overigens al jaren het geval. Jaren geleden beheerde ik een bedrijfsnetwerk met een 6 tal (Linux) firewalls met 8 fysieke netwerkinterfaces ieder, en met talloze subnetten en tientallen VPN verbindingen elk. Toen was ik er verantwoordelijk voor.

Inmiddels doe ik geen technisch inhoudelijk werk en komt IPTABLES alleen nog aan bod in de (Linux) training die ik geef. De interesse voor met name netwerk-security is gebleven en dan vooral het idee dat iemand op afstand een machine van je “over neemt” en daar informatie af kan halen of voor diens eigen doelen kan inzetten.

“Van mij en alleen van mij”

Op mijn eigen machines (webservers, latptops en desktops) neem ik dan ook uitgebreide maatregelen om misbruik te voorkomen. Zo maak ik gebruik van IPTABLES firewall, inloggen met SSH keys only, Fail2ban, scripts die logfiles “doorspitten” etc. Ik maak me geen enkele illusie, mijn maatregelen zijn niet voldoende. Mijn punt is, dat ik alle maatregelen tref die ik (in alle redelijkheid en binnen mijn kennis) kan treffen.

“Van jou of van mij?”

De maatregelen die ik tref maken me natuurlijk nieuwsgierig naar hoe anderen dit doen. Als ik met collega-vakbroeders praat die verstand hebben van beveiliging dan stel ik ze altijd dezelfde vraag. “Hoe weet je zeker dan jouw systeem echt van jouw alleen is?” Steevast krijg ik hetzelfde onbevredigende antwoord, “dat weet je niet”. Soms voegt men daar nog aan toe dat het meest verstandige wat je kan doe is de netwerkkabel los te trekken. Hoewel dat een machine volstrekt nutteloos maakt, kan zelfs deze maatregel in twijfel worden getrokken. Zo verscheen er een paar maanden geleden een artikel over een security specialist die meent malware (BadBIOS) te hebben gevonden dat een “air gap” kon overbruggen omdat het geluid gebruikte om te communiceren.

Deze zaken blijven knagen bij me.

 Edward Snowden

Het afgelopen jaar zijn we “verrast” door de onthullingen van Edward Snowden. Deze waren voor mij dan ook buitengewoon interessant. Van alle akelige dingen die ik me eerder kon voorstellen is inmiddels aangeven dat die ook daadwerkelijk plaats vinden. Bij elke onthulling dacht ik dan ook, “het verbaast me eigenlijk niets”. Ik zou er bijna cynisch van worden, maar ik sta nu op het standpunt, dat je dus inderdaad van het ergste uit moet gaan. Niet alleen criminelen proberen rottigheid uit te halen, maar onze eigen overheid en “bevriende” overheden ook.

Koude drukte

Zoals eerder gesteld, de onthullingen hebben me dus niet echt verbaast, maar hebben mijn ergste vermoedens bevestigd. Maar wat mij wel bevreemd is de gelatenheid van mijn ICT collega’s. Zo wordt netwerk apparatuur uit USA voorzien van standaard hardware waarmee de NSA zich toegang kan verschaffen. Als netwerkspecialist zou mij dat mateloos irriteren. Als ik verantwoordelijk ben voor een netwerk (van mijzelf of van een betalende klant), dan zou ik zeker willen weten dat de NSA – of wie dan ook – daar niet binnen kan komen. Ik zou alle maatregelen treffen die ik binnen redelijke grenzen kan realiseren. Ik bemerk echter een gelatenheid bij mijn collega’s. Ze reageren vaak met, “Tja wat kan je eraan doen?”, of “Ik heb toch niets te verbergen”.

Wake up call

Naar mijn idee kan – en moet – je er juist heel veel aan doen. Neem alle maatregelen die je kan treffen, ga altijd van het slechtste scenario uit (zie Snowden) en gebruik zoveel mogelijk Open Source Software. Natuurlijk zit ook in deze software fouten en exploits, maar het is de beste garantie dat fouten gevonden, en snel gefixed worden. Wees achterdochtig en controleer zaken, gaat het zoals ik verwacht of zie ik bijvoorbeeld netwerk verkeer dat ik niet kan verklaren? Maar bovenal, leg je er niet bij neer. Een “Big Brother” maatschappij laat je zelf gebeuren of niet..