External scanning

MopokeHQ checks the sites and services you deploy from the outside, the way an attacker sees them: certificates, TLS settings, security headers, exposed files, open ports, known vulnerabilities and web application problems.

Targets

A target is one host and port, such as shop.example.com (port 443) or api.example.com:8443. Add targets on the Assets page: give the address, optionally the repository and environment it serves, and how you will verify it.

• Linking a target to its repository and environment (for example the shop repository’s production) puts what the scans see next to what your pipelines and deploys reported. You can change the link later under Scan policy.
• Use a public host name. IP addresses, single-label names and internal suffixes (.local, .internal, .svc and similar) are refused.
• A host that resolves to a private, loopback, link-local or cloud metadata address is never contacted, even if its DNS changes later.

The first passive check runs as soon as you add the target. Everyone in the organisation can see targets; owners and admins add, change and verify them.

Passive and active

	Passive checks	Active scans
Which targets	Every target	Verified targets only
How often	Daily, always on	Weekly (you can switch the weekly scans off per target); the active ZAP scan only inside your window, when switched on
What they look at	What any visitor sees: the certificate, TLS versions, headers, redirects, and whether a few sensitive files are reachable	Open ports, known vulnerabilities, a thorough TLS test, and a web application scan

An unverified target only ever gets passive checks. MopokeHQ checks ownership again before every active scan, so a target whose proof has gone (for example, the domain changed hands) drops back to passive only.

Prove you own a host

Each target has a verification token, such as mopokehq-verify-3f9a.... Prove you control the host in one of two ways.

DNS TXT record

1. Open the target in Assets and choose DNS record. It shows the record name and the TXT value to copy.
2. At your DNS provider, add a TXT record named _mopokehq-verify.<host> with the token as its value. For shop.example.com the record is _mopokehq-verify.shop.example.com.
3. Wait for the record to publish (DNS changes can take a few minutes), then press Verify ownership.

The DNS method sends nothing to your site.

File under /.well-known

1. Open the target in Assets and choose File on the site. It shows the file address and its contents to copy.
2. Serve a plain text file containing the token at https://<host>[:port]/.well-known/mopokehq-verify.txt. For api.example.com:8443 that is https://api.example.com:8443/.well-known/mopokehq-verify.txt.
3. It must load over HTTPS with a valid certificate and must not redirect to another host.
4. Press Verify ownership.

Verify ownership is for owners and admins. The first success is recorded in the evidence log. Keep the record or file in place: it is checked again before every active scan, and if it is gone the scan is refused and the loss is logged.

Schedules and the scan window

Scan	Schedule
Passive checks	Daily
Ports, vulnerability templates, TLS test, ZAP baseline	Weekly, one after another, while Weekly scans is on
Active ZAP scan (sends attack payloads)	Off by default. When switched on, only inside the target’s window

Run passive scan now on the target runs the passive checks straight away. Only one active scan runs against a target at a time; the others wait their turn.

The window. The active ZAP scan sends attack payloads to find injection and similar flaws, so it is opt in per target and runs only inside a window you set under Scan policy: the days, a start time, how long it stays open (30 minutes to 12 hours) and a time zone. Pick a quiet time the site’s owner agreed to. Underneath, the window is a five-field cron expression. For example, Sundays at 01:00 for three hours in Europe/London is 0 1 * * 0, 180 minutes. A window with less than 15 minutes left does not start a scan, and a running scan stops ten minutes before the window closes.

Rate limit. Each target has a rate limit under Scan policy, 1 request a second by default, adjustable from 0.1 to 10. Passive checks, the port scan, the template scan and the active ZAP scan keep to it. The TLS test and the two-minute baseline spider have no per-second setting; they run one request at a time, so they stay light.

What each scan sends

Every request identifies itself with this User-Agent:

MopokeHQ external scan (+https://mopokehq.com/scanner)

Passive checks

About 14 requests a day per target.

Check	Sends	Reports
Certificate	TLS handshakes	Expired or expiring within 7 days (critical), within 21 days (medium); wrong host name, self-signed, untrusted or incomplete chain (high); RSA key under 2048 bits (high); SHA-1 signature (medium)
Protocol versions	Handshakes limited to one version each	TLS 1.0 or 1.1 accepted (medium each); TLS 1.3 not offered (low)
Security headers	One HTTPS GET of the home page	HSTS missing (medium) or under 180 days (low). On HTML pages: Content-Security-Policy missing (medium), no X-Frame-Options or CSP frame-ancestors (medium), X-Content-Type-Options not nosniff (low), Referrer-Policy missing (low)
Version disclosure	The same GET	X-Powered-By, a Server header with a version, X-AspNet-Version (low)
Plain HTTP	One plain HTTP GET	Port 80 serving the site instead of redirecting to HTTPS (medium)
Exposed files	HEAD only, for /.git/HEAD, /.env, /phpinfo.php, /server-status, /wp-config.php.bak, /.DS_Store	The real file is reachable (critical)

The exposed-file check never downloads a file. It compares the response headers with what your site answers for a made-up path, so a site that answers 200 with the same page for everything produces no findings.

Version headers are also kept as a hint about what you run (“Headers say PHP 8.2.12”). They are the weakest evidence MopokeHQ has, so they can open an exposure marked Unconfirmed, only where no deploy or check-in speaks for that environment, and never confirm a fix. See Priorities.

Active scans

Scan	Tool	What it does
Ports	naabu	Connect scan of the top 100 TCP ports. Addresses behind a CDN are kept to ports 80 and 443.
Vulnerability templates	nuclei with nuclei-templates	Templates for the technology it detects, then generic exposure, misconfiguration and takeover templates. Medium severity and up. No denial-of-service, fuzzing or intrusive templates, and no out-of-band callbacks.
TLS test	testssl.sh	A full TLS test: ciphers, known TLS vulnerabilities, an overall grade
ZAP baseline	ZAP baseline scan	A two-minute spider with passive rules only
Active ZAP scan	ZAP full scan	Spider plus active attack rules, one thread, paced by the rate limit. Only inside the window.

Tool versions are pinned. Findings the passive checks already cover are dropped from the active results so they are not reported twice, and informational results are left out.

Each active scan runs isolated, in its own sandbox that can reach only the target’s addresses, and is removed when it finishes.

Findings

Findings show on the target in Assets, most serious first.

• A new problem opens a finding. A later scan of the same kind that no longer reports it marks it fixed, but only if the check actually ran: if your home page did not answer, header findings stay as they were. A failed scan changes nothing.
• A fixed finding that comes back reopens.
• Owners and admins can dismiss a finding with a reason, and reopen it. A dismissed finding stays dismissed when later scans report it again.
• Evidence is redacted before it is stored: keys, tokens, credentials and long secret-looking strings are masked.

Every completed scan, every finding opened or fixed, and every dismissal goes into the evidence log, so you can show an auditor when each site was checked and what was found. The same events are available as webhooks: scan.completed, target_finding.opened, target_finding.fixed and target.verified.

Scanner address

Every scan, active and the daily passive checks alike, comes from one address:

IPv4 address	115.186.255.201
Host name	scanner.mopokehq.com (resolves to the address above)
IPv6	None
User-Agent	MopokeHQ external scan (+https://mopokehq.com/scanner)

Nothing else uses the address, and nothing answers on it: it only makes requests.

One request does not come from this address: when you press Verify ownership with the file method, MopokeHQ fetches /.well-known/mopokehq-verify.txt once from its application servers, whose address is not fixed, with the same User-Agent. Allowlist the scanner address for scans, but do not rely on it for that request: either use the DNS method, which sends nothing to your site, or make sure /.well-known/mopokehq-verify.txt is reachable from anywhere. The checks before each active scan come from the scanner address as usual.

Allowlist the scanner

If a firewall, WAF or bot filter sits in front of a target, it may block or slow the scanner, and scans then see the block page instead of your site. To scan the site itself:

• Allowlist by address, 115.186.255.201/32. Do not allowlist by User-Agent alone: anyone can send that header.
• Use the address, not reverse DNS. scanner.mopokehq.com resolves to the address, but a reverse lookup of the address does not return the name.
• Rate limiting and intrusion prevention. Exempt the address from rate limits and automatic bans (for example ignoreip in fail2ban) if active scans trip them.

Common places to add it:

• Cloudflare: Security, WAF, Custom rules: a rule matching ip.src eq 115.186.255.201 with the action Skip, skipping the WAF components you use.
• AWS WAF: an IP set containing 115.186.255.201/32 and a rule that allows it, ordered before your rate-based and managed rules.
• A firewall or security group: allow inbound connections from 115.186.255.201 to the target’s ports.

If you would rather not see the traffic in your analytics or logs, filter on the address or the User-Agent.

Site owners who received scanner traffic they did not expect can read mopokehq.com/scanner, which explains what it is and how to report it.