Fail2Ban4Win Changelog
What's new in Fail2Ban4Win 1.2.0
Jul 3, 2023- #30: Added new configuration option to let IP addresses or subnets in the reserved ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 get banned.
- To enable, set neverBanReservedSubnets to false in configuration.json.
- Backwards compatible: the default value is true, which preserves the old behavior of never banning addresses in those three ranges, even if this option is missing from the configuration file. Therefore, using an old configuration file written for a previous version of Fail2Ban4Win without this option will make it keep working the way it was, without you having to change the configuration file.
- If you allow addresses in those three reserved ranges to get banned, but still want to prevent a subset of addresses from being banned, you can always manually add as many exempt ranges as you want to the neverBanSubnets array.
- For example, to let addresses in 10.0.0.0/8 and 172.16.0.0/12 get banned, while ensuring that 192.168.0.0/16 cannot get banned, you could use the following configuration options.
New in Fail2Ban4Win 1.1.1 (Dec 23, 2022)
- Prevent a benign race condition in which enough failed requests simultaneously arrive from the same IP subnet that multiple firewall rules are created at once, instead of creating just one rule.
- For example, if maxAllowedFailures were set to 9, and 20 auth failures could have occurred at the same time, then Fail2Ban4Win would have processed the first 10, created a firewall rule for the first offence, and then processed the next 10 requests, which would have created another firewall rule for the second offense. The second 10 failure events were not blocked by the first offense firewall rule because they were already received, rejected, and logged before the first rule was created.
New in Fail2Ban4Win 1.1.0 (Dec 14, 2022)
- Changed example configuration.json to have logLevel Info.
- Fixed running Install-Install service.ps1 from directories that aren't the installation directory.
- Changed default banRepeatedOffenseCoefficient to 0 for simpler behavior if the property is missing (example config file still has recommended value of 1).
- Make the service depend on the Windows Defender Firewall service, to ensure the firewall is running before this service starts and tries to use the firewall's API.
- 1: Asynchronously clear existing firewall rules during startup to avoid service start timeouts
- Updated dependencies
- 8: Handle extracting IP address from unnamed Data element that isn't the first child of EventData
- Widen banRepeatedOffenseCoefficient type from int to double for more configuration flexibility
- 10: Crash after creating firewall rule due to ArgumentOutOfRangeException in Task.Delay