Kort gezegd: De beheeromgeving beveiligt u het best door hem alleen voor bekende netwerken te openen: met een IP-whitelist in de webserver, via een VPN met een vast uitgaand adres of met een tweede, voorgeschakelde aanmelding. Belangrijk zijn een volledige lijst van alle beheeradressen, de juiste behandeling van proxy's en CDN's en een test van buitenaf. De afscherming vult tweestapsverificatie en updates aan, ze vervangt die niet.
Waarom staat de backend eigenlijk open?
In veel bedrijven hebben beheerders vorige week PHP bijgewerkt en workers herstart. Wie daarna de toegangslogboeken bekijkt, ziet vaak iets anders: de aanmeldpagina van het CMS, het databasehulpmiddel en het hostingpaneel worden dag en nacht vanuit de hele wereld opgevraagd. Nodig zijn ze echter slechts voor een handvol mensen in het eigen team.
Elk van deze adressen is aanvalsoppervlak. Aanmeldformulieren worden doorgeprobeerd, beheerhulpmiddelen bevatten eigen kwetsbaarheden en plug-ins voor de backend zijn vaak minder goed gecontroleerd dan de kern van een CMS. Als buitenstaanders deze omgevingen helemaal niet kunnen bereiken, lopen veel aanvallen dood voordat ze beginnen.
Eerlijk ingeschaald: tegen PHP2Shell zelf helpt dit weinig. De kwetsbaarheden zitten in de interpreter en zijn volgens php.net zonder inloggen via openbare PHP-pagina's te activeren. De afscherming van de backend is een blijvende hardening, geen noodpatch.
Beheeromgeving beveiligen met IP, VPN of tweede aanmelding
Er is niet één juiste methode. Beslissend is hoe uw team werkt en waar de website draait.
| Methode | Geschikt voor | Grens |
|---|---|---|
| IP-whitelist in de webserver | kantoor met vast adres, kleine teams | wisselende adressen bij thuiswerken, onderhoud van de lijst |
| VPN met vast uitgaand adres | verspreide teams, dienstverleners | het VPN moet zelf goed beveiligd en actueel zijn |
| Voorgeschakelde aanmelding (HTTP-authenticatie) | aanvulling als een vast adres niet mogelijk is | extra wachtwoord, alleen zinvol samen met TLS |
| Clientcertificaten | enkele, vast beheerde apparaten | uitgifte en intrekking van de certificaten vragen discipline |
| Eigen hostnaam alleen in het interne netwerk | grotere omgevingen met interne DNS | aanpassing van de applicatie, niet elk CMS ondersteunt dit |
In de praktijk bewijst een combinatie zich: vrijgave alleen voor het VPN of het bedrijfsnetwerk, met een tweede aanmelding als terugvalniveau. De eigenlijke aanmelding in het CMS blijft bestaan met tweestapsverificatie, zoals beschreven in de gids Tweestapsverificatie voor beheertoegang.
Welke adressen horen eigenlijk bij de backend?
De meest voorkomende zwakte is niet de techniek, maar een onvolledige lijst. Ga daarom in deze volgorde te werk:
- Aanmeldpagina's van het CMS of de webshop inventariseren, inclusief alternatieve inlogadressen die plug-ins aanmaken.
- Beheerhulpmiddelen opsporen: database-interfaces, bestandsbeheerders, installatiescripts, status- en monitoringpagina's.
- Hosting- en serverpanelen meenemen, die vaak op eigen poorten draaien.
- Test- en stagingomgevingen controleren, die vaak dezelfde toegangsgegevens gebruiken als de live-website.
- Interfaces afbakenen: sommige backendpaden worden ook door de openbare frontend aangeroepen, bijvoorbeeld voor Ajax-verzoeken. Die mag u niet blind blokkeren, anders gaan formulieren of winkelwagens kapot.
Punt vijf is de reden waarom een afscherming altijd getest moet worden. Bij WordPress bijvoorbeeld wordt een bestand in de beheermap ook voor openbare functies gebruikt.
Configuratie: IP-whitelist plus tweede aanmelding
Onder Nginx kunt u beide voorwaarden combineren. Met satisfy all moet een verzoek uit een vrijgegeven netwerk komen en bovendien de tweede aanmelding doorstaan. Pad, adressen en PHP-doorgave zijn plaatshouders:
location ^~ /backend/ {
satisfy all;
allow 192.0.2.0/24; # bedrijfsnetwerk (plaatshouder)
allow 198.51.100.10; # VPN-uitgang (plaatshouder)
deny all;
auth_basic "Interner Bereich";
auth_basic_user_file /etc/nginx/htpasswd-backend;
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}
De geneste PHP-location is belangrijk: door ^~ worden andere regels voor .php niet meer beoordeeld. Onder Apache bereikt u hetzelfde met een blok waarin beide voorwaarden moeten gelden:
<Location "/backend">
AuthType Basic
AuthName "Interner Bereich"
AuthUserFile /etc/apache2/htpasswd-backend
<RequireAll>
Require ip 192.0.2.0/24 198.51.100.10
Require valid-user
</RequireAll>
</Location>
Het wachtwoordbestand hoort buiten de webroot. De tweede aanmelding verstuurt toegangsgegevens bij elk verzoek, gebruik haar daarom alleen via HTTPS.
Houd vóór elke wijziging een tweede toegangsweg tot de server open, bijvoorbeeld een bestaande SSH-sessie. Wie zichzelf buitensluit, heeft anders de hostingprovider nodig.
De valkuilen: CDN, proxy, IPv6 en thuiswerken
Staat uw website achter een CDN zoals Cloudflare of een load balancer, dan ziet de webserver in eerste instantie alleen de adressen daarvan. Een IP-whitelist zou dan ofwel iedereen blokkeren, ofwel iedereen doorlaten. De webserver moet het echte adres uit een header overnemen, onder Nginx met set_real_ip_from en real_ip_header, onder Apache met mod_remoteip.
Daarbij geldt: accepteer de header alleen van de eigen proxyadressen. Anders kan elke bezoeker een willekeurige herkomst voorwenden. Even belangrijk is dat de oorspronkelijke server niet rechtstreeks bereikbaar is, want anders is de proxy met al zijn regels te omzeilen. Aanwijzingen daarover staan onder Firewall voor webservers.
Twee andere punten worden vaak over het hoofd gezien. Is de server via IPv6 bereikbaar, dan hebben ook de IPv6-adressen van uw netwerk een vermelding nodig, anders staan beheerders met IPv6 voor een blokkade. En particuliere internetaansluitingen wisselen regelmatig van adres. Voor thuiswerken en externe dienstverleners is een VPN daarom meestal de stabielere oplossing.
Zo controleert u of de afscherming werkt
Een regel die niet is getest, geldt niet als doorgevoerd. Controleer vanaf een aansluiting buiten het bedrijfsnetwerk, bijvoorbeeld via het mobiele netwerk:
# Verwacht: 403 (geblokkeerd) of 401 (tweede aanmelding vereist)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Controleer ook PHP-bestanden rechtstreeks, niet alleen de map
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php
Voer daarna dezelfde aanroepen uit vanuit het bedrijfsnetwerk of het VPN: daar moet de pagina bereikbaar zijn. Controleer vervolgens de openbare frontend, dus formulieren, zoekfunctie en winkelwagen. In de logboeken van de volgende dagen horen toegangen tot de beheeradressen vrijwel alleen nog met status 401 of 403 voor te komen.
Was de omgeving tot nu toe open, dan loont een blik op de bestaande accounts. Hoe u onbekende beheerders vindt, beschrijft Vreemde beheeraccounts in CMS en server vinden. Aanvullend remt een bescherming tegen massaal doorproberen, zie Beheerlogins beschermen tegen brute force.
Hoe helpt PHP SOS concreet?
- Wij inventariseren alle beheeradressen van uw websites, panelen en hulpmiddelen en scheiden ze van paden die openbaar nodig zijn.
- Wij kiezen samen met u de passende methode, afhankelijk van teamgrootte, thuiswerken en hosting.
- Wij voeren de regels door in de webserver, houden rekening met CDN, proxy en IPv6 en houden daarbij een terugweg open.
- Wij testen van buiten en van binnen en leveren een korte documentatie met de vrijgegeven netwerken.
De afscherming van beheeromgevingen is onderdeel van onze serverhardening voor PHP-webservers.
Veelgestelde vragen
Is een sterk wachtwoord voor de CMS-login niet genoeg?
Een sterk wachtwoord en tweestapsverificatie zijn verplicht, maar beschermen alleen de aanmelding zelf. Kwetsbaarheden in inlogpagina's, plug-ins of beheerhulpmiddelen blijven voor iedereen bereikbaar. Een afscherming op netwerk- of webserverniveau zorgt ervoor dat buitenstaanders daar niet eens komen.
Wat doe ik als mijn medewerkers wisselende IP-adressen hebben?
Dan is een VPN met een vast uitgaand adres meestal een betere oplossing dan een lijst met losse adressen. Alle beheerders verbinden eerst met het VPN en de webserver geeft alleen dat adres vrij. Als alternatief is een voorgeschakelde tweede aanmelding geschikt.
Werkt een IP-blokkade ook achter Cloudflare of een load balancer?
Alleen als de webserver het echte bezoekersadres overneemt uit een betrouwbare header en die header uitsluitend van de eigen proxy accepteert. Anders ziet hij alleen de adressen van de proxy of vertrouwt hij vervalste gegevens. Bovendien mag de oorspronkelijke server niet rechtstreeks vanaf het internet bereikbaar zijn.
Beschermt een afgeschermde beheeromgeving tegen PHP2Shell?
Slechts in zeer beperkte mate. De PHP2Shell-kwetsbaarheden zitten in de PHP-interpreter en zijn zonder inloggen aan te vallen via elke openbare PHP-pagina. Tegen PHP2Shell helpt de PHP-update met aansluitend een herstart van alle workers; de afscherming verkleint alleen het overige aanvalsoppervlak.