Overslaan en naar de inhoud gaan

Maak Drupal nog veiliger in 7 stappen

Wat kun jij doen om Drupal veilig te houden? 7 tips om je Drupal CMS nog veiliger te maken.

Is Drupal veilig? Ja. Veiliger dan closed source software? Minstens zo veilig en meestal veiliger. Veiliger dan Wordpress of Joomla? Ja, ook dat. Niet dat Wordpress of Joomla veel onderdoen maar er zijn redenen waarom Drupal het over het algemeen erg goed doet op dit gebied. Hoe dit komt, en welke stappen je zelf kunt ondernemen om Drupal veilig te houden, lees je hieronder.

Open source: de code ligt op straat

Op het eerste gezicht lijkt het een groot risico dat open source code volledig openbaar is. In de praktijk blijkt echter dat veiligheidslekken hierdoor in vrijwel 100% van de gevallen worden ontdekt en verholpen voordat er misbruik van kan worden gemaakt. De code ondergaat in de vorm van crowdsourcing een continue kwaliteitscontrole die niet te reproduceren is door een beperkt team met beperkte middelen.

Voor de website van het Witte Huis is veiligheid uiteraard een belangrijke voorwaarde bij het kiezen van een geschikt CMS systeem. Het zegt veel dat de Amerikaanse overheid bij Drupal uitkwam.

Veiligheid binnen de Drupal community

Zowel Drupal als Wordpress en Joomla hebben een team van security experts die meldingen behandelen en proactief op zoek zijn naar beveiligingsproblemen in de Drupal core. De security experts werken ook nauw samen met module makers op het moment dat een kwetsbaarheid is ontdekt, bekijk ook onderstaande infographic (klik voor volledige weergave).

Binnen de community wordt veel gedaan om de reputatie van Drupal op het gebied van veiligheid hoog te houden. Op Drupal.org is informatie beschikbaar over het schrijven van veilige modules en het gebruik van de speciale security API. Op project pagina’s is veel informatie te vinden over de activiteiten rondom een module en mogelijke issues. Security updates bevatten begeleidende informatie over hoe problemen zijn ontstaan en opgelost.

7 Stappen om Drupal veiliger te maken

Stap 1: Zorg altijd voor een back-up

Een inkopper, maar zorg er altijd voor dat er structureel back-ups worden gemaakt van zowel de database als de bestanden op de server. Bewaar je back-ups buiten de root folder en/of op een externe offline of online locatie. Aangezien niet alle cloud spaces redundant zijn is het altijd verstandig om ook een met wachtwoord beveiligde back-up op een lokale USB stick achter de hand te hebben.

Met de Backup and Migrate module kun je automatische back-ups maken, in combinatie met Backup Migrate Files ook van je bestanden. De module heeft, eventueel met een uitbreiding, de optie om back-ups direct naar externe cloudspace of FTP locatie te versturen. Herstel de gemaakte back-up ter controle eerst een keer in een test omgeving voordat je er volledig op vertrouwt.

Stap 2: Hou Drupal up-to-date

Naast het maken van back-ups is het minimale en veruit belangrijkste wat je kunt (lees: moet) doen de core bijwerken op het moment dat er een security update beschikbaar is. Op de Security pagina van Drupal.org word je op de hoogte gehouden van nieuwe patches. Hier vind je ook informatie over hoe je je kunt inschrijven voor de security nieuwsbrief of relevante RSS feeds.

Stap 3: Update onveilige module en verwijder niet gebruikte modules

Je Drupal core kan helemaal up-to-date zijn maar dat heeft niet veel zin als een module toch toegang biedt tot content of gebruikersdata. Update daarom niet alleen de core maar ook alle modules. Met name degene waarvoor een security update beschikbaar is. Vergeet niet om eerst stap 1, het maken van een backup uit te voeren, voordat je de modules update.

screenshot van het overzicht van module updates in Drupal
Met name de module updates in het rood (beveiligingsupdate) moet je zsm doorvoeren.

Verwijder ook niet gebruikte modules. De meeste Drupal websites bevatten veel modules, bij een Wordpress of Joomla website is dat een teken van een beginnende ontwikkelaar (die zoveel mogelijk plugins wil testen) maar door de framework structuur van Drupal is het gebruiken van veel modules onontkoombaar. De module unused modules geeft je een goed overzicht van modules die niet gebruikt zijn maar waar de code wel van aanwezig is binnen je CMS. Het beste kun je deze helemaal verwijderen, dan kunnen deze ook geen veiligheidsrisico vormen. 

Stap 4: Vertrouw je gebruikers niet (teveel)

Je kunt nog zo’n veilig administrator wachtwoord hebben, een hacker kan via een omweg binnenkomen via een andere gebruiker met een minder veilig wachtwoord. Wanneer deze gebruiker het recht heeft om andere gebruikers aan te maken dan kan hij ook het wachtwoord van de administrator aanpassen om vervolgens de hele website over te nemen. Spring daarom spaarzaam om met gebruikersrechten en overweeg de volgende modules:

  • De Security Review module geeft een handig overzicht van alle actuele beveilingsrisico’s op een website, bijvoorbeeld wanneer administratieve rechten zijn toebedeeld aan rollen die dat waarschijnlijk niet hoeven te hebben.
  • De Paranoia module zorgt ervoor dat user1 (het admin account) niet meer veranderd kan worden en bevat nog enkele andere veiligheidsmaatregelen zoals het uitschakelen van PHP input in velden.
  • Met Password Policy kun je bepalen aan welke eisen wachtwoorden moeten voldoen, zoals minstens 6 tekens waarvan minimaal 1 cijfer en 1 hoofdletter.
  • Login Security of Flood Control (minder opties) kunnen voor je ingrijpen op het moment dat een script of persoon binnen korte tijd meerdere verkeerde wachtwoorden combinaties invult, iets wat wijst op brute force of flooding.

 Stap 5: Vergeet de serveromgeving niet

Aanvallen worden niet alleen gericht op gaten in het CMS maar ook op andere zwakke plekken binnen de totale serveromgeving. In situaties van shared hosting kan malware wellicht binnenkomen via een andere website op dezelfde server. Shared hosting is dan ook af te raden als extra beveiliging gewenst is.

Een andere kwetsbare ingang is de FTP server. Er zijn scripts in omloop die opgeslagen wachtwoorden in FTP programma's kunnen aflezen. Sla FTP wachtwoorden daarom niet op in het FTP programma of op jouw PC maar berg ze goed op of probeer ze te onthouden. Als je wachtwoord toch op je PC noteert probeer ze dan cryptisch te omschrijven op een manier die alleen voor jou te begrijpen is. Mocht iets of iemand toch toegang hebben tot de bestanden op de server zorg dan voor een extra drempel in de vorm van een .htacces bestand met ip-beveiliging.

Verzeker je er verder van dat de bestanden op de server niet door iedereen uitgevoerd mogen worden. De aanbevolen rechten voor de mappen en bestanden van Drupal vind je hier. De eerder genoemde Security Review module geeft ook aan of jouw mappen wel of niet goed beveiligd zijn. 

Stap 6: Hou alles goed in de gaten

Er meerdere modules voor Drupal die in real-time bijhouden of er verdachte voorvallen hebben plaatsgevonden:

  • De Hacked module houdt bij welke module zijn aangepast en welke regels precies. Het komt vaak voor dat ontwikkelaars modules aanpassen, waarna ze module niet meer updaten omdat hun wijzigingen dan verloren gaan. Het gebruik van deze module maakt het makkelijker om de wijziging na de update weer opnieuw toe te passen. (Let op: niet geschikt voor een live omgeving)
  • MD5Check doet vrijwel hetzelfde als Hacked maar is juist wel bedoelt voor productie website en geeft voor alle modules en de Drupal core aan of de code is gewijzigd ten opzichte van het origineel, wat natuurlijk erg verdacht is.
  • Tiny XSS detecteerd aanvallen op basis van Cross Site Scripting, oftewel XSS. Vrijwel de meeste (ook geslaagde) pogingen om Drupal te kraken komen van XSS aanvallen.

Daarnaast zijn er externe applicaties zoals Drupalmonitor.com (op moment van schrijven nog gratis) die bijhouden of je Drupal websites up-to-date en beschikbaar is. Zodra dit niet het geval is krijg je hiervan een melding. Zo weet je precies wanneer er actie moet worden ondernomen.

Stap 7: Stap over naar HTTPS

Wanneer gebruikers via jouw website gevoelige informatie delen of versturen zoals creditcard gegevens dan dien je naast het treffen van alle overige veiligheidsmaatregelen ook een HTTPS verbinding op te zetten. Dit verkleint het risico aanzienlijk dat de verzonden informatie wordt onderschept. Meer informatie over het instellen van een HTTPS verbinding.

Tot slot

Veiligheid is natuurlijk een relatief begrip. Een goed slot is nog geen garantie dat jij niet vergeet om je fiets op slot te zetten of dat je fiets met slot en al een busje wordt ingedragen.

De Drupal core is zeer veilig maar alleen als ze tijdig wordt bijgewerkt. Het installeren van veel en onvoldoende geteste modules verhoogt het risico op lekken. Daarbij zegt een veilige Drupal installatie nog niks over de veiligheid van jouw gegevens omdat je daarin ook afhankelijk bent van jouw serveromgeving. 

Kortom, elke situatie is anders en vraagt om haar eigen set van maatregelen. Maar wat de omstandigheden ook zijn: maak altijd back-ups en hou die core (plus modules) up-to-date!

Heb je iets aan deze content gehad? Laat weten hoe je ons waardeert.

Meld je aan voor onze nieuwsbrief

En je ontvangt net als 2321 andere leden een overzicht van onze nieuwste artikelen. Met onderwerpen als; de laatste webdesign trends, SEO tips, conversie optimalisatie, Joomla, Drupal en Wordpress ontwikkelingen.

Reacties

Beperkte HTML

  • Regels en alinea's worden automatisch gesplitst.