Nederlands
During a pentest we ask you to whitelist our IP addresses for firewalls, IDS, IPS and rate-limiting systems. This allows our pentesters to investigate the actual security of your application within the limited test period. This whitelisting is recommended but not required.
What whitelisting means concretely
For every pentest, we provide in advance a list of the IP addresses from which our pentesters will operate. We ask you to add these IP addresses to the allowlist on:
- Web server and firewall. Ensure requests from our IP addresses are not blocked based on rate-limiting or geographic restrictions.
- Web Application Firewall (WAF). Disable or bypass for our IP addresses so attack patterns are not automatically blocked.
- IDS and IPS systems. Temporarily disable or set to log-only mode for our requests.
- Rate-limiting on API endpoints. Increase or disable so we can test realistic scenarios.
- Hosting provider. If externally hosted: inform your hosting partner that pentesting is taking place during the given period.
- CDN (if applicable). Cloudflare, Akamai or similar: adjust WAF rules and rate-limiting for our IP addresses.
Why is this important
Application security consists of two layers:
- Primary security layer. The application itself: authentication, authorization, input validation, session management, encryption, business logic. This is the core of your security.
- Secondary security layer. Detection and response systems: IDS/IPS, WAF, rate-limiting, DDoS protection. This is an additional layer that can detect and slow down attacks.
Both layers matter, but the secondary layer should be additive, not compensating. An attacker with sufficient time and resources can bypass IDS/IPS systems by sending requests more slowly, varying patterns and evading detection signatures. The real protection must come from the primary layer.
During a pentest of 1 to 4 weeks, we do not have the same time as a real attacker. Without whitelisting, our pentesters spend excessive time bypassing your secondary layer instead of testing your primary layer. This results in a less complete assessment of where your real risks lie.
What if whitelisting is not possible
Whitelisting is recommended but not required. If it is not possible (for example on shared hosting without access to firewall configuration), we adjust our approach:
- Slower testing. We send fewer requests per time unit to avoid rate-limiting. This means a longer lead time for the same scope.
- Payload obfuscation. Adjusting test payloads so WAF rules do not trigger. This is time-consuming work that reduces core testing time.
- Limited test coverage. Certain tests (for example brute-force on login, fuzzing of API endpoints) cannot be fully performed. This results in blind spots in the report.
- Discussion during scoping. We discuss in advance which tests will be performed in limited form so you know what the report will and will not cover.
When to restore whitelisting
Immediately after the pentest is completed, restore the security layer to its regular configuration:
- Remove DongIT IP addresses from the allowlist
- Set IDS/IPS systems back to active blocking mode
- Restore original rate-limiting and WAF rules
- Verify that monitoring and alerting are fully operational again
We notify you when the last test activity has been completed so you can schedule this.
Learn more about pentest preparation? See the FAQ on how you prepare for a pentest. Contact us for a complimentary scoping conversation, or view our pentest packages.