aldaviva / fail2ban4win Goto Github PK

Event log entries have the IP address in one of the child Data elements inside the EventData element.

Currently, there are two ways to specify which Data element to search for the IP address in:

• by name, if the Data element happens to have a Name attribute, set ipAddressEventDataName to the attribute value (e.g. payload)

  <EventData>
      <Data Name="process">sshd</Data>
      <Data Name="payload">Failed password for invalid user foo bar from 192.168.1.7 port 49721 ssh2</Data>
  </EventData>

• the first one, if the Data element does not have a Name attribute

  <EventData>
      <Data>Failed password for invalid user foo bar from 192.168.1.7 port 49721 ssh2</Data>
  </EventData>

This does not handle the case where there are multiple unnamed Data elements, and the IP address is not in the first one.

<EventData>
    <Data>a</Data>
    <Data>b</Data>
    <Data>c</Data>
    <Data>1.2.3.4</Data>
</EventData>

I can think of two approaches that may help:

• if ipAddressEventDataName is empty, iterate through all child Data elements until a match is found, instead of only looking at the first one
• allow the rule to specify the index of the unnamed data element, such as 3, not just the Name attribute value

Blocking private addresses was my goal for this but was getting this message when trying to ban something like 192.168.1.7/32. Is there any way to ignore this or force the ban?

Also, 192.168.1.7 was used in your example for OpenSSH so I'm not sure if this is by design or not.

As a system administrator, I want to be notified over my preferred communication medium when an IP subnet has been blocked by Fail2Ban4Win, so that I am aware of failed authentication requests to my network and can potentially monitor these blocks with a tool.

The crash is happening on line 127 of BanManager.cs:

Task.Delay(unbanDuration, cancellationTokenSource.Token)

Task.Delay(TimeSpan, CancellationToken) can crash with this exception if the unbanDuration was negative except -1 (unlikely), or if it was too long (max int32 on .NET Framework 4.8, which is ~ 24.86 days). Like most parts of .NET, this was improved in .NET 6, but only to about 50 days.

I can imagine users wanting bans of longer than 25 days, especially for repeated offenses. I originally tried other scheduling libraries (FluentScheduler, Chroniton, and Hangfire) which were more robust and could probably handle longer durations than Task.Delay, but they were impossible to test, so I went with Task.Delay instead. To continue with the current dependencies, maybe I could chain Task.Delay?

Error log with stack trace

Anwendung: Fail2Ban4Win.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.ArgumentOutOfRangeException
   bei System.Threading.Tasks.Task.Delay(System.TimeSpan, System.Threading.CancellationToken)
   bei Fail2Ban4Win.Services.BanManagerImpl.ban(System.Net.IPNetwork, Fail2Ban4Win.Data.SubnetFailureHistory)
   bei Fail2Ban4Win.Services.BanManagerImpl.onFailure(System.Object, System.Net.IPAddress)
   bei Fail2Ban4Win.Services.EventLogListenerImpl.onEventRecordWritten(Fail2Ban4Win.Facades.EventLogRecordFacade, Fail2Ban4Win.Config.EventLogSelector)
   bei Fail2Ban4Win.Services.EventLogListenerImpl+<>c__DisplayClass6_1.<.ctor>b__1(System.Object, Fail2Ban4Win.Facades.EventRecordWrittenEventArgsFacade)
   bei Fail2Ban4Win.Facades.EventLogWatcherFacadeImpl.WatcherOnEventRecordWritten(System.Object, System.Diagnostics.Eventing.Reader.EventRecordWrittenEventArgs)
   bei System.Diagnostics.Eventing.Reader.EventLogWatcher.IssueCallback(System.Diagnostics.Eventing.Reader.EventRecordWrittenEventArgs)
   bei System.Diagnostics.Eventing.Reader.EventLogWatcher.HandleEventsRequestCompletion()
   bei System.Diagnostics.Eventing.Reader.EventLogWatcher.RequestEvents()
   bei System.Diagnostics.Eventing.Reader.EventLogWatcher.SubscribedEventsAvailableCallback(System.Object, Boolean)
   bei System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context(System.Object, Boolean)
   bei System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context_f(System.Object)
   bei System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   bei System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   bei System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(System.Object, Boolean)

While the service is starting, it deletes existing firewall rules that it previously created (filtered by Group; it doesn't delete any other rules created by other tools, Windows, or the user). It does this because otherwise the rules would never be deleted when the corresponding ban expired.

This runs in the constructor of the BanManagerImpl. The WindowsService.Start() method depends on this, so it blocks that method from finishing until all rules have been deleted. If there were a lot of rules to delete (there can be hundreds), this makes that method take a while to run. This results in the service taking a long time to start, as seen by how long it takes for net start Fail2Ban4Win to return, or for the progress bar to disappear when starting it from services.msc.

To solve this, we can start a new asynchronous Task in the constructor instead of running the blocking calls synchronously, so the constructor can finish and the rule deletion will finish at some point in the future, and the service can start and begin processing Event Log records.

To avoid overlap with rule creation, the rule deletion Task can signal a ManualResetEventSlim semaphore object or something, and rule creation can WaitOne() on that semaphore, which will only block if the initial deletion hasn't completed.