English
Tijdens een pentest vragen wij u om onze IP-adressen te whitelisten voor firewalls, IDS-, IPS- en rate-limiting systemen. Dit stelt onze pentesters in staat om de daadwerkelijke beveiliging van uw applicatie te onderzoeken in de beperkte testperiode. Deze whitelisting is aanbevolen maar niet verplicht.
Wat betekent whitelisting concreet
Voor iedere pentest leveren wij vooraf een lijst met de IP-adressen waarvandaan onze pentesters werken. Wij vragen u deze IP-adressen toe te voegen aan de allowlist op:
- Webserver en firewall. Zorg dat verzoeken van onze IP-adressen niet worden geblokkeerd op basis van rate-limiting of geografische restricties.
- Web Application Firewall (WAF). Uitschakelen of bypassen voor onze IP-adressen zodat aanvalspatronen niet automatisch worden geblokkeerd.
- IDS- en IPS-systemen. Tijdelijk uitschakelen of instellen op log-only mode voor onze verzoeken.
- Rate-limiting op API-endpoints. Verhogen of uitschakelen zodat wij realistische scenario's kunnen testen.
- Hosting provider. Bij externe hosting: informeer uw hosting-partij dat er in de betreffende periode pentesting plaatsvindt.
- CDN (indien van toepassing). Cloudflare, Akamai of vergelijkbaar: WAF-regels en rate-limiting aanpassen voor onze IP-adressen.
Waarom is dit belangrijk
Applicatiebeveiliging bestaat uit twee lagen:
- Primaire beveiligingslaag. De applicatie zelf: authenticatie, autorisatie, input-validatie, session-management, encryptie, business logic. Dit is de kern van uw beveiliging.
- Secundaire beveiligingslaag. Detection- en response-systemen: IDS/IPS, WAF, rate-limiting, DDoS-protectie. Dit is een extra laag die aanvallen kan detecteren en vertragen.
Beide lagen zijn belangrijk, maar de secundaire laag moet aanvullend zijn, niet compenserend. Een aanvaller met voldoende tijd en resources kan IDS/IPS-systemen omzeilen door verzoeken langzamer te versturen, patronen te variëren en detectie-signatures te ontlopen. De echte bescherming moet komen uit de primaire laag.
Tijdens een pentest van 1 tot 4 weken hebben wij niet dezelfde tijd als een reële aanvaller. Zonder whitelisting besteden onze pentesters onnodig veel tijd aan het omzeilen van uw secundaire laag in plaats van het testen van uw primaire laag. Dit levert een minder complete beoordeling op van waar uw echte risico's zitten.
Wat als whitelisting niet mogelijk is
Whitelisting is aanbevolen maar niet vereist. Als het niet mogelijk is (bijvoorbeeld bij shared hosting zonder toegang tot firewall-configuratie), passen wij onze aanpak aan:
- Langzamer testen. Wij versturen minder verzoeken per tijdseenheid om rate-limiting te vermijden. Dit betekent langere doorlooptijd voor dezelfde scope.
- Payload-obfuscatie. Aanpassen van test-payloads zodat WAF-regels niet triggeren. Dit is tijdrovend werk dat afgaat van de kern-testtijd.
- Beperkte test-dekking. Bepaalde tests (bijvoorbeeld brute-force op login, fuzzing van API-endpoints) kunnen niet volledig worden uitgevoerd. Dit resulteert in blinde vlekken in het rapport.
- Bespreken tijdens scope. Wij bespreken vooraf welke tests in beperkte vorm worden uitgevoerd zodat u weet wat de rapportage wel en niet dekt.
Wanneer de whitelisting weer normaliseren
Direct na afronding van de pentest herstelt u de beveiligingslaag naar de reguliere configuratie:
- Verwijder de DongIT IP-adressen uit de whitelist
- Zet IDS/IPS-systemen weer op actieve blocking-mode
- Herstel oorspronkelijke rate-limiting en WAF-regels
- Verifieer dat monitoring en alerting weer volledig werken
Wij informeren u wanneer de laatste testactiviteit is afgerond zodat u dit kunt inplannen.
Meer weten over pentest-voorbereiding? Zie de FAQ over hoe u zich voorbereidt op een pentest. Neem contact op voor een kosteloos scope-gesprek, of bekijk onze pentestpakketten.