External exposure
Listening services, DNS and TLS behavior, administrative interfaces, default sites, banners, and unintended network reachability.
Linux web server security audit
Linux Web Server Security Audit: the controls beneath your WordPress site.
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.
- Best for
- VPS, cloud instances, managed servers, migrations, and insurer reviews
- Web stack
- Nginx or Apache, PHP, database, TLS, and supporting services
- Host controls
- SSH, accounts, patching, firewall, permissions, logging, and backups
- Access
- Named, temporary, least-privilege administrative access after authorization
- Typical fee
- $300–$750 per server · 2–4 business days · fixed in the written proposal
Host scope
What the server audit examines
Administrative access
SSH configuration, account lifecycle, privilege escalation, MFA where supported, key handling, and emergency access.
Linux baseline
Supported software, patching, service minimization, scheduled work, process ownership, and security-relevant operating-system controls.
Web and PHP runtime
Nginx or Apache configuration, PHP execution boundaries, upload handling, sensitive paths, headers, and per-site isolation.
Files and database
Ownership, permissions, credentials, database exposure, backups, secrets, and separation between sites or tenants.
Detection and recovery
Security logs, retention, alerting, backup separation, restoration evidence, and response responsibilities.
Deliverable
Host findings mapped to practical ownership
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.
- External attack-surface inventory
- Linux, SSH, web server, PHP, and database observations
- Cross-site and account-isolation risks
- Backup and restoration readiness findings
- Prioritized configuration changes with operational cautions
- Items requiring host or platform-provider action
- Retest results for agreed changes
WHM, cPanel, and Plesk servers
On a shared control-panel server, the account is the security boundary
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.
Account isolation
CageFS, open_basedir, PHP-FPM pools, suEXEC/mod_ruid2, and whether files in one account are readable from another.
Home-directory sweep
Executables, hidden dot-directories, and recently changed files outside public_html across every account — where per-site scanners never look.
Panel access
WHM root and reseller logins, cPanel users, API tokens, SSH keys, FTP accounts, and the two-factor and IP-restriction settings applied to each.
Scanner configuration
ImunifyAV/Imunify360 heuristics and exclusions, CSF/LFD rules, ModSecurity rulesets, and whether alerts reach a person who acts on them.
Scheduled and outbound activity
Cron entries per user, systemd timers, at jobs, and outbound connections that bypass an inbound-only firewall.
Recovery per account
Backup coverage, restore evidence, and whether one account can be rebuilt without touching the rest of the server.
Hosting contexts
Built for the servers WordPress actually runs on
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
The audit finds; hardening fixes — both are available
| 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
Changes are assessed in the context of availability
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
Questions about this engagement
How much does a Linux server security audit cost?
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.
Do you audit WHM/cPanel and Plesk servers?
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.
Is this a VPS security audit as well?
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.
Do you need root access?
Some review areas require privileged visibility, but the minimum necessary access is agreed during scoping. External and unprivileged checks can be completed first.
Can shared hosting be audited?
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.
Do you support both Nginx and Apache?
Yes. The exact web stack and any proxy, CDN, WAF, or control-panel layers are documented during scoping.
Can you implement the hardening recommendations?
Yes, where authorized and operationally safe. Changes can also be supplied to an existing administrator and independently retested.