Hey iedereen, voor school heb ik een artikel moeten schrijven in het thema "Security, Safety & Privacy". Dit is het eindresultaat en zou het graag door jullie laten lezen. Opmerkingen over het stuk hoor ik graag en in punten die ik heb gemist ben ik ook geïnteresseerd.
Hier het artikel:

Beveilingen van Servers
1. Aanleiding
Naar aanleiding van het vak SOTA (State of the Art), met als thema “Security, Safety & Privacy”, schrijf ik dit artikel als afsluitende opdracht. Het onderwerp heb ik gekozen aan de hand van persoonlijke ervaringen tijdens het opzetten en onderhouden van servers. Tijdens mijn studie heb ik vooral veel aandacht besteed aan het ontwikkelen van verschillende soorten applicaties en het efficiënt opstellen van code waarbij mijn focus uit is gegaan naar webapplicaties. Omdat het naast het juist ontwikkelen van applicaties ook van belang is dat deze vervolgens in een veilige en stabiele omgeving kunnen draaien ben ik mij ook gaan oriënteren in het opzetten en beheren van webservers. Na het opgezet van een aantal test servers en deze te hebben laten draaien voor een aantal dagen viel het mij op dat er dagelijks honderden pogingen werden gedaan om deze servers binnen te dringen. Om meer te weten te komen over het beveiligen van servers heb ik daarom een klein onderzoek gedaan naar hoe misbruik of poging tot misbruik van servers vermindert kan worden en mogelijk zelfs helemaal kan worden gestopt, dit artikel is daarvan het eindresultaat.

2. Belang
Omdat er de laatste tijd veel belangstelling is voor privacy en security op het internet is het extra belangrijk dat de juiste stappen worden genomen om hier dan ook goed mee om te gaan. Een kleine fout kan al grote gevolgen hebben, vooral in een tijd dat veel mensen gebruik gaan maken van cloud services, onder andere om privacy gevoelige informatie op te slaan. Er zijn tegenwoordig veel verschillende type aanvallen en kwetsbaarheden waaraan gedacht moet worden dat er vaak over een aantal problemen wordt heen gekeken die dan pas worden opgemerkt als het te laat is. Om dit risico te verkleinen worden een aantal belangrijke problemen hier beschreven samen met mogelijke oplossingen.

3. Centrale vraag
Bij het opzetten en onderhouden van een server, welke verbonden is of gaat worden met het internet, op welke kwetsbaarheden en mogelijke aanvallen is het verstandig te anticiperen en wat voor oplossingen zijn er om dit succesvol gedaan te krijgen om diefstal of andere vorm van misbruik van persoonlijke data te voorkomen?

4. Middenstuk
Er is tegenwoordig veel aandacht voor en nieuws over het beschermen van privacy gevoelige informatie en hoe deze van servers kunnen worden gestolen of hoe deze servers kunnen wordt aangevallen. Denk hierbij aan de Heartbleed bug in OpenSSL waardoor het mogelijk was beschikking te krijgen over gevoelige informatie van servers zoals gebruikers gegevens of privé sleutels en sessie gegevens [1]. Maar ook de vele “Denial of Service” (DoS) aanvallen die er de afgelopen tijd zijn gedaan op allerlei verschillende soorten servers om deze onbruikbaar te maken of zelfs te vernielen waardoor informatie verloren of niet meer te bereiken was [2]. Daarnaast wordt er continue vanuit overal in de wereld geprobeerd om op servers binnen te dringen door het kraken van wachtwoorden door middel van brute force aanvallen of rainbow tables met als mogelijk doel de server vervolgens in te zetten in DDoS aanvallen.

4.1 Authenticatie
Veel van de aanvallen op een server kunnen al geweerd of sterk beperkt worden door goed met gebruikers om te gaan. Zo is het onverstandig om geen normale gebruikers aan te maken naast het “root” account van de server [3], met dit account kan een hacker namelijk alle controle krijgen zodra hij eenmaal de server binnen is gedrongen. Beter is het om het onmogelijk te maken om de server direct te bereiken via het “root” account, hierdoor zullen hackers sowieso naast het wachtwoord ook de juiste gebruiker moeten achterhalen voor er toegang gekregen kan worden tot het systeem. Hoewel het gebruiken van aparte gebruikers geen perfecte oplossing is een server te beveiligen maak het voor hackers toch weer een stapje lastiger om toegang tot het systeem te krijgen. Als de server alleen maar wordt gebruikt door een vaste groep mensen kan de toegangsbeveiliging nog op een andere manier worden gedaan waardoor het brute force kraken van wachtwoorden ook niet meer mogelijk is. Dit kan door gebruik te maken van publieke en privé sleutel paren [3, 4], voor elke gebruiker die toegang moet hebben tot de server wordt er op hun eigen computer een sleutel paar aangemaakt en vervolgens wordt de publieke sleutel opgeslagen op de server zodat deze kan verifiëren of een gebruiker toegang heeft. Hierna kan de mogelijkheid om inloggen met een wachtwoord worden uitgeschakeld. Zorgen dat de bestanden op de server de juiste rechten hebben is ook belangrijk, zo kan de impact van een gehackt account worden beperkt doordat de hacker vervolgens alleen bij de gegevens van de gehackte gebruiker kan komen.

Naast aparte gebruikers aan te maken op het systeem is het ook verstandig om voor elke service die op de server draait aparte authenticatie gegevens te hebben waar dit mogelijk is. Mocht een hacker het systeem binnenkomen zorgt dit er nog voor dat hij niet alle gegevens kan inzien, denk bijvoorbeeld aan databases die mogelijk gevoelige informatie bevatten over klanten. Waarschijnlijk kunnen een aantal login gegevens wel door de hacker gevonden worden in bestanden van de gehackte gebruiker maar als de rechten van deze gebruiker goed zijn ingesteld zal de hacker mogelijk niet alles in handen kunnen krijgen.

4.2 Security Services & Software
Firewalls kunnen worden gebruikt als toevoeging op het authenticatie proces om toegang vanaf onbekende locaties te blokkeren. Dit kan natuurlijk alleen gebruikt worden wanneer de server altijd vanaf van te vore bepaalde IP adressen wordt benaderd en kan daarom voor de gebruikers ook lastigheden creëren. Wel is het handig om poorten die sowieso niet gebruikt worden met een firewall dicht te zetten of juist alleen toegang te geven tot poorten die wel gebruikt worden [3, 4]. Natuurlijk is het verstandig de poorten die wel gebruikt worden als nog door een firewall te laten scannen zodat er alsnog word gecontroleerd dat er geen schadelijke data naar binnen komt. Dit geld ook voor de poorten die worden gebruikt voor uitgaande data want deze kunnen door hackers ook worden gebruikt om alsnog toegang te krijgen tot het systeem.

Naast het blokkeren van poorten die niet worden gebruikt kunnen meer kwetsbaarheden van de server worden gehaald door alleen software te draaien die daadwerkelijk gebruikt gaat worden [3]. Deze software kan dan ook niet misbruikt worden en hoeft ook niet up-to-date gehouden te worden wat extra onderhoud werk vermindert. De services/software pakketten die wel gebruikt worden zouden altijd up-to-date gehouden moeten worden omdat hackers veel gebruik maken van exploits in oudere software versies [5]. Er zijn namelijk een aantal programma’s die deze exploits gemakkelijk en overzichtelijk aanbieden aan de hacker die er dan direct gebruik van kan maken, hierdoor kost het een hacker nauwelijks moeite om van exploits gebruik te maken. Helaas kan het natuurlijk ook gebeuren dat er exploits in huidige versies gevonden kunnen worden [6], dit was bijvoorbeeld het geval bij de Heartbleed bug waardoor er van allerlei persoonlijke of privacy gevoelige gegevens konden worden gestolen van servers [1]. Deze exploits kunnen haast niet vermeden worden en de software moet dus zo snel mogelijk na het uitkomen van een patch worden geüpdatet. Om er voor te zorgen dat er minder risico’s zijn wanneer er een exploit wordt ontdekt is het daarom altijd verstandig om meerdere lagen van beveiligen te hebben ingesteld.

“Intrusion detection systems” (IDS) kunnen nog extra worden gebruikt om verdachte activiteiten te signaleren en vervolgens de server administrator hier van op de hoogte te brengen [7]. Er zijn veel verschillende soorten IDS’s beschikbaar, zowel voor buiten als op de server. Deze services monitoren zowel de packets die het systeem binnen komen als de packets die naar buiten worden gestuurd, aan de hand van deze analyses kan er worden bepaald wanneer er een dreiging is. Deze services kijken ook naar de data die zich in een packet bevind in tegenstelling tot een firewall die vooral kijkt naar de headers en protocollen. Ook houdt een host-based IDS (een IDS die op de server zelf draait) veranderingen binnen bestanden op de server bij en controleert zo of er geen systeem bestanden zijn aangepast. Een stap verder is een “intrusion prevention system” (IPS), dit soort services doen eigenlijk het zelfde als een IDS alleen weigeren deze het hele packet wanneer er een dreiging wordt gedetecteerd binnen in- of uitgaande data [7]. Combinaties van deze twee services bestaan ook waardoor dus wordt gewaarschuwd als er verdachte activiteiten worden gesignaleerd en waar nodig ook blokkades worden opgelegd [8].

4.3 Denial of Service
Tegenwoordig worden er ook veel DoS aanvallen gedaan op servers, aanvallen waarbij enorm veel aanvragen tegelijk naar een server worden gestuurd (Distributed DoS) of waar aanvallen waardoor de hardware of werking van de server wordt aangetast (Permanent DoS) [2, 9]. Voor het voorkomen van PDoS aanvallen is het van belang dat een hacker geen toegang kan krijgen tot het systeem zodat hij door het draaien van schadelijk programma’s of het overschrijven van systeem functies de hardware en de werking van de server niet kan aantasten. Tegen DDoS aanvallen valt met één server helaas weinig te doen en de server die aangevallen wordt zal dan ook niet meer bereikbaar zijn omdat hij te weinig middelen tot zijn beschikking heeft om op alle aanvragen te reageren. Wel is het mogelijk om meerdere servers in te zetten om een DDoS aanval op te vangen en vervolgens op deze servers de inkomende aanvragen te filteren zodat de kwaad willende aanvragen niet eens de verwerkende server zullen bereiken. Dit soort opvang netwerken zijn vooral effectief als het een wereldwijd netwerk betreft. Er zijn enkele externe partijen die deze dienst aanbieden die dit soort servers al hebben draaien [10]. Om een persoonlijk opvang netwerk op te zetten tegen DDoS aanvallen is af te raden omdat dit enorm veel onderhoud met zich meebrengt en waarschijnlijk relatief weinig zal worden gebruikt.

4.4 Zelf geschreven software
Uiteindelijk is de kans groot dat er op de server webapplicaties of andere zelf ontwikkelde programma’s gaan draaien die beschikbaar zullen zijn voor het hele internet. Hoe goed de server ook beveiligd kan zijn maakt weinig uit als er fouten voorkomen in deze applicaties. Ook bij deze applicaties is het dus van belang om altijd na te gaan of de gebruikte middelen geen security updates hebben uitgebracht. Daarnaast is het belangrijk om de applicaties grondig te testen voor het uitrollen naar een server. Enkele belangrijke kwetsbaarheden waar op getest zal moeten worden kunnen in de OWASP top 10 worden gevonden [11], dit zijn op het moment:
1. Injectie: onveilige data uit parameters wordt gebruikt in bijvoorbeeld SQL queries.
2. Authenticatie en sessie management: sessies worden niet goed afgesloten.
3. Cross-Site Scripting (XSS): onveilige data wordt gebruikt in bijvoorbeeld HTML.
4. Onveilige directe object verwijzing: objecten kunnen worden bereikt via parameters zonder check.
5. Incorrecte security configuratie: de instellingen zijn niet correct ingevuld.
6. Bloot geven van gevoelige informatie: er is geen encryptie gebruikt voor de communicatie.
7. Missen van functie level toegangscontrole: functies kunnen worden aangeroepen door gebruikers.
8. Cross-Site Request Forgery (CSRF): andere websites kunnen formulieren versturen naar de website.
9. Kwetsbare componenten gebruiken: externe code wordt gebruikt met security issues.
10. Ongecontroleerd doorsturen: bezoekers kunnen doorgestuurd worden via parameters zonder check.

Veel van deze kwetsbaarheden kunnen al worden opgelost door de data waar de gebruikers controle over hebben altijd te verifiëren of om te zetten naar veilige tekens. Ook wanneer er data wordt weergegeven welke afkomstig is van een gebruiker zullen de tekens omgezet moeten worden zodat deze veilig getoond kunnen worden zonder dat er daarbij geïnjecteerde code wordt uitgevoerd. De meeste programmeertalen hebben hier hun eigen functies voor om dit te doen. Er zal daarnaast altijd gecontroleerd moeten worden of de huidige gebruiker wel het recht heeft om bepaalde locaties, functies of objecten te benaderen en of formulieren wel echt door de gebruiker zelf zijn verzonden. Om het afluisteren van verzonden data tegen te kan zal er gebruik gemaakt moeten worden van versleuteling.

5. Conclusie
Er komt dus een hoop kijken bij het opzetten en onderhouden van een server waar toegang tot gekregen kan worden via het internet. Basis aanvallen zoals brute force of rainbow table aanvallen zullen altijd wel eens worden uitgevoerd op de server, hier moet dus rekening mee worden gehouden. Daarnaast zullen alle security mogelijkheden die de gebruikte software zelf beschikbaar stelt gebruikt moeten worden. Het opzetten en instellen van meerdere lagen beveiliging is namelijk van groot belang om de server veilig te houden omdat er meestal wel ergens exploits voor worden gevonden. Meerdere accounts aanmaken, één voor elke systeem gebruiker, zodat niet direct alle data bereikt kan worden bij het verkrijgen van toegang door een hacker op één van deze accounts maakt al veel uit. Dit geld ook voor andere software waar accounts bij van toepassing zijn zoals databases.

Exploits zullen zich blijven voor doen dus het up-to-date houden van de software die wordt gebruikt is belangrijk om hier geen slachtoffer van te worden. Andere software die niet gebruikt wordt maar wel op het systeem staat kan dus ook beter worden verwijderd zodat er hier geen extra inspanning voor nodig is om het te onderhouden en er geen misbruik van kan worden gemaakt. Om het risico van exploits te verminderen kunnen wel services gebruikt worden die al het verkeer dat de server binnenkomt of uitgaat extra controleert zoals firewalls, IDS’en en IPS’en.

Omdat sommige beveiligingsmethoden prijzig kunnen worden wanneer dit eigenhandig wordt opgezet, zoals een DoS opvang systeem, kan er gebruik gemaakt worden van externe diensten die hier in gespecialiseerd zijn. Deze oplossingen zijn over het algemeen niet nodig maar kunnen onder bepaalde omstandigheden wel van pas komen.

Met zelf geschreven software moet altijd worden opgelet dat deze zelf geen security issues naar de server brengen. Een goed beveiligde server is dus als nog kwetsbaar door code die er op wordt uitgerold. Het is verstandig om hiervoor bijvoorbeeld de OWASP top 10 te nemen en in ieder geval te controleren op deze veel misbruikte kwetsbaarheden.

6. Discussiepunten
Er is besproken wat voor type software en diensten er gebruikt kunnen worden bij het beveiligen van een server. De verschillende beschikbare oplossingen hiervoor zullen dus nog tegen elkaar afgewogen moeten worden. Dit kan nog een grote impact hebben op de veiligheid van het systeem afhankelijk van hoe de applicaties werken. Daarnaast zullen niet alle ontwikkelaars even snel een patch voor een security issue kunnen ontwikkelen om exploits tegen te gaan.

Waarschijnlijk zijn niet alle kwetsbaarheden in dit artikel opgenomen of komen er in de loop van de tijd nog extra kwetsbaarheden bij. Daarom is het verstandig om ook zelf na te gaan waar de server die beveiligd moet worden aan zal moeten voldoen. Daarnaast kan er niet worden uitgegaan van een compleet veilig systeem als software die op de server gepubliceerd is aan de OWASP top 10 voldoet. Dit zijn namelijk niet alle kwetsbaarheden die binnen applicaties te vinden zijn, het verder veilig ontwikkelen van software valt ook niet binnen de scope van dit artikel.

Naast het digitaal beveiligen van een server is het ook van belang dat de server fysiek goed beveiligd is. Dit valt niet binnen de scope van dit artikel maar is wel een belangrijk punt om rekening mee te houden. Met fysieke toegang tot de server maakt een groot deel van de digitale beveiliging niet meer uit.

7. Bronnen
[1] http://heartbleed.com/
[2] http://www.cloudflare.com/ddos
[3] http://www.cyberciti.biz/tips/linux-security.html
[4] https://library.linode.com/securing-your-server
[5] http://hal.inria.fr/docs/00/44/13/60/PDF/loriant.prdc05.pdf
[6] http://www.hackersonlineclub.com/exploits
[7] http://netsecurity.about.com/cs/hackertools/a/aa030504.htm
[8] http://www.snort.org/snort
[9] http://www.darkreading.com/permanent-denial-of-service-attack-sabotages-hardware/d/d-id/1129499
[10] http://www.blacklotus.net/protect/protection-for-networks/
[11] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project