A web hosting server is hard to secure for a simple reason: you don't control most of the code running on it. Every customer brings their own WordPress plugins, upload forms, outdated themes and weak passwords. A single compromised site can turn into a spam relay, a crypto miner or a phishing host, and the server's IP reputation takes the hit for everyone.
This guide covers the layers that matter most on a shared Linux hosting server, in the order an attack usually reaches them:
- Network edge: blocking known-bad sources (IP and CIDR blocking).
- Authentication: stopping brute force on SSH, FTP and mail (Fail2Ban).
- Application layer: filtering malicious HTTP requests (ModSecurity WAF with the OWASP Core Rule Set).
- Filesystem: catching malware the moment it lands (real-time scanning and quarantine).
- Containment: making sure one compromised account can't reach the others (isolation).
- Transport and mail trust: SSL everywhere, plus SPF, DKIM and DMARC.
For each layer I'll explain what it does and how to set it up by hand on a generic server, then show how it looks when it's built into a hosting control panel. My examples use HPanel, the self-hosted control panel I work on, because it ships all of these layers by default. The principles apply anywhere.
Disclosure: I'm on the HPanel team. HPanel feature details come from the public features page. Generic commands are standard Linux tooling.
Layer 0: The boring basics (do these first)
None of the layers below help if the foundation is weak. Before anything else:
-
Patch regularly. Apply OS security updates on a schedule (
unattended-upgradeson Ubuntu is a reasonable default). -
Use SSH keys for root and admin access, and disable password logins where you can (
PasswordAuthentication noinsshd_config). -
Close what you don't use. A default-deny host firewall (
ufw default deny incoming) with explicit allows for web, mail, DNS and panel ports. - Separate admin and customer access. Customers should never need root.
-
Keep backups off the server. Ransomware and
rm -rfmistakes both hit local backups too.
With that in place, let's go layer by layer.
Layer 1: IP and CIDR blocking
Sometimes the right answer is simply "never talk to this address again": a scanner hammering /wp-login.php, a botnet range, or a source behind a burst of abuse reports.
By hand, that means firewall rules:
# block a single IP
sudo ufw deny from 203.0.113.45
# block a whole range (CIDR)
sudo ufw deny from 198.51.100.0/24
That works, but on a hosting server it gets messy quickly. Who added which rule and why? Can customers block abusers on their own sites without root access? Do you need to reload anything?
In a control panel, IP blocking should work at two levels: server-wide (admin) and per account (customer). In HPanel, the IP Blocker accepts single IPs, ranges and CIDR blocks, works both per account and server-wide, and takes effect instantly with no server restart.
Customers can block single IPs, ranges or CIDR blocks for their own sites.
Tip: blocking is a blunt tool. Use it for persistent sources, and let Fail2Ban (below) handle the dynamic, behaviour-based bans.
Layer 2: Brute-force protection with Fail2Ban
On any internet-facing server, SSH, FTP and mail logins are attacked around the clock. Fail2Ban watches authentication logs and temporarily bans IPs that fail too many times.
By hand, a minimal jail.local looks like this:
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
[sshd]
enabled = true
[postfix]
enabled = true
[dovecot]
enabled = true
[vsftpd]
enabled = true
Then:
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd
What matters on a hosting server:
- Cover every authentication surface, not just SSH. Mail (Postfix and Dovecot) and FTP are attacked just as often, and a cracked mailbox becomes a spam source within minutes.
- Watch the activity. A sudden spike in bans on one jail is an early warning sign.
-
Don't lock yourself out. Add your own office or VPN IP to
ignoreip.
In HPanel, Fail2Ban is installed and configured during setup with separate jails for SSH, FTP, mail (Postfix/Dovecot) and web services. The admin panel adds a live activity feed of banned IPs, failed login attempts and blocked attacks, with severity levels (Critical, High, Medium) and configurable ban durations.
HPanel's security dashboard: ClamAV and Fail2Ban status, per-jail counters and live ban activity.
Layer 3: A web application firewall (ModSecurity + OWASP CRS)
Most hosting compromises don't come through SSH. They come through HTTP: SQL injection in an old plugin, a file-inclusion bug in a theme, an XSS payload in a contact form. A WAF inspects requests before they reach PHP and blocks the ones that match known attack patterns.
The usual open-source stack is ModSecurity with the OWASP Core Rule Set (CRS), which covers SQL injection, XSS, local/remote file inclusion (LFI/RFI) and other OWASP Top 10 classes.
By hand on Nginx, you build or install the ModSecurity connector module, download CRS, include it in your config, and then spend time tuning false positives. Expect some: CRS will occasionally flag a legitimate admin form or API payload. The standard workflow is:
- Start in detection-only mode (
SecRuleEngine DetectionOnly) and read the audit log. - Add targeted exclusions for known-good paths.
- Switch to blocking (
SecRuleEngine On). - Keep a per-site off switch for emergencies.
That last point is why per-domain control matters on a shared server. One customer's custom app shouldn't force you to weaken the rules for everyone.
In HPanel, the ModSecurity WAF ships with the OWASP Core Rule Set and offers a per-domain toggle, blocked-request logs and IP whitelisting from the admin dashboard.
ModSecurity WAF settings in the HPanel admin panel.
Layer 4: Real-time malware scanning and quarantine
Even with a WAF, something will eventually land on disk: a webshell uploaded through a vulnerable form, a backdoored "nulled" plugin, or a crypto miner dropped by a compromised account. The question is how fast you notice.
A nightly clamscan cron job is better than nothing, but it gives an attacker up to 24 hours. On a hosting server you want scanning to be:
- On upload: scan files as they arrive through the file manager or FTP.
- Continuous: watch the filesystem for new and modified files across all accounts.
- Automatic on detection: quarantine or delete instead of just emailing a report.
- Auditable: scan history, per-user reports and a timeline of what was found when.
By hand, you can get part of the way with clamd plus clamonacc (on-access scanning) or an inotify-based watcher, along with scripts for quarantine and reporting. It's doable, but there are a lot of moving parts to maintain.
In HPanel, the malware system includes:
- Real-time upload scanning of every file uploaded via the file manager or FTP, using custom pattern detection plus an asynchronous ClamAV deep scan,
- a filesystem watcher that detects new and modified files across all hosting accounts,
- ClamAV with automatic signature updates, plus HPanel's own malware signature engine,
- auto-quarantine of detected threats such as backdoors, webshells and crypto miners,
- per-user and full-server scans on demand, with reports, scan history and an infection timeline.
Layer 5: Containment, so one bad account stays one bad account
Assume a site will get compromised eventually. What matters then is the blast radius.
On a shared hosting server, containment means:
- Filesystem isolation. A compromised account can't read other users' files, system binaries or server configs.
- Separate PHP pools. Each account runs PHP under its own user, so a webshell runs with that account's permissions only.
- Resource limits. A crypto miner or fork bomb can't take the whole server down.
HPanel handles this with a CageFS-style chroot filesystem jail (users can't see other users' files or server configs), per-account PHP-FPM pools, and Linux cgroups limits on CPU, RAM, IO and process count per account. A runaway process hits its own ceiling instead of the server's.
Each account runs its own PHP version and its own PHP-FPM pool.
Layer 6: SSL everywhere, and mail that other servers trust
Two last layers protect your customers' visitors and your server's reputation.
SSL. Every site should be HTTPS, with certificates that renew themselves. Expired certificates are the most common avoidable outage in hosting. HPanel issues and renews Let's Encrypt certificates automatically for every domain, with wildcard support and certificate status monitoring.
Auto-issued, auto-renewed Let's Encrypt certificates per domain.
Mail authentication. SPF, DKIM and DMARC tell other mail servers which hosts may send for a domain and let them verify the signature. Without them, your customers' legitimate mail lands in spam, and spoofed mail is easier to send in their name. In HPanel, DKIM keys and DNS records are generated automatically when an account is created, and SpamAssassin filters incoming mail.
Common hardening mistakes on hosting servers
A few patterns come up again and again when a hosting server gets into trouble:
- Scanning only at night. By the time a nightly scan finds a webshell, it has often already been used to send spam or plant more backdoors. Scanning on upload, plus a filesystem watcher, closes most of that window.
- Protecting SSH but not mail. Mail logins are attacked just as often as SSH, and a compromised mailbox damages your IP reputation faster than almost anything else. Give Postfix and Dovecot their own jails.
- Turning the WAF off server-wide after one false positive. One customer's admin form trips a rule, the WAF gets disabled for everyone, and nobody turns it back on. Use per-domain exceptions instead.
-
One shared PHP user for every site. If every site runs PHP as the same user, a single compromised plugin can read every other site's
wp-config.php. Per-account PHP-FPM pools and a filesystem jail prevent that. - No limits. Without per-account CPU, memory and process limits, a crypto miner is a server-wide outage, not a single-account incident.
- Security that depends on paid add-ons nobody renewed. If a protection layer is an optional extra, sooner or later one server won't have it. Built-in defaults are easier to keep consistent across a fleet.
A hardening checklist you can copy
| Layer | Check |
|---|---|
| Basics | OS patched on a schedule; SSH keys only; default-deny firewall; off-server backups |
| IP blocking | Server-wide and per-account blocks; CIDR support; documented reasons |
| Brute force | Fail2Ban jails for SSH, FTP, Postfix, Dovecot and web; your own IPs whitelisted; activity reviewed |
| WAF | ModSecurity + OWASP CRS; tuned in detection mode first; per-domain toggle |
| Malware | Upload scanning + filesystem watcher; auto-quarantine; signatures auto-updated; scan history |
| Containment | Filesystem jail; per-account PHP-FPM; cgroups CPU/RAM/IO/process limits |
| SSL | Auto-issue and auto-renew for every domain; expiry monitoring |
| SPF, DKIM and DMARC for every domain; spam filtering |
Wrapping up
Hardening a hosting server isn't one tool. It's a set of layers, each catching what the previous one missed: block what you know is bad, rate-limit authentication, filter HTTP, scan the disk continuously, contain the damage, and keep SSL and mail authentication automatic.
You can build every layer yourself, and on a single personal server that's a great way to learn. On a server with dozens or hundreds of customer accounts, though, you want these layers on by default and visible in one dashboard. That's what we built into HPanel: malware scanning, Fail2Ban, ModSecurity, IP blocking, isolation and auto-SSL are included in every plan, with one flat license per server and no per-account fees. Setup steps are in the documentation.
Want these protections on your own server? Buy now.
Top comments (0)