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.3-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.3.tar.gz. Extract the package and install it as root:

tar -xzf ScantideGuard-Datacenter-linux-x64-0.8.3.tar.gz
cd ScantideGuard-Datacenter-linux-x64-0.8.3
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.

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.

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. Managed monitors remain read-only on the Guard; locally authored monitors stay separate.

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 intelligence settings while the browser only receives configured/not-configured markers for stored secrets.

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

Configure SMTP host, port, TLS, credentials, sender and recipients, save the settings, then send a test email. Attack alerts include country/location, network/ISP, available AbuseIPDB context, HTTP rule detail when applicable, product/version, current license state and the relevant evaluation/trial/offline-grace countdown. Custom monitors are identified by their configured display name rather than their internal ID. Expired-license and no-seat alerts are rate-limited and clearly distinguish detection from enforcement.

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.