1.3.0

• #34: Add ability to filter events based on Data elements other than the one that contains the IP address
  • New optional string property in eventLogSelectors objects: eventPredicate
  • Lets you append arbitrary XPath 1.0 query fragment to the ETW criteria
  • Useful if the existing filtering of logName, source, eventId, and ipAddressPattern are not powerful enough to match only the events that should trigger bans.
    • For example, there may be another <Data> element in <EventData> that specifies an important value you want to filter on, like the HTTP status code for IIS responses. If you only want to ban on 403 responses but not 200, you would need to set eventLogSelectors[].eventPredicate to something like [EventData/Data[@Name='sc-status']=403].
  • Most XPath functions are not supported by Windows ETW
• Added regular expression evaluation timeout of 3 seconds
• Added another Windows OpenSSH sshd selector to the default configuration file for "Invalid user" error, in addition to the existing "Failed password" selector
• Release memory for EventRecords properly
• Updated dependencies

1.2.0

• #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.

      "neverBanReservedSubnets": false,
      "neverBanSubnets": [
          "192.168.0.0/16"
      ],

1.1.1

• 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.

1.1.0

• 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

1.0.0

First release.