The lines of log in Apache access.log files often uses vhost_combined instead of combined. #1594
Comments
|
The same conclusion as #1589 (comment) |
|
It would be great if you could reconsider this defect. Not only does the filter not work, it fails silently. Some doco or a warning would make more sense, as vhost_combined is the default log format for Apache servers hosting multiple domains. |
Please provide the excerpt from access-log with this format.
Which filter(s) exactly?
This is basically outside of the responsibilities of fail2ban. By the way, monitoring of access-log is not recommended at all - see wiki :: Best practice (especially part Reduce parasitic log-traffic) for details. |
|
@sebres The filters mentioned in this ticket. They fail to match any lines, which in the context of a piece of software that is designed to match log lines and provide blocking, means it is failing silently. It would be great if the default regex could handle either scenario or expressly had a configuration item to do either. As it stands users will need to edit the default filters to make them work, there is no doco and then no further upstream updates will apply over the custom filter. |
I asked for an exact filter list and an excerpt from access-log with messages that need to match.
Well, it is not, let alone the range of reasons why it may stop to match, partially or even completely, is large:
There is no way to detect such situation... excepting something like there are 1000 messages in log, where no one matches, then generate a warning (not really desirable, because it is extremely error-prone).
Sure. That's why I reopened the issue. |
Environment:
The issue:
The
failregexfor the few apache filters that check theaccess.logfiles suppose that the input is from thecombinedLogFormatinstead (in my case) of thevhost_combinedone (or even thecommonone).Steps to reproduce
Create an entry such as:
The definition of the
vhost_combinedformat is:And as we can see the string starts with
%v:%p ...which is the virtual host domain name, a colon, and then the port being accessed. This way you can stick many logs in a single log file, which is very practical when you handle many hosts with one<VirtualHost>through a CMS like Snap! Websites.Expected behavior
The
failregexshould either work with both formats or we should have twofailregexentries and the administrator can choose the one he needs to use.You may also add a variable that one can then use in the regex.
There is an updated version that works for the
badbotsfilter andvhost_combinedformat:I added
.+?at the start to skip the%v:%pand also removed the$at the end because I may have information about the SSL encryption used appearing there. I use the same log for non-SSL and SSL connections—I would imagine that some other people do the same—with the followingLogFormatwhich is an extendedvhost_combined:I suppose one could have a variable to define whether the log line includes the
%v:%por not:The space at the end of
vhost=...variable may get trimmed. If so, we may want to use\s. I have not tested that theory, though. Another way is to use a more complicated regex which supports all combinations,combined,vhost_combined,vhost_combined_ssl(or other custom entries that add parameters at the end):This checks for the virtual host
<domain>:<port>entry plus a space, but makes that optional. This is probably the best solution to allow eitherLogFormatwithin the same file, although we may need a better format at this location:-.*.I also removed the ending
$so that way we can also support custom entries such as thevhost_combined_sslformat which adds two more fields at the end (and frankly it is a waste to add.*$at the end of any regex.)Observed behavior
The regex rejects everything. No ban ever happen.
Any additional information
The current regex also fails any custom formats that adds fields past the normal end of the
combinedorvhost_combinedformats.Configuration, dump and another helpful excerpts
Stock version.
Any customizations done to /etc/fail2ban/ configuration
The main problem does not come from customization.
The
$at the end of thefailregexdoes prevent simple customization adding fields at the end of your log lines, though.The text was updated successfully, but these errors were encountered: