Onderwerp: Hoe veilig is shared hosting?

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

Oorspronkelijk geplaatst door Wido

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 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.

Oorspronkelijk geplaatst door christian2

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?).

Oorspronkelijk geplaatst door christian2

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.

@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/.

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?