Top 10

10 Tips website beveiligen

10 Aanbevelingen voor het verbeteren van de veiligheid van je (WordPress) website

In de afgelopen jaren is er een snelle toename geweest van hulpmiddelen en diensten op het gebied van web ontwikkeling. Content Management Systemen (CMS) zoals WordPress, Joomla!, Drupal en vele anderen bieden ondernemers de mogelijkheid om snel en makkelijk hun online aanwezigheid op te bouwen. De zeer uitgebreide mogelijkheden van die systemen zoals verschillende stijlen, plug-ins, modules en extensies maken het makkelijker dan ooit om een website up en running te krijgen zonder dat daar jaren van leren voor nodig zijn.

Dit is ongetwijfeld een goede zaak, maar helaas heeft dit ook een nare bijwerking; er zijn nu veel webmasters die niet weten hoe ze moeten zorgen dat hun website veilig is, of webmasters die zelfs het belang van een veilige website niet begrijpen. In deze post deel ik de tien belangrijkste stappen die iedere webmaster en website-eigenaren kunnen en moeten nemen om hun website veilig te houden.

1 – Update, Update, Update!

Dit is iets wat we niet genoeg kunnen benadrukken hier bij Online Exposure. Er zijn talloze websites die iedere dag in het gedrang komen door het gebruik van verouderde en onbeveiligde software. Het is ongelooflijk belangrijk om je website gelijk te updaten wanneer er een nieuwe CMS versie of plug in beschikbaar is. Hacken vandaag de dag is meestal geheel geautomatiseerd, er zijn bots die constant aan het scannen zijn om zo exploitatie mogelijkheden te vinden.

Het is niet genoeg om je website iedere maand te updaten, en zelfs iedere week is niet genoeg aangezien de bots de kwetsbaarheid waarschijnlijk al gevonden hebben voordat je ze kan maken. Behalve als je een website firewall als CloudProxy gebruikt, moet je de website direct updaten zodra de update is gelanceerd. Wanneer je WordPress gebruikt, raad ik je persoonlijk aan om de plug in ‘WP Updates Notifier’ te gebruiken, deze plug in stuurt je een email zodra er een plug in of een belangrijke update beschikbaar is.

2 – Wachtwoorden

Tijdens het werken aan websites voor klanten, moet ik vaak inloggen met hun beheerdersgegevens op hun site of server. Ik stoor me er vaak aan hoe onveilig hun belangrijkste wachtwoorden zijn. Het is bijna eng dat ik dit moet uitleggen, maar beheerder/beheerder is geen veilige gebruikersnaam en wachtwoord combinatie. Als je wachtwoord voorkomt in deze lijst met meest gebruikte wachtwoorden (list of most common passwords) , dan garandeer ik je dat jouw site op een gegeven moment gehackt wordt.

En zelfs als je wachtwoord niet in die lijst staat, er blijven veel misvattingen bestaan over wat nou een sterk wachtwoord is. De lakse eisen van de meeste ‘wachtwoord meters’ zijn een deel van dat probleem.

Als het aankomt op het kiezen van een wachtwoord, zijn er drie eisen waaraan het wachtwoord altijd moet voldoen (CLU – Complex, Lang, Uniek):

  • COMPLEX: Wachtwoorden moeten willekeurig zijn. Laat niemand je account hacken puur en alleen doordat ze achter je verjaardag of je favoriete sportteam zijn gekomen. Er zijn programma’s voor het kraken van wachtwoorden die miljoenen wachtwoorden kunnen proberen in een paar minuten. Als je bestaande woorden in je wachtwoord gebruikt dan is het wachtwoord niet meer willekeurig. Je denkt misschien dat je slim bezig bent wanneer je ‘leetspeak’ (letters vervangen met andere tekens Z04LS D!T) gebruikt, maar zelfs deze wachtwoorden zijn niet zo veilig als compleet willekeurige combinaties van letters en tekens. Hackers hebben een aantal serieus indrukwekkende woordenlijsten samengesteld om wachtwoorden te kraken (word lists for cracking passwords).
  • LANG: Wachtwoordden zouden minimaal 12 karakters lang moeten zijn.Ik weet dat er mensen in de security community zitten die zouden spotten met een 12 karakter wachtwoord en er op staan dat wachtwoorden langer moeten zijn. Echter, wanneer het gaat om online inlog systemen, zou ieder systeem wat de basis beveiligingsrichtlijnen volgt de inlogpogingen moeten beperken. Wanneer er een limiet is op het aantal mislukte inlogpogingen, dan is een 12 karakter wachtwoord genoeg om iemand makkelijk te stoppen in een paar pogingen. Dat gezegd hebbende, hoe langer het wachtwoord, hoe beter.
  • UNIEK: Gebruik wachtwoorden niet opnieuw! Ieder wachtwoord wat je gebruikt zou uniek moeten zijn. Deze simpele regel beperkt de gevolgen van een gekraakt wachtwoord drastisch. Het raden van je FTP wachtwoord zou iemand niet in staat moeten stellen om ook in te kunnen loggen op je email of online bankieren account. In tegenstelling tot wat vaak gedacht wordt, zijn we niet zo uniek als we zelf geloven; als je een willekeurig wachtwoord kan genereren is dat nog beter.

Ik hoor je nu al vragen ‘Hoe moet ik 10 willekeurige wachtwoorden onthouden die allemaal uit 12 karakters bestaan?’ Het goede nieuws is dat je ze niet allemaal hoeft te onthouden, sterker nog, je moet het niet eens proberen. Het antwoord is, gebruik een wachtwoord manager zoals  “LastPass” (online) en “KeePass 2” (offline). Deze briljante hulpprogramma’s bewaren al je wachtwoorden in een versleuteld format en ze kunnen makkelijk willekeurige wachtwoorden genereren met een simpele klik. Wachtwoord managers maken het zo veel makkelijker om sterke wachtwoorden te gebruiken dan om een aantal halfsterke wachtwoorden te onthouden.

Ja, ook deze wachtwoord managers kunnen voor uitdagingen zorgen en kunnen misschien ook een zwak punt hebben; zelfs deze week kondigde LastPass nog een compromis qua beveiliging aan. Maar niet alle compromissen zijn hetzelfde, meer hierover op een ander moment.

3 – Eén Site = Eén Container

Ik snap de verleiding. Je hebt een onbeperkt web hosting abonnement en je denkt ‘Waarom zou ik niet al mijn website op één server zetten?’. Helaas is dit een van de ergste veiligheidsfouten die ik vaak zie. Door het hosten van verschillende websites op dezelfde locatie loop je een groot aanvalsrisico.

Bijvoorveeld: een server met maar één website heeft misschien een enkele WordPress installatie, een bepaalde template en 10 plug ins die aangevallen kunnen worden door een hacker. Wanneer je daarentegen vijf websites op een dezelfde server zet met allemaal hun eigen plug ins en templates, dan kunnen die allemaal aangevallen worden. En om het erger te maken, wanneer een hacker een weg heeft gevonden om één van die websites aan te vallen, dan kan dat virus heel makkelijk verspreid worden naar de andere websites op die server.

Op die manier kan het natuurlijk voorkomen dat al je sites op hetzelde moment gehackt worden, maar het maakt ook nog eens het oplossen moeilijker. De geïnfecteerde websites kunnen namelijk elkaar keer op keer weer infecteren.

Nadat het oplossen is gelukt heb je nu een veel groter probleem. Je moet al je wachtwoorden nu resetten. In plaats van dat je dat maar voor één site moet doen, moet je dat nu voor allemaal doen. Ieder wachtwoord wat te maken heeft met elke website op die server moet veranderd worden. De CMS, de database en alle FTP gebruikers van die websites vallen hier ook onder. Als je dit niet doet, kan de hacker gemakkelijk via een van die wachtwoorden weer terug komen en dan moet je weer van vooraf aan beginnen.

4 – Sensible User Access

Deze regel geldt alleen voor websites die verschillende gebruikers hebben. Het is belangrijk dat iedere gebruiker de juiste mogelijkheden heeft. Als een gebruiker tijdelijk uitgebreidere toegang nodig heeft geef dat dan en trek het daarna weer in. Dit noemen ze Least Privileged.

Als je bijvoorbeeld een vriend hebt die een gastblog voor je wil schrijven, zorg er dan voor dat die vriend kan inloggen maar niet de volledige beheerder privileges heeft. Hij heeft het alleen nodig om nieuwe posts te kunnen schrijven en om zijn eigen post aan te kunnen passen want is helemaal niet nodig voor hem dat hij instellingen kan aanpassen.

Als je beperkt toegang geeft dan vermindert dat de kans op fouten die gemaakt kunnen worden. Je hebt minder kans op aangetaste accounts en het kan je beschermen tegen ‘rogue’ gebruikers. Dit is iets wat vaak over het hoofd gezien wordt door het gebruikersmanagement: aansprakelijkheid en controle. Wanneer mensen een account delen, en er is door dat account iets veranderd wat niet veranderd had moeten worden, hoe vind je dan uit wie van de gebruikers verantwoordelijk was?

Wanneer je eigen accounts hebt voor iedere gebruiker is het makkelijker in de gaten te houden wie wat doet doordat je persoonlijke logs kan bekijken en dan kan je ook zien wanneer er wordt afgeweken van hun normale gedrag (wanneer en waar ze normaal gesproken de website openen). Op die manier kan je makkelijk zien als er iets abnormaals gebeurt zodat je gelijk kan checken met die gebruiker of dit klopt. 

5 –Verander de standaard instellingen!

De meeste CMS applicaties zijn makkelijk in gebruik, maar vanuit veiligheidsperspectief zijn ze verschrikkelijk. De meest gebruikte aanvallen tegen websites zijn compleet geautomatiseerd en veel van deze aanvallen zijn alleen gebaseerd op de standaard instellingen. Dit betekent dat je veel aanvallen kan voorkomen door alleen de standaard instellingen te veranderen.

De meeste CMS applicaties kan je als gebruiker overschrijven, door elke extensie te installeren die je wilt. Er zijn instellingen die je kan aanpassen zodat je reacties kan controleren, gebruikers en de weergave van de gebruikersinformatie. De bestandsvergunning, waar we het later over gaan hebben, zijn een ander voorbeeld van standaard instellingen die je moeilijker kan maken.

Het is het makkelijkste om die instellingen direct te veranderen bij het installeren van de CMS, maar je kan ze ook later nog veranderen.

6 – Extensies selecteren

Een van de beste dingen van de CMS applicaties die tegenwoordig beschikbaar zijn is de rekbaarheid ervan. Daar staat helaas wel tegenover dat die rekbaarheid, dus de vele mogelijkheden, ook de grootste zwakte is. Er zijn zoveel plug ins, add-ons en extensies die er voor zorgen dat iedere functie mogelijk is. Er zijn alleen zoveel extensies die aangeboden worden met dezelfde of vergelijkbare functies, dus hoe weet je nou welke je moet installeren? Dit zijn de punten waar ik naar kijk wanneer ik moet beslissen welke extensies ik ga gebruiken.

Het eerste waar ik naar kijk is wanneer de extensie voor het laatst geüpdatete is. Als de laatste update meer dan een jaar geleden is dan ga ik me zorgen maken. Is te maker gestopt met er aan werken? Ik gebruik altijd liever de extensies die actief ontwikkeld zijn. Dat wijst er namelijk op dat de maker probeert oplossingen te vinden voor problemen die zich voordoen. Bovendien, wanneer er een extensie bestaat die niet meer onderhouden wordt, dan heeft het weinig zin om deze te gebruiken voor je website, het zou namelijk zomaar kunnen stoppen met werken.

Ik kijk ook altijd naar hoe oud de extensie is en hoe vaak deze geïnstalleerd is. Een extensie die ontwikkeld is door een ervaren maker die vaak geïnstalleerd is, is veel betrouwbaarder dan eentje die maar 100 keer geïnstalleerd is en gemaakt is door iemand waarvan het de eerste extensie is. Een ervaren ontwikkelaar is niet alleen meer ervaren in veilig ontwikkelen van de extensie maar ze zijn ook veel voorzichter met het beschadigen van hun reputatie door het invoegen van virussen in hun codes. Wat nog belangrijker is, hoe groter het gebruik, hoe meer motieven eventuele hackers hebben.

Het is ongelooflijk belangrijk dat je alle extensies en templates download vanuit betrouwbare bronnen. Er zijn ontzettend veel websites die gratis versies aanbieden van programma’s die normaal premium zijn en waarvoor je moet betalen.

7 – Backups

Net zoals alles in de digitale wereld, kan je website ook zomaar verloren gaan. We maken nooit vaak genoeg een back up, maar je zal jezelf dankbaar zijn als je wat tijd stopt in het uitvinden wat de beste back up oplossing is voor je website (best website backup solutions).

Het maken van back ups van je website is erg belangrijk, maar als je deze bewaart op dezelfde server als je gewone website loop je een erg groot veiligheidsrisico. Deze back ups hebben namelijk oude versies van de CMS die je gebruikt en heeft extensies die publiekelijk verkrijgbaar zijn, zodat hackers makkelijk toegang kunnen krijgen tot de server.

8 – Server Configuratiebestanden

Je moet echt de tijd nemen om uit te zoeken welke configuratiebestanden jouw web server gebruikt. Apache web servers gebruiken de .htaccess bestanden, Nginx servers gebruiken nginx.conf, en Microsoft IIS servers gebruiken web.config. Deze soort bestanden zijn erg sterk en worden daardoor meestal gebruikt in de root web directory. Met deze bestanden kan je de server regels uitvoeren en zo ook de richtlijnen volgen die de veiligheid van je website verbeteren.

Ik raad je aan om de volgende regels uit te zoeken en toe te passen voor jouw web server:

  • Voorkom directory browsing: Dit voorkomt dat hackers de content van iedere directory op de website kunnen zien. Het beperken van beschikbare informatie is altijd een handige voorzorgsmaatregel.
  • Voorkom hotlinking bij afbeeldingen: Ook al is dit niet per se een veiligheidsverbetering, dit voorkomt wel dat andere websites jouw afbeeldingen kunnen gebruiken. Als mensen hotlinken naar jouw afbeeldingen dan kan het gebeuren dat jouw brandbreedte opgaat aan het weergeven van afbeeldingen voor andere websites.
  • Beveilig gevoelige bestanden:Je kan regels maken om bepaalde bestanden of mappen te beveiligen. CMS configuratiebestanden vallen onder de gevoeligste bestanden die zijn opgeslagen op de web server, aangezien ze de uitgeschreven database login details bevatten. Er zijn wellicht andere locaties die je makkelijker kan afblokken zoals beheerder pagina’s. Je kan ook PHP uitvoeringen beperken in gebieden waar afbeeldingen staan of die uploads toestaan.

Er zijn nog veel meer regels en opties waar je naar kan kijken voor je webserver configuratiebestanden. Je kan zoeken naar de naam van je CMS, je webserver en ‘security/beveiliging’ maar zorg er wel voor dat je uitzoekt of wat je vindt betrouwbaar is voordat je het toepast. Er zijn mensen met kwade bedoelingen die verkeerde informatie op het web zetten.

9 – Installeer SSL

Ik weet niet zeker of ik dit punt ook moet noemen, er zijn namelijk zoveel artikelen in omloop die, onterecht, stellen dat het installeren van SSL alle beveiligingsproblemen op kan lossen. SSL voorkomt namelijk niet dat je website aangevallen kan worden en het stopt het verspreiden van malware ookniet. Wat SSL wel doet is het versleutelen van de communicatie die plaatsvindt tussen de website server en de browser. Die versleuteling is belangrijk voor het volgende: het zorgt ervoor dat niemand die communicatie kan onderscheppen en zo je website aan kan vallen (MITM, Man in the Middle attack). Lees ook > SSL CERTIFICAAT INSTALLEREN WORDPRESS

SSL is vooral belangrijk voor E-Commerce website security en elke andere website die formulieren met gevoelige gebruikersinformatie gebruikt (PII, Personally Identifiable Information). Het SSL certificaat beschermt de bezoekersinformatie en zo beschermt het jouw tegen boetes wanneer je niet de richtlijnen volgt die in overeenstemming zijn met PCI DSS.

10 – Toegankelijkheid van bestanden

De toegankelijkheid van bestanden bepaalt wie wat kan veranderen aan een bestand.

Ieder bestand heeft 3 verschillende toegankelijkheidslevels en ieder level wordt vertegenwoordigt door een nummer.

  • Read/Lees‘ (4): Bekijk het bestand.
  • Write/Schrijf‘ (2): Verander het bestand.
  • Execute/Voer uit‘ (1): Voer het bestand of het script uit

Als je verschillende levels wil toestaan, dan moet je de getallen bij elkaar optellen, bijvoorbeeld, om toe te staan dat iemand het bestand kan bekijken (4) en kan veranderen (2) dan zet je de toegankelijkheid op 6. Wanneer je de gebruiker toe wil staan om het bestand de bekijken (4), te veranderen (2) en het uit te voeren (1) dan zet je de toegankelijkheid op 7.

Er zijn ook 3 verschillende gebruikerstypes:

  • Owner/Eigenaar– Dit is meestal de maker van het bestand, maar dit kan veranderd worden. Er kan maar één gebruiker de eigenaar zijn.
  • Group/Groep – Ieder bestand is toegewezen aan een groep en iedere gebruiker die bij deze groep hoort krijgt deze toegankelijkheden.
  • Public/Publiek– Alle anderen.

Dus, als je wil dat de eigenaar toestemming heeft om het bestand te bekijken en aan te passen, de groep om het te bekijken en het publiek helemaal geen toegang, dan zouden de toegankelijkheidlevels als volgt moeten zijn:

Write/Schrijf Read/Lees Execute/Voer uit
Owner/Eigenaar  2 4 0
Group/Groep  0 4 0
Public/Publiek  0 0 0

 

Als je dan de toegankelijkheid van dit bestand bekijkt, dan wordt dit weergegeven als 640. Mappen hebben dezelfde toegankelijkheidsstructuur, het enige verschil is dat de ‘voer uit’ melding je dan toestaat om van de directory je werkmap te maken (dus die wil je meestal aan hebben staan).

De meeste CMS hebben alle toegankelijkheidlevels goed ingesteld, dus waarom heb ik dit net allemaal uitgelegd? Wanneer je online zoekt voor oplossingen voor problemen met toegankelijkheid, dan vind je vaak het advies om de instellingen voor bestanden op 666 te zetten en voor mappen op 777. Dit lost vaak alle toegankelijkheidsproblemen wel op, maar vanuit veiligheidsperspectief is dit een ontzettend slecht advies. Wanneer je deze instellingen gebruikt, dan sta je namelijk iedereen toe om malware in te voegen in je code of om je bestanden te verwijderen!

Conclusie

Hier heb je ze, 10 relatief simpele stappen die je kan nemen om de veiligheid van je website drastisch te verbeteren. Deze stappen alleen zullen niet garanderen dat je site nooit gehackt zal worden, maar als je ze volgt dan zullen ze in ieder geval zorgen dat de meeste geautomatiseerde aanvallen gestopt worden en zo je algemene risico’s beperken.

Je bewust zijn en het begrijpen van deze kwesties geven je waardevol inzicht in hoe de onderliggende technologie werkt en het zal je helpen om een betere webmaster/site operator te worden.

Hulp nodig bij het beveiligen van je website?

Contact ons op: info@online-exposure.nl

 

 

Sorry, the comment form is closed at this time.