Account lockout and source blocking solve different problems
A Windows account-lockout policy limits how many bad passwords can be tried against an identity before the account is disabled. That can reduce password guessing, but it does not make the attacking source disappear. It can also create a denial-of-service opportunity: if an attacker knows valid usernames, deliberately submitting bad passwords may lock legitimate users out of Active Directory-backed services.
The firewall cannot infer authentication intent
A firewall can restrict which services are reachable and which networks may connect. That is essential. But when a service must remain reachable, the firewall normally cannot tell whether a connection represents a legitimate user mistyping a password or a source repeatedly guessing credentials. Guard monitors the authentication evidence closer to the application or operating system and can associate repeated failures with a source address, username and monitor.
Use layered controls
Account lockout, MFA, network restrictions, patching and source-based blocking are complementary controls. A sensible design uses each for what it is good at instead of expecting one mechanism to solve everything. Guard can block hostile origins without disabling the account being guessed, while existing directory policy continues to protect the identity itself.
Successful authentication changes the context
A system that only counts failures will eventually punish legitimate users. Supported Guard monitors can also classify successful authentication, allowing policy to reset or contextualize active failure history and learn trusted administration sources. Blocking an attack is one thing. Knowing when not to block is another.
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: Brute Force Protection for Windows & Linux ServersA brute-force or password-guessing attack repeatedly attempts authentication, often across common usernames or passwords. Guard focuses on observable failed-authentication evidence and source behavior.
Current Scantide source: Scantide Guard Product & Server Security GuidesProtect Windows Server from repeated RDP, IIS/RDWeb, Kerberos and SQL Server authentication attacks with deterministic monitoring and Windows Firewall blocking.
Current Scantide source: Scantide Guard 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.
Current Scantide source: Scantide Guard Product & Server Security GuidesLinux server brute-force and hostile web request protection for SSH, Apache, Nginx, Tomcat and WildFly using local evidence and nftables enforcement.
Current Scantide source: Brute Force Protection for Windows & Linux ServersNo. Guard does not perform brute-force testing. It observes authentication evidence generated by the protected server and responds according to policy.
Field experience from the archive
Historical source · JufCorp: Securing your servers, users and customers onlineYou 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 :
Enforce an Account Lockout Policy and enforce complex password. Yes, people will hate you but they will hate you even more if someone actually succeeds in hacking your users data. Have a look at the link above about Account Lockout Policies though. Do not have local users more than necessary on the Exchange Server itself.
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" ) .
Historical source · JufCorp: Automatisk skydd av Windows servrarAccount lockout is ineffective if the attacker is using a username/password combo list and guesses correctly on the first couple of attempts.
Historical source · JufCorp: Brute force protection on Windows ServerThere's a not that many tools to use natively in a Windows Server environment apart from Account Lockout Policies (which in some cases can do more harm than good to be honest). Imagine having 100 000 deliberately using all of your usernames but faulty passwords. This will simply render all of your user accounts locked out from your systems and nobody except Administrator is allowed to login (since that account can't be locked out)
Now, there are other ways of taking care of this problem and one is to use a brute force prevention software (which I do )
Practical review checklist
- A brute-force or password-guessing attack repeatedly attempts authentication, often across common usernames or passwords.
- Protect Windows Server from repeated RDP, IIS/RDWeb, Kerberos and SQL Server authentication attacks with deterministic monitoring and Windows Firewall blocking.
- 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.
- Linux server brute-force and hostile web request protection for SSH, Apache, Nginx, Tomcat and WildFly using local evidence and nftables enforcement.
- You simply need this to get rid of the attacks where username/password is hammered onto you servers (brute force attacks/dictionary attacks) .
- Enforce an Account Lockout Policy and enforce complex password.
- 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" ) .