Failure-only systems lack context
A protection engine that sees only rejected authentication cannot tell whether a source is a normal administrator who occasionally mistypes a password or an origin that never successfully authenticates.
Success can reset or contextualize failure history
Where the monitor supports it, a successful login can reset an active failure counter or contribute to trusted-source learning. This reduces unnecessary blocking without disabling the underlying protection.
Success can also be a security event
A successful login from an unexpected country, source or time may deserve more attention than another failed password. Guard's role is to preserve the event context rather than assume that success automatically means safe.
Custom Monitors should classify both outcomes
For line-of-business applications, a Custom Monitor becomes significantly more useful when it can identify both failed and successful authentication. The same event stream can support blocking, trust learning and operational review.
Keep learned trust auditable
A learned trusted source should be distinguishable from a manually configured allow list. Administrators need to understand why Guard considers the source normal and retain the ability to remove or override that trust.
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 ServerCustom monitors can classify successful authentication as well as failures so Guard can learn trusted administration sources and reset or contextualize active failure history where appropriate.
Current Scantide source: Scantide Guard Product & Server Security GuidesScantide 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.
Current Scantide source: Scantide Guard for Windows ServerGuard 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.
Current Scantide source: Scantide Guard Product & Server Security GuidesCustom Monitors can classify both failed and successful authentication, so trusted-source learning can extend to your own applications as well.
Current Scantide source: RDP Brute Force Protection for Windows ServerA 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.
Field experience from the archive
Historical source · JufCorp: Securing your servers, users and customers onlineBrute force attacks Another method of rendering you server useless is to use a brute force attack on the usernames (sometimes also known as a "dictionary attack" ) .
Use an automatic brute force prevention software ( I can recommend you some that can block attacks on RDWeb, RDP, Exchange Webmail, FTP, Citrix., basically anything that uses Windows Authentication or help you set it up if you like)
You simply need this to get rid of the attacks where username/password is hammered onto you servers (brute force attacks/dictionary attacks) . (I've written an earlier entry on why firewalls, VPN, account lockout polices and so on aren't enough here :
Historical source · JufCorp: Brute force protection on Windows ServerAnyhoo.. just a short post on the matter of brute force prevention on Windows and what it can do for yu.
Now, there are other ways of taking care of this problem and one is to use a brute force prevention software (which I do )
Brute force attacks are a constantly ongoing thing. Basically they're all automated and they (usually) try usernames such as administrator, root, backup etc .
Practical review checklist
- Custom monitors can classify successful authentication as well as failures so Guard can learn trusted administration sources and reset or contextualize active failure history where appropriate.
- 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.
- Custom Monitors can classify both failed and successful authentication, so trusted-source learning can extend to your own applications as well.
- 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.
- Brute force attacks Another method of rendering you server useless is to use a brute force attack on the usernames (sometimes also known as a "dictionary attack" ) .
- Now, there are other ways of taking care of this problem and one is to use a brute force prevention software (which I do )
- Use an automatic brute force prevention software ( I can recommend you some that can block attacks on RDWeb, RDP, Exchange Webmail, FTP, Citrix., basically anything that uses Windows Authentication or help you set it up if you like)