Just curious … I installed Hestia on a Digital Ocean VM for testing purposes a couple of days ago. I’d usually apply some security tweaks to it, such as putting basic auth on any logins, and usually I’d move from iptables/fail2ban to CSF, but I didn’t bother this time.
I notice that after two days, fail2ban has created the following blocks.
0 for fail2ban-SSH
5 for fail2ban-MAIL
262 for fail2ban-HESTIA
ssh is running on non-standard port, so I’d normally expect this. It takes a few days for scanners to locate ssh running on a non-standard port. And the 5 for mail servers, is within my expectations too. But the 262 login attempts for Hestia seem a bit strange, especially as it is running on a non-standard port as well. Any ideas how the hackers located a new install of Hestia on a non-standard port so quickly?
Going to add a bit more info here … despite the fact the iptables chains are called HESTIA, the actual IPs on that chain seem to have been added by the fail2ban recidive jail. This seems to be an implementation of a ‘repeat offenders’ filter, which looks through the fail2ban log, and bans any IPs which have attacked the server multiple times, for a much longer period.
[recidive]
enabled = true
filter = recidive
action = hestia[name=HESTIA]
logpath = /var/log/fail2ban.log
maxretry = 5
findtime = 86400
bantime = 864000
In this case, I’m guessing my original assumption was wrong. The 262 IPs on this list aren’t just trying to hack into HESTIA cp login, but have been detected by ANY of the jails on the server, including the typically busy jail on mail ports. So that explains it I think. Probably answered my own question.
Still finding things on Hestia that work slightly different to ‘the other cp’, so forgive my curiosity.
Nice. Made the changes manually. (edited /etc/fail2ban/jail.local , edited v-add-firewall-chain), then ran
v-add-firewall-chain RECIDIVE
systemctl restart fail2ban
All good, and the 262 bans now appear under the new chain, which blocks them a lot more comprehensively.
