General VestaCP configuration Print

  • vestacp, configuration, fail2ban, security
  • 0

A few settings are worth reviewing right after installing VestaCP.

Adding an IP address

Only one IP address is selected during installation. If your server has more, add them in the IP section of the top menu: click the add button and enter the settings for the additional address.

Once added, you can choose which IP address a site should run on when creating it.

Automatic updates

The panel updates itself automatically by default. Whether to keep that on is a judgement call.

Leaving it on means security fixes arrive without your involvement, which for most people is the safer option. Turning it off gives you control over when changes happen — worth considering if the server runs something that a panel update could disturb, but only if you will in fact apply updates yourself. An unattended panel with updates disabled is the worst of both worlds.

The setting is in the Updates section.

Increasing the fail2ban ban time

VestaCP uses fail2ban to block repeated failed login attempts. By default, five wrong attempts against SSH, the panel or another service result in a firewall block for 600 seconds — ten minutes.

Automated attempts against SSH are continuous on any server exposed to the internet, and ten minutes barely slows them down. An hour is a more sensible figure.

Go to the Server section, find fail2ban at the bottom of the list and click configure. In the [ssh-iptables] section, add:

bantime = 3600

Save the changes. You can add the same parameter to the other services, and raise the number of permitted failed attempts while you are there — a legitimate user rarely mistypes a password ten times in a row.

Take care not to lock yourself out. A long ban time combined with a low attempt limit will eventually catch you as well — after a mistyped password or a stale saved credential. Note the console access route before tightening these settings: see What is IPMI (IP-KVM) and how do I connect to it? for dedicated servers, or Managing your CloudVM virtual server in the client area for virtual ones.

Worth doing as well

  • Set up key authentication for SSH and disable password login. This removes the entire class of attack that fail2ban is mitigating — see How to connect to a server via SSH.
  • Issue an SSL certificate for the panel's own address, so that your login credentials are not sent unencrypted.
  • Check that backups are configured — see Configuring backups in VestaCP.

If you are not sure which settings suit your server, describe what it will be used for in a ticket and we will suggest sensible values.


Was this answer helpful?

« Back