fastly-ngwaf

Files (2)

• SKILL.md
• assess_ngwaf_rules.sh · scripts/

SKILL.md (first lines)

# Fastly NGWAF Workspace Audit

Audits NGWAF workspaces to verify critical templated rules are configured and enabled. Use the **fastly-cli** skill to configure rules; this skill identifies gaps.

## Quick Start

The bundled assessment requires Bash, `curl`, `jq`, network access to `api.fastly.com`, and a locally configured `FASTLY_API_KEY` with NGWAF read access.
The manual workflow also requires the `fastly` CLI.
Configure credentials in the user's local environment or CLI configuration.
Never ask the user to paste an API key into chat or print it in command output.

Set `NGWAF_SKILL_DIR` to the absolute directory containing this `SKILL.md`, using the installed skill location supplied by the client.
This is a variable you assign, not a client-provided environment variable.
Run the helper from the user's working directory:

```bash
NGWAF_SKILL_DIR=/absolute/path/to/fastly-ngwaf
bash "$NGWAF_SKILL_DIR/scripts/assess_ngwaf_rules.sh"
```

For manual inspection or partial audits, work through the steps below with the `fastly` CLI.

The CLI ignores `FASTLY_API_KEY`. Its precedence is `--token` > `FASTLY_API_TOKEN` > `fastly.toml` profile > default
stored token. To reuse the script's credential:

```bash
export FASTLY_API_TOKEN="$FASTLY_API_KEY"
```

## Audit Workflow

1. **List workspaces** — verify the account has NGWAF workspaces
2. **Fetch rules per workspace** — retrieve each workspace's rule set
3. **Validate critical signals** — confirm required rules exist and are enabled
4. **Flag gaps and search for uncovered endpoints** — report missing/disabled rules
5. **Check attack traffic against blocked traffic** — confirm enabled rules are actually blocking

### Step 1: List Workspaces

```bash
fastly ngwaf workspace list --json | jq -r '.data[].id'
```

If empty, NGWAF is not configured for this account.

### Step 2: Fetch Rules for a Workspace

```bash
fastly ngwaf workspace rule list --workspace-id "$WORKSPACE_ID" --json
```

Both list commands return `{"data": [...], "meta": {...}}` and cap at 100 items with no flag to raise it. Check
`.meta.total`; above 100, fall back to `GET /ngwaf/v1/workspaces?limit=200` or `.../rules?limit=200`.

`rule list` also takes `--enabled` and `--action` to filter server-side.

### Step 3: Validate Critical Signals

For each workspace, verify these templated rules exist and `enabled` is `true`:

| Category               | Required Signals                                                 |
| ---------------------- | ---------------------------------------------------------------- |
| Login Protection       | `LOGINDISCOVERY`, `LOGINATTEMPT`, `LOGINSUCCESS`, `LOGINFAILURE` |
| Credit Card Validation | `CC-VAL-ATTEMPT`, `CC-VAL-FAILURE`, `CC-VAL-SUCCESS`             |
| Gift Card Validation   | `GC-VAL-ATTEMPT`, `GC-VAL-FAILURE`, `GC-VAL-SUCCESS`             |

Check a specific signal:

```bash
fastly ngwaf workspace rule list --workspace-id "$WORKSPACE_ID" --json \
  | jq '[.data[] | select(.actions[].signal == "LOGINDISCOVERY") | {enabled, id}]'
```

### Step 4: Search for Uncovered Login Endpoints

When `LOGINATTEMPT` is missing or disabled, search recent request logs for login-like traffic the WAF isn't protecting.
No CLI equivalent exists (there is no `fastly ngwaf workspace requests`), so use the API:

```bash
curl -s -H "Fastly-Key: $FASTLY_API_KEY" \
  "https://api.fastly.com/ngwaf/v1/workspaces/$WORKSPACE_ID/requests?limit=100&page=1&q=from%3A-30min%20method%3APOST%20path%3A~%22%2Alogin%2A%22" \
  | jq -r '.data[].path' | sort | uniq -c
```

### Step 5: Check Attack Traffic Against Blocked Traffic

A rule can be present and enabled and still block nothing when the workspace mode overrides it. `requests_attack` is
what NGWAF flagged; `requests_total_blocked` is what it stopped. Attacks above zero with nothing blocked means the
workspace is in `log` or `off` mode. Report it even when every rule checks out.

```bash
fastly ngwaf workspace time-series get --workspace-id "$WORKSPACE_ID" \
  --from=2026-08-01T00:00:00Z --to=2026-08-08T00:00:00Z \
  --metrics=requests_total,requests_attack,requests_total_blocked \
  --granularity=86400 --json \
  | jq -r '.data[] | "\(.timestamp)  total=\(.requests_total)  attack=\(.requests_attack)  blocked=\(.requests_total_blocked)"'
```

Across every workspace at once, grouped by workspace:

```bash
fastly ngwaf time-series list \
  --from=2026-08-01T00:00:00Z --to=2026-08-08T00:00:00Z \
  --metrics=requests_total,requests_attack \
  --granularity=86400 --dimensions=workspaces --json \
  | jq -r '.data[] | "\(.dimensions.workspace)  \(.dimensions.time)  \(.values | add)"'
```

The workspace-level subcommand is `get`, the account-level one is `list`. They differ in three ways that break audit
scripts:

- Output shape. `get` returns flat objects keyed by metric with a `timestamp`. `list` nests them under `dimensions`
  and a `values` array, hence `.values | add`.
- Bucket size. The CLI only sends `--granularity` when passed; `get` then buckets hourly and `list` daily. Always
  pass it.
- Zeroes. `get` reports a quiet metric as `0`. `list` drops it from `values`, and returns
  `{"data":[],"meta":{"total":0}}` when nothing recorded. A missing key means zero, not an error.

Read `requests_total_blocked` through `get`. A workspace that blocked nothing is the case this audit is looking for,

From fastly/fastly-agent-toolkit, MIT.

More from fastly/fastly-agent-toolkit