SiteWatch Documents
Version 1.0

Meet SiteWatch

Protect access, review changes and investigate security signals from one WordPress workspace.

This guide covers SiteWatch 1.1.1, the Security & Monitoring product. SiteWatch has one edition; the earlier monitoring-only releases are a separate historical line.

Use the sections below for installation, daily review and optional policies. Begin with observation, then test the affected workflow before blocking.

Install and activate SiteWatch

↗ Enlarge

On multisite, network activation provides the network workspace. Network administration and approval authority are different permissions; review Network Management before applying a shared policy.

Find your way around

↗ Enlarge

Open ARN SiteWatch in the WordPress menu. The eight main groups contain task-specific tabs.

Select a main group, then its secondary tab. Forms save independently: use the button for the section you changed and confirm the saved state.

Choose an initial profile

Open Settings → Setup & Profiles.

Profiles enable login limits, request/email observation and selected hardening policies. They preserve existing stricter policies and apply to the current site. The screen explains password and session rules; those rules can affect future account changes. Restore previous policies is available only while the applied policies remain unchanged.

Set login limits and keep a recovery path

Open Access Security → Login Protection.

↗ Enlarge

1. Review the account failure limit, connection failure limit and attempt window.
2. Enable protection when the thresholds suit legitimate users on this site.
3. Select Save login protection.
4. Test a normal login and keep an existing administrator session available during setup.

The policy limits failed password attempts by account and server connection address. Existing authenticated sessions are not blocked. Forwarded headers are not trusted automatically; ask your host to confirm reverse-proxy/CDN handling before relying on IP limits.

Limits expire automatically. An administrator with an existing session can select Clear login counters. If all administrators are locked out, use the screen’s Recovery with hosting access instructions with your host rather than repeatedly guessing passwords.

Enroll an authenticator and define account policies

1. Open Users → Profile for your own account and locate SiteWatch authenticator enrollment.
2. Add the displayed secret to your authenticator app and verify a current code. Keep the secret and QR image private.
3. Save the eight one-use recovery codes in a secure offline location when shown. Each code can be used once.
4. Open Access Security → Two-Factor Authentication and choose required roles only after the relevant users can enroll and recover access.
5. Test a new sign-in using the authenticator while retaining a working administrator session.

Roles & Trusted Browsers configures role-specific password/session policies and new-browser verification. Sessions & Accounts lets you review account sessions. Required accounts may be restricted until enrollment; application passwords are disabled for protected accounts. Existing sessions remain active when the policy is configured.

Designate security approvers

An administrator account does not automatically receive authority to approve accounts, plugin packages or trusted update sources.

1. Enroll an authenticator for the eligible administrator account.
2. Open the security approval policy offered in the account/plugin review workspace.
3. For initial setup, confirm your current password and a fresh authenticator code, then select Designate my account as security approver.
4. Review the authorized approvers and save the policy. Later changes to this authority require a fresh authenticator code.

A verified current session can perform routine package decisions without asking for a new code each time. Sensitive policy changes still request fresh verification. On multisite the approval policy is shared; an ordinary site administrator cannot assume network decision authority.

Verify registrations and review accounts

Open Access Security → Registration Verification. Configure verification for supported WordPress and classic WooCommerce registrations, then test the actual registration and activation-email journey.

Where enabled, public registrations need email verification and a security-approver decision. Accounts created while public registration is closed follow their separate approval workflow. Multisite network signup already uses WordPress activation emails; supported direct site registrations are configured separately.

Review pending accounts deliberately. Verify the request with its owner before approving, and test that a pending account cannot enter protected workflows. Custom registration forms and other checkout flows need their own acceptance tests.

Run a scan and interpret findings

1. Open Dashboard and choose Full code scan for an initial review or Changed files scan after a complete baseline exists.
2. Select Scan now and follow progress. A running scan is different from a completed stored report.
3. Choose a stored entry in Report history and select Open.
4. Read the review priorities, technical details, environment and coverage limits.
5. Use Site Protection → Investigation Center and Security Findings to examine supporting context.

The review index expresses workload, not the probability of compromise. Severity shows review urgency; operational errors and an unverified publisher are not confirmed attacks. Counts can refer to the same component and are not unique attackers or affected files. Keep incomplete or unavailable checks visible when deciding what to do next.

Observe requests and harden supported endpoints

Open Site Protection → Requests & Endpoints. Begin in observation mode and review matched rule IDs before choosing blocking. Supported checks inspect bounded query/form values and selected login, XML-RPC, REST and admin-post paths; custom endpoints need adapters.

Test legitimate code examples, administrative actions, forms and store workflows. Administrators and explicit trusted source IPs are excluded from selected request checks. Review Hardening separately for dashboard editing, error output and other offered settings; enabling the plugin does not mean every protection is active.

Configure early request protection with your host

Open Site Protection → Early Request Protection. This optional PHP prepend bootstrap runs selected checks before WordPress loads.

↗ Enlarge

1. Check Hosting interface and Setup status. Automatic setup supports compatible writable PHP FPM/CGI .user.ini installations.
2. Keep hosting recovery access and a configuration backup. Preserve any existing prepend handler.
3. Where supported, select Back up configuration & install in observe mode, review the shared installation scope and apply the operation.
4. Wait for hosting INI caching, confirm the request marker and test normal traffic before choosing block mode.

Apache module, CLI, LiteSpeed/managed configurations may require hosting assistance. Activation/removal can be delayed by PHP’s INI cache; the screen reports the relevant delay.

Hosting recovery: remove the SiteWatch auto_prepend_file block from .user.ini and leave sitewatch-waf.php as an inert PHP stub until cached PHP directives stop referring to it. Do not delete a still-referenced loader immediately. On multisite only a network administrator may change this shared configuration.

Review published vulnerability information

Open Site Protection → Vulnerabilities and use the offered refresh action. Review the installed version, published affected range, provider status and advice before updating or escalating a finding.

SiteWatch uses WPVulnerability data for supported packages. Requests disclose package slugs and the WordPress core version to that provider. Unsupported/private products and failed lookups remain unknown. A known affected version is a review signal, not proof that the site was exploited; ordinary update availability is a separate check.

Daily comparison can be configured in Monitoring → Site & Asset Health. Scheduled batches fetch data independently of drawing the administration screen.

Compare files with trusted references

Open Site Protection → File Integrity.

↗ Enlarge

1. Review the installed version and the available official reference. WordPress core uses official version/locale checksums; supported public plugins use version-specific WordPress.org SHA-256 references.
2. For private plugins and themes, obtain a trusted fresh package of the exact version and generate/import the offered SHA-256 manifest.
3. Confirm that the manifest comes from a trusted fresh package. Complete fresh approval verification where requested.
4. Select Compare core & imported references.
5. Review matching, different, approved and unverified counts with their scope.

Never create a trusted baseline from a possibly compromised installed copy. A reference for another version, missing/oversized files, symlinks or unavailable references cannot establish integrity. Referenced-file comparison and scanning additional content are different checks.

Repair or quarantine only after review

Open Site Protection → File Repair for a supported existing file. Review its path, current digest, trusted replacement and preview. Use a matching official reference or a trusted uploaded package of the correct version.

Reviewed repair is restricted to eligible regular referenced files up to 1 MB. Configuration files and SiteWatch itself are excluded. The operation checks the current file and stores an encrypted backup; a changed target must be reviewed again.

Quarantine also requires explicit review, an unchanged digest and an encrypted backup before removing an eligible file. Core, symlinks and SiteWatch itself are excluded. Restore refuses to overwrite an existing destination. Interrupted fallback writes may require manual review.

Review plugin packages and trusted sources

Open Plugin Review. Use Installed Plugins for inventory, Pending Reviews for proposed packages and Trusted Sources for approved update origins.

1. Inspect the publisher, installed/proposed version, package evidence and requested operation.
2. Ask a designated security approver to review the exact pending package.
3. Approve only the reviewed content and operation, then complete the supported WordPress installation/update flow.
4. Check Activity History and the installed result.

Accounts & Permissions manages supported time-limited plugin-operation permissions. An approval is tied to package/content evidence; it is not a permanent blanket allowance for unrelated ZIPs.

WordPress-managed package controls do not physically lock files against FTP, shell or hosting writes. A source marked unknown is not automatically malicious. If a package is held, inspect its review request instead of disabling the protection to continue.

Set up an encrypted contact form

Open Forms & Email → Encrypted Forms.

↗ Enlarge

This workflow covers the native SiteWatch form. Contact Form 7 and Gravity Forms encryption adapters are not included. A compromised site can replace visitor JavaScript and capture data before encryption; stored-content protection does not make a hostile page trustworthy.

Read encrypted messages and rotate recipients

1. Open Forms & Email → Encrypted Inbox using an authorized account.
2. Export the encrypted message package; do not expect WordPress to display its plaintext.
3. Open the separate offline reader, unlock the matching encrypted private-key backup and load the exported package.
4. Read text and download any permitted attachment without executing it.
5. Lock the reader when finished and protect exported files.

Messages and optional attachments up to 3 MB use a per-submission encryption key wrapped to the recipient’s public key. New-message notifications contain a reference rather than the private message.

When changing recipients, rotate the public key for future submissions and retain old private-key backups for old messages. Revoking inbox access cannot revoke keys or messages already copied. Lost private keys/passphrases cannot be recovered by SiteWatch. Reader memory clearing is best effort.

Configure spam and email controls

Open Forms & Email → Spam Protection. Configure the supported native-form and classic WooCommerce registration controls. Where Turnstile is offered, configure your provider keys and test the actual visitor flow. The Contact Form 7 spam adapter does not encrypt its submissions.

In Email Security, review observation and budget policies before blocking. Site, user, component and recipient budgets are tracked separately for recognized standard mail contexts. Direct provider APIs or sockets can bypass standard wp_mail controls.

Use Mail Diagnostics to inspect errors and service acceptance. SMTP acceptance is different from inbox receipt. Test real registration, reset-password and order emails; an interrupted delivery worker can cause duplicate retry messages.

Monitor public pages, assets and changes

Open Monitoring → Site & Asset Health.

↗ Enlarge

1. Enter up to five public local paths, one per line.
2. List exact external asset hosts you intend to check.
3. Choose daily checks, checks after WordPress-managed updates and optional REST/form-ticket probes as needed.
4. Select Save monitoring policy, then Check pages & assets now when ready.
5. Review scope, skipped checks and the completed result.

Checks inspect public HTTP responses and bounded referenced CSS, scripts and images. The form probe requests a ticket only. Checkout, authenticated pages and actual message delivery require separate tests. Redirects and connection failures remain unverified.

When available, WebPix-managed media can be delegated to WebPix Delivery health. DualFix opens its backup/recovery workspace; SiteWatch does not perform an automatic rollback. Timing after an update is context, not proof that the update caused a failure.

The other Monitoring tabs show observed Live Security Events, Installed Products, Outbound Connections, File Changes, PHP Errors and Storage. Hosting edits may have an unknown actor and become visible only in the next completed scan.

Export reports and configure notifications

Open Reports & Events → Scan Reports or select a stored report on Dashboard. Use Download HTML for a readable copy or Download JSON for structured evidence. Review exported reports before sharing: paths, inventory and operational details can be private.

Event History retains supported recorded events. Notifications defines delivery policies; Delivery History records attempts and results. Retention, enabled hooks and request caps limit the timeline.

1. Open Settings → General & Report SMTP.
2. Choose the authorized recipient, daily digest time and WordPress timezone.
3. Configure the separate report SMTP account: server, port, STARTTLS/implicit TLS, account and permitted sender.
4. Save and test transport acceptance, then confirm actual inbox receipt.
5. Use Email this report only when the recipient and selected snapshot are correct.

Scheduled work depends on WordPress cron and hosting availability. Report SMTP is separate from ordinary site mail. Planned maintenance can suppress immediate alerts while keeping records.

Use optional AI with a reviewed input

Open Settings → AI Connection & Review. Configure the shared ARN Smart AI connection with a supported provider if you want an additional explanation of reviewed evidence.

1. Review the input preview and remove information that should not leave your organization.
2. Confirm the chosen provider and model, then submit only the approved scope.
3. Follow the queued job and read the result alongside the original report.
4. Verify recommendations before taking action.

AI is optional. Provider calls transmit approved input to that provider and may incur its charges. Missing evidence remains missing; an explanation is not a security verdict or approval to repair/quarantine files.

Operate a multisite network carefully

Network activation provides a network dashboard and Settings → Network Management. Review whether an action applies to the current site or the shared installation before confirming it.

Site profiles apply to the current site. Shared early PHP protection requires a network administrator. Approval authority is explicitly designated and is not automatically granted by an administrator role. Network signup activation and direct site/WooCommerce registration are separate workflows.

Keep report recipients, site scope, scan snapshots and recovery paths explicit. The monitor remains an ordinary plugin and can be deactivated; it is not an undeactivatable early-boot rescue service.

A practical daily review

1. Check the latest completed Dashboard report and its date.
2. Read high-priority findings with their evidence and coverage limits.
3. Review pending account and package decisions with the appropriate approver.
4. Check delivery failures, PHP errors and public health observations.
5. Investigate unexpected changes using trusted references and an independent backup.
6. After a planned change, test the affected user journey and record what was verified.

Do not equate policy actions with attacks: blocked login attempts, budget limits and package review holds describe recorded policy activity.

Troubleshooting

When contacting ARN support, include product version, the task and a redacted result. Exclude passwords, activation codes, authenticator secrets, private keys and private submissions.