Oorspronkelijk artikel in het Engels door Nicholas K. Dionysopoulos.

Dit artikel heeft niets te maken met religie. Het gaat over de veiligheid van uw website. Het beest waarnaar verwezen wordt, opent onbewust een achterdeur tot uw website voor mogelijke hackers. U weet het misschien niet, maar u zou een schietschijf kunnen zijn. Het heeft allemaal te maken met de duistere wereld van eigenaarschap, gebruikers, groepen en permissies. Dit is een lang artikel, maar we beloven u dat u dingen leert die u niet voor mogelijk houdt. Laten we wat helderheid scheppen in het mysterie van het getal 777, en het kwade beest doden!

777: Het getal van het beest

Lang geleden in Linuxland...

De meeste webservers draaien op Linux of een andere UNIX-variant, zoals Solaris, FreeBSD, etc. Een aspect wat alle UNIX besturingssysteemvarianten kenmerkt is het beveiligingsmodel van het bestandssysteem, gebaseerd op gebruikers, groepen, eigenaarschap en permissies. Een breed onderwerp, maar een snelle zoektocht op Google levert een immense hoeveelheid achtergrondinformatie op. We proberen hier de managementsamenvatting te geven.

UNIX-varianten kennen gebruikers, die elk tot één of meerdere groepen behoren. Elk bestand en elke directory (map) op het bestandssysteem is eigendom van slechts 1 gebruiker en groep. De eigenaar/gebruiker hoeft niet per se lid te zijn van de eigenaar/groep zodat flexibiliteit mogelijk is. Het systeem weet wie wat met een directory of bestand mag doen door middel van permissies. Permissies worden meestal aangegeven door een reeks van 3 octale getallen. Het eerste getal vertelt het systeem wat de eigenaar/gebruiker kan/mag doen, het tweede getal wat de eigenaar/groep mag doen en het derde getal wat ieder ander (de rest van de wereld) mag doen. De meest gebruikte getallen zijn 4 (alleen lezen), 5 (lezen en uitvoeren), 6 (lezen en schrijven) en 7 (lezen, schrijven en uitvoeren). Het utivoer-bit heeft een speciale betekenis bij directories: het betekent “bladeren”, bijv. iemand toestaan de inhoud van een directory weer te geven. Dit is wat anders dan “lezen”, dat alleen betekent dat een gebruiker een bestand uit de directory mag lezen als hij de naam weet.

Maar hoe weet het besturingssysteem nu hoe hij deze permissies moet verwerken? Net als bij directories en bestanden, is elk programma dat u uitvoert eigendom van een gebruiker en een groep.  Apache — de meest gebruikte webserver — is ook een programma. Het draait “onder” een gebruiker en groep. Dit geldt ook voor de FTP-server. Om de dingen wat ingewikkelder te maken: de FTP-server draait eigenlijk onder de gebruiker waarmee u op de FTP-server inlogt.

Dus, het besturingssysteem weet wie om toegang vraagt, gebaseerd op de gebruiker en groep van het programma dat toegang wenst. Het weet ook wat voor toegang gevraagd wordt (lezen, schrijven of uitvoeren/bladeren). Als het systeem het bestand/de directory vindt kan het de egienaar/gebruiker en eigenaar/groep opzoeken evenals de bijbehorende permissies. Het controleert eerst of de eigenaar/gebruiker en uitvoerende gebruiker hetzelfde zijn. Zo ja, dan wordt het eerste getal van de permissies gebruikt om te beslissen wat gedaan moet worden. Zo nee, dan wordt de eigenaar/groep en uitvoerende groep vergeleken en het tweede getal gebruikt om te beslissen wat gedaan moet worden. Als al het andere mislukt, wordt het derde getal van de permissies (de "wereld" permissies) gebruikt om te beslissen. Een elegant en effectief systeem, totdat iemand besluit het onwijs te gebruiken.

Er is niet meer dan een hap uit de appel nodig.
Op de meeste gedeelde hosts (shared hosts) wordt PHP ingesteld om als een Apache “module” te draaien (ook wel mod_php). Dit betekent dat uw PHP-bestanden draaien onder dezelfde gebruiker en groep als uw webserver. Vaak heten deze “nobody” en “nogroup”. Maar, als u uw bestanden upload met FTP, draait de FTP-server met de gebruiker waarmee u inlogt. Stel dat uw gebruikersnaam “foobar” is en u tot de groep “users” behoort. Dit houdt in dat alle bestanden en directories die u met FTP upload eigendom zijn van foobar:users en draaien onder nobody:nogroup (let op de gebruikte verkorte notatie voor gebruiker:groep voor de rest van het artikel). Dit betekent onder de gebruikelijke standaard directory- en bestandspermissies van 644 dat uw PHP-scripts (inclusief Joomla! en zijn extensies) niet naar bestanden op uw website kunnen schrijven, of zelfs door de inhoud van uw eigen websitemappen kunnen  bladeren!

Wat kan u dat schelen? Wel, moderne webtoepassingen, zoals Joomla!, WordPress en Drupal, moeten om verschillende redenen kunnen schrijven naar bestanden: cache bestanden, software installatie, logbestanden, geuploade bestanden via een webinterface, backups, etc. Aangezien de eigenaar en uitvoerende gebruikers/groepen verschillen is de enige manier om adequate permissies toe te wijzen het toekennen van lees, schrijf en blader/uitvoerrechten via het derde permissiegetal, de beruchte "wereld" permissies. Veel handleidingen - en zelfs software - doen de suggestie om 777 permissies te gebruiken. Inderdaad, dit werkt goed en al uw PHP-bestanden kunnen nu naar bestanden schrijven. Hoewel, het werkt eigenlijk te goed voor de gezondheid van uw website. Het lijkt een beetje op een hap nemen van de verboden appel. Hoe slecht kan het zijn?

U kent het verhaal. Er is slechts 1 hap van de appel nodig. Op een gedeelde host bent u niet de enige gebruiker. Andere websites hebben ook een gebruiker op hetzelfde systeem. Wat nog erger is, het exacte pad (ook wel het absolute bestandssysteempad) voor de root van elke website is zeer voorspelbaar, meestal in het formaat /home/gebruikersnaam/public_html. Als iemand uw website wil hacken, hoeft hij alleen maar een account op dezelfde server aan te maken en naar één van uw websitebestanden proberen te schrijven. Met de 0777 permissies, KAN HIJ DAT DOEN ZONDER DAT HIJ UW GEBRUIKERSNAAM EN WACHTWOORD KENT! Valt het u op hoe vaak al is verwezen naar het derde permissiegetal als "wereld" permissie? Dit geldt letterlijk voor de hele wereld. Iedereen op hetzelfde systeem mag naar uw bestanden en mappen schrijven!

Om u nog eens met de neus op de feiten te drukken, een slimme hoeft zelfs geen account op dezelfde server aan te maken. Op uw server draait heel veel software, zoals een webserver, een FTP-server, een DNS-server, een SSH-server, een mailserver enz. Als één daarvan kwetsbaar is kan hij dit lek  misbruiken om naar uw websitebestanden te schrijven. Zelfs als u alles blokkeert bieden gedeelde hosts een prachtige gelegenheid om u te grazen te nemen, zonder dat u het weet. Ook al heeft u alle maatregelen genomen om misbruik van lekken te voorkomen, een andere wesite op dezelfde server heeft wellicht niet zo nauw naar de veiligheid gekeken. Als de andere website kan worden misbruikt, kan de hacker uw website aanvallen omdat de 777 permissies hem daartoe in staat stellen.

Met andere woorden, het geven van 777 permissies is de snelste weg voor mogelijke hackers bezit van uw website over te nemen op tenminste 3 verschillende manieren, Gelooft u nu dat 777 het getal van het beest is?
Ter aanvulling, er geldt een uitzondering op deze regel. Als een directory boven de directory waarop u 0777 permissies heeft gegeven een 0 in de wereled-permissie bevat, bijv. 0700 of 0750, geeft het besturingssysteem geen wereld schrijfprivileges aan uw directory, ondanks de 0777 permissies. Bijv. als uw website staat onder /home/myuser/public_html en /home/myuser heeft 0700 permissies, heeft het instellen van 0777 permissies in /home/myuser/public_html/tmp geen effect. Dit verklaart wellicht waarom op een goed ingerichte host het instellen van 0777 permissies schijnbaar niet werkt.

Tijd voor een exorcist... of misschien niet?
Er zijn verschillende manieren om de slechte 777 permissies van uw server te verdrijven. Het hangt helemaal af van de manier waarop uw webserver is ingericht. Gordels aan, we betreden nu het doe-het-zelfgedeelte! Onthoudt: maak, voordat u ook maar iets doet met een live website, een backup. Download deze en sla het op tenminste 3 verschillende media op. Breng nooit, onder geen enkele omstandigheden, wijzigingen aan op een live website, zonder dat u een goede en geteste backup hebt. U kunt handmatig een backup maken of één van de garis extensies gebruiken uit de Joomla! Extensions Directory.

De perfect gedeelde host draait op suPHP
In de ideale situatie draaien de servers van de host op suPHP, zoals veel respectabele hosts. suPHP is een zeer slimme oplossing voor het permissiesprobleem. In plaats van dat PHP draait onder de gebruiker en groep van de webserver, draait PHP onder de eigenaar/gebruiker en eigenaar/groep van het PHP-bestand. Dit betekent dat alleen het eerste getal van de permissies belangrijk is, waarbij het tweede en derde getal kunnen worden ingesteld op 4 (lezen) of 5 (lezen, bladeren) voor directories. Gebruik geen 0, omdat u dan toegang weigert voor niet-PHP inhoud zoals afbeeldingen, Javascript en CSS-bestanden. In dit geval zijn de perfecte permissies 0644 voor bestanden en 0755 voor directories, die u kunt instellen met uw favoriete FTP-software.

Als u het niet weet, er is een makkelijke manier om uit te zoeken of uw host op suPHP draait. Ga naar de Joomla! administrator back-end en klik op Help, Systeeminformatie. Als “Webserver naar PHP interface” CGI of FastCGI aangeeft is er een goede kans dat uw webhost suPHP gebruikt. Vraag het hen eens.

De gedeelde host van de leek
Sommige hosts weigeren om suPHP te gebruiken. Dit zijn het soort hosts die een server volproppen met 2,000 - 3,000 websites. Bij suPHP zit een performance check, dus deze hosts gebruiken dit niet om zo hun servers zwaarder te kunnen belasten zonder dat dit leidt tot een gierende stop. In ieder geval, zelfs in deze situatie kunt u iets doen aan het semi-beveiligen van uw website.
De veel gebruikte en verkeerde benadering is om de webserver-gebruiker eigenaar te maken van al uw bestanden en directories. De gemakkelijkste manier om dat te doen is door een backup te maken van uw website, alles van uw account te wissen en daarna terugzetten van de backup door deze uit te pakken met een PHP-script dat geen gebruik maakt van FTP om bestanden over te zetten. Alle bestanden zijn dan eigenaar van de uitvoerende gebruiker van de webserver en u kunt 0644 permissies gebruiken voor bestanden en 0755 permissies voor directories. Vanuit beveiligingsoogpunt is dit grote onzin. Helaas trappen zelfs professionals met veel Linux-ervaring in deze valkuil. Waarom een valkuil? Ha! Als een andere gehoste website op dezelfde webserver wordt gehacked, kan de hacker naar uw website-bestanden schrijven omdat de eigenaar/gebruiker van beide websites dezelfde is: de gebruiker en degene die de webserver draait. Gefeliciteerd, u bent gehacked.

De juiste aanpak is moeizaam en kost tijd. U heeft alle bestanden en directories nodig van uw gebruikersaccount (bijv. gebruik FTP om ze te uploaden of gebruik een PHP-script om een backupbestand uit te pakken dat FTP kan gebruiken om te schrijven naar de uitgepakte bestanden) behalve degene waarnaar u moet kunnen schrijven. Omdat we het hier over Joomla! hebben, doe het volgende:

• Verwijder de cache, tmp en logs-directories
• Installeer Joomla! eXtplorer of NinjaXplorer op uw website. Deze bestandsbeheerders draaien binnen Joomla!, dus onder dezelfde naam en groep als uw webserver.
• Maak de cache, tmp en logs-directories aan met één van deze bestandsbeheerders. Deze directories zijn nu van de webserver-gebruiker.
• Geef ze tijdelijk 777 permissies, ook weer door gebruik te maken van deze bestandsbeheerders.
• Gebruik uw favoriete FTP-programma om een .htaccess bestand aan te maken in elk van deze directories met de volgende inhoud:
  
  order deny, allow
  deny from all
  

• Geef dit bestand 0644 permissies met uw FTP-programma.
• Ga terug naar de bestandsbeheerder (eXtplorer of NinjaXplorer) en geef de cache, tmp en logs-directories 0700 permissies. NB: wellicht moet u de cache-directory 0744 permissies geven en het .htaccess-bestand verwijderen om sommige CSS/JS aggregatie- & compressieplugins te laten werken. Een slechte praktijk, maar het lijkt in dat geval de enige werkbare oplossing. Beter is het om de plugin in kwestie te deïnstalleren.
• Ga naar de Algemene instellingen in Joomla! en activeer de FTP-laag. Sla het wachtwoord niet op!