alibabacloud-ddos-origin-exposure-detector

name

alibabacloud-ddos-origin-exposure-detector

description

Alibaba Cloud Anti-DDoS Proxy (ddoscoo) origin-server IP exposure risk detector. Detects whether a website protected by Anti-DDoS Proxy still has its origin IP exposed to direct attack, across two scenarios: (S1) a protected domain whose public DNS still resolves to the origin IP, bypassing protection; (S2) the origin IP is directly reachable from the public Internet. Reads protected domains / CNAME / origin IPs via ddoscoo (DescribeWebRules / DescribeNetworkRules). Two probe methods: (1) cloud probe via Cms one-off site monitor (CreateInstantSiteMonitor + DescribeSiteMonitorLog); (2) local dig / curl / nc, used when cloud probe is unavailable. Binary verdict. Triggers: "源站IP暴露", "源站暴露检测", "高防被绕过", "流量绕过高防", "origin IP exposure", "DDoS origin detection", "ddos-origin-exposure", "检测源站", "探测源站", "网络分析与监控探测源站", "Call DescribeWebRules", "DescribeWebRules", "DescribeNetworkRules", "CreateInstantSiteMonitor", "DescribeSiteMonitorLog", "get protected domains", "probe origin server", "site monitor probe origin".

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)

ID	Scenario	Judgment essence
S1	Domain DNS not pointing to Anti-DDoS (DNS layer)	For a protected domain configured in Anti-DDoS, if the public DNS resolution result intersects the origin IP set, traffic bypasses all intermediate protection layers and reaches the origin directly. The judgment only looks at "does the resolved IP hit the origin IP", with no need to identify the Anti-DDoS/scheduler CNAME — a resolution landing on the origin IP means exposure; landing on any non-origin address (Anti-DDoS IP, scheduler CNAME, WAF, CDN, etc.) means it went through an intermediate layer. This naturally covers ordinary Anti-DDoS, traffic scheduler, using the Anti-DDoS IP directly as an A record, and all such cases. Only validates domains already configured in Anti-DDoS; does not actively enumerate subdomains.
S2	Origin directly reachable from the public Internet (network layer)	Probe the origin IP + business port directly from multiple public locations; if directly reachable, it is treated as exposure (regardless of whether the origin is an Alibaba Cloud asset). Probe method depends on onboarding type: domain onboarding uses HTTP probing (bind the Host header, inspect status code); layer-4 port onboarding uses TCP probing.

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.

---

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.

Parameter	Required/Optional	Description	Default
ProbeMode	Required	Probe method: cloud (cloud probe, recommended, requires the site-monitor service activated, pay-as-you-go) / local (local dig/curl/nc probe, zero-cost single egress). If cloud is chosen but the service is not activated, auto fall back to local	cloud (needs user confirmation)
Domain	Optional	Business domain to check (if empty, check all configured domains under the instance)	empty (all domains)
InstanceIds	Optional	Anti-DDoS instance ID, to narrow the DescribeWebRules query scope	empty (all instances)
RegionId	Required	ddoscoo China mainland is fixed to cn-hangzhou, outside China mainland is ap-southeast-1	needs user confirmation
AgentGroup	Optional	CloudMonitor probe point type: PC (fixed line) or MOBILE	PC
RandomIspCity	Optional	Number of random probe points (system-picked, mutually exclusive with IspCities)	3
IspCities	Optional	Explicit probe points (city + ISP), JSONArray: [{"city":"546","isp":"465","type":"IDC"}]; look up city/isp codes with DescribeSiteMonitorISPCityList. Setting this disables RandomIspCity	empty (uses RandomIspCity)

---

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 <RegionId> 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 (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 <origin-domain> (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.

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 <origin-domain>) — 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 <business-domain>) — 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 "<TaskId>" \
  --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://<origin-ip>:<port>"; 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 / while ProbeMode=cloud.