Zoals je in het artikel over DNSSEC van vorige week kon lezen, werken we hard aan verbeteringen die bijdragen aan veiligheid. Op het internet speelt beveiliging immers een steeds grotere rol en mag daardoor zeker niet onderschat worden. Denk bijvoorbeeld aan beveiligingslekken die toenemen, aanvallen die vaker plaatsvinden en misbruik dat blijft stijgen. Uiteraard doe je er zelf alles aan om je website zo goed mogelijk te beveiligen. Maar wat als iemand anders, al dan niet bewust, de zaak om zeep dreigt te helpen? Je wilt natuurlijk niet dat een lek in de website van je ‘virtuele buurman’ een beveiligingsrisico voor jouw website vormt.
Om te begrijpen wat de gevaren zijn die je bij webhosting tegenkomt, en wat we daartegen kunnen doen, zullen we eerst een stukje de geschiedenis in moeten gaan. Mocht geschiedenis je niet zoveel interesseren, dan heb je geluk. Ik heb er een apart ‘hoofdstuk’ van gemaakt, zodat je eventueel kunt overslaan.
De geschiedenis van hosting
Lang, lang geleden (in internet-tijd) was het zo, dat als je iets op het internet wilde laten zien je een eigen server moest hebben. Uiteraard een fysieke, want van virtualisatie hadden we nog niet gehoord. Dit was natuurlijk veilig, want je had een hele server voor je alleen. Het was echter erg moeilijk en duur. Toen kwamen er mensen en die zagen een gat in de markt. Zij kochten servers en richtten die in. Er werden meerdere websites op deze servers gezet, waardoor de kosten per website naar beneden gingen. Anderen konden daar dus gebruik van maken, zonder dat het erg moeilijk en duur was. Dit was het begin van shared webhosting.
Qua veiligheid was er toen nog niet zo’n groot probleem, want veel websites bestonden uit statische HTML. Daarnaast werd er weinig actief geprobeerd om websites binnen te dringen om wat voor reden dan ook. In de jaren die hierop volgden, werd het internet groter en groter. De kracht en potentie van het internet nam enorm toe en daardoor werden websites steeds meer een interessant doelwit. Langzaamaan zagen dynamische websites het licht, met behulp van bijvoorbeeld PHP. Door de extra functionaliteit, steeg de populairiteit enorm. Echter, kwam het de veiligheid zeker niet ten goede.
Veiligheid van shared webhosting
Shared hosting groeit dus enorm, maar wordt ook onveiliger. Stap voor stap wordt gekeken naar oplossingen. Dit beveiligen gebeurt op verschillende niveau’s. In dit voorbeeld ga ik ervan uit, dat een website met behulp van PHP is geschreven.
- Beveiligen van de webserver: als een aanvaller gemakkelijk ‘root’ kan krijgen op de server, dan maakt het natuurlijk verder niet uit hoeveel moeite je doet. Om deze reden is het belangrijk dat je zo weinig mogelijk services draait die vanaf buiten bereikbaar zijn. Wat er draait moet zodoende goed worden bijgehouden qua security-updates.
- Beveiligen van PHP zelf: in 2002 kwam bijvoorbeeld PHP 4.2 uit, waarin register_globals default is uitgezet.
- Beveiligen van de PHP-scripts: niet zomaar globale variabelen gebruiken in je code, input van buiten valideren, input escapen, etc.
Vooral dit laatste is iets waar je bij shared hosting weinig invloed op hebt. Je kunt alleen je eigen code bijhouden. Gezien we nog steeds in het stukje geschiedenis zitten draait elke website onder dezelfde gebruiker. Een lek in één website op een server heeft tevens consequenties voor andere websites op deze server.
Je site ‘gehackt’, zonder dat je iets fout deed
Met een PHP-script kun je bestanden wegschrijven. Een PHP-script werd uitgevoerd door de gebruiker waaronder de webserver draaide, en dat was meestal ‘Apache’. Om deze te laten ‘schrijven’ moest je dus Apache-rechten geven om te kunnen schrijven. Meestal was het dan noodzakelijk om een map zogenaamde 777-rechten te geven. Dit betekent zoveel als: iedereen mag in deze map kijken, lezen en schrijven. Een aanvaller die via een andere site binnenkomt, kan zulke mappen vinden. Vervolgens kan hij er allerlei bestanden inzetten. Tevens had het uitvoeren van scripts onder de Apache user nog een ander probleem. Velen zullen zich herinneren dat bestanden die door Apache waren geplaatst niet via FTP konden worden aangepast en vice versa.
Evolutie: PHP onder je eigen gebruiker
Om bovengenoemd probleem te ondervangen werd PHP niet via de Apache-module mod_php uitgevoerd, maar middels CGI. Middels ‘suEXEC’ was het dan mogelijk om het script als de eigen user uit te voeren. Probleem opgelost! Helaas is deze manier vele malen langzamer, omdat voor elke pagehit PHP opnieuw moet worden gestart.
Om hier omheen te werken zijn verschillende oplossingen aangedragen, elk met eigen voor- en nadelen. Enkele voorbeelden zijn: fastcgi, fcgid, suphp, mpm-peruser, mpm-itk en mod_ruid. Deze oplossingen zijn momenteel nog steeds in gebruik. Dat betekent dat we aan het einde van deze geschiedenisles zijn gekomen. Op naar het heden!
Veilige webhosting in het heden
Ook bekend als: “Lees hier verder als je niet van geschiedenis houdt.” Hieronder gaan we dieper in op de nieuwe technologieën die worden gebruikt in ons nieuwe hostingplatform.
Nog steeds staan op één server verschillende websites. Echter, draait elke website nu onder zijn eigen user. Je zou zeggen, daarmee is het probleem van meerdere gebruikers op één server opgelost. Of toch niet? Beveiliging is niet één ding. Beveiliging moet je op zoveel mogelijk manieren doen. Het moet uiteindelijk voor de aanvaller niet de moeite waard zijn om proberen binnen te komen.
Als normale gebruiker kun je nog steeds de mogelijkheid om van alles op het systeem te zien. Welke andere gebruikers zijn er? Welke processen draaien er? Hoe zijn sommige services geconfigureerd? Enzovoorts. Ook is het mogelijk de meeste programma’s die op de server staan aan te roepen. Zou het dan niet beter zijn, als elke gebruiker zijn eigen stukje server heeft? Misschien wel.
Het opdelen van een server voor gebruikers
Om een gebruiker een eigen stukje op een server te geven, zijn er kort gezegd twee mogelijkheden.
- Eén, virtualisatie. Door het opdelen van de fysieke hardware in kleinere stukken, draai je meerdere virtuele machines op dezelfde server. Deze bootsen fysieke hardware na en hebben elk hun eigen OS. Voorbeelden zijn KVM, Xen en ESX(i).
- Twee, containerisatie. Door het opdelen van resources binnen een server kun je verschillende applicaties en gebruikers een eigen omgeving binnen het systeem geven. Voorbeelden zijn Docker, LXC, CageFS en Virtuozzo.
Virtualisatie heeft veel ‘overhead’. Binnen shared hosting wordt dit wel gebruikt, maar dan met name om op virtuele machines om meerdere gebruikers erop te zetten. Eén gebruiker per virtuele machine brengt veel te hoge kosten met zich mee om dit als aantrekkelijk concept te vermarkten. Je blijft dus met dezelfde problemen zitten als die je zonder virtualisatie hebt.
Containers hebben veel minder overhead en zijn dus beter geschikt in de shared-hostingwereld. Hiermee geef je iedere gebruiker een eigen virtueel bestandssysteem. Dit kan ook alleen door hem worden gebruikt. Zo lijkt het alsof hij de enige gebruiker is op een server. Mocht hij besluiten om bijvoorbeeld processen op te vragen die op de server draaien, dan ziet hij uitsluitend de processen die gekoppeld aan zijn eigen gebruik.
Containers bij Antagonist
Dit brengt ons bij ons eigen nieuw hostingplatform. Wij maken binnen ons platform gebruik van een gevirtualiseerd bestandssysteem. Daaromheen hebben we diverse tooling om een gebruiker op zijn eigen ‘stukje’ te houden. Simpel gezegd gebruiken wij een vorm van containerisatie die specifiek ontworpen is voor de shared-hosting-wereld. De overhead is nihil, de veiligheid wordt enorm verhoogd en er zijn ineens een heleboel unieke mogelijkheden die voor (shared) webhosting uniek zijn. Als iedereen namelijk zijn eigen bestandssysteem heeft, dan is het mogelijk om bijvoorbeeld zelf je PHP-versie te kiezen.
Eigenlijk kun je dus, dankzij de containerisatie op ons nieuwe platform en de tooling eromheen, niet meer spreken van shared webhosting. Je krijgt als het ware een container die door Antagonist wordt beheerd. Dat is sneller, veiliger en gemakkelijker. Plus dat er een heleboel nieuwe mogelijkheden ontstaan om te implementeren. Het wordt dus een soort van shared webhosting 2.0 of misschien wel managed container hosting.
Van huisgenoot naar luxe appartement
Voor webhosting heb je servers nodig. Heb je veel gebruikers, dan moet je veel servers hebben. Hieronder een voorbeeld om het verschil tussen shared webhosting en containerisatie verder te verduidelijken. Ik doe dit aan de hand van woonsituaties.
Bij shared webhosting is elke server één grote container. Hierin ‘wonen’ gebruikers als huisgenoten samen. Iedereen heeft zijn eigen kamertje, maar wel met dunne wandjes en deuren die slecht op slot kunnen. Het is prima om in te slapen en je kunt er je spullen kwijt. Wil je echter iets anders, bijvoorbeeld naar de wc of even douchen, dan moet je de gang op richting de openbare ruimtes. Ook zijn er regels die het samenleven mogelijk maken. Om dit goed te laten verlopen, worden deze nauwlettend door een conciërge in de gaten gehouden. Eén server is dus één woning, waar heel veel mensen wonen. Op zich best prima en veilig, maar het kent z’n beperkingen.
Met de komst van ons nieuwe platform is een server geen container meer. Zodoende fungeert het niet meer als één grote gezamenlijke woning. Iedere server wordt namelijk opgebouwd uit een heleboel kleinere containers. Elk van deze containers is geschikt als woonruimte voor één gebruiker. Er zijn dikke muren, goede sloten en isolatie. De woning is binnen van alle gemakken voorzien. Je hebt een eigen wc, badkamer en keuken. Met een dergelijke woning heb je dus veel meer privacy, veiligheid en vrijheid. Uiteraard zijn er nog steeds regels, maar deze zijn een stuk soepeler. Je hoeft immers geen rekening meer te houden met huisgenoten.
Klaar voor de toekomst!
We lopen graag voorop en daarom bereiden we ons stap voor stap voor op de toekomst. We willen jou immers de beste performance blijven bieden. Hoe je deze vorm van hosting ook wilt noemen, het gaat erom dat wij zorgen voor een optimale gebruikservaring en dat je klaar bent voor wat komen gaat. In de nabije toekomst kun je dus nog meer nieuwe features en updates verwachten, die allemaal dankzij ons nieuwe platform en netwerk mogelijk zijn! Benieuwd naar deze nieuwe veilige webhosting van Antagonist?
Nieuwsgierig naar meer informatie over ons nieuwe platform en hoe we dit technisch voor elkaar boksen? Lees dan verder over container hosting in het artikel je eigen resources voor meer performance en veiligheid! Veel plezier!
P.S. Wil je op de hoogte blijven van alle artikelen, updates, tips en trucs die verschijnen op ons blog? Dat kan! Rechts bovenin via RSS, e-mail, het liken op Facebook, het +1’en op Google+ of het volgen op Twitter.