Likes: 
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.Oorspronkelijk geplaatst door christian2
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?
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".
Quote
Ik draai het op ongeveer 50 Ubuntu servers, prima ervaringen mee.
