Jebus, why would they do that!?
I’m beginning to think firewalld is more trouble than it’s worth, though I don’t know what we’d replace it with. There isn’t anything else that is available in the OS repos across all supported distros that is a reasonable firewall abstraction layer. Maybe we ought to get on nftables support in Webmin and switch to using it directly.
FirewallD itself isn’t a problem. It would be a lot of work to implement nftables support as a separate module.
Debian should fix it upstream.
BIG WISH FOR XMAS
Remove Fail2ban and FireallD and use CSF Firewall!
And pleae bring back logfiles… I cant get used to journalctl!
Was where any change in the last years in these “new technology” (nftables vs iptables, logfiles vs. journal, systemd, and god knows what all else) that made is easier for you develovers?
The Webmin/Virtualmin dev’s have to work what the OS providers present to them
Yes some of the decisions of OS distributions might be questionable we have to live move forward with the OS tools that are current
Absolutely never going to happen. I don’t love Fail2ban or Firewalld, but CSF is not an upgrade.
If we change, it will be to sshguard (probably) and maybe managing nftables directly. All this heavy weight firewall-related stuff is dumb for a web server. CSF is overkill. So is fail2ban and Firewalld, but at least Fail2ban and Firewalld are provided by all of our supported distros in their regular OS repos. CSF is not, so we’d have to be responsible for those packages (and it’s a messy solution to the problem of firewalls on a web server, it is simply not the right tool for the job and never has been).
Of course not. But, you can do anything you want. It’s your system. You can still use text logs, you can still install rsyslog, you can still use the Webmin log reader, etc. I don’t recommend it, but we’re not stopping you. Go nuts.
But, also, this one is not our decision. Your OS vendor made this decision (and they were right to make it…the journal is superior to logs in almost every way), and we don’t override operating system choices unless we have no other choice. We respect your OS. Your OS uses the journal for most logs, so we support that in all of our tools.
We are really serious about working with your OS and not replacing huge swaths of it. That’s a feature of Virtualmin, and it is historically unique…most of our major competitors do replace huge swaths of the OS with less secure, poorly maintained, custom versions of all the packages it uses. That’s a terrible and dangerous practice for a small team (and all control panels are maintained by much smaller teams than the OSes we’re working on).
And, I guess I should say, I do kinda regret settling on both fail2ban and firewalld. They’re fine, but they’re not great. They’re also much heavier than I’d like, in terms of memory usage and in terms of how they approach the problems they solve. They introduce an extra layer of complexity that I’m not overly fond of.
And, I mean, look at this:
# ps aux |grep fail2ban
root 771 2.6 0.7 2743460 61676 ? Ssl Oct06 2316:26 /usr/bin/python3.6 -s /usr/bin/fail2ban-server -xf start
# ps aux|grep sshguard
root 50569 0.0 0.3 4424 3248 ? Ss 23:17 0:00 /usr/bin/sh /usr/sbin/sshguard
root 50570 0.0 0.1 4424 1892 ? S 23:17 0:00 /usr/bin/sh /usr/sbin/sshguard
root 50571 0.0 0.1 4424 1732 ? S 23:17 0:00 /usr/bin/sh /usr/sbin/sshguard
root 50572 0.0 0.1 10912 1888 ? Sl 23:17 0:00 /usr/libexec/sshguard/sshg-blocker
root 50573 0.0 0.3 4424 3304 ? S 23:17 0:00 /usr/bin/sh /usr/libexec/sshguard/sshg-fw-nft-sets
root 50574 0.0 0.1 3836 1916 ? S 23:17 0:00 /usr/libexec/sshguard/sshg-parser
The virtual and resident size of all of those sshguard processes and the parser adds up to a fraction of fail2ban, and it takes less CPU, to boot. It doesn’t do quite as much, and it’s a different syntax, but it does enough. It’s what I use on any server that doesn’t have Virtualmin (and thus already have fail2ban). I don’t hate fail2ban, but I just can’t see any reason to choose it over sshguard at this point.
So, I think we probably should replace fail2ban, even if we don’t replace firewalld. We’d need a new Webmin module, a new plugin in Virtualmin-Config, and some other code changes in Virtualmin. But, certainly a big benefit to switching.
Anybody using fail2ban in ways you can’t use sshguard?
At least firewalld is small:
# ps aux |grep firewall
root 700 0.0 0.0 317344 5452 ? Ssl Oct06 0:01 /usr/libexec/platform-python -s /usr/sbin/firewalld --nofork --nopid
VIRT is a little big, but that doesn’t really matter. nftables by itself is smaller, though.
Great idea, I would really appreciate that.
[quote=“Joe, post:6, topic:135964”]
Anybody using fail2ban in ways you can’t use sshguard?
Definition]
failregex = timeout after AUTH from .*\[<HOST>\].*
disconnect from .*\[<HOST>\].*auth=0/1
I have a few interesting filters like this.
Hmm…there is a regex parser available for sshguard, but I’ve never used it. And, the cost is high…a PCRE regex parser is going to effectively add a third of Perl to the memory usage and be quite a lot slower. And, it’s not in OS repos, AFAIK.
I think we’d have to just say “use fail2ban instead” in complicated use cases.
One of the reasons sshguard is so tiny and fast is that it’s not using regexes. It has signatures for most common services just built in…you don’t really configure the rules, and I don’t think you even can configure the rules without modifying the source, you just tell it what logs to pay attention to, and when it sees some kind of auth-related failure it responds appropriately. sshguard is not for micromanagers of firewalls and block rules, it’s for when you want to turn it on and forget about it.
From what little I know about sshguard it’s focused on blocking ssh attacks. Makes perfect sense on a non-VMin server where you may not have all the services online and being attacked.
I only use the Webmin F2b module to stop/start/reload, check the jail status - for which it is very handy. I might occasionally turn a jail on/off too.
I do the rest in a terminal session and have also moved to using /etc/fail2ban/jail.d/ format instead of jail.local
I create my own filters as blah.local which aren’t seen by the F2B module as there isn’t also a blah.conf file
So if you stop with F2B could you please leave it there as is? Even though it could do with some updates, it’s still very handy for me at least.
You know too little. 
Very true. 
Parser is here, which lists the formats it recognizes: Bitbucket
All of the services we normally use (either web server, Postfix, Dovecot, SASL, Mariadb/MySQL, BIND, and of course ssh) are all supported. Webmin and Usermin are not, but since we’re within days of releasing Virtualmin 8 and it’ll be at least Virtualmin 9 before we start shipping sshguard as default, there’s plenty of time to add it and contribute patches upstream (it might even Just Work with the Common Log format parser, I dunno).
For most, I’d imagine this is the goal anyway when it comes to out-of-the-box brute force protection. I’ve actually been pretty happy with fail2ban and Virtualmin’s modules for configuring it. I spent a short period modifying/tweaking the configuration files and I hit a place where I was happy relatively quickly. It was actually a relief to work with after coming from other panels that pushed CSF/LFD heavily.
That said, as long as it can monitor the common services you expect (which it sounds like it does), I’m all for reducing complexity of security configurations, and reducing overhead. Added to my list of go-to packages when configuring non-web hosting servers in the meantime.
I’ve made the point before. If you need CSF, you need a dedicated firewall. I remember initially my impression was it was a hook for them to sell other services. People who don’t understand security think things like these are more than they are. Set and forget. ‘How could my system have been compromised? I HAVE A FIREWALL?’
I think F2B is fine as an end of the line fine tune. I’ve thought it would be nice to actually coordinate it with the upstream firewall. Either it writes ‘upstream’ or is ‘upstream’ and reads the logs ‘downstream’.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.