Verouderde software op uw website: risico's en aanpak

Verouderde software is de meest praktische reden dat websites worden gehackt of kapotgaan. Loopt een CMS, plug-in, thema of PHP-versie achter, dan blijven bekende beveiligingslekken open staan en stapelen compatibiliteitsproblemen zich op. De oplossing is routine: weet wat u draait, maak een back-up, test updates op een kopie, werk in kleine stappen bij en houd een manier om terug te draaien.

Waarom is verouderde software gevaarlijk?

Als een ontwikkelaar een beveiligingslek dicht, zijn de release-notes en de codewijziging openbaar. Dat helpt iedereen bij het patchen, maar het vertelt aanvallers ook precies waar oudere versies zwak zijn. Bots scannen daarna het web op sites die nog de oude versie draaien.

Stel: een contactformulier-plug-in die u drie jaar geleden installeerde en nooit aanraakte. Er wordt een fout gevonden en in een nieuwe versie opgelost. Uw site staat nu in een lijst met duizenden die automatisch overgenomen kunnen worden, zonder dat iemand u uitkoos.

Verouderde software gaat ook kapot. Oude plug-ins werken niet meer met nieuwere PHP-versies, wat een wit scherm kan geven of de melding dat er een kritieke fout is opgetreden op uw WordPress-site.

Wat telt als verouderde software?

Vier lagen kunnen achterlopen, en elke laag verdient aandacht.

Verlaten plug-ins zijn een aparte categorie. Is een plug-in lang niet bijgewerkt door de maker en wordt hij niet meer onderhouden, dan wordt een gevonden lek nooit meer verholpen. Vervang hem.

Wat betekent end-of-life PHP?

Elke PHP-versie krijgt een beperkte periode van ondersteuning. Daarna is hij end of life (EOL) en komen er geen bug- of beveiligingsfixes meer, ook niet voor ernstige problemen. Het officiële overzicht van ondersteunde versies staat op php.net.

PHP 7.4 en oudere versies zijn al jaren end of life. Ziet u er nog een in uw hostingpaneel, plan de overstap dan nu. Omhoog gaan is zelden één klik, want oude plug-ins en eigen code kunnen leunen op functies die zijn verwijderd. Daarom test u eerst.

Hoe controleert u wat uw site draait?

U kunt niet bijwerken wat u niet kent. Een korte inventarisatie kost ongeveer twintig minuten.

1. Log in op uw CMS-beheer en noteer de versie van de kern.
2. Maak een lijst van alle plug-ins en thema's met hun versie en markeer wat verouderd of inactief is.
3. Bekijk de PHP-versie in uw hostingpaneel of in het scherm Sitegezondheid van uw CMS.
4. Zoek van elke plug-in waar u op leunt op wanneer de maker hem voor het laatst bijwerkte.
5. Zet alles met de datum in één document.

Hoe werkt u veilig bij?

De meeste updaterampen komen door haast, niet door het updaten zelf. Volg elke keer dezelfde volgorde.

1. Back-up
2. Kopie naar staging
3. Bijwerken en testen
4. Live bijwerken
5. Controleren of terugdraaien

Maak eerst een back-up

Maak een volledige back-up van bestanden en database en bewaar die buiten de server. Controleer dat hij bestaat voordat u verdergaat. Zonder geteste back-up is een update een gok.

Test op een staging-kopie

Een staging-site is een privékopie van uw website. Werk die eerst bij en klik langs de pagina's die ertoe doen: homepage, formulieren, inloggen en, bij een webshop, de checkout. Problemen komen dan boven water waar geen klant ze ziet.

Werk in kleine stappen bij

Werk plug-ins een voor een of in kleine groepen bij, en de kern apart. Gaat er iets stuk, dan weet u welke wijziging de oorzaak is. Doe dit op een rustig moment, niet op vrijdagmiddag vlak voor een campagne.

Houd een rollback klaar

Breekt de live site, zet dan eerst de back-up terug en onderzoek daarna op staging. Rustig terugdraaien wint het van debuggen onder druk. Ligt uw site al plat na een update? Lees dan wat u doet als een site kapot is na een update.

Wat als u te lang hebt gewacht?

Een site die meerdere versies achterloopt vraagt om een voorzichtige route, niet om één grote sprong. De gebruikelijke volgorde: back-up maken, ongebruikte plug-ins opruimen, PHP verhogen naar een versie die de site ondersteunt en dan de CMS- en plug-inupdates stap voor stap doorlopen. Sommige oude plug-ins moeten worden vervangen.

Welke updates doet u als eerste?

Niet elke update is even dringend. Beveiligingsreleases gaan voor, omdat ze een lek dichten dat al openbaar is. Functionele updates en ontwerpwijzigingen kunnen wachten tot een rustiger moment.

De release-notes vermelden meestal of een update een beveiligingsfix is. Beschrijft de maker een kritiek lek, behandel het dan als het werk van dezelfde dag dat het is, met een back-up en een snelle controle erna. Houd de rest op een vast maandelijks ritme.

Hoe kunnen wij helpen?

Bijwerken is niet moeilijk, maar het veilig doen kost tijd en zorg, en het houdt nooit op. Onze zorgplannen bevatten veilige updates met terugdraaien, dagelijkse back-ups op een andere locatie, uptimecontroles met meldingen, waarschuwingen voor SSL en domein, beveiligingsscans en een maandrapport. In websitebeveiliging voor het mkb ziet u waar updates in het grotere plaatje passen.

Al achtergelopen, of is er iets kapot? Neem contact op voor een gratis diagnose. U krijgt vooraf een vaste prijs en we maken vóór elke wijziging een back-up.