The nearest TCP peer may not be the attacker
Behind HAProxy, Nginx, IIS ARR, a load balancer or another reverse proxy, the backend server may see the proxy address for every request. Blocking that address would block legitimate users as well.
Headers such as X-Forwarded-For and Forwarded can carry the original client address, but an attacker can also send those headers directly. Guard should only accept forwarded client identity from explicitly trusted proxy sources.
Normalize chains carefully
Multiple proxies can create a list of addresses. The correct client depends on which hops are trusted and how the infrastructure appends or replaces forwarding headers.
Test before enforcing
Use controlled requests through the real proxy path and verify which address Guard extracts. A correct parser in a lab can still be wrong when production proxies are configured differently.
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: RDP Brute Force Protection for Windows ServerWindows Security Event ID 4625 is a common failed-logon source. Guard also supports other trusted authentication evidence depending on the configured collector.
Current Scantide source: Web Attack & Scanner Protection for IIS, Apache and NginxGuard is focused on log/evidence-driven host protection and controlled firewall response. It is not positioned as a full reverse-proxy WAF replacement.
Current Scantide source: Scantide Guard for LinuxDefine parsers for application-specific log formats, extract source IPs and usernames where present, and classify failures or successful authentication into Guard events.
Current Scantide source: Custom Security Log Monitoring & Automatic IP BlockingNot every application deserves a hard-coded collector. Guard Custom Monitors let administrators teach Guard how a trusted event channel or log file represents authentication failures, successful logins and source IP evidence.
Current Scantide source: Scantide Guard Product & Server Security GuidesAutomatically detect repeated failed logins and block hostile source IPs on Windows and Linux servers with configurable, explainable Guard policies.
Field experience from the archive
Historical source · JufCorp: Securing your server environment - Part III - Operating systemsWhatever you'll be using your server for. have a look at any information that it "bleeds". This could for instance be headers telling any attacker exactly what version of software you're running. If possible, try to hide such information. There's no need for it to be visible and help a hacker find a way in. Simple checks using telnet to the ports your services might reveal some interesting information . Sadly, it's not possible to remove all headers etc but you should give it a go and remove as many as possible While on the subject, use SSL-certificates for any service where possible. Also make sure to set it up correctly (disable weak ciphers, enable HSTS, set correct HTTP headers, set TLS correctly etc ) . Have a look at Letsencrypt for instance for SSL certificates. It's free, supported by basically everyone and it'll probably get the job done for you . All you have to remember is to check that your certificates are renewed every three months.
Historical source · JufCorp: Securing your servers, users and customers onlineDon't use the "validate reverse DNS" options since a lot of companies haven't actually set it up correctly so you'll just risk not getting email from them. The idea is good but it doesn't work in real life.
Practical review checklist
- Windows Security Event ID 4625 is a common failed-logon source.
- Guard is focused on log/evidence-driven host protection and controlled firewall response.
- Define parsers for application-specific log formats, extract source IPs and usernames where present, and classify failures or successful authentication into Guard events.
- Automatically detect repeated failed logins and block hostile source IPs on Windows and Linux servers with configurable, explainable Guard policies.
- Don't use the "validate reverse DNS" options since a lot of companies haven't actually set it up correctly so you'll just risk not getting email from them.