Scantide Guard Guide

Monitor First, Block Second: Safe Policy Tuning for New Applications

For unfamiliar applications and Custom Monitors, observe events first, validate parsing and baselines, then enable enforcement with confidence.

Technical guideUpdated 25 September 2026Scantide Guard
Short answer: For unfamiliar applications and Custom Monitors, observe events first, validate parsing and baselines, then enable enforcement with confidence.

A parser that matches is not automatically safe to block on

Custom logs can contain attacker-controlled fields, inconsistent formats or source addresses that represent proxies rather than clients. First confirm what each field actually means.

Build a baseline

Run the monitor without blocking long enough to see normal failures, service retries, maintenance behavior and legitimate administrative mistakes. This gives you evidence for a sensible threshold.

Test known bad and known good events

Use controlled examples to confirm that failures are classified as failures, successful logins are recognized when supported, usernames are extracted correctly and source IPs correspond to real clients.

Enable enforcement gradually

Start with an alert threshold, then temporary blocking, then longer/repeat-offender behavior if the evidence supports it. Avoid jumping straight to permanent blocks on a new parser.

Practical depth: examples, failure modes and what to verify

Source note: current Scantide material describes the present platform. Older JufCorp/Red Cloud material is retained as field experience and historical context. Old product names, versions and configuration examples are not presented as current requirements.

Current Scantide detail

Current Scantide source: Scantide Guard for Windows Server

Each monitor can inherit the global Guard policy or use its own alert threshold, block threshold, time window, block duration, immediate-block behavior and notification settings.

Current Scantide source: Custom Security Log Monitoring & Automatic IP Blocking

Yes. A custom monitor can classify successful authentication evidence so Guard can use it for trusted-host or safe-list learning rather than blocking.

Current Scantide source: Scantide Guard for Linux

Events from Custom Monitors feed the same deterministic Guard decision model and local firewall enforcement used by the built-in SSH and web collectors.

Current Scantide source: Scantide Guard Product & Server Security Guides

Detect repeated SSH login failures and automatically block hostile IP addresses on Linux with Scantide Guard and local firewall enforcement.

Current Scantide source: Brute Force Protection for Windows & Linux Servers

Scantide Guard does not need to attack, exploit or brute-force a service to decide that repeated hostile activity deserves action. Collectors observe evidence already generated by the server, normalize it into a common event model, then apply explicit thresholds, allowlists, exceptions and enforcement policy.

Field experience from the archive

Historical source · JufCorp: Securing your server environment - Part III - Operating systems

Enable logging of login failures, access failures to operating system events etc. In short, log everything. It'll impact performance and use up disk but it's useful for troubleshooting when the time comes.

Practical review checklist

Frequently asked questions

Why not enable blocking immediately?

Because custom application behavior may not be fully understood and a parsing mistake can block legitimate systems.

Can built-in monitors also run without blocking?

Yes, monitor-only or alert-focused operation can be useful during evaluation and tuning.

Use the same principles with Scantide Guard

Scantide Guard combines preconfigured collectors, Custom Monitors, per-monitor policy, successful-login learning, explainable firewall enforcement and optional Datacenter management across Windows and Linux.

Explore Scantide Guard Custom Monitors Datacenter