Scantide Guard Manual

Overview

Scantide Guard observes authentication and application evidence, correlates repeated hostile activity and applies local firewall blocks when policy and licensing permit it. It can work alone or receive policy from Scantide Guard Datacenter.

Installation

Windows Guard and Windows Datacenter

1. Run ScantideGuard-0.8.4-Setup.exe as Administrator.
2. The installer automatically selects the Legacy Guard build on Windows NT 6.1 / Server 2008 R2 SP1 and the standard Guard on newer Windows.
3. Select Guard, Datacenter, or both components as required.
4. Open Guard at http://127.0.0.1:8788/. Windows Datacenter listens on https://127.0.0.1:8790/ by default.
5. Add trusted administrative addresses to the allowlist before enabling broad blocking policies.

Windows Server 2008 R2 TLS repair

The unified installer runs the Legacy TLS repair automatically. For an existing Legacy installation with SSL errors:

powershell.exe -ExecutionPolicy Bypass -File .\Repair-ScantideGuardLegacyTls.ps1

Linux Guard

The recommended bootstrap reads the current Guard manifest, downloads the Linux package over HTTPS, verifies its SHA-256 and runs the packaged installer:

curl -fsSL https://www.scantide.com/guard/install.sh | sudo bash

To review it first:

curl -fLO https://www.scantide.com/guard/install.sh
less install.sh
sudo bash install.sh

Verify the service:

systemctl status scantide-guard --no-pager -l
curl -fsS http://127.0.0.1:8788/api/status
journalctl -u scantide-guard -n 100 --no-pager

Linux Datacenter

Linux Datacenter is packaged separately as ScantideGuard-Datacenter-linux-x64-0.8.4.tar.gz. Extract the package and install it as root:

tar -xzf ScantideGuard-Datacenter-linux-x64-0.8.4.tar.gz
cd ScantideGuard-Datacenter-linux-x64-0.8.4
sudo ./install.sh

Datacenter runs as the dedicated scantide-datacenter system account and uses /var/lib/scantide/guard/datacenter for persistent state. Verify it with:

systemctl status scantide-guard-datacenter --no-pager -l
journalctl -u scantide-guard-datacenter -n 100 --no-pager

Dashboard

• Security events defaults to grouped incidents so repeated activity from the same source is easy to scan. Use verbose view for underlying observations.
• Active blocks contains only blocks Guard actually applied.
• Collectors shows running state, last event, discovered files and current errors.
• Assessments contains posture reports and never triggers firewall blocking.

Collectors

Built-in sources include Windows failed logons, Kerberos pre-authentication, SQL Server, Exchange SMTP, IIS/RDWeb, Linux SSH, Apache/Nginx/Tomcat/WildFly, CrushFTP and custom Windows Event or log-file monitors.

Verified search crawlers

Suspicious-looking web requests from Google and Bing crawlers are exempt only after forward-confirmed reverse DNS verification. Guard first resolves the source IP to an approved crawler hostname and then resolves that hostname back to the original IP. A User-Agent string or hostname suffix alone is never trusted. Existing automatic web blocks are released after successful verification; manual and Datacenter shared blocks remain authoritative.

WordPress protection

Scantide Guard for WordPress 0.9.8 is a lightweight application-security and intelligence component for WordPress. It is designed to remain useful in shared hosting, self-hosted WordPress without Guard, and self-hosted WordPress connected to Guard/Datacenter. The plugin does not require root access for its local WordPress protections and does not stop working simply because Scantide cloud/intelligence services are temporarily unreachable.

What the WordPress plugin is — and is not

The plugin adds WordPress-aware security evidence, deterministic local blocking, incident grouping, site auditing, software/CVE/lifecycle intelligence and reporting. It is intentionally not a Wordfence/Sucuri-style all-purpose WAF or malware-cleanup product. Scantide does not exploit the site to prove findings and does not treat missing metadata as proof of vulnerability.

Deployment modes

Administration interface

The interface is organized into Overview, Events, Detection & Blocking, Site Audit, Integrations, Reports, Tools and Settings. Settings are shown in the context where they are used instead of being presented as one very long configuration page.

Event retention, grouping and filtering

The plugin retains up to 500 recent raw security events. The Events view groups repeated activity into incidents by source IP and rule/reason family so a scanner generating hundreds of similar requests does not create hundreds of operator-facing rows.

• Grouped incidents preserve the underlying raw observations.
• Severity membership is preserved, so a group containing Medium and High events is visible in both relevant filters.
• Outcome membership is also preserved for filtering blocked, detected and related states.
• Search/filtering applies to all grouped incidents built from the retained event window.

Active blocks and source context

The Active Blocks view shows blocks the WordPress plugin actually applied. Source context can include country/flag, country name, city/region, reverse DNS, ASN/provider and optional reputation information. The plugin reuses context already attached to recent events before spending a new lookup.

Blocking and trust precedence

Local trust is evaluated before automatic policy blocks. In practical terms, the intended precedence is:

1. Manual local allowlist.
2. Learned trusted source.
3. Verified search crawler.
4. Tor, Geo, Global Reputation and web-attack policy evaluation.

Logged-in administrators, private/LAN sources and proxy-ambiguous traffic receive additional safety handling where appropriate. Configure trusted proxies before enabling automatic blocking behind a CDN, reverse proxy or load balancer.

Verified search crawlers

Google and Bing crawler exemptions require forward-confirmed reverse DNS. Guard first resolves the source IP to an approved crawler hostname and then resolves that hostname back to the original IP. A User-Agent string alone is never trusted. Positive verification is cached; failed verification is cached for a shorter period and does not create an exemption.

Tor exit-node protection

Tor protection is independent of Scantide intelligence. The plugin can refresh and cache a Tor exit-node list locally, with monitor-only or blocking modes. A last-known-good local cache can continue to be used during temporary source outages.

Country / Geo policy

Geo policy supports selected-country deny/allow behavior and monitor/block actions. Failed or unknown Geo lookup fails open. Private/LAN addresses are ignored, and proxy-ambiguous requests are not Geo-blocked. Manual/learned trust and verified-crawler safety continue to take precedence.

Scantide Global Reputation

Licensed/enrolled installations can consume Scantide Global Reputation. The plugin keeps Global-feed provenance separate from local/manual blocks and follows the single-publisher principle: entries learned from the Scantide global feed are not republished as if they were local observations.

The Events page also provides an exact IP lookup and local override workflow. Operators can search an IPv4/IPv6 address against the locally cached Scantide feed, review confidence, observations, contributing installations/accounts and locally whitelist the address if appropriate.

IP context and 429 handling

IP context now prefers Scantide for licensed/enrolled WordPress sites before using public providers. The lookup order is:

1. WordPress transient cache.
2. Authenticated Scantide IP-context endpoint.
3. Direct ipwho.is fallback.
4. Direct ipapi.co fallback.

The Scantide endpoint is designed to answer from Scantide-owned/local data, including the Guard Reputation enrichment cache, enriched observations and the local DB-IP Lite dataset when available. It does not need to spend each WordPress site's public-provider quota.

If a direct public provider returns HTTP 429, that provider enters a local one-hour cooldown. Other available sources may still be used. This prevents a busy attacked site from repeatedly worsening an existing rate limit.

Software and runtime inventory

The software report inventories WordPress core, installed plugins, themes and the running PHP version. It includes installed version, component identity, activation state and lifecycle/CVE evidence where available. The report can be downloaded as HTML/JSON, and inventory can be exported as CSV for manual evaluation.

CVE applicability and provider provenance

WordPress-specific CVE matching is version-aware. A provider's broad or wildcard description is not automatically assumed to affect all future WordPress releases when stronger bounded applicability evidence exists. Provider provenance remains visible so operators can distinguish Wordfence data, Scantide correlation and other source evidence.

Optional Wordfence Intelligence remains a secondary WordPress-specific signal. It does not silently become the Scantide source; findings retain their provider identity.

Lifecycle intelligence and community observations

Lifecycle information is deliberately separated into two concepts:

• Vendor/authoritative lifecycle status: supported, EOL, end-of-support or another lifecycle state from an authoritative or structured source.
• Scantide Community observed version: anonymized evidence that a particular product/version has been observed in participating Scantide installations.

A community-observed latest version is not presented as a vendor support/EOL declaration. If vendor lifecycle status is unavailable but the installed version equals the current community-observed version, the UI can say Community observed current while separately stating that vendor lifecycle status is not confirmed.

Lifecycle community sharing is enabled by default, matching other Scantide lifecycle clients. It shares product, publisher and version observations only. Turning it off does not disable lifecycle evaluation; it only stops contributing observations.

Site Audit

The Site Audit is separate from CVE matching. It inspects WordPress-specific operational and security posture using deterministic evidence.

• Core integrity: compares WordPress core files with official checksums where available and reports missing/modified or unexpected files.
• WP-Cron health: surfaces overdue jobs, suspiciously frequent schedules, stale hooks and other unusual scheduled-task conditions.
• REST API exposure: inventories namespaces/routes and highlights security-relevant exposure where identifiable.
• XML-RPC: reports reachability and relevant exposure/abuse context.
• Privileged users: provides security-relevant visibility into administrative accounts and application-password state where available.
• Plugin/theme provenance: distinguishes repository-backed, private/custom and otherwise uncertain provenance when the available evidence allows it.
• MU-plugins and drop-ins: explicitly inventories must-use plugins and WordPress drop-ins such as object-cache.php, advanced-cache.php, db.php and sunrise.php.
• Database/options visibility: surfaces high-value database and option observations rather than dumping raw tables.
• External dependencies: provides visibility into relevant remote dependencies where they can be observed safely.

Local HTTP/header and cookie checks

The plugin can inspect the site's delivered HTTP response for security-relevant headers such as HSTS, CSP, X-Content-Type-Options, frame protection, Referrer-Policy and Permissions-Policy, plus Secure/HttpOnly/SameSite cookie attributes where observable. These checks are observational; the plugin does not rewrite web-server configuration automatically.

Email alerts and statistics

Immediate alerts and scheduled statistics use a Scantide-style HTML layout. Depending on available context, reports can include IP, country/flag, reverse DNS, city/region, ASN/provider, Tor state, active blocks, recent incidents and trusted/safelisted changes.

Statistics reports can be scheduled daily, weekly or monthly. Site Audit can also be scheduled and optionally emailed.

Mail transport and SMTP override

By default, Scantide-generated WordPress mail uses the site's normal wp_mail() transport, including any hosting-provider transport or SMTP plugin already installed.

The optional Scantide SMTP override stores its own host, port, encryption, authentication, sender and recipient-test settings. SMTP username/password are encrypted at rest and not rendered back into the browser. When enabled, Scantide applies its SMTP configuration as the final phpmailer_init configuration for Scantide-generated mail so another WordPress SMTP plugin cannot silently replace the saved Scantide transport.

The mail transport test uses the saved Scantide settings. Save changes before testing. Transport failures should be treated separately from configuration persistence: a correctly saved SMTP override can still fail because DNS, TCP, TLS, authentication or provider policy prevents delivery.

Optional third-party intelligence

• AbuseIPDB: optional reputation lookup and optional publishing of eligible attacks the WordPress plugin actually blocked. Manual/automatic publishing honors dedupe/cooldown and never republishes provider-learned reputation as local evidence.
• AlienVault OTX: optional pulse/intelligence context.
• Wordfence Intelligence: optional WordPress vulnerability source used as additional provider evidence.

Provider credentials are encrypted at rest. Integration tests can validate credentials and transport without exposing the plaintext secret.

Service availability and fallback behavior

If Scantide licensing/intelligence services cannot be reached, Scantide-dependent controls show an unavailable/cached state instead of presenting a generic failure. Local-only functionality continues: event monitoring, local blocking, site audit, inventory collection, cached reports, Tor/Geo handling and other local checks remain available.

Security boundaries

• Privileged configuration actions require WordPress capability checks and nonces.
• Mutating actions such as unblock, allowlist, trust changes and AbuseIPDB publishing use authenticated POST/AJAX workflows.
• Secrets are not placed in query strings, diagnostics or reports.
• Outbound provider destinations are constrained by allowlists and WordPress safe HTTP handling.
• Redirects are disabled for sensitive outbound integrations unless explicitly safe.
• Response sizes, timeouts and lookup budgets are bounded.
• Blocking decisions remain independent of optional enrichment.

Troubleshooting checklist

Operational guidance

Start new detection or network policies in monitor mode where practical, validate real client-IP handling and safelist behavior, then enable blocking. Keep WordPress core, plugins, themes and PHP patched independently of Scantide Guard. Scantide adds evidence and control; it does not replace normal WordPress maintenance.

Custom user-defined blockers

Custom monitors turn a Windows Event channel or application log into normalized Guard evidence. Each saved monitor is independent; creating a second monitor does not replace the first.

Windows Event workflow

1. Select Windows Event as the source.
2. Click the blue Load all event logs button.
3. Select a channel and click the amber Show recent events button.
4. Click the green Use this event button beside a representative failure.
5. Review the detected Event ID, provider, IP and username expressions.
6. Click Analyze & test sample. Guard proposes the recognition phrase, source IP, username and authentication category, then immediately verifies the result.

Log file or rolling directory workflow

1. Enter either one exact file or a directory plus filename pattern such as security-*.log.
2. Enable subdirectories only when the application rotates into nested folders.
3. Click the blue Find matching log files button.
4. Click the green Use as sample button beside a representative file.
5. Click Analyze & test sample, verify the extracted IP/username and event type, then save.

Successful logins and trusted hosts

A custom monitor can be classified as Successful authentication / trusted-host evidence. These observations do not block; they feed the same successful-login statistics used by Guard's trusted-host/safe-list learning. This is useful for FTP servers, gateways and other applications without a built-in successful-login collector.

Regex rules

A log-file monitor needs a recognition expression and an IP extraction expression. Named groups are recommended:

Match:     authentication failed|access denied
Source IP: (?<ip>(?:\d{1,3}\.){3}\d{1,3})
Username:  Username\s*[:=]\s*(?<user>[^\s]+)

Rotating files

Directory monitors continuously discover new filenames matching the configured pattern and persist their read positions. “Ignore files already present” prevents old history from immediately creating decisions; newly created rotation files are read from their beginning.

Community Monitor Catalog and languages

Custom Monitor packages use the scantide.custom-monitors/v2 schema with publisher/trust provenance. A stable semantic monitor can contain language variants such as en, sv, de-DE and *. Runtime selection prefers exact UI culture, then the two-letter language, then *, then the base rule. Community submissions are sanitized and queued for review rather than published automatically; sample log contents and local monitor identities are stripped before submission, while configured file/directory paths are retained as suggested defaults and verified on the importing host.

Blocking policy

The normal decision combines the configured number of observations with the correlation window. Repeat-offender escalation can make a later block permanent.

• Manual and automatic blocks are stored separately from raw observations.
• Allowlisting an address releases matching Guard blocks.
• Private, loopback and explicitly trusted sources are protected according to policy.
• If the license is expired or no floating seat is available, Guard may show the attack but does not block, export, propagate or write an actionable block entry.

Observations after a block

Guard does not terminate the associated service process. IIS, Exchange, SQL Server, Remote Desktop Services, SSH and other collectors may share one process across legitimate connections, so terminating it could cause an outage.

A later event from an actively blocked IP is shown as Later attempt with Firewall rule active. It may be an already-established connection, a protocol retry, an event buffered before enforcement, or delayed log processing. Depending on the protocol and firewall, new connections are expected to be silently dropped, rejected or time out.

• It does not apply another firewall rule.
• It does not create another email notification.
• It does not increment repeat-offender block occurrences.
• It does not enter correlation scoring.
• It remains available in verbose evidence and is counted separately in the grouped incident.

Performance and scalability

Scantide Guard 0.8.3 changes several high-volume paths so large block databases do not force repeated full-state work during normal operation.

Windows firewall projection

Windows Guard and Legacy keep Guard state as the authoritative block database and project active addresses into dense Guard-owned Windows Firewall rules. Modern Windows groups up to approximately 8,000 addresses per rule and Legacy uses a conservative approximately 900-address grouping for older Windows versions. IPv4 and IPv6 are kept separate.

Older Scantide Guard Block <IP> and sparse managed rules are migrated once. The migration completion version is persisted so later service restarts perform normal reconciliation only rather than repeating legacy discovery and cleanup. On Legacy/Server 2008 R2, reconciliation runs after the service has entered the running state so Service Control Manager startup is not blocked by large firewall work.

Linux firewall

Linux continues to use native nftables IPv4/IPv6 sets where available. Startup restores active blocks in bulk rather than replaying one firewall operation per address. iptables/ip6tables remains a compatibility fallback.

Memory and allocation pressure

• Recent in-memory security-event retention is bounded; historical audit evidence remains on disk.
• Guard state checkpoints are coalesced rather than repeatedly serializing the full state after ordinary events.
• Datacenter block and safelist telemetry is change-driven with periodic consistency refreshes instead of full-list serialization on every heartbeat.
• Global Reputation avoids repeated whole-block scans when block state has not changed.
• The dashboard limits routine Active Blocks refreshes instead of requesting the entire block history every few seconds.
• Status/performance endpoints use low-allocation counters where possible.

Use /api/system/memory and /api/system/performance when diagnosing a busy Guard. Memory diagnostics include working set, private bytes, managed heap, committed GC memory, fragmentation, allocation counters, threads and key cache/state counts.

Tor and country rules

Tor

Tor blocking is preemptive. Guard downloads the Tor exit-node list independently of AbuseIPDB and synchronizes dedicated Windows Firewall rules or Linux nftables sets before traffic is observed. Use Refresh and synchronize to test the download and rule update.

Country policy

Country deny/allow decisions are event-driven. A source is geolocated when Guard receives evidence; lookup failures fail open and do not create a country block. Datacenter provides a searchable country-name picker and stores ISO two-letter codes internally. The optional example preset is only a convenience starting point: it is never enabled automatically and every selected country remains visible and editable. Security Events and Active Blocks show the resolved country name and flag when enrichment is available.

Scantide Global Reputation

Global Reputation combines normalized attack observations contributed by enrolled Scantide Guard installations. It is designed to improve local decision context without turning the public website into an anonymous downloadable block feed.

Location and network intelligence

When available, public-IP intelligence includes country, region/state, city, ASN and network/provider name. This context is reused throughout Guard, Datacenter, Global Reputation views and notifications. Geolocation is approximate and describes the network location associated with the IP address; it must not be interpreted as proof of an attacker's physical location.

Ingestion is fail-open. If local enrichment is unavailable or a field cannot be resolved, the observation is still accepted and normal Guard enforcement is unaffected. A background enrichment process can fill remaining gaps later.

Public intelligence view

The public Global Reputation dashboard presents aggregate statistics rather than customer data. Public rankings are intentionally compact and normally show the top 10 entries per area, including source countries, cities, attack categories, monitor intelligence and ASN/network concentration. Monitor intelligence combines detection volume and actual blocking outcomes rather than presenting separate duplicate monitor lists.

• Monitor intelligence: unique attacking IPs, attempts, block events and permanent-block events for 24-hour, 7-day and 30-day windows.
• ASN/network intelligence: top source autonomous systems, associated network names, observed countries, IPs, reports and attempts.
• Current reputation: a compact top-10 view of the highest-priority current reputation entries rather than a full public block dump.
• Drill-down: country, ASN and exact-IP views expose aggregated evidence and recent activity without exposing private customer identifiers.

Privacy and feed behavior

The public view does not expose customer email addresses, installation IDs, server hostnames, usernames, raw logs, request bodies or an anonymous machine-readable blacklist feed. The actionable Global Reputation block feed remains authenticated, signed/rate-limited and separate from the public analytics page.

Licensing

Guard distinguishes the evaluation period, registered trial/license state and temporary offline grace. The UI and security emails show the effective state and remaining time.

Offline grace is not a second trial and never extends the real license or trial expiry. Attack emails in a non-blocking license state explicitly state that the address was not blocked.

Managed Guards also show whether effective credentials/settings come from Local, Global policy or Local override. Clear a local override to return control to Datacenter on the next policy poll.

File integrity

Every published Scantide Guard component includes a signed scantide-integrity.json plus detached scantide-integrity.sig, generated after the final release payload is assembled. The manifest records the SHA-256 and byte size of each immutable shipped file. Guard first verifies the RSA-4096 Scantide release signature using its pinned public key, and only then trusts the per-file hashes. Mutable configuration, logs and runtime state are excluded so normal administration does not create false failures.

Windows Guard / Legacy / Datacenter

& "$env:ProgramFiles\Scantide\Guard\Guard\Test-ScantideIntegrity.ps1"
& "$env:ProgramFiles\Scantide\Guard\Legacy\Test-ScantideIntegrity.ps1"
& "$env:ProgramFiles\Scantide\Guard\Datacenter\Test-ScantideIntegrity.ps1"

Linux Guard

sudo /opt/scantide/guard/verify-integrity.sh

Linux Datacenter

sudo /opt/scantide/guard-datacenter/verify-integrity.sh

A clean payload reports VERIFIED with signature VALID. Missing or modified files are listed and return a non-zero exit code. An invalid or missing manifest signature reports UNTRUSTED because the baseline itself cannot be authenticated. Do not regenerate the manifest on an installed system merely to clear an alert; doing so creates a new local baseline and defeats comparison with the released build.

Datacenter

Datacenter is available on both Windows and Linux. It distributes policy, licensing/integration settings and centrally managed custom monitors while displaying fleet status and aggregated SOC-style security telemetry. Managed monitors remain read-only on the Guard; locally authored monitors stay separate.

SOC overview and source intelligence

Datacenter aggregates security activity across managed Guards and can present source-IP context such as country, region, city, ASN, organization/provider and the monitor that detected or blocked the activity. The SOC view is intended to make repeated campaigns, heavily targeted systems, top source networks and active blocking activity easier to interpret without opening each Guard individually.

Where enrichment is available, incident and source details use the same compact location/network format as Guard and email notifications. Missing city or ASN information is treated as incomplete enrichment rather than an error.

Administrator token — Windows Datacenter

Run token recovery locally on the Datacenter host as Administrator. The service must be stopped first.

Stop-Service ScantideGuardDatacenter
& "$env:ProgramFiles\Scantide\Guard\Datacenter\Scantide.Guard.Datacenter.exe" --recover-admin-token
Start-Service ScantideGuardDatacenter

If the bootstrap token has already been consumed and must be replaced, stop the service and use:

Stop-Service ScantideGuardDatacenter
& "$env:ProgramFiles\Scantide\Guard\Datacenter\Scantide.Guard.Datacenter.exe" --reset-admin-token
Start-Service ScantideGuardDatacenter

Administrator token — Linux Datacenter

The installed helper stops Datacenter, performs the local root-only recovery and restarts the service automatically:

sudo /opt/scantide/guard-datacenter/recover-admin-token.sh

The equivalent direct command is:

sudo systemctl stop scantide-guard-datacenter
sudo env DataDirectory=/var/lib/scantide/guard/datacenter \
  /opt/scantide/guard-datacenter/Scantide.Guard.Datacenter --recover-admin-token
sudo systemctl start scantide-guard-datacenter

To invalidate the existing token and generate a replacement:

sudo systemctl stop scantide-guard-datacenter
sudo env DataDirectory=/var/lib/scantide/guard/datacenter \
  /opt/scantide/guard-datacenter/Scantide.Guard.Datacenter --reset-admin-token
sudo systemctl start scantide-guard-datacenter

Forget Datacenter and re-enrollment

A Guard can explicitly forget its Datacenter relationship without deleting local operational state. The action clears Datacenter URL/trust enrollment material, agent identity/secret, pending enrollment code, applied-policy revision and managed connection status while preserving local blocks, events, learned trusted hosts, custom monitors and unrelated local configuration.

Use Forget Datacenter when a Datacenter has been rebuilt, an agent identity was removed, the Guard is moving to another Datacenter, or stored agent credentials are rejected. Importing a deliberately selected fresh enrollment package can replace stale enrollment credentials even when the Datacenter hostname and CA are unchanged.

Datacenter automatic backups and startup recovery

Datacenter automatically protects critical persistent state with validated known-good backups. State and matching cryptographic/TLS material are captured as coherent timestamped backup sets so recovery does not mix files from different generations.

• New state is written to a temporary file, flushed and validated before it can replace the active copy.
• The previous known-good state is retained as a backup and timestamped restore points are kept automatically.
• Recent restore points are retained densely and older recovery points are retained on a daily basis according to the configured retention policy.
• At startup Datacenter validates the primary state and can fall back through known-good recovery copies rather than overwriting a good backup with corrupt data.
• Guard local settings/state use the same principle: validate writes, retain a last-known-good copy and avoid rotating corruption over the recovery copy.

Threat-intelligence integrations

Datacenter can distribute CrowdSec, AlienVault OTX, AbuseIPDB and Scantide Global Reputation settings while the browser only receives configured/not-configured markers for stored secrets. For managed Guard fleets, Datacenter can provide the central Global Reputation configuration and act as the single publisher for managed permanent blocks, preventing the same centrally managed block from being published repeatedly by individual Guards.

Community Monitor Catalog

Datacenter can browse/install monitor packages, review provenance and language variants, and deploy a centrally managed monitor library. Community monitors are downloaded disabled for review; centrally enabled packages are distributed as managed policy without overwriting locally authored monitors.

HAProxy

HAProxy support remains Preview / conceptual implementation. Validate the actual log format and trusted-proxy behavior before relying on it for enforcement.

Backup and recovery

0.8.3 adds automatic recovery protection for the files that define Guard and Datacenter state. This is intended to protect against interrupted writes, zero-filled/corrupt JSON and accidental replacement of the only known-good copy.

Backups are a resilience layer, not a replacement for normal infrastructure backup. Include the Scantide data directories in the server's normal backup system and keep at least one recovery copy outside the protected host.

Email alerts and security statistics

Immediate incident alerts and scheduled statistics reports are separate notification paths. They reuse the configured SMTP server and credentials but can use different recipients and schedules.

Immediate alerts

Configure SMTP host, port, TLS, credentials, sender and alert recipients, save the settings, then send a test email. Attack alerts include source IP, country/location, region/city when available, ASN/network/provider information, available AbuseIPDB context, HTTP rule detail when applicable, product/version, current license state and the relevant evaluation/trial/offline-grace countdown.

Custom monitors and application integrations such as WordPress are identified by their configured display name rather than an internal UUID. Expired-license and no-seat alerts are rate-limited and clearly distinguish detection from enforcement.

Scheduled statistics reports — new in 0.8.4

Guard and Datacenter can send periodic security summaries for either the previous 24 hours or 7 days. Statistics reports have their own enable switch and recipient list so an operations or management distribution list can receive summaries without receiving every immediate attack notification.

• Guard: total attack attempts/events, unique attackers, blocked activity, temporary/permanent blocks, top attacking IPs, top source countries, and most-triggered collectors/rules where data is available.
• Datacenter: fleet-level totals plus managed/online server counts, unique attackers, blocks across managed systems, top countries, top collectors/rules and most-targeted servers.
• Send now: use the manual send-now control to validate SMTP and report content before enabling a recurring schedule.

Troubleshooting

Security notes

• Public beta / code signing: Windows beta packages may not yet be Authenticode-signed with a commercial CA-issued certificate. This can cause Unknown publisher or SmartScreen reputation warnings. Verify origin and published SHA-256 before installation; the separate Scantide integrity signature does not replace Authenticode publisher identity.
• Beta disclaimer: use staged or controlled deployment, maintain backups and an independent administrative access path, and validate policy/safelists before broad enforcement. Beta software and cryptographic controls reduce risk but cannot guarantee freedom from defects, false positives or supply-chain compromise.
• Keep the management interface bound locally unless it is protected by an authenticated reverse proxy.
• Restrict access to configuration and state files; they may contain SMTP or enrollment credentials.
• Never solve TLS errors by accepting all certificates.
• Test allowlists before broad blocking policies.
• Back up settings before upgrades and retain an administrative path that is not subject to Guard blocking.
• Scantide Global Reputation uses enrolled per-installation credentials, HMAC request/response authentication, timestamp/nonce replay protection, version/expiry checks and scoped firewall reconciliation. Datacenter shared-blacklist propagation remains a separate fleet-local layer.