Stel dat uw webserver morgen wordt gecompromitteerd. Welke andere apparaten kan hij dan bereiken? Dat bepaalt mede of een incident tot één dienst beperkt blijft of ook andere delen van het bedrijf bedreigt. Een patch beschermt tegen een bekende kwetsbaarheid. Een goed ontworpen netwerk beperkt daarnaast de mogelijke gevolgen.
Ons voorbeeld is een fictief klantenportaal: mensen melden zich aan, bekijken bestellingen en downloaden documenten. De toepassing heeft een afgebakende databaseverbinding nodig. Dat betekent niet dat zij ook toegang nodig heeft tot het beheer van de NAS, de back-upserver of de virtualisatiehost. Dat onderscheid moet technisch worden afgedwongen.
Een gecompromitteerde dienst gebruikt de beschikbare paden
Een kwetsbaarheid kan ervoor zorgen dat ongewenste code draait met de rechten van de webtoepassing. Wat daarna mogelijk is, hangt onder meer af van netwerkregels, serviceaccounts, opgeslagen inloggegevens en andere kwetsbaarheden. Bereikbaarheid betekent nog geen geslaagde toegang. Een gecompromitteerde webserver neemt ook niet automatisch het hele LAN over.
Het risico neemt toe wanneer bereikbare interne diensten samengaan met te ruime rechten. Een aanvaller hoeft dan minder grenzen te passeren. Deze mogelijke verspreiding naar andere systemen heet laterale beweging. Bij het ontwerp is het daarom nuttig uit te gaan van een toepassing die al gecompromitteerd is.
Netwerk A: het portaal staat in een vlak bedrijfsnetwerk
In de eerste opzet delen het portaal, de database, bestandsopslag en beheerinterfaces één netwerk. De perimeterfirewall beperkt weliswaar inkomende verbindingen, maar intern bestaan ruime toegangsregels of ontbreekt voldoende scheiding. Daardoor kan de webserver meer systemen bereiken dan nodig is voor zijn taak.
Een gedeeld beheerdersaccount verergert de situatie. Hetzelfde geldt voor een gekoppelde back-upmap met schrijfrechten of krachtige inloggegevens in de toepassingsmap. Een werkende back-up helpt maar beperkt als de gecompromitteerde dienst ook het beheer ervan of alle back-upkopieën kan wijzigen.
Netwerk B: zones en regels beperken verbindingen
In de tweede opzet komt internetverkeer eerst bij een afgebakende frontend of reverse proxy. Die mag de benodigde toepassing in een apart websegment benaderen. De toepassing krijgt alleen de noodzakelijke verbinding naar een vastgelegde databasedoelhost. Beheer, back-ups en andere interne diensten bevinden zich in afzonderlijke zones; onnodige toegang vanuit het websegment wordt geblokkeerd.
Een VLAN verdeelt een netwerk logisch. De controle op verbindingen bepaalt of dat een effectieve beveiligingsgrens vormt. Te ruime routing tussen VLAN’s verbindt de gescheiden netwerken grotendeels weer met elkaar. Ook binnen een VLAN kan aanvullende filtering tussen afzonderlijke workloads nodig zijn.
OPNsense of Sophos Firewall zijn mogelijke platforms voor passende regels, net als andere geschikte producten. Het gaat om concrete bronnen, bestemmingen, diensten, verantwoordelijkheden en een gecontroleerde uitvoering. De bediening en beschikbare functies verschillen per platform. Een productnaam beschrijft op zichzelf geen geteste beveiligingsarchitectuur.
Reverse proxy en WAF blijven onderdelen van de beveiliging
Een reverse proxy kan openbare toegang bundelen, TLS-verbindingen afhandelen en verzoeken gericht naar backends sturen. HAProxy ondersteunt daarvoor onder meer HTTP- en TCP-modi. Dat betekent geen algemene proxyfunctie voor elk willekeurig protocol. Een vooraf geplaatste web application firewall kan bepaalde schadelijke webverzoeken herkennen en weigeren.
Deze componenten vervangen geen veilige toepassingen, tijdige updates of beperkte backendtoegang. Verkeerde regels of een andere bereikbare ingang kunnen beschermingsmaatregelen omzeilen. Daarom mag in het voorbeeld ook een toepassing die achter de proxy wordt gecompromitteerd alleen de uitdrukkelijk benodigde bestemmingen bereiken.
Bekijk ook uitgaand en intern verkeer
De belangrijkste vraag is niet alleen wie de webserver mag benaderen. Naar welke bestemmingen mag de server zelf verbindingen opzetten? Kan hij het beheer van de NAS bereiken? Moet hij willekeurige internetbestemmingen kunnen benaderen? Welke interne diensten hebben andere containers werkelijk nodig?
Bij uitgaand verkeer, of egress, horen onder meer naamresolutie, tijdsynchronisatie, updates en externe koppelingen in het plan. Noodzakelijke bestemmingen worden gericht toegestaan. Communicatie tussen interne systemen, vaak oost-westverkeer genoemd, heeft eveneens duidelijke regels nodig. IPv6 en alternatieve routes moeten dezelfde beoogde scheiding respecteren.
Een verbindingsplan legt bron, bestemming, vereiste dienst, doel en verantwoordelijke vast. Vervolgens worden toegestane en geblokkeerde paden gecontroleerd getest. Logging en monitoring moeten onverwachte geslaagde verbindingen en verdachte geblokkeerde pogingen zichtbaar maken. Een regel waarvan de werking niet is gecontroleerd, is nog geen betrouwbaar bewijs.
VM’s en containers hebben passende grenzen nodig
Een virtuele machine heeft een eigen gastbesturingssysteem; containers delen doorgaans de kernel van hun host. Beide modellen vragen om passende netwerk- en rechteninstellingen. Proxmox VE biedt firewallregels voor hosts en gasten. Welke lagen en functies daadwerkelijk werken, hangt ook af van de firewallbackend en de concrete activering.
Bij Docker kunnen containers op hetzelfde bridgenetwerk met elkaar communiceren. Uitgaande verbindingen zijn niet automatisch beperkt tot openbare bestemmingen. Gepubliceerde poorten kunnen extra ingangen creëren. In de hostnetwerkmodus delen containers de netwerknaamruimte van de host; daar bestaat dus geen afzonderlijke netwerkisolatie.
Extra privileges, onnodige hostmounts en toegang tot de Docker-socket kunnen de gevolgen van een incident aanzienlijk vergroten. Gescheiden toepassingsnetwerken, minimale rechten, passende hostfirewallregels en gecontroleerde DNS- en egresspaden horen daarom bij elkaar. Ook hier is de werkelijk toegepaste configuratie doorslaggevend.
Een behapbaar begin voor kleinere bedrijven
- Diensten inventariseren: openbare toepassingen, afhankelijkheden en verantwoordelijke personen documenteren.
- Zones vastleggen: openbare workloads, gegevens, beheer en back-ups scheiden naar beveiligingsbehoefte.
- Verbindingen onderbouwen: alleen vastgelegde bronnen, bestemmingen en diensten toestaan; de rest blokkeren waar dat operationeel passend is.
- Beheer beveiligen: vertrouwde toegangspaden, geschikte VPN- en MFA-methoden en afzonderlijke accounts gebruiken.
- Beheerprocessen meenemen: updates, centrale logging, waarschuwingen en onafhankelijk beveiligde back-ups met geteste herstelprocedures plannen.
- Werking aantonen: regels regelmatig controleren, uitzonderingen een einddatum geven en na wijzigingen opnieuw testen.
Wijzigingen vragen voorbereiding, een geschikt onderhoudsvenster en een terugvalmogelijkheid. Een algemene blokkade kan legitieme toepassingen of uw eigen beheerstoegang onderbreken. Breng daarom eerst afhankelijkheden in kaart, voer de wijziging gecontroleerd uit en laat de bedrijfsfuncties samen met de verantwoordelijken controleren.
Eén gecompromitteerde toepassing hoeft niet het hele netwerk te bedreigen
De PHP2Shell-artikelen over reageren op PHP-kwetsbaarheden en inventariseren met AI-ondersteuning vormen de actuele aanleiding. De aanvullende controle van NAS, Docker en openbare diensten leidt tot een blijvende architectuurvraag: welke verbindingen en rechten heeft elke dienst echt nodig?
DAXS ondersteunt inventarisatie, communicatieplanning, implementatie en aantoonbaar beheer. Of de toepassing lokaal, in een private cloud of op een openbaar cloudplatform draait: de beveiligingsgrenzen moeten bij de werkelijke behoefte passen. Laten we uw concrete omgeving bespreken.
Bronnen: OPNsense: regels en stateful filtering · Sophos Firewall: zones, regels en logging · HAProxy: HTTP- en TCP-modi · Docker: bridgenetwerken · Docker: hostnetwerkmodus · Docker: daemon, rechten en beveiligingsgrenzen · Proxmox VE: firewalldocumentatie · NCSC: verspreiding beperken en beheer en back-ups beschermen.
