alibabacloud-ddos-origin-exposure-detector

Anti-DDoS Proxy Origin Cloud IP Exposure Risk Detection

Detects whether a website that has onboarded Alibaba Cloud Anti-DDoS Proxy (ddoscoo) still has its origin server IP exposed on the public Internet and directly attackable by bypassing Anti-DDoS.

This skill is distilled from real support tickets: many customers "onboarded Anti-DDoS but the origin still gets bandwidth-saturated / black-holed", with the root cause being an exposed origin IP whose traffic bypasses Anti-DDoS.

Detection Scenarios (two classes, binary verdict, no grading)

S1 was originally two scenarios (A1/A2); since their judgment signal is identical ("does the resolution result hit the origin IP"), they were merged into a single DNS-layer check. S1 and S2 are independent: S1 checks "does the current DNS bypass Anti-DDoS", S2 checks "is the origin locked down against the public Internet". Even if DNS points correctly (S1 miss), if the origin has no access control and is directly reachable (S2 hit), an attacker can still obtain the origin IP via historical resolution / certificate transparency and bypass Anti-DDoS. So both must be checked.

Only two possible verdicts:

• "Exposure risk found" + matched scenarios (S1 / S2, one or both) + affected domains / origin IPs + recommended actions
• "No exposure risk detected for now"

Architecture (products and APIs involved)

Anti-DDoS Proxy (ddoscoo) DescribeInstances + DescribeWebRules + DescribeNetworkRules -> choose one of two probe methods: CloudMonitor (Cms) CreateInstantSiteMonitor -> DescribeSiteMonitorLog (cloud probe, recommended) or local dig / curl / nc (local probe).

[MUST] Disclosure: Before this skill runs for real, you MUST clearly tell the user which product APIs will be called and their purpose, let the user choose the probe method, and only proceed after the user acknowledges.

1. Read Anti-DDoS configuration (always used, read-only)

• Anti-DDoS Proxy (ddoscoo) DescribeInstances: read-only, confirm whether the account has any new BGP Anti-DDoS instances (stop early if none).
• Anti-DDoS Proxy (ddoscoo) DescribeWebRules: read-only, get layer-7 domain onboarding protected domains, Anti-DDoS CNAME, origins (IP or domain), and protocol/ports.
• Anti-DDoS Proxy (ddoscoo) DescribeNetworkRules: read-only, get layer-4 port-onboarding forwarding rules (forward port, origin IP, protocol). These form the data basis for S1/S2.

2. Probe method (user chooses one)

• Method 1 — Cloud probe (recommended): use CloudMonitor (Cms) CreateInstantSiteMonitor to create a one-off probe task and DescribeSiteMonitorLog to read per-probe-point details, performing DNS resolution (S1) and direct HTTP/TCP probing of origin IP:port (S2) from multiple public probe points. Pros: multi-region multi-ISP perspective, closer to real public access; Prerequisite: the site-monitor service must be activated (pay-as-you-go, incurs cost); if not activated, the API fails.
• Method 2 — Local machine probe: use the local machine running this skill to run dig (DNS resolution, S1), curl (HTTP direct connect with Host header bound, S2 layer-7), nc/curl (TCP connectivity, S2 layer-4). Pros: zero cost, no service activation needed; Limitation: single network egress perspective only, may be affected by local network/firewall.
• Auto fallback: if the user picks Method 1 but CreateInstantSiteMonitor fails because the service is not activated (API unreachable), automatically fall back to Method 2 local probe and inform the user "cloud probe service not activated, automatically switched to local probe".

Note: all of the above are read-only queries or one-off side-effect-free probes (public probing / local probing); no customer configuration is modified and no persistent monitoring task is created.

Local tools (common to both methods): when the origin is a domain (RsType=1), resolve it to an IP locally with dig +short before probing (avoids consuming cloud probes and avoids resolving too many IPs that complicate probing).

---

RAM Policy

The RAM permissions required by the APIs this skill uses are listed in references/ram-policies.md. The core ones are: yundun-ddoscoo:DescribeInstances, yundun-ddoscoo:DescribeWebRules, yundun-ddoscoo:DescribeNetworkRules, cms:CreateInstantSiteMonitor, cms:DescribeSiteMonitorLog.

[MUST] Permission Failure Handling: When any command or API call fails due to permission errors at any point during execution, follow this process:

1. Read references/ram-policies.md to get the full list of permissions required by this SKILL
2. Use ram-permission-diagnose skill to guide the user through requesting the necessary permissions
3. Pause and wait until the user confirms that the required permissions have been granted

Parameter Confirmation

IMPORTANT: Parameter Confirmation — Before executing any command or API call, ALL user-customizable parameters (e.g., RegionId, instance names, domain names, origin IPs, probe agent selection, etc.) MUST be confirmed with the user. Do NOT assume or use default values without explicit user approval.

---

Observability (MUST follow for every aliyun command)

Upon loading this skill, generate a random session ID (32-char lowercase hex string) once for the entire session. Use it as {session-id} below.

Rule: Every aliyun CLI command that calls a cloud API MUST include the --user-agent flag. Local utility commands (e.g. configure, plugin, version) do not support this flag and should be excluded.

--user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id}

Example (assuming session-id is a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6):

aliyun ddoscoo describe-web-rules --region cn-hangzhou --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

Do not skip, alter the format, or omit --user-agent on any aliyun API command invocation.

---

Core Workflow

🚨 Absolute execution order: Step 0 disclosure → user confirms (or default applied) → Step 0.5 env pre-checks → Step 1 instance query. ANY aliyun command before Step 0 completes invalidates the session — restart from scratch.

IMPORTANT: Parameter Confirmation — Before executing any command, you MUST confirm RegionId, the target Domain/InstanceIds, and other parameters with the user; do not silently use defaults.

[MUST] Step 0 is a non-bypassable hard gate: you must NOT run any aliyun CLI command or API call (including describe-instances, and also including environment pre-checks like aliyun version, aliyun configure list/get, aliyun plugin list/update) until you have output the Step 0 disclosure (APIs to be called + probe-method options with cost/perspective + requested confirmation of RegionId/ProbeMode). If the user gives no reply or replies without selecting, apply the Step 0 default (cloud probe) and state it explicitly — but the disclosure text must still be produced first. Even if the user prompt explicitly names a specific tool or API (e.g., "Use Cms to probe origin server", "Use dig to check DNS resolution", "Call DescribeWebRules to get protected domains", "Invoke CreateInstantSiteMonitor", "Use nslookup/telnet/HTTP..."), you MUST still produce the full Step 0 disclosure BEFORE executing any command. Do NOT interpret a tool-named prompt or an "environment check" intent as implicit consent to skip Step 0; the disclosure text is always output first. Skipping Step 0 invalidates the entire detection and must be restarted.

Step 0 — Disclose API purpose, choose probe method, and confirm parameters

1. Explain to the user which product APIs will be called (see "Disclosure" above), and confirm RegionId (mainland cn-hangzhou / non-mainland ap-southeast-1) and the detection scope.
2. Let the user choose the probe method (recorded as ProbeMode):
   • Method 1 — Cloud probe (recommended, default): multiple public probe points, broader perspective; requires the site-monitor service activated, pay-as-you-go incurs cost.
   • Method 2 — Local machine probe: use local dig/curl/nc, zero cost, no service activation; single network egress perspective only.
   • Clearly state: if Method 1 is chosen but the service is not activated, causing CreateInstantSiteMonitor to fail, it will automatically fall back to local probe.
   • [MUST] Default when the user does not answer: if the user gives no explicit probe-method choice (empty reply, or proceeds without selecting), default to Method 1 (cloud probe) and tell the user: "No probe method selected; defaulting to cloud probe (multi-location perspective, pay-as-you-go). Reply local to switch to local probing." Do not silently pick local probing when the user has not confirmed.

Step 0.5 — Environment pre-checks (MUST run ONLY after Step 0 disclosure is complete and acknowledged)

Run these checks now. If any fails, pause and ask the user to fix before continuing to Step 1.

1. CLI version: aliyun version — must be >= 3.3.3. If not: /bin/bash -c "$(curl -fsSL --connect-timeout 10 --max-time 120 https://aliyuncli.alicdn.com/setup.sh)" or aliyun upgrade (CLI >= 3.3.5). See references/cli-installation-guide.md.
2. Plugin auto-install: aliyun configure set --auto-plugin-install true, then aliyun plugin update.
3. Credentials: aliyun configure list — confirm a valid profile (AK/STS/OAuth). NEVER read/echo/print AK/SK values; NEVER ask the user to input credentials in conversation. If no valid profile: stop, ask user to configure credentials outside this session, then re-run.

Step 1 — Instance existence check (early-stop gate) First confirm whether the account has any new BGP Anti-DDoS instances.

aliyun ddoscoo describe-instances \
  --region cn-hangzhou \
  --page-number 1 \
  --page-size 10 \
  --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id}
# [MUST] describe-instances --page-size range is 1~50; describe-web-rules/describe-network-rules cap at 10 (over 10 raises InvalidPageSize). When there are many instances, paginate with --page-number to fetch all.

• Instances empty / TotalCount=0 → stop detection immediately and output: "No Anti-DDoS instance found: no new BGP Anti-DDoS instance was found under `` for this account; there is nothing to detect. Please confirm the RegionId (mainland cn-hangzhou / non-mainland ap-southeast-1) is correct, or whether the account has activated Anti-DDoS Proxy." Do not proceed to later steps.
• Instances exist → record the InstanceId list (only used in Step 2 for the per-instance layer-4 describe-network-rules query; the layer-7 describe-web-rules is queried region-wide and does not use an instance filter), then proceed to Step 2 to read forwarding configuration.

Step 2 — Read forwarding configuration (shared data basis for S1/S2, layer-7 + layer-4)

(2a) Layer-7 domain onboarding — DescribeWebRules returns, for each protected domain: the Anti-DDoS CNAME Cname, origins RealServers[] (with RsType: 0=IP, 1=domain + RealServer value), and protocol/ports ProxyTypes[] (ProxyType=http/https/websocket… + ProxyPorts[]).

# [MUST] Query region-wide and fetch all: read TotalCount from page 1, then paginate by TotalCount to fetch every page
aliyun ddoscoo describe-web-rules \
  --region cn-hangzhou \
  --page-number 1 \
  --page-size 10 \
  --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id}
# Only add --domain "www.example.com" when narrowing to a single domain

[MUST] Layer-7 domains MUST be fetched in full region-wide; NEVER filter with --instance-ids:

• Do not filter describe-web-rules with --instance-ids — in practice this filter causes massive under-collection (an account had 35 real domains in a region, but per-instance querying with --instance-ids returned only 7, missing 80%). describe-web-rules already returns all website rules in the region, so querying by region without an instance filter is what is complete. The goal is "all exposure surface in the whole region", so there is no need — and no reason — to split by instance.
• [MUST] Fetch-completeness check: read TotalCount from the page-1 response, compute the number of pages needed (ceil(TotalCount/10)), fetch every page with --page-number N, and finally verify the cumulative fetched WebRules count == TotalCount. If they differ, you must re-fetch or warn. Never proceed after fetching only page 1 (--page-size cap is 10; fetching one page misses all subsequent domains when TotalCount>10).

(2b) Layer-4 port onboarding — for each InstanceId, call DescribeNetworkRules to get port forwarding rules: FrontendPort (forward port), BackendPort (origin port), Protocol (tcp/udp), RealServers (origin IP list), IsAutoCreate (the hard flag indicating whether it was auto-generated by website onboarding, see exclusion note below).

aliyun ddoscoo describe-network-rules \
  --region cn-hangzhou \
  --instance-id "ddoscoo-cn-xxxxxxxx" \
  --page-number 1 \
  --page-size 10 \
  --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id}
# [MUST] --page-size cap is 10; read TotalCount on page 1, paginate by ceil(TotalCount/10) with --page-number N to fetch all, and verify cumulative fetched count == TotalCount; re-fetch if mismatch

[MUST] Exclude "website-onboarding auto-generated" layer-4 rules (otherwise you get false probes/verdicts): when configuring layer-7 website business, Anti-DDoS auto-generates same-port layer-4 TCP forwarding rules based on the website's server ports (in the console such a rule has an exclamation-mark icon next to "forward protocol", cannot be manually edited/deleted, and disappears automatically when the website config is unbound). The RealServers of these auto-generated rules are Anti-DDoS internal layer-7 forwarding/back-to-origin cluster IPs, not the user's real origin IP; doing S2 layer-4 probing against them is both meaningless and produces false positives (you probe the Anti-DDoS cluster, not the origin).

• Identification (preferred: hard flag): each rule returned by DescribeNetworkRules includes an IsAutoCreate field (corresponding to the console's exclamation mark). IsAutoCreate=true means it is a website-onboarding auto-generated rule — the only auto-creation source of a layer-4 rule is layer-7 website onboarding, so this field can directly and reliably decide it; prefer it.
• Fallback criterion (when IsAutoCreate is missing/unavailable): if a layer-4 rule's Protocol+FrontendPort matches the server port used by some DescribeWebRules domain under the same instance → it is an auto-generated rule for that website (same instance + same protocol + port must be unique; once a website occupies a port, the corresponding layer-4 rule is auto-generated and the user cannot manually create a same-port rule, so a port collision is sufficient to decide; this criterion is region-independent). Note: do NOT use "reserved ports 80/443/8080/8443/53" to decide — that restriction only applies to China mainland (ICP filing regulation); outside China mainland (ap-southeast-1) layer-4 Anti-DDoS can legally configure 80/443, and excluding by that would wrongly delete real detection targets and cause under-detection.
• Handling: remove the identified "website auto-generated layer-4 rules" from the S2 layer-4 probe list (their exposure risk is already covered by the corresponding layer-7 domain's S1/S2), and list them separately in the report noting "the following layer-4 rules are auto-generated by layer-7 website onboarding; the origins are Anti-DDoS forwarding cluster IPs, not user origins, and are excluded from layer-4 probing". The only rules that truly need S2 layer-4 probing are user-manually-created non-website ports (e.g. custom 8081/8082/9000/9999) forwarding rules.

• Both layer-7 and layer-4 rules empty → output: "An Anti-DDoS instance exists but no forwarding rule (layer-7 domain / layer-4 port) is configured; nothing to detect." Stop.

Build a checklist for each detection object, recording: identifier (domain OR instance+port), onboarding type, Anti-DDoS CNAME (layer-7 only), origin list (value + RsType), business port.

• Onboarding type: from DescribeWebRules → domain onboarding (layer-7); from DescribeNetworkRules → port onboarding (layer-4).
• [MUST] Port expansion rule (avoid HTTPS/multi-port under-detection): for each layer-7 domain, expand every entry of ProxyTypes[] × every port of ProxyPorts[] into a configuration item (a single domain can have HTTP:80 + HTTPS:443 + custom 9090 simultaneously — you MUST NOT pick only the first port). For each layer-4 rule, expand every FrontendPort × every RealServer in RealServers into a configuration item. Probe dedup rule: because WebSocket (ws) and HTTP share the same TCP port and initial HTTP handshake (ws:// is an Upgrade from HTTP), entries that map to the same (origin_ip, port, protocol) but differ only in ProxyType (e.g. websocket:80 vs http:80) MAY be deduplicated for probing — one HTTP probe covers both. The S2 probe target count = unique (target_id, origin_ip, port, protocol) tuples after dedup; Coverage counts every original configuration item sharing that IP:port as "covered" by one probe result. Skipping any distinct port (not ProxyType) causes coverage < 100%.
• Origin normalization: if a layer-7 origin has RsType=1 (domain), first resolve it to IP with local dig +short (do not use cloud probe to resolve, to avoid resolving too many IPs that complicate probing); layer-4 RealServers are usually already IPs, and if they are domains, resolve them locally too.
• Wildcard domain identification and handling: if a domain returned by DescribeWebRules starts with *. (e.g. *.example.com), flag it as a wildcard domain. Wildcard domains cannot be used directly in S1 (DNS probing) or S2 (HTTP origin probing) and need separate handling. If there is no wildcard domain in the current scope → go straight through the generic flow, no extra handling needed. If a wildcard domain exists → pause, explain the situation to the user, and offer three options:
  1. User provides a subdomain list: ask the user to give some actually-used subdomains under the wildcard (not all required, e.g. www.example.com, api.example.com); add these to the checklist and run the generic S1+S2 flow.
  2. Probe with common prefixes: generate a subdomain list by concatenating preset common prefixes (www, mail, api, m, static, cdn) with the wildcard parent domain. You MUST explicitly tell the user which subdomains will be probed (e.g. "the following subdomains will be probed: www.example.com, mail.example.com, api.example.com, m.example.com, static.example.com, cdn.example.com") and only proceed after user confirmation. Note in the report "wildcard *.example.com cannot exhaustively enumerate all subdomains; the following is a common-prefix sample".
  3. Skip the wildcard: do not probe the wildcard at all; only check the exact domains already configured in the current scope. Note in the report "wildcard *.example.com skipped, not included in detection".

Probe point selection (region and count controllable): all CreateInstantSiteMonitor probes (DNS/HTTP/TCP) can specify probe points:

• Count only: --random-isp-city N (system picks N random points, default 3).
• Explicit region/ISP: --isp-cities '[{"city":"546","isp":"465","type":"IDC"}]' (city=city ID, isp=ISP ID, type=IDC/LASTMILE). Mutually exclusive; setting isp-cities disables random-isp-city.
• Probe point type: --agent-group PC (fixed line, default) or MOBILE.
• Get city/isp codes: first confirm with the user whether a specific region is needed; if so, call aliyun cms describe-site-monitor-isp-city-list --view-all true --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id} to look up codes. Judging "is the origin exposed" usually only needs 3~5 random multi-ISP points; explicit isp-cities is only needed to verify access from a specific region.

Batching and quota (important): an instance may have dozens to hundreds of rules. Batching and throttling rules:

• Batching: recommend ≤10 detection objects per batch; confirm scope with the user first to avoid an accidental full scan.
• Call interval: keep about 1.5s between adjacent CreateInstantSiteMonitor calls (avoid triggering the CloudMonitor one-off probe quota throttling).
• [MUST] Throttling backoff retry: on throttling errors, follow Type C of the Cloud Probe Error Handling Decision Tree (backoff 2s/4s/8s, max 3 retries, then list-as-failed; never skip remaining items).
• Slow down when throttled: once throttling hits, double the call interval for the rest of the batch (1.5s → 3s), and sleep 5s before the next batch.

---

Step 3 — S1: DNS resolution check (judges "does the resolved IP hit the origin IP", layer-7 domain objects only)

Applicability: S1 only makes sense for layer-7 domain onboarding objects; layer-4 port onboarding has no domain resolution concept, so skip S1 and go straight to S2. [MUST] Skipping S1 must NOT cause S2 to be skipped: for a layer-4 object you skip only the S1 DNS check, but you must still run the Step 4 S2 probe (TCP/UDP) for it. Do not treat "no S1 for layer-4" as "no cloud probe at all for layer-4". Judgment core: only compare whether "the IP the domain finally resolves to" intersects the "origin IP", with no need to identify the Anti-DDoS/scheduler CNAME or Anti-DDoS IP. Intersection = bypass protection to origin = exposure; no intersection = went through some intermediate layer (Anti-DDoS/scheduler/WAF/CDN) = not exposed. This logic naturally covers ordinary Anti-DDoS, traffic scheduler, using the Anti-DDoS IP directly as an A record, and all such cases.

[MUST] Strict field isolation (avoid confusion): the following three data classes are semantically completely different and must never impersonate each other; both the detection data structure and the report display must keep three independent columns:

1. Config field: Anti-DDoS CNAME (from the Cname returned by DescribeWebRules) — the CNAME address Anti-DDoS assigned to the domain, config info, not the actual DNS resolution result.
2. Config field: origin IP set (from RealServers[].RealServer; when RsType=1, the IP normalized via local dig +short ) — the origin address, not the resolution result of the "business domain" itself.
3. Probe result: the IP the domain actually resolves to on the public Internet (obtained by running a cloud probe DNS task against the business domain itself or local dig +short ) — only this column can be used for the S1 verdict.

Forbidden: filling class 1 (Cname config) or class 2 (origin IP, IP normalized from origin domain) into the class-3 "DNS resolution result" column to impersonate the actual resolution. If the business domain dig returns empty, record class 3 explicitly as "no resolution"; do not substitute the Anti-DDoS CNAME or origin IP. When judging, only read class 3.

Report display rule: the report must show at least 4 columns per domain — business domain, origin IP (RsType note), Anti-DDoS CNAME config, actual resolution result IP — and the verdict column must directly correspond to "actual resolution result IP ∩ origin IP".

Wildcard S1 probing: per the user's Step 2 choice:

• Option 1 or 2 (user-provided subdomains / common prefixes): run the generic S1 flow below for each expanded subdomain. Additionally: you may run local dig '*.example.com' +short (quote * in shell) to look up the wildcard fallback record's resolved IP as an auxiliary reference (cloud probe API support for *. format is uncertain; if it raises IllegalAddress, skip).
• Option 3 (skip wildcard): do nothing, skip directly.

For each layer-7 domain, do DNS resolution, read the actual resolved IP, and pick the probe method by ProbeMode:

(Method 1) Cloud probe: launch a DNS-type one-off probe, then use DescribeSiteMonitorLog (note: not SiteMonitorData) to get per-probe-point details.

# 3a. Create the DNS probe task, record the returned TaskId
aliyun cms create-instant-site-monitor \
  --address "www.example.com" \
  --task-type "DNS" \
  --task-name "ddos-dns-check-www-example" \
  --random-isp-city 3 \
  --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id}
# [MUST] The returned TaskId is at CreateResultList[0].TaskId (not Data.TaskId)

[MUST] Auto fallback on service not activated: classify per Type A of the Cloud Probe Error Handling Decision Tree — inform the user "cloud probe service not activated, automatically switched to local probe" and use Method 2 local probe for this and all subsequent domains/origins.

# 3b. Poll for detail logs (including the IP each probe point resolved to). Probing has execution latency:
#     query every 5s, up to 6 times; keep waiting while Data is empty.
aliyun cms describe-site-monitor-log \
  --task-ids "" \
  --metric-name "ProbeLog" \
  --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id}
# [MUST] Result-parsing gotchas:
#  1) --task-ids takes ONE TaskId at a time, query them one by one (CLI parsing of comma-separated multiple IDs is unstable and raises invalid character)
#  2) The per-probe-point data is in the returned Data field (a JSON string, needs second parse; not Datapoints)
#  3) The resolved IP field (e.g. ips) may have a trailing comma ("1.2.3.4,"); after split, strip and filter empty strings

(Method 2) Local probe: directly use local dig to resolve the domain and read the final resolved IP.

dig +short www.example.com          # Get the final resolved A-record IP (may go through multiple CNAME layers)

Verdict (per domain, identical for both methods): intersect the domain's final resolved IP set with the domain's origin IP set

• Non-empty intersection (any probe point / local resolution hits an origin IP) → S1 hit (traffic bypasses protection to origin), record domain + hit origin IP.
• Empty intersection (all resolution results land on non-origin addresses: Anti-DDoS IP, scheduler/WAF/CDN addresses, etc.) → S1 miss (went through some intermediate protection layer).

Note: the verdict does not care what CNAMEs are traversed, nor does it enumerate "legitimate pointing targets"; it only checks whether the final IP lands on an origin IP. When cloud probe and local dig agree, the conclusion is more reliable.

---

Step 4 — S2: origin direct-connect probe (judges "is the origin directly reachable from the public Internet")

[MUST] S2 is unconditional — never skip based on S1 results: regardless of whether S1 found DNS resolution (all "miss", all "hit", mixed, or S1 skipped for layer-4), you MUST probe every S2 target from Step 2. "No DNS resolution" does NOT mean "origin unreachable" — attackers can obtain origin IPs via historical records/certificate transparency, making S2 mandatory even when S1 shows nothing.

[MUST] S2 verdict rules (read before probing): (a) HTTP: HIT only when HTTPResponseCode ∈ 2xx/3xx. 4xx/5xx (including 401/403/404/409/429/500/502/503/504) count as not-exposed / uncertain, never HIT — explicitly write "HTTP , classified as not-exposed per S2 verdict rule" in the report. (b) TCP: HIT only when cloud-probe errorCode is empty AND tcpConnectTime has a real value (or local nc -zv returns "succeeded"); do NOT judge HIT by TotalTime>=0 or status!="error". (c) HTTPS ports (443 / any 443-like): use --task-type HTTP with --address "https://:"; the TaskType enum does not support HTTPS and raises TaskType does not exists. (d) When ProbeMode=cloud, cloud probe MUST be attempted first for EVERY expanded S2 target — only degrade to local per the Cloud Probe Error Handling Decision Tree.

For each normalized origin IP + business port from Step 1, first pick the probe protocol (HTTP/TCP) by onboarding type, then pick the execution method (cloud/local) by ProbeMode:

[MUST] Pre-filter the layer-4 probe list: before layer-4 S2 probing, you must have completed the "exclude website-onboarding auto-generated layer-4 rules" filtering from Step 2 — probe only user-manually-created non-website-port layer-4 rules; never probe auto-generated rules (whose RealServers are Anti-DDoS forwarding cluster IPs).

[MUST] No subjective filtering of probe targets (avoids incomplete coverage + false "not exposed"): after removing IsAutoCreate=true rules, every origin IP:port of every remaining user-manual rule must be probed one by one with the chosen method, none skipped. Never subjectively skip an origin IP because it "looks like a public/test/reserved IP" (e.g. 1.1.1.1/2.2.2.2/1.1.1.2). 🚫 Forbidden skip reasons: do NOT use ProxyStatus=off / ProxyEnable=0 / IP-range judgment / "time constraints" / "seems already covered" as reasons to skip any S2 target — the ONLY valid exclusion for layer-4 rules is IsAutoCreate=true. Never do only local while skipping cloud probe — a third-party detection once subjectively filtered out 6 origins this way, ending with only 50% coverage, and wrongly described the unprobed targets as "not exposed". If a target genuinely cannot be probed (e.g. no IPv6 capability), it can only be marked "not detected" and explicitly listed in the report's failed-items list (with IP:port + reason); never describe it as "not exposed / miss". Whether to clean up these suspected test configs is the customer's decision; the detector must not pre-judge for the customer and omit probing.

Wildcard S2 probing: a wildcard (*.example.com) cannot be used directly as an HTTP Host header. Per the user's Step 2 choice: options 1/2 use each expanded subdomain as the Host for HTTP direct-connect to the origin IP one by one; option 3 skips the wildcard's S2 probing.

Method 1 — Cloud probe

[MUST] S2 must attempt cloud probe first when ProbeMode=cloud: whether or not S1 ran, every S2 target (layer-7 HTTP and layer-4 TCP/UDP) must first be probed via CreateInstantSiteMonitor. Only degrade to local probe (Method 2) after the service is confirmed not activated, or after the plugin-parse remediation ladder below has been exhausted. Do not skip cloud probe and go straight to local nc/curl while ProbeMode=cloud.

(a) Domain onboarding (layer-7): HTTP probe + bind Host header, inspect status code

[MUST] Correct way to probe HTTPS: the TaskType of CreateInstantSiteMonitor only supports HTTP/PING/TCP/UDP/DNS; writing HTTPS raises InvalidQueryParameter: TaskType does not exists (verified in practice). The correct way to probe HTTPS business ports like 443 is --task-type HTTP + --address "https://:443" (the https:// URL prefix makes the probe do the TLS handshake); do not write --task-type HTTPS.

# HTTP ports use the http:// prefix; HTTPS ports (e.g. 443) use the https:// prefix; task-type is always HTTP
aliyun cms create-instant-site-monitor \
  --address "http://:" \
  --task-type "HTTP" \
  --task-name "ddos-origin-http-example" \
  --random-isp-city 3 \
  --options-json '{"header":"Host: www.example.com","time_out":5000}' \
  --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id}

[MUST] Correct HTTP options-json (gotchas):

• Binding the Host header MUST use the header field, format "header":"Host: ". The CMS HTTP probe options-json has no host key; writing {"host":"..."} will not bind the Host, causing the origin's Host-based routing to mis-verdict/miss. Separate multiple headers with \n.
• CLI escaping: wrap the whole options-json JSON in single quotes ('{"header":"Host: x","time_out":5000}'); do not use double quotes + backslashes (easily re-parsed by the shell). Under a healthy CLI/plugin this submits fine (reaching the auth/business response). If it still errors with invalid character 'r' looking for beginning of value, it is most likely an aliyun-cli-cms plugin version bug — follow the "handle cloud-probe failures by error type" remediation ladder below; do NOT immediately treat it as a skill syntax error or immediately fall back to local.

(b) Port onboarding (layer-4): pick TCP or UDP probe by the Protocol field

[MUST] TCP/UDP address format (gotcha): the --address of a TCP/UDP probe takes the origin IP only, no port; the port is passed via --options-json '{"port":}'. Writing --address "ip:port" raises InvalidQueryParameter: illegal port.

When Protocol=tcp, use a TCP probe:

aliyun cms create-instant-site-monitor \
  --address "" \
  --task-type "TCP" \
  --task-name "ddos-origin-tcp-example" \
  --random-isp-city 3 \
  --options-json '{"port":,"time_out":5000}' \
  --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id}

When Protocol=udp, use a UDP probe:

aliyun cms create-instant-site-monitor \
  --address "" \
  --task-type "UDP" \
  --task-name "ddos-origin-udp-example" \
  --random-isp-city 3 \
  --options-json '{"port":,"time_out":5000}' \
  --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id}

Get detail logs to judge:

aliyun cms describe-site-monitor-log \
  --task-ids "" \
  --metric-name "ProbeLog" \
  --user-agent AlibabaCloud-Agent-Skills/alibabacloud-ddos-origin-exposure-detector/{session-id}

[MUST] Cloud-probe detail "reachable/failed" verdict fields (avoid TCP false positives, judge strictly by these): ProbeLog's Data is a JSON string; the per-probe-point verdict must only rely on the following decisive fields:

• TCP probe: errorCode empty and tcpConnectTime has a real handshake time → reachable (S2 hit); errorCode non-empty (commonly 611), or the response contains i/o timeout/connection refused/no suitable address found → failed (miss).
• HTTP probe: inspect HTTPResponseCode, landing in 2xx/3xx → hit; 0/empty/4xx/5xx → miss.
• [MUST] NEVER use TotalTime>=0 or status!="error" to judge "reachable": on failure TotalTime is still filled with the exhausted timeout duration (e.g. 5000.5), and the TCP probe's status is always an empty string with no "error" enum at all — using these two conditions would make every TCP probe that got a log be wrongly judged OPEN (a third-party detection had 100% false positives this way; must avoid).

[MUST] On any cloud-probe error, classify it and act per the "Cloud Probe Error Handling Decision Tree" section below (Type A service-not-activated → fall back to local; Type B plugin-parse error → remediation ladder then local; Type C throttling → backoff retry then list-as-failed; unknown → local fallback + note). Do not fall back to local unconditionally, and do not silently skip the item.

Method 2 — Local probe

(a) Domain onboarding (layer-7): curl direct-connect to the origin IP and bind Host with --resolve (equivalent to the cloud probe's Host header), inspect status code

# HTTP (port 80 etc.)
curl -sS -o /dev/null -w '%{http_code}\n' --connect-timeout 5 --max-time 8 \
  --resolve "www.example.com::" "http://www.example.com:/"
# HTTPS (port 443 etc.): when the origin uses a self-signed / mismatched cert, add -k to judge connectivity + status code only
curl -sS -k -o /dev/null -w '%{http_code}\n' --connect-timeout 5 --max-time 8 \
  --resolve "www.example.com::" "https://www.example.com:/"

(b) Port onboarding (layer-4): pick TCP or UDP local probe by the Protocol field

Protocol=tcp:

nc -z -w 5   && echo "TCP OPEN" || echo "TCP CLOSED/FILTERED"
# Alternative: curl -sS -v --connect-timeout 5 "telnet://:" 2>&1 | grep -i connected

Protocol=udp:

nc -zu -w 5   && echo "UDP OPEN/NO-REJECT" || echo "UDP CLOSED/FILTERED"
# -u means UDP mode; note UDP has no handshake, "OPEN" only means no ICMP port unreachable was received

[MUST] IPv6 origin handling (cloud probe does not support IPv6 targets for now): if an origin RealServer is an IPv6 address (like 2400:...), cloud probe CreateInstantSiteMonitor cannot probe it — confirmed by repeated testing: its probe backend forces the IPv4 stack, so even using --isp-cities to specify probe points with IPV6ProbeCount>0 and probing a known publicly-reachable IPv6 (e.g. Alibaba public DNS 2400:3200::1) still al