1.4.1

• #41: Try to reduce antivirus false positives by offering an additional download option without repacking into a single-file EXE
  • This new Fail2Ban4Win-unpacked.zip is functionally equivalent to Fail2Ban4Win.zip. The only difference is that instead of one big EXE, it has a small EXE and a folder full of DLLs.
  • As you can see on VirusTotal, repacking the program with 0 detections into a single EXE causes 14 false positives.
  • Thanks to @jmoudy and @ilanni2460 for reporting this, and @jdstroy for the unpacking suggestion.

1.4.0

• #40: Added new option to retain existing bans when Fail2Ban4Win restarts, instead of deleting its previous firewall rules and starting from scratch
  • Off by default (old deletion behavior).
  • Can be enabled by setting unbanAllOnStartup to false in configuration.json.
  • Thanks for the suggestion, @thephantom1492!
• #39: Added ability to configure logging, including file logging, in addition to the fairly unusable stdout logging this program previously used
  • Messages are logged to <installation directory>\logs\Fail2Ban4Win.log by default.
  • You can customize the level, format, files, retention, and all other logging options by editing NLog.config in the Fail2Ban4Win installation directory.
  • More documentation can be found at NLog, with detailed links above specific options in the config file.
  • Thanks for the contribution, @mexmer!

1.3.2

• #36: Decreased target version of .NET Framework from 4.8 to 4.7.2 so that users can install this program on RTM Windows Server 2019 without having to first upgrade .NET Framework to 4.8 and reboot, which would be annoying if you're trying to run a high-uptime server.
  • This program will still run the same on 4.8, so there is no action to take in terms of installing different .NET Framework versions with this update. In other words, you don't need to go downgrading anything.
  • Thanks to @mexmer for the idea.

1.3.1

• #35: Updated the default configuration file to reflect new Source and Data values for Cygwin sshd and Windows sshd.
  • You should update your configuration.json file if you use Fail2Ban4Win with OpenSSH sshd distributed by Cygwin or Microsoft.
  • To update an existing Fail2Ban4Win installation, you need to manually copy the following objects to the eventLogSelectors array in configuration.json, replacing the existing objects that have the same logName and source. Fail2Ban4Win won't modify this file automatically, to avoid overwriting your customized configuration.

    {
        "logName": "Application",
        "source": "sshd-session",
        "eventId": 0,
        "ipAddressPattern": "^sshd-session: PID \\d+: Failed password for(?: invalid user)? .+ from (?<ipAddress>(?:\\d{1,3}\\.){3}\\d{1,3}) port \\d{1,5} ssh\\d?$"
    }, {
        "logName": "OpenSSH/Operational",
        "eventId": 4,
        "ipAddressEventDataName": "payload",
        "ipAddressPattern": "^(?:sshd: )?Failed password for(?: invalid user)? .+ from (?<ipAddress>(?:\\d{1,3}\\.){3}\\d{1,3}) port \\d{1,5} ssh\\d?$"
    }, {
        "logName": "OpenSSH/Operational",
        "eventId": 4,
        "ipAddressEventDataName": "payload",
        "ipAddressPattern": "^(?:sshd: )?Invalid user .+ from (?<ipAddress>(?:\\d{1,3}\\.){3}\\d{1,3}) port \\d{1,5}$"
    }

  • Cygwin sshd gained an additional selector for the sshd-session source (the first object above).
  • The two existing Windows sshd selectors had their ipAddressPattern values modified by adding a leading (?:sshd: )? (the second and third objects above).
  • Thank you @Eno77 for noticing and raising this issue.

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
  • Thanks to @jmoeller-ua for the suggestion
• 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"
      ],

  • Thanks to @judfromhud for the suggestion.

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