IPBan, fail2ban-style blocking for Windows, and the two paths it watches

Count the failures, then push the address into the firewall

IPBan's mechanism is the same idea as fail2ban, and the README says so directly in the Windows install section, where it describes itself as fail2ban but for Windows.

The cycle has three parts. It reads failed login events from the Windows event viewer or from log files. It counts them per source address against a configurable threshold. When the threshold is crossed, it bans that address through the platform firewall. Everything is configured in one file, `ipban.config`, which the README notes was formerly named `DigitalRuby.IPBan.dll.config` and is now found in the IPBanCore project, with every option documented in comments in the file itself.

The applications it watches differ by platform, and the list is the clearest statement of what this tool is for. On Linux, SSH is watched by default. On Windows, the list is RDP, OpenSSH, VNC, MySQL, SQL Server, Exchange, SmarterMail and MailEnable. That is a list of Windows services that are commonly exposed to the internet and commonly brute-forced, which is exactly the attack surface fail2ban covers on a Linux host. More applications can be added through the configuration file, and a `Recipes` directory in the repository holds additional recipes for event viewer entries and log files for the cases the maintainers did not ship.

The thresholds are described as highly configurable, with options for the failed login count and the time to ban among others. That configurability is the whole design, and it is also the risk: a threshold that is too high leaves a brute force running, and a threshold that is too low will ban an address that had a typo. There is no default worth trusting without reading the config file and deciding what your own login failures look like.

Both address families are handled, with IPv4 and IPv6 on all platforms, which matters more each year as dual-stack hosts become the default.

Event log detection is instant, log file detection is a poll

The single most important line in the feature list is a comparison: banning happens essentially instantly for the event viewer, while for log files you can set how often it polls for changes.

That difference is not a performance detail, it is a detection guarantee. The Windows event log is a queryable service, so IPBan can be notified or can query a narrow window and act within the same second a failure is recorded. A log file is a file, so the only way to know it changed is to look, and the poll interval is the window in which a completed attack is running unblocked. Set it to a minute and every attacker who gets through before the first poll is a minute closer to succeeding. Set it to a second and you are reading a file continuously, which on a busy server is real I/O for a result that has not changed.

The practical consequence is that your poll interval is part of your security posture, and it is a much more consequential setting than most of the options in the config file. Nothing in the README defaults it or recommends a value, which means the right answer depends on how much log traffic your services produce and how fast an attack completes.

The polling path also has a second failure mode that the event log path does not: log rotation. A service that rotates its log on a size or time boundary can move the failed login out from under a tool that was about to read it, and btrfs-style tail-following semantics do not apply to a file a rotation has replaced. The README does not discuss rotation, so if you rely on log file detection for a service that rotates aggressively, that is a behaviour to verify yourself rather than assume.

The performance claim in the README is that the code has been optimised and tuned since 2012 and that the bottleneck is essentially always the firewall implementation rather than this code. That is the author's own characterisation rather than a measurement, and it is the reason to spend your effort tuning the firewall path and the poll interval rather than looking for a faster logger.

Three Linux firewall backends, one of which decides your distribution support

The supported platform list is unusually specific about a detail that matters more than it first appears.

Windows support is Windows 10 or newer on x86 and x64, and Windows Server 2016 or newer on x86 and x64, with the note that Windows Server 2025 requires IPBan 2.0.1 or newer. Windows Server 2012 stopped being supported in October 2023, and the README's advice on that is to upgrade to an operating system Microsoft still supports, which is the correct answer but not a useful one if you are stuck.

The Linux entries are Ubuntu, Debian, CentOS and RedHat, each on x64, arm and arm64, and each carries the same parenthetical requirement: firewalld, nftables, or iptables. That is the whole Linux firewall abstraction. Three backends, and the presence of nftables and firewalld alongside iptables tells you the project has been kept current with how distributions have moved.

The consequence is a hard dependency you cannot design around. IPBan needs a local firewall it can drive, so it does not work on a host with no firewall tooling installed, on a container without the necessary capabilities, or behind a network where the ban cannot be enforced locally. A cloud firewall does not help, because IPBan's ban is a local rule and a local rule does nothing about traffic that never reaches the host.

macOS is explicitly not supported, and the README says so without elaboration. Given that the firewall story on macOS is meaningfully different from both Windows and Linux, that is a reasonable line to draw rather than a gap, but it does mean this is a tool for servers and for Windows desktops and nothing else.

The build side is straightforward. Development needs the .NET 9 SDK, with Visual Studio Community suggested on Windows and VS Code on Linux, and you can either build a self-contained executable so the server machine does not need a .NET runtime at all, or download the precompiled binaries from the releases. Running or debugging at all requires administrator on Windows or root on Linux, which follows from the firewall requirement and is worth noting if you were planning to run it as a restricted service account.

unban.txt: unbanning is a file, and that is a design decision

The manual unbanning mechanism is one line in the feature list and deserves a section of its own, because it is unusual and it has consequences.

To unban an address, you place a file called `unban.txt` into the service folder with each address on its own line. There is no command, no API and no configuration change. The service reads the file, lifts the bans, and the operator deletes the file.

For the operator this is excellent. It works when you have no shell, when the ban is on your own address and you have locked yourself out, and when you are on a Windows box and the only tool available is Notepad. Those are real situations, and a CLI-based unban would fail all three.

The risk is the permission model. Anyone who can write to the service folder can unban anything. On a default Windows install of a service under a local system account, that folder is not writable by standard users, so the exposure is limited. On a Linux install where the service directory is group-writable, or on a machine where a lower-privileged process runs alongside IPBan, the file becomes an unban button for anyone who can reach it. And since the whole point of the tool is that a hostile address stays out, an unban path reachable by a non-administrator is the wrong kind of convenience.

Two related operational details are worth planning around. Banning is permanent for the configured duration, so if you ban your own address while connected over RDP, your session continues while it is live and drops when the ban takes effect on the next connection attempt, which is an unnerving way to discover the feature works. And the ban duration is a configuration value, not a fixed constant, which is the setting to shorten while you are tuning thresholds and lengthen once you trust them.

The feature list also mentions a comprehensive list and statistics output. On a machine under active attack that output is the difference between tuning a threshold and guessing at one, so it is worth finding before you need it.

The Windows one-liner, and the parameter you now have to pass explicitly

The Windows install is a single command run from an administrator PowerShell prompt, and PowerShell 5.1 or later is required.

$ProgressPreference = 'SilentlyContinue'; [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/DigitalRuby/IPBan/master/IPBanCore/Windows/Scripts/install_latest.ps1'))

The command sets progress preference to silent, pins the security protocol to TLS 1.2, downloads the installer from a path inside the IPBanCore project, and executes it. Fetching the latest version from the master branch is the documented behaviour, and the releases page is the alternative if you would rather pin a build.

The more interesting part is what came after. The README states that because of PowerShell parameter validation introduced in recent updates, you must explicitly specify the `startupType` parameter when using the one-liner installation command, and it then gives a longer form that passes it:

$ProgressPreference = 'SilentlyContinue'; [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; iex "& { $((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/DigitalRuby/IPBan/master/IPBanCore/Windows/Scripts/install_latest.ps1')) } -startupType 'delayed-auto'"

That is a good catch by the maintainer and a good sign about the project. A change in PowerShell's own parameter handling silently broke the documented install path, and rather than leaving users to discover it, the README now explains why the command must be different and gives the working form. Most projects in this position would have a support thread full of people whose install failed for a reason nobody documented.

The available parameters are `-startupType`, `-silent`, `-autostart` and `-uninstall`, and the startup type choice is a genuine trade-off the README does not hide. `delayed-auto` is the default and the safer option because it waits for higher-priority services to start first, which leaves the system briefly unprotected after boot. `auto` starts the service immediately at boot, giving protection from the first moment, and may encounter compatibility issues with some system configurations. The advice for anyone choosing `auto` is to verify the service starts correctly after rebooting.

That trade-off is worth thinking about for a security tool specifically. A ban list that takes effect thirty seconds late is a small exposure. A service that fails to start at all because of a startup-order conflict is an exposure that lasts until a human notices, and the README's recommendation to verify after reboot is the mitigation.

IPBan against fail2ban, and against a cloud firewall

Two comparisons with genuinely different answers.

Against fail2ban, the difference is the platform and the implementation model. fail2ban is a Python tool that watches log files, filters them with regular expressions defined per service in a jail configuration, and issues bans with a firewall command. IPBan is a C# application that reads the Windows event log natively on Windows and log files elsewhere, configured through a single .NET-style config file rather than a set of filter files. On a Windows host, fail2ban is a port with a dependency on a Python runtime and a translation layer between Windows events and its filter model; IPBan reads the event log directly, which is why the README can claim that event viewer detection is essentially instant. On Linux, the comparison is much closer, and there fail2ban has the advantage of a much larger body of published configuration.

The IPBan feature list also mentions RDP explicitly, which is the attack that Windows servers actually see. fail2ban has Windows arrangements that need a translation layer; IPBan treating the Windows event log as a first-class source is the design decision that makes it the better tool on its own platform.

Against a cloud firewall or a hosting provider's intrusion prevention, the difference is where the ban is enforced. IPBan writes a local firewall rule, which is instant, free and does not depend on anyone else's infrastructure, and which does nothing for traffic that never reaches your host. A cloud firewall can drop traffic before it arrives, which protects a host that is already overwhelmed, and which you cannot configure as precisely as you can a local rule, and which costs money on a per-connection basis.

The honest answer for most people is that they are complementary. A cloud firewall stops the volumetric and the automated bulk, and a local tool like IPBan or fail2ban stops the persistent low-and-slow attempt against a specific exposed service. The failure mode to watch for is assuming a local ban is sufficient: if the attack is a distributed one with a new source address per attempt, a local ban list is fighting the wrong battle, and no threshold in `ipban.config` will change that.

MIT, Azure Pipelines, a homepage that sells something else

The licence is the MIT License, with the text in a file named `LICENSE.md` at the repository root. That permits commercial use, modification and redistribution with attribution and no warranty, which is the least restrictive common choice for infrastructure tooling.

The build is on Azure Pipelines, with an `azure-pipelines.yml` at the top level and a build status badge pointing at a DigitalRuby project on dev.azure.com. The solution is a conventional four-project .NET layout: `IPBan`, which is the application, `IPBanClient`, which is presumably the client interface, `IPBanCore`, which holds the shared library and, as the install path reveals, the per-platform scripts, and `IPBanTests`. Separating the core library from the application is what lets the installer script live in a versioned location that the README's install URL can point at directly, which is a detail that makes the install path stable across releases.

The release cadence looks healthy. Version 4.0.0 was published on 2025-11-19, 4.1.0 on 2026-06-16, and 4.2.0 on 2026-09-28, with the last push on the same day as the newest tag, and the repository is not archived. A project at version 4 with a major bump in the last year is past the point where the API is likely to move again soon.

Two things about the project's presentation are worth noting before you evaluate it. The declared homepage is the IPBan Pro upgrade page, and the repository description leads with a claim about being the most trusted free security software since 2011, which is a marketing assertion rather than anything you can check. The free version is fully functional and MIT licensed, and the paid Pro version has its own install instructions on the vendor's site rather than in the repository. Nothing about that is dishonest, but the README you are reading is written by someone with a product to sell, and the free-versus-Pro boundary is worth keeping in mind when you read claims about performance or coverage.

The smaller housekeeping observation is a `coverage/` directory committed at the top level of the repository, next to the solution and the tests. Test coverage output in version control is a choice some teams make deliberately so reviewers can see the numbers in a diff, and a choice other teams make by accident, and from the repository alone there is no way to tell which. It is a small thing, and it is the kind of thing worth checking before you file your first pull request.

The genuinely useful documentation is not in the README at all. The wiki linked from the feature list carries the rest, and given the breadth of what this tool watches, that is where the per-service configuration detail lives.

Editorial conclusion

Adopt IPBan on a Windows machine where fail2ban does not run and RDP or SQL Server or Exchange is being brute-forced, and configure ipban.config before you leave the defaults, because the shipped thresholds and ban durations are guesses. Do not run it on macOS, which is not supported, and think about who can write to the service folder before you rely on unban.txt, since that is how an operator lifts a ban and it is also how anyone else could. Verify first by installing with -startupType delayed-auto, reading the service log after the first ban, and testing an unban by dropping an address into unban.txt to confirm the file-based path works on your platform.

Frequently asked questions

Official sources

1. DigitalRuby/IPBan on GitHub
2. License: MIT
3. Project website
4. README
5. Releases