webmin: Fail2ban doesn't notice configs in jail.d
Fail2ban supports configuration files in /etc/fail2ban/jail.d, which the Webmin module seems to ignore.
It is used in distribution packages to setup the default action. In the case of CentOS 7, it changes the default action to firewallcmd-ipset, but Webmin still says it is iptables-multiport. I’m using it to add that rule on Debian/Ubuntu, as well, even though they have their own defaults
As far as I can tell from my testing, the files in jail.d are processed after .conf files but before .local files. So, jail.d/whatever.conf will override jail.conf, but will be overridden by jail.local.
You can see what configuration fail2ban has ended up with by using the fail2ban client to query it. e.g.
fail2ban-client get sshd actions
After making changes, you can use the reload fail2ban-client reload.
The /etc/fail2ban/jail.d/00-firewalld.conf I’m generating for Ubuntu/Debian is copied from CentOS 7 and looks like this (but anything that can appear in jail.conf can appear in these files…I guess they execute in alphabetic order, due to CentOS 7 prepending 00):
[DEFAULT]
banaction = firewallcmd-ipset
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 1
- Comments: 26 (10 by maintainers)
Commits related to this issue
- Also parse jail.d/*.local files https://github.com/webmin/webmin/issues/599 — committed to webmin/webmin by jcameron 7 years ago
you are rigth, but the output of fail2ban-client has only the active config, but e.g. not the names/config of inactive jails etc.
so we may need both, fail2ban-client for active config and parsing files for additinal info, e.g. defined but not active jails to have the possibility to activate them in jail.local
Why do we need to know what file they came from, if we’re only changing jail.local? I think that’s actually an improvement over trying to keep up with which file it’s coming from originally. The docs suggest never changing jail.conf, and there’s good arguments against changing existing jail.d files (they’re provided by packages from the distro and so could be upgraded in the future).
There’s a lot of good reasons to only modify jail.local (except in the plaintext config file editors, which can keep doing what they’re doing, but nobody ever messes with those, generally). It removes any doubt about whether it’s the option that’ll take precedent (local is always parsed last), and it removes any doubt of the OS changing things out from under us (jail.conf and some jail.d files can be modified by the system).
I think we could simplify things a lot, and make them behave actually correctly (right now we have wrong info in the UI), by just taking the parsed output from fail2ban-client, and then only making changes in jail.local.
Ah, I wonder if maybe, because this is so complicated (infinite number of locations for a config directive), we should be doing something different here.
Maybe we should get the results of the parsed configs from fail2ban, and then only modify jail.local with the changes we want. e.g. use fail2ban-client to query what the state of things actually is, and then if a user wants to change it, we change it in jail.local. The editor for the other config files can remain, but the intended purpose of jail.local is for ad hoc changes like we’re doing…maybe that’s where we should be doing them and not worry about the complexity of parsing the thing (and worse, trying to figure out where to add user changes, since the original location of a config option could be in an infinite number of locations).
If we just change jail.local, that’ll always apply (it overrides jail.conf and jail.d), and it’ll be what the authors of fail2ban intended to happen (I think). We could, instead, make a jail.d/ZZ-webmin.conf, or something, for adding our config options, but I think that’s less intuitive.