Firewall pentest: zo test je meer dan open poorten

Een firewall pentest onderzoekt of de netwerkgrens, beheerlaag en segmentatie in de praktijk weerstand bieden tegen ongewenste toegang. De tester kijkt verder dan een lijst met open poorten. Ook firewallregels, NAT, VPN, beheerinterfaces, uitgaand verkeer, logging en routes tussen netwerkzones kunnen binnen de scope vallen. Zo ontdek je waar beleid en technische werking van elkaar afwijken.

Deze test past bij organisaties die hun internetperimeter willen toetsen, een netwerkverandering hebben doorgevoerd, segmentatie gebruiken voor gevoelige systemen of bewijs nodig hebben voor een normenkader. Een firewallonderzoek kan zelfstandig plaatsvinden of onderdeel zijn van een bredere pentest.

Wat is een firewall pentest?

Een firewall pentest is een geautoriseerde aanvalstest gericht op de technische werking van firewalls en aangrenzende netwerkbeveiliging. De onderzoeker benadert de omgeving vanuit afgesproken posities. Dat kan vanaf internet zijn, vanuit een gastnetwerk, vanuit een kantoorsegment, via een VPN-account of vanuit een gesimuleerde gecompromitteerde werkplek.

Het doel is geen theoretische beoordeling van een regelbestand. De centrale vraag luidt: welke verbindingen, systemen en beheerfuncties zijn werkelijk bereikbaar, en past dat bij het vastgestelde beleid? Een tester verzamelt bewijs met gecontroleerde scans, handmatige verificatie, routeanalyse en beperkte exploitvalidatie binnen de afgesproken grenzen.

NIST beschrijft firewalls als onderdelen die verkeer tussen netwerken met verschillende beveiligingsniveaus regelen. De publicatie NIST SP 800-41 Rev. 1 behandelt beleid, selectie, configuratie, testen, ingebruikname en beheer. Voor de opzet van technische securitytests biedt NIST SP 800-115 een bruikbaar kader voor planning, uitvoering, analyse en herstel.

Firewall pentest, audit, scan en segmentatietest: wat is het verschil?

De termen worden regelmatig door elkaar gebruikt. Toch beantwoorden ze andere vragen. Een brede opdracht bevat vaak meerdere onderzoeksvormen, zodat documentatie, configuratie en waargenomen gedrag naast elkaar worden gelegd.

Onderzoeksvorm	Centrale vraag	Typische input	Typische uitkomst
Firewall pentest	Kan een aanvaller ongewenste toegang, routevorming of misbruik aantonen?	IP-ranges, testposities, accounts en scopeafspraken	Technisch bewijs van bereikbaarheid en misbruikbaarheid
Firewall configuratiereview	Sluiten regels en instellingen aan op beleid en hardeningrichtlijnen?	Configuratie-export, objecten, zones, changegegevens en architectuur	Bevindingen over regels, beheer, objecten en instellingen
Vulnerability scan	Welke bekende kwetsbaarheden en blootgestelde diensten zijn zichtbaar?	Doeladressen en scannerprofiel	Geautomatiseerde lijst met signalen die verdere validatie vragen
Segmentatietest	Blijven afgescheiden zones vanuit de gekozen testposities werkelijk gescheiden?	Netwerkdiagram, zonebeleid en testhosts per segment	Bewijs van toegestane en geblokkeerde paden tussen zones

Een scanner kan bijvoorbeeld een beheerpoort signaleren. De pentester controleert vervolgens of die poort vanuit de gekozen positie bereikbaar hoort te zijn, welke authenticatie actief is en welk gevolg toegang kan hebben. Lees ook het verschil tussen een pentest en vulnerability scan.

Welke onderdelen kan een firewall pentest onderzoeken?

De juiste scope hangt af van de architectuur en onderzoeksvraag. Eén firewall kan meerdere functies uitvoeren, terwijl grotere omgevingen gebruikmaken van internetfirewalls, interne firewalls, web application firewalls, cloud security groups, VPN-gateways en afzonderlijke beheerplatformen.

1. Externe blootstelling en toegestane diensten

De tester brengt vanaf internet in kaart welke adressen, poorten en protocollen reageren. Daarna volgt handmatige verificatie van diensten die binnen de scope vallen. Het onderzoek richt zich op onverwachte blootstelling, beheerfuncties, oude diensten, testomgevingen, onbedoelde publicaties en verschillen tussen DNS, documentatie en werkelijkheid.

Dit deel overlapt met een externe pentest. Het verschil zit in de nadruk. Bij een firewall pentest staan verkeersbeleid, regelwerking, netwerkzones en de beheerlaag centraal.

2. Firewallregels, objecten en NAT

Firewallregels bepalen bron, bestemming, dienst, actie en vaak aanvullende inspectie. Een review kan zoeken naar brede bron- of bestemmingsgroepen, overlappende regels, verouderde objecten, tijdelijke uitzonderingen, ongebruikte regels en volgorde-effecten. De actieve test controleert vervolgens hoe relevante paden zich gedragen.

NAT verdient een eigen controle. Een vertaling kan een intern systeem naar buiten publiceren, verkeer naar een andere bestemming sturen of de herkomst verhullen. De pentester vergelijkt verwachte publicaties met feitelijke bereikbaarheid en controleert of test-, acceptatie- en beheersystemen via vertalingen zichtbaar zijn geworden.

3. Beheerinterfaces en beheerpad

De beheerlaag vraagt extra aandacht, omdat toegang tot de firewall grote netwerkbevoegdheden kan geven. Het onderzoek kan kijken naar bereikbaarheid, versleuteling, authenticatie, multifactor-authenticatie, beheerdersrollen, bronbeperkingen, sessiebeleid en scheiding tussen regulier gebruikersverkeer en beheer.

CISA neemt geregeld kwetsbaarheden in firewall- en VPN-producten op in de Known Exploited Vulnerabilities Catalog. Dat onderstreept waarom internetbereikbare beheerfuncties, softwareversies en hersteltermijnen apart worden beoordeeld.

4. VPN en toegang op afstand

Veel firewalls verzorgen remote-access- of site-to-site-VPN. De test kan de externe VPN-dienst, authenticatiestroom, MFA, certificaatgebruik, gebruikersrollen, toegewezen netwerktoegang en scheiding na inloggen toetsen. Ook split tunneling, DNS-afhandeling en toegang vanaf beheerde versus onbeheerde apparaten kunnen relevant zijn.

Een VPN-verbinding vormt na succesvolle authenticatie een nieuwe testpositie. Vanuit die positie controleert de onderzoeker welke segmenten en diensten bereikbaar worden. Zo wordt zichtbaar of een regulier account meer netwerktoegang krijgt dan de functie vraagt.

5. Interne segmentatie en east-west-verkeer

Een internetfirewall beschermt de buitenrand. Interne segmentatie beperkt beweging tussen werkplekken, servers, beheerzones, productienetwerken, OT, IoT, gasten en betaalomgevingen. Een tester plaatst of gebruikt testhosts in afgesproken zones en verifieert toegestane en geblokkeerde verbindingen.

Dit onderzoek past vaak binnen een interne pentest of een bredere pentest van het bedrijfsnetwerk. De waarde zit in het aantonen van werkelijke paden. Een netwerkdiagram kan een scheiding tonen, terwijl routing, een beheerregel of een brede servicegroep alsnog verkeer doorlaat.

6. Uitgaand verkeer en egress filtering

Firewallbeleid gaat ook over verkeer dat de organisatie verlaat. Een gecompromitteerd systeem kan externe infrastructuur benaderen, data versturen of aanvullende software ophalen. De test controleert daarom welke protocollen, bestemmingen en poorten vanuit relevante zones naar buiten bereikbaar zijn.

De onderzoeker voert hiervoor vooraf afgesproken, herkenbare en beheersbare tests uit. Denk aan verbindingen vanaf een testhost naar gecontroleerde testinfrastructuur. Het doel is zicht krijgen op toegestane paden en detectie, zonder echte bedrijfsdata te versturen.

7. Logging, detectie en opvolging

Een verbinding blokkeren is één deel van de beveiliging. Het securityteam wil relevante gebeurtenissen ook kunnen herkennen en onderzoeken. Daarom kan de opdracht vastleggen welke testhandelingen in firewalllogs, SIEM, IDS of SOC-processen zichtbaar horen te worden.

Na de test worden tijdstippen en bronadressen naast de logregistratie gelegd. Zo ontstaat antwoord op drie vragen: werd het verkeer vastgelegd, kwam er een bruikbaar signaal en volgde daarop de afgesproken behandeling?

8. Softwareversies, hardening en ondersteunende diensten

De tester kan softwareversies, updatebeleid en blootgestelde ondersteunende diensten beoordelen. Denk aan beheerportalen, API’s, centrale managementservers, authenticatiekoppelingen, DNS, NTP, logging en back-upvoorzieningen. Een kwetsbaarheid in een ondersteunend onderdeel kan dezelfde beheerketen raken.

Versiecontrole vraagt zorgvuldigheid. Een zichtbaar versienummer is een aanwijzing, geen sluitend bewijs. Daarom worden scannerresultaten, banners, configuratiegegevens en gedrag waar mogelijk met elkaar vergeleken.

9. IPv6, cloud-firewalls en hybride omgevingen

Organisaties richten beleid vaak eerst voor IPv4 in. IPv6 kan intussen actief zijn op endpoints, netwerkapparatuur of cloudplatformen. De scope hoort daarom vast te leggen welke IP-protocollen gelden en of gelijkwaardig beleid aanwezig is.

In cloudomgevingen bestaat filtering uit meerdere lagen, zoals security groups, network ACL’s, platformfirewalls, virtuele appliances en route-tabellen. Een firewall pentest kijkt dan naar het complete verkeerspad. Anders blijft een afwijking tussen datacenterbeleid en cloudbeleid buiten beeld.

Hoe verloopt een firewall pentest?

Een sterke aanpak begint met een afgebakende onderzoeksvraag. Daarna volgen technische inventarisatie, uitvoering, analyse en herstelvalidatie. De precieze volgorde verschilt per omgeving, terwijl de onderstaande fasen vrijwel altijd terugkomen.

Stap 1. Doel, scope en Rules of Engagement

Opdrachtgever en tester leggen vast welke firewalls, IP-ranges, zones, accounts en tijdvensters binnen het onderzoek vallen. Ook uitgesloten systemen, toegestane technieken, contactpersonen, stopcriteria, escalatie en omgang met bewijs komen in de afspraken.

De Rules of Engagement beschermen de bedrijfsvoering en geven het onderzoeksteam heldere grenzen. NIST SP 800-115 beschrijft dit document als de afspraken rond uitvoering, bevoegdheden en beperkingen van de test.

Stap 2. Architectuur en verwachte verkeersstromen

De tester bestudeert netwerkdiagrammen, adresschema’s, zone-indeling, publicaties, VPN-stromen en beheerarchitectuur. Bij een white-boxonderzoek kunnen ook configuratie-exports, rule bases en changegegevens worden aangeleverd.

Deze informatie vormt een hypothese: welk verkeer hoort toegestaan te zijn en welk verkeer hoort te worden geblokkeerd? De actieve test toetst die hypothese vanuit meerdere posities.

Stap 3. Inventarisatie en bereikbaarheid

De onderzoeker brengt bereikbare hosts, diensten en netwerkpaden in kaart. Daarbij blijft de snelheid afgestemd op de omgeving. Kwetsbare legacy-apparatuur, industriële systemen en bedrijfskritische verbindingen kunnen een aangepast testprofiel krijgen.

Stap 4. Handmatige verificatie

Geautomatiseerde signalen worden handmatig beoordeeld. De tester controleert herhaalbaarheid, context en het bereikbare vervolgpad. Een open dienst vormt op zichzelf nog geen bevinding als de publicatie bewust, passend afgeschermd en actueel is.

Stap 5. Beperkte exploitvalidatie

Waar de opdracht dit toestaat, toont de pentester met een beheerste handeling aan welk toegangsniveau haalbaar is. De test stopt zodra voldoende bewijs is verzameld of zodra een afgesproken grens wordt bereikt. Productieverstorende technieken vallen buiten de scope, tenzij daar vooraf aparte toestemming en waarborgen voor zijn vastgelegd.

Stap 6. Rapportage en bespreking

Het rapport beschrijft scope, methode, testposities, aannames, bevindingen, bewijs en hersteladvies. Een managementsamenvatting vertaalt technische uitkomsten naar risico’s voor processen en gegevens. Het technische deel helpt netwerk- en securityteams bij herstel.

Bekijk vooraf welke onderdelen je mag verwachten in een voorbeeld van een pentest rapport.

Stap 7. Herstel en hertest

Na aanpassingen verifieert de tester de eerder aangetoonde paden opnieuw. De hertest kijkt niet uitsluitend naar het verdwijnen van één signaal. Ook neveneffecten en alternatieve routes verdienen aandacht. Daarna krijgt iedere bevinding een actuele status met nieuw bewijs.

Black box, grey box of white box?

De gekozen testvorm bepaalt hoeveel voorkennis de pentester ontvangt. Bij firewallonderzoek is een mix vaak waardevol. Een externe black-boxfase toont wat zonder voorkennis zichtbaar is. Een white-boxfase maakt diepere controle van regels, objecten en uitzonderingen mogelijk.

Testvorm	Informatie voor de tester	Sterk bij firewallonderzoek	Aandachtspunt
Black box	Doeladressen en beperkte context	Realistisch beeld van externe blootstelling	Verklaart minder snel waardoor een afwijking ontstaat
Grey box	Gedeeltelijke architectuur, accounts of zone-informatie	Gerichte test van VPN, rollen en segmenten	De aangeleverde context bepaalt mede de dekking
White box	Volledige architectuur, configuraties en beleidsinformatie	Diepe controle van rules, objecten, NAT en beheer	Vraagt actuele documentatie en toegang tot configuraties

Meer achtergrond staat in de uitleg over het verschil tussen een black-box-, grey-box- en white-box-pentest.

Veelvoorkomende bevindingen bij firewallonderzoek

Bevindingen verschillen per netwerk. De onderstaande categorieën komen geregeld terug in omgevingen die jarenlang zijn uitgebreid, gemigreerd of door meerdere teams worden beheerd.

• Onverwachte externe dienst: een beheerportaal, testserver of oude publicatie reageert vanaf internet.
• Te brede regel: een grote bron- of bestemmingsgroep krijgt toegang tot meer systemen of diensten dan bedoeld.
• Verouderde uitzondering: een tijdelijke regel bleef actief nadat het project of onderhoud was afgerond.
• Beheer vanaf gebruikersnetwerk: reguliere werkplekken kunnen beheerinterfaces bereiken.
• Ruime VPN-rechten: een standaardaccount bereikt server- of beheersegmenten buiten de functie.
• Segmentatielek: verkeer tussen zones loopt via een alternatieve route, gedeelde dienst of verkeerde rule.
• Breed uitgaand verkeer: testhosts kunnen via meerdere protocollen onbeperkt externe bestemmingen benaderen.
• Beperkte registratie: relevante testhandelingen ontbreken in logs of bevatten te weinig context voor onderzoek.
• Verschil tussen IPv4 en IPv6: de beoogde blokkade geldt voor één protocol, terwijl het andere protocol verkeer doorlaat.
• Cloud-drift: security groups of routes wijken af van het beleid dat in het datacenter geldt.

Samengesteld praktijkvoorbeeld: segmentatie rond een beheerzone

Onderstaand voorbeeld is samengesteld en beschrijft geen specifieke klant.

Een organisatie gebruikt aparte zones voor medewerkers, servers en beheer. Volgens het netwerkdiagram kan het medewerkersnetwerk geen beheerprotocollen naar de beheerzone sturen. Tijdens de test krijgt de pentester een reguliere testwerkplek en een beheerhost.

De eerste verbindingstests tonen dat directe toegang grotendeels wordt geblokkeerd. Via een gedeelde beheerservice blijkt toch een route naar meerdere apparaten bereikbaar. De oorzaak ligt in een brede servicegroep en een regel die ooit voor migratiewerk is toegevoegd. De logging registreert de verbinding, terwijl het signaal geen opvolging krijgt.

Het herstel bestaat uit het verkleinen van de bron- en bestemmingsgroepen, het scheiden van de gedeelde service, het beperken van beheer tot aangewezen hosts en het toevoegen van detectieregels. De hertest bevestigt dat het oorspronkelijke pad is gesloten en dat een nieuwe testpoging zichtbaar wordt in de monitoring.

Wat staat in een firewall-pentestrapport?

Een bruikbaar rapport helpt zowel besluitvormers als technische beheerders. De lezer hoort te kunnen zien wat is getest, vanuit welke positie, onder welke voorwaarden en met welk resultaat.

• Managementsamenvatting met hoofdconclusies, risico’s en prioriteiten.
• Scope, uitzonderingen, testvensters, testposities en gebruikte accounts.
• Methodiek en beperkingen van het onderzoek.
• Netwerkpaden en systemen die feitelijk bereikbaar bleken.
• Per bevinding: omschrijving, bewijs, risico, reproduceerbaarheid en hersteladvies.
• Relatie met beleid, architectuur of normenkader waar relevant.
• Prioriteitenlijst voor netwerkteam, securityteam en systeemeigenaren.
• Status en bewijs van de hertest.

Vraag daarnaast om een mondelinge bespreking. Een regelwijziging kan gevolgen hebben voor applicaties, beheer en monitoring. Door bevindingen samen door te nemen, kunnen teams herstelwerk plannen zonder de context uit het oog te verliezen.

Wat kan een firewall pentest geen zekerheid geven?

Een pentest is een tijdgebonden onderzoek binnen een afgesproken scope. De uitkomst zegt veel over de geteste configuratie, posities en aanvalspaden op dat moment. Ze vormt geen garantie dat iedere toekomstige aanval wordt tegengehouden.

Wijzigingen na de test kunnen nieuwe paden openen. Ook vallen uitgesloten systemen, niet-aangeleverde cloudomgevingen en onbekende netwerkverbindingen buiten de dekking. Daarom hoort de rapportage aannames en beperkingen zichtbaar te maken. Periodiek beheer, changecontrole, monitoring en nieuwe tests blijven onderdeel van het beveiligingsproces.

Wanneer laat je een firewall pentest uitvoeren?

Een vaste jaarlijkse cyclus kan passend zijn, afhankelijk van risico, regelgeving en veranderingssnelheid. Gebeurtenissen in de infrastructuur geven vaak een sterkere aanleiding dan de kalender.

• Na plaatsing of vervanging van een firewallplatform.
• Na een datacenter-, netwerk- of cloudmigratie.
• Na grote wijzigingen in zones, routing, NAT of VPN.
• Voor ingebruikname van een nieuwe internetdienst of beheeromgeving.
• Na een incident waarbij netwerkgrenzen of beheeraccounts een rol speelden.
• Wanneer PCI DSS, ISO 27001, klantvoorwaarden of intern beleid technisch bewijs vragen.
• Wanneer eerdere scans of audits onduidelijke of tegenstrijdige signalen opleveren.

NIST SP 800-115 benadrukt technische verificatie na veranderingen en herstel. Dat voorkomt dat een configuratiewijziging administratief als afgerond geldt terwijl het netwerkpad anders reageert dan verwacht.

Firewall pentest en compliance

Een pentest ondersteunt compliance door technische werking aantoonbaar te maken. De test vervangt geen volledig audit- of managementsysteem. Wel levert het onderzoek bewijs voor risicoanalyse, herstel, controlewerking en opvolging.

PCI DSS en segmentatie

Organisaties die netwerksegmentatie gebruiken om de kaartgegevensomgeving af te bakenen, horen die scheiding technisch te verifiëren. De PCI Security Standards Council Penetration Testing Guidance beschrijft actieve controle van routes en segmentatiemechanismen, waaronder firewall- en VLAN-regels.

Bekijk voor de bredere context de pagina over een PCI DSS pentest. De precieze vereisten hangen af van de omgeving, validatiemethode en actuele versie van de standaard.

ISO 27001

ISO 27001 vraagt een risicogestuurde aanpak voor informatiebeveiliging. Een firewall pentest kan onderbouwen of geselecteerde netwerkmaatregelen in de praktijk werken en of afwijkingen worden opgevolgd. Lees meer over de plaats van pentesten binnen ISO 27001.

Hoe bereid je een firewall pentest voor?

Een complete voorbereiding vergroot de dekking en verkleint verrassingen tijdens de uitvoering. Verzamel vooraf de informatie die past bij de gekozen testvorm.

• Doel van het onderzoek en belangrijkste bedrijfsprocessen.
• Publieke IP-ranges, domeinen, VPN-eindpunten en cloudaccounts binnen scope.
• Netwerkdiagram met zones, routes, firewalls en beheerverbindingen.
• Overzicht van verwachte toegestane verkeersstromen.
• Testaccounts met passende rollen, inclusief MFA-proces waar van toepassing.
• Configuratie-export en rule base bij een white-boxreview.
• Contactgegevens van netwerkbeheer, security, hosting- en cloudpartijen.
• Onderhoudsvensters, gevoelige systemen, back-upstatus en escalatiepad.
• Bekende uitzonderingen en recente wijzigingen.
• Wensen voor loggingvalidatie, rapportage en hertest.

Stem ook af wie bronadressen van de pentester op allowlists plaatst als dit voor monitoring of een externe beschermingslaag nodig is. Een volledige allowlist kan de test vertekenen. Leg daarom vast welke laag wordt vrijgegeven en welke laag juist onderwerp van onderzoek blijft.

Hoe kies je een partij voor een firewall pentest?

Vraag verder dan een opsomming van scanners en certificaten. De onderzoeksopzet, handmatige verificatie en rapportage bepalen hoeveel bruikbare informatie het traject oplevert.

• Ervaring met netwerkarchitectuur: de tester begrijpt routing, NAT, VPN, zones, cloudnetwerken en beheerketens.
• Duidelijke scope: offerte en plan benoemen testposities, systemen, uitgesloten acties, planning en hertest.
• Handmatige validatie: scanneruitvoer wordt beoordeeld en gekoppeld aan aantoonbare netwerkpaden.
• Veilige werkwijze: de partij bespreekt stopcriteria, gevoelige systemen, communicatie en gegevensverwerking vooraf.
• Bruikbaar rapport: zowel management als beheerders krijgen passende uitleg, bewijs en prioriteiten.
• Transparante beperkingen: aannames en delen buiten scope staan zichtbaar in het rapport.
• Hertest: herstel wordt technisch opnieuw beoordeeld en voorzien van actuele status.

Video: technische achtergrond bij firewall penetration testing

De onderstaande Engelstalige video van PurpleSec laat zien welke onderdelen bij een firewallgerichte pentest aan bod kunnen komen. Bekijk technische demonstraties binnen een geautoriseerde lab- of testomgeving.

Bronnen en methodiek

Deze uitleg is opgebouwd rond gangbare netwerk- en pentestprincipes. Voor technische en procedurele onderbouwing zijn onder meer de volgende bronnen gebruikt:

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy.
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment.
• PCI Security Standards Council, Penetration Testing Guidance.
• CISA Known Exploited Vulnerabilities Catalog.

Auteur: [naam pentester], [functie en relevante certificeringen].
Technische review: [naam reviewer], [functie].
Laatst inhoudelijk bijgewerkt: 17 juli 2026.

Veelgestelde vragen over een firewall pentest

Is een firewall pentest hetzelfde als een externe pentest?

Kan een firewallscanner de pentest vervangen?

Worden firewallregels tijdens de test gewijzigd?

Kan de firewall pentest tijdens kantooruren plaatsvinden?

Hoelang duurt een firewall pentest?

Welke toegang heeft de pentester nodig?

Test een firewall pentest ook de web application firewall?

Is een hertest nodig na herstel?

Hoe vaak hoort netwerksegmentatie te worden getest?

Wat heeft de directie aan een firewall pentest?