You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You have not applied any additional foreign patches to the codebase
Some customizations were done to the configuration (provide details below is so)
The issue:
According to the ChangeLog for v0.10.4
ignorecommand extended to use actions-similar replacement (capable to interpolate all possible tags like <ip-host>, <family>, <fid>, F-USER etc.)
We need to send the full line from the Apache Log (e.g. <matches>) to our ignorecommand. We need to determine whether an Apache log line is from a user who has logged into our application, to prevent them from getting banned from too many 404s.
Why are they getting 404's? It's a ticketing system where guest-submitted emails turn into tickets that the logged-in users can respond to. If the guest-submitted email contains an image, it often has a relative link that turns into a 404 when opened in our ticket system.
So, we need non-logged-in guests to get banned for too many 404's, but logged-in users to be ignored. Now that everyone is working from home, keeping an up-to-date list of users' IPs to ignore is proving infeasible.
Our system already gives logged-in users a session ID, so we will get Apache to pass that into the Apache Log, and then Fail2Ban will pass that to our ignorecommand, which will compare it to our current list of active session IDs. If the Session ID from the Apache Log matches an active Session ID, any 404s will be ignored.
Problem is, <matches> and <match> don't appear to be working with ignorecommand.
Which tags can we use? How can we get the full line from the Apache log sent into our ignorecommand script?
And last but not least - you don't need to supply whole matched lines from log to check user is logged.
Normally you can simply exclude it in failregex. Assuming you have 2 lines in log (first should match second should not):
would match only unauthenticated requests (without username in log).
So you would save a lot of resources to store the ticket in fail2ban failures queue, parse matching lines and check the user via ignorecommand.
Another (fewer optimal) possibility would be to extend filter to extract username using tags <F-USER>\S+</F-USER> and check it in ignorecommand like:
Environment:
The issue:
According to the ChangeLog for v0.10.4
ignorecommand
extended to use actions-similar replacement (capable to interpolate all possible tags like<ip-host>
,<family>
,<fid>
,F-USER
etc.)We need to send the full line from the Apache Log (e.g.
<matches>
) to our ignorecommand. We need to determine whether an Apache log line is from a user who has logged into our application, to prevent them from getting banned from too many 404s.Why are they getting 404's? It's a ticketing system where guest-submitted emails turn into tickets that the logged-in users can respond to. If the guest-submitted email contains an image, it often has a relative link that turns into a 404 when opened in our ticket system.
So, we need non-logged-in guests to get banned for too many 404's, but logged-in users to be ignored. Now that everyone is working from home, keeping an up-to-date list of users' IPs to ignore is proving infeasible.
Our system already gives logged-in users a session ID, so we will get Apache to pass that into the Apache Log, and then Fail2Ban will pass that to our ignorecommand, which will compare it to our current list of active session IDs. If the Session ID from the Apache Log matches an active Session ID, any 404s will be ignored.
Problem is,
<matches>
and<match>
don't appear to be working with ignorecommand.Which tags can we use? How can we get the full line from the Apache log sent into our ignorecommand script?
Steps to reproduce
This works:
This doesn't:
Expected behavior
Expect to receive the full matched line from the Apache Log as an argument to our ignorecommand
Observed behavior
ignorecommand is never called
Relevant parts of /var/log/fail2ban.log file:
Received this in fail2ban.log:
The text was updated successfully, but these errors were encountered: