Granting access for internal networks

How to temporarily reach a private asset for our pentesters.

To test an asset on a private network, our IPs need to reach it. This guide covers the 4 most common ways to grant access and when to use each.

Option 1: Publish through your load balancer or CDN

The most practical method for anyone who already runs a load balancer, CDN, or reverse proxy in front of their applications. You publish a temporary staging address on that existing ingress and restrict access to HackerSec IPs only, without touching the perimeter firewall and without standing up any new server.

When to use

• You already operate a load balancer, CDN, or reverse proxy (AWS ALB/ELB, Cloudflare, Azure Front Door, CloudFront, nginx, Traefik).
• You want to reuse the infrastructure you already have, without touching the perimeter firewall or standing up a new server.
• The target is a staging web application or API.

What to do

1. Get the HackerSec IPs from Company settings › Network and Firewall tab (after login).
2. Create a temporary, non-obvious hostname (e.g., pentest-a9f3.yourcompany.com) on your load balancer/CDN pointing to the internal staging application.
3. Restrict the origin to HackerSec IPs only (Security Group, NSG, WAF rule, or CDN IP allowlist), for both IPv4 and IPv6.
4. Configure a Skip / Bypass of the content-based WAF rules (SQLi, XSS, RCE, bot detection, rate limiting) for HackerSec IPs during the test.
5. Send the generated URL in the credentials field of the test.

Typical setup time: 30 minutes to 1 hour.

Harden the access

Since the address is public during the test window, we recommend pairing the IP allowlist with: a non-guessable hostname, a per-test secret (a header token or mTLS we validate at the ingress), and a short time window. Remove the rule when the test ends to revoke access immediately.

Option 2: Allow our IPs on the firewall

The most direct method. You add the HackerSec IPs to the firewall rule protecting the asset, and our team reaches the endpoint normally.

When to use

• The asset already has a public IP or URL that can be filtered on the firewall.
• You have access to add firewall rules (on-premises, Cloudflare WAF, AWS security group, Azure NSG, etc.).
• No compliance restriction preventing exposed endpoints.

What to do

1. Get the HackerSec IPs from Company settings › Network and Firewall tab (after login).
2. Access the firewall config that protects the asset.
3. Allowlist both IPs (IPv4 and IPv6) on the firewall. Modern systems use dual-stack, and the request may come via either.
4. Add a rule allowing traffic only from those IPs (inbound, HTTPS or the service-specific port).
5. Optional: add extra auth (mTLS, token header, WAF rule) if the asset is sensitive.
6. Send the asset URL in the credentials field of the test.

Typical setup time: 1 to 4 hours, depending on your infrastructure.

⚠️ Cloudflare and WAFs notice: allowlisting the IP does not disable content-based WAF rules, bot detection, or rate limiting. For the pentest to work fully (including tests with SQLi, XSS, RCE payloads, etc.), also configure a Skip / Bypass rule for these modules for HackerSec's IPs during the test.

After the test

Remove the firewall rule to revoke access. That ends the exposure immediately.

Option 3: Bastion Host (Jump Server)

A dedicated, monitored host inside your network serves as the single entry point. Our pentesters SSH into the bastion and, from there, reach the asset. This is the most classic pattern for compliance because all activity goes through a centralized, auditable point.

When to use

• Your company already has an access policy requiring a jump server (ISO 27001 control A.9, SOC 2, PCI DSS 8.2, GDPR/HIPAA).
• The internal security team needs a full audit trail (session recording, executed commands, file transfers).
• You prefer temporary credentials (a user created just for the pentest) over allowlisting external IPs directly to the asset.
• The asset is in a private VPC/subnet with no internet egress (Cloudflare Tunnel doesn't apply).
• It's the most complete option when the test needs to reach the entire internal network (multiple hosts, Active Directory), not just a single application.

What to do

1. Stand up (or reuse) an SSH-accessible Linux bastion host in a subnet that can reach the target asset.
2. Create a temporary user (e.g., pentest-hackersec) with the SSH public key we'll send you.
3. Get the HackerSec IPs from Company settings › Network and Firewall tab (after login) and allowlist only those IPs on the bastion firewall, on port 22.
4. Send the bastion address, username, and port in the credentials field of the test. If TOTP 2FA is required, include the seed.
5. Recommended: enable session recording (auditd, tlog-rec-session, or tools like Teleport, JumpCloud, AWS Systems Manager Session Manager) for full audit coverage.

Typical setup time: 2 to 6 hours, depending on whether the bastion already exists.

Advantages

• Standard pattern accepted by every compliance framework. Likely already part of your internal policy.
• Granular audit: everything the pentester does on the bastion is logged.
• You have full control of credentials. Just disable the user to revoke access.
• Works even in partially air-gapped environments, where the asset cannot have direct internet access.

After the test

Disable the pentest-hackersec user or remove the public key from authorized_keys. Keep session logs for at least the period required by your compliance (typically 1 to 5 years).

Option 4: Cloudflare Tunnel

Alternative when you can't change the firewall or the asset is on a fully private network with no public IP. A Cloudflare program (cloudflared) runs inside your network and creates a secure tunnel to us, without opening any firewall port.

When to use

• Strict compliance that forbids public endpoints.
• Fully private network (the asset has no public IP).
• Legacy assets that don't work well behind a traditional reverse proxy.
• When you want something quick to set up.

What to do

1. Get the HackerSec IPs from Company settings › Network and Firewall tab (after login).
2. Create a free account at Cloudflare.
3. Install cloudflared on a host inside your network (Linux or Windows). See the official docs.
4. Run cloudflared tunnel create pentest-hackersec and follow the wizard.
5. Configure Cloudflare Access with an allowlist of the HackerSec IPs.
6. Send the generated URL (e.g., https://pentest-hackersec.trycloudflare.com) in the credentials field of the test.

Typical setup time: 30 minutes to 1 hour.

Advantages

• Free on Cloudflare's Free plan.
• Outbound only. No firewall port needs to be opened.
• Accepted by most compliance frameworks (SOC 2, ISO 27001, PCI DSS).
• You terminate the tunnel whenever you want and access is revoked instantly.

Login credentials

Granting network access is separate from providing login credentials. On step 2 of the wizard you choose:

• IP access only: Black Box test authenticated via network, no specific login.
• Login credentials: username/password, token, API key, etc. Gray Box test.

Questions

If you have questions about which option to choose or during setup, talk to your Account Manager. They follow the configuration through until the test starts.