Plesk Hardening: ASK AI if Your Plesk Extensions are Safe and you are Locked Down, and for Additional Hardening

by | Apr 15, 2026 | Misc | 0 comments

Go to our Plesk extensions page, and in the right pane of Comet ask for an evaulation using AI assistant. Example:

You’re in very good shape already; you’ve got most of what I’d normally tell someone to install. Here’s a focused hardening checklist tailored to what you have on this Obsidian box.

1. Core Plesk security settings

  • Turn on Multi-Factor Authentication (MFA) for the admin and any reseller/customer logins that can touch hosting or DNS.
  • Under Tools & Settings → Security Policy, enforce strong password policy and, if possible, restrict outdated TLS versions and weak ciphers.
  • Keep Plesk Obsidian and all extensions (Imunify, Sitejet, WP Toolkit, etc.) fully updated; enable automatic updates for micro‑releases.

2. Network and firewall

  • Use the Plesk Firewall extension to: allow only needed service ports, limit remote admin access (e.g., only from your static IP/VPN if feasible), and block all else.
  • If SSH is exposed, change it to key‑based auth only, no password logins, and consider a non‑standard port (you have SSH Terminal, so you can do this quickly).
  • Make sure Docker‑exposed ports aren’t accidentally published to the world unless necessary, especially if you start using Docker for apps.

3. Imunify and intrusion protection

  • In Imunify, enable:
    • Proactive Defense,
    • Malware scanner on cron + inotify (if available),
    • automatic cleanup/quarantine for high‑confidence hits.
  • Tie SSH and Plesk login to Fail2Ban (Imunify can complement this) with sensible bans for repeated failures.

4. Web stack and certificates

  • Use Let’s Encrypt / SSL It! to ensure every domain and the Plesk panel are on valid SSL with HTTP→HTTPS redirects.
  • Default your service plans to modern PHP versions only, and lean on TuxCare PHP ELS only for legacy stuff you absolutely must keep; phase those out when you can.
  • For WordPress sites (via Softaculous or WP Toolkit), use WP Toolkit’s security hardening presets and auto‑updates; that’s where most real-world risk will be, not Sitejet.

5. Backups and monitoring

  • Use Scheduled Backups List + Amazon S3 Backup to ensure you have at least daily backups going off‑server; test a restore occasionally.
  • Turn on Monitoring + Grafana to watch CPU, RAM, disk, and 5xx error spikes; that’s often your first signal of abuse or brute‑force activity.
  • Configure Watchdog to restart critical services on failure and alert you when things go sideways.

6. DNS and surface area

  • Use Plesk DNSSEC for zones you host, and keep DNS tidy (no old test subdomains or open endpoints).
  • Fix the DNS for anywheredining.com so the domain actually resolves, then confirm the only public web endpoints are the ones you intend (no stray dev vhosts).

7. Sitejet-specific notes

  • Treat Sitejet sites as mostly “locked down” frontends: no custom PHP, no random plugins, little attack surface; just keep Plesk, Sitejet, and SSL up to date.
  • If you later add forms or integrations, be careful with where they submit (avoid exposing unprotected custom scripts in other vhosts).

Ask the assistant to outline a “golden” Service Plan config (permissions + PHP + Sitejet/WP defaults) so every new subscription comes out pre‑hardened with this stuff baked in.

Here’s a “golden” service plan baseline you can apply to your main hosting plan so new subscriptions come out pre‑hardened.

1. Permissions to disable by default

In the plan’s Permissions tab, for normal sites:

  • Turn off “Hosting settings management” so customers can’t weaken PHP/web settings you enforce globally.
  • Turn off “Setup of potentially insecure web scripting options that override provider’s policy” (only becomes available if you allowed hosting settings mgmt).
  • Turn off any legacy stuff you don’t use: CGI support, Perl, Python, Ruby, Node.js, unless you actually need them for a given customer.

You (admin) can always temporarily enable these per‑subscription if a specific site really needs them.

2. PHP, scripting, and handlers

On the plan’s PHP settings / Hosting:

  • Default to one modern PHP-FPM version (from OS packages or TuxCare ELS) with opcache; avoid Apache module handler.
  • Disable functions you never need globally, e.g. exec, shell_exec, passthru, proc_open, popen, system, curl_multi_exec (you can relax this if some app truly needs them).
  • Turn off “allow_url_include” and “display_errors” in production; log errors instead.

3. File transfer and remote access

In plan and server‑wide settings:

  • Disable plain FTP access; use FTPS/SFTP only.
  • Don’t give shell access in the plan by default; only grant chrooted SSH on a per‑subscription basis when needed.

You can enforce this globally and only override for your own development subscriptions.

4. Web server security defaults

Use the plan’s Web server settings / Apache & nginx as a preset:

  • Enable HTTPS redirect by default once Let’s Encrypt / SSL It! issues a cert (you can bake this into a skeleton or apply via a post‑create script).
  • Add sane security headers in the plan’s web server settings so they apply to all new vhosts, e.g.:
    • X-Frame-Options SAMEORIGIN (or DENY if you don’t use framing)
    • X-Content-Type-Options nosniff
    • Referrer-Policy strict-origin-when-cross-origin
    • Content-Security-Policy at least limiting scripts to self and known CDNs for generic sites.

5. Mail and rate limits in the plan

From the CLI or GUI for the plan:

  • Set a sane outgoing messages per subscription per hour limit (e.g., 200–500 for regular sites), not unlimited; this protects IPs if a site gets compromised.
  • Disable “Mailing lists” and any legacy webmail apps you don’t use.
  • Enforce SSL/TLS for SMTP/IMAP and avoid plaintext auth over unencrypted connections.

You can override higher limits only on your own bulk‑mailing/SMTP boxes where you control the apps.

6. DNS and Sitejet/WordPress defaults

In the plan’s Hosting features:

  • Enable Sitejet Builder and disable auto‑install of other random site apps unless you specifically want to offer them.
  • For WordPress, rely on WP Toolkit defaults, then in WP Toolkit set: auto‑updates for core and security releases, security hardening presets, disallow file editing from wp‑admin.
  • Turn on DNSSEC support for zones (if your registrar supports DS records) in the plan or as a follow‑up step.

7. Applying to existing subscriptions

Once the plan is tuned:

  • Sync all existing subscriptions with this plan (respecting locked items you’ve customized per‑subscription).
  • For email limits, you can also mass‑update via plesk bin service_plan (e.g., -outgoing_messages_subscription_limit 200) then sync.