Help4 Net
WordPress plugin tutorial

Operate Help4 security controls safely

The Help4 CDN Security Center combines managed website scanning, official WordPress core checksums, local administration activity, site-scoped WAF events, and entitled edge controls. It reports evidence without silently rewriting WordPress files.

Help4 CDN 0.2.1 Security Center showing scan, core check, metrics, and hardening state
Security Center shows managed scan and core-integrity actions, current counts, and WordPress hardening evidence. WAF and Enterprise policy appear farther down when entitled.

Start with Security Center

  1. Open Help4 CDN.
    Use a WordPress administrator account with the manage_options capability.
  2. Read the current state first.
    Review managed scan status, site security state, last completed time, pages/resources scanned, detections, and warnings.
  3. Run Security Scan.
    The button queues a managed Help4 website scan when the registered domain is eligible.
  4. Check Core Files.
    The plugin compares installed WordPress core files with official checksums for that WordPress release.
  5. Review evidence.
    Use the hardening table, WordPress activity table, and CDN/WAF event table before changing policy.
Scan availability: local core integrity remains available even when the domain is still waiting for managed scanner eligibility.

Interpret scan and integrity results

ResultMeaningNext action
Confirmed detectionThe managed scanner matched evidence strong enough to classify as a detection.Preserve evidence, take a backup if safe, and follow the incident response path. Do not delete files blindly.
WarningThe scan found a condition requiring review but not enough evidence for a confirmed malware classification.Inspect the listed route or resource and compare it with the expected application state.
Modified core fileA WordPress core file does not match the official checksum.Confirm whether it is an unauthorized edit, then replace core from the matching official release after backup.
Missing core fileAn expected WordPress core file is absent.Check deployment history and restore from the matching official release if required.
Unexpected PHPPHP appeared in a core area where the checksum inventory did not expect it.Treat as high priority and inspect without executing the file.
A clean checksum is not a complete malware clearance. Themes, plugins, uploads, database content, credentials, and server persistence require separate evidence. The managed scan and core check complement each other.

Use the activity views

WordPress activity

Review authentication, user, theme, and plugin administration events. Compare the time, event, username, source, and message with approved work.

CDN/WAF activity

Review site-scoped edge events with timestamp, severity, event type, and sanitized message. Use the Help4 dashboard for broader fleet analytics.

Do not publish raw security logs. Client-facing reporting should use aggregate counts and sanitized events, not credentials, private URLs, or detailed defensive configuration.

Select full proxy and WAF mode

Pro and Enterprise domains can request full proxy after the paid domain is assigned and hostname validation passes. The page shows both the requested and effective mode; do not assume a saved selection is active until the effective status confirms it.

ControlUseOperational guidance
Static CDN onlyRewrites selected public assets without placing the whole website behind the WAF.Use before DNS/full-proxy validation or when only asset acceleration is needed.
Full proxy + WAFRoutes eligible website traffic through Help4 proxy and WAF controls.Activate only after DNS, TLS, origin, login, callback, and form validation.
Basic challenge + filteringNormal managed WAF operation.Use as the routine protected mode when available to the plan.
Strict challenge + filteringHigher-friction filtering for elevated risk.Canary login, forms, APIs, payment flows, and mobile applications before broad use.
WAF sensitivityLow, standard, or high inspection sensitivity.Start at standard. Raise only with evidence and test legitimate workflows.

Choose bot protection deliberately

Off

No Help4 browser challenge. Managed WAF rules can still operate according to the selected WAF mode.

Managed bot challenges

Routine automated-request filtering with lower visitor friction.

Advanced browser challenge

Uses a first-party browser challenge for traffic that needs stronger verification.

Under Attack mode

Temporary highest-friction browser challenge for a current application-layer attack, not a normal permanent setting.

Canary challenge modes. Test WordPress login, password reset, forms, REST/API clients, webhooks, payment callbacks, accessibility, and mobile application flows before fleet-wide use.

Configure canonical edge headers

  • HTTPS redirect: enable after HTTPS works on every required hostname.
  • HSTS: start without preload or subdomains unless every included hostname is permanently HTTPS-ready.
  • Frame policy: use SAMEORIGIN for normal WordPress pages; reserve DENY for specifically designated sensitive surfaces.
  • Referrer, COOP, and CORP: check embedded media, OAuth, external checkout, and application integrations.
  • CSP and Permissions-Policy: inventory real script, style, image, frame, font, media, and connection sources before enforcing.
HSTS preload and CSP can break production access. Do not copy a policy from another site. Test in a canary and preserve rollback access.

Use Enterprise access controls

Enterprise can define IP, country, ASN, User-Agent, and path allow/block lists. Enter one value per line and use the smallest rule that matches the intended traffic.

  1. Record the current policy.
    Keep a rollback copy and verify an independent administrator path.
  2. Add required allow rules first.
    Preserve administrator, monitoring, origin, API, callback, and known integration access.
  3. Keep the default action at allow for ordinary deployments.
    Use block-by-default only for a deliberately closed application with a complete allowlist.
  4. Add one block class at a time.
    Save, verify, and inspect events before adding another dimension.
  5. Test from outside the allowlisted network.
    Confirm the block works without locking out legitimate workflows.
Country policy is an edge enforcement choice, not evidence that every blocked request was malicious. Report geographic policy separately from detected attacks.

Transport optimization

HTTP/2 remains required. Automatic mode lets Help4 negotiate Brotli or gzip and select a safe minimum response size. Enterprise manual override can choose custom gzip/Brotli behavior when an application requires it.

Recommended: leave transport in Automatic unless browser, content-type, or origin evidence proves a custom setting is needed.

Respond to a real alert

  1. Preserve the event and time window.
    Record the affected site, route class, POP, status, and sanitized evidence.
  2. Check customer impact.
    Verify rendered pages and application workflows, not only HTTP status.
  3. Contain narrowly.
    Use a focused WAF, bot, path, IP, ASN, or access control when the evidence supports it.
  4. Verify recovery.
    Check public content, login, forms, callbacks, cache, origin, and routing before relaxing temporary controls.
  5. Keep local evidence.
    Use Help4 operations reporting for the verbose timeline and client communication for concise confirmed impact.

Continue with the configuration and troubleshooting guide or return to cache controls.