Web Attack and Scanner Protection
A large share of hostile web traffic is reconnaissance: secret-file requests, CMS probes, traversal attempts, scanner bursts and repeated forbidden or missing resources. Guard can identify high-confidence patterns and behavioral signals, then apply policy-driven blocking.
Path traversal normalization and detection
Supported as part of the Guard monitoring, policy or enforcement workflow.
Secret/admin path probes such as .env and .git
Supported as part of the Guard monitoring, policy or enforcement workflow.
CMS and WordPress reconnaissance patterns
Supported as part of the Guard monitoring, policy or enforcement workflow.
phpMyAdmin, Tomcat Manager and actuator probes
Supported as part of the Guard monitoring, policy or enforcement workflow.
SQL injection indicators using confidence-based handling
Supported as part of the Guard monitoring, policy or enforcement workflow.
Excessive 404/403 and scanner-burst behavior
Supported as part of the Guard monitoring, policy or enforcement workflow.
What this Guard workflow covers
- Path traversal normalization and detection
- Secret/admin path probes such as .env and .git
- CMS and WordPress reconnaissance patterns
- phpMyAdmin, Tomcat Manager and actuator probes
- SQL injection indicators using confidence-based handling
- Excessive 404/403 and scanner-burst behavior
- Trusted crawler verification
- Application-aware exceptions such as legitimate RDWeb flows
- Explainable rule family and match reason
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.
Frequently asked questions
Is Guard a web application firewall?
Guard is focused on log/evidence-driven host protection and controlled firewall response. It is not positioned as a full reverse-proxy WAF replacement.
Can legitimate crawlers be protected from false blocks?
Guard supports verified crawler handling using forward-confirmed reverse DNS rather than trusting a User-Agent string alone.
How are false positives handled?
Rules can include application-aware exceptions, monitor-only behavior and profile/policy controls so administrators can validate detection before enforcing blocks.
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.