My apologies: Removed to avoid confusion…
1 Like
Yeah. I’ve considered the option of asking them but I wasn’t sure how it would be implemented. I was thinking a periodic check to make sure the rules were active. Or maybe anytime a new rule is created or an old one dropped? I think it would fall on them in terms of ‘pecking order’. They depend on the firewall, the firewall doesn’t depend on them so they should track it.
Thanks for the input. Maybe something I could float but I need to let this gel in my mind AND do a search to make sure there’s not something we’re missing.
The systemd unit files that decide order of starting services is, ultimately, the responsibility of the distro you’re running. So, if Fail2ban has to start after firewalld, then it’s a problem in the systemd unit files. Upstream may maintain a systemd unit file, but it’s probably customized by your OS vendor.
That said, when I look at my system:
[Unit]
Description=Fail2Ban Service
Documentation=man:fail2ban(1)
After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service
PartOf=firewalld.service
This is already correctly handled on RHEL-derived systems, as far as I can tell. So, check the fail2ban.service unit file on your system and see if it does the right thing.
Only support I found for Fail2ban is their Github. I don’t currently have an account. But top post was about ‘already banned’. I followed it the best I could but didn’t see anything obvious to me, a non coder.
Not like the restart issue doesn’t go back to discussions in 2015?
Potentially dangerous in the firewalld.conf file:
# FlushAllOnReload
# Flush all runtime rules on a reload. In previous releases some runtime
# configuration was retained during a reload, namely; interface to zone
# assignment, and direct rules. This was confusing to users. To get the old
# behavior set this to "no".
# Default: yes
FlushAllOnReload=yes
how is this dangerous, can you expand on this ?
Ok, finally it was realized that there is a configuration error, but where…?
Because it’s a recursive thing that’s been going on for years now, it’s not possible that every installation has the same problem, it’s a security problem too serious to overlook.
What is the firewalld setting or something else ?
Minor but if you do something really stupid a reboot doesn’t flush it and reset to the hard coded config.
My apologies: Removed to avoid confusion…
My apologies: Removed to avoid confusion…
My apologies: Removed to avoid confusion…
Tell me how to show it to you and I’ll do it. Do you prefer a screenshot from Webmin or a particular file?
I’ve read all your posts, but I’m just more confused…
Or maybe I’m wrong, you explained how to fix it and I didn’t understand it?
Not sure what this has to do with what I posted. I was talking about the option to NOT flush direct rules on reboot.
My apologies: Removed to avoid confusion…
Just reread what I posted, and no, the documentation in the code from the config I posted is pretty clear. Again, this is about carrying over direct rules created by Fail2ban on reload.
In previous releases some runtimeconfiguration was retained during a reload,
Setting this to NO fixes the problem. Maybe not the best way, but, a way.
My apologies: Removed to avoid confusion…
Well, jail.local has already changed for longer times and has been restarted, of course, without any difference.
All this already before opening the topic.
Regarding spam, I don’t suspect it but I’m sure of it and I don’t know how to change the configuration and block them, otherwise I wouldn’t be here asking for help…
Do you know the IP address they are using? If so do this from the command line for a quick fix.
For a single IP (of course you change the IP):
firewall-cmd --add-rich-rule="rule family='ipv4' source address='103.125.190.102' drop"
For a block of IP’s (Again changing the IP):
firewall-cmd --add-rich-rule="rule family='ipv4' source address='141.98.11.0/24' drop"
Please share your jail.local.
Here is one setup I use in a VPS and work as is on CentOS/Rocky Linux.
You may need to adjust the mail log location, other than that you could set on each jail: maxretry = 3 and bantime = 5m and to do a quick check
As always backup your jail.local before do the changes so you can go back if needed.
/etc/fail2ban/jail.local
[dovecot]
enabled = true
port = pop3,pop3s,imap,imaps,submission,465,sieve
bantime = 2d
#logpath = /var/log/maillog
logpath = %(dovecot_log)s
backend = %(dovecot_backend)s
mode = aggressive
maxretry = 20
findtime = 4h
bantime = 30m
[postfix-blacklist]
enabled = true
port = smtp,465,submission
filter = postfix[mode=rbl]
logpath = /var/log/maillog
findtime = 6h
bantime = 1d
maxretry = 1
[postfix-connection]
enabled = true
filter = postfix[mode=ddos]
port = smtp,465,submission,imap,imaps,pop3,pop3s
bantime = 2d
logpath = /var/log/maillog
findtime = 5m
maxretry = 15
[postfix-rejected]
enabled = true
port = smtp,465,submission,imap,imaps,pop3,pop3s
bantime = 7d
logpath = %(postfix_log)s
maxretry = 1
findtime = 1h
[postfix-sasl]
filter = postfix[mode=auth]
enabled = true
port = smtp,465,submission,imap,imaps,pop3,pop3s
bantime = 2d
#logpath = /var/log/maillog
logpath = %(postfix_log)s
backend = %(postfix_backend)s
findtime = 8h
maxretry = 10
[postfix-auth]
filter = postfix[mode=auth]
enabled = true
port = smtp,465,submission,imap,imaps,pop3,pop3s
bantime = 2d
#logpath = /var/log/maillog
logpath = %(postfix_log)s
backend = %(postfix_backend)s
findtime = 4m
maxretry = 6
logpath can be the path or the variable.
on webmin, tools, terminal you can run following commands:
After changes to jail.local, restart fail2ban & firewall
sudo systemctl restart fail2ban
sudo systemctl restart firewalld (CentOS/Rocky Linux)
To release all ip and start banning again:
sudo fail2ban-client unban --all
To check banned ips:
fail2ban-server status dovecot
fail2ban-server status postfix-connection
fail2ban-server status postfix-sasl
fail2ban-server status postfix-blacklist
fail2ban-server status postfix-rejected
To stop spam (received) check this post Fighting Spam & Malware with Virtualmin
To stop spam sent I will create a new post this week and hopefully will have some help. For now it may help to set a rate limit at Virtualmin, Email settings, Mail Rate Limit. This won’t stop spam but will give you time a litle time to fix it and above all you will notice right away when someone is sending spam as nobody will be able to send email.
I can help troubleshooting after 7pm CST if you provide me access.
1 Like