Beveiliging van je website, waar en hoe doe je dat?

Vaak is de beveiliging van een website voor onze opdrachtgevers een soort onvermijdelijk sluitstuk. Het laatste jaar heeft vooral in het teken gestaan van http/ssl, het bekende groene slotje. Maar dat zegt slechts iets over de wijze waarop data versleuteld wordt verstuurd vanaf de server naar de browser en (eventueel) terug vanuit bijvoorbeeld een webshop of contactformulier.

Maar een veilige website vergt heel wat meer dan slechts versleutelde data. Er zijn nogal wat plugins op dit gebied. De twee meest bekende zijn Sucuri, Wordfence en iThemes Security. Allemaal forse plugins met talloze instellingen. Meestal zijn de meest belangrijke instellingen al vooraf gedefinieerd. Daardoor weet je als eindgebruiker eigenlijk niet goed, wat de plugin nu precies wel of niet doet. Maar het geeft wel het gevoel van zekerheid. Deels is dat ook wel terecht.

Login pogingen

Een mogelijke aanval begint altijd met pogingen om in te kunnen loggen. Dergelijke pogingen zijn niet uniek, robots scannen het hele internet af en vinden in ca. 30% van de gevallen WordPress, waarvoor geautomatiseerde routine zijn geschreven om inlog pogingen te doen. De gebruikersnaam ‘admin’ is daarbij voor de hand liggend en met tal van algoritmes trachten dergelijke robots wachtwoorden in te voeren in hun poging binnen te komen. Je zou dergelijke pogingen kunnen afvangen, door de IP adressen geautomatiseerd op een blacklist te plaatsen na een aantal pogingen. Dat resulteert veel in vele honderden adressen, daar inbraken wereldwijd vanaf zoveel plekken plaatsvinden, dat dit nauwelijks afdoende is. Het aantal pogingen om in te loggen zal hierdoor zeker niet afnemen.

Tweede scherm na ‘gewoon’ inloggen, voer de 6-cijferige code in die in de mobiele app ‘Google Authenticator’ verschijnt.

Het is op eenvoudige wijze mogelijk inlogpogingen eerder ‘af te vangen’ door te voorkomen, dat een poging het systeem al binnenkomt en dus de inlog routine doorloopt om deze vervolgens bij verkeerde gebruikersnaam en/of wachtwoord af te wijzen. Tegenwoordig wordt vaak gebruikt van de zogenaamde ’twee stappen authenticatie’. Dat betekent dat na een gewone inlog een tweede stap moet worden doorlopen. Natuurlijk zijn voor deze methode talloze gereedschappen beschikbaar. Onze keuze viel op ‘Two Factor Authentication‘.

De plugin werkt feilloos samen met de app Google Autheticator, die de 6-cijferige code verschaft om na de gebruikelijke inlog in te voeren, zoals te zien in bijgaande illustratie. Binnen de app kunnen meerdere websites worden opgenomen om de juiste codes te verschaffen per inlog per website. Binnen WordPress zorgt de plugin ervoor dat elke gebruiker zelf zijn eigen basisinstellingen kan instellen.

Meer beveiliging

Natuurlijk is er veel meer dan alleen het afwenden van inlog pogingen. Het aantal mogelijke beveiligingsmaatregelen is eigenlijk teveel om op te noemen. De WordPress kern wordt bij vrijwel update weer voorzien van maatregelen tegen ‘lekjes’ en ook serieuze plugin ontwikkelaars zorgen voor het dichten van lekken un hun producten.

WPScan Vulnerability Database is de centrale lokatie waar lekken worden geregistreerd. Ook wordt aangegeven of er een patch heeft plaatsgevonden om het lek te dichten. Een e-mail abonnement kan gratis worden afgesloten om meldingen te ontvangen.

Op serverniveau

LUIT.nl heeft ervoor gekozen om de beveiliging van websites centraal op serverniveau te regelen. Het bekende control panel Plesk biedt met de zogenaamde WordPress Toolkit talrijke mogelijkheden websites afdoende te beveiligen. De eindgebruiker wordt niet geconfronteerd met een plugin met talloze instellingen, alles gebeurt onder de verantwoordelijkheid van de server beheerder.

De Tooklit zorgt o.a. voor:

• Aanpassen van gebruikersnaam ‘admin’
• Aanpassen van de database prefix. Naast inlogpogingen kunnen robots ook pogingen doen de achterliggende database aan te vallen. Alle tabellen beginnen met ‘wp_’, robots gaan hier dan ook vanuit in hun pogingen, door deze zogenaamde ‘prefix’ aan te pakken (bijvoorbeeld ‘gjhf5_’) wordt het robots een stuk lastiger gemaakt de database te kunnen bereiken
• Beveiligen van de WordPress configuratie file (wp_config.php). Hierin staan kwetsbare gegevens, welke door de Toolkit worden geblokkeerd voor aanvallen van buitenaf.
• Blokkeren van het kunnen bekijken van de inhoud van de WordPress installatie via een browser
• Het controleren van de zogenaamde ‘security keys’ in wp_config.php
• Het controleren van de gebruiksrechten van bestanden en mappen
• Het controleren of de uitvoering van PHP bestanden in de mappen wp-content en wp-includes is toegestaan
• Het blokkeren van zogenaamde XML-RPC pingbacks om DDOS aanvallen te voorkomen
• Het voorkomen van zogenaande script aanvallen op het dashboard

Daarnaast biedt de WordPress Toolkit tal van (geautomatiseerde) voorzieningen rondom updates van zowel de WordPress basis, thema bestanden en plugins. Plesk streeft ernaar een volledige WordPress beheeromgeving aan te bieden en zij slagen daar goed in.

Conclusies

De beveiliging van websites vergt steeds meer aandacht. Dit te centraliseren op serverniveau verlaagt de kwetsbaarheid in het gebruik van het mogelijke gebruik van diverse plugin, al dan niet door klanten zelf geïnstalleerd. Juist doordat de keuzemogelijkheden zo divers zijn, vergt dat per website veel meer extra beheerstaken in vergelijking tot gelijktijdige centraal geregelde beveiliging voor meerdere websites. Voor u veiliger en tevens voordeliger in de beheerskosten.