Bekijk Volledige Versie : Hoe veilig is shared hosting?
christian2
27/04/08, 14:45
Ik ben momenteel een PHP/Flash CMS aan het bouwen en probeer uiteraard alle mogelijke beveiligingmaatregelen in te bouwen. Echter deze applicaite zal vooral ook door mensen gebruikt worden die gebruik maken van shared hosting accounts (zowel op Windows/IIS en Linux/Apache).
Tot dusver ging ik ervan uit dat verschillende shared hosting klanten op één server(/farm) geen toegang zouden kunnen hebben tot elkaars scripts/bestanden. Echter na het lezen van enkele boeken m.b.t. PHP security lijkt het dat deze aanname niet terrecht is, er wordt namelijk opgemerkt dat dit een nadeel is van shared hosting, dus dat men die toegang tot elkaars bestanden weldegelijk heeft. Nu kan ik weliswaar met de open_basdir ini instelling de toegang regelen, echter dat werk alleen maar binnen PHP, via andere wegen is de toegang dan nog steeds open.
Vraag 1: hoe zit het nu? ... is shared hosting inderdaad een security risk omdat aanbieders van shared hosting hier niets tegen kunnen of willen doen?
Vraag 2: Als een shared hosting provider weldegelijk de boel kan dicht timmeren is er dan een (nette/legale) manier om vanuit PHP te testen of de host provider de juiste maatregelen heeft genomen of dat de achterdeur open staat?
Bedankt alvast voor jullie input :)
Zorg in ieder geval dat je scripts werken met safe_mode aan (schijnbeveiliging imo, maar goed) en met de open_basedir restrictie aan. Dit zijn de twee dingen die iedere provider toch wel een beetje toepast.
Daarom codeer ik altijd een deel van de klantengegevens (naam, adres, etc) in de database als ik een webshop oid oplever .. Kost iets meer performance maar als door jou fout een heel klantenbestand op de straat ligt ben je nog verder van huis!
En de sleutel waarmee je dat codeert, waar bewaar je die?
Uhm, een goede hoster heeft zijn beveiliging op orde en daar kan je elkaars bestanden niet lezen :)
christian2
27/04/08, 17:25
Uhm, een goede hoster heeft zijn beveiliging op orde en daar kan je elkaars bestanden niet lezen :)
Dat is dus wat ik ook zou verwachten, maar goed volgens een aantal boeken is dat zelden het geval, vandaar dat ik graag wil weten hoe ik (via PHP code) kan testen of alles goed op slot zit zonder hack pogingen te moeten ondernemen.
Maar daarom is het misschien handig om te snappen waarom shared hosting potentieel gevaarlijk is. Dit is wat ik tot dusver begrepen heb:
De shared webserver draait meestal onder het account 'nobody' en niet onder het account van de eigenaar van het hostingaccount. PHP scripts worden uitgevoerd onder de privellege's van 'nobody' en aangezien die privelleges gelden voor ALLE hosting accounts hebben we dus een onveilgie situatie waarin een script van de ene hosting klant bedoeld of onbedoeld kan rommelen met de bestanden van andere hosting klanten.
Dan heeft het niet veel doel zoals RedoX adviseert om zaken te coderen, daar de decodeer sleutel ergens beschikbaar moet zijn voor het decodeer script en daarmee ook voor 'nobody' en dus eigenlijk 'local_everybody' ;-)
Wido (of wie dan ook) weet jij hoe een goede hoster een en ander zo afschermt dat willekeurig welke tool/technologie eventueel gebruikt wordt, bijvoorbeeld PHP/Perl/Shell commands/..., de webserver user (nobody) geen toegang zal hebben buiten de grenzen van een bepaald host account?
@Randy: open_basedir heeft toch alleen effect op PHP, dus dan kan een onverlaat nog steeds met bijvoorbeeld een Perl script ongewenste intimiteiten ontplooien?
Open_basedir heeft inderdaad alleen invloed op PHP. Door PHP te draaien als CGI- of FastCGI-applicatie wordt het mogelijk om suexec te gebruiken. Met suexec (http://httpd.apache.org/docs/2.2/mod/mod_suexec.html) kunnen applicaties worden uitgevoerd onder het account van de klant. Dit geldt dan meteen voor zowel PHP als andere CGI-applicaties waaronder perl-scripts.
Dat dit door weinig hosters zo wordt gedaan, komt waarschijnlijk doordat er (relatief) veel technische kennis voor nodig is. En door zaken als safe_mode en open_basedir lijkt de beveiliging op orde, waardoor men er geen tijd en moeite in wil steken.
Komt ook omdat de controlpanels hier weinig rekening mee houden. Ze doen alsof ze het hele beheer van de server makkelijk maken maar dat is maar een deel.
Een eenvoudige check is aan de host vragen of je via FTP dezelfde gebruiker bent als via een script op de website.
Dat is dus wat ik ook zou verwachten, maar goed volgens een aantal boeken is dat zelden het geval, vandaar dat ik graag wil weten hoe ik (via PHP code) kan testen of alles goed op slot zit zonder hack pogingen te moeten ondernemen.
Maar daarom is het misschien handig om te snappen waarom shared hosting potentieel gevaarlijk is. Dit is wat ik tot dusver begrepen heb:
De shared webserver draait meestal onder het account 'nobody' en niet onder het account van de eigenaar van het hostingaccount. PHP scripts worden uitgevoerd onder de privellege's van 'nobody' en aangezien die privelleges gelden voor ALLE hosting accounts hebben we dus een onveilgie situatie waarin een script van de ene hosting klant bedoeld of onbedoeld kan rommelen met de bestanden van andere hosting klanten.
Dan heeft het niet veel doel zoals RedoX adviseert om zaken te coderen, daar de decodeer sleutel ergens beschikbaar moet zijn voor het decodeer script en daarmee ook voor 'nobody' en dus eigenlijk 'local_everybody' ;-)
Wido (of wie dan ook) weet jij hoe een goede hoster een en ander zo afschermt dat willekeurig welke tool/technologie eventueel gebruikt wordt, bijvoorbeeld PHP/Perl/Shell commands/..., de webserver user (nobody) geen toegang zal hebben buiten de grenzen van een bepaald host account?
@Randy: open_basedir heeft toch alleen effect op PHP, dus dan kan een onverlaat nog steeds met bijvoorbeeld een Perl script ongewenste intimiteiten ontplooien?Wij (naam laat ik achterwege) draaien alle VirtualHosts onder hun eigen user waardoor, wanneer jij je files netjes 600 chmod, niemand je bestanden kan uitlezen (behalve wij dan natuurlijk ;) ).
openbase_dir, safe_mode, allemaal schijnveiligheid, want zodra je met de system() en exec() functies aan de gang gaat, wandel je langs al die beveiligingen heen.
Het uitzetten van system() en exec() os ook alleen maar onhandig voor de coder, je beperkt de vrijheid daar flink mee. (Denk aan foto-albums die imagemagick aanroepen?).
Vraag 2: Als een shared hosting provider weldegelijk de boel kan dicht timmeren is er dan een (nette/legale) manier om vanuit PHP te testen of de host provider de juiste maatregelen heeft genomen of dat de achterdeur open staat?
Bedankt alvast voor jullie input :)
Het antwoord op deze vraag interesseert me. Er zijn op internet veel tools te vinden om te checken of je PC geen beveiligingsrisico's heeft. Is er geen gelijkaardig script dat je kan draaien dat wat info geeft of de beveiligingsrisico's van je site ?
Er zijn zeker wat rudimentaire tests mogelijk zodat iets gemaakt kan worden dat kan uitgevoerd worden door niet-experten.
Volgens mij zou een dergelijk tool al wat simpele aanbevelingen kunnen geven.
@1qbe
Ik heb ook al diverse malen gezocht naar een soort van standaard PHP script die de server configuratie even flink 'test' zodat je weet waar je aan toe bent als admin/gebruiker. Tot nu toe heb ik m.b.v. google nog niet kunnen vinden...
Dan heeft het niet veel doel zoals RedoX adviseert om zaken te coderen, daar de decodeer sleutel ergens beschikbaar moet zijn voor het decodeer script en daarmee ook voor 'nobody' en dus eigenlijk 'local_everybody' ;-)
Dit is meer voornamelijk om op een shared server je database data veilig te stellen. Overigens hoeft het niet eens zo te zijn dat je MySQL server direct je PHP server is. Maargoed, misschien doel ik op een andere punt dan jij. Ik doel namelijk meer op MySQL dan op PHP/FILES op de server. De kans dat iemand in je MySQL database gaat neuzen is namelijk veel groter dan dat iemand in je files komt.
christian2
28/04/08, 13:44
@RedoX, waar bewaar je dan de inloggegevens voor je mysql db. Die moeten toch ergens beschikbaar zijn voor je PHP scripts? En als dat zo is dan zijn die daardoor voor 'nobody' en dus ieder hostingaccount op de webserver beschikbaar?
TS, kijk eens op http://phpsec.org/.
christian2
28/04/08, 14:42
Na vele artikelen en discussie gelezen te hebben kom ik tot de conclusie dat, zoals reeds geopperd door Hans en Wido, de enige veilige methode is om Apache met suEXEC en PHP als fastCGI te runnen. CGI lijkt me te veel overhead met zich mee te brengen. FastCGI is dan misschien minder snel dan mod_php maar ik denk dat veiligheid toch wel heel wat belangrijker is. Dus wat mij betreft winnaar w.b. performance vs security verhouding.
Ik vindt het wel schrikbarend dat schijnbaar inderdaad de meeste providers die shared hosting aanbieden uitgaan van de goede bedoelingen van hun klanten en kiezen voor snelheid (dus mod_php) boven veiligheid. Wat me daaraan het meeste stoort is dat je dat als shared hosting klant dit meestal niet weet. Iedereen gaat er vanuit dat dit gewoon geregeld is en op de sites van de meeste aanbieders vindt je hierover geen informatie net zo min als op review sites zoals webhosters.nl. Is het dan zo onbelangrijk volgens deze mensen, ik kan daar met mijn hoofd niet bijkomen :( ... misschien als providers die het WEL goed geregeld hebben daar nu eens prominent de aandacht op zouden vestigen dan zouden mensen die op zoek zijn naar een vhost er wellicht bewust van gaan worden dat het naief is om te veronderstellen dat dit wel goed geregeld zal zijn bij een provider die bijvoorbeeld op een review site goiede reviews krijgt.
Het andere wat ik opmerkelijk vindt is dat de markt en het Apache team hiervoor nog geen veilige simpel te implementeren oplossing voor heeft gevonden. En dat het PHP team mod_php verzuimd heeft een cuEXEC compatible versie van mod_php te maken. Of is dat om een of andere technische redenen gewoon niet mogelijk??
Anyway ik weet nu voldoende denk ik om mijn CMS klanten straks goed te informeren over eisen die ze aan hun hostaccount zouden moeten stellen als ze interne hacks willen voorkomen.
Ik wil daarbij ook nog steeds een lock mechanisme inbouwen dat gebruik van de site verhinderd totdat alle potentieel onveilige instellingen etc zijn gecorrigeerd met de optie voor de eigenaar om e.e.a. te overrulen als hij van mening is dat hij de andere accounts op de server kan vertrouwen.
Hoe (m.b.t. preventie interne hacks van ander accounts)?
Ik zit te denk om te testen of een script uitgevoerd kan worden als ik alleen de user rechten toeken (en group en world dus 0). Zou dit afdoende zijn om te concluderen dat een account
voldoende is afgeschermd voor interne hacks (tenzij de provider (root) niet vertrouwd kan/mag worden)?
Is een PHP encoder (Zend/ionCube) nog een optie om interne hacks te voorkomen of zijn de betreffende loaders ook makkelijk te compomitteren door andere lokale users?
GlennMatthys
28/04/08, 14:50
Na vele artikelen en discussie gelezen te hebben kom ik tot de conclusie dat, zoals reeds geopperd door Hans en Wido, de enige veilige methode is om Apache met suEXEC en PHP als fastCGI te runnen. CGI lijkt me te veel overhead met zich mee te brengen. FastCGI is dan misschien minder snel dan mod_php maar ik denk dat veiligheid toch wel heel wat belangrijker is. Dus wat mij betreft winnaar w.b. performance vs security verhouding.
Ik vindt het wel schrikbarend dat schijnbaar inderdaad de meeste providers die shared hosting aanbieden uitgaan van de goede bedoelingen van hun klanten en kiezen voor snelheid (dus mod_php) boven veiligheid. Wat me daaraan het meeste stoort is dat je dat als shared hosting klant dit meestal niet weet. Iedereen gaat er vanuit dat dit gewoon geregeld is en op de sites van de meeste aanbieders vindt je hierover geen informatie net zo min als op review sites zoals webhosters.nl. Is het dan zo onbelangrijk volgens deze mensen, ik kan daar met mijn hoofd niet bijkomen :( ... misschien als providers die het WEL goed geregeld hebben daar nu eens prominent de aandacht op zouden vestigen dan zouden mensen die op zoek zijn naar een vhost er wellicht bewust van gaan worden dat het naief is om te veronderstellen dat dit wel goed geregeld zal zijn bij een provider die bijvoorbeeld op een review site goiede reviews krijgt.
Het andere wat ik opmerkelijk vindt is dat de markt en het Apache team hiervoor nog geen veilige simpel te implementeren oplossing voor heeft gevonden. En dat het PHP team mod_php verzuimd heeft een cuEXEC compatible versie van mod_php te maken. Of is dat om een of andere technische redenen gewoon niet mogelijk??
Anyway ik weet nu voldoende denk ik om mijn CMS klanten straks goed te informeren over eisen die ze aan hun hostaccount zouden moeten stellen als ze interne hacks willen voorkomen.
Ik wil daarbij ook nog steeds een lock mechanisme inbouwen dat gebruik van de site verhinderd totdat alle potentieel onveilige instellingen etc zijn gecorrigeerd met de optie voor de eigenaar om e.e.a. te overrulen als hij van mening is dat hij de andere accounts op de server kan vertrouwen.
Hoe (m.b.t. preventie interne hacks van ander accounts)?
Ik zit te denk om te testen of een script uitgevoerd kan worden als ik alleen de user rechten toeken (en group en world dus 0). Zou dit afdoende zijn om te concluderen dat een account
voldoende is afgeschermd voor interne hacks (tenzij de provider (root) niet vertrouwd kan/mag worden)?
Is een PHP encoder (Zend/ionCube) nog een optie om interne hacks te voorkomen of zijn de betreffende loaders ook makkelijk te compomitteren door andere lokale users?
Het probleem is wat dat je aanhaalt: performance. Aangezien marges op shared hosting belachelijk laag liggen moet er het meeste uit elke server geperst worden. Door gebruik te maken van suexec+fastcgi kan er minder uit één server gehaald worden.
suexec+fastcgi is ook niet direct de ideale oplossing, aangezien de files van de website wellicht altijd in o+rw staan, kan de webserver daar plots beginnen dingen wegschrijven aangezien de webserver onder dezelfde owner draait. Leuk voor de zoveelste halfgare php applicatie die gehackt wordt of een lek in de webserver zelf.
Voor webdesign bedrijven is het zowiezo beter om gewoon een dedicated oplossing in gebruik te nemen, daar de websites laten op te draaien en gewoon een fee ofzoiets aan de klanten vragen om hun website te laten hosten. Zo hoeven ze zelf geen FTP toegang of dergelijke, geen risico op "interne hacks".
Is een PHP encoder (Zend/ionCube) nog een optie om interne hacks te voorkomen of zijn de betreffende loaders ook makkelijk te compomitteren door andere lokale users?
Ja en nee. De Suhosin plugin beschermd weer zaken die Zend laat liggen bijvoorbeeld.
Het probleem is mijn inziens niet de performance, die is gewoon goed voor een standaard site. Het probleem is de standaard cp's. Veel hosters (no offence) weten van 'boe of bah' als het aankomt op security en de configuratie van software.
Helaas zijn er (te) veel die uitgaan van een default DA / Cpanel / Plesk installatie waarbij een hoop verbeterd zou kunnen worden. Nieuwe mensen in de hosting scene raad ik dan ook altijd aan om of zelf een cp te ontwikkelen (kost in het begin meer tijd, maar is uiteindelijk veel flexibeler) ofom een expert in te huren die een standaard product netjesdicht kan timmeren.
Waarom suExec of FastCGI? Ooit gehoord van mod_ruid?
Waarom suExec of FastCGI? Ooit gehoord van mod_ruid?
Daarom (http://www.freshports.org/www/mod_ruid) ;-)
Op Linux is mod_ruid inderdaad ook een optie, maar daar heb ik persoonlijk geen ervaring mee.
Daarom (http://www.freshports.org/www/mod_ruid) ;-)
Op Linux is mod_ruid inderdaad ook een optie, maar daar heb ik persoonlijk geen ervaring mee.Ah, inderdaad, niet aan gedacht ;) Ik draai het op ongeveer 50 Ubuntu servers, prima ervaringen mee.
Ah, inderdaad, niet aan gedacht ;) Ik draai het op ongeveer 50 Ubuntu servers, prima ervaringen mee.
Ik zal het eens testen; had toch in de planning staan om komende maand de prestaties van freebsd versus linux als NFS-client en NFS-backed webserver te vergelijken.
Ik heb op dit moment een standaard installatie van Ubuntu met daarop apache2, php5 en Mysql. Op dit moment kan ik met fopen iemand anders zijn config.inc.php uitlezen. Dit lijkt mij dus niet de bedoeling.
Ik ben opzoek naar goed leesvoer voor het beveiligen van mijn webserver. Is bovenstaand probleem op te lossen met mod_ruid en alle bestanden van gebruikers te chmodden naar 600?
Wido, welke stappen onderneem jij allemaal om je webserver te beveiligen? (mod_ruid, openbase_dir etc.)
Kijk ook eens naar mpm-itk, dit zit standaard in apache2 ingebakken en doe hetzelfde als mod_ruid. Per vhost geef je aan onder welke user het moet draaien.
Bij beiden geldt dat wanneer je wat vergeet het als root draait dus goed opletten. :)
Wido, welke stappen onderneem jij allemaal om je webserver te beveiligen? (mod_ruid, openbase_dir etc.)
openbase_dir is (als de rechten op de verschillende bestanden tenminste met gezond verstand zijn ingesteld, dus 0 voor world ipv bv 5 of 7) niet nodig als je mod_ruid in gebruik hebt. Doordat apache en daarmee php netjes de root-privileges droppen en als gewone gebruiker verdergaan, kan je ook met bv. fopen niet meer in andermans bestanden neuzen.
Ik heb mod_ruid altijd gebruikt. Echter zonder te weten wat het echt deed. Ja ik wist dat het elke vhost onder zijn eigen gebruiker liet draaien maar meer ook niet. Nu ben ik steeds meer lees voer aan het verzamelen over het optimaal beveiligen van je systemen.
Bij ons draait alles op freebsd en voor elke klant onder zijn eigen gebruiker en groep. zonder gebruik van fastcgi of suexec. en dus met de snelheid van mod_php.
In een nieuwe situatie zal dit nog een stap verder getrokken worden, zodat apache per account onder een eigen gebruiker draait zonder dat deze schrijfrechten heeft. zodat schrijfrechten binnen je directory structuur gelimiteerd kan worden, ook voor scripts.