Een sterk wachtwoord is een goed begin, maar geen serverbeveiliging op zichzelf. De meeste websites en servers worden niet gehackt omdat een aanvaller gericht uw wachtwoord kraakt — ze worden gevonden door geautomatiseerde bots die continu het hele internet aftasten op zoek naar een openstaande deur. Hieronder leggen we uit welke lagen samen wél echte bescherming bieden, en waarom wij deze principes ook op onze eigen infrastructuur toepassen.
Bij ICT Solutions Zeeland testen we niet alleen websites en servers van klanten — we passen dezelfde aanpak toe op onze eigen omgeving. Niet omdat we nooit een verbeterpunt tegenkomen, maar omdat we structureel controleren, aanscherpen en documenteren. Dat is precies waar dit artikel over gaat.
1. Waarom SSH-brute-force gewoon normaal internetverkeer is geworden
Elke server met een openbaar IP-adres krijgt voortdurend inlogpogingen te verwerken, ook als er nooit iemand op die specifieke server heeft gelet. Bots scannen doorlopend grote delen van het internet af op openstaande beheerpoorten en proberen daar veelgebruikte gebruikersnamen en wachtwoorden op los. Dit is geen teken dat u persoonlijk doelwit bent — het is de digitale versie van iemand die aan elke deurklink in de straat trekt. Precies daarom is server beveiligen geen eenmalige actie, maar continue basishygiëne.
2. Waarom root-login met wachtwoord onnodig risico geeft
De meeste servers hebben één account met volledige rechten. Als dat account ook nog met een wachtwoord van buitenaf bereikbaar is, hoeft een aanvaller maar één ding te raden om volledige controle te krijgen. Wachtwoorden lekken via datalekken bij heel andere diensten, worden hergebruikt, of zijn simpelweg te raden voor een geautomatiseerd script dat duizenden pogingen per uur doet. Beheertoegang met alleen een sleutel toestaan — en het hoofdaccount helemaal niet via een wachtwoord bereikbaar maken — sluit dit hele aanvalspad in één keer af.
3. SSH-sleutels versus wachtwoorden
Een SSH-sleutelpaar bestaat uit een publieke en een privésleutel. De publieke sleutel staat op de server, de privésleutel blijft op uw eigen apparaat en verlaat dat apparaat nooit. Zonder die specifieke privésleutel is inloggen praktisch onmogelijk te raden — heel anders dan een wachtwoord, dat op afstand net zo lang geprobeerd kan worden tot het raak is. Voor elke vorm van SSH beveiliging is sleutelauthenticatie daarom de basis, niet een extra optie.
4. Een vast beheer-IP toestaan in plaats van de hele wereld
Wie standaard vanaf een vast internetadres beheert, kan beheertoegang beperken tot precies dat adres. Daarmee wordt de aanvalsoppervlakte in één klap enorm kleiner: een bot ergens ter wereld kan het beheerpaneel dan simpelweg niet meer bereiken, ook niet met het juiste wachtwoord. Dit werkt het beste in combinatie met een vaste werkplek of vertrouwde locatie — niet geschikt als enige maatregel voor wie voortdurend vanaf wisselende netwerken werkt.
5. Firewall en brute-force-bescherming
Een firewall bepaalt welk verkeer een server überhaupt mag bereiken. Brute-force-bescherming (software die herhaalde mislukte inlogpogingen automatisch herkent en de bron tijdelijk blokkeert) vangt vervolgens af wat er toch doorheen komt. Beide zijn losse, aanvullende lagen: een firewall zonder brute-force-bescherming laat herhaald raden gewoon toe binnen de toegestane regels, en brute-force-bescherming zonder firewall reageert pas ná elke poging in plaats van vooraf te weren. Samen vormen ze de kern van Linux server beveiligen in de praktijk.
6. 2FA voor WordPress-beheeraccounts
Ook als een wachtwoord ooit uitlekt, blijft een account met tweestapsverificatie (2FA) beschermd: zonder de tweede factor — meestal een code uit een app op uw telefoon — kan een aanvaller niet inloggen. 2FA voor WordPress-beheeraccounts is een van de goedkoopste en effectiefste maatregelen die er zijn, en hoort standaard te staan voor elk account met beheerrechten, niet alleen voor de hoofdbeheerder.
7. Onnodige accounts en oude wachtwoordhashes opruimen
Elk account dat niemand meer gebruikt is een deur die niemand meer in de gaten houdt. Oude testaccounts, accounts van vertrokken medewerkers of vergeten beheeraccounts van een vorige bouwer zijn een verrassend vaak over het hoofd geziene ingang. Periodiek controleren wie er nog toegang heeft — en overbodige accounts daadwerkelijk verwijderen in plaats van alleen deactiveren — hoort bij structureel WordPress beveiliging-onderhoud.
8. Database niet publiek bereikbaar maken
De database bevat alle content, klantgegevens en instellingen van een website. Voor een normale WordPress-site is er geen enkele reden waarom die database vanaf het internet bereikbaar hoeft te zijn — de website zelf draait op dezelfde machine en kan er lokaal bij. Een database die toch breed bereikbaar staat, is een onnodig extra aanvalspad dat met een kleine configuratiewijziging dicht kan.
9. Configuratiebestanden en back-ups buiten de publieke webroot
Bestanden zoals de WordPress-configuratie, omgevingsvariabelen met sleutels/wachtwoorden, en volledige back-ups horen niet in de map die door de webserver publiek wordt uitgeserveerd. Staan ze daar toch, dan is één verkeerd geconfigureerde map genoeg om een compleet databack-up of wachtwoordbestand direct downloadbaar te maken voor iedereen die de bestandsnaam kent of raadt.
10. Updates en malwarecontrole
De meeste succesvolle aanvallen op WordPress-sites maken gebruik van een kwetsbaarheid waarvoor allang een update bestaat — niet van een onbekend lek. Regelmatig bijwerken van WordPress zelf, plugins en thema’s sluit die bekende deuren. Daarnaast is het slim om periodiek te controleren op kernbestanden die zijn aangepast, onbekende bestanden tussen de uploads, of vreemde geplande taken — vroege signalen dat een site is gecompromitteerd, vaak lang voordat een bezoeker er iets van merkt.
11. Back-ups én herstel testen
Een back-up die nooit is teruggezet, is een aanname, geen garantie. Naast het maken van regelmatige, automatische back-ups is het minstens zo belangrijk om af en toe daadwerkelijk een herstel te oefenen. Alleen dan weet u zeker dat een back-up bruikbaar is op het moment dat u hem echt nodig heeft — bijvoorbeeld na een website gehackt-scenario.
12. Waarom u vóór het aanscherpen een recoveryroute nodig heeft
Dit is het punt dat het vaakst wordt overgeslagen — en dat is riskant. Beveiliging aanscherpen zonder eerst een uitwijkroute te regelen kan er namelijk voor zorgen dat u zichzelf buitensluit: een verkeerd getypte firewallregel, een verlopen sleutel of een niet-werkende 2FA-app, en niemand kan er meer bij. Een verstandige volgorde bestaat uit een paar lagen naast elkaar:
- Normale toegang — de dagelijkse, sleutelgebaseerde inlogroute die u gewoon blijft gebruiken.
- Een apart, dedicated herstelaccount — alleen bedoeld voor noodgevallen, met een eigen sleutel die nergens anders voor wordt gebruikt.
- Een vertrouwde tussenstap (bastion/jumpserver) — een tweede, onafhankelijke machine waarlangs u bij een probleem alsnog kunt binnenkomen.
- Een vast beheer-IP — zodat die noodroute niet breed openstaat, maar wel altijd vanaf de bekende plek bereikbaar blijft.
- De console van de hostingprovider — het laatste vangnet als alle netwerktoegang onverhoopt wegvalt.
Pas als deze route daadwerkelijk getest is — niet alleen ingesteld, maar ook echt geprobeerd terwijl de bestaande toegang nog werkt — is het verantwoord om de eigenlijke beveiliging (wachtwoordlogin uitschakelen, firewall aanzetten, brute-force-bescherming activeren) door te voeren. Andersom werken is de meest voorkomende oorzaak van een onnodige, zelf veroorzaakte lockout.
Uit de praktijk
Tijdens een interne controle zagen we tientallen tot honderden SSH-loginpogingen binnen korte tijd, verspreid over meerdere bronnen.
Dit was geen gerichte aanval op één specifiek bedrijf — het is precies het patroon uit punt 1 hierboven. Geautomatiseerde bots proberen continu bekende gebruikersnamen en wachtwoorden op elke server die ze tegenkomen, zonder enige interesse in wie de eigenaar is. Dat is meteen de reden waarom losse maatregelen niet genoeg zijn: het is niet de vraag óf een server ooit wordt benaderd door zo’n scan, maar of er dan meerdere onafhankelijke lagen klaarstaan om dat verkeer te weren. Precies dat noemen we defense in depth: geen enkele maatregel hoeft perfect te zijn, zolang de lagen samen het gat dichten.
Wilt u weten hoe uw WordPress-site of server ervoor staat?
De maatregelen hierboven zijn precies waar wij naar kijken bij een security check: van WordPress-beheeraccounts en 2FA tot serverconfiguratie en recoverymogelijkheden. Geen hackerstaal, geen paniek — gewoon een heldere lijst van wat goed staat en wat aandacht verdient.