Custom application logs
Define parsers for application-specific log formats, extract source IPs and usernames where present, and classify failures or successful authentication into Guard events.
Linux SSH and web attack protection
Scantide Guard for Linux
Protect Linux servers with lightweight log-based detection, configurable thresholds and local nftables enforcement for SSH, web servers and application logs.
SSH failed-authentication monitoring
Supported as part of the Guard monitoring, policy or enforcement workflow.
Apache and Nginx access-log monitoring
Supported as part of the Guard monitoring, policy or enforcement workflow.
Tomcat and WildFly web evidence
Supported as part of the Guard monitoring, policy or enforcement workflow.
nftables firewall enforcement
Supported as part of the Guard monitoring, policy or enforcement workflow.
Temporary and permanent IP blocks
Supported as part of the Guard monitoring, policy or enforcement workflow.
Tor, country and reputation-assisted policy
Supported as part of the Guard monitoring, policy or enforcement workflow.
Capabilities
What this Guard workflow covers
- SSH failed-authentication monitoring
- Apache and Nginx access-log monitoring
- Tomcat and WildFly web evidence
- nftables firewall enforcement
- Temporary and permanent IP blocks
- Tor, country and reputation-assisted policy
- Custom application log monitors
- Central Datacenter enrollment when required
- Local standalone operation
- Certificate-file discovery and OpenSSL/web-proxy TLS posture where supported
Designed around observable server evidence
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.
The result is intended to be understandable by an administrator: which source IP was seen, which collector reported it, which rule or threshold was reached, what action Guard took, and when a temporary block is due to expire.
Standalone when you need it. Centralized when you grow.
A single Guard can protect its own server with local policy and local firewall enforcement. Organizations with multiple systems can add Scantide Guard Datacenter for shared policy, fleet visibility, licensing and coordinated reputation services.
Download
Install Scantide Guard for Linux
The bootstrap downloads the currently published Linux Guard package over HTTPS and verifies the release SHA-256 before installation.
Linux Guard
Bootstrap install
curl -fsSL https://www.scantide.com/guard/install.sh | sudo bash
Review the script first if preferred:
curl -fLO https://www.scantide.com/guard/install.sh\nless install.sh\nsudo bash install.sh
SHA-256
2d0edf8556c6b13e8308fa7537b220290f25b95f3a9932520d3b0bcbec6574cb
New in 0.8.4
Scheduled security statistics email
Guard can send a concise security summary for the previous 24 hours or 7 days, separate from immediate attack alerts. Reports can include attack activity, unique attackers, blocks, countries and collectors/rules, with their own recipient list.
New in 0.8.2
Certificate discovery and local TLS posture
Guard can now inventory local certificate material and make certificate/TLS posture easier to understand without changing the system. Run a Windows certificate-store check, sweep local certificate files or run a full certificate reconnaissance pass. Findings are presented per certificate with expiry, chain, private-key state, likely consumer and replacement-readiness context.
Certificate discovery
Review Windows certificate stores and local PFX/P12/PEM/CER/CRT files, including application-oriented locations such as CrushFTP and common web/proxy certificate paths.
Client and server TLS
TLS posture distinguishes inbound server settings from outbound client settings. Raw Schannel/OpenSSL and configuration evidence remains available for administrators who need the detail.
Datacenter visibility
Managed Guards can report compact certificate and TLS/cryptography posture to Datacenter so fleet-level issues are visible per Guard.
Under development: certificate handling in 0.8.2 is reconnaissance and validation-only. Guard does not automatically replace certificates, export private keys, change trust roots or rebind services.
Frequently asked questions
Does Scantide Guard use nftables?
Yes. On supported Linux installations, Guard uses the local Linux firewall backend for enforcement rather than requiring a network appliance.
Can it protect SSH without Fail2ban?
Guard can monitor SSH authentication failures and enforce its own configured blocking policy. It can be used where administrators want Guard's shared management and evidence model.
Does Linux Guard require Datacenter?
No. It can run standalone or enroll into Guard Datacenter for centralized management.
See Scantide Guard in context
Read the current Guard documentation, deployment notes and product status, then choose the Windows, Linux or Datacenter path that fits your environment.
Supported operating systems
See the current Windows Server, Windows client, Legacy Windows and Linux compatibility overview, including which platforms are tested, targeted or still awaiting explicit validation.
View OS compatibility
Extend Linux Guard
Explore Custom Monitors Browse Monitor Catalogue
SSH and web collectors are preconfigured monitors — not the edge of Guard.
The bundled SSH, Apache, Nginx, Tomcat, WildFly and related collectors are intended to give Linux Guard useful coverage immediately. Custom Monitors extend the same detection, alerting and blocking model to other applications that write meaningful authentication or security evidence to files or supported logs.
Rotating and newly created files
Custom file monitors can follow application log locations where new files appear over time, instead of assuming one fixed log file forever.
Per-monitor policy
A custom Linux monitor can inherit the normal Guard thresholds or use an explicit override for alerts, blocking, windows, durations and notification routing. Application-specific recipients can be added to or replace the normal server recipient list.
Same enforcement pipeline
Events from Custom Monitors feed the same deterministic Guard decision model and local firewall enforcement used by the built-in SSH and web collectors.
Datacenter distribution
Organizations can centrally distribute approved monitor definitions from Datacenter while preserving locally authored monitors for server-specific applications.
Reusable monitor ecosystem
Monitor packages make it possible to build reusable definitions for products such as remote-access tools, web portals, appliances and other software without waiting for a new Guard binary.
Reduce false positives automatically
Blocking an attack is one thing. Knowing when not to block is another.
Guard does more than count failures. Supported built-in collectors and Custom Monitors can also classify successful authentication. That lets Guard learn which source addresses are repeatedly associated with legitimate administration and use that evidence to reduce unnecessary blocking.
Successful-login learning
When a trusted authentication source reports a successful login, Guard can use that evidence to learn or reinforce the source as a known administrative origin instead of treating every future failure from that address as hostile.
Reset-on-success behavior
A successful login can reset or contextualize the active failure counter for the same source where the monitor supports it, helping distinguish mistyped credentials from a sustained brute-force attack.
Works with Custom Monitors
Custom Monitors can classify both failed and successful authentication, so trusted-source learning is not limited to RDP or other built-in collectors. Applications with usable login evidence can participate in the same model.
Explainable trust
Learned trust should remain visible and auditable: administrators can see why a source became trusted and distinguish learned entries from manually configured allow lists.
Safer than blind whitelisting
The goal is not to permanently trust any IP that happens to log in once. Trust decisions are tied to supported authentication evidence and Guard policy so administrators retain control.
Useful across managed estates
Combined with Datacenter, successful-login intelligence can help reduce friction for known management sources while keeping attack blocking and repeat-offender handling active across the fleet.
Smarter protection
Blocking an attack is one thing. Knowing when not to block is another.
Scantide Guard can use successful authentication evidence from supported built-in collectors and Custom Monitors to recognize trusted administration sources, reset or contextualize active failure history where appropriate, and reduce unnecessary blocking without weakening the deterministic protection model.
Learn from successful logins
Trusted authentication evidence can help Guard distinguish legitimate administration from repeated hostile attempts.
Reduce false-positive blocking
Successful authentication can reset or contextualize active failure counters where supported, helping avoid blocking known legitimate sources after simple mistakes.
Not limited to built-in collectors
Custom Monitors can classify both failed and successful authentication, so trusted-source learning can extend to your own applications as well.