🧱 Ban subnets using Windows Firewall rules after they make enough incorrect login attempts, as indicated by Windows Event Log records.
APACHE-2.0 License
Bot releases are hidden (Show)
eventLogSelectors
objects: eventPredicate
logName
, source
, eventId
, and ipAddressPattern
are not powerful enough to match only the events that should trigger bans.
<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]
.EventRecords
properlyPublished by Aldaviva over 1 year ago
10.0.0.0/8
, 172.16.0.0/12
, and 192.168.0.0/16
get banned.
neverBanReservedSubnets
to false
in configuration.json
.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.neverBanSubnets
array.
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"
],
Published by Aldaviva almost 2 years ago
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.Published by Aldaviva almost 2 years ago
Published by Aldaviva over 3 years ago
First release.