Linux web server security audit
A WordPress installation can be well configured while the server underneath it remains exposed. This audit reviews the Linux host — a VPS, a cloud instance, or a WHM/cPanel or Plesk server — including administrative paths, web stack, account boundaries, logging, and recovery controls that determine the real blast radius of a compromise. Hardening can be applied as part of the same engagement.
Never send credentials, private keys, backup archives, or confidential source code through this website.
What you receive
Controlled cross-site read and write between sites sharing one account.
One compromised site can reach the files and configuration secrets of three others.
Move each site into its own hosting account and PHP-FPM identity, with separate deployment and database credentials.
Open — staging migration passed; production separation still outstanding.
| Finding | Final disposition |
|---|---|
| VPS-01 · Root SSH password access | Resolved Acceptance checks passed |
| WP-01 · Public events backup | Resolved Acceptance checks passed |
| HOST-01 · Shared filesystem identity | Open Staging passed, production due 2 October |
| INFO-01 · Public version metadata | Accepted Named approver, review due 22 December |
From the 22-page sample report, a fully fictional worked example. Read the whole report
Active incident
A root-level incident review reads the process table, every crontab and systemd timer, every account home outside public_html, SSH keys and API tokens, and outbound sessions before anything is deleted. It then contains the affected accounts, rotates credentials, and decides on evidence whether accounts can be cleaned in place or the host needs a rebuild.
Active incidents receive a reply the same business day; every other inquiry within 24 hours. Once the server is clean, this audit is the right next step to measure and harden it.
Host scope
Listening services, DNS and TLS behavior, administrative interfaces, default sites, banners, and unintended network reachability.
SSH configuration, account lifecycle, privilege escalation, MFA where supported, key handling, and emergency access.
Supported software, patching, service minimization, scheduled work, process ownership, and security-relevant operating-system controls.
Nginx or Apache configuration, PHP execution boundaries, upload handling, sensitive paths, headers, and per-site isolation.
Ownership, permissions, credentials, database exposure, backups, secrets, and separation between sites or tenants.
Security logs, retention, alerting, backup separation, restoration evidence, and response responsibilities.
Deliverable
Server findings often cross boundaries between a site owner, developer, systems administrator, and hosting provider. The report identifies the responsible layer instead of leaving the client with generic hardening advice.
“Guido provided valuable technical support and security expertise throughout a complex server security project. He was thorough in his assessments, identified important risks clearly, and provided practical advice that helped us better understand the wider security position across our hosting environment. We appreciated the depth of his technical knowledge and the quality of the audit work he delivered…”
WHM, cPanel, and Plesk servers
A WHM/cPanel or Plesk server hosts many accounts on one Linux host. A per-site WordPress scan cannot see the layer where the serious problems live: the home directories, the process table, cron, and the isolation between accounts.
In a documented engagement, Wordfence and ImunifyAV both reported a WooCommerce shop clean at the file level and the database was spotless — while a packed ELF backdoor sat in a hidden folder inside the account’s home directory, outside the document root, on a server carrying 261 accounts. Only a root-level filesystem review found it. That is the vantage point this audit takes on a control-panel server.
The control-panel review covers CageFS and PHP handler isolation, per-account execution restrictions, cPanel and WHM user lifecycle and API tokens, the ImunifyAV and CSF/LFD configuration actually in force, hidden files and executables in every account home, cron and scheduled work, outbound connections, and whether one compromised account can reach its neighbours.
CageFS, open_basedir, PHP-FPM pools, suEXEC/mod_ruid2, and whether files in one account are readable from another.
Executables, hidden dot-directories, and recently changed files outside public_html across every account — where per-site scanners never look.
WHM root and reseller logins, cPanel users, API tokens, SSH keys, FTP accounts, and the two-factor and IP-restriction settings applied to each.
ImunifyAV/Imunify360 heuristics and exclusions, CSF/LFD rules, ModSecurity rulesets, and whether alerts reach a person who acts on them.
Cron entries per user, systemd timers, at jobs, and outbound connections that bypass an inbound-only firewall.
Backup coverage, restore evidence, and whether one account can be rebuilt without touching the rest of the server.
Hosting contexts
The audit is regularly applied to VPS and cloud instances on DigitalOcean, Hetzner, Linode/Akamai, Vultr, AWS Lightsail and EC2, and to control-panel servers running WHM/cPanel, Plesk, RunCloud, GridPane, and CloudPanel. The stack usually pairs Nginx or Apache (often both, with Nginx as a reverse proxy), PHP-FPM, MariaDB or MySQL, and a Cloudflare or other CDN in front.
Findings are mapped to the layer that owns them. On a fully managed VPS the fix is usually in your hands; on a control-panel server some controls belong to the panel’s own configuration; on shared hosting the audit documents what the provider must supply. Recommendations follow the CIS Distribution Independent Linux benchmark where it applies to a web host, without applying settings that would break the panel, the deployment pipeline, or the site.
Audit or hardening
| Engagement | Question answered | What you receive |
|---|---|---|
| Server security audit | Where is the host exposed, and which layer owns each gap? | Prioritized findings with evidence, ownership, and retest results |
| Server hardening | Apply the agreed fixes safely on a live server | Implemented changes with rollback notes, a change record, and verification |
| Ongoing security care | Keep the hardened baseline from drifting | Monthly review of access, patches, configuration, and recovery signals |
Approach
Hardening advice is not applied blindly. A control that is appropriate for a single-purpose VPS may be unsafe for shared hosting, a control panel, a clustered platform, or a server with deployment automation.
The engagement records dependencies, rollback expectations, testing windows, and emergency contacts before active changes. Recommendations distinguish immediate exposure from longer-term architectural improvement.
Common questions
Typically $300–$750 per server, delivered in 2–4 business days. A single-purpose VPS sits at the lower end; a WHM/cPanel or Plesk server with many accounts, a control panel, or a hardening implementation on top of the audit moves it up. The written proposal fixes the fee before any access is exchanged.
Yes. Control-panel servers are a core use case: account isolation, panel access, scanner configuration, hidden files across account homes, and per-account recovery are reviewed from a root-level vantage point, not from inside one WordPress site.
Yes. The same scope applies to VPS and cloud instances on DigitalOcean, Hetzner, Linode, Vultr, AWS, and similar providers — SSH, firewall, patching, web and PHP runtime, database exposure, backups, and logging.
Some review areas require privileged visibility, but the minimum necessary access is agreed during scoping. External and unprivileged checks can be completed first.
Only the controls visible or configurable within the account can be reviewed. Host-owned isolation and operating-system controls may require cooperation from the provider.
Yes. The exact web stack and any proxy, CDN, WAF, or control-panel layers are documented during scoping.
Yes, where authorized and operationally safe. Changes can also be supplied to an existing administrator and independently retested.