# How to Configure Network Profiles for Authorized Pentest Scoping > Learn to configure network profiles for authorized pentest scoping by setting restrictive modes in scope.md. Ensure valid boundaries for secure testing. - Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill) - Tags: how-to-guide - Published: 2026-09-01 --- **Configuring network profiles for authorized pentest scoping requires setting one of four restrictive modes in the `work//scope.md` file to define permissible network boundaries, which the `case-guard` script validates against [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md) gate logic before allowing any active testing.** The `zhaoxuya520/reverse-skill` repository treats network profiles as immutable contracts that prevent unauthorized interaction with production systems. When you configure network profiles for authorized pentest scoping correctly, you create a "hard gate" that the framework enforces before any active scanning, exploitation, or hooking (ACT) can execute. ## Why Network Profiles Act as the Hard Gate According to the security rules defined in [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md) (lines 99-100), **no ACT may occur** unless the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file declares an `auth.status` of `granted` alongside a valid `network_profile.mode`. This design ensures that operators cannot accidentally execute exploits against unintended targets. The [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) template defines this relationship, making the network profile section (lines 65-71) mandatory for case initialization. ## The Four Network Profile Modes When you configure network profiles for authorized pentest scoping, you must select exactly one mode that matches your engagement environment. Each mode creates specific allowlists and blocklists for network traffic: - **`offline`**: Permits only pure static analysis, local samples, and isolated emulation. **Prohibits** all outbound traffic, public RPC calls, and Internet access. - **`lab_only`**: Restricts activity to lab or CTF sandbox IP ranges only. **Prohibits** any access to production environments or unauthorized external IPs. - **`authorized_target_only`**: Allows interaction exclusively with assets listed under `in_scope.assets` in the contract. **Prohibits** any asset not explicitly enumerated in the scope file. - **`unrestricted_lab`**: Permits isolated experimental lab environments with written authorization. **Prohibits** direct access to production Internet services. Selecting the wrong mode triggers a hard stop in the `case-guard` validation layer, preventing workflow progression. ## Step-by-Step Configuration Guide ### Initialize the Case with case-init First, generate the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file from the canonical template using the platform-native initializer. This creates `work//scope.md` pre-populated with the `network_profile` section at lines 65-71. On Windows: ```powershell powershell -NoProfile -ExecutionPolicy Bypass -File skills\scripts\case-init.ps1 -Hint "" -CaseName "my-case" ``` On Linux, macOS, or Kali: ```bash bash skills/scripts/case-init.sh --hint "" --case-name "my-case" ``` Both scripts copy the template from [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) into your working directory. ### Edit the network_profile Section Open [`work/my-case/scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/work/my-case/scope.md) and locate the `## network_profile` section. Set the `mode` key to one of the four allowed values and add clarifying notes. For a lab-only engagement: ```markdown ## network_profile - mode: lab_only - notes: | Only the internal CTF lab subnet (10.10.0.0/16) is reachable. No external Internet access is permitted. ``` For targeted assessments against specific assets, use `authorized_target_only` and reference the `in_scope.assets` list defined elsewhere in the file. ### Validate with case-guard Before executing any ACT, run the validation script to verify the hard gate requirements: ```bash case-guard check --case my-case ``` The `case-guard` script performs three critical checks: - Verifies `auth.status` equals `granted` (or valid offline consent). - Confirms `network_profile.mode` is set and valid. - Prevents `unrestricted_lab` mode when targeting production environments. If validation fails, the workflow stops immediately and outputs the specific constraint violation. ### Execute the Pentest Once `case-guard` returns `✅ auth.status=granted, ✅ network_profile.mode selected, ✅ ready_for_act=true`, mark `signoff.ready_for_act` as `true` in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) and proceed with active testing. ## Network Profile Configuration Examples The [`examples/ctf-demo/scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/examples/ctf-demo/scope.md) file demonstrates a production-ready configuration. For a targeted web application test: ```yaml # work/webapp-pentest/scope.md ## network_profile - mode: authorized_target_only - notes: | Allowed to interact only with the following in-scope assets: - 192.168.10.5 (web server) - api.example.com (API endpoint) All other network traffic is blocked by the case-guard. ``` For malware analysis in air-gapped environments: ```yaml ## network_profile - mode: offline - notes: | Strictly static analysis and local emulation. Zero outbound connections permitted. ``` ## Summary - The `network_profile` in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) serves as the mandatory boundary controller enforced by [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md) gate logic. - Four modes exist: `offline`, `lab_only`, `authorized_target_only`, and `unrestricted_lab`, each with specific traffic restrictions. - The `case-init` scripts (`skills/scripts/case-init.ps1` and [`skills/scripts/case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-init.sh)) generate the template from [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md). - The `case-guard` script validates `auth.status` and `network_profile.mode` before allowing any ACT operations. - Configuration changes must be committed to `work//scope.md` before the pentest begins. ## Frequently Asked Questions ### What happens if I omit the network_profile.mode setting? The `case-guard` validation will fail and block all ACT operations. According to [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md) lines 99-100, the workflow hard-stops when the network profile mode is undefined or invalid, preventing any active scanning or exploitation from executing. ### Can I switch modes after starting the engagement? Yes, but you must re-run `case-guard check` after editing `work//scope.md`. The framework reads the `network_profile` configuration dynamically; however, changing from a restrictive mode like `offline` to `authorized_target_only` requires re-verification of `auth.status` to prevent scope creep. ### When should I use authorized_target_only versus lab_only? Use **`authorized_target_only`** when testing specific production or staging assets listed in `in_scope.assets`, as it restricts interaction to explicitly enumerated IPs and domains. Use **`lab_only`** when working in CTF environments or sandboxed subnets where you control the entire network range but want zero access to external corporate resources. ### How does the framework enforce these network restrictions? The enforcement occurs in two layers: the `case-guard` script performs pre-flight validation of the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) contract, while the [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md) gate logic provides the final check before any ACT module executes. This dual-layer approach ensures that even if manual validation is bypassed, the routing rules will halt unauthorized network activity.