Security Best Practices

This page covers security hardening for both server admins and hosting account users. Running a shared hosting server means two distinct attack surfaces: the server itself, and the applications your customers run on it.

For server admins#

OS and software#

• Keep the OS patched. Run dnf update (AlmaLinux/RHEL) or apt upgrade (Debian/Ubuntu) weekly. Unpatched kernel and system packages are the most common root-compromise vector.
• Keep Opterius Panel and the agent updated. Each release may include security patches.
• Remove unused services. If you are not using a service, disable and remove it. Every running service is an additional attack surface.

SSH hardening#

• Use SSH keys, not passwords. Disable password authentication in /etc/ssh/sshd_config:

  PasswordAuthentication no
  PubkeyAuthentication yes
  

• Restrict SSH to specific IPs. Use the Firewall to allow port 22 only from your known admin IPs.

• Change the default SSH port if you receive high volumes of automated scan traffic (optional — security through obscurity, but reduces log noise).

• Enable Fail2ban. Opterius installs it automatically. Verify it is running: systemctl status fail2ban. See Fail2ban.

Panel and agent access#

• Enable 2FA for your admin panel login. Server Mode → Your Account → Two-Factor Authentication.

• Use a strong, unique agent token. The agent token is set during install. If you suspect it is compromised, rotate it and restart the agent.

• Restrict agent port (8444) to localhost or your admin IP only. The panel communicates with the agent locally. Exposing port 8444 to the public internet is unnecessary:

  # UFW — restrict agent port to local only
  ufw deny 8444
  ufw allow from 127.0.0.1 to any port 8444
  

• Use a dedicated IP for nameservers. If you run PowerDNS, point NS records at a separate IP that does not also serve the panel or customer sites. See Pointing Nameservers.

Monitoring and incident response#

• Run scheduled malware scans. Weekly at minimum. See Malware Scanning.

• Store backups off-server. An on-server backup is not a backup if the server is compromised or the disk fails. Use S3 or Backblaze B2. See Scheduled Backups.

• Review Fail2ban logs regularly. A sudden spike in ban activity may indicate a coordinated attack:

  fail2ban-client status sshd
  journalctl -u fail2ban --since "24 hours ago"
  

• Set up server monitoring. Watch CPU, memory, and disk usage. Unusual CPU spikes often indicate cryptomining malware. Disk space exhaustion can cause backup failures and mail queue buildup.

• Know how to use Lockdown Mode. If a server is actively compromised, mass-suspending accounts stops the immediate damage while you investigate.

For hosting account users#

Passwords#

• Use strong, unique passwords for your panel login, email accounts, and databases. Do not reuse passwords across services.
• Enable 2FA for your Opterius Panel login. Hosting Mode → Your Account → Two-Factor Authentication.
• Change default application passwords immediately after installing WordPress or any other CMS. The default admin password is often targeted.

Application security#

• Keep WordPress, plugins, and themes updated. The vast majority of shared hosting compromises happen through outdated WordPress plugins. Update weekly.
• Remove inactive plugins and themes. Inactive plugins still run if not deleted and may contain vulnerabilities.
• Do not upload PHP files from untrusted sources. Nulled plugins and themes frequently contain backdoors. If the source is not official, do not install it.
• Restrict file upload directories from executing PHP. If your application allows file uploads, configure Nginx to deny PHP execution in the upload directory. Ask your admin if you need this configured.

File transfer#

• Use SFTP or SSH instead of FTP. Plain FTP transmits credentials in cleartext. Opterius does not install an FTP server by default — use SFTP with your SSH credentials.
• Audit file permissions after deployments. PHP files should generally be 644 and directories 755. Do not set 777 on files or directories.

Backups#

• Create a backup before major changes. Before updating WordPress, importing a large database, or deploying new application code, create an on-demand backup. See Creating a Backup.
• Verify your backups work. Periodically download a backup and confirm it contains what you expect. A backup you have never tested is a backup you cannot trust.