All Apache's fail2ban jails look useless

Virtualmin
1
SYSTEM INFORMATION
OS type and version Ubuntu Linux 22.04.3
Webmin version 2.105

Hi,

I found that all Apache’s fail2ban jails use variable %(apache_error_log)s as a log file path.
This variable is set in /etc/fail2ban/path-common.conf as /var/log/apache2/*error.log
But it is useless because files in /var/log/apache2/ in Virtualmin’s environment have almost nothing - all logs are written in /var/log/virtualmin/your_site_error_log files.
I tried to create path-overrides.local with the new paths but without success.

I think Webmin should set all fail2ban files from the box that way they can be used with Virtualmin but now all Apache’s jails are useless.

2

Ok here is a long winded fix
in server templates

image
image1369×823 108 KB

change _log to .log
drop to a terminal then

cd /etc/apache2/sites-available
and run sed -i ‘s/_log/.log/g’ *

this will change where apache logs to
then change you fail2ban config to something like

image
image1381×764 45.8 KB

restart apache2 and check that the new log files are created if so, restart fail2ban
then navigate to

/etc/logrotate.d
and run this
sed -i ‘s/_log/.log/g’ virtualmin.conf

which will take care of the new files for log rotation
and you should end up with something like this in the fail to ban logs

image
image966×264 11.8 KB

3

Also post this as a bug so it can be fixed

4

I would guess if the staff read this thread they will fix this if they feel it’s required

5

Not from my experience …

6

@staff is this issue a bug in virtualmin or am I missing a point here ?

@Shirehosting done

7

@Aido21,

While I understand your frustration. The problem with your suggestion is that Fail2Ban is a “Webmin” module, and therefore if Webmin is installed without Virtualmin setting a rule up like this would cause it to point to a non-existent directory.

Putting things correctly, perhaps when Fail2Ban is installed as part of a “Virtualmin” install the additional path could be implemented as part of the post install.

@Ilia @Joe would my “adjusted” suggestion be possible?

@Aido21 since this pertains to a “Virtualmin” installation, I’ve moved the thread to the “Virtualmin” category.

8

The problem lies with the log file not having an extension. This may be a bug in fail2ban not parsing files with no extension, from that I would think the virtualmin apache logs need an extension in order for fail2ban to parse them which in turn would need some alterations to the webmin fail2ban module if virtualmin is installed if not apache should log to the default location and no further action is required

9

@jimr1,

Nah, files don’t need extensions to be parsed. You must be a Windows user. Heh heh

1 Like
10

Nope i added /var/log/virtualmin/* to the jail and fail2ban refused to start erroring on bad log file names … adding extensions to the log files and adding .log to the the jail path then allowed fail2ban to restart and work as expected. As a foot note i have not used windows since around 2002 lol :laughing: :rofl: :upside_down_face:

11

@jimr1,

Fair enough, though one other thing that should be noted is some rules are meant to scan error and others only access logs. So by doing *.log you’re parsing both which is making it work a bit harder then needed in many cases. Just an FYI, might consider adjusting that rule to something like “*error.log” or “*access.log” (for you RedHat folks)

*** The path was omitted to highlight the part that should be adjusted ***

12

I know this is due to auto-close in the next few days, but this looks like the best guidance that exists for configuring fail2ban for Apache in Virtualmin as @jimr1 shared.

Are there any other potential issues that could result from the changes suggested to the logs?

13

I’m on AlmaLinux 9.3 and if memory serves, this is what I did:

I created “paths-overrides.local” in /etc/fail2ban with just these two lines in it:

[DEFAULT]
apache_error_log = /var/log/virtualmin/*_error_log
apache_access_log = /var/log/virtualmin/*_access_log

That made %(apache_error_log)s see the correct files.

Then, in each of the Apache related jails in jail.local, I added:

backend  = polling
journalmatch =

You can use any backend that’s not systemd… that tells Fail2Ban not to scan the journal, but to look at the logs.

I believe I found this workaround in a tutorial online. It’s been weeks since I implemented it, but I do get notified multiple times a day that my Apache jails are working.

2 Likes
14

Thanks for that. Fail2ban is one of the things I’ve been meaning to look into more but I really have nothing on my system. This does seem like one of the things Virtualmin should include since this is one instance it is altering the OS default.

1 Like
15

Thanks for sharing. I guess I’m just trying to understand if there’s a reason this configuration needs to be modified to work out-of-the-box for Apache, and if making these changes is going to break anything else? Otherwise, why wouldn’t it just be included as standard?

16

A few reasons, but mostly just that we didn’t think to do so. I don’t generally use fail2ban on Apache, so I never thought to make it the default. I’m a little ambivalent about it, because people have a hard time troubleshooting stuff as it is, and adding a failure mode that is sort of non-obvious like this feels a little risky.

What I mean is that we already see people tripped up by fail2ban on other services…they’re trying to login to SMTP or SSH and it fails a bunch, and then they’re blocked by fail2ban so even if they finally got everything right, they’re still locked out and now they’re not even looking in the right places to solve it.

Also, I’m not sure just making this change does all that much for most users. I’m not sure, but I’m guessing it only looks for http auth failures, and won’t notice failures of application authentication, which is most of what y’all are wanting to protect. And, those kinds of auth generally already have brute force protection built-in. It might be that a firewall rule could help mitigate a DDoS situation, though.

I’ll have to look into it. Has anyone who’s made this change checked to see if it actually does something useful? e.g. if you’re using WordPress, does it notice failed WordPress logins, or does it need a modified configuration to handle that specific case?

17

@Joe awesome reply, thank you, that makes sense.

It seems like the yield is low for this, and potentially adds complexity so I’ll personally leave it alone and rely on things like Wordfence for application security.

18

My 2 cents would be to leave it ‘off’ but correct the log paths in case someone wants to use it. I have it on and set to 1 because I have mostly default pages, so if someone/something is trying to log in, it is malicious. More of a novelty right now.

There is a separate wordpress jail. Logs are set to:
/var/log/virtualmin/*access_log

4 Likes
19

I second this. The implementation is fine as is, all that needs changing is where it’s told to look for the Apache logs.

20

100% on the money here