New user: Does Hestia CP have bruteforce password protection built-in?

Hi all,

New user here. So I’ve now been running Hestia CP for around a week and mostly play with it in the weekends. I’ve installed web- and mail-server and am running wordpress, now with the “Security Overview”-plugin, which I think is really nice. So I’m blocking people trying to bruteforce attack my admin password with this plugin. But that’s only for the wordpress-site. Now I’m thinking: What should I do to avoid brute-force attacks on the Hestia CP? Example: www.mysite.com has protection via WP plugin, but I think hcp.mysite.com:8083 has no protection so people can bruteforce all they want? Or am I misunderstanding something? Finally, I’m using Roundcube as webmail client at mail (dot) mysite (dot) com - do I need to do something to protect against bruteforce password attacks for the mailserver?

Is already built in with fail2ban, you can have a look at the configs in /etc/fail2ban.

You can tune fail2ban to suit your needs.

It already has a rule for hestiaCP accesses and IMAP accesses.

As for the WordPress, you can use a plugin that integrates with fail2ban

By default the ip should be blocked for 15 min after failed attempts…

Ah, that’s really great… I’ve reading a bit abount it - looks really cool and iptables -nvL tells that several services are automatically protected:

    0     0 fail2ban-HESTIA  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8083
    0     0 fail2ban-FTP  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:21
   86  6096 fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
46037 2454K fail2ban-MAIL  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 25,465,587,110,995,143,993
 121K   55M fail2ban-RECIDIVE  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 1:65535

The only thing I don’t understand is “RECIDIVE” - but here is a few of those that have been blocked by something (did fail2ban do it?):

Chain fail2ban-RECIDIVE (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  *      *       87.246.7.77          0.0.0.0/0            reject-with icmp-port-unreachable
    7   420 REJECT     all  --  *      *       87.246.7.76          0.0.0.0/0            reject-with icmp-port-unreachable
   17  1000 REJECT     all  --  *      *       87.246.7.226         0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       41.216.183.105       0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       37.139.128.29        0.0.0.0/0            reject-with icmp-port-unreachable

… But it’s great to hear I need not worry… Well, the only thing I’m unsure about is: These rules protect if a single if tries bruteforce-guessing my passwords. If someone does a botnet attack on my website, ddos, these rules won’t help, right? In that case I think I need cloudflare or something for my website, is that understood correctly?

Do you have a recommendation for that, that integrates well with fail2ban (I currently use “Security Overview” and although this seem to do many great things, this did not include “rate-limiting” protection in the free version and I do not wish to pay, for a small hobby-server)?

I think my /etc/fail2ban/jail.conf says “bantime = 10m” (=findtime). I think I’ll try to implement “incremental time banning” tonight (Incremental banning with Fail2Ban - Visei Internet). But it’s great - from what I read you all say, I should not worry, with the default configuration (although I think I’ll make it a bit more strict as wordpress blocked around 200 ip-adresses from yesterday, which I think is a lot and don’t want any of them to succeed in getting in)…

RECIDIVE is repeated…

If a user get bannedd for 5 times it het added to the RECIDIVE and banned for a longer period…

Could also be 10 min I don’t remember the exact settings

Enable blacklist for all ports:
https://docs.hestiacp.com/admin_docs/settings/firewall.html#how-do-i-setup-ip-set-black-whitelist

@eris: Okay, thanks a lot for that information. I now think I know enough to play around with it myself. Thanks! I also followed the steps (the last link) for setting up that blacklist of suspicious ip-addresses and blocking those - NICE!

The only thing that’s on my mind now is that this wordpress-plugin I’m using “Shield Security” they say my “security score” is a bit bad because I don’t have “(Brute Force) Traffic Rate Limiting” enabled. Then they say “Traffic Rate Limiter is a Pro-only feature”, so they want money for it. When looking at the help for this feature, they write: “Traffic rate limiting is where you restrict the number of requests a single visitor can make against your site, within a certain period of time” and " There are 2 important factors in Rate Limiting your WordPress site:

  1. How many requests are allowed in the time period.
  2. How long a time period will you count the number of requests."

Is this something I can make with fail2ban and do I need it at all or is it just something they try to make people think is important so people buy the “pro”-version of their plugin? Should I worry or does hestia defaults also include some kind of “Rate Limiting”?

That’s a bit unclear for me still, sorry (but thanks!).

You can rate limit with fail2ban but I do not recommend it to you. I tried that in the past and ended banning legitimate users.

It takes a lot of trial and error.

But you may ban bad bots and repeat 403, 404 visitors and malicious requests.

You may also try the 7g firewall for Nginx. It works great.

Ok, I’ll ignore “rate limiting” for now, at least until I know more.

I think I have enough things to look at now, incl. about 7g firewall, which I found something about here: 7G firewall nginx configuration - I’ll look into that the coming days, it’s too late today. But thanks and I have the impression that the default Hestia/wordpress fail2ban-stuff is good enough for most users and what I’ll be doing is probably just some minor tweaks, thanks all!

Rate limiting also available in nginx config, if you feel like writing your own template to include it.

But maybe if you’re trying to stop password brute forcing, then the simplest approach might be just to put a basic auth on it, either in nginx or apache. (i.e using a password in .htpasswd)
I generally do this on phpmyadmin, hestia login, and sometimes wp-login.php if its getting attached a lot

I don’t think I understand that… But I got a lot of things to look deeper into now, which is really great… I’ll try to look at this tonight and see if I understand what you suggested (and read the link), thanks :smile:

Hi @pluto I have read the rate limiting Nginx doc and I would like to implement it for my WordPress hosting.

Do you have an implementation that could serve as a starting point? I host mainly WordPress sites and I fear to block Googlebot.

The relationship between the rate, the bursts and the geoip map is tricky for sure.

I don’t have one that I’ve tried on Hestia. But you can start pretty simple.

The limit_req_zone bits would go in nginx.conf, and then you’d probably need to create a custom template to hold the limit_req bits.

http {
    #...

    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

    server {
        #...

        location /search/ {
            limit_req zone=one;
        }
    }
}

A forum member tried it before, but apparently was getting errors.