If you’re running cPanel servers that process, store, or transmit credit card data, or even connect to systems that do, PCI DSS compliance isn’t optional. It’s a requirement that carries real financial and legal teeth.
With PCI DSS v4.0.1 now fully enforced (the March 31, 2025 deadline for all “best practice” requirements has passed), every hosting provider and sysadmin running cPanel in a cardholder data environment needs to take a hard look at their configurations. The problem? cPanel ships with sensible general-purpose defaults, but those defaults were never designed to satisfy PCI auditors.
This cookbook walks you through the practical, hands-on steps to harden a cPanel/WHM server for PCI DSS compliance.
Before You Begin: Scope Your Environment
The single most impactful thing you can do for PCI compliance is reduce your scope. PCI DSS v4.0 now mandates that organizations formally document their assessment scope annually, identifying every system component, person, and process that interacts with cardholder data.
For a cPanel server, ask yourself: does this server actually need to touch card data? If your clients are using third-party payment gateways like Stripe Checkout, PayPal, or Square, where the customer is redirected off-site or card data is tokenized in the browser, you may only need SAQ A compliance. That’s a dramatically smaller surface area.
If card data does traverse your server (self-hosted payment gateways, WooCommerce with direct processing, custom e-commerce applications), then the full PCI DSS applies and everything below becomes critical.
Network Segmentation and Firewall Rules
PCI DSS Requirements: 1.2, 1.3, 1.4
The CDE (Cardholder Data Environment) must be isolated. On a cPanel server, this means your firewall configuration is your first and most important control.
Install and configure CSF (ConfigServer Security & Firewall):
If you followed the ConfigServer shutdown saga, you already know that Way to the Web Ltd permanently closed on August 31, 2025, and the original download.configserver.com infrastructure is offline. The good news: cPanel now maintains an official fork of CSF focused on critical security and stability fixes, published under the original GPLv3 license.
For existing CSF installations on cPanel/WHM servers, cPanel automatically updated eligible servers on February 18, 2026 to point to their update mirrors (provided AUTO_UPDATES was enabled and the server was running CSF v14.0+). If your server wasn’t automatically migrated, or you need a fresh install, use cPanel’s built-in repair script:
# New installation or migration to the cPanel-maintained fork
/scripts/autorepair cpanel_csf_install
This installs CSF from cPanel’s repository and configures the update source to point to cPanel’s mirrors instead of the defunct ConfigServer infrastructure. Once installed, verify the update path is correct and enable automatic updates:
# Verify CSF is installed and functioning
perl /usr/local/csf/bin/csftest.pl
# Ensure AUTO_UPDATES is enabled in /etc/csf/csf.conf
# so you receive security patches from the cPanel fork
grep AUTO_UPDATES /etc/csf/csf.conf
For a deeper dive on the ConfigServer shutdown, migration options, and what this means for non-cPanel servers, check out our CSF Post-Shutdown Survival Guide.
Once CSF is installed and receiving updates from the cPanel fork, edit /etc/csf/csf.conf and lock down your allowed ports. A PCI-hardened cPanel server should expose only what’s strictly necessary:
# Inbound allowed ports
TCP_IN = "22,80,443,2083,2087,2096"
# Outbound allowed ports
TCP_OUT = "22,25,53,80,113,443,2087,2089"
# Enable SYN flood protection
SYNFLOOD = "1"
SYNFLOOD_RATE = "75/s"
SYNFLOOD_BURST = "25"
# Connection tracking
CT_LIMIT = "300"
CT_INTERVAL = "30"
# Enable port scan detection
PS_INTERVAL = "300"
PS_LIMIT = "10"
Remove FTP ports (21, 20) entirely if you can mandate SFTP-only access (you should). Remove port 2095 (webmail over HTTP) and force all webmail through 2096 (HTTPS).
Key audit point: PCI DSS 1.3 requires that the CDE is not directly accessible from untrusted networks. If your cPanel server is hosting both PCI and non-PCI sites, you have a segmentation problem. The cleanest approach is dedicating a server (or VPS) exclusively to PCI-scoped accounts.
Eliminate Vendor Defaults and Harden System Configuration
PCI DSS Requirements: 2.1, 2.2, 2.2.1
This is where most cPanel servers fail their first scan. PCI DSS requires you to change all vendor-supplied defaults and remove unnecessary functionality.
Change default ports for administrative access:
# In WHM: Tweak Settings > System
# Or via command line, edit /var/cpanel/cpanel.config
# Change SSH port
sed -i 's/#Port 22/Port 2222/' /etc/ssh/sshd_config
systemctl restart sshd
Disable unnecessary cPanel services in WHM:
Navigate to WHM → Service Manager and disable anything not required:
- cpdavd (WebDAV) – disable unless explicitly needed
- cphulkd – keep enabled (brute force protection)
- ipaliases – disable if not using dedicated IPs per account
- Mailman – disable if mailing lists aren’t needed
Remove unnecessary RPM packages:
# Audit installed packages
rpm -qa | sort > /root/installed_packages.txt
# Common packages to remove on PCI servers
yum remove -y cups cups-libs xorg-x11* wireless-tools \
bluetooth* avahi* telnet-server rsh-server
PCI DSS 2.2.1 states that only one primary function should be implemented per server. This is the requirement that causes the most friction in shared hosting. A cPanel server inherently combines web, mail, DNS, and database functions. For strict compliance, you need to either justify this combined role with documented compensating controls or separate services across multiple servers (dedicated MySQL server, external DNS, etc.).
TLS Configuration – Kill Weak Protocols and Ciphers
PCI DSS Requirements: 4.2.1, 4.2.2
This is the recipe that directly addresses the most common PCI scan failures on cPanel servers. You need to disable all SSL/TLS protocols below TLS 1.2 and eliminate weak cipher suites.
Apache (EasyApache 4):
In WHM, navigate to Service Configuration → Apache Configuration → Global Configuration, or edit directly:
# /etc/apache2/conf.d/includes/pre_virtualhost_global.conf
SSLProtocol -ALL +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder on
SSLCompression off
# HSTS header
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
After making changes, run the distiller and restart:
/usr/local/cpanel/bin/apache_conf_distiller --update
/scripts/rebuildhttpdconf
systemctl restart httpd
cPanel and WHM services (ports 2083, 2087, 2096):
Edit /var/cpanel/cpanel.config:
tls_minimum_version=1.2
Then restart cPanel:
/scripts/restartsrv_cpsrvd
Exim (SMTP):
In WHM → Exim Configuration Manager → Advanced Editor, add to the top of the config:
tls_require_ciphers = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
openssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1
Dovecot (IMAP/POP3):
Edit /etc/dovecot/conf.d/10-ssl.conf:
ssl_min_protocol = TLSv1.2
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
ssl_prefer_server_ciphers = yes
Pure-FTPd (if FTP must remain enabled):
Edit /var/cpanel/conf/pureftpd/main:
TLSCipherSuite: HIGH:!aNULL:!MD5:!RC4
MinTLS: 1.2
Then rebuild and restart:
/scripts/setupftpserver pure-ftpd --force
systemctl restart pure-ftpd
Verify everything with:
# Test Apache
openssl s_client -connect yourdomain.com:443 -tls1_1
# This should FAIL (connection refused)
openssl s_client -connect yourdomain.com:443 -tls1_2
# This should SUCCEED
# Quick nmap scan for cipher validation
nmap --script ssl-enum-ciphers -p 443 yourdomain.com
Access Control and Authentication Hardening
PCI DSS Requirements: 7.2, 8.2, 8.3, 8.4, 8.5, 8.6
PCI DSS v4.0 significantly strengthened authentication requirements. Multi-factor authentication (MFA) is now mandatory for all access into the CDE, not just administrative access.
Enforce strong passwords in WHM:
Navigate to WHM → Password Strength Configuration:
- Set minimum password strength to 65+ (cPanel’s 0-100 scale)
- Require passwords of at least 12 characters (PCI DSS 8.3.6 now requires minimum 12)
Enable Two-Factor Authentication:
WHM → Two-Factor Authentication → enable for all WHM/cPanel accounts. cPanel supports TOTP (Time-based One-Time Passwords) natively.
For SSH, implement key-based authentication and disable password auth:
# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
MaxAuthTries 3
LoginGraceTime 60
AllowUsers youradminuser
For an additional MFA layer on SSH, install Google Authenticator PAM:
yum install -y google-authenticator
# Configure per-user with: google-authenticator
# Add to /etc/pam.d/sshd:
auth required pam_google_authenticator.so
# In sshd_config:
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
Implement session timeouts (PCI DSS 8.2.8):
# /etc/profile.d/pci_timeout.sh
TMOUT=900
readonly TMOUT
export TMOUT
In WHM, set the session timeout to 15 minutes or less under Tweak Settings → Security.
Account review cadence: PCI DSS v4.0 requires human accounts to be reviewed every six months. Set a calendar reminder. Document every cPanel account, its purpose, and who has access. Application/system accounts should be reviewed at a frequency determined by a targeted risk analysis.
Logging and Monitoring
PCI DSS Requirements: 10.2, 10.3, 10.4, 10.5, 10.7
Logging is non-negotiable and v4.0 now requires automated mechanisms to detect and alert on security events.
Enable comprehensive audit logging:
# Install auditd if not present
yum install -y audit
# Configure key audit rules in /etc/audit/rules.d/pci.rules
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k actions
-w /var/log/lastlog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k system-locale
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /var/cpanel/ -p wa -k cpanel_config
# Enable and start
systemctl enable auditd
systemctl start auditd
Configure centralized log shipping:
PCI DSS 10.5 requires that logs be secured and made tamper-evident. Ship your logs to a remote syslog server:
# /etc/rsyslog.d/pci-remote.conf
*.* @@remote-syslog-server.yourdomain.com:514
NTP synchronization (PCI DSS 10.6):
All system clocks must be synchronized:
# Verify chrony is running
systemctl status chronyd
# /etc/chrony.conf - use at least two reliable NTP sources
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
Set up automated alerting:
cPanel’s built-in Contact Manager (WHM → Contact Manager) should be configured to alert on login failures, service status changes, and disk usage. For PCI-grade monitoring, supplement with a tool like OSSEC or Wazuh:
# Install Wazuh agent for HIDS
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
# Follow Wazuh agent installation for your Wazuh manager
Vulnerability Management
PCI DSS Requirements: 5.2, 5.3, 6.2, 6.3, 11.3
Anti-malware:
PCI DSS 5.2 requires anti-malware solutions on all systems. For cPanel, ClamAV is the go-to:
# Install via WHM → cPanel → Manage Plugins → enable ClamAV
# Or via CLI:
/scripts/update_local_rpm_versions --edit target_settings.clamav installed
/scripts/check_cpanel_rpms --fix --targets=clamav
Supplement ClamAV with a more aggressive scanner like ImunifyAV or Imunify360 for real-time filesystem monitoring and proactive defense.
Patch management:
PCI DSS 6.3.3 requires critical patches to be installed within 30 days of release. Automate this:
# Enable automatic security updates
yum install -y yum-cron
# /etc/yum/yum-cron.conf
update_cmd = security
apply_updates = yes
For cPanel itself, ensure automatic updates are enabled:
# /etc/cpupdate.conf
CPANEL=stable
UPDATES=daily
RPMUP=daily
SARULESUP=daily
Quarterly vulnerability scanning (PCI DSS 11.3):
You’ll need an Approved Scanning Vendor (ASV) to perform quarterly external scans. Common choices include Qualys, Trustwave, and SecurityMetrics. Run your own pre-scans with:
# Install and run OpenVAS/GVM for internal scanning
# Or use nmap for a quick check
nmap -sV -sC --script vuln yourdomain.com
File Integrity Monitoring
PCI DSS Requirements: 11.5
File integrity monitoring (FIM) is a hard requirement. You need a mechanism to detect unauthorized changes to critical system files.
AIDE (Advanced Intrusion Detection Environment):
yum install -y aide
# Initialize the database
aide --init
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
# Create a daily cron check
cat > /etc/cron.daily/aide-check << 'EOF'
#!/bin/bash
/usr/sbin/aide --check | /bin/mail -s "AIDE Report - $(hostname)" [email protected]
EOF
chmod +x /etc/cron.daily/aide-check
Configure AIDE to monitor PCI-critical paths:
# /etc/aide.conf additions
/etc/httpd CONTENT_EX
/usr/local/cpanel CONTENT_EX
/var/cpanel CONTENT_EX
/etc/exim CONTENT_EX
/etc/dovecot CONTENT_EX
/etc/ssh CONTENT_EX
If you’re running Imunify360, it includes built-in file integrity monitoring capabilities that satisfy this requirement out of the box.
Web Application Security
PCI DSS Requirements: 6.4, 11.6
PCI DSS v4.0 introduced some of its most impactful new requirements around web application security. Requirement 6.4.2 mandates automated technical solutions (such as a WAF) for public-facing web applications, and requirements 6.4.3 and 11.6.1 require strict control and monitoring of payment page scripts.
Install ModSecurity with OWASP rules:
In WHM → Security Center → ModSecurity Configuration:
- Enable ModSecurity
- Install the OWASP ModSecurity Core Rule Set (CRS)
- Set to “Detection Only” first, then switch to “On” after tuning false positives
Payment page script integrity (PCI DSS 6.4.3 and 11.6.1):
This is the requirement that catches many hosting providers off guard. Every script executing on a payment page must be inventoried, authorized, and monitored for unauthorized modification. If your clients’ e-commerce sites load third-party JavaScript on checkout pages, each script needs to be documented with a business justification, and you need a mechanism to detect if unauthorized scripts are injected.
For cPanel-hosted sites, guide your clients toward implementing Content Security Policy (CSP) headers and Subresource Integrity (SRI) attributes on their payment pages. At the server level, you can enforce CSP headers as defaults in Apache:
# /etc/apache2/conf.d/includes/pre_virtualhost_global.conf
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://js.stripe.com; frame-src 'self' https://js.stripe.com;"
Data Encryption at Rest
PCI DSS Requirements: 3.4, 3.5
If cardholder data is stored on disk (even temporarily), it must be encrypted. PCI DSS v4.0 strengthened the requirements around disk-level encryption, specifying that whole-disk encryption alone is only acceptable for removable media.
For cPanel servers processing card data, the application layer should handle encryption (your e-commerce platform encrypting data before writing to MySQL). At the server level, ensure:
MySQL/MariaDB encryption at rest:
-- In /etc/my.cnf under [mysqld]
-- Enable InnoDB tablespace encryption
innodb_encrypt_tables = ON
innodb_encrypt_log = ON
innodb_encryption_threads = 4
-- Use the file_key_management plugin or a proper key manager
plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/encryption/keyfile
Encrypt backups:
cPanel backups should be encrypted, especially if shipped off-server:
# For cPanel backup transport, use encrypted rsync over SSH
# Or encrypt backup files with GPG before transport
find /backup -name "*.tar.gz" -exec gpg --encrypt --recipient [email protected] {} \;
Disable Cleartext Protocols
PCI DSS Requirements: 4.2, 2.2.7
No cardholder data should ever traverse an unencrypted channel. On a cPanel server, this means:
Force HTTPS redirects:
In WHM → Tweak Settings:
- Enable “Always redirect to SSL”
- Enable “Require SSL for cPanel/WHM/Webmail”
Disable plain FTP entirely:
# In WHM → FTP Server Configuration
# Set "Allow Anonymous Logins" to No
# Set "Allow Anonymous Uploads" to No
# Set "TLS Encryption Support" to Required (Command)
# Better yet, disable FTP and mandate SFTP
# /var/cpanel/conf/pureftpd/main
NoAnonymous: yes
TLS: 2
# TLS: 2 means TLS required, refusing cleartext
Disable plain IMAP/POP3:
In WHM → Mailserver Configuration → Dovecot:
# Set to require SSL/TLS for all mail connections
disable_plaintext_auth = yes
ssl = required
The Compliance Documentation Layer
Technical controls are only half the battle. PCI DSS v4.0 places heavy emphasis on documentation, policies, and targeted risk analyses. You’ll need to maintain:
- Information security policy covering all 12 PCI DSS requirement areas
- Network diagram showing all connections to and from the CDE
- Data flow diagram documenting where cardholder data goes
- Incident response plan with specific procedures for suspected breaches
- Change management procedures for all system modifications
- Targeted risk analyses for controls where PCI DSS allows flexible frequency (these must be reviewed every 12 months)
- Evidence of regular access reviews (every 6 months for human accounts)
Keep this documentation in a version-controlled repository. When the QSA asks for evidence, you want to hand them a clean, timestamped trail, not scramble through email threads.
Running Your Own Pre-Scan
Before your ASV scan, run a self-assessment. A useful pre-scan checklist:
# Check for TLS 1.0/1.1 on all services
for port in 443 2083 2087 2096 993 995 465 587; do
echo "=== Port $port ==="
echo | timeout 5 openssl s_client -connect localhost:$port -tls1_1 2>&1 | grep -i "protocol\|error\|alert"
done
# Check for default/weak SSH config
grep -E "^(PermitRootLogin|PasswordAuthentication|Protocol|X11Forwarding)" /etc/ssh/sshd_config
# Check listening services
ss -tlnp | grep -v "127.0.0.1"
# Verify no cleartext auth on mail
grep -r "disable_plaintext_auth" /etc/dovecot/
# Check password policies
grep -E "^(PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_MIN_LEN)" /etc/login.defs
Final Thoughts
PCI DSS compliance on a cPanel server is achievable, but it requires deliberate effort. The default cPanel installation prioritizes convenience and broad compatibility, which is the opposite of what PCI auditors want to see. Every recipe in this cookbook closes a specific gap between those defaults and what the standard demands.
The most important takeaway: reduce your scope wherever possible. If you can keep cardholder data off your cPanel server entirely by using tokenized payment gateways, you turn a massive compliance project into a manageable one. For the cases where that’s not possible, the configurations above give you a solid foundation to build on.
Remember that compliance is not a one-time checkbox. PCI DSS v4.0 explicitly emphasizes continuous security as an ongoing process. Schedule quarterly internal reviews, keep your ASV scans clean, and treat every configuration change as a potential compliance event.